TFTP Encryption and Synchronization Extensions (EFUP): Client and Server Programs in C

Author: James Northway


This report details a project involving the addition of security components to an application-level network protocol for transferring files between two computers. The project has been conducted for educational purposes. The protocol that has been modified is a derivation of the Trivial File Transfer Protocol (TFTP) [19], named the Trivial File Update Protocol (TFUP) [15]. The TFUP project was undertaken while learning network programming with Unix Sockets [21] at the University of Southern Queensland. It is a TFTP implementation with the addition of new packet types, and a decision process to compare the timestamp of a local and remote file of the same name. The decision process results in the transfer of the latest copy of the file to the computer with an older or missing copy of the file, over the IP network.

The protocol TFUP was derived from, TFTP, was designed to provide a minimalist means of performing file transfers over a computer network, with reliability, in situations where access to the server or the contents of transmitted data need not be limited programmatically. TFTP is by design an insecure protocol, and provides only a get and put operation. TFTP does not contain a directory listing operation, and the file name to be requested must be known prior to making a request. Beyond minimalism, a primary benefit of TFTP is the provision of a reliability mechanism for file transfer over a connectionless protocol, such as the User Datagram Protocol (UDP) [16].

The TFUP client and server programs were written in ANSI C, and the project involved modifications and additions to that source code. The security concepts implemented as additions to the TFUP protocol are authentication and confidentiality [10]. These implementations utilise hash functions [17], asymmetric key cryptography (often referred to as public key cryptography) [5] and symmetric key cryptography in the form of a block cipher [12]. The new protocol described in this report will be referred to as the Encrypted File Update Protocol (EFUP).

Problem and Existing Solutions

The problem can be defined as ensuring that data transferred over a common medium is not acquired or viewed by third parties to the transfer. This is a problem with much history and the earliest and most famous solution was Julius Caesar's cipher which involved offsetting the character of plaintext by a predefined number of characters in the alphabet sequence [4]. Cipher's have become the mainstay of ensuring confidentiality over the internet, and the existing solutions to the problem of ensuring confidentiality of transferred data are many. In the context of TFTP or TFUP, the best solution is to select a secure protocol and use that for transferring files instead. Examples of such protocols that encrypt data for transit are Secure Copy provided by SSH [23] and FTP over SSL (FTPS)[8]. It is also commonplace for data to be transmitted from server to client using a secure version of the Hypertext Transfer Protocol, HTTPS [18]. Of these three examples, FTPS and HTTPS rely on the previously published RFC, the Transport Layer Security protocol (TLS) [6].

Relevant Cryptographic Methods in TCP/IP Networking

Cryptographic Hash Functions take an input of variable length and produce a fixed length output, with the intention of the input being undiscoverable from the output, and the same output being produced from the same input. A determinant of the strength of a cryptographic hash function is the number of possible inputs that can produce the same output. These are referred to as collisions, and provide avenues for possible discovery of a plaintext that has been hashed [10]. Much of the development of hash functions has occurred comparatively slowly since the 1970s [17], at times widely used algorithms are deemed to no longer provide adequate security and are superceded by more complex ones, an example of such a situation is the MD4 and MD5 hash functions. Those functions were largely replaced by the newer SHA-1 since it was proven that meaningful collision discovery was computationally feasible in MD4 [7]. To further distance current practice from computation feasibility, SHA-1 [22] has been superceded by SHA-2 functions, and the new SHA-3 function [17]. Hashes can be used to prove that one party knows a secret that is also known by the other party by comparing hashes of that item.

Symmetric Key Cryptography is the enciphering of a plain text using a key that can also be used to decipher it. Like hash functions, symmetric cryptographic functions can be found vulnerable to new means of computation and are superceded by less vulnerable functions. An early and widely used standard, the Data Encryption Standard (DES), was found increasingly vulnerable to brute force attacks as available computing power increased over time. It was superceded by 3DES/Triple DES which included three rounds of the DES [1]. A determinant of the widespread use of a cryptographic algorithm is its publication as a United States Federal Government standard as DES was in 1977 [13]. After a number of demonstrations of methods to break DES encryption, the standard was withdrawn in 2005, three years after a new standard, the Advanced Encryption Standard (AES) came into effect [14]. To date, no practical means of breaking AES with key sizes of 256 bits or more is known, however, an improvement over brute force is theorised but is not yet computationally feasible [2]. Symmetric ciphers that do not alter the size of the data as it is encrypted are referred to as block ciphers. A distinct difference between a weaker and stronger block cipher is the use of the electronic code book (ECB) or cipher block chaining (CBC) mode. In ECB mode, the plaintext is enciphered and deciphered using the key alone. In CBC mode, the previously encrypted block is added to the next block before encryption, and an initialization vector (IV) is specified when encrypting, and also required to decrypt the message [10].

Asymmetric Key Cryptography, which is also known as public key cryptography, uses a separate public key for encrypting a plaintext and a private key for decrypting the ciphertext. Although different, the two keys are mathematically related, and the public key is derived from the private key [10]. RSA is a widely known and used public key encryption algorithm named after its authors Ron Rivers, Adi Shamir and Leonard Adleman [12]. Asymmetric key cryptography allows anyone with the public key to encrypt content that can only be decrypted by the holder of the associated private key. A second point of utility is that a key that is persistently held by only one person or computer can be used as a means of identity verification. One application layer protocol that provides this functionality is Secure Shell (SSH) [23]. In such an implementation, clients which can present a prior authorized public key will be permitted to communicate with the service. When used in this way, it is best to keep the key pair specific to the application on that computer, and not to give the public key to any party other than the server that will be encrypting content for the client with that particular key. Conversely, in an application that permits all content sent to a private key holder to be encrypted with the public key by any sender, the public key is often published on a web page or kept in a publicly available repository. This is the case with an e-mail protocol like OpenPGP [11].

Methodology and System Analysis

Project Objectives

The following improvements are to be made to TFTP/TFUP:

Existing Software

The starting point for the improved protocol implementation was the TFUP server and client program completed previously. These programs were written in ANSI C and used the Unix Sockets library for network interface operations. The architecture of the client and server programs used common libraries between the two programs. These libraries were produced as part of the project and can be described as follows:

The main programs were driven by a finite state machine specific to the client and server, and included the following states:

State diagrams: Server, Client.

Component Selection

A library to provide cryptographic functions was required, and the most ubiquitous of which is the OpenSSL library. The library is readily available for linking to C programs compiled on BSD, Linux, Macintosh and Windows computers. Since it is relied upon for securing large scale commercial and government activity, it typically makes available up to date and feature complete implementations of advanced crytptographic algorithms, the use of which is considered good practice. The criteria for selecting which algorithms within OpenSSL to use, was that the implementation must contain no current vulnerabilities that can be exploited without state of the art code breaking methods, and a considerable amount of time. Effectively, they are assumed to have low or no computational feasibility of breaking. In addition to being assumed to provide a high level of security, the algorithm must also be widely known and used. Since such implementations are made available by OpenSSL, it is the only cryptographic library used to complete the project.

No cryptographic algorithm can be known to be completely effective on an ongoing basis.
In this case, the following functions provided by OpenSSL have been used:

Objective: The server shall only perform file transfers with authorised clients

To limit the file transfer actions to being performed with only those clients that the server operator has authorised, RSA public key encryption was utilised in two ways:

Prior to any client connecting to the server, it must have the server's RSA public key, which is not given out by the server program and must be installed on the client. When the client connects to the server, before issuing any read or write requests, it will send the server its own public key, encrypted with the server's public key. It is for this reason that the server's public key is larger than the client's, so it can be used to encrypt the client key and transfer it in one packet.

Upon receiving the encrypted client key, the server will decrypt the message, and if succesful in doing so, will compare the client's public key to the keys stored in a file called "authorized_keys". If the client key is found in the file, the client is considered to be authorised, as the client's key should only have been added to that file by someone with administrative access to the server, and who has been given the public key from the client computer. There is, however, an issue with TFTP being a connectionless protocol, in that anyone can send requests at any time and the server will oblige. To prevent this, the client must maintain exclusive access to the server. This is achieved by the server generating a pseudo-random AES-256 session key, and an AES-256 CBC initialization vector, which the client must use to form a valid request from that point on, until the currently connected client sends a valid disconnection packet.

These conditions have required two new packet types to be added to the TFUP:

Encrypted Transaction Request (ETRQ) packets with the operation code of 8, consist of the two byte operation code followed by the client's public key encrypted with the server's public key. Upon receipt, the server will validate the client's identity and, if successful, generate an AES session key, and initialization vector. If unsuccessful, an error packet is sent.

Encrypted Transaction Acknowledgements (ETACK) packets with the operation code of 9, are sent when a client public key sucessfully validates, and the server program is not occupied by another client. These packets consist of the two byte operation code, followed by the 32 byte AES session key encrypted with the client's public key, followed by the 16 byte AES initialization vector, also encrypted with the client's public key. Upon receipt, the client will retain the session key and initialization vector (IV) in memory and use them for the remainder of its communication with the server until disconnection. This will be referred to as establishing an encryption session, which will only belong to one client.

A Hangup packet is sent by the client to indicate that its encryption session should be ended. The structure of the packet is an operation code of 10, followed by the client's public key encrypted with the server's public key. The implementation provided here requires one client's encryption session to be invalidated before another may establish one.

Objective: File contents and attributes shall only be transmitted in encrypted form

On an IP network, one machine cannot typically prevent another from transmitting a packet via one of its interfaces, it can only choose what is done with any packet received by its own interfaces, be it dropped or ignored or actioned. For this reason, the encryption requirement is enforced by the server and client only actioning packets that are encrypted using the right encryption inputs and are presented with the right hash to match the inputs.

Request (RRQ, WRQ and TSRQ) packets are now required to have the filename encrypted with the session key and IV, and have an SHA-256 hash of the IV and encrypted filename appended afterward.

Timestamp (TS) packets are now required to have the timestamp encrypted with the session key and IV.

Data packets are now required to have the included file content encrypted with the session key and IV.

Acknowledgement (ACK) packets for data transfers are unchanged from TFUP, and packet operation codes remain in plain text.

While one authorised client maintains an encryption session with the server, there is no existing functionality of TFUP that will prevent another client from sending a request to the server, in these cases the server would be unable to decrypt the request data, but would still attempt to read the file. A preventative measure to ensure only the client that established the session can have requests actioned by the server was needed. The method chosen was a hash of the initialization vector, salted by (prepended to) the file name being requested in the TSRQ, RRQ or WRQ. This resulted in a new format for TSRQ, RRQ and WRQ packets in that the file name portion should now be encrypted using the session key and IV, and followed by a hash of the IV salted with the file name. The server can then decrypt the file name in the packet upon receipt, and generate its own hash of the IV and decrypted file name, and compare it to that received from the client. If the hashes match, then the client must know the IV, and the unencrypted file name requested. The IV was only sent once to the client intended to be the owner of the session.

Significant Changes to the TFUP Programs

The client main program, fsynccli.c, has been altered to form and send an ETRQ packet to the server and action the reply by populating session related variables, or exit if an ETACK is not received, prior to accepting any command input from the user.

The server main program, fsyncsrv.c, has only received minor alterations to make the appropriate function calls for the new packet types, and to make available stored keys and initialization vectors.

file.c has the addition of functions used to read a key file to a string, and perform AES-256 CBC encryption and decryption of files to disk.

tfup.c has been renamed efup.c to reflect the protocol changes. Modifications have been made throughout the parse, form and receive functions to incorporate encryption and decryption of items added to and parsed from a packet buffer. The ETRQ and ATACK functions and associated logic have been incorporated in their own parse, form and receive functions. Functions for performing the SHA-256 hash generation and pseudo-random session key and IV generation have been added. The pseudo-random key selection is performed using the OpenSSL RAND_bytes function.

EFUP in Operation

The images that follow show a demonstration of the new functionality added to the TFUP programs.

The first scenario, shown in figures 3 through 5, shows the exclusion of other clients while one client has an active session. This test can be repeated by starting the server, invoking a client to connect to it, and then invoking a second client to connect. If the command exit is entered on the first client, the second client will then be able to connect. This demonstrates that a client's ability to establish communications with the server is being controlled.

The scenarios shown in figures 6 and 7 show a client successfully requesting the remote directory listing, as it has the same session key and IV that the server maintains as current. The second figure shows a failed timestamp request via the rupdate command because the client's session key and IV does not match the server's. This test can be repeated by starting the server, connecting a client, then terminating the server and restarting it on the same port before issuing the command on the client.

Figure 8 shows the difference between the plaintext of the Project Gutenberg edition of Herman Melville's Moby Dick, and the ciphertext form when transferred to the client.


Client: Server:

Client screenshot: Successful connection

Server screenshot: Successful connection

Figure 3: Successful connection and authentication


Client: Server:

First client
Client 1 screenshot: Successful connection
Second client
Client 2 screenshot: Unsuccessful connection

Server screenshot: One client successful, a second client fails to connect

Figure 4: A second client attempts to connect


Client: Server:

First client (Disconnects, then tries to reconnect)
Client 1 screenshot: Disconnects
Second client (Connects after the first disconnects)
Client 2 screenshot: Successful Connection

Server screenshot: The first client disconnects, the second is then successful

Figure 5: The First client disconnects, the second client is now successful


Client: Server:

Client screenshot: Retrieves the directory listing, has the correct key and IV

Server screenshot: A client successfully retrieves the directory listing

Figure 6: The client successfully requests the remote directory listing, as it has the current session key and IV.


Client: Server:

Client screenshot: Fails to update a file, the key and IV are incorrect

Server screenshot: A client attempts to update a file with the incorrect key and IV

Figure 7: A client fails to update a file, as it has the wrong session key and IV.


A file as plaintext

A file as transmitted in ciphertext

Figure 8: A file in plaintext and ciphertext as transmitted.


Practical Considerations and Future Direction

Although the security of the application has been improved, it has not been tested against the numerous attack types that may befall it. The project has addressed the authentication and confidentiality aspects of securing the application, it has not addressed reliability when receiving malicious input or weakness to attacks intending to deny service or trigger abnormal behaviour. Therefore, the program is not ready for uses other than experimentation in a controlled environment. Much of the reliability aspect relates to the architecture of the program in regards to how it services and sequesters concurrent connections. These are significant issues in the server program that require solving before the program could reach a production level of reliability. They may best be solved while incorporating a multiprogramming methodology such as multi-threading into the server.


The TFUP and associated programs have been modified to create a new protocol EFUP. The protocol utilizes cryptographic methods for authentication and to maintain confidentiality of transferred data at the application layer. Although the program is not feature complete, or ready for use in the wild, it may form the basis of improved works in the future. The project has achieved the aim of improved security, but the software does not provide practical security to the point it could be confidently used in a production setting. It has, however, provided inspiration for future work in which these issues may be addressed to develop more secure software for networked environments.


TFUP Client and Server Source Tarball MIT License Readme


[1] Richa Arya. Data Encryption Approach For Security. International Journal of Computer Sciences and Engineering, 2(5):176-179, 2014.
[2] Andrey Bogdanov, Dmitry Khovratovich, and Christian Rechberger. Biclique cryptanalysis of the full AES. In Advances in Cryptology-ASIACRYPT 2011,pages 344-371. Springer, 2011.
[3] Noel Chiappa. Homepage of J. Noel Chiappa,, 2014.
[4] Robert F Churchhouse. Codes and ciphers: Julius Caesar, the Enigma, and the Internet. Cambridge University Press, 2002.
[5] Jyotirmoy Das. A Study on Modern Cryptography and their Security Issues. Internation Journal of Emerging Technology and Advanced Engineering, 4(10):320-324, October 2014.
[6] T. Dierks and C. Allen. The TLS Protocol Version 1.0, RFC 2246. Technical report, 1999.
[7] Hans Dobbertin. Cryptanalysis of MD4. In Fast Software Encryption, pages 53-69. Springer, 1996.
[8] P. Ford-Hutchinson. Securing FTP with TLS, RFC 4217. Technical report, 2005.
[9] A. Harkin and G. Malkin. TFTP Option Extension, RFC 2347. Technical report, 1998.
[10] D. Gollmann. Computer Security. Wiley, 2011.
[11] H. Finney J. Callas, L. Donnerhacke and R. Thayer. OpenPGP Message Format, RFC 2440. Technical report, 1998.
[12] Mervat Mikhail, Yasmine Abouelsoud, and Galal El Kobrosy. A Survey of Cryptographic Protocols. The 3rd International Conference on Design Engineering and Science, ICDES 2014, 2014.
[13] NIST. Data Encryption Standard. In FIPS PUB 46, Federal Information Processing Standards Publication, pages 46-2, 1977.
[14] NIST. Specification for the Advanced Encryption Standard (AES). Federal Information Processing Standards Publication 197 (FIPS 197), 2001.
[15] James Northway. TFTP Synchronization Extensions (TFUP): Client and Server Programs in C with Unix Sockets. October 2013.
[16] J. Postel. User Datagram Protocol, RFC 768. Technical report, 1980.
[17] Bart Preneel. The First 30 years of cryptographic hash functions and the NIST SHA-3 competition. in Topics in Cryptology-CT-RSA 2010, pages 1-14. Springer, 2010.
[18] E. Rescorla. HTTP Over TLS, RFC 2818. Technical report, 2000.
[19] K. R. Sollins. The TFTP Protocol (revision 2), RFC 783. Technical report, 1981.
[20] K. R. Sollins. The TFTP Protocol (revision 2), RFC 1350. Technical report, 1992.
[21] W.R. Stevens, B. Fenner, and A.M. Rudoff. UNIX Network Programming, Volume 1 of Addison-Wesley Professional Computing Series. Addison-Wesley, 2004.
[22] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. Finding collisions in the full SHA-1. In Advances in Cryptology-CRYPTO 2005, pages 17-36. Springer, 2005.
[23] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Transport Layer Protocol, RFC 4253. Technical report, 2006.

Copyright (c) 2013, 2014, 2015 James Northway.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Last revised 22/07/2015.