This blog post assumes that you already have knowledge on overall cryptography systems & terminology (encrypt, decrypt, cipher, hash etc.). The intention of this post is just to clarify the main concepts of Public-Key Cryptography.
Mainly this post describes the concepts below:
- Digital Signatures
- Digital Certificates
So lets jump straight to it 🙂
Basically, in a public key cryptography scheme, all entities will posses a pair of keys. In comparison to symmetric cryptography entities will have only one pre-shared key (the main disadvantage of symmetric ciphers). A key pair consist of two keys mathematically tied to each other. The concept is that anything encrypted with one part of the key, it can be decrypted only with the other part. So in terminology a key pair will include a public and a private key. As by their name the public part of the key pair is supposed to be shared publicly with anyone who wants to initiate communication with that entity. While the private part of the key pair is assumed to be kept secret for themselves. So if two endpoints want to have a secret communication with each other, initially they need to share their public keys. Then, they will encrypt their messages with each other’s public keys. This way, the only ones who can decrypt the messages are themselves with their private keys. This way the communication is ensured to be confidential. And most importantly, it solves the key sharing issue which we face on symmetric encryption (hopefully will be another blog post for that).
Another feature of Public-Key Cryptography is the Authentication. It is easily achievable just by applying the encryption method the other way around. This means that using the private keys to encrypt (the other way around of what we described in the last paragraph), one can also achieve authentication. That is because everyone can decrypt a message that was encrypted with a private (because you would only need the public key, duh!). So this means that the only one that could create message which is readable by everyone (using the public key) is the one who holds the private key for it. This process ensures the authenticity of the message, by guaranteeing that the message was composed by the entity that owns the private key (ideally the private key is not stolen).
A digital signature in particular mimics the behavior of human signatures. Basically, it uses the authentication feature of Public-Key cipher. It works by compressing the message (hashing) and encrypting the hash with the private key, then sending it along with the original message (cleartext / un-encrypted). More specifically, it contains the original message, the hash of the original message encrypted with the private key, the public key, the hash & encryption algorithm information, and other metadata. Hence, in the other end, the receiver will verify the message authenticity by creating a hash of the original message by using the same algorithm. Then will decrypt the encrypted hash with the provided public key. After that, it will check if both hashes match, the one that was calculated itself by using the original message and the one by decrypting the encrypted message hash. If hashes match it means the message is authentic from that public key and was not altered by any third party. So this from the human perspective is similar to someone signing a document with its (supposedly) unique handwriting signature. While the document is not secret and it is readable by others, so anyone can easily verify your handwriting signature.
Anyway, digital signatures do not guarantee the identity behind that public key. Therefore digital certificates are introduced.
To follow up with understanding a digital certificate, first, we need to clarify the notion of Central Authority (CA). A CA is an entity which contains a key pair like others as well. The difference here is that its public key is trusted by others (usually systems are pre-configured with them). The job of a CA is to verify the identities behind public keys. If it can identify them correctly, the CA digitally sign the hash of their public keys. Then the entities can use this signature to prove their valid identity. So a digital certificate will contain the original public key, the public-key hash signed by the CA, CA identifier, hash & encryption algorithm, and other metadata. Thus, in this case, when a receiver tries to verify the message, will first check if the CA identifier is in its trusted list. Then, will use its public key to decrypt the signed public key hash. After that, will calculate the hash of the original public key and compare it with the hash of CA signed the message. If hashes match, then the identity of that public key can be trusted. Again, seeing this on human perspective, is similarly with our National ID documents. These documents are signed and issued by the Government which is (supposedly) trusted by others.
By using digital signatures & certificates, we can also achieve to have Non-Repudiation. This is a mechanism which assures that someone cannot deny a specific action. Usually, this is used to ensure that some party cannot deny the authenticity of their identity which was used in some communication or whatever other action. From the human perspective, this is the same as the process of signing or stamping documents, as an assurance that someone verified them and they cannot deny it later. The same principle is achieved with digital signatures & certificates. So they are not only used to have authenticity, integrity, and secrecy, besides there is also non-repudiation.