Cryptogram: Palladium Only for DRM

AARG! Anonymous remailer at aarg.net
Thu Sep 19 11:13:44 PDT 2002


Lucky Green wrote:
> AARG! Wrote:
> > In addition, I have argued that trusted computing in general 
> > will work very well with open source software.  It may even 
> > be possible to allow the user to build the executable himself 
> > using a standard compilation environment.
>
> What AARG! is failing to mention is that Microsoft holds that Palladium,
> and in particular Trusted Operating Root ("nub") implementations, are
> subject to Microsoft's DRM-OS patent. Absent a patent license from
> Microsoft, any individual developer, open source software development
> effort, and indeed any potential competitor of Microsoft that wishes to
> create a Palladium-like TOR would do so in violation of Microsoft's
> patent. U.S. Patent law takes a dim view of such illegal infringers:
> willful infringers, in particular infringers that generate a profit from
> their creation of a non-Microsoft version of a TOR face the risk of a
> court ordering such infringers to pay treble damages.

That's too bad.  Trusted computing is a very interesting technology
with many beneficial uses.  It is a shame that Microsoft has a patent on
this and will be enforcing it, which will reduce the number of competing
implementations.

Of course, those like Lucky who believe that trusted computing technology
is evil incarnate are presumably rejoicing at this news.  Microsoft's
patent will limit the application of this technology.  And the really
crazy people are the ones who say that Palladium is evil, but Microsoft
is being unfair in not licensing their patent widely!

> As of this moment, Microsoft has not provided the open source community
> with a world-wide, royalty-free, irrevocable patent license to the
> totality of Microsoft's patents utilized in Palladium's TOR. Since open
> source efforts therefore remain legally prohibited from creating
> non-Microsoft TORs, AARG!'s lauding of synergies between Palladium and
> open source software development appears premature.

Well, I was actually referring to open source applications, not the OS.
Palladium-aware apps that are available in source form can be easily
verified to make sure that they aren't doing anything illicit.  Since the
behavior of the application is relatively opaque while it is protected by
Palladium technology, the availability of source serves as an appropriate
balance.

But it does appear that Microsoft plans to make the source to the TOR
available in some form for review, so apparently they too see the synergy
between open (or at least published) source and trusted computing.


> > [1] A message from Microsoft's Peter Biddle on 5 Aug 2002; 
> > unfortunately the cryptography archive is missing this day's 
> > messages.  "The memory isn't encrypted, nor are the apps nor 
> > the TOR when they are on the hard drive. Encrypting the apps 
> > wouldn't make them more secure, so they aren't encrypted."  
>
> In the interest of clarity, it probably should be mentioned that any
> claims Microsoft may make stating that Microsoft will not encrypt their
> software or software components when used with Palladium of course only
> applies to Microsoft and not to the countless other software vendors
> creating applications for the Windows platform.

UNLESS Microsoft means that the architecture is such that it does not
support encrypting applications!  The wording of the statement above seems
stronger than just "we don't plan on encrypting our apps at this time".
There are a couple of reasons to believe that this might be true.

First, it is understood that Palladium hashes the secure portions of
the applications that run.  This hash is used to decrypt data and for
reporting to remote servers what software is running.  It seems likely
that the hash is computed when the program is loaded.  So the probable
API is something like "load this file into secure memory, hash it and
begin executing it."

With that architecture, it would not work to do as some have proposed:
the program loads data into secure memory, decrypts it and jumps to it.
The hash would change depending on the data and the program would no
longer be running what it was supposed to.  This would actually undercut
the Palladium security guarantees; the program would no longer be running
code with a known hash.

Second, the Microsoft Palladium white paper at
http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.asp
describes the secure memory as "trusted execution space".  This suggests
that this memory is designed for execution, not for holding data.
The wording hints at an architectural separation between code and data,
when in the trusted mode.


> Lastly, since I have seen this error in a number of articles, it seems
> worth mentioning that Microsoft stated explicitly that increasing the
> security of DRM schemes protecting digital entertainment content, but
> not executable code, formed the impetus to the Palladium effort.

Further reason to believe that Palladium's architecture may not support
the encryption of executable code.





More information about the cypherpunks-legacy mailing list