Self Asserted Key Pinning

Rationale

Convergence notaries employing network perspective (the default notary strategy) are very effective at _introducing_ clients to servers. The Convergence client then caches the server's seen certificate for future use.

If the cached certificate changes in the future, the client will have to contact the notaries again. This is effective in mitigating attacks from those who only control a partial path to the server (the vastly common case), but it would also be nice to protect against attacks by those who control the entire DNS.

Network perspective notaries can alert clients when certificates change, but SAKP is an attempt to provide a more explicit mechanism for servers to assert their identity. When combined with a secure introduction mechanism like Convergence notaries, it provides a system which protects against both local and global attackers.

Overview

Self-asserted key pinning allows an SSL site to advertise certificate requirements to connecting clients, which they must validate on subsequent connections. These advertised certificate requirements allow a site to "pin" the certificates it is using, either by:

1. Specifying the public key of a CA which must exist in future certificate chains the client is presented with.
2. Specifying a "meta" key which must contain a signature for future end-entity certificates the client is presented with.

Delivery Mechanism

Key pinning is something that should be asserted and validated at the SSL protocol level. In order to communicate an SAKP assertion, the server includes a "superfluous" certificate in the SSL certificate chain that it presents to the user.

For instance, a normal SSL certificate chain for an end-entity such as thoughtcrime.org might look like this:

VeriSign Level 1
   |
   ---> VeriSign Intermediate CA
           |
           ---> www.thoughtcrime.org

If thoughtcrime.org were to assert SAKP rules, however, the certificate chain would look like this:

SAKP Certificate (self-signed)
VeriSign Level 1
   |
   ---> VeriSign Intermediate CA
           |
           ---> www.thoughtcrime.org

A certificate containing SAKP information is merely included in the chain (although it is not strictly part of the chain, since it doesn't sign anything other than itself). Clients that do not understand SAKP will simply ignore it, while clients that do understand SAKP will parse it to interpret the SAKP assertions.

Pinning a CA hierarchy

In the above example, thoughtcrime.org is signed by the CA VeriSign. The site operators of thoughtcrime.org might wish to assert that clients should not accept certificates signed by *other* CAs. In this case, thoughtcrime.org can present an SAKP certificate which contains a v3 extension that specifies the "pin" of VeriSign's SubjectPublicKeyInfo.

Once clients see this SAKP assertion, they will ensure that all future end-entity certificates for thoughtcrime.org have the "pinned" SubjectPublicKeyInfo somewhere in the chain.

Pinning outside the CA hierarchy

While pinning to a CA hierarchy might be desirable to some, others might not want to directly place their trust into a single CA. In the above example, for instance, VeriSign (or attackers who managed to compromise VeriSign) would still capable for forging certificates for thoughtcrime.org.

For those that wish to isolate trust from CAs, SAKP also provides pinning to "meta" keys. These provide a layer of indirection away from CA certificates, while still allowing sites to provide end-entity certificates that are signed by CAs. To do this, thoughtcrime.org would provide an SAKP certificate which contains a v3 extension that specifies a "pin," where the SubjectPublicKeyInfo of the pin is that of the SAKP certificate itself.

In this case, the SAKP certificate would then have another v3 extension that contained a signature of the end-entity certificate for thoughtcrime.org.

Once clients see this SAKP assertion, they will ensure that all future end-entity certificates for thoughtcrime.org are provided with an SAKP certificate containing the same SubjectPublicKeyInfo, with a v3 extension containing a signature for the new thoughtcrime.org end-entity certificate.

SAKP Pin Revocation

A site might wish to change or otherwise eliminate its pin. To facilitate this, every SAKP certificate contains a "pin break commitment." This is a v3 extension that contains sha384(pin-break-code), where the pin-break-code is simply a random value. When a client accepts the SAKP certificate's assertions, it remembers the pin break commitment.

In the future, if the site wishes to change its SAKP certificate assertions, the new certificate will contain a v3 extension specifying a list of previous pin-break-codes. When a client sees this new SAKP certificate, it will ensure that one of its specified pin-break-codes hashes to the pin-break-promise for the current SAKP assertions it has pinned.

Structure of a SAKP certificate

To recap, a SAKP certificate has this structure:

X509 Certificate
   Version
   Serial Number
   Algorithm ID
   Issuer ('SAKP')
   Validity
      Not Before
      Not After
   Subject ('SAKP')
   Subject Public Key Info
      Public Key Algorithm
      Subject Public Key
   Extensions
      SAKP Pin - SHA384(Certificate's SubjectPublicKeyInfo)
      SAKP Pin Break Promise - SHA384(pin_break_code)
      SAKP Meta Signature (Optional)
      SAKP Pin Break Codes (Optional)

Thanks To

• Trevor Perrin for much of the heavy lifting.