Pragmatically speaking, good ideas. But still security by obscurity, is it not?
----- Original Message ----- From: Bryan Glancey To: [email protected] Sent: Saturday, February 23, 2008 1:15 PM Subject: Re: [FDE] Princeton Memory vulnerability There are a complete set of feasible defenses suggested including (suggested in full text of research paper): · Split encryption Keys (or s-box tables) into separate pieces · Dynamically relocate Keys regularly in memory - to make exact location difficult to determine · Overwrite memory several times when unloading Key · Encrypt key in memory with another key Of course, most of these are more difficult to rearrange with hardware where the inputs and outputs are known memory addresses and can not be easily relocated. Bu these defenses are already in some FDE software products but, obviously, not all. Regards; Bryan Glancey From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett M. Groff Sent: Friday, February 22, 2008 2:55 PM To: [email protected] Subject: Re: [FDE] Princeton Memory vulnerability That statement is true if BitLocker is set to use transparent operation mode ("basic mode"), which, I argue, is ill-advised anyway. In that case, an "online attack" (like an exploitable buffer overflow vulnerability on a system service) would likely be easier anyway than the hardware/RAM approach. Also, the statement quoted below does not mean that TPMs are less secure than a software-only solution (I'd argue they're more secure, though transparent operation mode negates the benefit, IMO). The most secure mode if using BitLocker would be TPM+PIN+USB (a mode that I believe will be supported in SP1). I.e., the TPM is present, verifying the checksum of the boot components. A PIN is required to release the key as well as the integrity check. Also, a USB containing the other half of the key is required. Pretty secure since it's multi-factor & the TPM does the pre-boot check. Even in that case though, the key is stored in RAM and, therefore, vulnerable to this hardware-based attack. The RAM, not the TPM or software, is the weak link. (Even with an invulnerable Momentus drive, an attacker could analyze RAM and possibly gain some juicy information; so, again, more secure RAM is desirable, is it not?) The ways to mitigate this, AFAIK, are: * Use a drive like Momentus... and hope that the anti-tampering mechanisms within the Momentus drive make hardware-based attacks (like the RAM attack) infeasible and unreliable. * Don't use standby mode. Instead, use hibernate (though hibernation might still be vulnerable depending on the FDE solution) or shut off the computer. * Physically make RAM difficult to remove from the machine (crude, but effective?). * Set BIOS boot sequence such that the machine boots to the HDD first; password protect BIOS. (I know, I know. Not fool-proof, but the extra time it takes to reset the BIOS & boot to a CD or USB stick might make the contents of RAM unreliable. Having said that, this is only mitigating if attacker uses your own machine to stage the attack. Bets are off if he removes the RAM & puts them in his own machine. But hey, it's a good thing to do regardless, right??) - Garrett ----- Original Message ----- From: Bryan Glancey To: [email protected] Sent: Friday, February 22, 2008 4:55 PM Subject: [FDE] Princeton Memory vulnerability Previously discussed in another posting the comment was made that this would have less impact on hardware solutions - I quote the research paper , page 3 paragraph 3 - "Notably, using BitLocker with a Trusted Platform Module (TPM) sometimes makes it less secure, allowing an attacker to gain access to the data even if the machine is stolen while it is completely powered off." Regards; Bryan Mobile Armor, Inc. Enterprise Mobile Data Security Bryan E. Glancey Senior Vice President & Chief Technology Officer Mobile Armor, Inc 400 South Woods Mill Rd. Suite 300 Chesterfield, MO 63017 [EMAIL PROTECTED] tel: fax: mobile: 314-590-0902 314-590-0995 314-495-2048 Want to always have my latest info? Want a signature like this? ---------------------------------------------------------------------------- The information contained in this e-mail, including any files attached to it, is intended only for the personal use of the designated recipient and may contain PRIVILEGED and CONFIDENTIAL information and is exempt from disclosure under applicable law. If the reader of this e-mail and attachments is not the intended recipient, you are notified that any dissemination, disclosure, distribution, printing, copying or the taking of any action in reliance on this information is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by responding to this email or by calling our office at (314) 590-0900. ---------------------------------------------------------------------------- _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde ------------------------------------------------------------------------------ _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
<<image001.gif>>
_______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
