Palladium FAQ

[Seth Johnson]

Message from Cryptography list below; FAQ text pasted below
that.  Note in particular the following passage:

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.


Microsoft says Palladium is not DRM, because their game is
*universal content control.*  They intend to provide to one
and all, the technological means to enforce the
unprecedented notion that information producers have a
"moral right" to control *how the public makes use of
information.*  Microsoft says Palladium is not DRM because
Microsoft defines DRM as mediating access on "machines in
the control of *entities other than* the content or service
provider" -- whereas Palladium is designed to mediate access
on machines *in the control of the content or service
provider* -- *not* the actual owner of the logic device
itself.

They are attempting to make it sound like they are
dispelling abusive third parties, when in fact they are
attacking free society in the name of the notion of "moral
rights."

Seth Johnson


-------- Original Message --------
Date: Wed, 21 Aug 2002 23:45:29 -0700
From: AARG!Anonymous <remailer at aarg.net>
To: cypherpunks at lne.com,
cryptography at wasabisystems.com,
mail2news at anon.lcs.mit.edu

Microsoft has apparently just made available a new FAQ on
its controversial Palladium technology at

> http://www.microsoft.com/PressPass/features/2002/aug02/0821PalladiumFAQ.asp.

Samples:

> 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.

> 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.

Hopefully Microsoft will continue to release information
about Palladium.
That should help to bring some of the more outrageous rumors
under
control.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com

----

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 at 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 exceptions1). 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. 

1 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."


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com