just use a CO2 extinguisher in case you are missing that N
BitLocker, meet BitUnlocker. Word arrives from The Electronic Frontier Foundation that a crack team of researchers - including the Foundation's own Seth Schoen - have discovered a gaping security flaw in everyday disk encryption technologies, including Microsoft's BitLocker as well as TrueCrypt, dm-crypt, and Apple's FileVault …
just use a CO2 extinguisher in case you are missing that N
I was taught years ago to cache encryption keys for as short a time as possible. It seems to me that the window of opportunity for this mischief is very small indeed - the attacker needs to get physical access (basically, steal the laptop) and perform their voodoo straight away - say in a van parked right outside - and that's going to be expensive. Or they'd have to get to your desktop while you're out of the office - but if they can do that, they can install a keylogger and audio bug anyway.
And one minute to get to the memory? It takes me longer than that to put the laptop in the carry case.
Of course, physical security underpins data security every time, so if you are serious about encryption, keep your laptop on you or locked away - that really goes without saying.
The TPM aspect may change things, but since I don't use one, I can't really say.
that if it's possible someone will use it, and one if person uses it many will try. It may not be elegant to take a fire extinguisher to a PC or laptop but I have heard of people doing more than that to get at money which is what the data is. I have to go back to my original basis it's not possible to secure a computer 100% mostly this is something I believe (I can't prove it) but every time I think I am wrong something like this encourages my _belief_. If someone has possession of the device it can be cracked. Anyway my point was this is very bad never underestimate the enemy.
Anyone who needs encryption and has a little common sense would disable booting from external devices.
That's MY laptop in the video!!
That's a pretty damn big hole in encryption security, not your usual "Oh only a serious h4XX0R could execute that" job.
Makes me glad I didn't pay for BitLocker!
Evil Bill, and if I could choose more than one icon I'd have Evil Steve and Evil Penguin up there as well considering this affects all three OSes equally.
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?
A Windows machine that can reboot in less than a minute? Pull the other one.
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.
I think as soon as you get into cooling the laptop itself, it becomes much more complex to do discretely, and to hide the evidence afterwards. The more worrying attack is the 'room temperature' one, where by you could power cycle the machine and dump the memory to the USB drive (as they did), and then leave the scene quickly. The user would just come back and mutter "stupid Windows" at the machine that crashed whilst they were at the coffee machine.
This shows why computer security isn't just about key length and encryption algorithm, and I would hope/assume that CESG haven't become too complacent in this regard.
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.
A window to perform the attack that is measured in minutes at best and requires physical access to the machine.
The threat seems real, but your data is relatively secure, unless you really expect someone (government agency?) to come bursting into your house with liquid nitrogen in hand.
One possible solution would be to have the bios write gibberish to the ram as part of the post. But that could be circumvented by transferring the HD and RAM to another machine they brought with them... Maybe a special module could randomize the ram whenever the power was cut off, but that sounds like it's more difficult than a change to the bios.
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.
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.........
Just enable the memory test in the BIOS! This will test every location to make sure it is working. In the process, it gets written to; and whatever may have been there before becomes lost for all time. The test does slow down the boot-up process, but at least it makes sure the RAM is zeroed out.
Adding an extra couple of minutes to something that only needs doing every few months probably is well worth it, if it makes your computer more secure.
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
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.
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 ;)
Um, yes, but the whole point of bitlocker is to prevent people getting at your data if they steal the machine.
All these comments about the transient window for attacks misses the final point. If a PC has a TPM in it then the window is as long as you want it to be. Nick the PC and cold boot it. You'll have the encryption key loaded freshly into RAM, ready for stealing.
*That* is the "when we say gaping, we mean gaping" hole.
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)?
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.
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
The first thing I did when I got a laptop years ago was to set the bios password. Too many times we had booted a freinds "secure" (windows password) laptop with a rogue CD in childish school prankery.
As far as I am aware you only have to remove the BIOS battery to reset a BIOS password and allow yourself to enable booting from external device. Admittedly it would add a couple of min to the procedure but if you are able to keep the memory cold and viable for 10 min I doubt it would be a problem.
Vista disc encryption: Come on... If it’s that important use something else!
TrueCrypt: Don’t leave your volume mounted when you aren’t there!
First of all - forget the liquid nitrogen, ignoring the havoc pouting that stuff into a laptop will cause, it's NOT what was used, the Reg seems to have employed a moonlighting Sun writer at this point!
The video clearly shows a simple, cheap, safe, pocketable and freely available 'freeze spray' being used (none of which apply to liquid nitrogen, still, it sounds better to some) - NOT liquid nitrogen. Get yer facts right please.
However, the video bangs on about how little known the ability of RAM to retain data after power off is. True. Little known to USERS.
I frequently get the phone call along the lines of:
"My computer's doing something dementoid"
"OK, first of all, have you switched it off, gone and got a coffee, then rebooted?"
"Yes, I've DONE a restart"
"No, NOT a 'restart', actually shut down, waited, then rebooted?"
"Well, indulge me, try doing exactly what I said please, and let me know if that fixes it before we start wasting even more time?"
5 mins later:
"Hey, it's OK now, thanks, why did that work"
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.
Well, it's what IT is all about really, isn't it? Futile attempts to train users...
But, the point here is, I, and I'm sure many others, encounter this regularly.
Describing the ability of RAM to retain data (corrupt in the case of a computer persistently repeating an error, intact in 'normal' use) is hardly "little known", certainly not to anyone reasonably competent at IT...
The only newsworthy point made is that it's been publicly exposed as a data security issue.
ooooh, another cleartext/keys-in-ram-attack.
ok so to get a hold on my data, the guys will need to
1 : have the box powered, and booted
2 : not hibernated in crypted swap (yes, my ram images are in crypted swap. what's the fscking point of TrueCrypting your whole partition if the guy can straight dump it from memory with a fscking PCI card ?
3 : bootable from other mean that i defined. too hard to prevent, seriously.
4 : freeze the damn dram with nitrogen or whatever will bring the temp down enough to stop the bits from flipping. oh. on a electrically powered machine. wonderful idea, really.
and DO THE WHOLE IN LESS THAN IN A FSCKING MINUTE
motivation needed : high
skill needed : high
time available : *very low*
assessed threat level : near nil.
end of processing, have a good day.
btw, the NSA called, they want their paranoia back. NOW.
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?
...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.
"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.
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?
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
Going back 20 years to the good old Amiga days, people took advantage of this memory retention property to rip graphics and music from games by rebooting and then scanning the memory for goodies. There were quite a few tools that could do that. So this technique is NOT new. Did no one at Microsoft have an Amiga? Even when they were writing AmigaBasic?
Even cooler, there were a couple of Amiga demos that continue to run even if you power-off at the mains for up to 10 seconds. Turn the juice back on and the demos continued to run immediately from RAM without any disk access. Proof of the power of memory retention - 20 years ago.
Gary (former Tech Ed of AUI if anyone remembers!)
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......
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)
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...
... with Cloe's help on the upload, all before the President comes back from the bathroom...
"...just clobber the guy over the head, and take him to your local disused warehouse to torture until he gives you the key."
I believe that TrueCrypt lets you create an undetectable hidden partition within the encrypted partition that is accessed by using a different key.
So if you're data is so sensitive that you're at risk of being tortured for it, you'll have good quality decoys on the non-hidden encrypted bit, and will give up those keys after a suitable amount of interrogation resistance.
We're a very long way away from "idiot proof encryption". That said, most people who know little about it gain some limited security against credit card disclosure when they order from an e-commerce site using HTTPS . When somewhat stronger and relatively idiot-proof encryption arrives it is unlikely to be Windows based, as it will be in a security dedicated embedded system that communicates with the untrusted PC using standardised (i.e. peer reviewed and open) protocols.
If the PC is untrusted, the embedded device will display the secret messages or content to be signed using its own display. It will have it's own keypad to input data which has be kept secure. So it will probably look a bit more like a mobile phone than a PC - easier to put in your pocket when you leave the room for a couple of minutes. But for it to be idiot proof you won't be able to download games or ringtones onto it, or mix executable content with message content. So Windows XLS/DOC etc. formats will not be supported any more than downloadable games.
Basically the PC is too complex and multifunctional to be part of a trustable information channel. The crypto we have at the moment tends to treat the PC as trusted and the network as untrusted, but for this to be both more effective and relatively idiot proof it has to be within a device whose sole purpose is providing information security.
The security you can achieve in practice has trade offs and cost-benefit compromises. What I have described above probably still won't protect you against an extremely well resourced and determined adversary. If the asset you are trying to protect is the launch codes for nuclear missiles then high explosives and the capability to destroy keys using these when a device is tampered with goes with the territory. So if you think you really want "tamper proof" rather than just "tamper resistant" then you had better be willing to kill your adversaries to go as far as you can in achieving this.
is it not easier just to stick a thumb drive and just *copy* the data across...
If the session is open, your encryption has just been bypassed...
of course if the session is closed, then you can always try to connect it to a LAN and hack it... or check default shares and copy from there...
"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.
I've never used Sleep or Hibernate ever in my PC'ing life!
My Comp is a Digital thing!
it's either On (1)
or Off (0)
there is no in-between :D
p.s. just in case i;ve super glued the dimms to the mobo!! :D:D
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.
One of my colleagues asks... if you took a few Frappuccino® drinks, and a macbook air, could you do away with the liquid nitrogen?
 I don't like Macbook (Air) systems, so I'd happily lose a few to some liquid inducing experiments
Paris, because she's not cool enough to read your DRAM.
This would be good if they were seizing a computer during a raid, there is a cool kit that lets you splice power for a computer so you can cart it off still running and get the keys.
Also why are people trusting BIOS passwords, most of them have manafacturer overrides which have worked for me, also many boards have a ZIF tool so you can just swap the BIOS chip out with a fresh/blank one and operate as normal.
Given the existence of 'rubber hose cryptanalysis', you'd better hope anyone who might use it upon you is either unaware of the possiblity of 'fake' encrypted partitions, or easily pleased by the goodies you left in the one you've just shown them.
Because if they don't find what they're looking for, maybe they'll just go back to brute forcing *you* in the offchance there might be more keys you're holding back. For the paranoid, consider a law enforcement agency who believes you're hiding something, correctly or otherwise. Especially in today's terrorist and paedophile filled world.
"So is there anything Windows-based which is idiot proof and 'just works' out of the box?"
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?
Gotta love old-tech approaches to data extraction. The cooling thing works much better than you might guess; back when CirKitChill was (legally) sold in cans, a grad student demonstrated by stopping the CPU clock mid-cycle while polling the bits on the bus. Took nearly a minute for the first bit to evaporate.
'81 or '82; Z-80 (over-)clocked at ~4 MHz to zero. (Yes, I *am* an old fart, why do you ask?)
Not that any of your post will mean anything to the Drama Queens.
"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.
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.