Public Key Infrastructure: What & How?
Public Key Infrastructure: What & How?

Public Key Infrastructure: What & How?

GET THE BASICS RIGHT – THE REST WILL FOLLOW

Encryption: A process of converting data into a form which can’t be comprehended by anyone UNLESS he does the operation of decryption to get back the original data.

Why Encrypt: To prevent the data from being read/understood and used by some unintended party. World is not that good a place 🙁

The major elements of the encryption & decryption process are:

  • Key              
  • Algorithm

P.S. – Mind the colors

Encryption Process

The encryption consists of passing the data and key into an algorithm, which does some mathematical magic and spews out the cipher(encrypted) data.

[Original Data, Key] -> Algorithm -> Cipher Text

Decryption Process

The decryption does the opposite of encryption, i.e. retrieves the original data from the cipher text.

[Cipher Text, Key] -> Algorithm -> Original Data

Types of encryption

  1. Symmetric : Uses the SAME KEY in both encryption and decryption.                        The same key is given to participating parties (not very scale-able).
  2. Asymmetric: Uses DIFFERENT KEY for encryption and decryption.                                  The user has a PRIVATE and a corresponding PUBLIC key.

PEARLS OF WISDOM

“My PRIVATE key is private to me but my PUBLIC key is known to the world”.

Oh yes, this is the way it is 🙂

Data encrypted by the PUBLIC key can ONLY be decrypted by the corresponding PRIVATE key. Now this is making sense…this seems scale-able. I can distribute my public key without any fear of compromise, unlike the symmetric keys, which if compromised can lead to unintended parties accessing my data.

Symmetric key: That’s my secret. I’ll only give it to whom I trust.

Asymmetric key: I can share my public key, not a big deal.

THE PROBLEM

How do I distribute my public key???

Why…I’ll give out my public key to whosoever I’m dealing with…what’s the problem!!

What is the authenticity of the information?

Let’s say If I’m Alice, a 3rd party who is taking care of the all the electronic communications happening with a bank. As a customer I would need the banks public key, so that I can send encrypted information to the bank.

Alice provides me the public key of the bank. Should I go ahead with this key?

What if Alice has provided a different key?

Hell…I need to TRUST somebody.

THE SOLUTION

 Trust…trust…trust

Here comes the Public Key Infrastructure (henceforth referred to as PKI), which solves the problem of trust and thereby the distribution of keys.

PKI is a hierarchical trust structure which      16starts with the Certificate Authority (Root CA), and branches out to other PKI entities like  intermediate CA (optional), relying entity etc.

Some of the well know certificate authorities (CA) are Verisign, Symantec, Globalsign etc.

Key terms

Certificate Authority(CA): A trusted entity which provides the public keys for the involved parties.

Intermediate CA: A entity trusted by the CA. Mainly used for offloading work of the root CA. Hence intermediate CAs are responsible for distributing the public keys.

Relying party: The end device/user doing the communication

Certificate:  Analogous to a physical certificates, acting as the carrier of authentic data. These digital certificates are provided by the certificate/intermediate authorities and contains the public key of the end entity, for e.g. a web server.

X.509: Is a standard defining the format of public key certificates

ACTION SPEAK LOUDER THAN WORDS

Lights…camera…action

Plot: An online transaction with the bank, performed by the user

Actors: CA, Bank, User

Behind the scenes: Bank approaches the CA and hands over its public key, asking for a digital certificate. The CA does some checks to confirm the validity of the facts provided and if convinced, provides a digital certificate to the bank, embedding the public key in it. Like any other physical certificate which needs a seal/signature from the issuing authority to prove its validity, the CA digitally signs the digital certificate. This digital signature can be cross verified by anyone who has the public key of the CA….phew…too much digital.

On-Stage: User connects to the bank. The bank sends the digital certificate to the user. The user has a list of known good CAs with their public keys. If the digital certificate received is signed by any of the CAs in my list, I’ll check the seal/signature with the respective CAs public key. If it matches…voila…i have contacted a genuine bank. Go ahead and start communicating with bank, using asymmetric encryption.

Remember, the banks public key is in the digital certificate and can be used to encrypt and send data to the bank; which can only be decrypted by the bank using its private key.

Wow, I now have a channel with the bank which is secure and can be used for any communication.

Well this is a highly simplified explanation of what happens. In reality, each of the steps  are a separate area of study and as such would require a whole book on its own. But all in all, this is the high level working.

How do I get the ‘my list‘ of CAs?

Well before going any deeper, lets bring in the real actors of the play.

User -> Web Browser

Bank -> Web service

Each of the browsers have list of CA certificates called trust store, which come preconfigured with the browser. For example, shown below is the trust store for chrome.

17

Although the above example shows a webservice using digital certificates, it can be used with just any application which supports the use. In this example, we created a secure channel between the service and the user. This is typically achieved by the TLS protocol, which is basically the underlying workhorse for manifesting the security in HTTPS.

So, coming back to the topic…What is PKI?

A public key infrastructure is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. (source: Wikipedia)

Can I have my own CA?

Oh yes, you can have your own PRIVATE CA, which is only known to you. Maybe it delivers all the certificates used for applications inside your organization.

But as soon as you move out of your organizational boundaries, you would need certificates issued by a PUBLIC CA, so that it could be trusted by other parties.

CLIMAX

Lets provide a good ending by doing some hands-on practice. We will use openssl toolkit (OpenSSL) to do create a private CA.

Generate a 2048 bit RSA key for the private CA.

openssl genrsa -out privCA.key 2048

Generate the certificate for your private CA. On executing this command  it will prompt you to enter your country, company name, etc.

openssl req -new -X509 -key privCA.key -out privCA.crt

Now that we have a private CA, we can use this CA to create certificates for entities. The only requirement is that the private CA certificate should be installed in the end entities.

Generate key pair for entity

openssl genrsa -out entity.key 2048

Generate a certificate signing request (CSR). The CSR gets submitted to the CA for the purpose of issuing a certificate.

openssl req -new -key entity.key -out entity.csr

Generate the entity certificate, signed by our private CA

openssl X509 -req -in entity.csr -CA privCA.crt -CAkey privCA.key -CAcreateserial -out entity.crt

Congratulations…you just became a CA 🙂

Further Reading: Anatomy of Digital Certificate

One comment

  1. Pingback: AWS IoT: The programmatic way – Keep It Simple

Comments are closed.

Discover more from Open Knowledge

Subscribe now to keep reading and get access to the full archive.

Continue reading