Re: Palladium, Memory Forensics, Clouds.

[Joanna Rutkowska <joanna () invisiblethingslab com>]

Dave Aitel wrote:
> A few things stand out from my thoughts here, as I pack up to return from
> Hong Kong.
>
> The first thing is that Microsoft's best hope for Windows is to make it the
> only platform you can trust with your identity. If you have "end to end
> trust" then your ISP can say "only machines signed to your identity are
> allowed on the Internet". They can sell you internet where only IE can
> access it. How cool is that? See, not cool at all. Consumers hate it and
> people don't trust Microsoft as a company, which is why the people excited
> about it are DRM focused or just evil in general.

Yes, this is how most people perceive Trusted Computing (AKA Palladium), but in
practice this is not true and will not be anytime soon. Two main reasons:

1) The functionality you describe require Remote Attestation (TPM Quote command)
to work. There is a small catch however -- how does a remote system know that it
is "talking" to a genuine TPM and not software emulated TPM? (more precisely:
that the key used for signing the TPM Quote "packet" has been generated on a TPM
and not in software?).

This is where the EK (Endorsement Key) keys comes into play -- the theory says
that the vendor should embed an EK keypair in each TPM (unique to each TPM) they
sell. They should also publish certificates for all the EKs for their chips
(e.g. on their website). In other words EK is a root of trust for reporting for
each TPM and can be used to validate that a certain message has been signed by a
genuine TPM indeed (in fact, the various books say, EK should never be used for
remote attestation directly, as it betrays the actual unique identity of the
platform. Here is where AIK comes into play, but the details are not so
important here).

The problem is that a couple of TPMs we have looked at (all TPM 1.2) in our lab
haven't got any EK embedded. They were just blank. This means they cannot be
used, even in the future, to e.g. attest to Warner Bros. or AOL that you're
using Windows -- as simply the Warner Bros. or AOL will not be able to determine
that they are "talking with" a genuine TPM. Of course one cannot also imagine
Warner Bros or AOL to ask users to generate EKs and send the public portion to
them, as they would again have no assurance that the users indeed generated
their EKs on TPMs and not in software (when you generate an EK on a TPM you
don't have access to the corresponding private key, unless you're Chirs
Tarnovsky I guess).

In other words, a TPM without an EK written at the manufacturing process cannot
prove to a remote entity that it is a TPM. Which means we can still run Linux
and connect to all those Warner Bros. or AOL services.

2) Even assuming that all TPMs ship with EKs (and vendors publish certificates
for them), I still don't see how this could be used to implement the scenario
Dave's (and a lot of other people) talking about here:

"They can sell you internet where only IE can access it."

Whether you use Static Root of Trust (think TPM only, like in BitLocker) or
Dynamic Root of Trust (think Intel TXT), you only assure trusted boot of the
*core* system components, e.g. the hypervisor or kernel. Now, it's the
responsibility of the kernel to load (in a trusted way) all the hundreds of 3rd
party kernel drivers (we see an effort here by MS in Vista x64 with driver
signing), then all the libs and all the apps. So far so good -- this is doable.

But here is where the actual catch is: now the kernel must make sure that when
the system is running nobody can compromise all those hundreds of drivers in
*runtime* (think overflows), and also that nobody can compromise all those
system libs in *runtime*, and that nobody can compromise all those sensitive
applications (like IE, or Media Player) in *runtime* (think Dino/Charlie and Nil).

A single compromise of any of those elements means that one can get to the
address space of one of the sensitive apps (IE or Media Player) and steal all
the keys it just obtained from the remote entity (that happily verified the app
via Remote Attestation and concluded it is a trusted software). So, a single
exploit for one of the drivers, system libs, or the apps, and all your keys are
belong to the adversary, who I guess will happily post it on the internet for
all the Linux's pleasure.

Consequently, for the TC-based DRM to ever work, the following things would have
to happen:

1) Vendors should be embedding EK on TPMs they sell (and also issue certs) --
this is all possible, but what about millions of the computers that already have
TPM 1.2 and don't have an EK?

2) Microsoft would have to migrate towards a micro-kernel-like architecture,
e.g. similar to the used by Xen 3.3/3.4 with driver domains etc. Additionally
they should make sure it will not be possible to exploit any of the sensitive
apps like e.g. IE or Media Player.

Do you think point #2 is possible anytime soon? I seriously doubt it.

Oh, and this is actually what I will be talking about at the EuSecWest next week
(in addition to evil maids and malicious Chinese PCI backdoors) :)

<cut>

> The other thing that keeps coming up is memory forensics. You can do a lot
> with it today to find trojan .sys's that hackers are using - but it has a
> low ceiling I think. Most rootkits "hide processes", or "hide sockets". But
> it's an insane thing to do in the kernel. If you're in the kernel, why do
> you need a process at all?

I couldn't agree more:

http://invisiblethings.org/papers/rutkowska_bhfederal2006.ppt

(slide #14 and later)

Welcome in 2006 :)

joanna.

-- 
Joanna Rutkowska
Founder/CEO
Invisible Things Lab
http://invisiblethingslab.com/

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave