Cryptogram: Palladium Only for DRM

Niels Ferguson niels at ferguson.net
Mon Sep 16 15:47:33 EDT 2002


Dear all,

Well, it is kind of silly to argue with someone anonymous who doesn't even
provide a return address, but his or her arguments exactly reflect the
erroneous arguments for Pd.

Before we continue, I should state that all I know of Pd is based on the
presentation at the rump session of Crypto 2002 and the following
discussion with several Microsoft employees.

At 10:51 16/09/02 -0700, AARG! Anonymous wrote:
>Niels Ferguson writes:
>
>> What Pd adds is to take control away from the user.  It "allows" the
>> user to give up part of his control over the machine, and give it to a
>> program.  This is of course required for DRM, but I cannot really think
>> of any other application.  They talked about some things like banking
>> software, but that is just silly.  We have perfectly good cryptography to
>> handle those threats, and using Pd for banking would be very dangerous.
>> After all, the Pd chip isn't protected against physical attacks, so you
>> have to trust the owner of the computer anyway.
>
>One likely use of Pd for banking software would be to use the "secure
>vault" to lock up account number and password information.  This would
>ensure that no other software than the banking client could access this
>data, so that if you got a virus it would not be able to empty your
>banking account.  And if the virus infected the banking client software
>itself, that would change its hash which would keep it from being able
>to access the data.

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?


>Also, Palladium's attestation feature can be used to let the remote bank
>server check that the local client is clean and uninfected.  This will
>catch the case where a virus infects the client before it initially
>creates the "vault".

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


>Contrary to Niels Ferguson's comments, these kinds of applications
>are far from silly.  As we move into an era where more individuals use
>electronic banking systems, we face the risk that viruses can inflict
>serious financial costs on their victims.  The next Nimda could empty
>your bank account and transfer its entire contents irreversibly to an
>overseas server.  Given this threat, the defenses above seem not only
>desirable, but absolutely necessary to protect people from massive theft
>and fraud.  Ordinary cryptography and CPU process architectures are not
>enough to provide this type of security.

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.

Niels


==============================================================
Niels Ferguson, niels at ferguson.net, phone: +31 20 463 0977
PGP: 3EC2 3304 9B6E 27D9  72E7 E545 C1E0 5D7E

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



More information about the cryptography mailing list