IT101: Encryption, keys and certificates


The topic encryption is quite complex and it takes a while before it gets clear why all the ingredients are necessary.



It gets more and more common to encrypt every data transfer over an unsecured network like the Internet.


From a high-level perspective the encrypted communication between two partners A and B is quite simple: A uses a key to encrypt the data, send the encrypted data to B and B uses a key to decrypt the data.


If we dive deeper into the process of encryption and decryption it gets a bit more difficult.

First of all, the two partners need to agree about the kind of encryption (encryption algorithm) that they will use.


Then they have to make sure that both A and B have all the necessary information for the chosen encryption algorithm. Mainly this will be the key A uses to encrypt and B uses to decrypt. At this point it is important that ONLY A and B have this information, otherwise some others could intercept and read the transmitted data even if it is encrypted.


There are some well-defined encryption algorithms with efficient implementations that A and B will use for their communication. These algorithms are based on “symmetric encryption” with a single key used for encryption and decryption.


It is most likely that the communication partners A and B have only an unsecure communication channel like the Internet to negotiate this key before they can start the encrypted data transfer.

This is a scenario for example that happens every time A like to use a website of B and requires to have the data transferred encrypted to and from the website.


So, what has to happen before the actual request to and the response from the web server can be transmitted encrypted, when A types in an URL starting with “https://” in his browser addressing B’s website ?


Asymmetric encryption with public and private keys

This is the moment where asymmetric encryption comes into the play:

Asymmetric encryption uses not a single key but a pair of two keys to encrypt and decrypt.

This two keys are called public key and private key. They are created together and one key can only be used in combination with the other.


Here some important facts about private/public key pairs

  • Data, that is encrypted with the public key, can only be decrypted with the private key
  • Data, that is encrypted with the private key, can only be decrypted with the public key
  • The key pair always belong to a communication partner. The pair owner has to keep the private key as a secret and should publish the public key to everyone who likes to communicate with him.
  • The two keys are much longer than the keys used for symmetric encryption, so the asymmetric encryption algorithms are much slower than the algorithms used for symmetric encryption. They are too slow to use them efficiently for larger amounts of data like the communication between client and web server.


Now we come back to the “key exchange problem” of the symmetric encryption: before the encrypted data transfer between client A and web server B can start, both partners – and only these two – have to know the key they will use.


And this is the solution: client A generates a key K (also called session key) that both will use for the symmetric encryption, encrypts this key with the public key of server B and sends the encrypted key K to B.

Server B is now the only one that can decrypt the key K with his private key. B decrypts the key K and both partners can start the encrypted communication with key K.


Here some recap before we introduce certificates:

  1. Our starting point is, that A and B want to exchange encrypted data over an unsecured channel like the Internet. For efficiency reasons symmetric encryption has to be used.
  2. The only way to negotiate the necessary key K for the encryption is over the same unsecure channel.
  3. Therefore client A generates a key K, encrypts it with B’ public key so that only B can decrypt it and send the encrypted key to B.
  4. B decrypts the key K with his private key and both partners can start their encrypted communication by using key K.


So, why do we need certificates, chains of trust and public key infrastructures on top of this  ?


Certificates and Chain of Trust

The challenge raises from the fact that A has to use B’s public key for encrypting session key K.

How does A get this key? If B provides A with his public key, how does A know that this is really B who sent the public key and not a fake web server that pretends to be B?


Some words about Public Key Infrastructure (PKI) before we start with the certificates. PKIs are useful to exchange keys within a trusted domain like an enterprise. E.g. email encryption within a company can be realized by linking the email recipient’s public key to his email address in the corporate directory (mostly a LDAP), using this directory as a PKI. The sender of the email has to trust the corporate directory and the public key of the recipient he gets from there.


Another way to proof the authenticity of a public key is by the use of certificates. With this approach every owner of a public key provides his key directly to a requestor instead of using a central public key directory. The public key is bundled with some additional information that should convince the requestor that the public key is authentic.


The bundle of public key and the additional information is a certificate. And this additional information is a signature from a trusted third-party. This third-party should be a well-known Root Certification Agency (Root-CA). For trusted domains like a company’s Intranet this can be an internal security department.


Let’s have a look at the players of our encryption game. We have client A that likes to exchange encrypted data with server B. This server B has to provide A with his public key in a way that A trust that public key.


Preparation of the certificate

Therefor B sends beforehand his public key together with some information about himself to a Root-CA named C to request a signature for that public key. This request is known as Certification Request. The formal Certification Request consist of the public key in a textual representation together with some information about the key’s owner B also as text in a predefined format.


Agency C checks then that the requestor is really, really B and not a fraud (this process is a story by its own). If the check is successful, C signs the public key and the provided information about B and sends the result – the Certificate – back to B.


From a technical point of view the certificate consists of B’s public key and ownership information in the mentioned text representation and the signature added by C. The signature is a checksum of the key’s and ownership’s text calculated by C and then encrypted with C’s private key.
Usage of the Certificate

Server B sends the certificate (containing his public key, the ownership information and the encrypted checksum of these information as C’s signature) to A. Client A uses the public key of C to decrypt the signature, calculates the checksum by himself and checks it against the checksum calculated by C. If both match, A accepts B’s public key from the certificate (saves it for further usage) and finally starts the encrypted communication with B.


Chain of Trust

We just found out that the agency C has also a private/public key pair and the public key of C must be known and trusted by A, otherwise the whole thing doesn’t work.


How does A get C’s public key? Who tells A that this is really the public key of C? Are we lost in an infinite loop of signing public keys by another agency again and again? No we don’t!


And the solution is pretty simple: Every web browser, every Windows installation and every Java installation contains a list of public keys (better: the self-signed certificates containing the public key) of well-known Root-CAs. And with that list of public keys client A trust every certificate that was signed with a private key that matches one of the public keys on the list.


This burdens a big responsibility to the Root-CAs to protect the access to their private keys. These private keys are normally implemented in a specific hardware that destroys itself in case of an attempt of fraud. Replacing the destroyed hardware is less expensive than the damage that could be happen with unauthentic certificate generated from that private key …


Lessons learned

  • Normal encryption between two communication partners is done with a symmetric encryption algorithm using one key for encryption and decryption.
  • The exchange of this symmetric session key is done with the help of an asymmetric encryption algorithm using a private/public key pair.
  • The challenge for the key pair owner is to convince the user of the public key to trust this key.
  • This is done by wrapping the public key with a certificate containing a signature from a Root-CA. This signature proves the authenticity of the public key.
  • The certificate can be gathered from a Root-CA by
    1. generating a private/public key pair
    2. sending the public key together with some ownership information (e.g. the websites domain name) to a Root-CA as a Certification Request Form (CRF)
    3. getting through the Root-CA authentication procedure (and pay some money)
    4. receiving the certificate from the Root-CA
  • And last but not least: you must provide this certificate to clients, so that they can check the signature and use the contained public key.


Here are some examples how to use the certificate:

A website certificate (as a text file) together with the private key (as a separate text file) must be part of the webservers configuration.

A code signing certificate must be delivered to the client together with the code that was signed with the private key (signing means, that a checksum of the code was encrypted with the private key).