[cryptography] Certificate pinning: full certificate vs SubjectPublicKeyInfo

Ondrej Mikle ondrej.mikle at nic.cz
Fri Dec 16 12:05:05 EST 2011


what are the known attacks when pin is created to a CA certificate by 
SubjectPublicKeyInfo (SPKI) compared to pinning by full certificate (or 
hash of full certificate)?

Some I could think of:

1. Extending certificate chain

Let's have server-cert SC1 that directly chains to CA-cert I1 from 
authority CA1, pin is made by SPKI to I1.

If there exists cross-certificate R1 such that:
- R1 is issued by CA1 to authority CA2
- R1 directly chains up to certificate O1 (from CA1)
- O1 and I1 have identical SPKI

then original chain
can be extended to

where SC2 is server-cert issued by CA2 (fraudulently perhaps) and pin 
would be valid (the scenario is a bit simplified since CAs usually don't 
issue end-entity certs directly under their root).

I'm not sure how viable the above scenario is - I presume CAs won't 
share same key for signing cross-certs and server-certs. (Though 
occasionally CA certs with identical key and different subject pop up; 
perhaps offices/RAs at different geographical locations.)

2. Swapping certs with different X.509v3 extensions

Let's say attacker swaps CA-cert I1 for different CA-cert I2 having 
different extensions (e.g. in SSL handshake). Some that matter here:

- basic constraints - would allow longer/shorter chain (shorter 
chain=>possible DoS)
- name constraints - very rare in practice
- policy constraints - rare in practice, I'm not sure how widespread 
support in clients is
- authority information access - it may be handy to swap a cert for one 
without OCSP or CRL

Adam Langley mentioned following scenario before 
* The site fails to include any intermediate certificates
* The leaf doesn't include an Authority Key Identifier, but incudes an
AIA URL for I1 (I1 = next CA cert in chain just above server cert)
* I1 is replaced with a certificate with the same SPKI, but a different 

Though in case server does not send intermediate chain the processing at 
client's side is non-deterministic.

Any other ideas?


More information about the cryptography mailing list