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.