Security Watch

Encryption Does Not Equal Integrity

Intercepted e-mail can become he-said-she-said without you knowing it.

• By Roberta Bragg
• 10/18/2004

Then everyone got into the act. It seemed like everyone knew lots about everything, security-wise. Who needs an evangelist when everyone goes to church?

Recently however, I've discovered a big secret. Some of those people preaching security have their definitions confused. Now, I'm not talking about differences of opinion. It's true that in the information security field we sometimes have different definitions for the same thing or disagree on terminology. For example, you may say certificate authority, while others say certification authority. You may believe that a VPN means encryption; I say, strictly speaking, a VPN is a tunnel that may or may not be encrypted. In the former example it's more a naming issue; for the VPN, it could get you into trouble if you think your data is encrypted when it's not.

Please understand that encryption does not mean integrity. Just because the data is encrypted before being sent doesn't guarantee it doesn't change before it's delivered. You might think it's so, and it's easy to see why. After all, if you can't unscramble the encrypted message, how can you change it to say something else?

Let me give you an example of how you can, using my friends Alice, Bob and Chester. Alice wants to send a confidential message to Bob. Fortunately, they both work for the Acme Roadrunner Delivery Company. Acme has installed Microsoft PKI, so Alice uses Outlook to compose and send an encrypted message to Bob. Behind the scenes, the e-mail is encrypted with a secret key; the key is encrypted using Bob's public key and sent with the message. When Bob receives the e-mail, his private key is used to decrypt the secret key and the secret key is used to decrypt the message. Because Bob is the only one who has access to his private key, he's the only one who can read the message Alice sent.

The question is, does the message say what Alice wrote before she sent the message? Here's where Chester comes in. Chester also works for Acme. Because Bob's public key is, well, public, Chester can also use it to send an encrypted message to Bob. The message will be identified as coming from Chester.

But what if Chester intercepts Alice's message and replaces the message part of her e-mail with the message part of the e-mail he composed, then sends this altered message to Bob? Chester can't read the message Alice sent, but that doesn't matter. The message Bob receives can be decrypted by Bob; thus, Bob gets the message that Chester sent, not the one Alice sent, although he thinks it's from her.

Now, imagine the havoc Chester could cause. Then substitute some interesting public personalities for our little trio.

Note that I've made this sound easier than it is, but that's not important. What's important is that it could happen, and public key/private key cryptography is not the only encryption technology subject to this type of attack. My point is this: Encryption does not guarantee integrity. We need to use other cryptographic tools such as digital signatures or specific integrity algorithms, such as SHA1.

So maybe you don't have a Chester working for you and you feel this is a very unlikely scenario. That doesn't matter. In your organization you may decide that the risk of such an attack is low enough that you don't need to add integrity checks to your e-mail. But you should still be clear on the difference between encryption, scrambling (which keeps information confidential) and integrity (which guarantees that data remains the same). Someday it might make a difference.