XML signature HMAC truncation authentication bypass

[Peter Gutmann]

Leandro Meiners <lmeiners at gmail.com> quotes:

>"For example, by specifying an HMACOutputLength of 1, only one bit of the
>signature is verified. This can allow an attacker to forge an XML signature
>that will be accepted as valid."

This excessive generality is a serious problem in way too many crypto specs, 
and implementations of security protocols.  For example PKCS #11 allows you to 
leak keys out of cryptographic hardware by specifying the use of a 1-bit key 
derivation function, allowing you to guess an entire key one bit at a time 
(fortunately few, if any, implementations actually support this).  In the PKI 
world, virtually no spec requires sensible limits on anything (some years ago 
I brought a CA to a halt by specifying a huge salt and large iteration count 
for the challenge-response protocol they used to authenticate certificate 
issues.  Then I repeated it to make sure it wasn't just a coincidence the 
first time :-).  PGP Desktop 9 uses as its default an iteration count of four 
million (!!) for its password hashing, which looks like a DoS to anything that 
does sanity-checking of input.  Netscape (and obviously this test was done 
some years ago) will happily accept a certificate with a 1MB MPEG of a cat in 
the X.500 DN, but then become what could mildly be described as "unresponsive" 
once it's stored it in its cert.database.  The SSH oracle attack of a few 
months ago was helped by the fact that the length field wasn't constrained to 
sensible values.  This list goes on and on, it's scary just how vulnerable a 
lot of security software is to anything that can drop a slightly unexpected 
value into a data field.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com