Feasability of Palladium / TCPA

[lynn.wheeler at firstdata.com]

there are two possible answers:

1) it just has to be at least as secure at the risks (doing something might
improve the situation so that some number of vulnerabilities ... but not
all ... are minimized).

2) one of the excuses for not spending the money on secure software ... as
opposed to the current process .... is it wouldn't improve anything because
everything else is insecure. so there is a huge chicken and egg situation
.... no single operation should do anything about security because the
hundred of other organizations that are involved in producing insecure
components are not doing anything about security
(nobody should do nothing because everybody else is doing nothing).

I've been railing about the buffer-overflow vulnerability every since we
did the vulnerability analysis for ha/cmp in the late 80s .... it is just
another on the list of things that need fixing also. some general stuff:
http://www.garlic.com/~lynn/subtopic.html#fraud
http://www.garlic.com/~lynn/subtopic.html#assurance







tim dierks.org on 8/12/2002 10:12 am wrote:


I haven't done an in-depth reading of available information of
Palladium/TCPA specifications, but my understanding is that there is a
private key stored in hardware and a contiguous chain of trust that extends

from the hardware/BIOS through the OS to an application, with each level
validating the superior levels; specifically, the hardware/BIOS validates
the OS as compliant, and then the OS validates an application's identity.
The OS then vouches for the application to the BIOS, giving the application

the ability to make indirect use of the hardware private key in order to
engage in application-level communication with an attestation of the
integrity of all levels (hardware, OS, application).

Here's my question: who thinks this can actually be made secure? Having
spent some time looking at such security issues, developing software, and
watching security alerts fly by for software, I think there's almost no
chance that the attestations made by the OS can be very secure.

Given the nature of PC software platforms, with the size, complexity, and
diversity of vendors, I think it is guaranteed that there will be software
bugs that will allow attackers to run rogue code inside another
application's address space or otherwise cloak themselves in another
application's trust attestation. The attacker can thus get access to
protected secrets or the ability to convince a remote system that they are
an authentic & secure software instance.

Does anyone not believe that there's not going to any buffer-overflow type
bugs in drivers for third-party sound cards that will allow an attacker to
execute code as some other application? And what can be done about? It's
certainly not viable to require dramatically more code review & security in

applications & drivers: I don't think Microsoft & Intel are willing to
sacrifice the economic viability of the platform on the throne of DRM. It's

also not acceptable to customers to require that all code running on the
platform be signed & authorized (unless you're willing to destroy the
industry of software developers who are not large enough or reliable enough

to get such signatures, including the entire open source industry). I don't

believe it's technologically feasible to design a software platform that
can reliably determine the complete chain of control resulting in an API
entry-point being called. (Among other things, you can execute an attack
without having your return address address on the stack.)

Bottom line, I don't think that TCPA or Palladium will be reliable enough
to really constrain those who wish to penetrate it. Given that, I don't
think that there will be as high a value put on the technology by vendors &

rights holders (since their stuff can be stolen by others anyway). If
there's not a high differential value to these architectures, then
presumably the market will not support a high differential price, and the
technologies will not see widespread acceptance.

  - Tim Dierks

PS - I'm looking for a job in or near New York City. See my resume at
<http://www.dierks.org/tim/resume.html>




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