System Integrity Team Blog

BitLocker, Brossard’s Pre-boot Authentication Research, and the BSI

2008-09-04T23:00:00Z

Attending DEFCON presentations that target a product you use or helped build can be exciting in a bad way. And believe me – knowing the fix has already been shipped reduces that excitement… in a very good way. This is what made Jonathan Brossard’s DEFCON 16 presentation Bypassing pre-boot authentication passwords less exciting for me: I knew the fix had been delivered to customers seven months earlier as part of Windows Vista Service Pack 1. That isn’t the complete story though.

The BitLocker Team collaborates with customers, partners, and world-class security-research organizations to complement its internal security analysis and penetration testing. Sometimes Microsoft initiates the external analysis and other times this work is begun independently. Reports of vulnerabilities flow from various sources through different channels. Each case is usually unique in some way. For instance, sometimes the finder doesn’t want publicity. In other cases, public events change the situation in a way that prompts us to respond publicly.

The password artifact in the firmware, or BIOS, keyboard buffer is a real problem. The BitLocker Team fixed this in Windows Vista SP1 by flushing the PIN from the keyboard buffer. While Mr. Brossard and his employer iViZ Techno Solutions are due credit and thanks for independently identifying this problem and publicizing their multi-vendor findings, they weren’t the first to report it privately to Microsoft. That credit belongs to the German government’s Federal Office for Information Security (BSI) and the Fraunhofer Institute who reported this issue to us in 2007. Thanks to their close collaboration with us, we were able to get the fix into Windows Vista SP1 and Windows Server 2008. We are also thankful that iViZ chose to responsibly disclose this to us and other vendors prior to publicizing their research.

There is an element of Mr. Brossard’s findings that is often ignored or misunderstood: The full, end-to-end, boot-component-modifying attack requires administrative privileges, or root, on all of the operating systems covered in his presentation – including Windows. Mr. Brossard made this clear during his DEFCON 16 presentation and in the associated white paper. On Windows, administrative privileges are required to write to the MBR and other boot components. Even if offline attacks are considered, BitLocker, in its TPM modes, will detect any unauthorized modification of the boot components during its secure boot phase.

The prerequisite of administrative privileges makes the BitLocker PIN attack much less interesting. If the attacker has administrative privileges, she could read disk encryption keys or, more simply, turn BitLocker off. I’m not trying to dismiss Mr. Brossard’s findings; the password artifact is a real problem that has to be addressed by a wide variety of vendors. But from a BitLocker TPM + PIN point-of-view, the vector provides limited capabilities to an attacker who doesn’t already have administrative privileges.

-- Douglas MacIver
-- BitLocker Test Team
-- Microsoft Corporation

Redirect to new post title

2008-02-26T07:47:00Z

Protecting BitLocker from Cold Attacks (and other threats)

2008-02-26T03:08:00Z

Hi. My name is Douglas MacIver and I specialize in security assurance at Microsoft as a member of the BitLocker Test Team. My responsibilities on the team are to perform BitLocker penetration testing and risk analysis.

As you may have seen in the press, last week researchers at Princeton University published a paper and video on how to attack disk encryption using a characteristic of memory called “DRAM remanence”. The research and presentation are impressive (I especially like the key reconstruction techniques). But after reading it, you may come away wondering “What can I do immediately to protect myself?” Our customers have been asking us this same question. In this post, I’m going to answer that question, providing tips on what you can do today to help protect your system against this class of attack.

As the researchers state in their paper, dynamic random access memory (DRAM) remanence issues have been known about since the 1970’s. At Microsoft, we considered this class of attack and other platform realities while designing, implementing, and documenting BitLocker. We have also worked to inform our customers of these risks and mitigations in many forums, including my Hack in the Box presentation in September, 2006.

Along with discussions in public forums, we have also documented platform risks in the Data Encryption Toolkit (DET). The risk analysis provided in the DET is intended to help customers balance security with usability, and with the cost of implementation and management. This is no small point. We believe customers are best suited to make decisions about the tradeoffs of security, usability, and cost. (Russ Humphries discussed these tradeoffs in the context of DRAM remanence in his blog entry.)

With that in mind, here are some practical countermeasures that Windows Vista BitLocker users can use today to make their systems more resistant to platform threats. Some of these approaches may apply to other products, but my expertise and responsibilities are with BitLocker, so these tips understandably focus on Microsoft’s BitLocker Drive Encryption.

Use BitLocker Advanced Modes with Hibernation

Note: This is the primary and most effective way to protect your system from DRAM remanence and other platform attacks.

Platform attacks that access encryption keys in DRAM obviously rely on those keys to be present in DRAM. As with all practical disk encryption approaches, these encryption keys must exist in system memory in order to provide the performance that makes disk encryption usable.

When BitLocker is configured in its advanced modes, encryption keys are not loaded into system memory until after the authorized user has provided credentials like a PIN, dongle, or both. An attacker without these credentials will not be able to boot the system to a state where confidential information – including encryption keys – are in DRAM.

There are some caveats though; one is a very practical threat, the other less so. If an attacker gains access to the system after the authorized user has authenticated with their BitLocker credentials, but before its owner turns it off or hibernates, the encryption keys are in DRAM and an attacker could use one of the Princeton researchers’ ‘DRAM remanence’ attacks or other platform attacks such as direct memory access (DMA) to gain access to those keys.

This is why it’s important when using BitLocker’s advanced modes to use ‘hibernation’ rather than ‘sleep’. To provide high-performance for sleep transitions, BitLocker does not encrypt RAM contents nor does it require BitLocker re-authentication when waking up from sleep. With hibernation, a system is effectively ‘off’, and keys will not be resident in physical memory (I’ll get to the second caveat that discusses this shortly). On resume from hibernation, BitLocker will require the credentials I discussed earlier, and without those credentials, encryption keys will not be loaded into DRAM.

During design and implementation, the BitLocker team worked with other teams within Microsoft to enable complete control of system-suspend settings by local and domain administrators through group policy. Instructions on how to configure this and other BitLocker settings can be found in the design and deployment guides available in BitLocker's online documentation.

Now let me address the second caveat, which is less of a practical threat. As described in the Princeton researchers’ paper and elsewhere, DRAM may retain state under normal temperatures for several seconds or a few minutes. If an attacker gains access to a laptop within this window, they may be able to access information located in DRAM. Again, the risk of an attacker exploiting this is low relative to other platform threats.

Again, this is the primary and most effective way to protect your system from DRAM remanence and other platform attacks.

Use TCG compliant systems with firmware that implement “Platform Reset Attack Mitigations”

When designing BitLocker, Microsoft worked with the Trusted Computing Group (TCG) on specifications that require platform firmware (e.g. BIOS) to overwrite physical memory to mitigate attacks exploiting DRAM remanence. In the “TCG Platform Reset Attack Mitigation Specification”, the TCG describes firmware interface requirements that BitLocker leverages to help protect against these attacks. BitLocker users should make sure that their platforms are fully compliant with TCG specifications. Please refer to Windows Vista Logo information.

Note: This is not an absolute mitigation for all platform threats. Firmware-based overwrite does effectively limit the options available to the attacker though.

Limit boot device options

Another way to mitigate some of the DRAM remanence threats is to limit the boot device options in the firmware’s (e.g. BIOS) options configuration. Doing so will limit an attacker’s options for ‘warm’ rebooting a system and loading software of their choice while keeping DRAM contents intact.

This implies that the firmware options are themselves protected by, for example, firmware passwords. There are publicly documented threats against firmware security, but remember, in the context of DRAM remanence, the attacker is attempting to keep the DRAM charged, so some traditional attacks against firmware may ultimately not help them.

Note: This is not a complete mitigation, but it is a simple way to increase the effort that is needed to exploit DRAM remanence.

Limit Windows shutdown options

And yet another method to reduce an attacker’s options is to make it more difficult for an unauthorized user to perform a ‘warm’ reboot by disabling the ability to shut down the system without having to log on. This behavior can be controlled in Windows Group Policy. See the “Shutdown: Allow system to be shut down without have to log on” setting in Windows security policy.

Note: This is not a complete mitigation, but it is a simple way to increase the effort that is needed to exploit DRAM remanence.

Disable 1394 and PCI host controllers

Another class of physical memory attacks that Microsoft has been warning customers about is DMA attacks. These attacks use DMA (direct memory access) across 1394 and PCI buses to directly access the contents of system memory without software or CPU interaction. In these attacks, an attacker using another device – for example a laptop – connects to the victim platform by plugging into an external hardware port. In the 1394 case, this is as simple as using a 1394 cable along with another ‘attack’ laptop. Once the cable is plugged in, the attacker then runs software on the ‘attacking’ laptop that accesses physical memory contents on the ‘victim’ laptop using DMA.

I’m surprised that the Princeton researchers did not treat DMA attacks as equally serious as the DRAM remanence problem they focused on. As documented in Microsoft’s Data Encryption Toolkit, DMA attacks present a slightly higher risk to customers, since attackers can mount the attack quickly and with less intrusiveness --- and potentially avoid detection.

One way to mitigate these DMA threats is to disable the 1394 and PCI host controllers. This can be done by using the Windows Device Manager.

Be aware of your surroundings

If you use PINs or passwords with your disk encryption product, be aware that highly-motivated attackers may use various ‘environmental’ methods to capture your credentials. Shoulder surfing, cameras, and microphones that capture key strokes are examples. To mitigate these risks, I use my laptop lid to shield visual capture, and I type lightly. Changing your password or PIN on a regular basis helps, especially after you think you’ve been in a ‘hostile’ environment.

Since I spend so much of my time playing the role of an attacker and obsessing about worst-case scenarios, I have a tendency (like others in my field) to be, well, paranoid. I fight this paranoia by finding practical ways to mitigate the risks so that I – and more importantly you – can continue to use the modern computing gadgets that make us productive and help make life fun.

The Princeton University paper did a good job of raising the public awareness of DRAM remanence risks. For that I am thankful. But since fear has accompanied this increased awareness, I hope that you will find the countermeasures included in this post and in the other sources that I list, practical and reassuring. The world is scary sometimes, but we have to resist allowing our fears to overcome our ability to be rational about the risks, or to blind us to available mitigations.

Regards,

Douglas MacIver
BitLocker Test Team

Links included in this post:

Microsoft’s Data Encryption Toolkit

BitLocker Drive Encryption Documentation

Windows Vista Logo Information

Princeton University Research on Data Remanence

Russ Humphries' Blog Post

Detecting BitLocker

2006-10-27T00:00:00Z

Although the most appropriate way to detect BitLocker is to use the interfaces in BitLocker’s WMI provider, specifically the "GetEncryptionMethod", But sometimes, you might wish to detect a BitLocker volume when the WMI provider is not available – such as when running a disk tool from another OS.

I stress that the "GetEncryptionMethod" should always be used if it is available. GetEncryptionMethod asks the BitLocker filter driver to report the status of the volume, and using it will make your program much more "future proof". In contrast, a program that looks at the content of the physical disk directly will require revision whenever the BitLocker disk structures change. But, if the WMI provider is not running (that is, when you are not running Windows Vista), using a method like a direct disk read is required.

Now with all these cautions aside, how can we actually detect a BitLocker-protected volume? The simple answer is that a BitLocker volume can be detected because it will have an easily recognizable BIOS Parameter Block (BPB). Note that the partition type for a BitLocker will normally be the same as that used for NTFS, which is one of the Installable File System (IFS) partition types.

BitLocker BIOS Parameter Block

A BitLocker volume has a clear-text BPB much like FAT and NTFS. The BPB is located at the first 0x54 bytes of the first sector of the volume. A BitLocker volume has a BPB that has the following characteristics:

Offset	Size	Field	Required Value for BitLocker
0x003	8	Signature	‘-‘,’F’,’V’,’E’,’-‘,’F’,’S’,’-‘
0x00B	2	BytesPerSector
0x00D	1	SectorsPerCluster	One of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40 or 0x80
0x00E	2	ReservedClusters	0x0000
0x010	1	FatCount	0x00
0x011	2	RootEntries	0x0000
0x013	2	Sectors	0x0000
0x016	2	SectorsPerFat	0x0000
0x020	4	LargeSectors	0x00000000
0x038	8	MetadataLcn

Since other file systems, such as FAT, also use a BPB structure, it’s not enough to rely on the "Signature" field alone to determine that the volume is a BitLocker volume. All the fields above with a "Required Value" must be checked.

BitLocker Metadata Location

BitLocker stores multiple copies of the volume metadata, and the first copy can be located from information in the BPB. The byte offset of the first metadata location is calculated as MetadataLcn * SectorsPerCluster * BytesPerSector. The structure found at this byte offset has the following format:

Offset	Size	Field	Content
0x000	8	Signature	‘-‘,’F’,’V’,’E’,’-‘,’F’,’S’,’-‘
0x008	2	Size	Size of structure. Validation data follows this structure.
0x002	2	Version	0x0001 for current version.
0x004	…		Version specific content.

Conclusion

By examining the BPB and the BitLocker Metadata – all of which is available in plain text – it is possible to conclusively determine that the volume has been configured as a BitLocker volume and what revision of the BitLocker structures apply to the volume.

-
Jamie Hunter

Multi-boot Security

2006-10-04T01:52:00Z

As people start analyzing BitLocker, a question that keeps getting raised is "Can I break into BitLocker by installing another copy of Vista?" This blog entry intends to show how BitLocker allows and supports multi-boot without compromising security.

There is a saying that "if it walks like a duck and talks like a duck it is a duck." If I put two operating systems on a computer, at what point are they the same operating system? And at what point are they different? If it walks like a duck (boots) and talks like a duck (accesses unique encrypted data) then for all intents and purposes from an attacker’s perspective, it is a duck.

It’s important therefore for BitLocker to be able to differentiate a real duck from a fake duck using some form of DNA. To ensure no genetic experiments on the duck, the DNA is kept secret. In the case of BitLocker, the DNA is a key called the "Volume Master Key" or VMK. Without the VMK, the "Full Volume Encryption Key" (FVEK) is not known. Without the FVEK, the content of the encrypted volume is not known. Not only is it not known, but it cannot be meaningfully modified as (with the aid of the Elephant algorithm) Decrypt(FVEK, OriginalSectorData + DeltaModification) results in an unpredictable change to the entire sector. Niels wrote a paper on the benefit of the Elephant algorithm, described in the preceding blog entry.

For this reason, the fully encrypted volume can be considered a black box and the VMK is it’s key. The next question that arises is can the VMK be passed to a red box. For this we need to understand what happens during boot.
I will describe the boot process as 3 stages:

Early Boot
Mid Boot
OS Boot

In "Early Boot", all boot components write values (measurements) to the TPM as the boot process proceeds. An example of this is that the BIOS will measure the boot code in the MBR, and write this to PCR[4] of the TPM. If the MBR is correct, the correct value will be in PCR[4]. If the MBR has been modified, the wrong value will be in PCR[4]. In either case, the MBR (legitimate or malicious) will be measured and will be executed. The TPM accumulates these measurements in a manner that cannot be undone unless the hardware is reset. It is important to ensure that all measurements are correct (therefore no modification to code) to successfully have the necessary PCR pre-conditions to allow the TPM to unseal the VMK.

In "Mid Boot", the time comes where the VMK is required to transition from "Mid Boot" to "OS Boot". BOOTMGR communicates with the TPM sending it a block of data previously encrypted by the TPM, and requests that the TPM decrypts the block of data. The TPM checks the values of PCR’s along with the values and policy conditions encoded into the block of data. The TPM also verifies the MAC (Message Authenticity Check) to ensure that the block of data was not tampered with. A legitimate BOOTMGR can obtain VMK, or know that it cannot obtain a VMK. A modified BOOTMGR will only know that it cannot obtain a VMK. If the VMK cannot be obtained, then there is nothing the modified BOOTMGR can do to open the black box. It is obvious therefore that the legitimate BOOTMGR must be used to retrieve the VMK at this point.

In "OS Boot", the legitimate BOOTMGR transitions to an active role to protect the VMK. The legitimacy of the BOOTMGR has been proven (above) implicitly by the fact that it has the VMK for a given volume. BOOTMGR must transition to the OS Loader, and it must do so without giving the VMK to the wrong OS Loader. This is where things get interesting. The metadata associated with the OS Volume contains a set of requirements indicating what boot executables are considered valid - more than one is required to support memory testing and to support resume from hibernate. BCD policy is also stored to ensure most BCD settings cannot be modified. To ensure the metadata is not tampered with, a MAC exists. Calculating the MAC requires knowledge of the VMK.

Before BOOTMGR transitions to the OS Loader, it verifies that the OS Loader and BCD settings are trusted. At this point the OS Loader can be trusted with multiple keys, but only if the metadata for the associated volumes indicate explicit trust. Modifying an OS Loader will immediately invalidate this trust. BOOTMGR also ensures that no more BitLocker keys can be accessed by writing a value to PCR[11] that is akin to locking a safe until the next boot.

Prior to transitioning to the OS, the OS Loader ensures that it will hand off at most one key (VMK) to the OS. Prior to handing the key off to the OS, the following conditions must apply:

All components up to and including BOOTMGR must be correct. If they were not correct, the VMK would not be available.
VMK must be correct to validate the MAC of the metadata. BOOTMGR verified this MAC.
OS Loader must be the loader approved by metadata associated with VMK. Verified by BOOTMGR.
BCD settings must be the settings approved by metadata associated with VMK. Verified by BOOTMGR.
VMK must correctly decrypt FVEK stored in the validated metadata. Verified by BOOTMGR.
FVEK must successfully decrypt data stored on the volume. Incorrect FVEK will result in invalid executable code or invalid data. In some cases this is caught by code integrity.

MFT must be encrypted by correct FVEK to access all files.
Phase 0 drivers including fvevol.sys must be encrypted by correct FVEK.
Registry must be encrypted by correct FVEK.
Kernel and Hal must be encrypted by correct FVEK.
Phase 1 components must be encrypted by FVEK, as fvevol.sys (encrypted by FVEK) will only decrypt using the same FVEK.
Phase 2 components must also be encrypted by FVEK etc.

The last point is particularly important, and is only true if the data on the volume is entirely encrypted - i.e. a volume where encryption was paused half way through is not secure. The black box OS described earlier will therefore meet these requirements; whereas the red box OS will not.

Conclusion

As only the OS that was encrypted by a given VMK/FVEK combination can access the VMK, multi-boot is not only secure, but very much a central part of the BitLocker design and threat analysis.

Jamie Hunter

BitLocker cryptographic algorithm published

2006-09-16T00:56:00Z

While working on the BitLocker data encryption we realized that no existing algorithm satisfied all the requirements that we had. We resolved this by combining AES-CBC with a specialized diffuser that improves the security against manipulation attacks.

The paper describing all of this in detail finally made it through all the procedural hoops, and is now available for download. The PDF is at

http://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608.pdf

This paper was also distributed as a handout at the rump session of Crypto 2006.

Enjoy!

- Niels Ferguson (cryptographer and developer)

BitLocker recovery password details

2006-08-10T23:13:00Z

Recently the BitLocker Penetration team was asked some questions about the security of the recovery password. Even if you use BitLocker every day, you may never have seen the recovery password entry screen – it is displayed by the Boot Manager in the situation where the key it needs to unlock your BitLocker protected volume is not available for some reason. A simple way to see this screen in TPM & PIN mode is to forget your PIN - you will be asked to enter a 48-digit recovery password. This password allows you to boot into Vista and set a new PIN.

Figure 1 - Please enter 48 digits!

To help ensure that the password is entered correctly, we have you type it in in eight blocks of 6 digits. If you make a typing error while entering any block, we let you know that an error is present, and allow correction before continuing. Why do we do this? Well, manually entering 128 bits of a cryptographic key via the keyboard is not particularly easy. Users making a small error entering the key would simply be told 'incorrect key' and would have to re-enter the whole key. One of the enterprise scenarios we picture is a helpdesk technician reading a recovery key over the phone to a remote user - re-reading long keys increases support costs as well as user frustration!

The question we are being asked is 'doesn't this verification stage weaken the security?'. The answer is, as you'd hopefully expect, no - and here's why:

When we create the recovery password, we start with a random 128-bit key, which we split it into eight groups of 16 bits. Each group contains 16 bits of entropy, and can be written as a value between 0 and (2^16 - 1). We take this value and multiply it by 11. The range of values this now describes is from 0 to 11 x (2^16 - 1) (0 thru 720885). Notice that only 1 in 11 of the output are now 'valid' values. We pad with zeros, and write this as a six-digit value. This value still contains the original 16 bits of entropy, but now distributed over a larger range. We repeat the process for the other seven blocks, producing a 48 digit password.

When a user is entering the key, we accept it 6 digits at a time, and then check to see if the number they just entered is exactly divisible by 11. If it is then we know it might form part of the key - if it doesn't then we know for sure it isn't a valid block. This guards against swapped digits, mis-entered numbers, etc, and we can safely report the entry error to the user.

But does this check reduce the amount of work an attacker would have to do to brute force the underlying key? Consider that when we check a group of digits we aren't saying that they are the 'correct' group for that location in the key - merely that they could be a correct group, as they are divisible by 11. To verify this, try swapping two groups when entering your key - the individual groups will validate correctly, but the overall key will still be rejected. The work that an attacker has to do to brute-force the key is equivalent to the situation without the group-check.

Here's a small toy example, where we start with an 8-bit key (01101101). We will split it into two blocks of 4 bits:

0110 1101 =  06  13 (decimal)

we now multiply by 11:

          =  66 143

Which gives us a recovery key of 6 digits [066-143]

Mistyping these blocks as 067, 606, 134, 413 etc. will result in an error - but we can't verify the whole key until we have both blocks. How much work would an attacker have to do to brute-force this key? Each block has potentially 1000 values - but the attacker knows that only those divisible by 11 can be valid keys - thus the exhaust work space is reduced to 90 values. More so, the attacker knows that all values above 165 are not valid keys (because there is no way that 4-bit value x 11 would be greater than 165), so there are only actually 16 valid values per block (0, 11, thru 165); with two blocks, this gives a key space of 16 x 16 = 256 keys to try, which is, unsurprisingly, 2^8 - or the same as the key space we began with. If the example is expanded to the full key of 48 digits the same facts about the key space hold, and the amount of work required for the attacker is not diminished.

- Jon (Penetration Test Engineer)

AES test vectors

2006-05-19T22:01:00Z

I’ve been working to optimize our AES implementation. BitLocker encrypts and decrypts more data than all other features in Windows Vista combined, so we have the most to gain from a fast implementation.

I won’t bore you with the details of optimizing AES in assembler. Let’s just say that the Pentium 4 has various quirks that make performance measurement and optimization harder than you’d think. And of course the code has to be fast on a variety of CPU architectures, so you cannot optimize for one CPU only.

Properly testing an AES implementation is hard if you don’t already have a good AES implementation. NIST included some test vectors in FIPS 197 but these are limited to one or two key/plaintext/ciphertext values for each key length. It is quite conceivable that you could have a small error in an implementation that would not be caught by the FIPS 197 test vectors.

So I defined my own test vectors using the construction the Twofish team used for the Twofish test vectors. This is actually a generic construction that you can use for any block cipher.

Notation:

b # bytes in a plaintext or ciphertext block

k # bytes in a key

E(K,P) Block cipher encryption function, K = key, P = plaintext

D(K,P) Block cipher decryption function, K = key, C = ciphertext

Test algorithm:

S = a string of k+b zero bytes.

repeat 1000 times:

n = length(S)

K = S[n-k..n-1] the last k bytes of S

P = S[n-k-b..n-k-1] the b bytes just before K

append E(K,E(K,P)) to S

The last b bytes of S are the test vector value.

When implementing this you don’t have to keep the whole S. You only need to store the last n+b bytes of S, plus another b bytes to store the data you are appending to S.

There is a reason why each iteration uses two consecutive block encryptions. In most software implementations each time you use a key you first compute an expanded key which is then used by the encryption function. If you only use the expanded key once the test would never notice if the encryption function were to accidentally damage the expanded key it is using. (That is an easy mistake to make in assembler.) By encrypting twice we make sure that the test is sensitive to this type of error.

One very nice property is that you can compute the recursion backwards. Given the last n+b bytes of S you can compute all the earlier values using the decryption function and check that you get the original all-zero starting string. That is how the decryption function is tested.

It is hard to see how an implementation could pass this test and still be wrong. There are 2000 encryptions in each test, for a total of at least 320000 S-box lookups. Even if the implementation uses a separate S-box for the last round (which is slightly different) there are 32000 lookups into that S-box, so every table entry will be used several times. There could be a hidden bug if your implementation uses very large tables with 2^16 entries, but I’ve never seen that done in practice.

Here are the actual values for AES (with b=16 of course):

AES-128 (k=16): 0xbd, 0x88, 0x3f, 0x01, 0x03, 0x5e, 0x58, 0xf4, 0x2f, 0x9d, 0x81, 0x2f, 0x2d, 0xac, 0xbc, 0xd8

AES-192 (k=24): 0x41, 0xaf, 0xb1, 0x00, 0x4c, 0x07, 0x3d, 0x92, 0xfd, 0xef, 0xa8, 0x4a, 0x4a, 0x6b, 0x26, 0xad

AES-256 (k=32): 0xc8, 0x4b, 0x0f, 0x3a, 0x2c, 0x76, 0xdd, 0x98, 0x71, 0x90, 0x0b, 0x07, 0xf0, 0x9b, 0xdd, 0x3e

Feel free to use this to test your own AES implementation. If you verify these test vectors against a known good AES implementation, please let me know and I’ll update this post with a list of people and implementations that have verified these vectors. (That should also catch the case of me making a mistake in this posting.) I can be reached at <my-first-name>@microsoft.com.

Update:

2006-06-06 Srdjan Sobajic verified the AES-128 test vector on an 8051 implementation.

2006-06-21 Dominik Weber verified the test vectors in C on an x86.

2006-12-06 Taral verified test vectors on AMD64 against OpenSSL.

2006-12-19 Sergey Gerasimenko verified the AES-128 test vectors on a Hitachi SH2 implementation.

- Niels Ferguson (developer)

Finding a Secure PIN

2006-04-11T02:36:00Z

BitLocker Drive Encryption offers users a number of different modes to protect the key used in encrypting/decrypting data. One of these modes requires a PIN be entered at boot time, which is used as authorization data to the TPM, and allows the key to be unsealed. As a penetration tester on BitLocker, I’ve been examining the strength of this PIN.

BitLocker processes the PIN before localized keyboard support is available, and as a result, only the Function keys (F0-F9) may be used. Naturally, this limits the entropy of the key, so brute force attacks become a concern. Fortunately, the TPM authorization data mechanism is designed to be resistant to dictionary attacks. The details vary from vendor to vendor, but if we make some basic assumptions, we can begin to calculate how strong our PIN needs to be, given this TPM protection. For argument’s sake, let’s suppose that the dictionary attack mitigation mechanism makes guessing 5000 PINs take one year (an average of ~1.8 hours per guess), and call this an acceptable level of security.

Since we have ten keys available to us, the number of possible PINs of length n is equal to 10ⁿ, and the average time to guess a length n PIN is 10ⁿ / 2. So we can get our desired security level with a 4-digit PIN: 10⁴ / 2 = 5000. For the sake of comparison, suppose we instead used a password composed of alpha-numeric characters plus standard keyboard symbols (of which there are about 32, by my count), but did not have anti-hammering protection. Assuming even a modest average time-per-guess of one millisecond, in order to get the same level of security, we would need close to 6 characters. Plus, the TPM protects us against offline pre-computed dictionary attacks, because there is no way to access the hash of the correct PIN.

An interesting challenge arises out of the fact that only the Function keys are used in the PIN: due to the infrequent use of these keys for other purposes, an adversary might be able to perform a wear analysis to determine which keys are used in the PIN. If finger oil or corrosion on the F3, F4, F7, and F9 keys is noticeably greater than on the others, a clever adversary would just try the 4! = 24 possible orderings of these keys. So, how can you help protect yourself against this attack?

The question is: if an adversary knows which keys you used in your PIN, how many guesses will it take them to find the PIN itself? The following table helps answer this question. Here, the columns show a length-n PIN, and the rows correspond to a PIN using exactly k distinct keys:

**Possible n-digit PINs using exactly k characters**
	n = 4	n = 5	n = 6	n = 7	n = 8	n = 9	n = 10
k = 1	1	1	1	1	1	1	1
k = 2	14	30	62	126	254	510	1022
k = 3	36	150	540	1806	5796	18150	55980
k = 4	24	240	1560	8400	40824	186480	818520
k = 5		120	1800	16800	126000	834120	5103000
k = 6			720	15120	191520	1905120	16435440
k = 7				5040	141120	2328480	29635200
k = 8					40320	1451520	30240000
k = 9						362880	16329600
k = 10							3628800

So, in order to raise the expected number of required guesses to the previously described level, even against an attacker who can successfully analyze key wear, the PIN must contain at least 7 digits with at least 4 different keys. An important note is that the maximum in each column is not the bottom entry: it actually strengthens the PIN (against this particular attack) to have a repeated character or two. Thus, when choosing your PIN, you may want to consider intentionally having multiple occurrences of the same key(s).

Bear in mind that the wear analysis attack is still hypothetical. The BitLocker penetration testing team hasn’t tried to do this, so any guess of what’s possible is merely speculation. Nevertheless, for those looking to go the extra step to protect their data, it never hurts to consider all the attacks, even the unproven ones. If you’re concerned about wear analysis attacks, you may want to look into other mitigations (beyond smart PIN choice), such as wear-resistant keyboards, regular cleaning, or increasing use of the Function keys during normal operation.

With some smart use and a good TPM anti-hammering mechanism, your PIN can provide a major additional layer of security, without need for carrying an external key.

- Kevin Litwack (Penetration Test Engineer)

What got me out of bed today?

2006-03-22T02:32:00Z

Recently I read yet another report (http://www.komotv.com/stories/42263.htm) of stolen laptops resulting in a bigger loss then the monetary cost of the hardware. When we interact with different companies and provide personal information, such as credit cards, bank accounts, social security numbers, or even our mothers’ maiden names, we are entrusting the company to handle that information securely. In the world of electronic commerce and convenience, a game of “Russian Roulette” is being played with the trigger being pulled each time a computer is lost. The cost is a thief being interested in the sensitive information that is left as easy pickings on the hard disk. I want to put an end to that game.

When I joined System Integrity (then NGSCB) 2½ years ago, I had the opportunity to become part of the solution to this issue, in what has become BitLocker Drive Encryption (BDE). The great thing about being on this project is not just making it part of the Windows product, but also the excellent engineers I work with, and interact with while solving very interesting problems.

Let me give you an example. Consider the fact that the whole operating system is encrypted. The kernel, the HAL, the registry, the hibernation file, the paging file, and all the boot drivers (including the BDE driver) are encrypted. The NTFS MFT (Master File Table) is encrypted, so none of these files can be found. A key is required to decrypt the disk. Where do we get this key from? And how do we decrypt the kernel? How do we ensure that the boot code has not been tampered with?

Working with the boot architecture engineers, “bootmgr,” “winload.exe” and “winresume.exe” contain some of the code that exists in the BDE driver so that the operating system files can be found and decrypted. With this merged technology the hibernation file can be decrypted as it is loaded into memory.

Working with OEM’s, and the TCG, new hardware is appearing containing the latest TPM generation. OEM’s are adding security features and support functions into their BIOSes to allow any operating system (not just Windows) to utilize the TPM during boot. Using this technology a key can be encrypted by hardware and only decrypted if certain conditions are met. If multiple operating systems exist on the computer, each one can maintain their own set of conditions separate from each other.

Managing keys in a multi-boot environment has its own set of challenges. I (and others) have lost sleep working through different scenarios on how someone may try to break the security of BDE and making sure we have all of our bases covered. We have every reason to make sure we got it right, as it’ll be really embarrassing if we miss something that we should have caught. We have Penetration testers to help keep us on our toes and make sure we write code with an eye to the most experienced hackers.

So what got me out of bed? I enjoy technology, I enjoy challenges, and I enjoy being part of the solution that BitLocker Drive Encryption is providing.

- Jamie Hunter (Senior Developer)

Back-door nonsense

2006-03-03T04:10:00Z

Two weeks ago BBC News published an article speculating about a possible “back door” in BitLocker (http://news.bbc.co.uk/1/hi/uk_politics/4713018.stm). The suggestion is that we are working with governments to create a back door so that they can always access BitLocker-encrypted data.

Over my dead body.

Well, maybe not literally---I’m not ready to be a martyr quite yet---but certainly not in any product I work on. And I’m not alone in that sentiment. The official line from high up is that we do not create back doors. And in the unlikely situation that we are forced to by law we’ll either announce it publicly or withdraw the entire feature. Back doors are simply not acceptable. Besides, they wouldn’t find anybody on this team willing to implement and test the back door.

We are of course talking to various governments; we want them to buy Vista and use BitLocker for their own security. We get the typical questions you always get: ease of use, performance, security, etc. We also get questions from law enforcement organizations. They foresee that they will want to read BitLocker-encrypted data, and they want to be prepared. Like any security technology BitLocker has its avenues of attack and law enforcement should know about them. For example, if they search a house and find a computer, they should also take all USB thumb drives, as these might contain a BitLocker key. This information is not secret; our users need to have the same information when they make the security vs. convenience tradeoff of choosing a key-protection option (TPM only, USB key, TPM + USB key, etc.) We plan on having a KB article with the details when Vista ships.

- Niels Ferguson (developer & cryptographer)

Welcome to the System Integrity Team blog.

2006-03-03T03:45:00Z

I finally managed to organize a team blog so that we can put out some technical information without going through the marketing machine.

You might not have heard about the System Integrity group. We used to be called NGSCB, which was always a temporary name but it took more than 2 years before we got around to changing it. We are part of Windows Security; our charter is to provide Integrity for the Windows platform. That should keep us busy for the foreseeable future.

Our goal for this blog is to publish information to a technical audience without all the marketing speak. It is not a blog in the sense of something that is updated every day; we will post new items whenever we feel we have something important to share.

Enjoy!

- Niels Ferguson