example: secure computing kernel needed

[David Wagner]

Amir Herzberg  wrote:
>I'm not sure I agree with your last statement. Consider a typical PC 
>running some insecure OS and/or applications, which, as you said in earlier 
>post, is the typical situation and threat. Since the OS is insecure and/or 
>(usually) gives administrator priviledges to insecure applications, an 
>attacker may be able to gain control and then modify some code (e.g. 
>install trapdoor). With existing systems, this is hard to prevent. However, 
>it may be possible to detect this by some secure monitoring hardware, which 
>e.g. checks for signatures by the organization's IT department on any 
>installed software.

But:

1. If you can check signatures on running software, you might as well
check the signature when the software is first executed, and prevent
it from being executed if it is not allowed.  The operating system is
going to have to be involved in the process of checking which user-level
applications are running (because on the OS knows this fact), so you
might as well get it involved in deciding which user-level applications
are allowed to be executed.  Proactive prevention is just as easy to
build as after-the-fact detection, and is more useful.

2. Your system administrator can only enumerate what applications you're
running if you have a trustworthy OS.  Today's OS's typically aren't
very trustworthy.

Let me explain.  Let's say the sysadmin want to check whether I'm running
Doom.  Fine.  That means the TPM (the hardware) is going to check what
bootloader (or nexus) was loaded at boot time, and sign that fact.
Then, the bootloader/nexus is going to check what operating system
kernel it loaded, and sign that fact.  Finally, the OS kernel is going
to check what user-level applications are running, and sign that fact.
This chain of signatures then tells you what software is running.  But,
if you want to believe in the chain of signatures, you have to believe
in the trustworthiness of all the software involved here: the TPM, the
bootloader/nexus, and the OS.  If my OS is Windows XP, you're screwed;
that chain of signatures doesn't tell you much.  There is no reason to
think Windows XP is trustworthy enough to know what software is running.
If Windows XP has a buffer overrun vulnerability somewhere -- as seems
likely -- then it could have been compromised, and my OS might be
signing false statements.  Maybe I hacked my OS to falsely report that
Doom is not running, when in fact I'm happily gaming away.  Maybe the
Doom installer hacked the OS to hide its presence.  You, and my sysadmin,
have no way of knowing, if Windows has any security vulnerability anywhere.

Conclusion: in today's machines, there's no reliable way to identify
which user-level applications are running, even if we all have a TCG
that supports remote attestation.

Now, there is an exception.  If my application is running natively on
top of the bootloader/nexus, not on top of Windows, then this issue
goes away.  In Microsoft's Palladium architecture, this is known as
"the right-hand side", and the TPM protects the "right-hand side" from
Windows and apps running on Windows.  (I don't recall whether TCPA has
a similar concept.)  But it seems unlikely that everyday applications,
like Doom, are going to be running on the "right-hand side".

To rephrase, my system administrator can reliably tell what is running
on the "right-hand side" of my machine, but my sysadmin has no reliable
way to tell what apps I'm running on top of Windows.

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