We are going to discuss in this article about the following concepts. The article is divided in 2 parts: a glossary and the “why and how” of the certificates/public/private keys.

The certificates are mainly used for 3 uses cases :

• Authentication: The assurance to one entity that another entity is who he/she/it claims to be.
• Integrity: The assurance to an entity that data has not been altered (intentionally or unintentionally) between “there” and “here,” or between “then” and “now.”
• Confidentiality: The assurance to an entity that no one can read a particular piece of data except the receiver(s) explicitly intende

1. Glossary

1.1 PKI

A typical PKI consists of hardware, software, policies and standards to manage the creation, administration, distribution and revocation of keys and digital certificates.

A typical PKI includes the following key elements:

• A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities
• A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root
• A certificate database, which stores certificate requests and issues and revokes certificates
• A certificate store, which resides on a local computer as a place to store issued certificates and private keys

1.2 Private & Public keys & asymmetric cryptography

Private and public keys are randomly generated string of characters. They are used to encrypt and decrypt messages. The private key is never revealed to anyone whereas the public key may publicly revealed.

A message encrypted with a private key may only be decrypted with the associated public key and vice versa. This is what we call asymmetric cryptography. As oppposed to symmetric cryptography which needs only a unique key to encrypt and decrypt messages.

Note that only the messages which are encrypted with the public key are “secret” since the ones that are encrypted with the private key may decrypted by anyone who owns the public key which is publicly available.

1.3 Certificate

A certificate is an envelope which contains (among other elements), the public key of the secured server and a “signature”. The signature is generated by hashing the whole certificate with all its messages using a hash algorithm (ex : SHA1 or MD5) ans the result of that hash is called a digest. The digest is then encrypted with a private key (usually it is a Certificate Authorithy’s private key). The encrypted digest is what we call the “signature”. Thus, a certificate embeds the public key and some identification meta data concerning the server and the signature.

1.4 Signature

A signature is a message (usually a digest generated with a hashing algorithm) which has been encrypted using a private or a public key.

1.5 Keystore & Trustore

Keystore & Trustsore are are mainly the same type of element. They are safes which contain private keys, public keys and certificates and which are protected with a password. The keystore contains your public/private keys and certificates whereas the Truststore contains the certificates of the authorities or servers that you trust.

1.6 Asymmetric vs symmetric cryptography

A crypted communication may be done either with a unique key -> symmetric (DES & AES) or with 2 key, private & public -> asymmetric (RSA et DSA)

Pros and cons : The problem with symmetric cryptography is that a secured server who wants to receive encrypted messages (secured web server for instance) will have to generated a different encryption key for each server that need to communicate with it. If all other servers had the same encryption key, then they would all be able to decrypt each othes messages that they each send to the secured server. -> This is why we need asymmetric cryptography.

1.7 Hashing vs Cryptography

1.7.1 Hashing with SHA1

SHA1 is a hash algorithm, which is a one way function, turning an input of any size into a fixed-length output (128 bit in this case). A cryptographic hash function is one for which it should not be possible to find two inputs giving the same output except by brute force (for instance, with a 128-bit function you should need to try on average 2^64 message to find such a “collision” due to something called the birthday paradox - Google it for more). In fact for SHA1 this is no longer the case - the algorithm is (in cryptographic terms at least) broken now, with a collision attack described by Xiaoyun Wang et al that beats a classic birthday attack. The SHA2 family is not broken, and a process is underway by NIST to agree on a SHA3 algorithm or family of algorithms.

1.7.2 Crypting with RSA

RSA is an asymmetric encryption algorithm, encrypting an input into an output that can then be decrypted (contrast a hash algorithm which can’t be reversed). It uses a different key for encryption (the public one) than for decryption (the private one). This can therefore be used to receive encrypted messages from others - you can publish your public key, but only you with the private key can then decrypt the messages that have been encrypted with it.

If you reverse the keys for RSA, it can be used to generate a digital signature - by encrypting something with your private key, anyone can decrypt it with the public key and, if they are sure the public key belongs to you, then they have confidence that you were the one who encrypted the original. This is normally done in conjunction with a hash function - you hash your input, then encrypt that with your private key, giving a digital signature of a fixed length for your input message.

2. Why and how

2.1 Encrypted communication (SSL)

Since the symmetric cryptography needs less CPU calculation then asymmetric cryptography, it is better to have a symmetric cryptography. The 2 servers which need to communicate securely need to have the same encryption key. The client will generate a symmetric encryption key, encrpyt it with the public key of the secured server and send it to the secured server.

Now the 2 servers have the same encryption key and will be able to start an symmetric encrypted communication. Ths encryption key will be used only for that session.

In order to have an asymmetric cryptography the secured server need to send its public key to the client. Here comes the man in the middle vulnerability : If the man in the middle catched the public key of the secured server and sends its own public key to the client, the client would then encrypt its messages with the man in the middle’s publick key. The man in the middle would then be able to decrypt the message with its own private key. And then encrypt it again with the secured server public key before sending that message back to the secured server.

We need a solution to garantee to the client (server 3 in the image) that the public key he received is really the one that has been sent by the secured server -> This is where certificates gets into the act !

Once the client server receives that certificate, it does 2 things :

1. It checks if the public key needed to decrypt the signature is in its trustore. In that case, it means it can trust the incoming message. The client decrypts the signature and gets ths digest.
2. The client then generates the digest with the same algorithm used by the secured server and it compares both digests. It they match, the client has the guarantee that the public key embeded in the certificate has not been altered and thus can be used to encrypt sensitive data.

If the man in the middle tried to get into this communication, its certificate would have been rejected from the client since the client does not have the public key of the signatory of the man in the middle’s certificate (whether it is self-signed or signed by CA certificate)

2.2 Message integrity

Data integrity is guranteed:

1. When data is sent, a digest is calculated from this data
2. Sender encryps the digest with his private key and sends the encrypted with the message
3. The receiver uncrypts the digest with the public key of the sender
4. The receiver calculates the hash of the message and compares it to the one he received
5. If the difests are the same, than that means that the message has not ben altered

In that case, the message itself is not encrypted but is certainly not altered

2.3 Authentication

1. The client sends it’s signed certificate to the server after encrypting the digest of the certificate with his own private key.
2. The server checks the integrity of the digest using the client’s public key which can be found in the server’s truststore
3. If the certificate has not been altered, then the server may trust the identity described in the certificate and authenticate the client.