7. The Bedrock of Cybersecurity: Cryptography 169 One downside of public key cryptography is that it is not nearly as efficient as symmetric key cryptography—it takes much longer to encrypt and decrypt messages. For example, symmetric keys are typically either 128, 192, and 256 bits long, but public keys need to be 1,024, 2,048, and 4,096 bits long to achieve similar levels of cryptographic strength, respectively. This is a humongous difference and translates into considerably more computer processing. Therefore, public key cryptography is typically limited to exchanging short symmetric keys. If Alice wants to send a secret message to Bob, she first generates a random symmetric key, encrypts it with Bob’s public key, and sends it to him. Then, she encrypts the actual message using symmetric key cryptography with the new secret key she just generated. Bob first decrypts the secret symmetric key with his private key, and then uses the secret key to decrypt Alice’s message. This creates a best of both worlds scenario: public key cryptography is used to distribute the symmetric key and the more efficient symmetric key cryptography is used for encrypting and decrypting the message. 7.2.2.3 The Public Key Infrastructure Public key cryptography solves the key distribution problem that plagues symmetric key cryptography, but it has its own significant weakness. Since public key cryptography does not assume that the communicating parties have ever met, how can they be sure they are communicating with the correct party? This is an authentication problem. For example, in Figure 7.12, it is assumed that Alice has Bob’s public key. On the one hand, this should not be an issue because Bob’s public key is public and can be posted online or sent to Alice. But, on the other hand, how does Alice know for sure that she actually has Bob’s public key and not someone else’s? What if Mallory sent Alice her public key and claimed that it was Bob’s public key? How would Alice know the difference between Mallory’s public key and Bob’s? This is called the key binding problem. The key binding problem involves tying an identity to a public key. If it is not addressed, public key cryptography is vulnerable to impersonation and man-in-the-middle attacks. In a man-in-the-middle attack, a malicious actor undetectably intercepts all the messages sent in both directions between the communicating parties. As an example, when Bob sends Alice his public key over an untrusted channel, Mallory intercepts Bob’s public key and forwards her own public key to Alice instead, claiming it is Bob’s. Alice accepts Mallory’s key as Bob’s, and encrypts her message to Bob using Mallory’s public key and sends her message to Bob. Mallory intercepts the encrypted return message, and since she has the corresponding private key, decrypts it, reads it, and potentially modifies it before re-encrypting it using Bob’s public key and forwarding it to him. Bob decrypts the message with his private key not realizing it was actually sent to him by Mallory, not Alice. The key binding problem is solved on the Internet with a system called the public key infrastructure (PKI). The PKI is a trust hierarchy that uses signed certificates to bind keys to real-life identities. In order to bind a public key to a real-life identity, public keys are presented to a certificate authority (CA). A CA is a third-party that is trusted to verify real-life identities. Once the CA verifies the identity, it uses its private key to sign a public key certificate tying the identity to the public key. As long as the CA is trusted,
RkJQdWJsaXNoZXIy MTM4ODY=