palladium presentation - anyone going?

Adam Back adam at
Mon Oct 21 17:52:20 EDT 2002

On Sun, Oct 20, 2002 at 10:38:35PM -0400, Arnold G. Reinhold wrote:
> There may be a hole somewhere, but Microsoft is trying hard to get
> it right and Brian seemed quite competent.

It doesn't sound breakable in pure software for the user, so this
forces the user to use some hardware hacking.

They disclaimed explicitly in the talk announce that:

| "Palladium" is not designed to provide defenses against
| hardware-based attacks that originate from someone in control of the
| local machine.

However I was interested to know exactly how easy it would be to
defeat with simple hardware modifications or reconfiguration.

You might ask why if there is no intent for Palladium to be secure
against the local user, then why would the design it so that the local
user has to use (simple) hardware attacks.  Could they not, instead of
just make these functions available with a user present test in the
same way that the TOR and SCP functions can be configured by the user
(but not by hostile software).

For example why not a local user present function to lie about TOR
hash to allow debugging (for example).

> Adam Back wrote:
> >- isn't it quite weak as someone could send different information to
> >the SCP and processor, thereby being able to forge remote attestation
> >without having to tamper with the SCP; and hence being able to run
> >different TOR, observe trusted agents etc.
> There is also a change to the PC memory management to support a 
> trusted bit for memory segments. Programs not in trusted mode can't 
> access trusted memory.

A "trusted bit" in the segment register doesn't make it particularly
hard to break if you have access to the hardware.

For example you could:

- replace your RAM with dual-ported video RAM (which can be read using
alternate equipment on the 2nd port).

- just keep RAM powered-up through a reboot so that you load a new TOR
which lets you read the RAM.

> Also there will be three additional x86 instructions (in microcode)
> to support secure boot of the trusted kernel and present a SHA1 hash
> of the kernel code in a read only register.  

But how will the SCP know that the hash it reads comes from the
processor (as opposed to being forged by the user)?  Is there any
authenticated communication between the processor and the SCP?


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list