Cryptogram: Palladium Only for DRM

[Niels Ferguson]

At 16:04 16/09/02 -0700, AARG! Anonymous wrote:
>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.

But I am not suggesting to do it purely in software. Read the Intel manuals
for their CPUs. There are loads of CPU features for process separation,
securing the operating system, etc. The hardware is all there!


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

The 'secure chip' in Pd is only needed for DRM. All other claimed benefits
of Pd can be achieved using existing hardware. To me this is an objectively
verifyable truth. How can that be an extreme position, unless you wish to
call anything that contradicts your marketing speak an extreme position.


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

How does the virus ever get to the security-critical portion of the OS?
Maybe I have to explain the obvious. On boot you boot first to a secure
kernel, much like the Pd kernel but running on the main CPU. This kernel
then creates a virtual machine to run the existing Windows in, much like
VMware does. The virus is caught inside this virtual machine. All you need
to do is make sure the virtual machine cannot write to the part of the disk
that contains your security kernel. 

There is a company here in Amsterdam called NAH6 who is doing exactly this
to secure a notebook. You first boot to a minimal Linux, start VMware, and
run Windows inside the VMware. You can then encrypt all disk accesses,
including things like the Windows swap file. No virus can get at the
security kernel, because it is caught in the VMware virtual machine. There
is a beta available for download at www.nah6.com. This isn't rocket science.


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

But how does the virus get to the keys used to authenticate the user to the
bank? It doesn't. The virus could put a window up on the screen and entice
the user to type his password. The virus can then start the banking client
and generate the user interactions for the client to perform payments. But
guess what? This virus will work just as well against Pd. Of course, you
could put security features into the OS and GUI/keyboard to allow a
(secure) program to securely communicate with the user. But this solves the
problem both in my and the Pd setting. Again: no difference.


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

See above for the fallacy of your argument. The security kernel can easily
protect itself against any virus. 


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

Who are you protecting against? If the system protects the interests of the
user, then you don't need to protect the system from the user. The security
chip is only useful if you try to take control away from the user.

I've done years of research into securing transactions with the use of
tamper-resistant hardware. Back in '93 I published a paper on an electronic
payment system that used tamper-resistant hardware to improve security.
(http://www.macfergus.com/niels/pubs/mcoins-c93.html) It was one of our
main lines of work at DigiCash. 

Now, let me tell you our conclusions from years of research on how you
could use tamper-resistant hardware. The hardware becomes really useful if
it is owned and controlled by the user and it has its own controlled user
interface. That means a separate LCD screen and keys, not just a corner of
the monitor. That is not what Pd provides. There are some marginal
bennefits for having just a tamper-resistant module in the computer. But
then this module must be hardened from attack by the user, something the Pd
chips is not according to the presentation I saw. And the Pd presentation
never mentioned anything like the scenario where this gets even marginally
useful. 

You can, for example, use the tamper-resistant hardware to prevent users
from double-spending digital money, and then use cryptography to detect
them when they break the hardware and do it anyway. We looked at this for
years, but it isn't worth the trouble. The security provided by the chip is
not high enough to make it really useful for large or small transactions.
(It might be good enough for medium-sized transactions, but that is a
limited market.) No sensible bank will bet its own money on the chip (and I
have spent lots of time selling secure payment systems to banks) so you end
up using cryptography in real-time to prevent the attacks from occurring in
the first place. But then you don't need the chip anymore. Been there, done
that, even got the mug.

In the mean time we have gotten way off topic. I said the claimed benefits
of Pd can be achieved with existing hardware except for the DRM. You are
argueing that there is a use for a Pd-like secure chip, something that is
very different.


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

Like I said before, most of the Pd stuff is really welcome. Everything
except the secure chip is a great improvement, and long overdue. My
observation is that the secure chip is only needed to do DRM, and that
trying to sell it to the public under the 'we need more security' banner is
bogus. Now which part of this do you think is intellectually dishonest? And
what are my political aims? I have no interest in bashing MS or anyone
else. I just wanted to point out the flaws in some of the Pd arguments.


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

Please, name a few. So far the banking example seems to have fallen apart.
It also happens to be the field I've worked in for nearly a decade, so
maybe that helped. 


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

And a similar amount of code can achieve exactly the same on existing
hardware. The security kernel has the same set of functionality in either
case, so it remains the same size.


Cheers!

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