The original best-effort, packetized data delivery
Adding Encryption to the Truly Trivial File Transfer
Building on the Truly Trivial File Transfer Project, we add encryption, employing AES encryption and standard encryption modes and MAC.
NAME
ttftp-enc
SYNOPSIS
ttftp-enc [-vLF] [-h host -f filename] [-k key] port
DESCRIPTION
Implements a client and a server for the tftp protocol. If called without -h and -f
options, the programs implements the server listening on port port. If called with
both -h and -f options, the program uses the tftp protocol to read file filename
from host host connecting to the server listening on port port.
The client writes the received bytes to standard out.
The server implements basic security by requiring that filename is in the current
directory and is world readable. Else an error is returned.
On reading of files in mode OCTET is supported. All over requests generate
error responses.
OPTIONS
-f File to read.
-F client sends the fixed IV "123456789"
-h Host to contact for the file.
-k Key for encryption
-L If invoked as server, do not loop. Service one read request then exit.
-v Verbose. Helpful debugging output to stdout.
NOTES
Implement only octet and only read. If requested return an error packet with
message "mode not supported".
Data provider (in this case the server) to resend DATA on acknowledgement timeout.
Acknowledgement timeout, and maximum acknowledgement retries to be a define in the
code, and can be changed by recompiling with the -D compiler option.
Default acknowledgement timeout is 4 seconds, and 4 retries.
Maximum filename length is 256 characters, and cannot contain a pathname.
Server can be single-threaded.
If the -k option is supplied in client mode, request an encrypted transfer using
the provided key; else request an unencrypted transfer.
If the -k option is supplied in server mode, provide an encrypted transfer if
requested; else reject an encrypted transfer if requested. Always support unencrypted
transfer, if requested.
HISTORY
First introduced in Fall 2003. Made Truly Trivial in Spring 2015.
LAST UPDATED
March 25, 2016
Detailed description
Starting from the Truly Trivial File Transfer Protocol, we will add encryption to the data blocks in provide confidentiality and integrity. We will use the following standards in our implementation:
It is important to use an Initial Vector (IV) when encrypting, to diversify the pseudorandom encryption bytes, so as to never use the same stream of bytes. The IV will be sent by the client to the server in the RRQ packet. The RRQ packet format description is hereby amended to include the additional format:
2 bytes string 1 byte string 1 byte string 1 byte
--------------------------------------------------------------------
| Opcode | Filename | 0 | Mode | 0 | IV | 0 |
--------------------------------------------------------------------
Mode will be set to "AES128", and the IV string is 9 ASCII bytes. It SHOULD be the
least significant 9 digits of time() (see man 3 time) when converted to decimal.
The data bytes of the file are collected into 128 bit subblocks, and padded to the next even multiple of 512 bytes. The encryption uses the IV, the port numbers for the session, block numbers, and sub-block identifiers, to derive a 128 bit pseudorandom block which is exclusive or'ed with the data sub-block. To decode, this block is recalculated by the data receiver and is exclusive or'ed again to retrieve the plaintext. The calculation for the counter mode AES is:
2 bytes 1 byte 2 bytes 2 bytes 9 byte string
----------------------------------------------------------
| Block | sBlk | Client Port | Server Port | IV |
----------------------------------------------------------
||
||
VV
-------
K-->| AES |
-------
||
||
VV
P_i ------> ( XOR ) -------> C_i
The block and port numbers are in network byte order. The P_i and C_i are subblocks.
The Block starts at 1, and is equal to the block as used in tftp. The
sBlk goes from 0 to 31 for each block, and is the 16 byte subblock within the 512
byte block.
Data blocks and padding
Only the data in the TTFTP DATA packets are encrypted and MAC'ed. The first four bytes of the TTFTP DATA packets are not encrypted (i.e. the operation code and the block number). The request, error and acknowledge packets have no encryption.
File will be padded to a 512 byte multiple, and will be sent encrypted in 516 byte data packets (512 byte data, plus 4 bytes operation code and block number). The final data packet will be 20 bytes, the 16 byte MAC plus the 4 bytes operation code and block number.
If the file is not a multiple of 512 bytes, the last block is padded up to a full 512 byte block as follows:
The blocks are then divided into 16 byte subblocks and each subblock is encrypted in counter mode (as show above).
Example:
Padding:
-------------------------------------------
... byte | byte | 0xff | 0x00 | ... | 0x00 |
-------------------------------------------
AES CMAC
The Message Authentication Code (MAC) is calculated over the sequence of encrypted blocks, and the 16 byte result is appended as the last block sent by the server. (I.e. Encrypt-then-MAC.)
The MAC is described in RFC 4493. The RFC provides for padding in the case that the message length is not a multiple of the block size of AES. This padding procedure will not be needed, as the data has already been padded to a multiple of 16 bytes.
The first 16 byte subblock is encrypted using AES with the MAC Key K; the output of this encryption, and each subsequent encryption, is exclusive or'ed with the next subblock and the result encrypted using AES with the key K. The last block is exceptionally exclusive ordered with the derived key K1 before the final encryption.
P_2 --------+ P_3 --------+
| |
+-------+ V +-------+ V
P_1 ---> | AES_K | ---> ( XOR ) ---> | AES_K | ---> ( XOR ) ---> ...
+-------+ +-------+
P_n -------+ +---------- K1
| |
+-------+ V V +-------+
... ---> | AES_K | ---> ( XOR ) ---> | AES_K | ---> MAC
+-------+ +-------+
The AES Key
There are three keys needed:
The Master Key is given by the input option -k. If the key is less than 16 character, pad with the null characters to the right (i.e. higher indexed bytes when viewed as an array of bytes). If the input is longer than 16 bytes, truncate to 16 bytes.
If the client sends a standard RRQ, then the server will send the file unencrypted regardless of whether or not the server was invoked with the -k option.
Error messages
To RFC 1350 we add the following error codes:
| Error codes | |
|---|---|
| value | meaning |
| 8 | encryption requested, server has no key |
| 9 | data does not agree with received MAC |
The client checks the MAC and sends the proper error message and returns with return code 1 if the MAC is wrong. Else it sends the ACK as normal and returns value 0.
Checking the MAC
The client will recalculate the MAC over the encrypted data and compare the result to the MAC sent by the server. The protocol terminate normally and quietly of the MAC's are equal.
If unequal, the client sends an error message to the server instead of the final ACK packet. The client will exit with return code 1. The client will, however, decrypt and write to standard out any and all remaining bytes it has received.
Protocol Trace
This is a trace of the sending of a zero-length file (filename "empty") using the IV "123456789" (that is, 0x31 0x032 .. etc). The client port is 57023 (0xdebf); the server port is 61409 (0xefe1), These are the values used in the counter mode.
Sniffer$ sudo tcpdump -i lo0 -X port 33031 or portrange 50000-65535
Server$ ./ttftp-enc -Lv -k HeLlO 33031
Client$ ./ttftp-enc -F -h localhost -f empty -k HeLlO 33031
18:46:56.368597 IP localhost.57023 > localhost.33031: UDP, length 24
0x0000: 4500 0034 d2bc 0000 4011 0000 7f00 0001 E..4....@.......
0x0010: 7f00 0001 debf 8107 0020 fe33 0001 656d ...........3..em
0x0020: 7074 7900 6f63 7465 7400 3132 3334 3536 pty.octet.123456
0x0030: 3738 3900 789.
18:46:56.369147 IP localhost.61409 > localhost.57023: UDP, length 516
0x0000: 4500 0220 0ff5 0000 4011 0000 7f00 0001 E.......@.......
0x0010: 7f00 0001 efe1 debf 020c 0020 0003 0001 ................
0x0020: 27ae c4a0 6561 da34 397c c414 4b66 ff84 '...ea.49|..Kf..
0x0030: 902f b0d7 6c15 46ef 17ec 40bf a703 645e ./..l.F...@...d^
0x0040: d419 17de 3382 f35b 5d48 8e5c 1aaf 5c09 ....3..[]H.\..\.
0x0050: 3745 16f7 5228 80ba 6bdb cd4c 65b3 5666 7E..R(..k..Le.Vf
0x0060: 9615 ac8e 351b 40b8 1e12 c849 a64a 9f2a ....5.@....I.J.*
0x0070: a4e7 909b f3ed ab3d 02e3 0f79 68ce 2dd5 .......=...yh.-.
0x0080: ed51 fbcf a9c5 9d64 92f4 26ad 9fe3 1436 .Q.....d..&....6
0x0090: 75f9 3624 2a67 391f 46d6 5c27 9488 67b9 u.6$*g9.F.\'..g.
0x00a0: 5eff 4d8b 6620 da1f eda6 e0cf cb1b 8990 ^.M.f...........
0x00b0: 93c4 6ed6 b1ad a7ed 7205 0305 2e41 cea5 ..n.....r....A..
0x00c0: da14 7f36 cb99 50db c87e 4cbc 15b6 1dcd ...6..P..~L.....
0x00d0: d0aa 3360 fab4 cc66 bb92 ea6b 9596 d439 ..3`...f...k...9
0x00e0: 6ab0 c40f 6932 57c3 ef4c 328e 5400 b8b5 j...i2W..L2.T...
0x00f0: 53d9 ab7d b17a f562 0b10 d5e5 abd4 f1d3 S..}.z.b........
0x0100: 3b22 5f0b 8f92 92a2 be75 11ac 55a1 0050 ;"_......u..U..P
0x0110: f7f2 a437 2d8a 24b3 279c cd9e 9ef7 2602 ...7-.$.'.....&.
0x0120: 93ae f826 1b19 a0b2 f764 8dc9 14e7 49fa ...&.....d....I.
0x0130: b3da 3135 5964 99e5 012f 0997 95f4 ac4b ..15Yd.../.....K
0x0140: 55ea e48f 8c0d c6e6 77f6 8322 9145 703a U.......w..".Ep:
0x0150: c167 1a06 081f bc1d 7376 f294 ab40 2770 .g......sv...@'p
0x0160: b7b8 d2a7 4e73 3835 d4d0 f8d1 bb25 1e8c ....Ns85.....%..
0x0170: 315e 2e43 e06f 9393 d582 ecd9 078b 800d 1^.C.o..........
0x0180: 9818 6945 cabe ce92 4e86 5af9 4e44 c113 ..iE....N.Z.ND..
0x0190: 3cef 3b18 5bab 43f3 4789 b422 c446 2b5a <.;.[.C.G..".F+Z
0x01a0: a45c 167d f662 55c4 52ec 3049 8314 234c .\.}.bU.R.0I..#L
0x01b0: 4155 ea2e 7268 5e0b 7baf 5632 9c19 be28 AU..rh^.{.V2...(
0x01c0: 9694 f36e efff cfbb b824 0d17 21b3 3563 ...n.....$..!.5c
0x01d0: e957 8d96 aa7b 4660 d5b5 0ef3 5304 58fb .W...{F`....S.X.
0x01e0: de2a 78a5 f8c5 cd50 4d00 2261 e774 3790 .*x....PM."a.t7.
0x01f0: a75d bc21 9660 ed34 3f93 abb3 3936 0527 .].!.`.4?...96.'
0x0200: a818 60ad 894b 68d1 42a2 a69c ffe3 9b76 ..`..Kh.B......v
0x0210: c475 382a 2560 2369 e63b 44f7 cd2b f463 .u8*%`#i.;D..+.c
18:46:56.369513 IP localhost.57023 > localhost.61409: UDP, length 4
0x0000: 4500 0020 d4d5 0000 4011 0000 7f00 0001 E.......@.......
0x0010: 7f00 0001 debf efe1 000c fe1f 0004 0001 ................
18:46:56.369549 IP localhost.61409 > localhost.57023: UDP, length 20
0x0000: 4500 0030 f95e 0000 4011 0000 7f00 0001 E..0.^..@.......
0x0010: 7f00 0001 efe1 debf 001c fe2f 0003 0002 .........../....
0x0020: 64e2 f394 8dc9 bce3 4bd3 643a 27dd e131 d.......K.d:'..1
18:46:56.369577 IP localhost.57023 > localhost.61409: UDP, length 4
0x0000: 4500 0020 de4a 0000 4011 0000 7f00 0001 E....J..@.......
0x0010: 7f00 0001 debf efe1 000c fe1f 0004 0002 ................
Author: Burton Rosenberg
Created: January 18, 2014 as mytftp
Last Update: March 24, 2016