<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Some stuff &#187; charge decay</title>
	<atom:link href="http://blog.yhuang.org/?feed=rss2&#038;tag=charge-decay" rel="self" type="application/rss+xml" />
	<link>https://blog.yhuang.org</link>
	<description>here.</description>
	<lastBuildDate>Wed, 27 Aug 2025 08:50:58 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.1</generator>
		<item>
		<title>IT security policy &#8220;research&#8221;</title>
		<link>https://blog.yhuang.org/?p=103</link>
		<comments>https://blog.yhuang.org/?p=103#comments</comments>
		<pubDate>Sat, 23 Feb 2008 20:23:36 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[charge decay]]></category>
		<category><![CDATA[curious piece]]></category>
		<category><![CDATA[DRAM]]></category>
		<category><![CDATA[dram manufacturers]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[hardware]]></category>
		<category><![CDATA[liquid nitrogen]]></category>
		<category><![CDATA[magnitude difference]]></category>
		<category><![CDATA[RAM]]></category>
		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://scripts.mit.edu/~zong/wpress/?p=103</guid>
		<description><![CDATA[&#8220;Researchers find way to steal encrypted data,&#8221; screams this article in the New York Times. Oh do they? But come&#8230; on&#8230;, what is this ridiculous demonstration? Okay, okay, it&#8217;s the IT Policy School over there, let&#8217;s cut them some slack. What they&#8217;ve come up with is a way to read seated DRAM under OS lock [...]]]></description>
			<content:encoded><![CDATA[<p>&#8220;Researchers find way to steal encrypted data,&#8221; screams <a href="http://www.nytimes.com/2008/02/22/technology/22chip.html">this article</a> in the New York Times.</p>
<p>Oh <em>do</em> they? But <em>come&#8230; on&#8230;</em>, what is <a href="http://citp.princeton.edu/memory/">this ridiculous demonstration</a>? Okay, okay, it&#8217;s the IT Policy School over there, let&#8217;s cut them some slack. What they&#8217;ve come up with is a way to read seated DRAM under OS lock without specialized hardware, and if they said that, it would be fine.<br />
<span id="more-103"></span><br />
While I don&#8217;t care for their pseudo-slick presentation and shameless self-promotion (with a &#8220;blog&#8221;?), it is still a curious piece of work. Its unfortunate and regurgitated untechnicality leaves questions, though. DRAM is refreshed in tens of milliseconds, and since DRAM manufacturers are always trying to cut power consumption, I&#8217;m going to assume this rate is necessary to ensure reliable read out. There is a 3-order magnitude difference between that and the seconds to minutes reported that DRAM can be without power and still be read, during which time <em>exponential</em> charge decay takes place. Something else has to be going on, no? It just isn&#8217;t entirely clear that when the computer is turned off momentarily, on-board capacitors or even on-module capacitors aren&#8217;t discharging for long enough to residually power the refresh circuitry [*]. On the other hand, they claim they can remove the RAM completely and (with the help of liquid nitrogen) halt for an hour without power. I have some doubts as they dance around this issue.</p>
<p>As for real implication for security, there isn&#8217;t much, if only because this kind of breach isn&#8217;t fundamental. We already know that once indefinite hardware access to a running machine is first obtained (a practical requirement for this attack), there are always ways to compromise it. That&#8217;s how <a href="http://www.xenatera.com/bunnie/proj/anatak/xboxmod.html">the Xbox was cracked</a> &#8212; I&#8217;m talking about in-parallel probes on pins and traces, which can be just as well applied to the scenario here. Unless there are self-destructive mechanisms or other <em>fundamental</em> barriers to hardware access, we are just dealing with a matter of how high is the effort threshold. To fix it, encryption keys should not be stored in RAM in a detectable way, and any TPM modules that are currently being designed should have additional hardware security measures. That&#8217;s not hard to do, but in the meantime, let&#8217;s sit back and watch an uptick in the cracking of existing software and DRM protection schemes, as protected areas of RAM are opened up to easy hacking &#8212; a far more likely and practical fallout.</p>
<hr size=1>
<p>[*] I just read their full technical documentation, and they seem a little sloppy. They measure (and plot) total module read out error rate, but then fit a curve to it that they justify with MOSFET charge decay characteristics. Isn&#8217;t that right? Well, no: error rate should exhibit the typical digitizing water-fall effect of the comparator circuit.</p>
]]></content:encoded>
			<wfw:commentRss>https://blog.yhuang.org/?feed=rss2&#038;p=103</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
