Security WatchBitLocker and the Complexities of Trust

Justin Troutman

Windows Vista. I have not uttered those two words in an article before, which is why writing this column makes me feel like a five-year-old with a blank check walking into a toy store. There are so many features to talk about, so much real estate worth exploring, and so many possible avenues a discussion can take.

A while back, I was reading security guru Bruce Schneier's blog and I came across an entry about something that was new to me at the time—BitLocker™. I quickly gleaned that this was intended to provide cryptographic functionality in Windows Vista®—and immediately cringed, "Oh no. Windows Vista is doing cryptography? It can't be any good. And even if it does a decent job, there's gotta be a back door somewhere."

There are some historical arguments (valid or not) as to why one might hesitate to rely on security features built into Windows®. But that's not why I'm writing this column. Instead, I'd like to build a case detailing why I believe there are sound reasons for giving BitLocker a chance. I also want to toss in a few cents on the kind of philosophy that ensures the vitality of cryptographic software and hardware.

But make no mistake: I'm not proposing BitLocker as a panacea for security as a whole—BitLocker is just one of the many pieces of the security puzzle. Its goal is to provide resiliency under certain threat models.

In particular, BitLocker sets its sights on the lost (or stolen) laptop. Mobile workers are constantly toting all sorts of confidential information all over the place—trains and planes, restaurants and hotels, home offices and branch offices. And they're carrying this information on laptops and other mobile devices that typically lack any real security, leaving the data on them extremely vulnerable. So what happens to this data when one of your users leaves a laptop somewhere?

You can't eliminate the sloppiness of human nature. Luckily, you can limit the mess that could ensue. The cost to a company for replacing a laptop is minor compared to the cost of dealing with confidential data that's been compromised. This is the security that BitLocker aims to provide.

Traversing the Credits

I'm discussing BitLocker here from an interesting perspective. You see, I haven't tried it yet. I know what you're probably thinking: how can some guy who hasn't even used BitLocker have an opinion about it, let alone anything useful to say on the subject? Bear with me please. What I really want to discuss is cryptography from a higher level and the design philosophies that are critical to a successful solution.

This all started with what I read on Bruce Schneier's blog. Say there's a new movie you want to see. Based on the trailer and the lead actors in the cast, you've made some assumptions about the film. True, a good cast doesn't guarantee a good movie. However, the cast list can say a lot about the film and what you might expect from it. Does it star Chris Rock and Ben Stiller? Or is it a Kate Winslet and Johnny Depp film?

Similarly, when I saw that an internationally respected security guru was discussing BitLocker on his blog, I made some assumptions. First, I figured that this new technology must either be good enough to deserve an honorable mention or so ridiculously bad that it had to be called out publicly. To my surprise, Bruce Schneier's final verdict was positive.

One particular sentence stood out in his write-up: "There aren't any back doors for the police." This statement packs a lot of punch. It was stated with great confidence and included a link to the Microsoft® System Integrity team blog. I followed the link and found a post by Niels Ferguson, a security-focused developer at Microsoft, denouncing speculative rumors that Microsoft had intentionally included back doors in BitLocker for law enforcement purposes. Ferguson stated outright that back doors are unacceptable and that he'd have no part in a project that supported them. (He also explained that even if Microsoft was forced to include a back door by law, the company would either announce the back door publicly or withdraw the feature entirely.)

The name on the post—Niels Ferguson—explains Schneier's confidence, and it sent confidence my way as well. Ferguson is someone who knows what he's talking about, and he has a track record that ensures you can trust what he says. Bruce Schneier and Niels Ferguson are the coauthors of Practical Cryptography (a seminal book about applying good cryptography, simplistically, correctly, and securely) and the co-designers of the block cipher, Twofish—a 128-bit Feistel network that earned its cryptanalytical bones by surviving as a finalist in the Advanced Encryption Standard (AES) selection process.

Of course, having a seasoned cryptographer attached to a project is no guarantee that the final product will be secure. Even the masters of this art can sometimes miss a stroke or two. But regardless of how BitLocker pans out over time, you can at least be certain that sound design strategies played some part in its creation.

Speaking of missed strokes, there are the bona fide attempts by developers without a lick of cryptographic sense and the mala fide attempts by those who are more concerned with just getting a product out the door. Both endeavors, regardless of intent, are security failures in the making. Neither, however, appears to be the case with BitLocker. Having at least one competent cryptographer involved and ample resources supporting the effort bodes well.

A Word about Trust

Not long ago, Phil Zimmerman, creator of PGP encryption, shared some rules of thumb with me. Should there ever be a published "Security Creed for Developers," his advice would surely grace the top of the charter. While his points were not intended to be specific to BitLocker, the design philosophies they promote can be applied to most any cryptographic solution. You might find these obvious or overzealous. But given the state of security today, they are worth stating explicitly.

When designing a cryptographic infrastructure, the developer must be simple, correct, and secure. Although mistakes are inevitable, they should not be accepted as a natural occurrence and merely shrugged off. The developer must be a staunch advocate of nothing less than meticulous perfectionism. As Zimmerman put it, "design as if making a mistake will cost someone's life." Think this is an exaggeration? At the 2005 Annual Computer Security Applications Conference, NSA cryptographer Brian Snow (who has since retired) said, "I want functions and assurances in a security device. We do not beta test on the customer. If my product fails, someone might die." So remember—mistakes can have more than just a monetary cost.

Users deserve assurance. Gaining—and maintaining—the trust of users is pivotal. Zimmerman makes this very clear when he says: "Earn the trust of the users. Once you shoulder that burden, you can never put it down." By doing so, the company preserves the user's assurance and its own reputation as being secure. If lost, these can be irrecoverable.

These are perspectives I hope Microsoft kept in mind when designing BitLocker (or any of the company's other products, for that matter). That said, I want to explain why I'm optimistic that Microsoft has actually gotten this right and delivered a piece of cryptography technology that should be taken seriously.

A Poor Man and His Elephant

At its core, BitLocker is how Windows Vista (specifically, the Enterprise and Ultimate editions) encrypts all system volume data. This may sound like a straightforward application, but consider the constraints. Since BitLocker encrypts data at the per-sector level, and the ciphertext cannot exceed the length of the plaintext, there is no breathing room left for anything else—such as nonce (a number or string used only once for authentication), initialization vector (IV), or Message Authentication Code (MAC). I anticipated that such tight constraints and the conditions they impose were likely, but I also knew that message authentication would be addressed somehow.

BitLocker relies on what's often called poor-man's authentication. The compromise isn't as conservative as you usually want, since it assumes that manipulated ciphertext doesn't result in meaningful plaintext. In other words, if ciphertext is manipulated, it should, for example, cause the system to crash rather than allow an adversary to carry out some function.

The Microsoft team behind BitLocker knew that an entirely new block cipher would require more time to analyze than is acceptable, but existing designs either hadn't yet been analyzed well enough or weren't efficient enough. So, for encryption, Microsoft chose AES in CBC (Cipher Block Chaining) mode, which I'll refer to as AES-CBC. This is indistinguishable under the chosen plaintext attack model (abbreviated IND-CPA), but it does not preserve integrity. And since there's no room for a MAC, and CBC is a mode of confidentiality, there's no integrity preservation at all. This is Elephant's cue to enter the room.

The new Elephant component sports two diffusers, which are built to render much better poor-man's authentication than vanilla AES-CBC. (I should note, however, that there is an option to run AES-CBC without Elephant for those of you who must obey strict standards-compliance policies.) Although not always ideal, poor-man's authentication is the most suitable solution under the given constraints, and Elephant aims to make the best of the situation. How exactly does all this work?

Figure 1 illustrates the flow of understanding. When encryption takes place, the plaintext is combined, via XOR, with a sector key. The text then flows through two unkeyed diffusers. From there, the text is encrypted using AES-CBC. The sector key and AES-CBC both require key material and therefore they are keyed—independently. This method simplifies the formalization of a proof for reducing the security of the AES-CBC and Elephant construction to that of AES-CBC. Elephant is a new primitive, and new primitives may be met with reluctance until they've been rigorously analyzed. But this approach balances the scale since BitLocker can show that AES-CBC with Elephant is no easier to attack than AES-CBC alone.

Figure 1** Poor-man's authentication with Elephant **

The sector key and the AES-CBC components both receive 256 bits of key material, making the key length 512 bits. By default, however, these components use only 128 bits of key material each, meaning some of the key material isn't used. The reason for this is simply that it's easier to throw away bits you don't need than it is to change the key management infrastructure as key lengths vary.

The block length is allowed to be any power of two, within the range of 512 and 8192 bytes. To ensure that any alteration to the ciphertext results in all of a sector's plaintext being modified in a random way, the block cipher is designed to behave with such a variable block size. Furthermore, if it behaves like a tweakable block cipher (as described by Liskov, Rivest, and Wagner), with the algorithm changing slightly from sector to sector, an adversary can't successfully move one sector's ciphertext to another sector.

Only Time Will Tell

Speculating about the cryptographic security of BitLocker misses the much bigger picture. For BitLocker, being secure isn't necessarily sufficient for it to be able to do its job. This is because BitLocker is not a solution unto itself—it's one of many Windows Vista appendages. Microsoft says BitLocker is tightly integrated into Windows Vista. But if there is such tight integration with the OS, then isn't it plausible that another component's failure could in turn cause BitLocker to fail or be compromised?

Personally, I believe in modularity and isolated failure. Tight integration without modularity leads to complexity. Granted, this may not be the case with Windows Vista and BitLocker, but only time—and ample analysis—will tell if that is so.

So what do I think about BitLocker? I tip my hat to the Microsoft System Integrity team for relying on true, reliable cryptographers who did things as cryptographers should. It's obvious that this feature was designed for cryptography, not for a marketing campaign. So my response to that question is that BitLocker should be taken seriously. Notice that this sets aside the verdict of whether its security is sound. Again, only time and real-world evaluation will tell. Many cryptographic primitives and protocols have been broken. But at the very least, the Microsoft System Integrity team has given us understanding and platforms upon which to build even better solutions.

Justin Troutman is a maturing cryptographer and undergraduate student in mathematics. His primary focus is on symmetric cryptography. He is also the founder of Extorque, which specializes in cryptographic research and consulting.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.