<?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:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: DRM is passive and active</title>
	<atom:link href="http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Tue, 16 Mar 2010 03:16:39 +0000</lastBuildDate>
	<generator>http://wordpress.com/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3380</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Mon, 22 Oct 2007 16:50:37 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3380</guid>
		<description>Well, it&#039;s some kind of restriction, although it&#039;s certainly not in the same class as something designed to be DRM from the beginning.  It&#039;s similar to people saying XOR with a constant is &quot;encrypting the data&quot; -- nowhere near accurate.  In that case, I call it &quot;masking the data&quot; since it is slightly transformed.  So what&#039;s the term for &quot;unprotected, but with a couple speedbumps bolted on the side&quot;?</description>
		<content:encoded><![CDATA[<p>Well, it&#8217;s some kind of restriction, although it&#8217;s certainly not in the same class as something designed to be DRM from the beginning.  It&#8217;s similar to people saying XOR with a constant is &#8220;encrypting the data&#8221; &#8212; nowhere near accurate.  In that case, I call it &#8220;masking the data&#8221; since it is slightly transformed.  So what&#8217;s the term for &#8220;unprotected, but with a couple speedbumps bolted on the side&#8221;?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alun Jones</title>
		<link>http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3348</link>
		<dc:creator>Alun Jones</dc:creator>
		<pubDate>Thu, 18 Oct 2007 18:03:20 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3348</guid>
		<description>Makes sense - type 2 is no DRM at all, in essence. Whether it&#039;s a &quot;broadcast flag&quot; on television, or a CD with an executable root-kit, there are legitimate systems that won&#039;t even see that the content should be protected, and the temptation to deal with that is to somehow outlaw such systems.
It&#039;s effectively already happened - while multi-region DVD players are common and inexpensive in the UK, in the US, I find it difficult to find a player that is advertised as multi-region. While they&#039;re clearly not illegal, the marketplace here has somehow been coerced into making them unavailable.
Maybe my proposed two types should be &quot;DRM&quot; and &quot;not DRM&quot; :)</description>
		<content:encoded><![CDATA[<p>Makes sense &#8211; type 2 is no DRM at all, in essence. Whether it&#8217;s a &#8220;broadcast flag&#8221; on television, or a CD with an executable root-kit, there are legitimate systems that won&#8217;t even see that the content should be protected, and the temptation to deal with that is to somehow outlaw such systems.<br />
It&#8217;s effectively already happened &#8211; while multi-region DVD players are common and inexpensive in the UK, in the US, I find it difficult to find a player that is advertised as multi-region. While they&#8217;re clearly not illegal, the marketplace here has somehow been coerced into making them unavailable.<br />
Maybe my proposed two types should be &#8220;DRM&#8221; and &#8220;not DRM&#8221; :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3347</link>
		<dc:creator>Nate Lawson</dc:creator>
		<pubDate>Thu, 18 Oct 2007 15:38:45 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3347</guid>
		<description>Thanks for the reply.  I see you used to work at Microsoft but don&#039;t any more.  Sorry for the mistake.

My main issue is that you picked two arbitrary DRM schemes and then defined a terminology based on them.  I&#039;ll call the two approaches &quot;ProtectionX&quot; and &quot;Assassin&quot; instead of &quot;active&quot; and &quot;passive&quot;, respectively.

1. Encrypted file + DRM client (&quot;ProtectionX&quot;):  DRM client attempts to verify environment before decrypting file.  Assumes file is encrypted with standard symmetric crypto so that it can&#039;t be retrieved without at least one instance of DRM client.

2. Unprotected CD + autorun assassin software (&quot;Assassin&quot;):  CD is unprotected 16 bit samples readable by standard consumer grade equipment.  In one specific environment and configuration (Windows with autorun), the assassin program runs and attempts to interfere with any attempt to copy data.

What I&#039;m trying to tell you is that your example of a file with a flag that says &quot;do not copy&quot; or a disc with autorun assassin software that is otherwise unprotected is a special case.  It&#039;s an attempt to retrofit some kind of client-side control onto a format that doesn&#039;t already have it, not a type of pre-defined DRM.

No one, especially content producers, asks for an unprotected format and assumes they&#039;ll bolt on something later.  All you&#039;re seeing is the fact that some formats made it out of the gate without protection (CD) or were weak and eventually broken (DVD-CSS).  In those cases, some people make the effort to add optional &quot;assassin&quot; software, even if it only slows down some small percentage of users.

You and I both agree that this is ineffective, easily bypassed, and can interfere with legitimate use.  But some companies have analyzed the cost/benefit tradeoff and based on that information continue to deploy this approach rather than accept the alternative (do nothing).

Side note: the reason why this subject is particularly important to me is that some people are already using the concepts &quot;active&quot; and &quot;passive&quot; in terms of DRM.  The claim is that crypto-based systems (i.e., &lt;a href=&quot;http://www.aacsla.com/&quot; rel=&quot;nofollow&quot;&gt;AACS&lt;/a&gt;) are &quot;passive&quot; and software protection (i.e., &lt;a href=&quot;http://www.cryptography.com/technology/spdc/bluray.html&quot; rel=&quot;nofollow&quot;&gt;BD+&lt;/a&gt;) are &quot;active&quot;.  This is nonsense since you have to consider the software that decrypts the disc part of the system, and thus there are no true &quot;passive&quot; systems.</description>
		<content:encoded><![CDATA[<p>Thanks for the reply.  I see you used to work at Microsoft but don&#8217;t any more.  Sorry for the mistake.</p>
<p>My main issue is that you picked two arbitrary DRM schemes and then defined a terminology based on them.  I&#8217;ll call the two approaches &#8220;ProtectionX&#8221; and &#8220;Assassin&#8221; instead of &#8220;active&#8221; and &#8220;passive&#8221;, respectively.</p>
<p>1. Encrypted file + DRM client (&#8220;ProtectionX&#8221;):  DRM client attempts to verify environment before decrypting file.  Assumes file is encrypted with standard symmetric crypto so that it can&#8217;t be retrieved without at least one instance of DRM client.</p>
<p>2. Unprotected CD + autorun assassin software (&#8220;Assassin&#8221;):  CD is unprotected 16 bit samples readable by standard consumer grade equipment.  In one specific environment and configuration (Windows with autorun), the assassin program runs and attempts to interfere with any attempt to copy data.</p>
<p>What I&#8217;m trying to tell you is that your example of a file with a flag that says &#8220;do not copy&#8221; or a disc with autorun assassin software that is otherwise unprotected is a special case.  It&#8217;s an attempt to retrofit some kind of client-side control onto a format that doesn&#8217;t already have it, not a type of pre-defined DRM.</p>
<p>No one, especially content producers, asks for an unprotected format and assumes they&#8217;ll bolt on something later.  All you&#8217;re seeing is the fact that some formats made it out of the gate without protection (CD) or were weak and eventually broken (DVD-CSS).  In those cases, some people make the effort to add optional &#8220;assassin&#8221; software, even if it only slows down some small percentage of users.</p>
<p>You and I both agree that this is ineffective, easily bypassed, and can interfere with legitimate use.  But some companies have analyzed the cost/benefit tradeoff and based on that information continue to deploy this approach rather than accept the alternative (do nothing).</p>
<p>Side note: the reason why this subject is particularly important to me is that some people are already using the concepts &#8220;active&#8221; and &#8220;passive&#8221; in terms of DRM.  The claim is that crypto-based systems (i.e., <a href="http://www.aacsla.com/" rel="nofollow">AACS</a>) are &#8220;passive&#8221; and software protection (i.e., <a href="http://www.cryptography.com/technology/spdc/bluray.html" rel="nofollow">BD+</a>) are &#8220;active&#8221;.  This is nonsense since you have to consider the software that decrypts the disc part of the system, and thus there are no true &#8220;passive&#8221; systems.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alun Jones</title>
		<link>http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3316</link>
		<dc:creator>Alun Jones</dc:creator>
		<pubDate>Tue, 16 Oct 2007 03:49:53 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/2007/10/04/drm-is-neither-passive-nor-active/#comment-3316</guid>
		<description>I&#039;ve obviously failed to communicate a number of things:
1. I am not &quot;of Microsoft&quot; by any means.
2. I am fully aware that in any DRM system, there is an &#039;active&#039; and a &#039;passive&#039; component.
3. My attempt to give names to different types of DRM refer to whether the content is securely protected when it&#039;s just laying there (&quot;passive&quot;), or whether it&#039;s only protected when you&#039;re running the DRM component (&quot;active&quot;).
So, if you encrypt a file, and hand me the encrypted bits on a disk, that&#039;s what I would call &quot;passive DRM&quot;, because its protection does not require me to be running the DRM client code. Only its unlocking requires me to run the DRM client code (or a reasonable facsimile thereof) and get a key. Killing the DRM client code restores the protection - it has &quot;defence in death&quot;.
If, on the other hand, you place the file unencrypted on the disk, but expect my file reader to obey a flag in the file&#039;s header to not display it, then that&#039;s what I would call &quot;Active DRM&quot;, because the protection requires that the DRM client code is active. Killing the DRM client code removes the protection.
That latter kind of DRM can only function in an environment where users can be prevented from _not_ running the DRM client code. This is why you see irritating (and sometimes successful) attempts by various content producers to pass legislation that prevents users from choosing what software to run - or not run - on their own machines.
Sure, you can say that there&#039;s a continuum between these two extremes - and that the fact that &quot;passive DRM&quot; requires a key to be given to the client certainly makes it possible to hack - but I think the distinction is worth making.
So, now that I&#039;ve further explained myself, do you agree with me that there is a valid distinction between the two types of protection? Are we simply quibbling about names?</description>
		<content:encoded><![CDATA[<p>I&#8217;ve obviously failed to communicate a number of things:<br />
1. I am not &#8220;of Microsoft&#8221; by any means.<br />
2. I am fully aware that in any DRM system, there is an &#8216;active&#8217; and a &#8216;passive&#8217; component.<br />
3. My attempt to give names to different types of DRM refer to whether the content is securely protected when it&#8217;s just laying there (&#8220;passive&#8221;), or whether it&#8217;s only protected when you&#8217;re running the DRM component (&#8220;active&#8221;).<br />
So, if you encrypt a file, and hand me the encrypted bits on a disk, that&#8217;s what I would call &#8220;passive DRM&#8221;, because its protection does not require me to be running the DRM client code. Only its unlocking requires me to run the DRM client code (or a reasonable facsimile thereof) and get a key. Killing the DRM client code restores the protection &#8211; it has &#8220;defence in death&#8221;.<br />
If, on the other hand, you place the file unencrypted on the disk, but expect my file reader to obey a flag in the file&#8217;s header to not display it, then that&#8217;s what I would call &#8220;Active DRM&#8221;, because the protection requires that the DRM client code is active. Killing the DRM client code removes the protection.<br />
That latter kind of DRM can only function in an environment where users can be prevented from _not_ running the DRM client code. This is why you see irritating (and sometimes successful) attempts by various content producers to pass legislation that prevents users from choosing what software to run &#8211; or not run &#8211; on their own machines.<br />
Sure, you can say that there&#8217;s a continuum between these two extremes &#8211; and that the fact that &#8220;passive DRM&#8221; requires a key to be given to the client certainly makes it possible to hack &#8211; but I think the distinction is worth making.<br />
So, now that I&#8217;ve further explained myself, do you agree with me that there is a valid distinction between the two types of protection? Are we simply quibbling about names?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
