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.

 

Understanding Public Key Infrastructure (PKI) - Part 1 (Introduction)

Introduction

Ever wondered what happens behind the scenes when you do an online bank transaction? Do you know what goes on in the background to keep your transactions safe and secure from the prying eyes? Are you getting confused about terms like digital signature, digital certificate, hash functions, symmetric and asymmetric encryption, certificate authorities, SSL/TLS, etc? Then this blog might help you clear some concepts for you. Read on.

PKI, Public Key Infrastructure, is a very complex mix of security technologies. So, I am going to start by explaining individual components that make up the PKI. Once you are familiar with these components, understanding PKI becomes very easy.

 

Symmetric Key Encryption

 

This is the simplest thing to understand, and in high probability, you already know this. Encryption is the process of scrambling the data into an unrecognizable form, such that, if the traffic ends up in the wrong hands, it will be useless. To perform encryption, the data in clear text and a key is input to an encryption algorithm. The output of the encryption algorithm is the encrypted text or ciphertext. To get back the original data from the ciphertext, you need to use the same algorithm that was used to encrypt the data and also input the key. If the same key is used to encrypt and decrypt the data, then it is called 'Symmetric Key Encryption'. DES, 3DES, and AES are examples of symmetric key encryption. Symmetric key encryption is generally used to achieve confidentiality of your data.

 

Asymmetric key Encryption

 

Unlike symmetric key encryption, where only a single key is used to encrypt and decrypt the data, asymmetric key encryption involves two keys or a key pair. The keys in the key pair are mathematically related in such a way that any data encrypted with one key can only be decrypted using the other key and vise versa. It is important to note that the same key that was used to encrypt the data cannot be used to decrypt the data. RSA is an example of asymmetric key encryption.

 

Now, what is the difference between symmetric and asymmetric key encryption?

 

Symmetric key encryption is used when bulk encryption is needed. For example, symmetric key encryption is used when your browser and the web server are communicating via SSL/TLS communication. The reason for this is symmetric key encryption is faster and consumes less processing overhead.

On the other hand, asymmetric key encryption is slower and consumes more processing overhead. Therefore, asymmetric encryption is used for encrypting a small amounts of data, such as in digital signatures, digital certificates, etc. Asymmetric key encryption is generally not used to encrypt your data traffic.

 Great! I am sure that was a piece of cake for you. Let us move on. 

 

Hashing

 

While the encryption process keeps your data hidden from the bad guys, the hashing algorithm is used to ensure the integrity of the data. Let's say, you are sending a message to your bank to "Pay $100 to Mr. Scooby". What if Mr. Doo is able to intercept this communication and change the message to "Pay $1000 to Mr. Doo?" How will the bank know that the data has been modified in transit?  This is where hashing helps.

Hashing is a one-way mathematical function, that takes a message of arbitrary length, (could be one word or an entire book) and produces a fixed-size sequence of bits. These output bits are called the 'hash' or 'message-digest' of the message. MD5 and SHA are the two popular hashing algorithms. MD5 produces a 128-bit hash and SHA-1 produces 160 bit of hash.

So, how is hashing going to help in our case here? Before sending the message, you must calculate the 'hash' of your message "Pay $100 to Mr. Scooby" using, say MD5. Now, send the hash, along with the message to the bank. The bank will verify the integrity of the data by calculating the 'hash' of the received message (of course using the same algorithm) and compare it with the 'hash' received along with the message. If both the hashes match, that indicates to the bank that the message has not been altered in transit. Mr. Scooby gets his $100 happily. If Mr. Doo has modified the message in transit, the hashes won't match at the bank end, and the bank will discard the message. Mr. Doo is still wondering why $1000 is not credited to his account!

Even if one bit is modified in the original message, the resulting 'hash' will be entirely different from the original 'hash'.

And, read the first line of the second para above again. I said hashing is a one-way mathematical function. By one way, I mean, it is almost impossible to get the original message from the 'hash'.

A key can also be used to input to the hash algorithm (in addition to the message) to make it more secure. This is called HMAC, Hashed Message Authentication Code.

Getting interesting uh? Dig in for more.

Digital Signature

 

If you thought the digital signature is the scanned copy of your signature on a paper, then you are not alone. When I heard of this term many years ago for the first time, I really thought so. So cute, isn't it?

Before we talk about the 'digital' signature, let us see what paper signature is used for. As we all know, when a person puts a signature, with a pen on a paper, the person authenticates the message written on the paper. Right? A digital signature is also used for the same purpose, but to authenticate digital messages, such as an e-mail.

Before we see how a digital signature is created, let us take another look at asymmetric key encryption. In asymmetric key encryption, two keys (a key pair) are generated, a Private Key and a Public Key. These two keys are mathematically related in such a way that, a text encrypted with a private key can only be decrypted with its corresponding public key and vise versa. This is very important in understanding digital signatures and PKI.

So, if Alice wanted to sign a message digitally to authenticate it, she must first generate a private/public key pair, on her computer. The private key, as the name implies, is known only to Alice (her computer) and no one in the world. Alice must take at most care not to share her private key with anyone. However, she can distribute or share her public key with anyone in the world. 

Let's say, Alice wanted to send a digitally signed message to Bob. First, she must share her 'public' key with Bob. Then, she creates her message that says "Let's have coffee". Now, she will have to create a digital signature for her message.

Here is how a digital signature is created and used.

1. Alice takes the message "Let's have coffee" and runs it through a hashing algorithm, such as SHA-1. SHA-1 takes the message as input and generates a 160 bit hash as output. 

2. Alice encrypts the resulting hash (160 bit) with her 'private' key. The encrypted form of the hash is Alice's digital signature for that message.

3. Alice sends the message (Let's have coffee) to Bob and also appends the digital signature with it. 

4. Bob receives the message along with the digital signature. 

5. Bob runs the messages through the same hashing algorithm, SHA-1 in this case, and produces the hash. This hash will be the same hash generated by Alice in step 1.

6. Bob also decrypts the digital signature with Alice's 'public' key. The result will be the original hash of the message (same hash value in step 1). That is, Bob simply performs the reverse operation of step 2.

7. If the hash generated in step 5 and step 6 are the same, then Bob can be sure that Alice has signed the message, and also the message has not been modified in transit. The fact that only Alice has her private key and nobody else, the matching hash indicates that the message was in fact signed by Alice's private key.

8. If the hash generated in step 5 and step 6 do not match indicates either Alice has not signed the message or the message has been modified in transit. In this case, Bob will simply discard the message.

From the above steps, carefully note that the 'message' is not encrypted, but the 'hash' of the message is encrypted, which forms the digital signature.

Here, asymmetric key encryption is used to authenticate the message, but not used for encrypting the message. As I discussed earlier, message encryption is performed using symmetric key encryption. We will talk about this later.

I hope you now have a fairly good idea of how digital signature works! Great.

I know you have a few questions on the digital signature process we discussed above. I had them too. I will address them in part-2 of this blog.

See you there...

Mohan Muthu
mohan.bestroute@gmail.com