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<mailto:[EMAIL PROTECTED]>
To: [email protected]<mailto:[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<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=400+South+Woods+Mill+Rd.&csz=Chesterfield%2C+MO+63017&country=us>

[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>

tel:
fax:
mobile:

314-590-0902 [cid:[email protected]] 
<http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=314%2D590%2D0902&[EMAIL
 PROTECTED]>
314-590-0995
314-495-2048 [cid:[email protected]] 
<http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=314%2D495%2D2048&[EMAIL
 PROTECTED]>





Want to always have my latest 
info?<https://www.plaxo.com/add_me?u=4295266455&src=client_sig_212_1_banner_join&invite=1&lang=en>

Want a signature like 
this?<http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en>




________________________________
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

<<inline: image001.gif>>

_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde

Reply via email to