Exchanging Private Keys– Cisco Security Tools
Protocol designers combine the best aspects of public and private key cryptography to create secure transport protocols.
Figure 20-12 illustrates how these protocols use these two forms of cryptography.
Figure 20-12 Combining Public and Private Key Cryptography
1. The sender creates a key for a public key cipher, split into public and private keys. The sender stores the private key securely.
2. The sender publishes the public key to a server on the Internet, through DNS, etc. The receiver finds this public key and stores it locally.
3. The sender creates a secret key, stores it securely, and uses the private key to encrypt the secret key.
4. The sender transmits the encrypted secret key as cipher text to the receiver.
5. The receiver uses the sender’s public key and a cipher to recover the private key. The receiver securely stores this secret key, often called a session key.
6. The sender uses the secret key and cipher to convert clear text to cipher text.
7. The sender transmits the cipher text over the network to the receiver.
8. The receiver uses the secret key and cipher to recover the original clear text.
Secure transports often include anti-replay protections in this kind of key exchange.
Replay attacks are when an attacker captures and replays packets off the network. These attacks can be used to access a protected system or cause an action (such as a bank transfer) to happen more than once.
Cryptographic Signatures
Public key cryptography is also widely used to create cryptographic signatures or cryptographic hashes. Figure 20-13 illustrates.
Figure 20-13 Cryptographic Signatures
1. The sender creates a key, which is divided into public and private keys.
2. The sender publishes the public key through a website, DNS, etc. The receiver retrieves this key.
3. The sender uses the private key and cipher to create a cryptographic hash.
4. The sender transmits this signature across the network to the receiver. The receiver stores this as Signature (R).
5 The sender transmits the original data, in clear text (not encrypted), across the network to the receiver.
6 The receiver uses the public key and cipher to create a signature for the clear text, calling it Signature (L).
7. The receiver compares the local and remote cryptographic hashes. If they match, the signature is valid.
This process might seem like a lot of work to carry data across a network. If you are going to build a hash of the data, why not just encrypt the data? Because:
• Public key cryptography is computationally expensive for large volumes of data.
• Sometimes you want anyone to be able to read or see data, but you want those who are interested to be able to verify the data they receive is what you sent. For instance, you want anyone to be able to read your emails, but you also want the recipient to know—for certain—the email they are reading is what you sent.
• Sometimes you want anyone to be able to read or see data, but you want everyone to be able to verify you sent it. For instance, anyone should be able to read a legal document, but signers should not be able to claim they did not sign it.
• Sometimes you do not want to store the original data, but you do want to verify the data you have is the same as some future copy of the same data. For instance, you do not want to store users’ passwords. Instead, you want to store cryptographic hashes of each user’s password, which you can compare to
passwords they enter later.
Cryptographic hashes are repeatable signatures across a piece of data. These hashes are repeatable, but they cannot be unencrypted.
These use cases are critical in real-world uses of cryptography, specifically:
• Authentication is ensuring a person is who they claim to be.
• Validation is ensuring data has not changed from what the sender transmitted.
• Nonrepudiation is ensuring someone cannot claim they did not sign or send something.