The draft onAsymmetric Transport Protocol: http://219.232.1.66/attached/info/atp-2004.pdf It has a security feature: encyrpted transport mode which combines AES and SHA1. It is suggested that the mode is optional when ATP is over UDP while mandatory when over IPv6. The algorithm (rewritten and clarified recently, renamed to AES-SHA1-CV) is that: Problem Space: To ensure successive packets came from the same source (identity of the source), and in the same time To protect confidentiality of the payload. (It is not in the same problem space as AES-CCM or AES-OCB.) It is assumed that a shared secret which is at least 283 bit has been established (using Elliptic Curve Diffie-Hellman key-agreement process, elliptic group sect283k1). In encrypted transport mode, if there is non-null payload no extension header may sit between the ATP fixed header and the payload. The structure of the ATP packet is: 0 1 2 3 |0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1| |---------------------------------------------------------------| | OpCode | Data Segment Length | |---------------------------------------------------------------| | Sequence Number |0 |---------------------------------------------------------------| | Connection | | Key |1 |---------------------------------------------------------------| | Next Expected Sequence Number | |---------------------------------------------------------------| | Stack Pointer | Flags | Identity |2 |-------------------------------- /Integrity | | Check | | Code |3 |---------------------------------------------------------------| ~ ~ ~ Payload ~ ~ ~ |---------------------------------------------------------------| ATP fixed header is 192 bit. When it is over UDP, the full ATP fixed header is stored next to UDP header. When it is over native IPv6, apparently ATP fixed header is 128 bit, Sender's behavior ----------------- Encryption, Composition of ICC: Step 1, Get the high-order 16 bits of ICC and the comparison vector (CV): IV80 = SHA1-80(Fixed Header Excluding ICC, Shared Secret) Namely, replace ICC field with the Shared Secret and apply SHA1-80. The high-order 16 bits of IV80 SHALL be stored in the high-order 16 bits of ICC field, while the low-order 64 bits are taken as the CV. Note that ; here ',' denotes concatenation. Step 2, Padding The length of the cipher text, which is determined by the length of the original clear text according to the padding method hereafter states, is stored in the data segment length field. It equals the length of the padded clear text minus 8. The original clear text is firstly padded with a sequence of octets of zero or more length. The length of the octet sequence is 15, if the original clear text has already been 128-bit aligned, or the number of octets it required to make the clear text 128-bit aligned minus 1. The length, which is represents by a single octets, of the octet sequence is padded as the last octet. (The idea is borrowed from ESP, slightly modified) Then the clear text is padded with the initial 64 bits, which include the OpCode, the data segment length and the sequence number, of the ATP packet, and lastly the 64-bit CV . Step 3, AES-CBC encryption The last 128-bit block of the padded clear text is taken as the initialization vector (IV). The IV and the full padded clear text are fed into the AES-CBC encryption module. The key fed SHOULD be installed by the ULA. On the default the key is derived from the shared secret. The key derived function MUST conform to ANSI-X9.63-KDF [KDF]. The first 64 bits are stored in the low-order 64 bit position of the ICC field. Following bits are stored in the payload field of the ATP packet. Receiver's behavior ------------------- Decryption, Verification of ICC Step 1, Rebuild IV and Preliminary check Again, IV80 = SHA1-80(Fixed Header Excluding ICC, Shared Secret) The high-order 16 bits are compared with the high-order 16 bits of the ICC field of the ATP packet received to preliminarily check whether the packet came from the same source. The initial 64 bits of the ATP packet received and the low-order 64 bits of IV80 form the IV'. Step 2, AES-CBC decryption The cipher text, taken from the lower-64 bit position of the ICC field and the payload field, together with the IV and the AES key are fed into the AES-CBC decryption module. Step 3, Verifying IV The last block of the decryption result is compared with IV'. If they are equal, the packet SHALL be accepted. Or else it MUST be silently discarded. Finally, padding is removed and the clear text payload is delivered to the ULA. ---- It is straightforward to modify the algorithm to use SHA1-144 to obtain the high-order 16 bits of ICC and the 128-bit initialization vector. We choose SHA1-80 because the secure hash algorithm applied used to be MD5, and we believe that entropy space of 64 bit for the initial word of the IV is enough. The algorithm is actually a combination of AES-CBC and partial HMAC. Partial HMAC protects the packet header which is very short (effectively at most 112 bits take part in the partial HMAC). AES-CBC provides both encrytion and message authentication service for the payload. The problem space for the attacker is: Provided that low-order 64-bit of the MAC value is known (the high-order 64 bits of the MAC value is encrypted and unknown by the attacker, and it is easy to modify the algorithm to make the whole MAC value confidential), and the IV is the clear text of the last block, find a sequence of octets which makes the same AES-CBC-MAC value, and the high-order 64 bits of the MAC value must equal the unkown partial HMAC result of the fixed header while the low-order 64 bits equal the initial 64 bits of the ATP fixed header. Four fields of the fixed header may be modifed, to a limited extent: the data segment length, the sequence number, the next expected sequence number and the flag. We believe that the problem is so hard that SHA1-80 is enough here. ------------------- Acknowledgement Thanks to Stephen Sprunk. He made us aware that the original name of the algorithm, AES-IV-SHA1-80 is misleading and the algorithm itself is obscure. We hope that it is corrected and clarified. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf