Think for a moment about the security guarantees that two peers get when communicating using symmetric-key systems like Kerberos, or even SSL (where the actual messages themselves are protected using symmetric keys).
Let's imagine Alice sends a message to Bob, and her message is signed[1] then encrypted using symmetric keys that Alice and Bob share. Who can read the message once it's encrypted? Only Alice and Bob. Who can verify Alice's signature? Only Alice and Bob. This last point is important.
“Signatures“ formed with a shared (symmetric) key can only be validated by someone who knows the key. Later on, Alice can repudiate her message, “Bob, I never sent that message, you're trying to set me up!“ and Bob has no recourse - an independent adjudicator would simply look at the message and say, “How do I know who actually signed that message, Bob? Both you and Alice knew the signing key!“ For this reason, cryptographers carefully distinguish message authentication codes from digital signatures, but in most Web Service security scenarios, the terminology is rather muddied. XML Signatures can be formed not only with private keys, but also with shared keys (in which case the “Signature“ is really just a MAC).
On the other hand, if Alice and Bob use an asymmetric-key system, Alice would sign the message with her private key, and Bob (and anyone else, including the adjudicator from my last example) can verify the signature. Thus Bob gains some measure of “nonrepudiation“. But interestingly enough, Bob also may be losing a security guarantee. Systems that sign and encrypt with asymmetric keys are often subject to an attack called “surreptitious forwarding“.
In order to understand this attack, and the implications for Bob's peace of mind, put yourself in Bob's shoes when he receives a message that was first signed with Alice's private key then encrypted with Bob's public key. Bob decrypts the message, verifies the signature, and what does he know? Alice's signature was intact, so surely she signed the message, but has anyone else seen the plaintext? And was the message really addressed to him? If Alice didn't explicitly include “To: Bob“ in the message, how does Bob know that this message really came from Alice?
Consider this scenario: Alice signs the message, “I love you“, encrypts it with Chris's public key, and sends it to Chris. She loves Chris and wants to let him know. Chris, the villian in this story, decrypts the message, and decides to set up Bob for some embarrassment by reencrypting it with Bob's public key and sending it to Bob. When Bob receives “I love you“, signed by Alice and encrypted so only he can read it, he will very likely be fooled! Now, if Alice had thought ahead and instead signed the message, “Chris, I love you“, this “surreptitious forwarding“ attack would have been prevented.
There seems to be a common misconception that asymmetric cryptosystems are somehow better or more secure than symmetric cryptosystems, but this example shows that of course this is not true; you have to be very careful designing any type of cryptosystem. I'm glad there are people much smarter than I am doing this sort of thing!
Soooo, what does this have to do with anything? One interesting place where these ideas are applied is in WS-Security implementations. If you've ever used WSE to secure a web service, you may have wondered why all those headers are included in the XML signature and not just the body of the message itself. In particular, the WS-Addressing header - why would the sender take the time to sign that? Well, now you know at least one reason why that fragment is signed. That's the equivalent of including “To: Bob“ as part of the signed message. It helps prevent surreptitious forwarding.
If you're interested in learning more about challenges in building cryptosystems, my favorite book by far is Practical Cryptography. And for an in-depth look at surreptitious forwarding and the myriad of protocols that are susceptible to it, read Don Davis's paper on the topic. Don's point is that many toolkits (and protocols) don't bother to protect against this attack because they assume the user will be aware of the problem. I think he'd be happy with the WSE and Indigo implementations that implicitly protect against this attack by including the recipient information in signatures automatically.
[1] more correctly, the message is protected with a message authentication code (MAC), which you can learn more about here.
Posted
Aug 21 2005, 11:36 AM
by
keith-brown