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 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 TACK 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

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 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 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 chain (although 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 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 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 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 be capable for forging certificates for thoughtcrime.org.

For those that wish to isolate trust from CAs, TACK 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 a TACK certificate which contains a v3 extension that specifies a "meta key." This is a key that the site controls, which they can use to sign any end-entity certificates they would like to present. Since the "meta signatures" live in the TACK certificate itself, the site is free to continue having their end-entity certificates signed by CAs.

In the "meta key" case, the TACK certificate would also contain a v3 extension that specifies a "pin," where the pin references the site-controlled "meta key," rather than the SubjectPublicKeyInfo of a CA certificate.

Once clients see this TACK assertion, they will ensure that all future end-entity certificates for thoughtcrime.org are provided with a TACK certificate containing a "meta key signature" from the same "meta key."

TACK Pin Revocation

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

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

Structure of a TACK certificate

To recap, a TACK certificate has this structure:

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
      TACK Pin Break Promise (Optional)
      TACK Meta Signature (Optional)
      TACK Pin Break Codes (Optional)

Structure of TACK Pin

struct TACK_Assertion_Type1 {
	uint8 spki_sha256[32];
};

struct TACK_Assertion_Type2 {
	uint8 metakey_sha256[32];
};

enum {spki(1), metakey(2)} TACK_Assertion_Type;

struct {
	TACK_Assertion_Type assertion_type;
	select (assertion_type) {
		case spki: TACK_Assertion_Type1;
		case metakey: TACK_Assertion_Type2;
	};
} TACK_Pin;

Structure of TACK Pin Break Promise

struct TACK_Break_Type1 {
	uint8 break_verifier_sha256[32];
};

enum {sha256(1)} TACK_Break_Type;

struct {
	TACK_Break_Type break_type;
	select (break_type) {
		case sha256:  TACK_Break_Type1;
	};
} TACK_Pin_Break_Promise;

Structure of TACK Meta Signature

enum {ecdsa-sha256(1)} TACK_MetaKey_Type;

struct TACK_MetaKey_Signature_ECDSA_SHA256 {
	opaque metakey_value[64];
	uint32 expiration;
	opaque signature[64];	
};

struct {
	TACK_MetaKey_Type metakey_type;
	select (break_type) {
		case ecdsa-sha256:  TACK_MetaKey_Signature_ECDSA_SHA256;
	};
} TACK_MetaKey_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.