Re: Packet Number Encryption outside of AEAD

[Kazuho Oku <[e-mail]>]

2018-07-27 22:43 GMT+09:00 Christian Huitema <[e-mail]>:
>
>
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>>
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.

I do not see how the issue relates to the endianness.

Consider the following case.

encrypted PN + payload: 46 5f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
0d 0e 0f 10 11
AES-CTR mask for PN: c5 5c

The PN field after decryption is 83 03. IV used for PNE is 02 03 .. 11.

Attacker applies XOR 0x80 (to change the PN field length from 2 to 1)
and removes the second octet.

The modified encrypted PN + payload becomes: c6 00 01 02 03 04 05 06
07 08 09 0a 0b 0c 0d 0e 0f 10 11.

The PN field after decryption is 03, and IV used for PNE is 02 03 .. 11.

In such case, the receiver will successfully process the modified
input if the PN was expressible using one octet, thereby leaking the
fact that the first 6 bits of the 16-bit PN was equal to the least
significant 6 bits of the PN and that the 7th and 8th bits were zero.

Admittedly, this attack relies on the fact that the frames contained
in the packet are 2 octets. But I am not sure if this is the _only_
attack that is possible.

Am I missing something?


Besides, note also that the proposed change will prevent us from using
the PNE key to encrypt other information. For example, in #1322, we
have been discussing about how to protect the key-phase bit. It seemed
to me that we were leaning towards encrypting the key-phase bit using
the PNE key. That would no longer be possible (or lead to other
security concerns) if we adopt this proposal.

>
> -- Christian Huitema



-- 
Kazuho Oku