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.
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 rRRQ 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, with padding for the last subblock if necessary (see below). 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,
where i is 32 times the block number minus one, plus the sub block identifier
(sBlk in the diagram):
i = 32 (block-1) + sBlk.The sBlk counting starts from 1, so that the first plaintext block is P_1.
Data blocks and padding
The data bytes of the file are collected into 128 bit sub-blocks (16 bytes). Each 32 sub-blocks are collected into a 512 byte block to be sent in a single TFTP message. If the final data sub block is less than 16 bytes, it is padded as follows:
Each of these 16 byte blocks, including the MAC block, are encrypted as described above.
Example: If file has 659 data bytes, block 1 will be full with sBlks 0 through 31; block 2 will have 9 full sub blocks a partial block of 3 bytes. That partial block will be made a full block by appending first a 0xff byte then 12 bytes of 0x00. The 128 bit MAC will be placed in the 10th subblock of block 2. Each of the 26 sub blocks will be encrypted using counter mode AES.
Padding:
-------------------------------------------
... byte | byte | 0xff | 0x00 | ... | 0x00 |
-------------------------------------------
No padding:
-------------------------------------------
... byte | byte | byte | byte | ... | byte |
-------------------------------------------
AES CMAC
The Message Authentication Code (MAC) is calculated almost as described in RFC 4493, for the case of data lengths a multiple of 128 bits (which are data is, after the padding is done as above).
The first 16 byte subblock is encrypted with AES and the key K; the output of this encryption, and each subsequent encryption, is exclusive or'ed with the next subblock. The result is encrypted with AES an the key K. The last pass block is treated differently that as described. Add a round that uses the key K as the plain text:
P_2 --------+ P_3 --------+ P_n --------+ K' --------+
| | | |
+-------+ V +-------+ V V +-------+ V +-------+
P_1 ---> | AES_K | ---> ( XOR ) ---> | AES_K | ---> ( XOR ) ---> ... ---> ( XOR ) ---> | AES_K | ---> ( XOR ) ---> | AES_K | ---> MAC
+-------+ +-------+ +-------+ +-------+
This 128 bit resultant MAC is then modified:
Added 2 April, after an attack was noticed on April Fools. K' is either K or K XOR const_Rb as described in RFC 4493, page 5, depending on whether the last block is unpadded or padded, respectively.
The AES Key
The Key is used:
The key is given by the input option -k, i.e. -k HeLlO. If the key is less than 16 character, pad with the null character (numerical value zero), and if longer, truncate. The key must be a command line option, for the purpose of testing.
If the server does not have the -k option, it will reject with an error message a transfer that offers an IV string. If the server has the -k option but gets a RRQ without the IV string it will send the data without encryption.
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 |
Implementation Notes
Note that the server does encryption and MAC creation; the client does decryption and MAC verification. Note that the client sends all information in the clear. The server sends the data portion of the DATA packets encrypted, but the rest (the opcodes, block numbers, and error packets) are sent in the clear. The MAC is encrypted when sent, as an additional 16 byte block. The MAC serves both the authenticate the message and, by the value of the most significant bit, to indicate whether the previous block, which was a data block, was padded or not.
If the message does not MAC properly, return an error message to the server, and write BADMAC to standard error. But do complete the decryption of the message.
Protocol Trace
Server$ ./ttftp -vdl -k HeLlO 4434 Client$ ./ttftp localhost 4434 myfile.txt Sniffer$ sudo tcpdump -i lo0 -X port 4434 or portrange 50000-65535 22:43:34.415269 IP localhost.64881 > localhost.4434: UDP, length 19 0x0000: 4500 002f 9eb1 0000 4011 0000 7f00 0001 E../....@....... 0x0010: 7f00 0001 fd71 1152 001b fe2e 0001 6d79 .....q.R......my 0x0020: 6669 6c65 2e74 7874 006f 6374 6574 00 file.txt.octet. 22:43:34.415368 IP localhost.60537 > localhost.64881: UDP, length 278 0x0000: 4500 0132 c984 0000 4011 0000 7f00 0001 E..2....@....... 0x0010: 7f00 0001 ec79 fd71 011e ff31 0003 0001 .....y.q...1.... 0x0020: 616e 796f 6e65 206c 6976 6564 2069 6e20 anyone.lived.in. 0x0030: 6120 7072 6574 7479 2068 6f77 2074 6f77 a.pretty.how.tow 0x0040: 6e0a 2877 6974 6820 7570 2073 6f20 666c n.(with.up.so.fl 0x0050: 6f61 7469 6e67 206d 616e 7920 6265 6c6c oating.many.bell 0x0060: 7320 646f 776e 290a 7370 7269 6e67 2073 s.down).spring.s 0x0070: 756d 6d65 7220 6175 7475 6d6e 2077 696e ummer.autumn.win 0x0080: 7465 720a 6865 2073 616e 6720 6869 7320 ter.he.sang.his. 0x0090: 6469 646e e280 9974 2068 6520 6461 6e63 didn...t.he.danc 0x00a0: 6564 2068 6973 2064 6964 2e0a 0a57 6f6d ed.his.did...Wom 0x00b0: 656e 2061 6e64 206d 656e 2862 6f74 6820 en.and.men(both. 0x00c0: 6c69 7474 6c65 2061 6e64 2073 6d61 6c6c little.and.small 0x00d0: 290a 6361 7265 6420 666f 7220 616e 796f ).cared.for.anyo 0x00e0: 6e65 206e 6f74 2061 7420 616c 6c0a 7468 ne.not.at.all.th 0x00f0: 6579 2073 6f77 6564 2074 6865 6972 2069 ey.sowed.their.i 0x0100: 736e e280 9974 2074 6865 7920 7265 6170 sn...t.they.reap 0x0110: 6564 2074 6865 6972 2073 616d 650a 7375 ed.their.same.su 0x0120: 6e20 6d6f 6f6e 2073 7461 7273 2072 6169 n.moon.stars.rai 0x0130: 6e0a n. 22:43:34.415429 IP localhost.64881 > localhost.60537: UDP, length 4 0x0000: 4500 0020 9609 0000 4011 0000 7f00 0001 E.......@....... 0x0010: 7f00 0001 fd71 ec79 000c fe1f 0004 0001 .....q.y........ Client$ ./ttftp -k HeLlO localhost 4434 myfile.txt 22:43:34.421008 IP localhost.62009 > localhost.4434: UDP, length 30 0x0000: 4500 003a b7c1 0000 4011 0000 7f00 0001 E..:....@....... 0x0010: 7f00 0001 f239 1152 0026 fe39 0001 6d79 .....9.R.&.9..my 0x0020: 6669 6c65 2e74 7874 0041 4553 3132 3800 file.txt.AES128. 0x0030: 3432 3737 3639 3831 3400 427769814. 22:43:34.421151 IP localhost.59907 > localhost.62009: UDP, length 308 0x0000: 4500 0150 9fb5 0000 4011 0000 7f00 0001 E..P....@....... 0x0010: 7f00 0001 ea03 f239 013c ff4f 0003 0001 .......9.<.O.... 0x0020: 853d a48c 374a 8105 9315 7784 bdfa ff89 .=..7J....w..... 0x0030: c3f0 faee 4c8d 2bae 4e64 a416 9f7f 7743 ....L.+.Nd....wC 0x0040: a8f3 6e13 fcea 5248 86a5 e10b 3a0d 870f ..n...RH....:... 0x0050: bdaa 7a2b a255 7965 6d42 fe20 acc3 8886 ..z+.UyemB...... 0x0060: f941 ff38 f04e e171 9cfa d750 640b 44aa .A.8.N.q...Pd.D. 0x0070: 036b 0ee6 973f a140 e7be 6705 4a44 be9b .k...?.@..g.JD.. 0x0080: 0e7e dbad 8ecd a799 f9d9 6ea9 22a8 50eb .~........n.".P. 0x0090: b1fe 9329 6920 d1d6 e9bf 79e9 64b8 36d4 ...)i.....y.d.6. 0x00a0: 47db 62c9 60bc a298 63ec c8ab 6cbb 2bdd G.b.`...c...l.+. 0x00b0: 1a3b be80 6547 11fc 69ed b634 5902 b48d .;..eG..i..4Y... 0x00c0: f1f2 cffa 10bc 0b4d b212 2a09 0594 063c .......M..*....< 0x00d0: 53ae 1307 e5c0 3a3c a28a 87d7 4d99 6ca0 S.....:<....M.l. 0x00e0: f97a d522 edf2 260c 46da 8d90 7a7a 0dbe .z."..&.F...zz.. 0x00f0: 54b1 4431 f787 7690 fb3f 0eab 34c8 8254 T.D1..v..?..4..T 0x0100: 63e9 d07f 4c17 047c 2513 1b07 53aa daaf c...L..|%...S... 0x0110: d686 02fb 6369 075c 033e 0744 6df0 c2ea ....ci.\.>.Dm... 0x0120: 9bc6 595e 01d5 9df1 99e0 5218 08a3 6774 ..Y^......R...gt 0x0130: 8958 2140 07a1 ab35 8627 659b 856f fd6b .X!@...5.'e..o.k 0x0140: 8497 6025 27b4 c85b e5fd 80b8 b7b9 b7a1 ..`%'..[........ 22:43:34.421265 IP localhost.62009 > localhost.59907: UDP, length 4 0x0000: 4500 0020 2a5a 0000 4011 0000 7f00 0001 E...*Z..@....... 0x0010: 7f00 0001 f239 ea03 000c fe1f 0004 0001 .....9..........
Author: Burton Rosenberg
Created: January 18, 2014 as mytftp
Last Update: February 18, 2015 as ttftp