Digital Signatures are something that is very important in understanding security on the Internet. While we have seen it in the context of personal e-mail, the applications are much broader, in particular to the use of certificates to establish communication.
Recall from our discussion of e-mail that there are two things you can do with an e-mail using PGP or GPG. First is you can encrypt the message, which you do using the public key of the recipient, and then they can decrypt the message using their private key. The other was putting a digital signature on a message. But how does that work?
Well, we saw in the last tutorial that asymmetric encryption generates two linked keys, which can each be used to decrypt what the other one encrypted, but cannot be used to decrypt what they themselves encrypted. And that is the key, if you will pardon the pun, to understanding digital signatures. When you digitally sign a message, you are using your private key to encrypt the message itself, which gets added to the bottom of the message. But this is not done to obscure the message at all, since the message is also sent “in-the-clear” in the e-mail. Your recipient can then use your public key to decrypt the digital signature, get the message back from the encrypted form, and compare it to a the message as it was sent “in-the-clear”. If they match, you have established two things:
- Because your public key successfully decrypted the message, we have established that it was you who sent it. Your public key can only decrpyt messages that were encrypted by your private key in the first place.
- Because the messages match, we have established that the contents of the message have not been tampered with en route.
When you understand how this works with e-mail signatures you are well on the way to understanding how Certificates work, since the technology is very similar. In fact, some definitions of Digital Certificate start with the signing of e-mails, but what I want to do now is move to understanding how certificates work on the Web, which is where we most commonly encounter them.
Transport Layer Security (TLS)
Transport Layer Security is how you establish a secure connection to a Web site, among other things. It is the successor to Secure Sockets Layer (SSL), which was created by Netscape in the 1990s. TLS is more secure, but it does include a mechanism to downgrade to SSL 3.0 if necessary. Many people use these terms interchangeably, but the technologies are not equal, and you always want to be using TLS. Fortunately, in most cases this is all handled behind the scenes in a negotiation between your browser and the remote site.
TLS works much like e-mail encryption. Asymmetric encryption is used to establish a connection and to validate the identity of a site, then a symmetric key is exchanged and used to securely communicate both ways. As we saw previously, Asymmetric encryption is very useful for establishing a connection when there is no shared key, but it is not computationally efficient, so switching to a symmetric key once the connection is established speeds things up.
Another similarity to e-mail encryption is that establishing trust has issues. We saw that PGP keys are “signed” by people as part of what we call the Web of Trust, which while not perfect, does provide some measure of assurance that the key you are using does in fact belong to the person you are communicating with. All of these issues apply as well with Digital Certificates. Establishing trust means signing the certificate, and this is done by a Certificate Authority. Symantec, which bought Verisign’s SSL business, is the largest, and GoDaddy is also significant here. For you trivia buffs, one of the early authorities was Thawte, which was owned by Mark Shuttleworth. He sold the company for a large pile of cash and then founded Canonical, creators of Ubuntu Linux.
X.509 is the standard adopted by the International Telegraphic Union for managing secure communications, and dates back to 1988 in its original form. It establishes the role of Certificate Authorities, sets standard formats for certificates, and so on. The model this standard adopted for establishing trust is hierarchical, which is different from the Web of Trust model. Everything starts with a root authority which testifies to the authenticity of a certificate by adding its own digital signature. These root authorities can sign certificates for other authorities, who can then issue certificates, and so on. Most browsers some with a pre-installed set of certificates for the largest online sites so that a connection happens very quickly. But if if you don’t have a certificate, you need to go through a handshake process to create a connection and obtain a certificate.
X.509 Certificates include a number things, and I won’t list all of them (if you are curious, this Wikipedia page has more information.) But among the specific items it includes are:
- Serial Number
- Algorithm ID
- Public Key
The first three items, Version, Serial Number, and Algorithm ID, are important for setting up a connection, as we will see. There is a negotiation between your browser and the server to establish the specifics of the encryption protocol to be used. Issuer is of course important in establishing how reliable the certificate is. If it is signed by a respected Certificate Authority, it is considered more trustworthy, while if it is a “self-signed” certificate it is somewhat questionable. So why do people use self-signed certificates? The ones from the Certificate Authority can be very expensive. As I mentioned previously, Mark Shuttleworth became w wealthy man through owning a CA. These certificates can run thousands of dollars, and need to be renewed every few years.
Validity is an important field, not always handled properly. Recall that when we looked at e-mail encryption we noted that a key pair usually is created with an expiration date, and then a new key pair needs to be created. Similarly, a certificate has valid dates during which it should be accepted, and if you are outside those dates your browser should reject the certificate and throw up a warning. It is important to note here that the end user is allowed to make insecure connections if he wishes, but a good browser will at least warn you of the problems. If you get one, and just click OK without too much thought, well, you deserve whatever you get. There are a lot of issues around Validity, and more than just dates are involved. We will get to that in more detail in another tutorial.
Finally, the certificate must include the Public Key which you can use to set up a secure connection. This can be complicated, as we will see below in the handshake process, but the simple idea is that when you generate a key pair, You get two keys, which we could call A and B. If anything is encrypted using A, it can only be decrypted using B. And anything encrypted using B can only be decrypted using A. It is kind of arbitrary which one is public and which one is private. So if the server wants to send you a symmetric key ot use for communication, it encrypts the symmetric key using its Private key, and you can decrypt it using the server’s Public key.
A full description of the handshake could encompass several tutorials all by itself, and I don’t plan to do that. You can get the details from Wikipedia. But in essence it follows this pattern.
- You send the server a message asking to create a secure connection. For example, there is a browser plugin from the Electronic Frontier Foundation called HTTPS Everywhere, and as the name implies it attempts to create an HTTPS connection to every site. This plugin is available for Chrome, Firefox, Opera, and Firefox for Android. I highly recommend that you install this on your browser. You can also manually request a secure connection by typing the URL using https instead of http. Some sites may not offer secure connections (see above for the cost of certificates), but Google now does so by default for all of its properties. And if you are trying to do e-commerce you really need to offer it. I would never enter my credit card number on a site that was not secure.
- Alternatively, the server may decide to go to a secure connection (e.g. e-commerce) and send a message to your browser telling it to move to a secure mode.
- Then a negotiation takes place to establish the precise encryption protocols to be used. There are a number of them available, and in general the negotiation is to find the highest level of security supported by both your browser and the server. Once this is agreed the server will create a symmetric key using the agreed protocol, encrypt that key with its own Private Key, and send it to the client.
- The client then decrypts this using the server’s Public Key, and now both sides can use the symmetric key to communicate securely.
- A session ID is established that allows an interrupted session to be resumed without going through the whole handshake process again.
This is the essence of the handshake. It works reasonably well, but there are issues where things can go wrong, and that is where we will go next.
But one thing you might want to keep in mind is that this technology does more than just connect you to a Web site securely. In general, when you hear someone talk about “certificates” in any security context this is what they are talking about. For instance, the Dreaded UEFI (Unified Extensible Firmware Interface) and its related Secure Boot uses X.509 certificates issued by Microsoft (as the Certificate Authority) to validate the software that is allowed to boot on a system that employs Secure Boot. So if you get to know how this works on Web sites, you already understand much more than that.
Listen to the audio version of this post on Hacker Public Radio!