In the world of internet, sending messages in clear text is like swimming naked. We would love some secure communication channels free from eavesdropping or tampering. Security as such is not some trivial question. An evolution of designs is presented below to illustrate the challenge we face and how we end up trusting trust (PKI-CA).

Design 0: Clear text

The reason clear text transmission is unsafe is that the connection between the two parties is logical. Packets are in fact routed multiple times before reaching destination, which means any intermediate node has access to the payload, hence no privacy.

Exposures to the intermediate nodes are unavoidable. It is the way the internet was built and the reason the internet can be scalable to billions of users. It is funny that for hundreds of years mathematicians had engaged with cryptography but were unsure how it might be applicable to anything if at all. Luckily when the internet started booming and security concern raised, we had every tool in our hands.

Design 1: Symmetric key

It is assumed that an encrypted message cannot be decrypted in tractable time unless one holds the decryption key. When the encryption and decryption keys are the same, it is said to be symmetric. One major challenge when using cryptos is the distribution of secrets, in this case the symmetric key. If the internet is the only communication medium, then any sharing of keys is in clear text (no encryption before knowing the key), and all bets are off once any third party knows the secret. If you want to encrypt the key before sending over, then you need another key for this encryption and you still face the challenge of secret sharing.

We might approach the problem by hard coding it to the two communication parties, but the client code is not secure. It is subjective to manipulation even in binary format.

Design 2: Public key and private key

We may choose different keys for encryption and decryption respectively and share the encryption (public) key only. Any message encrypted with this public key can only be decrypted with the private key, which is assumed to be known only to the principal. Each party mints a key pair and it never has to change.

But sharing the public key leads to the initial problem of secret distribution. When Bob receives a key marked as Alice’s, how can Bob be sure? Mallory in the middle could easily swap the key with hers so that when Bob thinks he is talking to Alice, it is actually Mallory.

Design 3: Root of trust and public key as identity

To ensure that the key Bob receives is indeed Alice’s public key, Bob needs to hear it from someone he trusts before he can trust Alice, if we assume trust is transitive. However, to find that someone Bob trusts, Bob has to trust another one who trusts that someone. To end the inductive chain, we must have some root of trust. In the internet, it is the certificate authority (CA). A certificate of Alice is Alice’s public key digitally signed by the CA. The digital signature of any content is the hash of that content then encrypted with the CA’s public key. All CA’s public keys are baked in the client, like your browsers. If Bob trusts the CA, who trusts Alice, then Bob could trust Alice given a signed certificate.

With knowledge of Alice’s public key, Bob may bootstrap a secured communication with Alice by encrypting his public key using Alice’s public key. Only Alice will be able to decrypt this message, who may reply messages encrypted using Bob’s public key. Since asymmetric keys are computationally expensive to use, they are often used to bootstrap a secure channel through which a symmetric key is shared. Subsequent communication is then encrypted and decrypted using that symmetric key.

Problem remains

The trust aforementioned refers to the confidence in one’s identity but says nothing about the information provided or assertion made by that principal.

Also in such centralized design, once the root of trust compromises, then all bets are off. DigiNotor is a contemporary example.