Correction: Re: Serious crypto problem fixed by envelope HMAC method insteadof currently used prefix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
This would have been a problem if the HMAC was just SHA-1(...) or MD5 (...)
or similar type of prefix HMAC. However, the HMAC used in TLS is more
involved construct (see RFC 2104) and the attack is not applicable.
----- Original Message ----- 
From: "Omirjan Batyrbaev" <batyr@xxxxxxxxxxxxxxxxxx>
To: <bugtraq@xxxxxxxxxxxxxxxxx>
Cc: <dm@xxxxxxxxxxxxxxxxx>
Sent: Sunday, November 19, 2006 9:44 PM
Subject: Serious crypto problem fixed by envelope HMAC method insteadof
currently used prefix


> Hi,
>
> I propose to use envelope method instead of currently used prefix method
in
> HMAC used in TLS/SSL. 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 easily broken 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
> originals. 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.
>
> I quote TLS 1.2:
> "The MAC is generated as:
>
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
> TLSCompressed.fragment));
>
>    where "+" denotes concatenation."
>
> This is subject to the above mentioned attack.
>
> Instead I propose the HMAC construct which is not prone to the above
stated
> exploit:
>
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
> TLSCompressed.fragment + MAC_write_secret));
>
> addition of the MAC_write_secret as the last bits of the input to the HMAC
> makes it envelope method which is secure against the above stated exploit.
>
> Versions affected Products that implemented TLS 1.2; 1.1; 1.0 and SSL v3,
> v2, v1.
>
> PS: it makes no difference if the plaintext compressed or not I just
quoted
> from the draft/specs.
>
>
> Thanks.
> Regards,
> Omirjan Batyrbaev, CTO B3 Security Corp.
> batyr@xxxxxxxxxxxxxxxxxx
>


[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux