Understanding Public Key Infrastructure (PKI) - Part 2 (Digital Certificates)

In part-1 of this blog, we discussed the basic building blocks of PKI infrastructure, such as encryption, hashing, digital signatures, etc. In part-2 here, we will continue to discuss the digital signature process and address the questions.

In part-1, under the 'Digital Signature' section, I said, Alice will have to send her 'public' key to Bob, so that Bob can verify her signature at the receiving end. Now, the first question is; How can Bob be sure that the 'public' key he received from Alice is in fact belongs to Alice? It is quite possible that an attacker can send his 'public' key to Bob and fool Bob into thinking that the key belongs to Alice. This way, the attacker can send any digitally signed message to Bob and if Bob uses the attacker's 'public' key, the attacker can send a message to Bob and it will appear that the message came from Alice.

So, the question is; How does Bob verify that the 'public' key he received from Alice is in fact belongs to Alice? This is where Digital Certificates come into play.

Digital Certificates

 

 Before Alice sends her 'public' key to Bob, she has to obtain a digital certificate from a third party, that both Alice and Bob trust. This thrid-party is called the Certificate Authority or CA for short. The digital certificate issued to Alice by the CA simply authenticates that the 'public' key mentioned in the digital certificate belongs to Alice. Here is the process of obtaining a digital certificate.

1. Alice generates the key-pair (public key and private key) on her computer. She keeps the private key safely on her computer.

2. She then generates a 'certificate signing request' to CA. In this request, she puts her name and her public key along with other information and sends this request to the CA.

3. Upon receiving this request from Alice, the CA will verify, through off-line methods such as phone or e-mail, that the requested person is genuine.

4. Once the CA is satisfied that the request is genuine and verified its requester, it will create a digital certificate for Alice and sign it with its own 'private' key.

Here is what happens at the CA end when the digital certificate is created:

1. The CA will take all the information in the certificate request, adds validity dates, issued to, issued by fields, and pass this information (like a message) into a hashing algorithm, such as SHA-1. The SHA-1 will produce a hash.

2. Then, the CA will digitally sign the contents of the certificate by simply encrypting the hash (in step 1) using its own 'private' key. The encrypted hash is the digital signature of the CA.

3. The CA then appends the digital signature to the contents such as name, public key, validity dates, etc. This now becomes the digital certificate of Alice, signed by CA.

4. CA will send the signed digital certificate to Alice.

From now on, Alice can use her digital certificate to prove that the 'public' key mentioned in the certificate belongs to her. In our case, instead of sending just the 'public' key to Bob, Alice will instead send her digital certificate to Bob.

Got it? Wait, the story is still not complete. If your head is spinning at this stage, you may want to take a break (or a beer) at this stage and fully understand the certificate signing process. Very important in understanding PKI.

Once you are sober...jus kidding...no offense... Continue on...

Now, after receiving Alice's digital certificate, how will Bob verify the authenticity of Alice's certificate? Part-3 of this blog will answer this question.

See you there.