Vitanuova for 2002 July 5

The Microsoft meeting

(I am omitting some "sensitive" material, but none of what I omit is material which I think would embarrass Microsoft or expose it to criticism. No part of the meeting was under an NDA or confidentiality agreement.)

Please don't attribute anything below to Microsoft, e.g. in a news article; instead, you should call them to confirm it. I'm just giving my impressions and my understanding based on some fairly sparse notes.

Peter Biddle at Microsoft began thinking around 1997 about how to protect his bits when they were on someone else's computer. (He was Microsoft's representative at CPTWG and in the DVD-CCA, and was somewhat skeptical of the technical efficacy of software-based DRM.)
His view, and the view of some of his colleagues, was that they ultimately did not know how to enforce a policy for the use of information when it was kept and used on somebody else's PC. The PC platform did not seem to support this.
In thinking about this, he decided that "a blob is a blob". ["Blob" is a database term for "binary large object", and roughly means "file", "data structure", or "sequence of bits whose internal structure is unanalyzed".] So, it was not appropriate to think about protecting some bits more than others, or enforcing some kinds of policies but not others. So the protection of privacy was the same technical problem as the protection of copyright, because in each case bits owned by one party were being entrusted to another party and there was an attempt to enforce a policy. Technologically, this could not be done securely with software alone.
It is hard to imagine how, in software alone, one part of the functionality of a general-purpose operating system can be protected from another part of the functionality of a general-purpose operating system. The existing PC architecture does not support this kind of compartmentalization. Consequently, a virus could potentially access or capture any kind of data (including very sensitive personally identifiable information, financial and medical records, etc.), and redistribute it over a network.
Similarly, an emulator or debugger could be used to extract copyrighted material and redistribute it or use it contrary to policy.
The view of some people working on Palladium is that it's appropriate to create technology which would permit each creator of any kind of digital information to set and enforce any policy whatsoever for the use of that information. (If you don't want to abide by the policy, you don't have to accept the information.) There are various subtleties here and some debate about public policy, but the basic assumption is that you have a right to control, if you wish, how other people will use bits you create.
[Omit some discussion of business models, DRM, file sharing, legislation, etc.]
Microsoft does not have the desire or means to control any information which is input into a computer via a means beyond the scope of DRM or Palladium (in unencrypted formats such as MP3), and intends to continue supporting such formats.
Microsoft employees have a broad variety of opinions on legal and technical issues related to copyright enforcement. The company's position is that the use of DRM should be purely voluntary (in the sense in which the industry uses that term; they do not have a public position that the DMCA's anticircumvention provisions need to be modified).
Microsoft wants to compete with proprietary platforms which offer DRM [to publishers], such as proprietary consumer electronics platforms. Microsoft believes that, if it did not support DRM at all, it would be at a competitive disadvantage relative to proprietary platforms which did.
The Palladium architecture has been under development since around 1997, and Microsoft holds or has filed for some patents which cover portions of it. At least one of the inventors of the Digital Rights Management Operating System patent is working on Palladium, although we did not discuss whether the DRM OS patent is related to Palladium, whether Microsoft is writing an operating system using the techniques disclosed in that patent, or whether the DRM OS patent covers any parts of Palladium.
Palladium is distinct from TCPA and has technical differences from TCPA. It has some architectural points in common with TCPA, including, most significantly, the use of "trusted hardware" within a PC in order to establish a root of trust. Both TCPA and Palladium require modifications to existing PC hardware architecture in order to work. In addition, they both require modifications to software in order to use trust features. Both are intended to run existing "untrusted" software without any modifications.
Palladium would, inter alia, add a new opcode and a new operating mode to the CPU. A portion of the enforcement resides within the CPU itself.
Microsoft assumed as a design criterion for Palladium that existing versions of Windows should be able to run on a Palladium PC, as should existing Windows applications, as should existing non-Windows operating systems like Linux. There is no attempt to stop people from booting whatever code they currently use or may write in the future. In addition, the hardware trust features can potentially be used by specially-adapted software, regardless of what operating system is running. It is possible to imagine that a Palladium-hardware-aware version of Linux could be created and could make full use of Palladium's hardware features in order to achieve trust comparable to the Windows implementation. Microsoft is only writing an implementation for Windows, but plans to publish all the technical details. (Microsoft has not yet decided about patent policies or stated whether an operating system which used Palladium hardware features would necessarily infringe any of Microsoft's Palladium patents.)
Microsoft, like chemists, calls Palladium "Pd" for short.
I'm going to type ":abbr pd Palladium" in vi so that I can stop typing "Palladium" all the time. Hooray for :abbr!
The initial version of Palladium will require changes to five parts of the PC's hardware. Changes will be required to the CPU, the chipset (on the motherboard), the input devices (e.g. keyboard), and the video output devices (graphics processor). In addition, a new component must be added: a tamper-resistant secure cryptographic co-processor, which Microsoft calls SCP or SPP.
Although the SCP is tamper-resistant, it is likely that a skilled attacker with physical access to the inside of a Palladium PC can still compromise it or subvert its policies in some way. One possible attack is one I discussed with Ross Anderson last week: you can replace the system RAM with special RAM which allows its contents to be read or modified by an external circuit.
So it is possible that an attacker with physical access can still compromise the system, even though the SCP is meant to be tamper-resistant, partly because other components (like RAM) are less robust against modification. Palladium primarily defends effectively against two classes of attacks: (1) remote network-mounted attacks (buffer overflows and other programming flaws, malicious mobile code, etc.), because even if some malicious code is installed in one part of the system, it still can't effectively subvert the policy of another part of the system, and (2) local software-based attacks, including things like using a debugger to try to read a program's internal state while it's executing or to try to subvert its policy. Thus, Palladium can probably guarantee that you can't write or download any software (and nobody else can write or upload to you any software) which would compromise the policy of software running locally which is making use of Palladium trust features.
Although hardware attacks can work, they are probably not portable from one machine to another. This is especially interesting for users of DRM -- even though one user can launch an expensive and successful attack, that user can't publish an inexpensive software-based technique or HOWTO which would enable others to reproduce this attack cheaply. (Cue reference to Bunnie's X-BOX reverse engineering paper, where he suggests that his inexpensive attack on the X-BOX can yield portable techniques which can be used by others inexpensively, but that the X-BOX could have been designed so that his attack was not readily portable to other machines.)
Palladium's changes to the CPU allow it to be placed into a new mode where certain areas of memory are restricted via a technique called "code curtaining" to an ultra-privileged piece of code called the "nub" or "TOR". ("Nub" is the Palladium team's term for this code, and "TOR", for "Trusted Operating Root", is the official public term.) The nub is a kind of trusted memory manager, which runs with more privilege than an operating system kernel. The nub also manages access to the SCP.
The SCP is an 8-bit tamper-resistant cryptographic smart-card which contains unique keys, including public keypairs (2048-bit RSA), and symmetric keys for AES in CBC mode. These keys are unique per machine and the SCP does not reveal them to anything outside the SCP's security perimeter. It also contains a variety of other cryptographic functionality, including SHA-1, RSA, AES, and other cipher implementations, a small amount of memory, and a monotone counter. The SCP can do a number of cryptographic protocols. It also contains a thing called a PCR. (I think that stands for "platform configuration register".)
When you want to start a Palladium PC in trusted mode (note that it doesn't have to start in trusted mode, and, from what Microsoft said, it sounds like you could even imagine booting the same OS in either trusted or untrusted mode, based on a user's choice at boot time), the system hardware performs what's called an "authenticated boot", in which the system is placed in a known state and a nub is loaded. A hash (I think it's SHA-1) is taken of the nub which was just loaded, and the 160-bit hash is stored unalterably in the PCR, and remains there for as long as the system continues to operate in trusted mode. Then the operating system kernel can boot, but the key to the trust in the system is the authentication of the nub. As long as the system is up, the SCP knows exactly which nub is currently running; because of the way the CPU works, it is not possible for any other software to modify the nub or its memory or subvert the nub's policies. The nub is in some sense in charge of the system at a low level, but it doesn't usually do things which other software would notice unless it's asked to.
Palladium's authenticated boot is simpler than TCPA's version, because only a single hash (or "measurement", in TCPA language) is taken. Palladium does not attempt to "measure" the hardware, BIOS, boot loader, OS kernel, etc., or at least not within the SCP. In TCPA, several separate hashes will be taken and stored in secure registers.
The nub interfaces with other software on the system by means of programs (outside the nub) called trusted agents (or TAs). The TAs can implement sophisticated policies and authentication methods, where the nub (and SCP) just implement fairly simple primitives. A TA can also communicate with user-space programs (at least, that will be a feature of Microsoft's nub; other people can write their own nubs which can support different kinds of TAs or even do without TAs entirely). The TAs are protected by hardware from one another and from the rest of the system.
Even PCI DMA can't read or write memory which has been reserved to a nub's or TA's use (including the nub's or TA's code). This memory is completely inaccessible and can only be accessed indirectly through API calls. The chipset on the motherboard is modified to enforces this sort of restriction.
The SCP provides a feature called "sealed storage" by means of two API calls (called SEAL and UNSEAL). The Microsoft nub provides more complicated wrappers around these calls; using the Microsoft wrappers, you can have features like "migration strategy" or "migration policy" (allowing at least three different policies for how encrypted data can be moved from one machine to another). If a TA running on a system in trusted mode wants to use sealed storage, it can call into the APIs implemented in the nub.
Sealed storage is implemented by means of encryption (sealing) or decryption (unsealing) with a symmetric cipher (probably AES in CBC mode). When the SCP is given data to seal, it's given two arguments: the data itself and a 160-bit "nub identifier" (which is the SHA-1 hash of some nub and so uniquely identifies that nub).
Sealing is performed by prepending the nub identifier to the data to be sealed, and then encrypting the result with a private symmetric key -- I want to call this the "platform-specific key", which varies from machine to machine and is secret. (I don't remember whether "platform-specific key" is Microsoft's term for this.) That key is kept within the SCP and is a unique identifier for the machine which performed the sealing operation.
The SCP actually also prepends a random nonce to the data to be sealed before encryption (and discards the nonce upon decryption). This is a clever privacy feature which prevents someone from creating an application which "cookies you" by recording the output of sealing an empty string (and then using the result as a persistent unique identifier for your machine). A program which tried to "cookie you" this way would find that, because of the random nonce, the result of sealing a given string is constantly completely different, and no useful information about the identity of the machine is revealed by the sealing operation.
After encryption, the SCP returns the encrypted result as the return value of the SEAL operation.
When an SCP is given encrypted data to UNSEAL, it internally attempts to decrypt the encrypted data using its platform-specific key. This means that, if the encrypted data was originally sealed on a different machine, the UNSEAL operation will fail outright immediately. (You can't take a sealed file and transfer it to another machine and unseal it there; because the platform-specific key is used for encryption and decryption, and can't be extracted from the SCP, you can only UNSEAL data on the same machine on which it was originally SEALed.)
If the decryption is successful, the SCP performs a second check: it examines the nub identifier which resides within the decrypted data. The nub identifier was specified at the time the data was originally SEALed, and indicates which nub is allowed to receive the decrypted data. If the nub identifier for the decrypted data is identical to the nub identifer which is currently stored in the PCR (which is the SHA-1 hash of the currently-running nub on the machine at the moment UNSEAL was called), the UNSEAL is successful and the decrypted data is returned to the calling nub. However, if the nub identifier does not match the contents of the PCR, the SCP concludes that the nub which is currently running is not entitled to receive this data, and discards it.
Thus, sealing is specific to a physical machine and also specific to a nub. Data sealed on one machine for a particular nub cannot be decrypted on a different machine or under a different nub. An application which trusts a particular nub (and is running under that nub) can seal important secret data and then store the resulting sealed data safely on an untrusted hard drive, or even send it over a network.
If you reboot the machine under a debugger, there is no technical problem, and you can debug the software which created the encrypted file. However, since you aren't running the proper (non-debugger-friendly) nub, the debugger will work, but the UNSEAL call won't. The SCP will receive the UNSEAL call, examine the PCR, and conclude that the currently-running nub is not cleared (so to speak) to receive the sealed data. Your applications can only decrypt sealed data if they are running under the same machine and under the same software environment within which they originally sealed that data!
This is remarkably clever. When you are running under a trusted nub, your applications can use the SCP to decrypt and process data, but you can't run software which subverts a TA's policy (because the nub will not permit the policy to be subverted).
When you are not running under a trusted nub, you can run software which subverts a TA's policy (because the nub isn't able to prevent it), but your applications will no longer be able to decrypt any sealed data, because the SCP won't be willing to perform the decryption.
There is a long discussion of how you can make a backup, or upgrade your system, or migrate your software and data to a new system, etc. The default with sealed storage is that any sealed data will be unusable when migrated to a new system. (Thus Ross Anderson mentioned that you can't easily leak a document to a reporter, because if the document is sealed for use only on your PC, the reporter's PC will be unable to decrypt the document.)
The Microsoft nub provides wrappers around the SCP's sealing features which allow the software which performs the sealing operation to specify a migration policy at the time the sealing operation is originally performed. The migration policy can be (approximately) one of the following, at the software's sole option: (1) Migration is prevented entirely, and the data must die with the current PC where it was created. (2) Migration is permitted upon some kind of authentication by a local user (e.g. a password) which will decrypt or command the decryption of data temporarily in order to permit it to be migrated. (3) Migration is permitted with the assistance and consent of a 3rd party -- e.g. in DRM applications, the DRM software might have to "phone home" to get consent and decryption keys which will permit a file to be decrypted temporarily in order to permit it to be migrated. This last option might be called a key escrow application, although it's not technically parallel to something like the Clipper Chip, because it doesn't facilitate wiretapping or threaten communications privacy.
Palladium's modifications to input and output hardware will prevent software from doing certain kinds of monitoring and spoofing, as well as "screen scraping". A program will be able to ask Palladium to display a dialog box which can't be "obscured" or "observed" by other software, and Palladium hardware can enforce these conditions. And there is a way to be sure that input is coming from a physical input device and not spoofed by another program. This is probably also comparable to the "physical presence detection" in TCPA, which tries to ascertain whether a user is physically present (which is a requirement in order for certain security-sensitive things to happen).
The secure output features also permit, e.g., a DVD player program to prevent other software from making screen captures. The initial version of Palladium does not control audio output in this way, so you can still record all sound output via something like TotalRecorder. (Microsoft also has an initiative called Secure Audio Path which could potentially restrict that, but SAP isn't part of Palladium proper. The Palladium secure output features are currently totally video-specific.)
We didn't talk much about the details of how TAs communicate with user-space programs, which is key to how a programmer would actually use Palladium features. We also didn't talk about whether there is some kind of authentication of a kernel or precisely which traditional kernel features are taken over by the nub. Microsoft did say that most things which are currently in the kernel will remain in the kernel.
In principle, nub and kernel are independent, so a non-Microsoft kernel could run on a Microsoft nub, or vice versa. Patent and copyright issues might prevent this from being done in practice, but it is apparently technically possible within the design of Palladium.
Microsoft's nub, including its source code, will be published for review by anyone who wants to examine it, in order to allow all of Microsoft's claims about its security properties to be verified. There is no part of Palladium's design or code which needs to be kept secret, although each SCP will contain secret cryptographic keys loaded at the time of its manufacture. Microsoft will encourage non-Microsoft people to read and discuss its nub. You will also be able to create your own nub, except that changing the nub will (as discussed above) prevent previously-sealed data from being decrypted.
If you choose to allow people on the network to tell which nub you are running, they can probably find out in a way you can't fake (using a cryptographic protocol). You can refuse to tell them, but if you do choose to tell them, you will not be able to lie about it (except maybe if you know a way to tamper with the hardware). This is like TCPA; critics note that many entities which use Palladium might assume by default that any non-Microsoft nub is untrustworthy, which would make it very inconvenient to change your nub from the Microsoft-supplied default.
Your nub's identifier is not a unique identifier for your machine, because it is the same as everyone else's nub. Palladium does not create any remotely-visible unique identifier for your machine, and actually contains some features to try to avoid inadvertently disclosing a unique identifier. There is a concept of an "identity server" which is a separate service which issues you some kind of identity credential which uses Palladium and may or may not reveal particular personal information. (I didn't get a lot of details on how identity servers would work or who would run them.)
Microsoft suggests that Palladium is flexible enough that many entities could use it to create their own policies, judgments, certification services, etc. That part of the discussion reminded me in some ways of PICS and P3P, although Palladium has a more robust technical enforcement mechanism than either of those standards.

We talked about lots of other things, but that's all I have notes on.

I also wrote a message to the cryptography list in response to someone who wondered whether Palladium would prevent you from writing your own programs and scripts:

> * or are not able to use shell scripts (at least not in
> trusted context). This means a
> strict separation between certified software and data.

The latter is closest to what's intended in Palladium. Individual programs using Palladium features are able to prevent one another from reading their executing or stored state. You can write your own programs, but somebody else can also write programs which can process data in a way that your programs can't interact with.
The Palladium security model and features are different from Unix, but you can imagine by rough analogy a Unix implementation on a system with protected memory. Every process can have its own virtual memory space, read and write files, interact with the user, etc. But normally a program can't read another program's memory without the other program's permission.
The analogy starts to break down, though: in Unix a process running as the superuser or code running in kernel mode may be able to ignore memory protection and monitor or control an arbitrary process. In Palladium, if a system is started in a trusted mode, not even the OS kernel will have access to all system resources. That limitation doesn't stop you from writing your own application software or scripts.
Interestingly, Palladium and TCPA both allow you to modify any part of the software installed on your system (though not your hardware). The worst thing which can happen to you as a result is that the system will know that it is no longer "trusted", or will otherwise be able to recognize or take account of the changes you made. In principle, there's nothing wrong with running "untrusted"; particular applications or services which relied on a trusted feature, including sealed storage (see below), may fail to operate.
Palladium and TCPA both allow an application to make use of hardware-based encryption and decryption in a scheme called "sealed storage" which uses a hash of the running system's software as part of the key. One result of this is that, if you change relevant parts of the software, the hardware will no longer be able to perform the decryption step. To oversimplify slightly, you could imagine that the hardware uses the currently-running OS kernel's hash as part of this key. Then, if you change the kernel in any way (which you're permitted to do), applications running under it will find that they're no longer able to decrypt "sealed" files which were created under the original kernel. Rebooting with the original kernel will restore the ability to decrypt, because the hash will again match the original kernel's hash.
(I've been reading TCPA specs and recently met with some Microsoft Palladium team members. But I'm still learning about both systems and may well have made some mistakes in my description.)

I'm also ignoring, for the time being, my attacks on Peter Biddle's "a blob is a blob" and "privacy = content protection" claims. That topic is interesting to me, but not necessarily urgent for people who are looking for more information on Palladium. But you should read his and Paul England's presentations from WinHEC.

Vitanuova for 2002 July 5

Friday 5th July 2002

Palladium summary?

The Microsoft meeting

Google juice

Mime Troupe

Illiteracy

Hilarious

Friday

Lack of DRM spurs music sale