On Shifting “Windows” and “Security” from Less Antonymous to More Synonymous

(Page 5)

A Poor Man and His Elephant

Don't worry. We're still talking about cryptography here, but don't feel bad if you had sudden thoughts of weathered behemoths with ivory headlights in Amboseli, or a fellow who's a few bucks short. You'll see where I'm going with this, in a little while. Until then, let's take a look at BitLocker's guts. This implies that Microsoft has done a great job at documenting the preliminary analytical summary of BitLocker, and thanks to Niels Ferguson, this is case. Thanks, Niels.

Okay, so what is it? At its core, BitLocker is how Vista (at least Enterprise and Ultimate editions, for the time being) encrypts all system volume data. This sounds like a commonplace application, until you consider the constraints. Since BitLocker encrypts data at the per-sector level, and the ciphertext cannot exceed the length of the plaintext, this leaves no breathing for anything else – nonce, IV, and MAC, to be exact. Y'all might know how I feel about MACs, and if you've skimmed through a copy of Practical Cryptography, you'll see how Niels feels about them as well. Fortunately, I saw this coming. I realized the likelihood for such tight constraints and the conditions they would impose, and I knew that somehow, some way, message authentication would be addressed. I mean, c'mon, authentication is the Orville to encryption's Wilbur; without both, it's not going to fly.

BitLocker invests in what is called poor-man's authentication. The compromise isn't as conservative as you'd usually want to be, since it assumes that manipulated ciphertext doesn't result in meaningful plaintext; in other words, should ciphertext be manipulated, it should, for example, cause the system to crash, rather than be a controlled change that allows the adversary to carry out some desired function. Niels and Co. knew that an entirely new block cipher would require more time to analyze than is acceptable, but existing designs that were kosher enough, security wise, either hadn't been analyzed well enough yet, or couldn't pass the efficiency muster. So, for encryption, they chose AES in CBC mode, which is IND-CPA secure (i.e., indistinguishability under chosen-plaintext attacks), but does not preserve integrity. That's okay; we can use a M . . . uh oh. There's no room for a MAC, and CBC is a mode of confidentiality, so there's no integrity preservation at all. It's time to call in the elephant.

< 1 2 3 4 5 6 7 8 >