Digital Signatures Long history of using physical signatures as proof of authorship or agreement with some document. Physical signatures have (to some degree) the following desirable characteristics, which help make them valuable A. A signature is authentic - its presence convinces a recipient of a document that the signer deliberately signed the document. Using pen and ink leaves a mark with characteristics that are hard to duplicate in any way other than with handwriting B. A signature is hard to forge - its presence is proof that a particular individual and no other signed the document. C. The signature is not reusable - it is part of a specific document, and cannot be moved to another. It is very hard to cut and paste real paper without leaving a trace. D. The signed document cannot be altered after signing Possibly the trickiest part of paper systems - maybe the typography is such that new words or lines cannot be added... E. The signature cannot be repudiated - after signing a document, the signer cannot convincingly claim that he did not sign it. It is a handwritten physical artifact. Somebody made it... We would like to obtain similar assurances with computer documents, but there are problems with the fact that files are trivial to make identical copies of, and almost as trivial to modify. The underlying physical medium gives no easy help here, since computer files generally move all over the place - from memory to disk to disk to disk to tape... ---------------------------------------------------------------------------- Digital signatures using symmetric cryptography and a trusted arbitrator. * Trent, the trusted arbitrator, shares secret keys Ka and Kb with Alice and Bob respectively. These keys are established before the transaction, have indefinite lifetime, and can be used for multiple transactions. * The following protocol allows Alice to send a signed message to Bob 1. Alice encrypts here message with Ka and sends it to Trent 2. Trent decrypts the message with Ka 3. Trent adds a statement that he has received this message from Alice, and encrypts the bundle, including Alice's encrypted version, with Kb. 4. Trent sends the bundle to Bob 5. Bob decrypts the message with Kb, and can now read both Alice's message, and Trent's certification. * Trent knows the original message is from Alice, because no one else has Ka. A message from anyone else claiming to be Alice will decrypt as garbage. Part of Trent's job is thus to make sure the message is sensible. * Bob knows that Trent (and not someone else) verified Alice sent the message because no one else has Kb * If Bob wants to (officially) show the signed document to Carol, he has to use Trent again 1. Bob takes the messages he received from Trent, adds a request that the signed document from Alice be shown to Carol, encrypts the bunch with Kb, and sends it to Trent. (This added request inside the encryption ensures that it is not Eve, with a saved copy of the message Trent originally sent to Bob asking for the copy to be sent to Carol who might actually be Eve...) 2. Trent decrypts with Kb 3. Trent checks that the document matches Alice's original, either from a database, or by checking the encrypted original returned by Bob 4. Trent encrypts the bundle with Kc - the key he shares with Carol, and sends it to Carol. 5. Carol decrypts the lot, and now has Alice's message certified by Trent, sent to her by Bob. * In more detail, we can look at how this scheme meets our requirements for signatures. A. Authenticity: Bob knows the message came from Trent, who is the only one with Bob's secret key, so the message is authentic. Trent knows the message came from Alice, and (as far as Bob is concerned) the received certification is proof of that. B. Unforgeability: Only Alice (or Trent, but he is trusted) could have sent Trent the encrypted document, so no third party can get a document certified by Trent to be Alice into Bobs hands. C. Non-reusability: If Bob takes Trents certification and attaches it to another document, and tells Alice (or anybody) she signed it, Alice can demand that Bob produce her original encrypted version, and then ask an adjudicator (Trent or someone else) to verify that the encrypted version decrypts to what Bob say it does. D. The signed document can't be altered. If it were Trent, or any other trusted adjudicator with Alice's key could prove it as above. (And anyone looking at such a document should demand proof from Trent before believing it) E. Non-repudiation: If Alice claims she did not send the message, Trent can say otherwise. Of course, Alice might claim that her private key was stolen, but that is another kettle of fish... * All this works, but Trent is a bottleneck and a vulnerability. He does a lot of work, and if he ever made even one mistake, his trust would be severely compromised. He may have to maintain a message database (avoidable if Ka encrypted versions of Alice's message are sent with it, but that might reduce the security of Ka over time, as an adversary could use this as a mechanism to mount a chosen plaintext attack). If Trent's database of secret keys is ever compromised, the result would be total disaster. So some better mechanism would be very popular... Digital signatures using public key cryptography. When using RSA for secret communication, the public key is generally used for encryption, and the private key for decryption. However, since encryption and decryption are performed by raising the text and ciphertext to an ecryption power or its inverse mod n = pq, the decryption key can just as easily be used as an encryption key, and the encryption key as a decryption key. Alice can thus sign a document for Bob as follows: 1. Alice encrypts a document using her private key, thus signing it. 2. Alice sends the signed document to Bob 3. Bob verifies the signature by decrypting with Alice's public key. Here the only need for Trent is to certify Alice's public key Checking desired properties: A. Authenticity: Alice's public key decrypts the message, therefor it was signed with her private key B. Unforgeability: Only Alice has her private key, so only Alice could have signed it. C. Non-reusability: The signature is the encryption of the document. Any other document would have a different encryption, so the signature is non-transferable. Further, it is easy for Bob to show the signature to anyone, and they can verify themselves that Alice signed it by looking up Alice's public key. D. By the same token the document cannot be altered, since the signature would decrypt to the original document, and Bob has no way of figuring out what the encryption would be for an altered message. E. Alice cannot easily say she did not sign the document, since only Alice is supposed to have her private key. However, she can always conveniently "lose" her private key... There are actually a couple of ways Bob could try to cheat Alice 1. If the document was something like a check, or authorization of funds transfer, Bob cold try to reuse the entire document at a later date. To prevent this, such messages are ofter "Timestamped" with a time value that, together with account information etc., forms a unique ID for the message. A bank would keep a record of transfers, and allow only one with a given timestamp. 2. If block-by-block, Electronic Codebook Mode (ECM) is used, Bob can potentially piece together a new message by reusing pieces of old ones, especially if he sent the original contracts for Alice to sign, and arranged the block boundaries for his convenience. This can be avoided by using a block-chaining mode for encryption. Public key cryptography is a relatively slow process. To increase efficiency, and to guard against certain types of man-in-the-middle attacks against encrypted messages, one-way hash functions are often incorporated into the protocol 1. Alice produces a one-way hash of the document she wishes to sign. The hash function is publicly known. 2. Alice encrypts the hash value with her private key. 3. Alice sends the encrypted hash value AND the document to Bob 4. Bob produces a one-way hash of the document using the same publicly known hash function 5. Bob decrypts Alice's hash using her public key, and verifies that it matches his hash. Since the probability of any other document producing the same hash is safely small, and a document cannot be modified to produce the same hash, this effectively verifies Alice's signature. Other benefits * The signature is separate from the document, and can be stored separately * The existence of documents at a certain date can be verified efficiently by an archive of timestamped signatures without any need to archive the entire document. * Alice can sign documents that are not revealed until later (e.g. a will) Proposed use in nuclear test ban treaty: Sealed seismographs in foreign country sign data before it is sent. Host country can read, but not alter the data sent out. Digital signature with encryption: The following protocol allows a signed message to be encrypted 1. Alice signs a document with her private key 2. Alice encrypts the message and signature with Bob's public key and sends it to Bob 3. Bob decrypts the message with his private key 4. Bob verifies Alice's message with Alice's public key. Note that the signature operation occurs BEFORE the final encryption. This is good policy, as in general, it is a bad idea to sign something you cannot read. There are various other public-key signature schemes (e.g. DSA). Some cannot be used (directly at least) for encryption. However, all public key systems stll have the notion of a private (signing) key, and a public (verifying) key. Key distribution: How does Bob get Alice's public key? * Calls up a secure database a Key Distribution Center (KDC) that no-one but Trent can write to. * Keys in database can be signed by Trent with a private key to prevent Mallory from substituting some arbitrary key for Alice's during transmission. The signed response would incorporate both Alice's key and some identification, e.g. "Alice's key is 12345. Signed Trent, h(kdk%N38LKdsf)kiD87&" (of course he could still substitute another signed key in the database, e.g. his own, but this leaves a trail that points to Mallory or some cohort if Bob is paying attention * Of course Bob still needs Trent's public key, and his copy could conceivably be corrupted by Mallory, but this does makes life more difficult for Mallory. ----------------------------------------------------------------------- Key exchange Protocols: Use of a "session key" - a key used only for a particular conversation or communication session - is a common cryptographic technique. Central issue is how to securely get session key into the hands of the participants - the "key exchange" problem Key Exchange with symmetric cryptography Assumes Alice and Bob each share a secret key with Trent (who operates as the Key Distribution Center) Distribution and security of these keys is, in itself, a significant problem. 1. Alice contacts Trent and requests a session key to communicate with Bob 2. Trent generates a random key, encrypts one copy using Alice's secret key, and the other using Bob's, and sends both to Alice. 3. Alice decrypts her copy of the session key. 4. Alice sends Bob his copy of the session key. 5. Bob decrypts his copy of the session key. 6. Alice and Bob use the session key to communicate. Issues: * Basic security is that Eve can't make use of the key since she can't decrypt either copy. * Trent is a focal weak point. If Mallory corrupts him, the entire network, and all messages ever sent are potentially compromised. * Trent is a bottleneck. Key exchange with public key cryptography 1. Alice gets Bob's public key from Bob or Trent 2. Alice generates a random session key, encrypts it with Bob's public key, and sends it to Bob. 3. Bob decrypts the session key using his private key. 4. Alice and Bob use the session key to communicate. Issues: * Avoids problems with establishing and securing secret keys with Trent. * Even if Mallory gets write access to Trent, all he can do is substitute another key for Bob, and Bob is likely to notice if Alice, or someone else sends him information supposedly encrypted with his public key that decrypts to gibberish. Mallory has to stay much more on his toes not to be detected. * Mallory can mount a "man in the middle" attack on this protocol, and other direct public-key protocols, especially if Alice and Bob exchange public keys directly. 1. When Alice asks Bob (or Trent) for Bob's public key, Mallory intercepts the return message and sends Alice his own public key. 2. Mallory pulls the same switch on Bob - giving Bob his own key instead of Alice's. Note that Mallory now has both Alice's and Bob's public keys (but they are public so presumably he coud get them anyway) Or if Mallory is really talented, maybe he breaks into Trent and substitutes his own key for both Alice and Bob (though this is likely to be detected as mentioned above...) 3. When Alice sends a message to Bob, Mallory decodes it, since it is really in Mallory's key, reads it, re-encrypts it with Bob's public key, and sends it on. 4. Mallory does the same for any communication going the other way. # Man in the middle attacks can be hindered by using an "interlock protocol" (Rivest and Shamir of RSA). 1. Alice and Bob obtain each other's public keys, either by communicating with each other, or from Trent. 2. Alice encrypts her message using Bob's public key. she sends an undecipherable half of it (e.g. every other bit) to Bob. 3. When Bob gets the first half of Alice's message, he encrypts, using Alice' public key, some identifying acknowledgment, which would include any material he knows a-priori that Alice wants, and sends half of it to Alice. 4. When this get back to Alice, she sends the rest of her message. 5. Bob puts the two halves of Alice's message together, decrypts it with his private key, (reads it), and sends the rest of his acknowledgement to Alice. He can also encrypt and send the first half of any response that depends on Alice's message. 6. Alice puts together Bob's response, decrypts it using her private key, and reads it. If Bob is continuing the conversation, she encrypts and sends the first half of her next message. And so forth. Issues: * "message halves" could also be a verification string such as a one-way hash of the message to follow sent as the first half, or an enabler such as an initialization vector for decryption sent as the second half. * Conversations are a little tricky for Alice and Bob, as they must respond to messages they haven't yet been able to read, so there might be a bit of stuff like "OK, I got the first part of your message". * Things are even tougher for Mallory though, since he must blindly fabricate the messages he retransmits to Bob and Alice, and they will not match what Bob and Alice actually send. This is liable to get him detected. # Mallory also has problems if Alice and Bob are getting each other's public keys from a key server Trent, and Trent has signed them. Mallory can substitute his own key, but it is signed as belonging to Mallory or a cohort, not Alice or Bob, and would be noticed if Alice and Bob were paying attention. * Mallory could break into Trent, get his private key, create bogus new signed keys for Alice and Bob, and then manipulate them into using them, but this is getting to be a lot of trouble. * Mallory could pretend to be Alice from the beginning, establish a dialogue with Bob, and possibly get information that Bob would give to Alice, but not Mallory. Might be detected later, but the damage could be done. # Key and Message Transmission: Bob and Alice don't actually have to have any dialogue to use a session key. Alice can do it unilaterally. 1. Alice generates a random session key and encrypts her message to Bob with it. 2. Alice gets Bob's public key from Trent. 3. Alice encrypts the session key using Bob's public key. 4. Alice sends the (session-key) encrypted message, and the (public-key) encrypted session key to Bob. If Alice wants some extra security against Mallory, she can sign the whole package, an unusual case of signing after encryption. Now Mallory has not only to foist a bogus Bob key on Alice, but a bogus Alice key on Bob. 5. Bob decrypts the session key using his private key 6. Bob decrypts the message using the recovered session key. This is how public-key cryptography most commonly works in a communication system.