Certificates and the Chain of Trust

Introduction

Asymmetric keys provide an undeniable advantage over symmetric keys: Because they consist of a public and a private part, the key exchange becomes very simple, as you do not have to worry about keeping the (public) key a secret. (Check out my post on Asymmetric Key Encryption for details.)

However, there is a slight problem with this: How do you know that the public key you are currently holding really is the key from the person you are intending to communicate with?

Chain of Trust

Let us assume Alice wants to send Bob an encrypted message. To get Bob's public key, she sends him an email. After a while, she receives a response that contains a public key. Because email is an inherently insecure medium, Chuck could have sent the response claiming to be Bob. If Chuck found a way to intercept all communication between Alice and Bob, he now can decrypt every message Alice is encrypting with the fraudulent key. Afterwards Chuck can encrypt that message again with Bob's real public key and pass it on to Bob. Alice and Bob would never know of the "man in the middle".

If Alice and Bob know each other personally, they could meet and exchange their keys that way. However, if they do not know each other this becomes more difficult, as during that meeting they still would not know if they are actually talking to the right person.

What would you do, if you just met a person and needed to know that they actually are whom they proclaim to be? You would probably ask for their identification card or passport. That is a document that you inherently trust, and that can prove the identity of its holder. The important part here is that you trust that document; or rather, you trust the organization that created the document. The document says that that trustworthy organization vouches for the identity of the document holder.

In the digital world, a digital signature by a trusted third party can provide the same functionality. Let us go back to the example of Alice trying to communicate with Bob. If Alice trusts Trent, and Trent vouches for the correctness of Bob's public key, Alice can be pretty sure to have received the correct key.

Without going into too much detail, a digital signature is implemented by using asymmetric key encryption the wrong way around. If Trent takes Bob's key and encrypts it with his own private key, Alice can verify the correctness by decrypting it with Trent's public key. That decryption attempt can only be successful if Trent's private key was used to encrypt the key. As only Trent has access to his private key, Alice can assume that Trent encrypted Bob's key himself. In practice, Trent would not encrypt the entire key, but only a digital digest of the key, a so-called hash value. That encrypted value makes up the signature and like a physical signature, the digital signature implies that Trent has seen the signed document and that he agrees with or vouches for its contents.

Certificates

A certificate is a container for an asymmetric key together with additional describing information. In particular, a certificate can be signed by a third party. To verify that signature, you would have to get the certificate of the signing party. If you do not directly trust that third party, you can look at who signed their certificate and move up the chain of trust until you find a signature by an organization that you trust.

HTTPS Certificates

This system is for example implemented for websites that use TLS encryption (https://). When your browser contacts the web server of say mybank.com, it receives a certificate for that web address. The certificate is signed by the issuing certificate authority, say securebanking.com. Your browser automatically goes to that authority's web server and requests their certificate. That certificate contains the public key that your browser can use to confirm that securebanking.com actually issued the certificate received from mybank.com. However, your browser does not trust securebanking.com, so it looks at who signed their certificate. Every browser comes delivered with a set of trusted root-certificates. After following the certificate chain for a few steps, the browser will eventually find a certificate that was signed by one of those root certificates known to the browser. At that point, a complete chain of trust has been established and the browser can display that the authenticity of the web server has been confirmed.

Certificates in SQL Server

In SQL Server, certificates can for example be used to encrypt the communication with a client but also to sign stored procedures. Such a signature proves that the module has not been altered since it was signed. Module signatures can for example be used to grant additional permissions to that module, without having to grant those permissions to the caller.

Summary

A certificate is a container for an asymmetric encryption key. That container contains additional information about the key, including a signature by a third party. That signature can be used to establish a chain of trust between two parties that are trying to communicate. In SQL Server a certificate can also be used to grant additional permissions to a stored procedure without needing to grant those permissions to all callers.