Some highlights from Jon's response ...
"The basic issue is one that we have known for years."Well, that's not very concerting, or at least it shouldn't be. If it was so well known, then why is PGP Corp just now looking to integrate with hardware and BIOS vendors to attempt to resolve this? That line, along with Jon's general theme, is that this is no big deal ... we've known about it forever ... it's just a new spin on an old trick ...
"Those of us who consider these things have known that this was at least in theory possible for some time. This team did two impressive things: they made it actually work, and they did some math to recover partially-damaged RSA and AES keys. This latter feat they did by looking at scratch variables that the encryption systems use, and back-deducing what some of the damaged bits of the keys must have been. The process is a bit like a big Sudoku game; when you play Sudoku, you deduce what is missing based on what is present."
Again, "it's no big deal", except, wait, yep, there's that really complicated math part. I do like Jon's comparison to Sudoku; it's a good analogy.
"Despite how dramatic this attack is, there is an easy fix for it."If there really was an easy fix for it, then the whole notion of "coldboot" would be a solved problem, but that's obviously not the case. Ripping power from a running system (which Jon later goes on to say has never been the primary threat that PGP WDE was designed to overcome) does not protect the keys. Even if BIOS vendors started shipping with features that sanitize memory at boot, a quick power off optionally followed by a cool down of DRAM and finally placing the memory into a prepared system could still read the encryption keys. Yes, that requires a dedicated and trained adversary, but there are organizations with very valuable information. Jon should not be so quick to downplay the likelihood that his customers may have such an adversary, unless of course the really security conscious organizations have been skipping his company's products altogether.
"When a computer is hibernated, the contents of its memory is written to disk, and then the computer is shut down. No residual power is supplied to the RAM, so it will fade in one to two minutes, just as if you had shut it off. It doesn't matter what software you are running; if you hibernate a machine with WDE, it will be safe in a couple of moments. (Note: the Cold Boot researchers say that hibernate mode is vulnerable, and they are wrong on this nit. A truly hibernated machine is turned off, but with a copy of RAM written to disk. These machines are safe, once memory has faded.)"Anyone else want to hear Felten's and crew's response to the hibernate "nit"?
"If there is a hard power loss, such as pulling the battery from a laptop or yanking the power cord out from a server, there's next to nothing that software alone can do. There's next to nothing that hardware can do. We could design hardware and software to do something in this case, but you probably wouldn't pay for it. I wouldn't."I can think of several options here, all of which cannot be so expensive that when typical economies of scale (mass production and consumer demand) are applied the price becomes unreasonable. I'm not sure what this says about what's on Jon's computer, that he wouldn't be interested something as simple as a small reserve of electrical power (like in a capacitor) that can detect when main power has diminished and employs its small reserve which is just ample to perform a basic overwrite or sanitizing operation on DRAM. Such a feature could not possibly cost more than a seat of PGP WDE.
"External authentication using smart cards, tokens, TPMs, does not solve the problem. There have been reports of some people claiming that it does. It doesn't. Remember, this is very simple; there is some RAM that has a key, and that RAM needs to be cleared. Authentication doesn't clear memory. TPMs do not clear memory. The people who claim that a USB key helps at all are displaying their ignorance."I agree that USB keys don't clear memory. What was Dr. Eric Cole of SANS thinking when he said this in the Feb 29th issue of their Newsbites?
"(Cole): The cold boot attack has a cool factor to it, but remember thatBut a future generation of TPMs, or more specifically secure co-processors, could potentially perform all cryptographic operations in hardware, not just integrity checking of boot procedures. Whereas today's TPMs can store keys only later to hand them off to a process that will unfortunately store them in DRAM, the next generation of secure co-processors could be passed the ciphertext blocks of data for decryption, passing the plaintext version back to a WDE-like service. There will be I/O performance concerns to overcome initially, but it is feasible that a commodity-priced chip will one day solve that problem.
full disk encryption will protect a system only if it has a strong
password (two factor recommended) and if the system is completely turned
off. Use of a USB token stops the attack. If you turn your system
completely off (and hold on to it for more than 5 seconds) the attack
is not successful. If you do not follow either of these rules, than
full disk encryption can potentially be broken even without this
attack.]"
"There is more reason to use WDE in conjunction with either Virtual Disk or NetShare. We have always said that the primary threat model for WDE is a machine that is shut down or hibernated. We have always pointed to the added benefits of the other forms of encryption. In his recent article on mobile data protection, Bruce Schneier touts PGP Virtual Disk. The PGP Encryption Platform gives you defense in depth. Defense in depth is good because the layers of protection give more security."Translation: buy more of their products.
Of course, there's always the solution I have offered despite common objections: one method for securing information is to not place it on disk at all. Encryption is not always the answer.
2 comments:
Here's an idea, we could all start using Apple's 12" PowerBook G4 laptops. 256MB of the system RAM is hard-wired to the logic board meaning an attacker can't remove it and steal its contents.
On a more serious note, what if there were a way to always hold your crypto key in the CPU rather than in system RAM? Maybe the architecture could be extended to provide a reserved area or model-specific register, solely for holding AES keys (along with new instructions to read/write this area). Or, maybe it could be done today just by using an obscure/unused register ... some register not stored in memory as part of a context switch operation. You wouldn't even need to store the whole key there, just part of it, so that the key is not recoverable from RAM alone. For example, if you were not using the AMD-v feature, you could store an arbitrary 64-bit value in the VM_HSAVE_PA model-specific register.
Mike,
Thanks for commenting ...
You should read up on "secure co-processors" which have productized into TPMs. I'm not sure TPMs have the I/O performance required to run all disk encryption routines through them today, but they are built around the idea of doing key storage and crypto operations in tamper resistant hardware. Look to Sean W. Smith of Dartmouth for some good academic work in this area.
One advantage of having them separate from CPUs, from my perspective, is that a TPM/secure co-processor will not be as dynamic as normal CPUs. Since we all benefit from having a well understood implementation (including a certification/accreditation of the hardware itself) it would be a bad idea to integrate that directly with CPUs (vendors redesign CPUs way too often to go through formal validation processes). But the requirements for changing out a TPM's design won't come very often at all.
Post a Comment