As far as the question of malware exploiting TC, it's difficult to
evaulate without knowing more details about how the technology ends up
being used.
First there was TCPA, which is now called TCG. Microsoft spun off their
own version called Palladium, then NGSCB. But then Microsoft withdrew
NGSCB, and at this point I have no idea whether they will ever offer a
new approach.
Microsoft offered four concepts for its vision, but only two of
them are in the current TCG: Sealed Storage and Remote Attestation.
Microsoft's additional features are Trusted I/O and Process Isolation.
It's possible that TCG may incorporate these eventually, because without
them the security offered by TC is much more limited.
Microsoft's vision for application development under NGSCB involved
splitting programs into two parts, which they called the left hand side
(LHS) and right hand side (RHS). The LHS was the legacy program, which
had access to the entire Windows API. It would be responsible for user
interface, I/O, and any non-secure features. The RHS was the new stuff;
it would run in a special partitioned memory that could not be accessed
even by the OS. However the RHS would not have access to the full
Windows API, and instead would only get very limited OS support from a
mini-kernel called the Nexus. The goal was to publish the source of the
Nexus for review and to have it be simple and clean enough to be secure.
Applications would do their security stuff in the RHS modules, which
were called Nexus Computing Agents (NCAs). These could use the other TPM
features. They could encrypt data such that only that NCA could decyrpt
it; and they could attest to a remote server or peer about exactly what
NCA was running. NCAs would also have some kind of secure I/O channel
to input and display devices. An NCA would be immune to molestation by
virus and malware unless the virus got into the NCA itself, which would
be hard because they were supposed to be relatively small and simple.
Infections elsewhere in the program, in the OS, or in other NCAs would
not propagate to an NCA.
Microsoft's design was sophisticated and (IMO) elegant, and goes far
beyond anything the clumsy, design-by-committee TCG has come up with yet.
Yet NGSCB failed even before it was released. Experience from early
beta testers was uniformly negative, according to press reports, and the
project was pulled for a redesign. Nothing has been heard of it for a
year now.
The problem was apparently that this LHS/RHS design was unacceptable to
developers, introducing complexity and requiring a substantial rewrite
of existing applications. The RHS Nexus API was so primitive that it was
hard to do anything useful there, while LHS functionality was completely
unprotected and received no benefits from the new technology.
So that's where we stand. Given this uncertainty, it is hard to credit
those who claim that TC will be a golden opportunity for malware.
Nobody really knows what the architecture of TC will be by the time
it is released. In this respect, Bruce Schneier's comments were the
most accurate and prescient. Over two years ago he advised adopting a
wait and see attitude, and predicted exactly the kind of revamping and
redesign which is currently underway.
But for the purposes of analysis, let's suppose that Microsoft's original
vision were intact, and that NGSCB with the four features were actually
being deployed. How might Dan Kaminsky's scenario of an infected
Microsoft Word work out in detail?
First we need to consider how the LHS/RHS split might work for a word
processor. Most functions are not security related and will be in
the LHS. Let's imagine a security function. Suppose a company wants
to have certain documents to always be saved encrypted, and only to be
exchanged (in encrypted form) with other employees also running the secure
Word program. Nobody would be able to get access to the data except via
this special program. This could be useful for company-confidental docs.
So we will have an NCA on the RHS which can, under the guidance of
some policy, save documents in encrypted form and locked to the NCA.
No other software will be able to decrypt them because of the Sealed
Storage function of the TPM. NCA's can exchange documents with matching
NCAs on other computers, using Remote Attestation to verify that the
remote system is running the right software, and to set up a secure comm
channel between the NCAs. No other software, not even the LHS of Word,
could decrypt the data being exchanged between the NCAs. And the NCAs
run in secure memory, so that even in an infected computer there will
be no way for the malware to get access to the sensitive data.
So how does Kaminsky's attack work? He proposes to give some bogus
data to the NCA and infect it. Now, here's the problem. The NCA is
a relative small and simple program. It's not going to have the full
capabilities of the rest of Word. It has a clean interface and a clean
API to program to. Everything about the system is designed so that
secure NCAs will be relatively easy to write.
The goal here is to reduce the target size. Presently the target is the
entire Windows kernel, device drivers, services and all the other things
which run as Administrator. NCAs and the Nexus will be a much smaller
target, without the burdens of legacy code which make it so hard to
secure a system the size of Windows. (Of course this same "clean piece
of paper" approach to design is what caused NGSCB to be rejected, but we
are ignoring that for now in this thought experiment.) This gives us
reason to expect that NCAs and the Nexus will be much harder for virus
writers to hit than the big, fat, juicy target of Windows itself.
But no software is perfect, so let's suppose that some NCAs do have bugs
and can be infected. Kaminsky is right that these agents would then be
immune to memory-based AV scanners. Even though the scanners run with
full privileges, they can't see NCA memory. So this does give a virus
a place to hide. But what can the virus do? Remember, NCAs do not
have access to the full Windows API. They have a much simpler and more
primitive API in the form of the Nexus, and it's primarily oriented around
doing crypto operations. So a virus can come in and do some crypto.
Big whoop.
It's important to understand that architecturally, it's not like you break
into a "trusted code layer" and can then do whatever you want. NCAs are
still protected from one another. The Nexus is protected from NCAs.
The only single point of failure is the Nexus itself, but as I said it
is designed as a micro kernel set up for open review. This is the one
piece of code they would focus most intently on making bulletproof.
The other problem with breaking into an NCA is that if it changes the
memory footprint of the agent, the agent will lose access to its own
sealed storage. The sealed data is locked to the hash of the agent, so
if the agent's code is altered, unsealing will no longer be possible.
The virus can't even get access to the sensitive documents the NCA
was protecting.
Based on these considerations, attacking NCAs does not seem to be a
productive avenue for malware writers. The other possibility is for virus
writers to do as they do now, ignore the RHS and just go after Windows.
As Steve Bellovin points out, they can still delete files, send out
copies of themselves, and wreak other havoc. What good is TC against
this threat?
The benefit of TC is that data which is secured by NCAs would be immune
to discovery and disclosure by malware which broke into the rest of
the machine. This could include financial account numbers, passwords,
records and other important documents. We have already seen viruses
which scan disks for things that look like credit card and account
numbers, and probably these will increase in the future. Just being
able to have a secure, hardware protected vault for hiding this data
will be an important step forward for security.
Other kinds of applications will also benefit from immunity to malware.
Any network application can use remote attestation to make sure that
its servers, clients or peers are running intact, in secured and
isolated memory, on a TC enabled system. One example which has been
proposed is secure election software. It would be crazy to think about
Internet voting with today's PCs, but running a voting client as an NCA
would enable safe voting even on a malware infected PC. Another idea,
which should be near and dear to the cypherpunk heart, is a TC secured
remailer network. Each remailer could verify that the others in the net
were running unmolested, and even remailer operators would be unable to
monitor traffic passing through their systems.
TC will not stop the malware threat, but it aims to bypass it, by letting
designers create a new generation of applications which each runs securely
in its own world. This would stop the worst feature of today's systems,
that a failure in one part of the PC makes the whole thing insecure.
That will be a major step forward for the security and usability of the
next generation of computers.
If the technology is allowed to exist, that is.
