In today's world, more than ever, cyber security must be taken very seriously to protect all (inter)connected assets. In this article, we discuss the principle of asymmetric cryptography, the only way to guarantee authenticity, integrity and confidentiality in your operations.
What is asymmetric cryptography?
Over 2,000 years ago, Caesar protected his military messages by encrypting them. Would it be so simple today?
Today, cryptography adds an extra layer of security. Symmetrical cryptography, even if it ensures confidentiality up to a certain point, is not sufficient to guarantee the authenticity and integrity of communications. How can asymmetric cryptography solve this equation?
Let's take an example and designate Alice and Bob as the two people wishing to exchange a confidential message. Each has a public key and the corresponding private key. A message encrypted with a public key can only be decrypted by the corresponding private (secret) key. A message encrypted with a private key can only be decrypted by the corresponding public key (we'll see why later in this article).
In the situation described above, Alice, who wishes to send a message to Bob, will encrypt it with Bob's public key. In this case, only Bob will be able to decrypt it with his own secret key. This answered the need for confidentiality.
But how can Bob be sure that it was Alice who sent him the message? How can he be sure that the message hasn't been modified on the way? To answer this question, Alice will also use a signature mechanism. All these concepts (encryption, signature) are part of asymmetric cryptography.
The hash function and signature mechanism
Before talking about signature, we must introduce the concept of “hash function”. A “hash function” is a "mill" that turns a text into a signature (also called a fingerprint). This “mill” has 5 properties:
- For the same function, the number of characters in the fingerprint is always the same,
- The fingerprint does not allow the original text to be reconstructed,
- A fingerprint is not predictable,
- Identical data gives an identical fingerprint,
- Different data results in a completely different fingerprint.
“MD5” and “SHA” are two well-known hash functions. For example, with MD5, the text “Ewon: Leading IIoT for 20 years” is converted in the chain of 32 characters: “5b184c5cafcad9ef410afbcb0fab5518”. As a comparison, the entire content of all Wikipedia would also result in a (completely different) chain of 32 characters.
After the signature comes the encryption process
The above being considered, let’s come back to our example: To sign a document, Alice first generates the document fingerprint using a hash function (like https://www.md5hashgenerator.com/ or any other one you can find on the internet . Then, she encrypts this fingerprint with her private key. She gets a signature on her document which she can send to Bob along with the original document.
Bob will then decrypt the signature using Alice's public key. If that doesn't work, it's because the document was not sent by Alice (who is the only one in possession of the private key). If this works, he can be sure it was Alice who signed the message. He therefore obtains a first fingerprint of the document.
Once this step achieved, Bob will generate the fingerprint of the original the document he also received, using the same hash function as Alice. If both fingerprints are identical, then he is perfectly sure that the document has not been modified between the time Alice sent it and the time he received it.
The combination of encryption and signature is the only way to simultaneously encode and sign a document and ensure the confidentiality, integrity, and authenticity of the message.
That's all very well, but there's perhaps one last problem: how can Alice be sure that she's using Bob's public key when she encrypts a message? Indeed, if a hacker (let's call him Eve) were to produce a key pair (private/public) and pass it on to Alice, making her believe it was Bob's key, Alice would continue to encrypt the messages and pass them on to Bob. In this case, only Eve could decode and read the messages...
Alice must therefore be able to authenticate Bob before using the latter's public key. To do this, Bob can have his public key recognized by a Certification Authority (CA), which will ensure that he is indeed the owner of this public key. This assurance takes the form of a certificate that the CA provides to Bob. This certificate contains information identifying Bob and his public key. It is in turn signed by the certification authority to guarantee its legitimacy.
Alice can then contact this authority to obtain confirmation that the public key she is using is indeed Bob's. Difficult to do better!
Asymmetric and symmetric cryptography can be complementary
Asymmetric cryptography has only one drawback compared to symmetric cryptography; it is slower. To gain speed, a secure connection uses both types of encryption, symmetric and asymmetric.When an internet browser establishes a secure connection with a server, it will first generate an asymmetric session (temporary) key. Then it will use the public key of the server (whose authenticity and validity is verified thanks to its certificate) to encrypt this session key and send it back to the server, which after having decrypted it will be able to communicate with my browser in a symmetrical way.
This approach is the solution to Caesar's 2000-year-old problem. Thanks to it, two entities that don't know each other can exchange a secret without having to agree on an encryption/decryption key.