[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix
Hi Eric,
I've seen the TLS reference to the "Request for Comments: 2104" so this is
(probably) the HMAC used in TLS. Quoting to be on the same page:
"To compute HMAC over the data `text' we perform
H(K XOR opad, H(K XOR ipad, text))"
However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?).
Do you know which HMAC they used in say SSL v3 and v2 (which is still an
option in my browser, etc.)?
-Best,
Omirjan
----- Original Message -----
From: "Eric Rescorla" <ekr@xxxxxxxxxxxxxxxxxxxx>
To: "Omirjan Batyrbaev" <batyr@xxxxxxxxxxxx>
Cc: <TLS@xxxxxxxxxxxxxx>
Sent: Monday, November 20, 2006 10:23 AM
Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method
instead of currently used prefix
> "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