[e2e] Paper on ATP; end to end security provided by ATP: where SHA1-80 is enough

[Jason Gao]

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.