Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix

[Eric Rescorla <ekr@xxxxxxxxxxxxxxxxxxxx>]

"Omirjan Batyrbaev" <batyr@xxxxxxxxxxxx> writes:

> Hi, please see inserted:
> ----- Original Message ----- 
> From: "EKR" <ekr@xxxxxxxxxxxxxxxxxxxx>
> To: "Omirjan Batyrbaev" <batyr@xxxxxxxxxxxx>
> Cc: <TLS@xxxxxxxxxxxxxx>
> Sent: Sunday, November 19, 2006 10:45 PM
> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method
> instead of currently used prefix
>
>
>> "Omirjan Batyrbaev" <batyr@xxxxxxxxxxxx> writes:
>>
>> > Hi,
>> >
>> > I propose to use envelope method instead of currently used prefix method
> in
>> > HMAC. The measure is important especially since it was pointed out that
> the
>> > NULL cipher suites have a real use and since some ciphers are
> intentionally
>> > weak. With the NULL cipher (or the 40 bits cipher) the current HMAC
>> > construct is exploitable by an active attacker who appends to the
> message
>> > and substitutes the new message and the newly generated HMAC value for
> the
>> > original. On the server side the HMAC operation will succeed. Of course
> it
>> > can be the server message that gets compromised this way. This attack is
>> > well known in the crypto community and is well documented in HAC
> (Handbook
>> > of Applied Cryptography). The book is available online and I can send
> you a
>> > page reference if you are not familiar with the attack on the HMAC
> prefix
>> > method.
>>
>>
>> Even if there were an appending attack on HMAC, because the length
>> value is included in the MAC, I don't believe you can apply the
>> attack in the context of TLS.
>
> I agree that the inclusion of the length value has merit. But only if the
> peer checks the length value.

I'm not sure what you mean by "check" in this context. The length 
value is explicit in the record and is used to find the record
boundary (recall that TCP has no explicit record boundaries). 
The length field from the record is then used to compute the
MAC.

Let's take the case you suggest where we have record R, consisting of

  {
    ContentType = 23 (application_data)
    Version = {3, 1}
    length = 8 (for example)
    data = "testdata"
    MAC = "XXX"
  } 

The MAC here is computed as: 

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 8 + "testdata")


The attacker modifies the application data to be 
"testdataMOREDATA" and mounts the extension attack on the MAC

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 8 + "testdataMOREDATA")

[I'm ignoring the fact that in order to mount extension attacks
you need to include the hash padding as part of the extension]

Note that because this is an extension attack he can't modify
data already hashed so length MUST be 8. He then formats
this into a record.

  {
    ContentType = 23 (application_data)
    Version = {3, 1}
    length = ???
    data = "testdataMOREDATA"
    MAC = "YYY"
  } 
    
Now, the question is: what length value does he use. If he uses
8, then the receiver will interpret "MOREDATA" as part of the MAC
and the MAC won't match. On the other hand, if he uses 16, then
the receiver will compute:

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 16 + "testdataMOREDATA")
                              ^^
                        New length value   

This produces the wrong MAC and thus a MAC error.

There's no need to explicitly check the length field: you just copy
it from the header into the MAC input. 

Theoretically, this could be an issue with a datagram protocol such as
DTLS [again, assuming HMAC was in fact broken, which I'm not convinced
is true], but since more than one DTLS record can be packed into a
transport-layer datagram, you use the length field to decode the
records there as well, so I don't see that there's a problem.


> With the proposed envelope method even if the peer does not check the length
> value the MAC can not be forged.
> Isn't it better to use a more robust envelope method instead? It is a small
> change to the spec and implementations.

Again, I believe that the claim that HMAC is susceptible to this
attack is incorrect. I understand how to mount appending attacks
on simple prefix-type keyed hashes but I don't see how this applies
to HMAC. Please describe in detail how you believe you would
mount this attack with HMAC.

-Ekr


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls