Dell to Add Security Chip to PCs
Steven M. Bellovin
smb at cs.columbia.edu
Fri Feb 4 10:30:59 PST 2005
In message <42031E13.4040205 at doxpara.com>, Dan Kaminsky writes:
>>>Uh, you *really* have no idea how much the black hat community is
>>>looking forward to TCPA. For example, Office is going to have core
>>>components running inside a protected environment totally immune to
>>How? TCPA is only a cryptographic device, and some BIOS code, nothing
>>else. Does the coming of TCPA chips eliminate the bugs, buffer overflows,
>>stack overflows, or any other way to execute arbitrary code? If yes, isn't
>>that a wonderful thing? Obviously it doesn't (eliminate bugs and so on).
>TCPA eliminates external checks and balances, such as antivirus. As the
>user, I'm not trusted to audit operations within a TCPA-established
>sandbox. Antivirus is essentially a user system auditing tool, and
>TCPA-based systems have these big black boxes AV isn't allowed to analyze.
>Imagine a sandbox that parses input code signed to an API-derivable
>public key. Imagine an exploit encrypted to that. Can AV decrypt the
>payload and prevent execution? No, of course not. Only the TCPA
>sandbox can. But since AV can't get inside of the TCPA sandbox,
>whatever content is "protected" in there is quite conspicuously unprotected.
>It's a little like having a serial killer in San Quentin. You feel
>really safe until you realize...uh, he's your cellmate.
>I don't know how clear I can say this, your threat model is broken, and
>the bad guys can't stop laughing about it.
I have no idea whether or not the bad guys are laughing about it, but
if they are, I agree with them -- I'm very afriad that this chip will
make matters worse, not better. With one exception -- preventing the
theft of very sensitive user-owned private keys -- I don't think that
the TCPA chip is solving the right problems. *Maybe* it will solve the
problems of a future operating system architecture; on today's systems,
it doesn't help, and probably makes matters worse.
TCPA is a way to raise the walls between programs executing in
different protection spaces. So far, so good. Now -- tell me the last
time you saw an OS flaw that directly exploited flaws in conventional
memory protection or process isolation? They're *very* rare.
The problems we see are code bugs and architectural failures. A buffer
overflow in a Web browser still compromises the browser; if the
now-evil browser is capable of writing files, registry entries, etc.,
the user's machine is still capable of being turned into a spam engine,
etc. Sure, in some new OS there might be restrictions on what such an
application can do, but you can implement those restrictions with
today's hardware. Again, the problem is in the OS architecture, not in
the limitations of its hardware isolation.
I can certainly imagine an operating system that does a much better job
of isolating processes. (In fact, I've worked on such things; if
you're interested, see my papers on sub-operating systems and separate
IP addresses per process group.) But I don't see that TCPA chips add
much over today's memory management architectures. Furthermore, as Dan
points out, it may make things worse -- the safety of the OS depends on
the userland/kernel interface, which in turn is heavily dependent on
the complexity of the privileged kernel modules. If you put too much
complex code in your kernel -- and from the talks I've heard this is
exactly what Microsoft is planning -- it's not going to help the
situation at all. Indeed, as Dan points out, it may make matters worse.
Microsoft's current secure coding initiative is a good idea, and from
what I've seen they're doing a good job of it. In 5 years, I wouldn't
be at all surprised if the rate of simple bugs -- the buffer overflows,
format string errors, race conditions, etc. -- was much lower in
Windows and Office than in competing open source products. (I would
add that this gain has come at a *very* high monetary cost -- training,
code reviews, etc., aren't cheap.) The remaining danger -- and it's a
big one -- is the architecture flaws, where ease of use and
functionality often lead to danger. Getting this right -- getting it
easy to use *and* secure -- is the real challenge. Nor are competing
products immune; the drive to make KDE and Gnome (and for that matter
MacOS X) as easy to use (well, easier to use) than Windows is likely to
lead to the same downward security sprial.
I'm ranting, and this is going off-topic. My bottom line: does this
chip solve real problems that aren't solvable with today's technology?
Other than protecting keys -- and, of course, DRM -- I'm very far from
convinced of it. "The fault, dear Brutus, is not in our stars but in
--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb
More information about the cypherpunks-legacy