Security boffins unveil BitUnlocker

Boot from external HD

Anyone who needs encryption and has a little common sense would disable booting from external devices.

Time to turn on power-on test of DRAM at boot?

Subject says it all - MBIST of the DRAM on power-on will wipe the contents. Of course, it also slows boot and is therefore not turned on by default for most/all PCs, I think.

Time for a BIOS patch?

"quickly re-booting"

A Windows machine that can reboot in less than a minute? Pull the other one.

Change your BIOS

So it looks like the memory-reading software has to be run from a bootable external device. In which case, it's a simple matter of changing your BIOS settings to that external devices aren't in your "boot device" chain or at least are under the internal drive so C: is booted from first.

Password-lock the BIOS for more security.

OK, someone who's *really* determined could swap out your internal disc and boot from that, but they'd need to know in advance that they'd have to do it thus reducing the chance of them getting to the memory before it "faded".

Still very interesting though.

@Hugh McIntyre

Apparently the liquid nitrogen trick extends the life of the charge in the DRAM long enough to let an attacker remove the memory and install it in another computer.

@ Christoph

I guess the obvious solution is to disable booting from USB in the BIOS and password protect BIOS access. Such a delay should be plenty to allow DRAM contents to dissipate.

Ckever, Clever

Most impressive piece of work......

So - IS this a serious exposure?

Well, actually - no, not really. As already observed the window of opportunity is tiny and and if the machine is locked down and prevented from booting from an alternative drive then its cirumventable anyway (and really, business laptops really should have booting from USB etc disabled by default).

This is all about context. Its a physical cirumvention of encryption routines that in themselves remain sound (no-one has bust the algorythmn). As such, its a kind of evolutionary dead end.

But still ever so smart.........

To Anon quickly rebooting

Who Says it boots into windows to recover the keys ?

Disable booting from USB, even better would be enabling the bios password so the machine wouldn't boot.

Though with my experience of users that would be way too simple, they would rather boast about the encryption they just had to install becasue theyre such important people

Missed the details?

Is it me, or are a few of the comments so far missing some vital detail?

You DON'T need to perform the trick in a van outside; the key is cached in memory while the computer is still powered. You can stick it in the boot, drive home, and do it there as long as the battery lasts and it doesn't have some shut-down power-saving feature enabled.

@ Wyrmhole

Have you noticed them removing memory chip from the laptop and putting in another one? It can be overridden. Anyway, testes with my Ubuntu test machine. Damn it works like that.

ARGON, ARGON, ARGON ;)

the attacker needs to get physical access (basically, steal the laptop)

Um, yes, but the whole point of bitlocker is to prevent people getting at your data if they steal the machine.

@Ash

That assumes the system is set to cache keys indefinitely - not a good idea, and the user is asking to have their data stolen if they're so lackadaisical about encryption configuration. My system is set to not cache keys at all, and IIRC the default setting (with my software) is to only cache for two minutes - that's not with BitLocker though.

Then again, if you're serious about encryption would you have accessed the keys in a public location in the first place (considering oversight risk)?

This won't be the end of it

Let's say the attacker really have a complete and intact image of your RAM. An update to the encryption software can in a future revision dedicate say 64MB of RAM to store the key (that is say 2K). It can be stored at any location and scrambled. Just keep the offset of the key somewhere else, not in RAM (register/hdd?). If the attacker has the image of the RAM he can identify the 64MB zone where you have the key but he doesn't have the offset so he needs to try a lot of possible keys (about 64milions). I imagine this methond can be elaborated further.

Also consider a machine with soldered RAM if you are concerned :) Further fixes may be done as noted in BIOS. The good thing is that this is fixable, is not a principle problem, it's just about the implementation.

Obvious really

Probably the right solution is to force the encryption keys to be unloaded at every point which would also cause you to have to have to re-enter your login password later.

screen locks, hibernate, sleep, switch user etc. should all dump/overwrite crypto keys immediately if you have to re-authenticate your login this must be because there is the possibility that somebody else has access to the machine in between times so you should expect to have to re-authenticate your crypto at the same points.

What we really need is a good OS hook that allows any process to be notified of this kind of event and dump any keys that its holding. There are lots of different processes that cache security sensitive data in memory, ssh-agent, browsers holding unencrypted passwords etc

hiberfile.sys

When the machine hibernates it dumps the contents of RAM to a file, so are these keys being saved to the disk if they were in memory at the time?

If you really want the data that much...

...just clobber the guy over the head, and take him to your local disused warehouse to torture until he gives you the key.

Ignoring the TPM issue, this strikes me as all possible in theory, but if you're that desperate, there are simpler ways of doing it.

I *could* break into my office here by spraying the CCTV lenses with paint, shimmying up the wall to the 3rd floor, cracking the 3 digit keycode on the roof entrance, clambering down the disabled lift shafts to the basement, and coming up to the ground floor through air ducting.

Or I could just drive a car through the window, take what I needed, and be away in 10 seconds.

@Stephen Booth

"Screen locks, hibernate, sleep, switch user etc. should all dump/overwrite crypto keys immediately if you have to re-authenticate your login this must be because there is the possibility that somebody else has access to the machine in between times so you should expect to have to re-authenticate your crypto at the same points."

Excellent idea, and presumably far from obvious since the previous zillion people didn't suggest it. MS could put this solution into next month's Patch Tuesday bundle. In the meantime, laptop users should simply do a proper power off rather than a snooze. There, nothing to see here. Move along now.

Idiot-proof encryption?

A bit OT, so apologies....

I'm probably very low-tech compared to other readers of El Reg, but can anyone recommend anything good for encrypting a backup on an external USB drive? (People seem to be slating BitLocker, so anything that will work on non-Vista Windows?)

People may have scorned the backup device a few weeks ago which didn't do partitions, but it was aimed at the other 99% of computer users. A 'normal person friendly' encryption solution, which doesn't talk about algorithms or bit lengths, really would encourage people to encrypt things. These things start at home, and I'd hope that if people working the public sector found encryption at home, they'd probably implement it at work too. Which would be nice when things inevitably go wrong.

So is there anything Windows-based which is idiot proof and 'just works' out of the box?

Read the paper, people

There's a lot of very ill-informed comments here - anyone actually interested should really read the paper, which is well written and thorough. A couple of key points:

- Yes, the attacker requires access to a powered on laptop. However what most people seem to be missing is that this includes laptops in standby mode, as the DRAM is still being refreshed. In my experience, most laptop users, if given the chance, will choose to standby rather than hibernate or power off their laptop to save time when they come to 'switch it on'. It is then vulnerable to this attack. Anyone implementing full-disk encryption products would be well advised to turn off the capability for users to put their laptops into standby.

- BIOS password protection, key overwriting etc. etc. are all useful to an extent in that they make it a bit harder to from numpties to get access through a simple reboot to a flash drive. The problem is that you can't _know_ whether the person who stole a laptop was had enough knowledge to cool the DRAM and move it into another computer or not - and the technique is relatively easy and requires no special kit that can't be easily and cheaply purchased. Because they can't be sure this didn't happen, most organisations would have to treat the data as compromised anyway.

@OviB - there's no need to scramble the key, as any useful key should look like random data anyway. However, in order to implement an encryption product that works at a reasonable speed, you also need to store a whole load of intermediate structures derived from the key, called a 'key schedule', and these are recognisable and too large to go in registers. The authors constructed a program that automatically scans the entire RAM contents for structures that look like key schedules. The only way around this is not to store the key schedules in RAM, but then the encryption product has to work them out from the encryption key for each block read/write - which is SLOW. So none of them actually do this. You might say you need to scramble the key schedule. But how do you scramble it securely? The only way is through encryption - and where do I put that key/schedule? :-)

The net/net is that if

- You're not using BitLocker encryption with a TPM in basic mode (BitLocker in advanced mode with a USB key is no more vulnerable than any other product)

- Standby is disabled

- Your users don't leave a powered on notebook alone at any time when it could be stolen

You should be relatively safe against theft. But if someone does managed to nick a powered on laptop (e.g. cleaner lifts it from someone's desk as they go to the loo), you're _really_ not - even if the laptop was password locked and full disk encrypted.

Defending against this is HARD. The only real mitigation is to move encryption/decryption away from general purpose PC hardware and do it all in specialist tamper proof hardware which zeros the keys if anyone tries to physically tamper with the chips. Organisations with a real need for security combined with automatic operations - like banks with ATMs - have been doing this for ages. But it is expensive, can be attacked physically with enough resources - http://www.cl.cam.ac.uk/~sps32/ECRYPT2006_part1.pdf - and even some high-end implementations have been fooled into disgorging keys - http://www.cl.cam.ac.uk/~mkb23/research/Attacks-on-Crypto-TS.pdf

Points Taken

Yes... I rather neglected the thought that being in standby would keep the RAM 'hot' as it were. Too early in the morning, too little coffee...

But someone made the point that this is indeed fixable - its not an inherent weakness in the encryption design......

After watching the vid and reading the original article

I was pretty impressed with the spray duster method to ensure transfer the RAM into another (suitable machine).

Firstly with a fully encrypted filesystem and the joys of virtual memory and all the fun (modern) OS stuff, I doubt that you would be able to reliably dump the encryption keys from RAM and have the machine come back up reliably (Windows is unreliable enough), the same goes for hibernate.

Telling the encryption app to only cache the key for a few minutes isn't much use on a fully encrypted HD as there will be files open on the drive, and process running (and using the drive while you are away from it)

With the PGP disk function, it only clears the key if there are NO files open on that volume. How often for example does windows leave a file handle open (The answer is too often).

As I didn't get a chance to point out (cos I'm supposed to do some work during the day) It's easy enough to get enough time with a laptop, due to the batterys in the thing (and 2 or 3 seconds with a decent pair of cutters removes any tethering)

It's all down to users using their machines properly in the 1st place

I remember demonstrating RAM fade on a Sinclair Spectrum, by constantly resetting the R register to disable RAM refresh way back in 1983 (I'm sad enough to still have the source code written down somewhere)

Err...

I'd like to see a machine that has been working for an ammount of time survive having liquid nitrogen poured over it. I'd imagine that this would take the HDD well below it's minimum operating temp, probably screw any fan bearings and if your processor is in ceramic package it may well crack.

Other than that it's a great idea with no flaws whatsoever...

corrupt data?

"So, you explain about corrupt data (in this case) not being flushed by a simple 'restart' - and six months later the call is repeated by the same user."

What operating system/program depends on RAM contents on power up corrupt or otherwise?

If a cold boot fixes a problem it is fixing locked up peripheral hardware not 'corrupt' data in RAM.

It is fairly well known

Memory has always been a problem that most encryption systems tend to ignore, not due to ignorance but due to complexity.

Normally it rears its head during encryption and decryption where the data is in the plain - it has to reside somewhere.

This one is quite easy to solve though - flush (send gibberish to it) the memory just before power down. And to be fair the window of opportunity is quite small. For the screensaver attack, well yet again you have to be careful about the time the key is in memory and write gibberish to the addresses when not in use.

I am more concerned with how to keep data secure when it is in its plain state, that one is a lot trickier, probably need some hardware control there.

But, this does highlight the fact that encryption is not enough in itself. Encryption forms part of the security model, the major part but you still have to secure that process itself. This is why people do moan when the government says they will just encrypt their drives and all will be well, but really that is not enough and could give a false sense of security that is then leveraged. I reckon they won't even stay the course on encrypted harddrives, it is much harder to use your systems when the harddrive is encrypted.

They will unfortunately move to centralized and when they do they just put all their eggs in one basket, hopefully a secure basket but still a basket where all the eggs are. Better would be a shared system for 4 or 5 people, a hub that communicates with central, and only hubs are allowed to communicate with central, this starts to layer the defense in.

@ Chris

"So is there anything Windows-based which is idiot proof and 'just works' out of the box?"

No.

In fact, nothing is idiot-proof; every time we think we've idiot-proofed anything, along comes a more ingenious idiot.

Now, honestly, were you *deliberately* trolling with the juxtaposition of "Windows-based," "idiot-proof," and "just works," or was that serendipity?

@Tim Spence

"and take him to your local disused warehouse to torture "

Boy you are behind the times, no one uses warehouses these days, it's Deigo Garcia so the torturers, sorry I meant very nice CIA/MI6 personnel, can get a tan between torture sessons, I also hear the mess bar does some wicked cocktails.

Easy fix?

On a system that utilizes a write-back cache, perhaps it's possible for the O/S to ensure that the encryption key remains in CPU cache since it's probably used a lot anyway. The CPU cache is SRAM so once the power goes away, so does the data.

I think this technique may also protect against vulnerabilites where a rogue device could read arbitrary memory using DMA. I'm not that much of a PC hardware expert so I don't know if DMA would allow a device to read from L1 or L2 cache.