"Palladium" and TCPA

Thu, 27 Jun 2002 01:47:26 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Jiri Ludvik wrote:
> Richard Clayton wrote:
> > If someone can point out the difference between TCPA and Palladium I'd
> > be grateful (seems unlikely to me that chip makers will put in two
> > separate sets of hardware encryption features).
> 
> Even Microsoft probably does not know the difference exactly. See the
> details in an interview with MS's Mario Juarez at
> http://www.digitalidworld.com/print.php?sid=74

Ross' assessment that this is just a Windows version of TCPA seems to be
correct AFAICT; there's nothing that was not consistent with the basic
idea from "A Secure and Reliable Bootstrap Architecture".

Anyway, it sounds like they don't know what they're talking about from a
technical point of view. For example:

# In terms of system integrity what we have with Palladium is some new
# hardware components, actually one new component and some modified
# components. We have changes to the CPU, changes to the chip sets, and
# a new security chip that work together with the operating system to
# create what we call a Trusted Operating Root - the TOR. You can think
# of the TOR as a kind of micro-kernel.

Unless they intend to completely rewrite Windows from scratch (> 5 years
work), this is in no shape or form a micro-kernel. In a micro-kernel OS,
only a minimum of code runs at the highest privilege level, and things
like filesystems, windowing code, etc. run in outer levels, communicating
with the kernel using messages. In the TCPA architecture, as much code
as would be in a monolithic kernel gets pulled into ring 0; it just has
to be signed. This makes a big difference relative to the micro-kernel
case, see below.

# You've got machine specific secrets which are physically locked and
# cryptographically secure in a way that provide for these benefits
# without betraying information that you don't want to have revealed.
# The hardware and the architecture prevents snooping, spoofing, and
# different kinds of data interception. Because you have system secrets
# that are stored on the machine, [Palladium] is fundamentally
# impervious to a BORA (Break Once, Run Anywhere) attack. And if you
# do find a way to break open the machine - and we expect the first
# attacks to be hardware attacks where people sand off the silicon and
# pull the keys off the security chip - you've still only broken what
# that one machine can do.
#
# You can't do a widely deployable hack or put up an executable that
# will essentially break the whole platform. You may perhaps be able to
# break a machine, but you won't be able to break the guy's machine
# next to you. And moreover, when you break a machine, the compromised
# security can be spotted by service providers or other systems.

The basic assumption that Juarez is making is that it's sufficient for
the TOR and the hardware to be secure in order to prevent a software hack
that will work on all machines. That's not true: the TCB is everything
that is certified to run at kernel level, *not* just the TOR. That includes
all device and display drivers, for example, and if the OS design remains
basically the same as NT4/2000/XP, it will also include a lot of higher level
windowing code. There is not a chance in hell of making all certified code
secure. (We've seen this before with ActiveX, where there were several
Microsoft-signed controls with exploitable buffer overflow bugs.)
Furthermore, a machine that is broken using a bug in a certified component
will look just the same as any other machine - except that it will be able
to do "forbidden" things like recording the output to sound/video drivers,
etc.

(It should even be possible to run a TCPA OS for just long enough to
exploit the first bug, then replace it with another OS, keeping the
hardware fooled into thinking it's still running the TCPA OS. No doubt
the SSSCA - or whatever it's called this week - would make this illegal
in the U.S., but I can't see anything that would make it technically
impossible.)

# Its easy to have a kind of repudiation or ways to render the things
# that are being done with those secrets useless in a functional way by
# virtue of the fact that you have a unique system key set on each machine.

Again not true. If a certified component has been broken, the only
option is to revoke the certification and force an updated version to
be pushed to every machine. I hope that's not practical (think about how
much power it gives to MS if it is practical!)

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip