Disk encryption: Balancing security, usability and risk assessment

Hi: Russ Humphries here. There’s been a lot of attention this week paid to memory attacks against disk encryption technologies and I wanted to provide some commentary and thoughts. The focus of these conversations is centering on investigating the contents of a computer’s memory – if it’s running or shortly after it has been recently powered down; where ‘recently’ could be seconds to perhaps minutes. The concept that memory retains a ‘ghost image’ of what was last stored on it has been well documented and is an industry-wide issue.

However, the current debate has an interesting angle to it - specifically a method has been detailed in which an application might be able to reconstruct an encryption key, which might have been used for almost any security purpose, from these ghost images.

Since disk encryption is a topic that gains headlines perhaps it was inevitable that the practical demonstration of this key-reconstruction would be to investigate a computer’s memory to ‘break disk encryption products’ and potentially access data stored on the hard drive.

The thing to keep in mind here is the old adage of balancing security, usability and risk. For example BitLocker provides several options that allow for a user (or more likely Administrator) to increase their security protections but at the cost of somewhat lowering ease-of-use. BitLocker supports options that will not allow a machine to boot – or resume from hibernate – until the user can:

· Enter a PIN

· Insert a USB stick that contains a secret Key

· … and as of Windows Vista SP1 both enter a PIN and insert the USB stick!

We provide best practice guidance in the Data Encryption Toolkit (https://www.microsoft.com/technet/security/guidance/clientsecurity/dataencryption/analysis/4e6ce820-fcac-495a-9f23-73d65d846638.mspx ) that describes the various manners in which the above choices can be made and also provides advice to help improve security, such as disabling ‘sleep mode’ – forcing a user to hibernate and thus allowing memory to lose the ghost images discussed. These power management settings can all be configured centrally using Group Policy Objects.

Now with the above context in mind, I’d like to take a step back and, from a BitLocker perspective, detail some of the assumptions that have to be made for this attack to be successful:

· Physical access to the machine

· The user’s laptop would likely have to be in sleep mode, rather than hibernate mode or powered off

· The user would have chosen not to implement multi-factor pre-boot authentication

· The person who finds/steals the laptop must be knowledgeable and interested enough to execute this attack on the laptop they just stole

I would posit that the opportunistic laptop thief is somewhat unlikely to carry a separate laptop on which they will have installed tools that allow them to reconstruct cryptographic keys – or for that matter have a can of compressed air handy.

Targeted theft is, of course, an entirely different threat model!

Let me also point out that BitLocker allows an administrator to, quite easily, change the protection method for a laptop, even remotely [but assuming some form of connectivity], by having a script execute. Thanks to BitLocker’s design, which implements key abstraction, a script can be executed that adds pre-boot protection mechanisms without requiring the re-encryption of the hard disk. This script can therefore execute very quickly.

Let me close by clearly stating that quality security research helps our customers and the industry in general raise the security bar, and I applaud it; but let’s also keep in mind that technologies like BitLocker provide a very valuable service to users and helps them protect data on their PCs. BitLocker’s range of deployment options, ranging from single-factor authentication with sleep mode to TPM+PIN+USB with hibernation only, allow customers to find the right balance of security and convenience for their data; the documentation of one attack method, that can be mitigated through these policy choices, does not equate to a class of data protection products being rendered ‘useless’ as has been reported in some circles.

-Russ

Comments

• Anonymous
  February 22, 2008
  Thanks Russ, just one question that would help put into context the assertions in this article: what set of configuration choices do you use on your corporate laptop(s)?

• Anonymous
  February 23, 2008
  @Mike: We are using multi-factor authentication. My laptop is configured to use TPM+PIN and is restricted to boot from the harddisk only. Daniel

• Anonymous
  February 25, 2008
  The comment has been removed

• Anonymous
  February 25, 2008
  I certainly understand the advisability of multi-factor identification and a preboot password. However, in a coorporate environment where the fleet of machines must be patched as soon as effectively possible, and that the patches may require mutliple reboots, the additional security of preboot password has a significant impact on productivity. It would be of more use if the memory could be cleared as part of the hibernate process - we're looking at a wake-on-lan implementation that should reduce this risk. Laptops that are targetted thefts while travelling would seem to be the biggest risk

• Anonymous
  February 25, 2008
  Hi. My name is Douglas MacIver and I specialize in security assurance at Microsoft as a member of the

• Anonymous
  February 26, 2008
  While Bitlocker appears to be a fine solution and I use it with the USB required from hibernate, Russ's comments are from a sales prospective and do not address or mitigate the risk.  I agree that this memory freeze finding is of little consequence for most but the risk and probablity of attack is not the same for all.  E.g. computer systems used by military members on the battlefield or where systems are running, can be attained and where talent and money is present, this finding must be addressed.

• Anonymous
  February 27, 2008
  I very much agree that the hardware+software attack on BitLocker's keys via RAM is not "Microsoft's fault" or due to an intrinsic BitLocker weakness. Hence, Microsoft could justifiably do nothing about the threat. However, are there plans by Microsoft to pressure hardware manufacturers to incorporate security into their RAM chips? Or is some other solution in the works that anyone knows of?

• Anonymous
  February 28, 2008
  We would need a hardware solution, like a VRAM chip on the motherboard (where the keys can be stored) that gets overwritten securely during power loss. Also, if the VRAM chip is tampered with , it should break the system and make it inoperable.

• Anonymous
  March 08, 2008
  Well, now I have to ask about the Firewire thing.  Is this the kind of thing ASLR could help mitigate?  Why not disable unused Firewire ports when locking the PC?  Etc.   I know the adage that once you have physical access you're owned, but really, this doesn't even require rebooting the machine, much less having to rip the PC apart to clear the CMOS or remove the hard drive.  I pity IT guys that must manage Firewire-capable machines. What are your thoughts on this issue?

• Anonymous
  March 25, 2008
  The comment has been removed

• Anonymous
  April 22, 2008
  CAn you told me somethink abot the difference bitlocker and a hardisk encryption based on silocn on the harddisk like from seagate. What abouut enterprise management and perfromance

• Anonymous
  April 24, 2008
  I think what most people are missing about the Cold Boot attack is that with it an attacker is capable of removing the RAM to another computer to access it. The Cold Boot attack is reliant on only two of the four conditions stated by Mr. Humphries: knowledge and physical access. In the case of a stolen laptop, which is the largest reason for Full Disk Encryption, physical access is a given. The knowledge is now easily attainable with a quick search on Google. Given the stolen laptop is still on, the attacker may remove both RAM and HDD and connect them to another laptop. Since the USB and PIN are measures taken on the OS level and are not actually part of the FDE, the attacker doesn't need them. They have the decryption key and the drive, which is now slaved to their own computer. Microsoft's BitLocker offers no protection to this. The Cold Boot method is all about targeted theft! This is the model that Microsoft, nor any other currently available product, can currently protect you from.

• Anonymous
  June 04, 2008
  Awesome post! I am definitely going to try this one, it sounds complicated, and I am sure it will take me a couple days... but it will most likely eventually be worth it!

• Anonymous
  June 23, 2008
  The comment has been removed

• Anonymous
  June 29, 2008
  inrersante pero no comprendo nada

• Anonymous
  August 11, 2008
  " Since the USB and PIN are measures taken on the OS level and are not actually part of the FDE, the attacker doesn't need them." Actually this is incorrect - the PIN and becomes part of the access key that is required to unlock the volume. Since the TPM must actually return the unlocked access key the TPM's anti-hammering technologies help augment the security value of short PINs - I normally recommend 6 digit PIN as a compromise between security and ability for a user to remember the key (TCO in other words). With respect to the USB key - entropy us again stored o nthe USB key and extracted and integrated into the access key. All of the above key combinations occur pre-boot.

• Anonymous
  September 22, 2008
  Russ I have implemented Bitlocker with a TPM+PIN for my organisation following the publication of the Cold Boot Attack.  However the PIN is proving to be very, very unpopular with the user community, as well as making remote management more difficult, so my management has asked me to do everything possible within reason to remove it. I've come across a document that implies that the TPM specification might have been updated to set a "dirty" bit that causes memory to be overwritten at startup if the OS is not shutdown cleanly (https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PlatformResetAttackMitigationSpecification_1.00_0340308-1.pdf) However I cannot find any mention of this feature in the TPM specification, no information that Windows Vista supports it, and lastly, my laptop hardware vendor (Lenovo) has not been able to confirm the existence of this feature at hardware or firmware level either. Does this mitigation exist, and if so, how would I know if I have all the requirements in place?