Dec 12, 2019
Digital Identity as we know it…
We have seen how Alice and Bob can communicate with each other securely once they exchange their public keys in a previous article. This article deals with how they can make sure the key really belongs to who they think it does.
Imagine the scenario, Alice and Bob have to communicate over an insecure channel. Alice sends a message to Bob sharing her public key. Bob receives a public key. But since the channel is not yet secure, Bob needs to be sure that he received the key from Alice itself.
Chuck is a party who has some malicious intent. He intercepts the public key of Alice. He also generates an asymmetric key pair. Now Chuck sends the newly generated Public Key to Bob posing as Alice. Bob receives Chuck's key and thinks it is Alice's. Bob sends his public key to Chuck mistaken for Alice. Chuck then sends his Public key to Alice posing as Bob.
Now we have a situation where Alice thinks Chuck is Bob and Bob thinks Chuck is Alice. Chuck can now listen to everything Alice and Bob send. Also Chuck can send whatever he fancies to Alice and Bob posing to be the other. This scenario is the beginning of a man in the middle attack.
This can be avoided if the public key of the person you are communicating to is verifiable by you or made known to you previously in a secure manner. There are several ways you can do this.
Share your public key out of band. Out of band verification is used in so many places. The most common example is banks sending an OTP to your registered mobile or email when you try to make an online transaction. The logic is that it will be very unlikely that an attacker comes in possession of your banking or credit card details and also your unlocked phone simultaneously. If you loose your wallet and your phone then you are definitely out of luck!
Another way is to declare your public key in a public place. Like a trusted website. The most secure way would be to share in person. But that is not always feasible or scale-able. If you can easily meet a person best is to communicate in person!
The most widely used method to verify public keys is by using digital certificates. A digital certificate is issued by a certificate authority(CA) after verifying your identity. The certificate will include the owner’s verified details and public key as well as issuer’s name and digital signature, and in most cases a similar certificate of the issuer.
Wait. What is a digital signature? A digital signature guarantees that the contents of the certificate have not been altered and also provides a way to verify the author. Let’s see how it works.
A hash is a fixed size string obtained by passing any data of arbitrary size through an algorithm called hash algorithm. The algorithm becomes secure and useful in cryptography when it satisfies a few conditions. The important ones are as follows
The hash should be unique for a piece of data. A piece of data should always result in the same hash if the algorithm remains unchanged and no two distinct input should result in same hash. It should be simple to compute a hash. Given the hash it should not be possible to find out the original data(Theoretically only brute force can break it. But practically should be impossible). Also a small change in the data will result in a completely different hash. An algorithm that satisfies these conditions is called a Secure Hash Algorithm(SHA).
There are various SHA standards. Crypt-analysts try to find out vulnerabilities in these algorithms. As a result certain standards are found to be unfit for certain use cases.
A signature is basically the hash of the message signed using a private key (hence called signing key). The signature can be verified by a person who knows the corresponding public key and the original message. It is practically impossible to fake the signature.
Coming back to digital certificates, the certificate can be validated by verifying the signature of the issuer. To do that, one needs to know the public key of the issuer. Whoa! Now I need to know issuer’s key also. Great!
So now if Dave issued Alice's certificate, Bob needs to be sure that Dave is who he says he is to be sure that Alice is who she says she is. If Bob already trusts Dave and knows Dave’s key to verify the signature on the certificate, that’s great. Else he has to get Dave's certificate and verify that. If Dave's certificate is issued by someone Bob is not certain of, the chain of validation goes on. Bob can stop validation when he identifies a known issuer in the chain or when he reaches a ‘root certificate’.
Or alternately Alice can always provide a certificate issued by someone Bob trusts. Phew! That’s a relief for Bob. But then for each party Alice needs to get a new certificate. Or is there someone everyone trusts? ‘Everyone’ could be an overkill…
A root certificate is a self signed certificate. Meaning it is issued by no one else. Usually in a network, the entity holding the root certificate is known and trusted and is called the root CA. This is because the identity is widely publicized and expected to be known by all participants in that network. Any other certificate issuer is called an intermediate certificate authority.
Go ahead and click on the padlock next to the address bar to see the certificate details of Medium. This helps you be sure that you are interacting with the real Medium website and not a Chuck posing as Medium. For those of you using the app I have added images. You are welcome!
Digital Certificates can prove the identity of any entity to communicate over an insecure channel. The Digital certificates are an attestation by a CA that a public key belongs a particular digital entity. The CA’s do this by verifying the details that they are attesting. The CA may also attest to some other attributes of the holder.
To prove your digital identity all you need to prove is the ownership of the public key mentioned in the certificate. This can easily be done by signing a piece of data shared by a verifier using the corresponding private key. Bob can verify the identity of Alice by verifying the signature and then following the chain of certificates to verify the authenticity of the certificate itself.
The system of issuing and verifying certificates in this way is standardized by what we know today as the Public Key Infrastructure.
Tl;dr: Public Key Infrastructure helps you verify who you are communicating with.
The padlock in the address bar just means that the certificate was issued by someone your browser trusts. Your browser in this case is an agent acting on your behalf and verifying identities for you. For example to see a list of certificate authorities trusted by Firefox visit here.
Is there another way to verify someone’s identity? Wait for my next article.
