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 [EMAIL PROTECTED]