cool idea
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 …
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.
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.
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.
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.
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.
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
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?"
"Er, no..."
"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?"
"Er, OK"
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.
soooo scary.
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.
...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!)
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...
"...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.
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.
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?"
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?
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?)
"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.
" ...can get a tan between torture sessons, I also hear the mess bar does some wicked cocktails"
You've obviously never been to Diego Garcia .......
The mess bar is lucky to have fresh beer (what little they have is typically Bud .... eewwww) and there is just *no* decent place to tan.
Never knew spooks stayed up so late, it's a tropical island, its on flickr for the fishing expeditions by US personnel;, you would know that if they let you browse outside the firewall. For heavens sake the fishing maps and geosat photos are available on the web, the SW broadcasts are coming from the Yachts abusing "Ham to internet" links.
Do they ever let spooks out of bed or do they browse the internet all day.
I use SecureDoc by WinMagic, which DOES encrypt the hibernation file as well as every other sector on the hard disk, plus USB devices and CD/DVD data streams if required. It's commercial software but I feel worth the coin. No, I am not affiliated with them, just a very satisfied home user. I think it's worth a plug because it works very well without fuss.
To the other Chris - take a look at TrueCrypt to protect your external USB drive, I used to use it for precisely that reason until I bought SecureDoc.
Looks like you had one too many last night.
"Diego Garcia is a tropical island" - It's an atoll. No civilian population, no families - just a military base with military staff plus a few contractors. The bars are crap and the beer is stale. And you can't pull a bird. No-one likes being stationed there.
"unless you don't have acess to Google you can tan, catch fish..." - So those activities are dependent on having Google? Do I have to apply in advance to the Googleplex, or should I take my chances? You can fish off a rock if you want, but that doesn't necessarily make it a decent place. You can also tan on the airstrip ..... for the five minutes it takes the MPs to see you, grab you and chuck you in the back of the van.
"Never knew spooks stayed up so late" - It's a special deal ... we were waiting up just for you. Then again, maybe we're in another timezone, such as Diego Garcia for instance.
"you would know that if they let you browse outside the firewall" - Who do you think posted the (dis)information in the first place? Now you're thinking, 'was he being serious' or not? I'll leave that up to you to decide.
"geosat photos are available on the web" - Not with the anything worth looking at, unless some colleagues have truly messed up, but I doubt it.
"SW broadcasts are coming from the Yachts abusing "Ham to internet" links" - You shouldn't drink and post online. That's how accidents happen.
"Do they ever let spooks out of bed or do they browse the internet all day" - See above comment.
There aren't actually any spooks on Diego Garcia - it's a plain ol' military base. But I suppose I would say that, wouldn't I?
Sleep it off, peter.
"screen locks, hibernate, sleep, switch user etc. should all dump/overwrite crypto keys immediately"
Isn't that what the Blackberry OS (supposedly) does?? Somewhere deep in the help files, it states that it combines public-key crypto with AES to do this feat: the device's password unlocks the private key. When you "lock" the device, the priv key is securely wiped from RAM, the process is shown by a small "lock" icon that closes when the process is complete. Any incoming info to the device after that would be "encrypted by the public key" (which I assume means "AES key generated, data encrypted, stored, AES key encrypted with public key which then is stored along with data???). Thing is, the method not only protects the device's data while locked, it protects *any new data the device receives while locked*, which really sounds very secure.
So it seems my Blackberry is impervious to this method ... as long as it gets nicked while in "locked" mode. ;)
ummm, this is such an old method of retreiving data - I remember back in the
strong Amiga days having to reboot the machine after playing a game and
then using a module ripper to grab the song out of the machines memory
(a great way to get a tune of graphic you liked out of a game). since nothing
wiped the memory you could easily regain the classic tunes out of SpeedBall 2
etc.
the only thing that never really worked was getting music from a lof of demo disks as they never used tracker formats - or had their own format or special compression
methods or prodedural methods to generate music and graphical patterns.
so yes, its obvious that you can pull code/keys/passwords from the hot memory
of the machine.
but should the system be so insecure as to allow the booting of 3rd-party
media, USB sticks, etc. basic BIOS protection comes in here.
This is all very interesting but as mentioned above it's not news. It's ancient history actually! Two quick points.
1. We used to run old Z80 and 6502 S-100 systems with 16Kb DRAMS (that’s Kb, not Mb for all you lucky young ones). At boot-up, the ROM Monitor (BIOS if you will) checksumed the RAM in blocks before loading the OS from digital tape, and only loaded the blocks which failed. What we found was that it almost never loaded anything at all! The OS image usually remained intact overnight with all power disconnected. We got so used to this that after a while we were surprised if the thing didn’t just prompt instantly.
2. I worked on banking transaction gear for a decade or so back in the '90s. This problem was solved using elaborate and expensive tamper-proof hardware with some high tech Japanese materials (Shin-Etsu) and specialised circuitry. As told above, it’s not easy to solve except by ad-hoc methods.
What we must all realise is that the cost/benefit ratio of the attack has to be considered in all of these cases. If you are trying to grab the master transaction keys of the Bank of England or the activation codes of a nuclear weapon, this stuff is great news for you (if it's still news that is).
But would you expend the effort trying to clap Freddy Smallfry for downloading a couple of hundred MP3s?
Erm, 1 minute is plenty to power off a machine and power it on again? As soon as the powers back on the memory is refereshed again yes?
I have for some time longed for a tool that could pull dump data from the memory of a freshly rebooted PC. Would be very handy for rescuing work from a crashed/locked up machine. Even a simple prog that dumps it to a file/lan. Anyone know of such a boot disk? Or a way of forcing a locked up windows machine to write a full memory dump to disk?
Roger Heathcote
Some of the games for the TRS-80 Colour Computer that came on cassette tape had copy protection and were designed to be difficult to 'back-up' using audio dubbing. In one case, the copy-protected program tape would first load in an auto-executing loader (by over-writing live memory!) that would, in a clever series of steps, change the tape reader routine to non-standard settings and the tape was formatted to match.
It took me many hours of hitting reset and then searching the 32k of memory using a simple BASIC routine to extract the chunks of 6809 machine code. I'd rewrite each code block to load in the next block of the seemingly-endless series of ever-changing auto-loaders. Eventually, I got to the actual program software I was after. Then it was simply a matter of writing it out to a non-copy protected copy on tape.
I think that the ONLY thing that can ever stop a determined and reasonably skilled hacker is when they have children. Then they don't have time for this crap.
Yes, TrueCrypt does let you create an undetectable hidden partition within the encrypted partition. Unfortunately, that ability is too widely publicised to be of any real value at all.
If you do find yourself being tortured for your keys, a really good way to get your fingers removed with a pair of garden shears is to have forgotten to create that second, "hidden" partition. Just about anyone who knows about TrueCrypt is going to know about the mysterious second password, so why would they be satisfied with only one password which reveals only one set of data?
"I think that the ONLY thing that can ever stop a determined and reasonably skilled hacker is when they have children. Then they don't have time for this crap."
Unfortunately, the sort of hacker involved is extremely unlikely to have children, until such time as the various bits of kit advertised in down-market jazz mags are capable of being fertilised.
Which, as I understand it, means that stuff is secured (e.g. encrypted) in a way that it can only be accessed given the combination of something an authorised user will know (e.g. a password) and something an authorised user will physically have (eg a cryptographic dongle of some kind, which have been around for years). How does the cDc sploit work in that picture?
I haven't watched the video but as a qualified physicist and confirmed sceptic I find the concept of a card's worth of RAM contents surviving a machine to machine transfer and surviving live insertion into another machine rather surprising, even after a certain amount of cooling, and not just because of basic electronics principles either. Maybe I should watch the video, but frankly I cba, because if Windows is in the picture, or a typical PC user/PC-IT person is in the picture, there are far easier ways to get unauthorised access to data. Last week I was asked to email my own account name and password to my local HR department to resolve a Peoplesoft problem; that'll work, and there's no risk, right? Or just try "I'm from KPAndersdrive Consulting, I'd like everybody's data sent to me on CD please, but definitely don't send it recorded" - sounds as likely to work as the cDc game.
Long ago I had build a simple OS to replace the crappy TOS on my Atari ST machine. I was designed to take advantage of the fact that after power down, the memory stayed live for about 8 seconds. If my OS gained control before 8 seconds expired, it would actually bring the system back up in exactly the same state as it was before power down.
Funny enough this was needed, since the Atari hardware was flawy and chip subsystems would actually crash while the CPU and memory remained functional. So, this OS saved me from a lot of lost data/work I did on the machine.
It is nice to see that technology nowadays is also designed with the knowledge that the computer hardware is simply unreliable :-)
1. Adding hardware like a security dongle or an encryption card of course allows for much more sophisticated protection. (I would include a heuristic session challenge, for example.) But what the paper was talking about a vanilla PC which is what most people are using, including hordes of UK public servants for whom this stuff is most applicable at the moment.
2. We all know that there are dozens of things which can go wrong in both attacking and defending secure data and your scepticism is both understandable and shared by anyone who has the slightest inkling.
But that does not diminish the value of pointing out the theoretical possibility of a successful attack. In this case they have gone well beyond theory and produced a demo in a controlled environment. Whether this can survive in the wild, only time can tell. But I for one will be watching with interest.