Minasi Talks ... Encryption

Any security system relies, at least in part, on encryption. However, there are right ways and wrong ways to use encryption. To encrypt a block of data, you need two ingredients (in addition to the data itself): an encryption algorithm and a randomly generated, well protected cryptographic key. Inattention to either or both of those details has led to the downfall of some past security schemes and so provides a cautionary tale or two.

The first lesson of encryption systems is, "Don't use proprietary encryption algorithms; use standard, well understood algorithms." That sounds non-intuitive: Wouldn't an encryption algorithm built in the bowels of some obscure laboratory by a small cadre of mathematical geniuses who are sworn to secrecy turn out the most uncrackable encryption method? You might think so, but history surely hasn't borne that out. For example, Microsoft needed an encryption method for its VPN software years ago and so developed a proprietary encryption algorithm which it included in its Point-to-Point Tunneling Protocol (PPTP) software, which proved vulnerable to attack in fairly short order. In contrast, consider that Windows' LAN Manager (LM) authentication protocol is roughly 20 years old, and although it's clearly computationally crackable at this point, it did stand the test of 20 years' use and is still extant in most networks. Much of that longevity must be attributed to the fact that the LM authentication system relies heavily upon a publicly designed standard encryption method called the Data Encryption Standard. DES has a successor in the newer, more secure Advanced Encryption Standard (AES), so look for that in encryption solutions. It, too, will eventually fall victim to Moore's Law, but with hope that won't happen for a decade or two.

The second lesson of encryption systems, is "Pick a key that can't be easily guessed, and figure out a good place to hide the cryptographic key." To illustrate that point, I ask you to consider Microsoft's Encrypting File System. EFS offers a convenient and fairly transparent way to protect files on a Windows 2008/Vista/2003/XP/2000 system. It's built atop AES and uses fairly long (256-bit as opposed to DES's 56 bits) cryptographic keys. People have, however, tried to attack it via its key-generation and -storage methods. The first time you tell Windows to encrypt a file, EFS spins up a random number to use as your EFS encryption key from that time on. But how did Windows create that "random" number? When EFS appeared in Win2K, some people claimed that Microsoft's method of generating nearly random numbers generates numbers in only a small, predictable range. I've never seen actual proof of that, but if it had been true, EFS would have been useless and such guess-the-key attacks have been successful on other cryptographic systems in the past.

More fruitful attacks on EFS rely upon finding the key itself. When you start your computer and try to read an encrypted file, Windows has the AES decryption code on hand and the encrypted data right on the hard disk—but where's the key? Clearly, Windows can't just plop the key right onto the hard disk. That would be too easy to attack, right? So, where else might it go? Actually, there really isn't anywhere else convenient to put the key. Most of us aren't really willing to type in a long cryptographic key at the keyboard, or to carry around a USB stick that holds the key and insert that stick whenever we want to encrypt or decrypt something.

Actually (and I'm greatly simplifying here), Windows gives you three choices: Type in a key every time you boot, store the key on a floppy disk, or, yes, let Windows hide it on the hard disk. Most of us opt for the third choice (it's the default), and so over the years, bad guys have figured out how to find the key's location, rendering EFS useless. But all is not lost, as a growing number of computers ship with something called a Trusted Platform Module (TPM) chip. TPM has just one job—to store keys—and so most TPM-equipped systems come with software that will store and protect EFS keys. Thus, with the mix of a good algorithm (AES), a good random-number generator, and a bit of hardware help in storing its keys, EFS represents an example of fairly good encryption. There are many others on the market, of course, but in the end analysis, they all succeed or fail on the same criteria.

End of Article

Mark, you say "Most of us opt for the third choice (it's the default), and so over the years, bad guys have figured out how to find the key's location, rendering EFS useless."
Please give us real cases where the bad guys accessed the EFS-secured files.

muraty April 29, 2008 (Article Rating:

)

From Mark Minasi:

I got that from Steve Riley at Microsoft – he’d be the guy to know and wouldn’t have any reason to discuss a nonexistent vulnerability. Thanks for reading!

Jason Bovberg May 21, 2008 (Article Rating:

)

You must log on before posting a comment.

If you don't have a username & password, please register now.