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.
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.
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:
“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.
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.
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!
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.