Public Key Infrastructure is also named PKI. What is the role of Certificate Authority in PKI? Before we talk on this, let’s discuss the term “trust”.

The operation of Public Key Infrastructure strongly depends on “trust”.  And this is also related to the application of asymmetric cryptography technique.

To illustrate this, let’s suppose Bob wants to send a message to Mary securely over the Internet. He needs Mary’s public key to encrypt the message. Theoretically, it is Mary, who owns the one and only one private key of her own, who can decrypt the message. So Mary is the only recipient who can open this message. Bob achieves his objective of keeping the secrecy of this message and revealing it to Mary only.

But the problem is: how can Bob get Mary’s correct public key? Suppose hacker Tom wants to intercept their communication. He can create a fake public key for Mary and send it to Bob. Bob, without knowing that this key is fake, uses it to encrypt the message he intended to send to Mary. The message could then be compromised by Tom for he is the person who owns the corresponding private key to the fake public key he created for Mary.

Tom can then even further re-encrypt the secret message using Mary’s real public key, sending it to Mary, and she doesn’t realize that someone other than her has read the message. And worst of all, Tom can modify the message before he encrypts and sends it, compromising both the confidentiality and the integrity of the message.

How can Bob solve this problem? He can ask for a trusted third party to help verify Mary’s public key. Let’s say this third party is Peter. Peter can help Bob by signing on Mary public key using his own private key. However, there are two conditions that need to be satisfied for this verification to work:

  • First Bob must have full faith in Peter’s role as a verifier.
  • Second, Bob must have an authentic public key for Peter in his key database. He needs Peter’s public key to verify Mary’s signed public key and hence reconfirm the validity of Mary’s public key sent by Peter. (Without Peter’s authentic public key, Bob has no way to ensure he has Mary’s correct public key.)

If the above two conditions are satisfied, there is no way that hacker Tom can send a fake public key for Mary to Bob, because Bob can identify it as fake, with the help of Peter.

But then this leads to another problem: Bob must have a trusted and verified public key for Peter! This seems to create the very same problem involved with verifying Mary’s public key. Bob needs to repeat the same verification procedure used for Mary’s public key, looking for someone who can verify Peter’s public key. This problem can go on and on in a circle until Bob can find an ultimate trusted “root” of public keys.

In the modern public key infrastructure (PKI), the role of Peter is played by a so-called Certificate Authority (CA). In a communication system, CAs are trustworthy organizations that have the corresponding, verified public keys of the users you want to communicate to. The CA holds a database containing the signed public keys it issued for the users who have applied and obtained the public key/private key pair through it. The private key is kept by the user, and the public key is posted to the public and maintained by the CA.

You must have trusted CAs in your database or otherwise the above story can never reach its end.  Take our popular Internet Browser IE as an example. If you take a look at Tools ==> Internet Option ==> Content ==> Certificate ==> Trusted Root Certificate Authorities, you can see it contains a long list of trusted Root CAs.

Public Key Infrastructure: Trusted Root Certificate

The popular ones in the USA are VeriSign, Thawte, etc., which are commercial organizations. In most other regions, CAs come from Government initiatives. Take my home country of Hong Kong as an example. The official CA here is the Hong Kong Post Office, which is a governmental department, with its original function serving the postal service in Hong Kong. Government-backed organizations possess the “trust” factor, and that is an important criterion for a root Certificate Authority who needs to sign and verify its publicly issued keys.

Each CA must possess a very robust infrastructure of its Internet public key directory in serving the intended communication parties of its certificate clients.

Without CAs, you would have to verify the public key yourself. In the above case, Bob would need to verify Mary’s public key before he sends her any message encrypted by the public key he has on hand. This can be done with offline communication such as phoning Mary to verify the key, or simply getting the key from Mary by meeting her face-to-face. Of course, this is very inconvenient and impractical in most electronic communication cases.