|Previous||Table of Contents||Next|
Resending the Message as a Receipt
Consider an implementation of this protocol, with the additional feature of confirmation messages. Whenever Bob receives a message, he returns it as a confirmation of receipt.
If the same algorithm is used for both encryption and digital-signature verification there is a possible attack . In these cases, the digital signature operation is the inverse of the encryption operation: VX = EX and SX = DX.
Assume that Mallory is a legitimate system user with his own public and private key. Now, lets watch as he reads Bobs mail. First, he records Alices message to Bob in step (1). Then, at some later time, he sends that message to Bob, claiming that it came from him (Mallory). Bob thinks that it is a legitimate message from Mallory, so he decrypts the message with his private key and then tries to verify Mallorys signature by decrypting it with Mallorys public key. The resultant message, which is pure gibberish, is:
Even so, Bob goes on with the protocol and sends Mallory a receipt:
Now, all Mallory has to do is decrypt the message with his private key, encrypt it with Bobs public key, decrypt it again with his private key, and encrypt it with Alices public key. Voilà! Mallory has M.
It is not unreasonable to imagine that Bob may automatically send Mallory a receipt. This protocol may be embedded in his communications software, for example, and send receipts automatically. It is this willingness to acknowledge the receipt of gibberish that creates the insecurity. If Bob checked the message for comprehensibility before sending a receipt, he could avoid this security problem.
There are enhancements to this attack that allow Mallory to send Bob a different message from the one he eavesdropped on. Never sign arbitrary messages from other people or decrypt arbitrary messages and give the results to other people.
Foiling the Resend Attack
The attack just described works because the encrypting operation is the same as the signature-verifying operation and the decryption operation is the same as the signature operation. A secure protocol would use even a slightly different operation for encryption and digital signatures. Using different keys for each operation solves the problem, as does using different algorithms for each operation; as do timestamps, which make the incoming message and the outgoing message different; as do digital signatures with one-way hash functions (see Section 2.6).
In general, then, the following protocol is secure as the public-key algorithm used:
Attacks against Public-Key Cryptography
In all these public-key cryptography protocols, I glossed over how Alice gets Bobs public key. Section 3.1 discusses this in detail, but it is worth mentioning here.
The easiest way to get someones public key is from a secure database somewhere. The database has to be public, so that anyone can get anyone elses public key. The database also has to be protected from write-access by anyone except Trent; otherwise Mallory could substitute any public key for Bobs. After he did that, Bob couldnt read messages addressed to him, but Mallory could.
Even if the public keys are stored in a secure database, Mallory could still substitute one for another during transmission. To prevent this, Trent can sign each public key with his own private key. Trent, when used in this manner, is often known as a Key Certification Authority or Key Distribution Center (KDC). In practical implementations, the KDC signs a compound message consisting of the users name, his public key, and any other important information about the user. This signed compound message is stored in the KDCs database. When Alice gets Bobs key, she verifies the KDCs signature to assure herself of the keys validity.
In the final analysis, this is not making things impossible for Mallory, only more difficult. Alice still has the KDCs public key stored somewhere. Mallory would have to substitute his own public key for that key, corrupt the database, and substitute his own keys for the valid keys (all signed with his private key as if he were the KDC), and then hes in business. But, even paper-based signatures can be forged if Mallory goes to enough trouble. Key exchange will be discussed in minute detail in Section 3.1.
Why even bother with random-number generation in a book on cryptography? Theres already a random-number generator built into most every compiler, a mere function call away. Why not use that? Unfortunately, those random-number generators are almost definitely not secure enough for cryptography, and probably not even very random. Most of them are embarrassingly bad.
|Previous||Table of Contents||Next|