Subject: Re: [keyassure] Cert format substitution attack

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 28 Sep 2010 15:44:06 -0500 (GMT-05:00)

Phillip and all,

Yep!  and these 'Types' of attacks with various varients of course, are not uncommon as

well as easily missed or not recognized until long after the potential damage, whatever it

may be, is done or has been widely propagated.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Sep 28, 2010 3:10 PM
To: Paul Hoffman
Cc: [email-masked]
Subject: Re: [keyassure] Cert format substitution attack

The attack has nothing to do with cert pre-images. It is independent of the strength of the algorithm and it is the reason that you certainly do not want to be signing raw keys.

The reason behind the design of the RSA signature bit packaging formats is precisely to prevent against this form of attack. Imagine that MD4 has been broken completely but SHA256 is secure.

If the RSA signature was calculated on  0x00 .. 0x00 <SHA256 of certdata>, the cert would look something like:

certdata =

Issuer

Subject

Digest Algorithm = SHA256

RSA (0x00 .. 0x00 <SHA256 of certdata>)

That approach FAILS because an attacker can generate:

Issuer

Subject

Digest Algorithm = MD4

RSA (0x00 .. 0x00 <MD4 of certdata>)

So instead the packaging format is

0x00 .. 0x00 OID(SHA256) <SHA256 of certdata>

That OID value in the bit string is essential to the security of the system.

Now imagine we are using raw keys without the algorithm ID

Digest  = SHA256 (ECDSA-512 keydata)

All that is necessary for the attacker to break the system is to find an ECDSA bit string that is sufficiently similar to an RSA512 bit-string and forms an easily factored composite modulus.

They can now break the system entirely by asking to establish a session and present the RSA512 bit key.

The cert attack is essentially the same except that we are going to use the fact that a cert package in one format might be misinterpreted as another.

Proper cryptographic hygiene requires that both the certificate type and the certificate data be properly validated.

On Tue, Sep 28, 2010 at 2:16 PM, Paul Hoffman <[email-masked]> wrote:

At 1:48 PM -0400 9/28/10, Richard L. Barnes wrote:
>It occurs to me that one advantage of just binding to keys (not certs) is that this sort of thing is not an issue.

Given that the "issue" assumes a successful first-preimage attack on the cert, it is not clear if it is really an issue at all. No WGs in the IETF consider hardening against first-preimage attacks other than by having algorithm agility, which is already proposed here. Put another way, if there is an attack on hash(cert), there is an equivalent attack on hash(key), but there is also an attack on TLS and PKIX and....

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
keyassure mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/keyassure

--
Website: http://hallambaker.com/

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail [email-masked]
Phone: 214-244-4827

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 29 Sep 2010 13:26:45 -0500 (GMT-05:00)

Phillip and all,

I agree, I also prefer 'Algorithm Identifier' to magic number.  Further IMO I also believe that the IANA

will be more amenable to ASN.1 OIDS than Cert RR types and it frankly as you put it makes

a heck of alot more sense anyway.

-----Original Message-----
From: Phillip Hallam-Baker
Sent: Sep 28, 2010 5:26 PM
To: Matt McCutchen
Cc: [email-masked]
Subject: Re: [keyassure] Cert format substitution attack

Agreed,

Though I prefer the term 'algorithm identifier' to magic number, since magic number implies that this is some sort of heuristic approach which it isn't.

We have a choice of the CERT RR types or the ASN.1 OIDS.

I much prefer using ASN.1 OIDS since they allow anyone to use any algorithm they choose without IANA having to allocate a code point. This in turn means that IANA does not need to allocate code points for every bit of vanity crypto people might propose and the IETF does not need to risk the implication that assigning a code point implies endorsement.

A secondary advantage is that we can punt on the issue of flags. If we need to encode more data we use a different OID.

On Tue, Sep 28, 2010 at 4:52 PM, Matt McCutchen <[email-masked]> wrote:

On Tue, 2010-09-28 at 09:42 -0400, Phillip Hallam-Baker wrote:
> One thought that occurred to me last night was that if we are going to allow
> multiple cert formats, we have to prevent an attack that works by confusing
> a cert in one format with another.
>
> While this may sound farfetched, it is less far so when you consider what a
> minimal RP implementation that is only looking for the EE key might do.
>
>
> So we should do one of the following
>
> 1) instead of calculating SHA256 (cert) we should have SHA256 (cert-type,
> cert).
>
> 2) instead of using SHA256(cert) we should use cert-type + SHA256(cert)

I.e., the intended certificate format should be part of the assurance.
Ideally, formats would be self-identifying via magic numbers for the
convenience of file(1) and sysadmins, but specifying the certificate
format appears to be future-proof at minimal cost.

--
Matt

Regards,
Jeffrey A. Williams