This is a cached copy. It was taken on 2002-09-11, for the purpose of criticism using crit.org

Microsoft "Palladium" Initiative Technical FAQ

August 2002

Q: What is the "Palladium" initiative, anyway?

A: The "Palladium" code name refers to both hardware and software changes. Specifically, it refers to a new set of features in the Microsoft® Windows® operating system that, when combined with new hardware and software, provide additional security services to PCs. There are four categories of these features:

• Curtained memory. The ability to wall off and hide pages of main memory so that each "Palladium" application can be assured that it is not modified or observed by any other application or even the operating system
• Attestation. The ability for a piece of code to digitally sign or otherwise attest to a piece of data and further assure the signature recipient that the data was constructed by an unforgeable, cryptographically identified software stack
• Sealed storage. The ability to securely store information so that a "Palladium" application or module can mandate that the information be accessible only to itself or to a set of other trusted components that can be identified in a cryptographically secure manner
• Secure input and output. A secure path from the keyboard and mouse to "Palladium" applications, and a secure path from "Palladium" applications to a region of the screen

When running, "Palladium" provides a parallel execution environment to the "traditional" Windows kernel- and user-mode stacks; "Palladium" runs alongside the OS, not underneath it.

The goal with "Palladium" is to help protect software from software; that is, to provide a set of features and services that a software application can use to defend against malicious software also running on the machine (viruses running in the main operating system, keyboard sniffers, frame grabbers, etc). "Palladium" is not designed to provide defenses against hardware-based attacks that originate from someone in control of the local machine.

Q: How can I learn more about "Palladium" beyond what's in this FAQ?

A: Microsoft Corp. will be publishing additional technical information about "Palladium" over the coming months. To be notified when this information is available, send e-mail to pdinfo@microsoft.com, with "subscribe" in the subject line. We've established this announce-only mailing list to keep you informed as new information becomes available. We'll send a short note to this list whenever new information has been posted to Microsoft.com.

Q: What is the "SSC" component of "Palladium"? What is a "nexus" in "Palladium"?

A: These two terms refer to components of the "Palladium" infrastructure:

• The Security Support Component (SSC) is a hardware module that can perform certain cryptographic operations and securely store one or more cryptographic keys that are used by "Palladium" to provide the sealed storage and attestation functions. At a minimum, the SSC provides RSA public-key operations (encryption, decryption, digital signature generation and verification), AES encryption and decryption, and SHA-1 hash computation. The SSC also contains at least one RSA private key and AES symmetric key that are private to the SSC and never exported from the chip.
• A nexus, what we used to refer to as a "nub" or "trusted operating root," is essentially the kernel of the "Palladium"-isolated software stack. "Palladium" services are initialized by booting the "Palladium" hardware with a mini operating system kernel, the nexus. The nexus provides a limited set of APIs and services for "Palladium" applications, including sealed storage and attestation functions. Think of "Palladium" applications and a "Palladium" nexus as residing in the user mode and kernel mode spaces of the parallel "Palladium" execution environment.

Anyone can write a nexus for "Palladium," but the user always has the ultimate authority over what nexuses are allowed to run on top of the "Palladium" hardware.

Q: What is the "Palladium" privacy model?

A: The users are always in control over whether "Palladium" is enabled on their PC and what nexuses have access to specific "Palladium" functions. "Palladium" provides a fine-grained access control model that allows users to specify (by hash) whether an individual nexus has the right to invoke a specific security operation. In addition, SSC functions that reveal potentially machine-identifying information, such as the RSA public key, may only be performed once per SSC reset (and the SSC cannot be reset from software; you have to power-cycle the PC).

Q: What's the difference between "Palladium" and DRM?

A: Digital rights management (DRM) generally refers to software and/or hardware systems that enforce policies that mediate access to digital content or services on machines in the control of entities other than the content or service provider. Once the user of a machine accepts a set of policies, DRM systems are designed to enforce those policies even if the machine owner (or malicious software running on the user's machine) subsequently tries to subvert them.

"Palladium" itself is not a DRM system. DRM applications can, however, be built on top of "Palladium." What "Palladium" offers is a way to isolate applications (to avoid snooping and modification by other software) and store secrets for them while ensuring that only software trusted by the person granting access to the content or service has access to the enabling secrets. A DRM system can use this environment to help ensure that content is obtained and used only in accordance with mutually understood set of rules.

While "Palladium" enables DRM-style policy enforcement, it also can ensure that user policies are rigorously enforced on user machines. In addition, "Palladium" software can provide a mechanism to ensure that user interactions in unsafe environments (such as the Internet) can be safeguarded by software that the user trusts to protect his or her interests and wishes.

The powerful security primitives of "Palladium" offer benefits for DRM providers, but as important, they provide benefits for individual users and other service providers. "Palladium" can ensure that a virus or other malevolent software (even embedded in the OS) cannot observe or record the encrypted content, whether the content contains a user's personal data, a company's business records or other forms of digital content.

Q: Isn't DRM just for the benefit of big studios and major labels that want to control access to content, restrict its usefulness and get bigger fees? Won't "Palladium" give them unreasonable control over users?

A: Unfortunately, people tend to view DRM systems as being limited to functioning as copy-protection systems for commercial, mass market movies or music. While this is a valuable application that facilitates the digital distribution of content, there are much broader applications, particularly in the enterprise.

First, it is important to note that the technical mechanisms underlying DRM as employed by the motion picture industry can also be deployed to enforce restrictions on any private information used on a machine that is outside the control of the "owner" of that information (e.g., personally identifiable information such as medical records, corporate information, financial records and so on). In other words, DRM can provide a mechanism by which anyone can impose access control over remote networks and/or enforcement of user policy over sensitive information.

Second, "Palladium"-enabled DRM systems can overcome the overly restrictive and sometimes consumer-unfriendly mechanisms that are creeping into closed, captive devices (such as some consumer electronic devices and cell phones), by providing a broad, interoperable and open platform for content. Unlike closed, captive platforms, "Palladium" allows any provider or even individual to build a trustworthy interoperable mechanism that is not in the exclusive control of a single entity.

Third, unlike some antipiracy proposals endorsed by some content owners, no "Palladium" application can censor, monitor or disable another "Palladium" application - or in fact any software running on a user's machine - without the user's permission. This central principle of "Palladium," that machine owners, whether they are individual consumers or organizations, are in complete control of their machines and the programs they run, is in stark contrast with some current proposals that would mandate that all machines include monitoring systems that could arbitrarily disable content or programs. "Palladium" has no mechanism for filtering content, nor does it provide a mechanism for proactively searching the Internet for "illegal" content.

"Palladium" enables scalable, granular policy statement and enforcement mechanisms that extend customary file- or resource-protection services, while making these mechanisms interoperable over disparate disconnected systems.

"Palladium" enables policy enforcement that can benefit many parties, but enforcement remains in the control of users. Whether or not they use it in conjunction with DRM systems, individuals can use such systems to maintain the confidentiality or controlled sharing of their documents or even online collaboration with their friends, co-workers or colleagues, or to control sensitive operations performed on their machines.

Q: Is "Palladium" Microsoft's implementation of the Trusted Computing Platform Alliance (TCPA) specification?

A: No, "Palladium" is not an implementation of TCPA spec. The two projects do share some features, such as attestation and sealed storage, but they have fundamentally different architectures. (To learn more about the TCPA's approach, you can download a copy of version 1.1 of its spec from its Web site.)

Q: OK, so how does "Palladium" differ from the TCPA spec?

A: The key difference between the two models is the relationship between the security co-processor - the Trusted Platform Module (TPM) in TCPA and the SSC in "Palladium" -and the rest of the PC. In the TCPA model, the TPM is a mandatory part of the boot sequence on a TCPA-certified platform. A TCPA TPM is able to measure (make signed statements about) the entire set of software that is running on a PC. In contrast, "Palladium" is designed to sit side by side with the PC's operating system and does not need to be involved with the boot process of the machine. The use of security features provided by "Palladium," including all functions involving the SSC, is always optional and under the user's control.

Q: So I won't be able to play any MP3s on my PC any more?

A: You will. "Palladium" brings additional capabilities to the PC but does not interfere with the operation of any program that runs on current PCs. "Palladium" never imposes itself on processes that do not request its services; "Palladium" features must be requested by a program. So the MP3 player you have today will still work on a "Palladium"-enabled PC tomorrow.

Q: I've heard that "Palladium" will force people to run only Microsoft-approved software.

A: "Palladium" can't do that. "Palladium's" security chip (the SSC) and other features are not involved in the boot process of the OS or in the OS's decision to load an application that doesn't use a "Palladium" feature and execute it. Because "Palladium" is not involved in the boot process, it cannot block an OS, or drivers or any non-"Palladium" PC application from running. Only the user decides what "Palladium" applications get to run. Anyone can write an application to take advantage of "Palladium" APIs without notifying Microsoft (or anyone else) or getting its (or anyone else's) approval.

Playing devil's advocate, one might then ask, "But you have to be running a Microsoft operating system, right?" Remember, we have defined the "Palladium" initiative as a "new set of features in a forthcoming version of Windows that, when combined with new hardware and software, enable . . ." What we refer to as "Palladium" incorporates a Microsoft operating system. For further discussion of other OSs and "Palladium," see the last two questions of this FAQ.

It will be possible, of course, to write applications that require access to one or more "Palladium" services in order to run. Such applications could implement access policies, enforced by a "Palladium" application, that would allow the application to run only if it has received some type of cryptographically signed license or certificate. But "Palladium" isolates applications from each other, so it is not possible for one "Palladium" application to prevent another from running.

Q: Some people have claimed that "Palladium" will enable Microsoft or other parties to detect and remotely delete unlicensed software from my PC. Is this true?

A: No. As stated above, the function of "Palladium" is to make digitally signed statements about code identity and hide secrets from other "Palladium" applications and regular Windows kernel- and user-mode spaces. "Palladium" doesn't have any features that make it easier for an application to detect or delete files.

Q: Does "Palladium" spell the end of the smart card industry?

A: We believe smart cards and "Palladium" are complementary technologies because each focuses on a different type of authentication problem. Smart cards (and other cryptographic tokens) typically are used to authenticate users: You can be sure the user is present because you have proof that the smart card is present (the card's cryptographic response to a one-time challenge) and, theoretically, only the user knows the PIN to enable the card. "Palladium" is concerned with authenticating the machine and/or a stack of software running on the machine: "Palladium" by itself doesn't provide the presence guarantees that a cryptographic token does. (Note that it would be possible to build a digital signature application that ran on top of "Palladium" and enforced the same user-present guarantees as a cryptographic token.)

In the end, "Palladium" is very likely to increase the benefits that smart cards offer and increase demand for them.

Q: Won't the FBI, CIA, NSA, etc. want a back door to "Palladium"?

A: Microsoft would refuse to voluntarily place a back door in any of its products and would fiercely resist any government attempt to require back doors in products. From a security perspective, such back doors are an unacceptable security risk because they would permit unscrupulous individuals to compromise the confidentiality, integrity and availability of our customers' data and systems. From a market perspective, such products would not be marketable, either domestically or internationally. Equally important, deliberately inserting such vulnerabilities would undermine Microsoft's reputation in the marketplace as a trusted vendor of products. For these reasons and others, we would, as we did during the encryption debate, oppose any such government efforts.

Q: Will "Palladium" really stop spam/prevent viruses for me?

A: Unfortunately, no. Despite the hype in the media, "Palladium" will not stop spam or prevent viruses all by itself. But by using "Palladium" as a foundation, there are a number of trust and infrastructure models we can build that will help combat spam and viruses in new and effective ways.

Let's look at spam first. There's been plenty of research on techniques to automatically reject spam e-mail or restrict the ability of spammers to generate it in the first place. These techniques include the following:

• Simply rejecting mail that isn't authenticated or digitally signed with a "validated" identity (which would block all anonymous e-mail, including desired anonymous e-mail)
• Forcing spammers to perform some nontrivial computation for each message they wish to send
• Maintaining per-user whitelists and blacklists of senders
• Scoring every inbound e-mail message using heuristics that look for common characteristics of spam messages

"Palladium" systems could certainly be used to improve signing-required or computation-required regimes, compared with what's possible today on conventional hardware. (The latter is probably more interesting because "Palladium" provides facilities that would allow a sender to prove to a recipient that the sender performed a particular computation within the "Palladium" environment.) Clearly, the possibilities for antispam measures on "Palladium" PCs is a research area deserving of further study.

With respect to viruses, the contribution from "Palladium" is a little more straightforward. Since "Palladium" does not interfere with the operation of any program running in the regular Windows environment, everything, including the native OS and viruses, runs there as it does today. So we're still going to need antivirus monitoring and detection software in Windows as well. However, "Palladium" does provide antivirus software with a secure execution environment that cannot be corrupted by infected code, so an antivirus program built on top of a "Palladium" application could guarantee that it hasn't been corrupted. This grounding of the antivirus software allows it to bootstrap itself into a guaranteed execution state, something it can't do today.

Q: What's the difference between "Palladium" and per-processor serial numbers?

A: A per-processor serial number (or ID) is a piece of unique state that can be read by any application with access to the processor. The content of the ID is revealed to anyone requesting it, and there is no way to blind or use an indirect identity with a per-processor ID. More important, users can be uncertain about whether the per-processor ID is accessible only to the software they want it to be accessible to. A key design principle of "Palladium" is that no processor or user identification is enabled without the user's permission. In addition, "Palladium" will allow users fine-grain control of any such use or disclosure. A corollary is that users may choose to run "Palladium" software that blinds or renders anonymous any identity in many circumstances (not all - you want your bank to be sure who you are).

To understand the difference between "Palladium" and a per-processor serial number we first have to look at what unique, per-machine state exists under "Palladium." One of the hardware components of "Palladium" is the Security Support Component, which is a smart-card-like core with a small amount of persistent, on-chip state. Each SSC includes a unique RSA public/private key pair and a unique AES symmetric key. The AES symmetric key and RSA private key never leave the chip; they are used by the SSC to seal data so that only the SSC can retrieve it and make signed attestations, respectively. The SSC also will include a digital certificate for the RSA public key, issued by the manufacturer, stating that the private key corresponding to the certified public key is indeed the private key of a "Palladium" SSC.

Because the RSA key pair that ships with each SSC is unique, it could be used to identify the motherboard/PC that contains the SSC. To protect against this sort of data aggregation, Microsoft envisions a model in which each nexus generates random RSA key pairs for itself and uses the SSC key only to prove that the random keys were generated by a specific nexus on a "Palladium" machine. That is, we envision there being a number of third-party "pseudo-identity providers" that will accept as input an RSA public key signed by a "Palladium" SSC key as well as the digital certificate for that SSC key provided by the manufacturer, and in turn issue a new certificate for the random key. The new certificate would attest that the key is associated with a "Palladium"-enabled device but would not include any per-machine details or references to the SSC key. These pseudo-identity providers would be trusted third parties (TTPs) that would have the technical means to maintain mappings between the per-machine key and any random keys submitted for certification, but it would be these random keys, certified by the TTP, that would normally be used when communicating with others.

Note that, for some applications, the TTP could be the user himself: The user (or an organization that the user was part of) could self-certify keys. Organizations or persons who "trust" that user could rely on that intermediate key.

Microsoft will not allow any applications to gain access to the SSC machine key without the user's consent, and we expect that key to be used only when generating new pseudonyms (random RSA keys) or when migrating sealed secrets from one "Palladium" device to another.

Q: Are the keys stored on the SSC renewable?

A: No, but neither are they retrievable in any practical way. It's technically conceivable that a dedicated hacker could pull the SSC from the motherboard and physically attack it in a way that would produce the key, but this would be an extreme case and even then would only affect the single machine (i.e., it would not be a "BORE," break once run everywhere, attack). And it would require physical access to the machine.

Q: I've seen claims that "Palladium" will undermine the GPL. Is that true?

A: The claims that we've seen along these lines stem from the fact that the TCPA platform has some features that are accessible only to TCPA-certified software. So if you have source code to a piece of software that uses these features, and if you make changes to the source and recompile, you'd need to obtain a new license for the software from the TCPA: This concern is not an issue with "Palladium" because "Palladium" does not contain any restricted-access functions (except for functions restricted by the user); any nexus loaded into "Palladium" can access all "Palladium" security features for itself. Nexus B cannot access nexus A's secrets stored with "Palladium," but nexus B can always seal its own secrets without needing to hold a special license (from Microsoft or anyone else).

Of course, because "Palladium" exposes a programming model, it would be possible for someone to build a "Palladium" nexus that would restrict access to itself to some set of licensed applications. And, recursively, one could write an application on top of a nexus that restricted access to itself. But a firm design principle with "Palladium" is that the hardware and software itself will not have any such restrictions.

Q: How can anyone be sure that "Palladium" does exactly what you claim it does?

A: We have attempted to make the trusted computing base (TCB) of "Palladium" as small as possible, since it is the TCB that ultimately enforces "Palladium"-based policies (and could bypass them). We will make widely available for review the source code of the critical piece of enabling software, the nexus, so that it can be evaluated and validated by third parties.

Q: Can Linux, FreeBSD or another open source OS run on "Palladium" hardware?

A: Virtually anything that runs on a Windows-based machine today will still run on a "Palladium" machine (there are some esoteric exceptions¹). If you currently have a machine that runs both Linux and Windows, you would be able to have that same functionality on a "Palladium" machine.

Q: Could Linux, FreeBSD or another open source OS create similar trust architecture?

A: From a technology perspective, it will be possible to develop a nexus for other operating systems on the hardware of a "Palladium" PC. The "Palladium" PC design is covered by patents, and there will be intellectual property issues to be resolved. It is too early to speculate on how those issues might be addressed.

¹ These exceptions would include the following:

1. Debuggers will need to be updated to work in the "Palladium" environment, but they can still work.
2. Some special performance tools will need to be updated.
3. Software that writes directly to TCPA hardware will need to be updated.
4. Memory scrub routines (at the hardware level) will need attention.
5. Third-party crash dump software may need to be updated.
6. BIOS mode hibernation features will need to be updated to work with "Palladium."