-
Notifications
You must be signed in to change notification settings - Fork 108
TACK ECC
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.
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:
- Specifying an in-chain public key which must exist in the site's certificate chain.
- Specifying an out-of-chain public key which must sign some public key in the site's certificate chain.
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.orgIf 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.orgA 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 extensions. The TACK certificate extensions have been designed so that, in the future, they could be converted into TLS extensions.
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 a "pin" for one of the two VeriSign certificates' 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.
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, attackers who managed to compromise VeriSign, and intermediate CAs signed by 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, and can be used to sign any SubjectPublicKeyInfo in the site's certificate chain, including the site's end-entity certificate itself. 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 TACK certificate's out-of-chain key, rather than the SubjectPublicKeyInfo of an in-chain certificate such as VeriSign.
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.
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.
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)
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.
struct TACK_Pin_In_Chain {
opaque spki_sha256[32];
};
struct TACK_Pin_Out_Of_Chain {
opaque ecdsa_p256_sha256[32];
};
struct TACK_Break_Type_SHA256 {
opaque break_verifier_sha256[32];
};
enum {in_chain(1), out_of_chain(2)} TACK_Pin_Type;
enum {none(0), verifier_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;- "spki_sha256" is a SHA256 hash of some SubjectPublicKeyInfo field from an X.509 certificate in the current SSL Certificate chain.
- "ecdsa_p256_sha256" is a SHA256 hash of the "out_of_chain_key" field in this certificate's TACK Signature.
- "verifier_sha256" is a SHA256 hash of some 32-byte pin-break code.
enum {ecdsa_p256_sha256(1)} TACK_Signature_Type;
struct TACK_Signature_ECDSA_P256_SHA256 {
opaque out_of_chain_key[64];
opaque spki_sha256[32];
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;- "out_of_chain_key" is an EC public key on the NIST P-256 curve.
- "spki_sha256" is a SHA256 hash of some SubjectPublicKeyInfo field from an X.509 certificate in the current SSL Certificate chain.
- "expiration" is a uint32 encoding UNIX time / 60. The signature will be rejected by a browser if the expiration time has elapsed. This allows sites to mitigate the risk of compromise of in-chain SSL keys by using shorter-lived signatures.
- "signature" is an ECDSA-P256-SHA256 signature over the 101 bytes of TACK_Signature from the "signature_type" up to the "signature" field.
struct {
opaque pin_break_code[16];
} TACK_Pin_Break_Code;
struct {
TACK_Pin_Break_code pin_break_codes<16..4096>
} TACK_Pin_Break_Codes;- Trevor Perrin for much of the heavy lifting.