Top 3 Encryption Myths
Misconceptions of encryption keep us from obtaining the full range of benefits it offers.
- By Roberta Bragg
- February 01, 2005
Networks utilize encryption in many ways: during user authentication, to keep data confidential, to guarantee the integrity of information and to ensure non-repudiation. In fact, we now use encryption so much that like significant others and a steady paycheck, we take it for granted—until the protection it offers disappears.
As it's grown, various myths have grown up around it. These misconceptions keep us from obtaining the full range of benefits encryption offers. They also can cause us to use the wrong tool for the job, misconfigure the tool and jeopardize our business because we think critical and sensitive data is secure when it's not.
Myth 1: Encryption
Equals Integrity
Many products implement both encryption and integrity, and cryptographic algorithms are used to guarantee integrity. But encryption is the process of scrambling data so that it can't be unscrambled without access to a key and knowledge of the algorithm. It does not guarantee that the data hasn't changed; only that it's been kept private. Only those with access to the right key can unscramble the data.
Cryptographic hash functions, digital signatures and message authentication codes are used to guarantee integrity. You might be tempted—in fact, many intelligent and knowledgeable administrators have made this error—to think encryption alone can guarantee integrity. After all, if only those with access to the right key can decrypt the data, how can someone tamper with or change it? Think a minute and you will realize there are at least two situations where the data can be changed.
First, even though the data is scrambled and impossible to decode without the key, data is still a stream of bits. If a hacker can capture the encrypted data, he can inject bits in to it, in essence changing some 1s to 0s or vice-versa. Bingo, the data is changed.
But when the data is unscrambled by the intended recipient, won't it be obvious that it's been changed? Perhaps, but what if the hacker knows the data is composed of well-defined fields? If bits are injected into the appropriate fields—for example, the one that tells your broker how much to invest in ABC Company—said hacker might get him to do the wrong thing. In this case, the bad guy doesn't care what the original message said; he just wants to make the message received say something different.
Second, if the information in an e-mail can be changed, it doesn't matter what the original e-mail said or if an attacker can determine its contents. What matters is that the recipient gets the altered message and thinks it's information sent by the original writer. By intercepting a message from your boss, an attacker could rewrite it and tell you you're fired, or to not show up for the business meeting in Atlanta. You get the picture.
The lesson is clear: For both
confidentiality and integrity, you must incorporate both encryption and integrity algorithms.
Myth 2: Checksums Protect Data During Transport
Early digital communication systems needed a way to determine if the data received was the data sent—in other words, ensure its integrity. Solving this problem involved using simple checksums produced by a type of hash algorithm called a cyclic redundancy check (CRC).
Hash algorithms produce small integers from variable-sized blocks of data. The same algorithm used over a different set of data will produce a different result and the same algorithm used over the same set of data will always produce the same result. A checksum is then calculated for each packet's data payload, and sent with the data. Once received, a new checksum, calculated anew over the data, can be compared to the one sent with the data. If the two values match, the data hasn't changed. If the two values don't match, the data has been changed.
Checksums might seem an answer to whether data's been modified during transit, but they're not a good solution.
Checksums were designed to deal with potential data corruption, not malicious action; thus, they can easily be compromised. If a hacker wants to trick you into believing the data hasn't changed, he can merely calculate a new checksum over his version of the data and send both changed data and his checksum on to you.
To prevent malfeasance and ensure integrity, cryptographic algorithms such as cryptographic hashes, message authentication codes (MACs) and
digital signatures have become part of our secure communications toolbox. These functions are typically one-way functions, meaning that they can't be decrypted even with knowledge of the key. "Security Integrity Algorithms" defines these more secure integrity techniques.
Typically you don't get to choose which integrity algorithm is used, but you do get to choose the product. When evaluating the security of products, it's important to know the type of integrity algorithm utilized.
| Secure Integrity Algorithms |
| Message Authentication Code (MAC) |
| Checksums are derived using a secret key. The same key is used by the recipient to produce a second MAC for comparison with the first. Therefore, only the intended recipient (who possesses a copy of the key), can verify the integrity of the message. Because the key can be unique to the sender, a MAC can also provide authentication. A MAC derived from a block cipher is DES CBC-MAC. |
| Hash |
| An algorithm that converts a message of any length into a unique fixed-length string of digits. It's often referred to as a "message digest." A hash function will not produce the same result given two different inputs. When the
algorithm includes the use of a key, the integrity of the data can be guaranteed if the key is kept secret. Because a hash is a one-way function, it is often used to obscure sensitive data in a database or file, like passwords. The LAN Manager (LM) hash and its latter, more secure versions known as NTLM and NTLMv2 are used to
protect Windows passwords. |
| HMAC |
| A type of MAC that uses a hash
function and a key. MD5 and SHA1 are examples of HMACs. You can select either when configuring integrity for IPSec policies. HMACs are used to protect the integrity of schannel communications, which are secured communications such as secure socket layers (SSL) or transport layer security (TLS). The
algorithm used is based on the cipher-specific communication program choice. |
| Digital Signature |
| Uses a public/private key pair.
The sender uses his private key to encrypt a message digest of the message. The receiver creates his own message digest, uses the sender's public key to decrypt the message digest, then compares both results. If the results match, the
message is authenticated and there's proof of integrity. Because the public key can be utilized by anyone,
however (unlike the secret key used in a MAC), anyone can verify that the message is authenticated and its integrity is intact. Digital signatures are used in e-mail. |
Myth 3: SSL Only Secures
Data Between a Browser and a Web Site
Secure Socket Layers (SSL) is used to protect communications between Web sites and Web browsers. Most of us think nothing about making purchases on the Internet as long as sites use SSL, and many of us are quite comfortable implementing SSL by adding an SSL certificate to a Web site. However, most users and implementers of SSL don't realize that there's another important reason for using SSL, and that it's more than a solution for e-commerce.
It's critical to understand that SSL protects more than the private data sent between browsers and Web sites; because the SSL certificate can be verified as belonging to the organization represented by the Web site, it can prove that the Web site the browser connects to truly belongs to the purported owner. This is assured because the server presents a certificate that has been digitally signed by a trusted public certificate authority (CA) like VeriSign.
Without this check, it might be possible to trick users into sending credit card information to a spoofed site. (Of course, even with this check, warnings of certificate problems can be ignored by users by clicking Yes, as shown in Figure 1).
 |
Figure 1. Certificate warnings shouldn’t be ignored by
clicking Yes. |
SSL is also used to authenticate and protect communications between non-commercial Web sites and Web browsers, between Web sites and firewalls, and between Web sites and back-end databases.
Additionally, monetary transactions aren't the only types of communications for which SSL can provide protection. You might like to know, for example, that you really are reading laws, federal tax codes and city ordinances from an appropriate government site.
SSL is not just a solution for server authentication, either: It can also be used to authenticate clients. To
implement this type of mutual authentication, all clients must have their own certificate and the Web server must be configured to require client authentication. This is the
perfect solution, for example, for ensuring that just-authorized users can connect using Outlook Web Access (OWA).
When the OWA server is configured to use SSL, configure it to require the use of SSL by both servers and clients. This will ensure that users are not only connecting to an authorized OWA server for your organization, but also that only users to whom you have issued client certificates can get their mail via OWA. All communications between the client and the server will be encrypted.
Encryption is a sound choice for protecting communications and data at rest. However, if you can't distinguish between myth and reality you won't be able to take advantage of the many benefits of encryption. The even more dangerous result is that you'll be living with a sense of false security.