Understanding Public Key Infrastructure

Public Key Infrastructure

How does a client on the internet communicate with a server on the internet? Is this communication secure? Or is someone else like a bad actor listening in to this communication? How can we prevent that? Is the client sure about the identity of the server? What if it’s a fake server claiming to be genuine?

In this article, we’ll take a look into all these interesting questions. In the end, you’ll have the concepts and understanding to answer these questions perfectly.

Today, organizations rely on PKI (Public Key Infrastructure) to manage security through encryption. Specifically, the most common form of encryption used today involves 

• a public key, which anyone can use to encrypt a message
• a private key (also known as a secret key), which only one person (or an entity) should be able to use to decrypt those messages. These keys can be used by people, devices, and applications.

In this article, I am going to explain how all of this works and what are the challenges involved in it. We’ll look at different approaches to encryption and discuss the shortcomings of each approach. In this way, we’ll be able to understand the ‘why’ and ‘how’ each component of the encryption works. 

Let’s start with a basic scenario.

Scenario #1

Here is the situation:

• We have a client & a server. 
• The client is trying to pass sensitive data to the server.

The client can send information & the server can receive it. This is obvious.

Now, let’s change the situation a bit

• A bad actor is present now.
• Through various hacks, it can acquire the data as it is being passed.

So, the bad actor can read the sensitive information and misuse it.

We want to avoid this. 

But how? This is the problem we have to solve now.

Symmetric encryption

Under this method of encryption -

• We take an encryption key and use it to encrypt sensitive information. 
• We use the same encryption key to decrypt the encrypted information.

Let’s see if using asymmetric encryption can help us arrive at a solution.

Though the bad actor can still read the information being passed. It cannot decrypt it and therefore cannot misuse it.

Problem solved, right? Well, not really. Here’s why —

The information being passed has to be used by the server. But since the information is encrypted by a key present only with the client, even the server will not be able to decrypt it.

In order for the server to decrypt it, the client will have to send the encryption key to it. 

If the client decides to send the key to the server — the bad actor can see it too while passing and use it to decrypt everything.

So this would not work. We need to find a way that enables us to send the encryption keys in a way that the bad actor cannot use them to decrypt everything.

But how? This is the problem we have to solve now.

Asymmetric encryption

Under this method of encryption -

• We have a public key & a private key.
• The public key can be thought of as a public lock.
• The private key can be thought of as the key that can open the private key. 

#Scenario 2

Now, the situation is different -

1. The client starts a connection with the server.
2. The server sends the public key (I’ll use the ‘public lock’ term for ‘public key’ from now onwards as it would be easier to understand) to the client.
3. Note: The bad actor has also acquired the public lock now.
4. The client combines its encryption key (the one being used for symmetric encryption) with the public lock it received. It sends this combined entity to the server.
5. Note: The bad actor has also acquired the combined entity. 
6. Though the bad actor has acquired the combined entity, it cannot do anything with it. In order to separate the encryption key & the public lock — a private key would be required. This private key is present only on the server. Hence, it cannot misuse anything that it has acquired.
7. The server receives the combined entity and is able to separate the encryption key as it has the private key of the public lock.

So, we can use asymmetric encryption to securely share the encryption key and symmetric encryption to securely share subsequent sensitive information.

But, there is still a scenario where this could fail. 

Let’s see a new scenario —

1 — The user can be fooled by making them use a fake server operated by a bad actor. This is a type of phishing attack & is very common. 

3 — The unsuspecting users send their encryption keys because they believe the communication is happening with a genuine server.

5 — The bad actor can now separate the encryption key from the combined entity as it has the private keys of its fake server.

There needs to be a mechanism by which the user can figure out the identity of the server and determine if the server is genuine or not. 

But how? This is the problem we have to solve now.

#Scenario 3

Like a certification signals proficiency and genuinity of a skill or achievement, in the same way — websites can also be issued certificates. A website’s certificate signals that it is genuine and is what it claims. 

A digital certificate certifies the ownership of a public key by the named subject of the certificate. If a website does not have a valid certificate, the web browser will caution you about the website. 

But how do websites get their certificates?

Certificate Authorities

• It is a component that stores, signs, and issues digital certificates for websites. 
• It acts as a trusted third party — trusted both by the subject (website owner) of the certificate and by the party relying (users) upon the certificate. 
• Symantec is an example of a popular certificate authority.

How does this work?

• Website owners submit a CSR (certification signing request) using the domain names and server’s public key.
• The certificate authority verifies & validates the request.
• The certificate authority then signs a certificate for the website and sends it to the website owner.

The scenario looks like this now -

So, using these certificates received from the certificate authority, we can verify the identity of the server. 

But what if a bad actor figures this out? They can easily start their own certification authority to certify their own fake websites as legit & use that to dupe users like this -

We need a solution to verify the certificate authorities.

But how can we verify the certificate authorities?

Let’s see this —

• The CAs have public keys (or public lock) & private keys like any other server.
• The CAs use their private keys to sign the certificates i.e. the certificates contain the website details combines with the private key of the certificates.
• The public key of the CAs is built into the web browsers.
• So, when the website sends a certificate to the browser…the browser checks if the private key on the certificate can open the public lock on the browser.
• If yes, then it implies that the certificate authority was legit. And hence the certificate is legit.
• If no, then it implies that the certificate authority was fake. And hence the certificate is not trustworthy.

Note: The above is true for public CAs like Symantec. Some organizations make use of private CAs for their internal websites — in such cases, the public lock of the private CAs needs to be added to the browser explicitly.

And that’s all. We finally have a solution that covers all the situations and makes secure communication between a client and server possible. All the components discussed here, together make the Public Key Infrastructure.

Hope you learned something! Hit like, subscribe to my newsletter and share this with others. Stay tuned for the next one! Connect, Follow or Endorse me on LinkedIn if you found this read useful.

This newsletter is now read by more than 3000 engineers who are future CEOs, CTOs, founders, and distinguished professionals! If you are into cloud & containers you are invited to become a sponsor of one of the future newsletter issues. Feel free to reach out to me over DM for more details on sponsorships.

Other recommended reads:

- Saving EC2 logs on S3 buckets via lifecycle hooks

High Availability & Fault Tolernce for Monitoring Stack

- High Availability & Fault Tolerance for Monitoring Stack

- Using Envconsul with Vault