Feasability of Palladium / TCPA

Tim Dierks tim at dierks.org
Mon Aug 12 12:12:19 EDT 2002


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



More information about the cryptography mailing list