<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: Countermeasures to Cold Booting Attacks</title>
	<atom:link href="http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/feed/" rel="self" type="application/rss+xml" />
	<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/</link>
	<description>Information Systems and Internet Security</description>
	<lastBuildDate>Sat, 26 Sep 2009 11:11:21 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dan Guido</title>
		<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/comment-page-1/#comment-272</link>
		<dc:creator>Dan Guido</dc:creator>
		<pubDate>Fri, 14 Mar 2008 18:47:58 +0000</pubDate>
		<guid isPermaLink="false">http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/#comment-272</guid>
		<description>This is why hardware encryption isn&#039;t as trustworthy as people might think:
http://hardware.slashdot.org/article.pl?sid=08/03/14/1455255</description>
		<content:encoded><![CDATA[<p>This is why hardware encryption isn&#8217;t as trustworthy as people might think:<br />
<a href="http://hardware.slashdot.org/article.pl?sid=08/03/14/1455255" rel="nofollow">http://hardware.slashdot.org/article.pl?sid=08/03/14/1455255</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Guido</title>
		<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/comment-page-1/#comment-264</link>
		<dc:creator>Dan Guido</dc:creator>
		<pubDate>Thu, 13 Mar 2008 17:01:11 +0000</pubDate>
		<guid isPermaLink="false">http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/#comment-264</guid>
		<description>Seagate posted an official response to the cold-booting attack:
http://www.seagate.com/docs/pdf/security/Princeton_RC514_1_0702.pdf

&quot;Q: Is hardware FDE vulnerable to the DRAM freezing attack?&quot;

&quot;A: No. The drive memory and components of the Momentus 5400 FDE.2 drive are mounted in a way that would require a hacker to remove the drive&#039;s PCBA (printed circuit board assembly) and flip it over in order to gain access -- a process that would cut off power to the drive, locking it and removing the encryption keys from drive memory. In addition, the Momentus 5400 FDE.2 drive keeps encryption keys in drive memory for as short a time as possible and overwrites the key with zeros after each use. Because keys can be contained in drive memory, Seagate carefully secures the drive using hardware and software mechanisms to prevent access to drive memory by all but authorized users.&quot;

Nice, but notice the last sentence... &quot;all but authorized users.&quot; How does the drive tell who is authorized and who isn&#039;t?</description>
		<content:encoded><![CDATA[<p>Seagate posted an official response to the cold-booting attack:<br />
<a href="http://www.seagate.com/docs/pdf/security/Princeton_RC514_1_0702.pdf" rel="nofollow">http://www.seagate.com/docs/pdf/security/Princeton_RC514_1_0702.pdf</a></p>
<p>&#8220;Q: Is hardware FDE vulnerable to the DRAM freezing attack?&#8221;</p>
<p>&#8220;A: No. The drive memory and components of the Momentus 5400 FDE.2 drive are mounted in a way that would require a hacker to remove the drive&#8217;s PCBA (printed circuit board assembly) and flip it over in order to gain access &#8212; a process that would cut off power to the drive, locking it and removing the encryption keys from drive memory. In addition, the Momentus 5400 FDE.2 drive keeps encryption keys in drive memory for as short a time as possible and overwrites the key with zeros after each use. Because keys can be contained in drive memory, Seagate carefully secures the drive using hardware and software mechanisms to prevent access to drive memory by all but authorized users.&#8221;</p>
<p>Nice, but notice the last sentence&#8230; &#8220;all but authorized users.&#8221; How does the drive tell who is authorized and who isn&#8217;t?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kurt</title>
		<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/comment-page-1/#comment-248</link>
		<dc:creator>kurt</dc:creator>
		<pubDate>Tue, 11 Mar 2008 23:32:04 +0000</pubDate>
		<guid isPermaLink="false">http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/#comment-248</guid>
		<description>I doubt the feasibility of offloading security-critical processing
to a trusted hardware peripheral module.  

Option 1: The trusted module is secure, but it has low complexity and a narrow interface, and cannot be in the loop in modern computing situations like browsing the web.

Option 2: The trusted module does all sorts of cool stuff, but it has high complexity which means that it has a wide profile of exposure to both physical attacks (side-channel, etc) and logic attacks (programming bugs).  

By the way, if there&#039;s anyone out there who thinks that bugs are a software phenomenon and hardware doesn&#039;t have bugs, think again.  And the distinction between exploitable bugs versus non-exploitable bugs is not worth defining.  Complex hardware will have exploitable flaws.
So options 1 and 2, above, are mutually exclusive.  Trying to make a PC into a giant TPM on &#039;roids is not going to get us anywhere.  

By the way, it is interesting to think about the traditional TPM-style of bootstrapping trust and then growing the trusted perimeter outward, by authenticating the other components.  I have always felt that this is bogus.  We all know that it is impossible to do complete testing of a black box.  Trusted computing-style initialization generally just runs some basic authentication algorithm between the TPM and the peripherals.  This does not verify anything about what their behavior will be.  There is an assumption made, that an attacker could not arrange for his malicious functionality to run in chip, while preserving the authentication handshake.  This is basic.  It is the difference between authentication and trust.  

On a related note, what does it mean to authenticate a piece of logic?  If the logic is a little bit changed, is it still authentic?  With human authentication, this reduces to the old philosophical problem of personal identity.  (If you had my thoughts and my memories and my feelings, would you be me?  Surely identity is not physical, is it?)  But for information systems, authentication, identification, and verification are all deeply intertwined.</description>
		<content:encoded><![CDATA[<p>I doubt the feasibility of offloading security-critical processing<br />
to a trusted hardware peripheral module.  </p>
<p>Option 1: The trusted module is secure, but it has low complexity and a narrow interface, and cannot be in the loop in modern computing situations like browsing the web.</p>
<p>Option 2: The trusted module does all sorts of cool stuff, but it has high complexity which means that it has a wide profile of exposure to both physical attacks (side-channel, etc) and logic attacks (programming bugs).  </p>
<p>By the way, if there&#8217;s anyone out there who thinks that bugs are a software phenomenon and hardware doesn&#8217;t have bugs, think again.  And the distinction between exploitable bugs versus non-exploitable bugs is not worth defining.  Complex hardware will have exploitable flaws.<br />
So options 1 and 2, above, are mutually exclusive.  Trying to make a PC into a giant TPM on &#8216;roids is not going to get us anywhere.  </p>
<p>By the way, it is interesting to think about the traditional TPM-style of bootstrapping trust and then growing the trusted perimeter outward, by authenticating the other components.  I have always felt that this is bogus.  We all know that it is impossible to do complete testing of a black box.  Trusted computing-style initialization generally just runs some basic authentication algorithm between the TPM and the peripherals.  This does not verify anything about what their behavior will be.  There is an assumption made, that an attacker could not arrange for his malicious functionality to run in chip, while preserving the authentication handshake.  This is basic.  It is the difference between authentication and trust.  </p>
<p>On a related note, what does it mean to authenticate a piece of logic?  If the logic is a little bit changed, is it still authentic?  With human authentication, this reduces to the old philosophical problem of personal identity.  (If you had my thoughts and my memories and my feelings, would you be me?  Surely identity is not physical, is it?)  But for information systems, authentication, identification, and verification are all deeply intertwined.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kurt</title>
		<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/comment-page-1/#comment-240</link>
		<dc:creator>kurt</dc:creator>
		<pubDate>Sun, 09 Mar 2008 20:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/#comment-240</guid>
		<description>I&#039;m interested in revisiting the Seagate Drive Trust system.
It might make some sense after all.</description>
		<content:encoded><![CDATA[<p>I&#8217;m interested in revisiting the Seagate Drive Trust system.<br />
It might make some sense after all.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Guido</title>
		<link>http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/comment-page-1/#comment-213</link>
		<dc:creator>Dan Guido</dc:creator>
		<pubDate>Wed, 05 Mar 2008 05:55:07 +0000</pubDate>
		<guid isPermaLink="false">http://isisblogs.poly.edu/2008/02/23/countermeasures-to-cold-booting-attacks/#comment-213</guid>
		<description>Looks like cold booting just got a little bit worse:
http://www.news.com/8301-10784_3-9881870-7.html?tag=blog.1</description>
		<content:encoded><![CDATA[<p>Looks like cold booting just got a little bit worse:<br />
<a href="http://www.news.com/8301-10784_3-9881870-7.html?tag=blog.1" rel="nofollow">http://www.news.com/8301-10784_3-9881870-7.html?tag=blog.1</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
