TACK ECC

TACK (Tethered Assertions for Certificate Keys)

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 local attacks which only control some paths to the server (the vastly common case), but it would also be nice to protect against global attacks by those who control the DNS or routing for a site.

Network perspective notaries can alert clients when certificates change, but TACK provides a more explicit mechanism for sites to assert what changes are allowable. When combined with a secure introduction mechanism like Convergence notaries, it provides a system which protects against both local and global attackers.

Overview

TACK 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 an in-chain public key which must exist in the site's certificate chain.
2. Specifying an out-of-chain public key which must sign some public key in the site's certificate chain.

Delivery Mechanism

Key pinning is something that should be asserted and validated at the SSL protocol level. In order to communicate a TACK 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 TACK rules, however, the certificate chain would look like this:

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

A certificate containing TACK information is merely included in the SSL/TLS Certificate message (it is not strictly part of the chain, since it doesn't sign anything other than itself). Clients that do not understand TACK will simply ignore it, while clients that do understand TACK will parse it to interpret the TACK assertions. In the future, the TACK mechanisms have been designed so that they could be incorporated into a TLS extension, rather than a superfluous certificate.

Pinning an In-Chain Key

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 TACK certificate which contains a v3 extension that specifies the "pin" of VeriSign's SubjectPublicKeyInfo.

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

Pinning an Out-Of-Chain Key

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

For those that wish to isolate trust from CAs, or that want the flexibility to switch CAs, TACK provides pinning to out-of-chain 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 a TACK certificate which contains a v3 extension that specifies an out-of-chain public key. This is a key that the site controls which can be used to sign any public key in the site's certificate chain. Since the out-of-chain public key and signature live in the TACK certificate, the site is free to continue having its end-entity certificates signed by CAs.

In the out-of-chain pinning case, the TACK certificate's pin would reference the out-of-chain key, rather than the SubjectPublicKeyInfo of a certificate.

Once clients see this TACK assertion, they will ensure that all future certificate chains for thoughtcrime.org are provided with a TACK certificate containing an out-of-chain signature over a SubjectPublicKeyInfo appearing somewhere in the certificate chain.

TACK Pin Breaking

A site might need to change its certificate chain in a way that violates an existing pin. To allow this, TACK certificates may contain a "pin break verifier." This is a value stored alongside the pin that contains SHA256(pin-break-code), where the pin-break-code is simply a secret random value generated by the site. When a client stores the TACK certificate's pin, it stores the pin break verifier with it.

In the future, if a browser contacts the site and detects a mismatch between a stored pin and the certificate chain, the browser will check the TACK certificate extension specifying a list of pin-break-codes. If one of the specified pin-break-codes hashes to the pin-break verifier for the current pin the browser will delete the pin, and behave as if it was contacting the site for the first time (by checking with Convergence notaries).

If there is a pin mismatch and no pin-break code for the pin, the browser will reject the connection.

Structure of a TACK Certificate

To recap, a TACK certificate has the standard X.509 structure with three optional extensions:

X509 Certificate
   Version
   Serial Number
   Algorithm ID
   Issuer ('TACK')
   Validity
      Not Before
      Not After
   Subject ('TACK')
   Subject Public Key Info
      Public Key Algorithm
      Subject Public Key
   Extensions
      TACK Pin             (Optional)
      TACK Signature       (Optional, requires a TACK Pin of pin_type=out_of_chain)
      TACK Pin Break Codes (Optional)

A TACK Pin without a TACK Signature is pinning an in-chain key. When pinning an out-of-chain key, both the TACK Pin and TACK Signature are present. If older pins have been broken then TACK Pin Break Codes is present. TACK Pin Break Codes may appear by itself if the site wishes to break old pins but not create a new one.

The following extension definitions use the SSL Presentation language defined in RFC 2246.

Structure of TACK Pin

struct TACK_Pin_In_Chain {
	opaque spki_sha256[32];
};

struct TACK_Pin_Out_Of_Chain {
	opaque ecdsa_p256_sha256[32];
};

enum {in_chain(1), out_of_chain(2)} TACK_Pin_Type;

struct TACK_Break_Type_SHA256 {
	opaque break_verifier_sha256[32];
};

enum {none(0), sha256(1)} TACK_Break_Type;

struct {
	TACK_Pin_Type pin_type;
	select (pin_type) {
		case in_chain: TACK_Pin_In_Chain;
		case out_of_chain: TACK_Pin_Out_Of_Chain;
	};
	TACK_Break_Type break_type;
	select (break_type) {
		case sha256:  TACK_Break_Type_SHA256;
	};
} TACK_Pin;

Structure of TACK Signature

enum {ecdsa_p256_sha256(1)} TACK_Signature_Type;

struct TACK_Signature_ECDSA_P256_SHA256 {
	opaque key[64];
	uint32 expiration;
	opaque signature[64];	
};

struct {
	TACK_Signature_Type signature_type;
	select (signature_type) {
		case ecdsa_p256_sha256:  TACK_Signature_ECDSA_P256_SHA256;
	};
} TACK_Signature;

• "version" specifies the cryptographic algorithms used for metakeys and metakey signatures. Version 1 specifies SHA256 and ECDSA/NIST P-256.
• For version 1, "metakey_value" is an EC public key on the NIST P-256 curve.
• "expiration" is uint32 encoding UNIX time / 60
• For version 1, "signature" is ECDSA-SHA256 over the 69 bytes of TACK_MetaKey_Signature prior to the "signature" element and the SHA256 hash of the site's end-entity certificate.

Thanks To

• Trevor Perrin for much of the heavy lifting.