From this entry, which is a follow-up on the dedicated lecture at FSU, you can learn an in-depth outline of how digital certificates and certificate authorities work.Certificates are composed of a public and a private key. I should mention that there was a point where there was only one root certificate authority, VeriSign. Back in the day the Internet was small and there was one root CA. And the model worked, the model made sense: you have one guy that everyone trusts and he’s supposed to have, basically, top secret security, impossible to hack. And it all makes sense, it all works.
But now we have hundreds of certificate authorities, and that’s not necessarily a problem in itself, because we’re approaching a billion IP addresses that are used for websites. You can’t expect one single entity to police a billion different websites to make sure that: “Hey, they’ve kept the private key secure, they’re acting legitimately, they’re playing by the rules”. That’s actually infeasible, that’s impossible.
So, before we go further into that, we need to cover, basically, what certificates are. Certificates are basically composed of a public and a private key. This is, essentially, asymmetric key cryptography. The public key certificate, commonly referred to as just the certificate, is a digitally signed statement that binds the value of that public key to the identity of the person, device or service that holds the corresponding private key.
It’s usually supported through X.509 standard certificates. It’s important to note that these were designed back in the 80s. As a result, the X.509 standard is commonly perceived to be messy. They’re also designed to be very flexible and very general. Throughout the years since it was introduced, people have exploited its generality and its flexibility to make certificates behave in totally whacky ways that no one actually intended them to behave. Like I said, in the 1990s there was not a vast body of knowledge on how to properly secure protocols. So, take it 10 years earlier – they never foresaw any of these problems occurring. And yet, we still use it.The art of, basically, binding the value of the public key to the identity of the person, service or device holding its private key comes down to, essentially, signing (see right-hand image). Certificates can be used to sign two different things. One is to provide secure communication that offers non-repudiation and authenticity. In other words, Bob sent this message, I can prove that Bob did send this message. Bob can’t claim: “Hey, I didn’t send that message”. So it’s non-repudiation, and the first part that I said is I can prove Bob sent that message, so that’s authenticity.
The private key of a certificate can be used to sign a message and is decrypted or verified with the public key. A private key can be used to sign other people’s public keys, and this is how certificate chains are established in a chain of trust – essentially, trust relationships. So, in essence, VeriSign signs this certificate for Microsoft and your browser sees that: “Hey, VeriSign trusts Microsoft, I trust VeriSign, thus I trust Microsoft”. And this flaunts the foundation of the public key infrastructure.Let’s talk about the public key infrastructure (see right-hand image). It is, essentially, a set of hardware, software, people, policies and procedures needed to create, manage, distribute, use, store and revoke digital certificates. Now, I should note, before I get all doom gloom for the rest of the hour, that certificate blacklists exist and they work. It requires properly checking the blacklists though; some browsers may not be configured to do that as frequently as they should. So this is the topology for general public key infrastructure (see right-hand image). The most important part of it is the certificate authority. It is responsible for binding the public key with the respective users’ identities. The user identities must be unique, in theory, whilst in practice we see that not being the case; unfortunately, more often than we desire. And the CA uses its own private key to sign the user’s public key to say: “Hey, I trust this user”.
The validation authority, shorthanded as VA, is supposed to be a third party that exists to provide and vouch for user information. It validates that user A is who he says he is. It is involved in the registration and issuance of these certificates.
The registration authority exists to ensure that the public key is bound to the individual and to no one else. This ensures non-repudiation.Certificate authorities can sign the public key for other certificate authorities (see right-hand image), saying that: “I, VeriSign, or I, Mozilla, trust this organization to establish other trust relationships in the form of acting as a certificate authority itself”.
It shouldn’t work in reverse; the model should totally fail in reverse; you should not have trust cycles. Trust cycles, when you try to validate a chain of trust, can cause an infinite loop, depending on the implementation. Also they completely break the model; it just makes things not work. It logically falls apart. So this should never occur.
However, if you have enough money, it can, and if you find the right CA that is willing to do shady stuff. I won’t say it on the record here, but there are some CAs out there that will sell, basically, some form of their root certificate if you’re worth at least 5 million dollars, and some other stuff.So, here’s the process, if you own a website, to get a certificate:
1. I ask the certificate authority to issue a certificate in my name.
2. The certificate authority validates my identity and then issues the certificate.
3. I then present the certificate validating my identity to the user who wants to access my website.
4. The user doesn’t know me, so he has the authority to verify my identity, because a certificate authority is mentioned in the certificate that is provided to my user.
5. The certificate authority checks that my certificate is valid; in other words, it hasn’t been altered when the website owner got it, and it hasn’t expired, and some other checks: it hasn’t been revoked as well.
6. After validating the certificate provided to the user, certificate authority tells the user that that certificate is valid.
7. And finally, the user now trusts the website.
Competition was introduced, and so then the question was posed: “Who do I trust more, party A or party B to be my CA and what is it worth to me? How do I put value to that trust? Is there some sort of metric I can use to put the level of the trust I need should only cost this much money?” It’s a very difficult question. It’s an extremely vague question, because trust can really vary the definition from person to person.
There’s a lot of websites out there that allow you to compare the certification services provided from CA to CA. And so, the details here can vary between using 128-bit encryption keys to 156-bit encryption keys to 512 to 1024 and so on. However, in most of the columns it’s not really translated here; it’s just either some vague value of low and high that’s not really scientifically measureable and is used to describe its assurance level.
Now, to a normal website owner that doesn’t really mean that much. It doesn’t mean that much to us as scientists. I might consider 2048-bit encryption keys to be low insurance for my needs. In essence, the website owner has to make a decision, and it’s usually driven primarily by how much money I’m willing to spend. Maybe next year I’ll be able to afford a better one, but for now I’m not willing to allow 570 dollars per month to secure my website.
In essence, getting a certificate means forking over money, providing identifying info about yourself to the CA, and promising to play nice. This entire transaction boils down to your buying their trust. You can manipulate it and interpret it any other way you want, but it always boils down to your buying their trust.
There are some instances where, you know, there’s research done about each person who is registering for a certificate, registering for any certificate from a CA, make sure bad guy is not getting them. That usually does happen. But if they can’t find any bad stuff about you, it generally comes down to a decision that as long as they pay the money, they get their certificate. There may be some standards. For some enterprise certificates you may have to prove that you’re an actual company that exists in a physical location, an office building, has servers, has staff and personnel, and is worth at least that much money as a company, perhaps in publicly traded stocks and assets. So there are restrictions. But at the end of the day you’re buying their trust as long as you meet the standards.So, how do website owners decide? Really, the user doesn’t notice any difference. When was the last time any of you clicked on the certificate information for a website you visited to see it was signed by the exact same certificate chain and root CA as the last time? After all, these guys own a business selling trust, they are the ones securing the Internet, so they must all be trustworthy. So, why not buy the cheapest? And this is, essentially, a common decision that has shaped the nature of the public key infrastructure market. The market can’t decide that’s the actual value. There really can’t be any hard assignment of this much trust is worth this much dollar. So, naturally, market forces drive it to: the people who offer trust for the cheapest get the most customers.