Disk encryption: Balancing security, usability and risk assessment

re: Disk encryption: Balancing security, usability and risk assessment

Mike Smith-Lonergan — Sat, 23 Feb 2008 05:13:31 GMT

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)?

re: Disk encryption: Balancing security, usability and risk assessment

Daniel Melanchthon — Sat, 23 Feb 2008 16:34:29 GMT

@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

re: Disk encryption: Balancing security, usability and risk assessment

Doug — Mon, 25 Feb 2008 22:46:55 GMT

We just had two laptops stolen. Both were powered on and would be prime candidates for 'memory' based attacks. So this is not as improbable as you make it sound.

Bottom line is this, my impression thus far has been that hardware based disk encryption was basically fool-proof, except for a brute force attack. Now, it appears that we need some type of motherboard device that will overwrite memory on power down, sleep, or hibernate. Or, we need to store keys somewhere beside memory.

re: Disk encryption: Balancing security, usability and risk assessment

Michael Swift — Tue, 26 Feb 2008 00:30:58 GMT

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

Protecting BitLocker from Cold Attacks (and other threats)

System Integrity Team Blog — Tue, 26 Feb 2008 07:13:23 GMT

Hi. My name is Douglas MacIver and I specialize in security assurance at Microsoft as a member of the

re: Disk encryption: Balancing security, usability and risk assessment

Tim R — Tue, 26 Feb 2008 20:41:29 GMT

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.

re: Disk encryption: Balancing security, usability and risk assessment

Garrett G. — Wed, 27 Feb 2008 21:36:00 GMT

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?

re: Disk encryption: Balancing security, usability and risk assessment

Jasvir C. — Fri, 29 Feb 2008 01:37:57 GMT

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.

re: Disk encryption: Balancing security, usability and risk assessment

Mark Sowul — Sat, 08 Mar 2008 17:22:04 GMT

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?

re: Disk encryption: Balancing security, usability and risk assessment

CPL. D.G. Morrison USA RT. — Wed, 26 Mar 2008 04:58:00 GMT

Google virus caused my Compaq Presario SR1504X to crash repeatedly ;& as I was rebooting a Chinese script of idiograms apprear right to left. It has been 10 days of wrestleling with the google viruis as it continualy rapeates and eats up the progrming ??????!!!!!!?????? Help? yours truely DGM 03/25/2008 09:57pM or 2157hrs Dgm1492@yahoo.com / Dgm1496@hotmail.com

re: Disk encryption: Balancing security, usability and risk assessment

Hans — Wed, 23 Apr 2008 00:54:40 GMT

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

re: Disk encryption: Balancing security, usability and risk assessment

James — Fri, 25 Apr 2008 04:28:46 GMT

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.

re: Disk encryption: Balancing security, usability and risk assessment

Pierce — Wed, 04 Jun 2008 18:29:29 GMT

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!

re: Disk encryption: Balancing security, usability and risk assessment

Kim Pollard — Mon, 23 Jun 2008 18:16:21 GMT

Russell, is that THE Russell Humphries from HT days in Crawley? Email me on kj@pinewoods.freeserve.co.uk!

Kim (Trevett then!)

re: Disk encryption: Balancing security, usability and risk assessment

joel — Sun, 29 Jun 2008 22:59:26 GMT

inrersante pero no comprendo nada

re: Disk encryption: Balancing security, usability and risk assessment

Russ — Mon, 11 Aug 2008 18:25:10 GMT

" 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.

re: Disk encryption: Balancing security, usability and risk assessment

Ivan — Tue, 23 Sep 2008 07:01:19 GMT

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?