Bitlocker hack is easily prevented, Microsoft says A disk encryption system built into Windows Vista remains a viable way to protect sensitive files, according to Microsoft. In a blog posting, Russ Humphries, senior product manager for Windows Vista Security, outlined simple steps that users can take to prevent an attack laid out last week in a high-profile research report. He …
"According to Humphries, the hack is easily prevented. Users can configure BitLocker to prevent a PC from booting, or resuming from hibernation without confirmation of a password or a second key contained on a USB stick."
I'm confused, isn't bitlocker a software solution? Therefore it requires booting off the HDD internal to the laptop that contains the bitlocker boot-time software.
My understanding of the hack was that you plug a USB drive into the laptop, then reboot the laptop and have it boot off the USB drive.
If this is the case, the bitlocker software would never be executed, as the old boot drive that contains the software is not booted off of, thus bitlocker would never start and wouldn't be able to prevent the laptop from booting.
Or do I misunderstand how bitlocker or the hack works?
"..Users can configure BitLocker to prevent a PC from booting, or resuming from hibernation without confirmation of a password or a second key contained on a USB stick.."
What if the memory modules are unplugged from the PC after power down and plugged into another PC (or specialized hardware) to be accessed directly after bypassing the OS?
After all disk encryption is meant to protect the data even when the OS is not running.
Humphries did not demonstrate anything. He's making a sales pitch. His advice does nothing to address the issue of the RAM being removed from the targetted computer and installed in another.
The only way to address the issue is to turn off (not sleep) the computer at least 10 minutes before it gets stolen. If the OS will not write the encryption key to disk when it hibernates, you can resort to hibernating at least 10 minutes before the computer gets stolen.
I'm not sure the password-protection for boot/resume are relevant here. The point of the attack is not to boot the existing OS, but to boot _another_ OS (from a USB key, say), and use the crypto information stolen from the DRAM to mount the laptop's disk.
It is not at all clear to me from Humphries post that the password protection can prevent this --- he refers to it as an option "that will not allow a machine to boot – or resume from hibernate ". That sounds to me as if the OS still has the encryption key, in DRAM, and is asking for a password to resume. It does not sound as if it's hidden the encryption key somewhere where it can't be sniffed off the DIMMs.
Perhaps Vista does something more subtle than this, but that's certainly not ascertainable from Humphries' post.
"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."
Anyone who is going to be performing this sort of procedure, would be coming more from the industrial/business espionage angle, than an opportunistic thief.
This will not rule out the possibility that an opportunist might carry around these sorts of tools to maximise his potential income from any swiped lappy.
One way to prevent this that's invisible to the OS is to change the memory controller a tad.
* Add a random encryption key to it during manufacturing
* Add some logic so that it can encrypt/decrypt something like AES
* Make the controller encrypt everything that's stored in a memory block flagged as no-execute
* Let the disk-encryption software tag the memory block containing the key as no-execute
Performance will be affected to some extent, but since any application that uses a lot of cpu should fit in the cpu's cache anyway, it shouldn't be too bad. The memory blocks will hardly ever be modified, and forcing the memory controller to read in chucks of 128 or 256 bits (an encryption block) should only be a problem if you have a gazillion jumps in your code - which is a bad thing anyway.
I'm sure that Microsoft et al wouldn't mind that it'd be yet another piece in the pussle to enforce DRM either, so adding OS support shouldn't be too much of a problem if required.
So, someone want to call Intel and tell them to do it?
Cause I read the beginnings of the paper, and they _are_ aware of BIOS locks, and they propose to have a machine ready, freeze the ram, cut the power, and transplant on a different machine to examine memory content.
In this scenario, it's even worse cause the attacker could use his own ram for the OS that's examining the frozen RAM's content, and not have the OS clobber the data on them.
Be honest here - this is a ridiculously unlikely scenario.
If I wanted the data off a machine, it would most likely be much easier to read the password keystrokes by monitoring RF emissions from the keyboard during logon. And I firmly believe that's a stretch.
Better security topic: banks that still use only username/password credentials for logon.
Geeez.
Using compressed air to cool a chip introduces moisture (cold air CANNOT hold as much moisture as warm air, hence condesation). Therefore you risk shorting the chip, I know I've seen an server engineer blow a power suplly because the prat dusted it whilst powered on.
Second, you will need a system with compatible RAM, so simple answer is to use a crappy laptop, as the spooks proberbly use some super-duper kit, just like the real to life CSI...
"Using compressed air to cool a chip introduces moisture"
That's a negative... most decent compressors will have a moisture dump somewhere because when you compress air, it cannot hold the water the same so it condenses at that stage.
Having the device cold might encourage moisture in the surrounding air to condense, but this would only happen in a humid/hot environment.
That brings me to my point... this attack is obviously easier in the british winter (cold air/components already), so for secure computing we all need to move somewhere warm.
And of course, the gubermint should pay for this as part of it's "protecting people's data".
Who's with me?
I'll leave my coat here as I'm going somewhere warm!
The hack gets the key from RAM. So if you configure BitLocker to forget the key when it goes into sleep/hibernation (and it overwrites the key in RAM), then an attacker getting a laptop in sleep mode/hibernation isn't going to be able to retrieve the key using this attack. (Because the key isn't going to be in RAM any more, even pulling the RAM chips out and putting them into another PC doesn't help).
Obviously if you do this then the user is going to have to re-enter their BitLocker password when they resume the laptop. So Microsoft quite reasonably made this an option, so users can make the security/convenience tradeoff. (There might be people who find this too inconvenient, turning it off is still more secure than uninstalling BitLocker).
I'm making some assumptions here, and I don't know enough about how BitLocker works to know if these are reasonable. E.g. I'm assuming that BitLocker actually overwrites the key in RAM when suspending, and there aren't any bugs in that code.
Noone has addressed the "you can stick a 2nd key on a USB stick" work around? If the data is read directly from the key, and the key is removed how can the machine's data be snaffled?
I am actually genuinely interested if there is even a theoretical way round the not having half of the key in the RAM.
You know, RAM is not at all like disk storage and can be wiped at shutdown.
I would bet any one of you could write that little hack in your sleep.
With one hand tied behind your back (kinky programming is sometimes the best.)
(I will write it if I ever care who has access to the crap I have loaded on this thing.)
Why do people spend so long and so much effort into cracking encryption schemes? I bet 99% of hackers couldn't do what they do off their own back, they all use knowledge that someone else researched. Sure, an encryption system might have some holes in, but those holes are a *lot* more severe if someone takes the time to find them, and then make them public. Windows/Linux/OSX probably has some gaping security holes that no-one knows about and therefore no-one can leverage. It's only when some prat finds them and publishes them that they become a problem.
You'd rewrite a BIOS specifically designed to do this, no booting of OS needed. I mean, if you have to put the RAM into another machine and then boot an OS, aren't you running the risk of overwriting the very data you're trying to recover? So the BIOS version would just read the ram and write it out elsewhere.
"you configure BitLocker to forget the key when it goes into sleep/hibernation"
This is already an option? Does anyone at MS know? Why has the company's official response failed to mention this? You'd think they'd be rushing to point out that their product already has an option that protects against this attack. Perhaps their PR department is so used to apologising for bad security that they didn't bother to check whether there was anything to apologise for in this case.
Saint Bill icon, because I'll probably never get another chance to use it.
@AC "BitLocker password" is a bit of a misnomer. The password is used to access a key that is already there on the disk but encrypted using your password- a large fraction of an OS needs to be running before this can be done from the documentation that I've seen on the microsoft website. Their "full disk encryption" option requires an unencrypted partition, and they recommend that this is 1.5GB - which (to me at least) stops it counting as "full disk encryption". The linux equivalent (dm-crypt) can manage with about 20MB unencrypted on disk, and I've been using it transparently (apart from needing to type in the password on boot) for several months now.
@Fraser: Assuming that you're not using a hardware disk encryption device (e.g. you're using something like bitlocker or dm-crypt) a "key" will have to be in RAM at the time the data is encrypted/decrypted. If you have an OS that doesn't constantly read data from disk, then you can keep erasing the key from main memory and re-accessing it from the external device - but given the way that caching & other disk technologies work, I'm not sure that's an option really. Certainly my windows laptop seems to keep accessing the HDD - linux seems a lot tidier in that respect, but that's not an objective analysis.
The "simplest" answer would be to have removable disk controller logic to do the encryption. That way the OS doesn't even need to know it's there, and your vulnerability is limited to a very small/portable device that you can keep with you. Obviously, since this is an off the cuff idea, it's probably fatally flawed in some way *grin*.
everyone seems to be arguing about whether or not this is possible...
let me put a stop to this elreg dilemma by answering quite succinctly the answer to your internal dialogue...
USERS ARE GENERALLY TOO DUMB TO RUN ANTIVIRUS SOFTWARE! COMPANIES HAVE BEEN EVEN DUMBER, I DON'T NEED TO MENTION THE ISSUES WITH GOVERNMENT.
From a technical standpoint the will it won't it scenario may be entertaining to ponder, however the truth of the matter is this IS an issue, one which most are ignorant of. The most important thing is to identify the "at risk" of being attacked groups, and as we've already established a skag head looking for a fix probably won't come prepared. When it comes to the game of espionage you can bet your life that people will come prepared...
This isn't something you do when you're looking for a bit of "H" this is the kind of hack you do when it is very important to you as an individual/organisation to retrieve the information encrypted on the machine, and for those people the microsoft advice still won't help, as most of those who are at risk of this type of attack will probably ignore it too...
Sure, you can make machine wipe its RAM on shutdown, or on hibernate, and you can make it so that the machine won't boot without a password, but as long as the chhips are accessed "normally" and the keys you're interested are in memory, it *still* doesn't protect against cooling/freezing the chips while the machine is running, yanking the power, and dropping the chips into another machine for content recovery. Of course, if you have the machine running, why not clone the drive...
I wonder where in the memory the key is stored - if it's in the part of the memory soldered onto the mobo of your laptop, I'd like to see anyone get at that. If the attackers are the sort that have access to a logic analyser and whatever else is required, you can bet that they are also organised enough to have Other Means of obtaining the key. (I'd imagine something along the lines of kicking you until you tell them)
All security measure (well most) have the weakest link at the user...
except these tools...
as far as I under stand the problem is that on boot you enter your password, this forms a vital part of the encryption/nencryption process, and that's why it's cached in the RAM, else everytime the system needed to read/write data you'd have to re-enter the password...
thus the key is stored in the RAM and is recoverable...
simple answer, don't store the data in the RAM, store it in a USB dongle or smart card etc.
of course then you have to realise that when users know that they need said USB device always plugged in to be able to read/write data from the disk, or always have the smart card pushed in the slot then they'll tend to leave said smartcard/dongle with the PC... so nothing is really changed here...
i.e if the laptop is stolen then the key is stolen with it...
thus caching the key is the lesser of two evils as this seems only fallible to highly unlikely attack.
of course, what should happen is that when the device shutsdown/suspends/hibernates the key should be erased from the memory.
Is there any way to easily turn Vista off from the Start button? The normal power icon puts it to hibernate - you have to click the "more", then explicitly shut down to turn the damn thing off... Or just press the power button, but how many times have we all done that to hear "Joe User" shout "Oooooh! You can't do that! God kills kittens when you do that!"...
Oh Andy, Andy, Andy.
"Why do people spend so long and so much effort into cracking encryption schemes?"
Why do people climb mountains ?
"I bet 99% of hackers couldn't do what they do off their own back..."
<sigh>
First up, that very much depends on what your definition of a "Hacker" is. I'm not going to get into that to deeply here, partly because I doubt that this proportional font will allow for a decent ASCII Venn diagram, so lets just make a simple (and largely imaginary) distinction between between, say, the Eric Raymond/Stephen Levy model, and, say, the Phrack/Cracker model* of a "hacker" and, pausing for a moment while you google that, assume you mean the latter.
If you were to read the paper describing this attack (I assume you haven't), once you've got past the "neat!" reaction, you would see that, in fact, it isn't all that sophisticated. The cleverest parts are the algorithms for detecting the key and recovering keys from partially degraded images.
Clever, but not rocket science. Basically, anyone with the relevant background in CS and math and the will to do so could come up with this. It's true that the many hapless sKript kiddies of the world who consider themselves 1333t d00dz because they downloaded the latest version of Nessus are going to find such things a bit beyond them, but unfortunately for your argument, the kind of people who craft real 'in the wild' malicious attacks are way past this level.
Lets say we assume a normal distribution for the skill level of the populace of "hackers", the point at which this attack could be crafted is somewhere to the left of the middle (IMHO). Obviously this is subjective, but at any rate, I suspect your 99% figure ifsway of the mark, let's be generous to the guys who crafted this and say <=50%, because some of it is quite nifty. That's still a big gap.
"...they all use knowledge that someone else researched"
Certainly your malicious geek will use any public sources of information s/he can get their mucky little digital paws on. But that's by no means the end of the story.
"Sure, an encryption system might have some holes in, but those holes are a *lot* more severe if someone takes the time to find them, and then make them public. Windows/Linux/OSX probably has some gaping security holes that no-one knows about and therefore no-one can leverage. It's only when some prat finds them and publishes them that they become a problem."
Some more googling for you, I'll give you the link this time :
http://www.google.co.uk/search?source=ig&hl=en&rlz=&q=security+through+obscurity&btnG=Google+Search&meta=
And read this, particularly apposite as it's author is one of the foremost experts on crypto security :
http://www.schneier.com/blog/archives/2007/01/debating_full_d.html
Again, it's a long and tedious (and far from settled) argument, but in this context, there is far more risk to the users of such a system if the vulnerability is not disclosed, since they will continue to trust a system that is not providing them with security that they think it is. Contrary to what you seem to be perceiving there are a lot of capable people doing exactly this kind of research and not publishing anything. Exploits leveraging vulnerabilities that have never been publicly disclosed appear all the time. Want some numbers ?
http://osvdb.org/blog/?p=227 **
I can see how you would have formed such an opinion, since the contemporary "Security Community" seem to be obsessed with winning their spurs by breathlessly publishing POC code***, some of which later turns up in real exploits, and there are some merits to what you say, but the situation is nowhere as clear as you make it out to be.
*These models are for illustrative purposes only, I am all to aware of their faults, so please don't bother. Been there, participated in the flame wars, got the kill files, over.
**Other opinions are available, but some of them are from Graham Clueless.
*** Some (by no means all) "security researchers" disclose to vendors first, with varying lead times, in order to give the vendors a heads up and a chance to patch the vuln. YMMV
Well said! "Security by Obscurity" is a myth, a cypher is only as secure as the weakest link; you could argue Alan Turing was "spending too much time and effort on crypto cracking schemes" ... yet he didn't publish his findings. So while the Nazis thought they had an uncrackable Enigma cypher, GCHQ was happily reading along all their messages. A pseudo-random number generator exploit opened up the Lorentz cypher too, and incidentally led to the first computer in the world (Colossus).
Anyone who thinks the "RAM cooler" exploit is overkill should read Schneier's stuff, even if you'll end up being more paranoid than usual. I think I'd rather have some specialized hardware doing the crypto for me, and using a smart-card for keeping the key instead. That way, you'd be able to take the smartcard out when going to the loo or whatever, therefore trumping the "sooper sekrit ninja attack" described here. ;)
"A pseudo-random number generator exploit opened up the Lorentz cypher too"
Although, interestingly, the root cause of this was a very serious failure in operator protocol. As I understand it, an operator sent* a very long test message, and then sent almost the same message again after resetting the machine. The fact that the message was not quite identical** gave the allies a "depth", which allowed Col. John Tiltman to decipher large portions of the it, opening the way the for further developments (like Tutte's rather clever 'double delta' attack on the Lorenz PRNG) which then led to the automated breaking of the Lorenz cipher on an industrial scale using the Collosi and their precursors.
So in effect, Lorenz's security was originally busted by a user who didn't understand the operating protocols enough to realise that what he was about to do was really, really stupid.
It's amazing how little can change in ~67 years.
Black chopper (fnarr) because BP was on the QT
* August 30 1941, both messages had the indicator "HQIBPEXEZMUG", if anyone's interested in such trivia, or wishes to google it further.
** Had the messages been identical, they would not have constituted a depth and Tiltman et al would likely not have broken them (due to the nature of additive ciphers. GIYF)
I'm not important enough to worry about Cryo-Cyber-Ninja's. Truecrypt is probably just fine for protecting my bank statements.
For all the tinfoil hats out there, however I suggest taking the RAM with you when you go poop. Then you don't have your .jpgs of secret stuff in the plain in the RAM. Plus, when the aliens kick in the door and demand your RAM, you can crush it. Just to annoy them though, as their aliens, they can read the PW from you mind.
Bounty
"He said BitLocker allows administrators to remotely change protection settings by having a script execute."
Guess what? if "administrators" can do it, *anyone* can do it if they're willing to violate the law - and it would appear obvious that cracking encryption is likely to be illegal.
This is the biggest flaw in *all* versions of Windows, not just Vista - practically every "script" is ActiveX, which has *no* real security.
"Windows/Linux/OSX probably has some gaping security holes that no-one knows about and therefore no-one can leverage. It's only when some prat finds them and publishes them that they become a problem."
When security holes are found in Linux, they're normally fix in a day or two.
When security holes are found in Windows or OSX, they're normally fix within months of the public announcement by the disgusted security researcher who originally told MS or Apple about the problem in the first place, a year previously.
It works like this: You have a gold min, and a nice fence around it to keep people from helping themselves to your gold. Only the fencing contract ran out of wire before he finished the job, so there's a gaping hole in the fence back in the woods where you've never noticed it. Now,if an honest person walking the fence notices it and tells you, you can fix it. But if a gold thief wanders through the woods and finds the hole, he's going to start pilfering your gold, and while you may notice it's gone missing, you won't know how, and you won't suspect there's a hole in the fence back in the woods because you've never seen that hole.
So it's much better to have honest security researchers find the holes in your security and tell the world, because that way the holes will get fixed, sonner or later.
I can only make out one person who has really pointed out what is going on, so I will give it a go explaining. The reason the hack is hard to see, is because quite frankly it is quite odd, but something to bear in mind.
The key is held in volatile memory eg RAM, because people assume that when power is removed from volatile memory all contents are erased, the developers of the encryption system have not protected the RAM if moved to another machine, they have overlooked that possibility. Volatile memory by name is just that volatile, but it is not instantaneous and can be altered to a degree by manipulating temperature.
The hack is about freezing the memory and extending the voltile life span to a time period long enough for them to move the memory over to an environment they control.
Memory is somewhat protected in most modern operating systems, so if someone cracked into the machine whilst the key was in memory they would still have to defeat the operating system memory protection. If the machine was rebooted then the BIOS may very well zap the memory contents on reboot; depending upon settings. So, their hack is a way to show how even with these security elements in place it is possible to read the key from main memory.
In truth you are more likely to have the key read by someone breaking the OS memory protection, but this hack avoids that issue completely, though the solution to both styles of attacks is the same.
The moral is quite simple though - do not cache the key in memory and rewrite the areas of memory which the key has touched when applied. But, of course when you do that then you have to keep reentering your key, which most users would deem as reduction of usability. So, they are looking at the halfway stage where you just remove the key at certain points, perhaps when the screensaver kicks in, or hey why not when someone opens the box, yes quite a few boxes come with tamper alarms.
The hardware solution of using another chip to provide encryption of the key is an idea, but it would have to be tamper proof or it to could have the same freeze treatment.
As security hacks go this is low on the threat level, but it is a real hack, someone has thought outside the box on this one, and challenged the notion of volatile memory not being quite as volatile as people tend to assume.
Sorry but I know a far easier method of cracking files protected by any encryption software that relies on a key entered by a user.
In fact I know two.
The easiest one is to read the password directly from the Postit pad the user wrote it on.
The second method is to continually beat the crap out of the user until he enters the key for you.
I submit these are easier and far more practical methods of de-encryption than the one put forth in the article.
I agree, we have seen that details of anonymous bank accounts are worth £10Million at least in an open market, including reselling it to each government,
Petrobas in Brazil had details of a huge recent oil discovery boosting national oil reserves by 50 percent, someone nicked latops and hard drives from a container secured by Haliburton in Rio. These may not have been encrypted but they should have been.
Spending $500,000 on getting the data in either case would be very, very cheap, you could build custom hardware to help speed up the job & smooth over any snags, research common models and quickest methods in a lab setting.
I suppose most of us would like to run a custom superhero hideout creating new gadgets to fund the luxiourious lifestyle of white collar crime, daring adventures into Brazil, Africa, China and Milton Keynes, to steal precious secrets for millions of dollars in Bearer Bonds. With a the coporate private security chasing you in high speed pursuits though glittering cities.
Paris, because I got carried away and need to monitor the racks :(
I have read this thread with interest and as I use bitlocker thought I would have a look at some of the available settings
I already have the computer set to require re-insertion of the bitlocker usb key after hibernation and I have disabled sleep mode altogether.
the pc will automatically hibernate when I shut the lid and hibernates after a pre-determined period of inactivity.
but when it hibernates is the RAM overwriten?
The closest I could get to finding out from within the settings is this rather vague and unhelpful setting in the console.msi
//prevent memory overwrites on restart// (currently off in my config)
"Description:
This policy setting controls computer restart performance at the risk of exposing Bitlocker secrets. Bitlocker secrets include key material used to encrypt data. This policy setting applies only when Bitlocker encryption is enabled.
If you enable this policy setting, Windows will not instruct the computer to overwrite memory on restarts. Preventing memory overwrite may improve restart performance, but will increase the risk of exposing Bitlocker secrets.
If you disable or do not configure this policy setting. Microsoft Windows will help ensure that Bitlocker secrets are removed from the memory when the computer restarts."
So what is this telling me?
that;
if I just shutdown the memory is or is not overwritten? (don't know)
if I just hibernate that the memory is or is not overwritten (I now doubt it is)
so the only way to be sure according to this, is to restart the machine but then not insert the bitlocker key so that the memory is instructed to be overwritten but new keys are not inserted because the boot will fail.
Hmmm seems a bit of a pain in the arse when I want to go poo.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
