Cryptogram: Palladium Only for DRM

AARG!Anonymous remailer at aarg.net
Mon Sep 16 19:04:19 EDT 2002


David Wagner writes:
> I'm a little confused on this point.  Does Palladium really check the
> hash on running software?  I was under the impression that any hashes
> would be computed only when the banking software was loaded.  If this
> is the case, then a virus could simply infect the software after it
> has been loaded from disk.  In other words, the virus could attack the
> in-memory image rather than the disk image.  Probably the Palladium
> designers have noticed this.  What defenses does Palladium incorporate
> against this sort of attack?

The Palladium white paper [1] provides more information.  They have some
special memory which is supposed to be isolated from the rest of the
computer.  "Trusted code runs in memory that is physically isolated,
protected, and inaccessible to the rest of the system, making it
inherently impervious to viruses, spy-ware, or other software attacks."
Also, "Trusted code cannot be observed or modified when running in the
trusted execution space."

Probably what happens is that software is hashed as it is loaded into this
secure memory region.  This hash assures that the software is undamaged
at load time, and then the hardware keeps it safe from modification
after that.

> >Ordinary cryptography and CPU process architectures are not
> >enough to provide this type of security.
>
> Standard process separation, sandboxes, jails, virtual machines, or other
> forms of restricted execution environments would suffice to solve this
> problem.

Nothing done purely in software will be as effective as what can be done
when you have secure hardware as the foundation.  I discuss this in more
detail below.

> There is no need for remote attestation, for the DRM-enabling
> features of Palladium, or for its other features that could be used to
> take away control from the owner of the machine.  A banking application
> is a great example where the user's and the bank's interests are aligned,
> and hence there is no need for physical security or for a semi-coercive
> infrastructure for taking control away from the owner of the machine.
> It's only the fact that today's OS's aren't very good at providing process
> separation that prevents us from deploying comparable defenses today.
> If security for banking applications was really the goal, why tack on
> these controversial DRM-enablers?

Microsoft has never denied that Palladium can be used for DRM.  From the
white paper [1], "While DRM and 'Palladium' are both supportive of
Trustworthy Computing, neither is absolutely required for the other to
work. DRM can be deployed on non-'Palladium' machines, and 'Palladium'
can provide users with benefits independent of DRM. They are separate
technologies. That said, the current software-based DRM technologies
can be rendered stronger when deployed on 'Palladium'-based computers."

All they have ever said is that Palladium is not solely for DRM.  It seems
clear that Palladium has other uses.  Contrast this with the comment by
Niels, that the secure chip is "only there to support DRM".  Again and
again critics make this very strong claim, that Palladium's design is
ONLY for DRM.  Is it any wonder that Microsoft downplays the importance
of DRM, if only to try to get some balance against this extreme position?



Niels Ferguson writes:
> We don't need Pd for a "secure vault". Standard cryptographic techniques,
> just like the ones that Pd uses, are perfect for this. And protecting the
> secure vault form viruses etc. is something that you don't need Pd for. It
> is the operating system that _chooses_ to allow one program to interfere
> with another. I know it is too much work to rewrite Windows, but you could
> run a secure kernel, very much like the Pd kernel, on existing Pentium
> hardware and provide perfect separation between programs. If VMware can do
> it on existing hardware, why can't Microsoft?

You won't get as much security if you do it entirely in software.  As one
obvious point of attack, what if the security-critical portions of the
OS are altered by a virus, either in memory or on disk?  Palladium can
protect against that in two ways: by using its shielded memory which is
inaccessible to unauthorized programs; and by using its security chip
to make sure that the critical parts of the OS are the same as before
when they are loaded into this special area.

> I designed e-cash banking protocols for a living at DigiCash. There is no
> need for the remote bank to check that the local client is clean. Like I
> said, we have cryptography to handle that.

Your cryptography won't protect against an attack where a virus is
initiating the transaction, pretending to be the user.  That kind of
attack is out of scope for cryptographic protection, but it is one of
the things that Palladium is intended to address.

> And a security kernel on Pentium
> hardware could perfectly well check whether a client has been infected by
> checking a digital signature. Again, no need for special Pd hardware at all. 

Only if the security kernel itself is intact, as well as its copy of the
root key that it trusts to issue these signatures.  Palladium gives you
a hardware root of trust for this problem of whether your software has
been hacked.

> And this is where I think you go wrong. All the problems you mentioned can
> be solved using existing hardware. If you take the Pd architecture and run
> the 'secure chip' functionality on the main CPU, you get a system that
> achieves all the goals of the Pd project, except that the user keeps
> control of his own machine.
>
> This was my original comment: the only reason why you need a separate chip
> it to take away control from the user. And it is all done under the guise
> of providing security for the user. Much of the Pd work is very valuable in
> finally providing reasonable security for the PC, but the 'secure chip' is
> only there to support DRM and take control away from the user.

To recap, Palladium basically provides just three functions:
 - The secure memory allows software to be loaded and its hash taken by
   the security chip, and then it keeps the software safe.
 - The security chip can optionally report the hash to a remote party,
   signed with its key.
 - The security chip can encrypt and decrypt data, embedding the hash
   so that the decryption can only be done if the hash is unchanged.

A smart guy like you ought to be able to figure out uses for this beyond
DRM.  While walking the dog a few weeks ago I came up with several ways
to use the system [2] that rely on letting the user provably give up some
control of his machine.  Even Adam Back, who opposes this technology,
was willing to describe additional positive uses [3], including selling
CPU cycles such that the purchaser gains greater assurance of privacy
and integrity.

Adam had the intellectual honesty and integrity to say something favorable
about this technology even though he continued to oppose it on balance.
It's sad to see how few people have the courage to take this stance.
Ask yourself, if you did think of a good use for Palladium, would you
speak up about it in order to promote a balanced and fully informed
discussion?  Or would you remain silent in order to further your personal
political aims?

In any case, it is clear that even to the degree that Palladium is
designed to allow software to run in an environment where the user can
credibly promise not to molest it, there are many other applications
beyond DRM.



Perry Metzger writes:
> Why not simply design the OS so it is not a likely victim for viruses?
> This is a general security problem, not one special to banking
> operations.

That's a great idea.  I don't know why nobody thought of that before.

> (And before you mention the current worm infecting Linux apache sites,
> that's also caused by bad design, not an problem that requires
> hardware to fix.)

Right, so all we need is good design!  Damn, all these years struggling
to write secure software, and it's been staring us in the face all along.

> In any case, all of this is silly. Palladium is no more likely to be
> bugless than the OS. If you break it, why is that less damaging than
> breaking the OS?

The idea is that Palladium is a small amount of code that manages access
to the shielded memory and the security coprocessor.  If you can get this
little bit of code right, then you can get the securitiy promised by
Palladium.

> > The next Nimda could empty your bank account and transfer its entire
> > contents irreversibly to an overseas server.
>
> Not under US law it couldn't. You could just have the transfer
> reversed as fraudulent.

That's good to know.  Who exactly eats the charges if the money is no
longer present in the foreign bank account by the time you convince
everyone that the transfer was fraudulent?  And how are you going to
prove that, anyway?  Have you heard Ross Anderson's stories about people
trying to get unauthorized ATM withdrawals reversed?


[1] http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.asp
[2] http://www.mail-archive.com/cryptography@wasabisystems.com/msg02497.html
[3] http://www.mail-archive.com/cryptography@wasabisystems.com/msg02526.html

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



More information about the cryptography mailing list