At this point we largely agree, security is improved, but the limit remains assuring security of over-complex software. To sum up: The limit of what is securely buildable now becomes what is securely auditable. Before, without the Palladium the limit was the security of the OS, so this makes a big difference. Yes some people may design over complex trusted agents, with sloppy APIs and so forth, but the nice thing about trusted agents are they are compartmentalized: If the MPAA and Microsoft shoot themselves in the foot with a badly designed over complex DRM trusted agent component for MS Media Player, it has no bearing on my ability to implement a secure file-sharing or secure e-cash system in a compartment with rigorously analysed APIs, and well audited code. The leaky compromised DRM app can't compromise the security policies of my app. Also it's unclear from the limited information available but it may be that trusted agents, like other ring-0 code (eg like the OS itself) can delegate tasks to user mode code running in trusted agent space, which can't examine other user level space, nor the space of the trusted agent which stated them, and also can't be examined by the OS. In this way for example remote exploits could be better contained in the sub-division of trusted agent code. eg. The crypto could be done by the trusted-agent proper, the mpeg decoding by a user-mode component; compromise the mpeg-decoder, and you just get plaintext not keys. Various divisions could be envisaged. Given that most current applications don't even get the simplest of applications of encryption right (store key and password in the encrypted file, check if the password is right by string comparison is suprisingly common), the prospects are not good for general applications. However it becomes more feasible to build secure applications in the environment where it matters, or the consumer cares sufficiently to pay for the difference in development cost. Of course all this assumes microsoft manages to securely implement a TOR and SCP interface. And whether they manage to succesfully use trusted IO paths to prevent the OS and applications from tricking the user into bypassing intended trusted agent functionality (another interesting sub-problem). CC EAL3 on the SCP is a good start, but they have pressures to make the TOR and Trusted Agent APIs flexible, so we'll see how that works out. Adam -- http://www.cypherspace.org/adam/ On Mon, Aug 12, 2002 at 04:32:05PM -0400, Tim Dierks wrote:
At 09:07 PM 8/12/2002 +0100, Adam Back wrote:
At some level there has to be a trade-off between what you put in trusted agent space and what becomes application code. If you put the whole application in trusted agent space, while then all it's application logic is fully protected, the danger will be that you have added too much code to reasonably audit, so people will be able to gain access to that trusted agent via buffer overflow.
I agree; I think the system as you describe it could work and would be secure, if correctly executed. However, I think it is infeasible to generally implement commercially viable software, especially in the consumer market, that will be secure under this model. Either the functionality will be too restricted to be accepted by the market, or there will be a set of software flaws that allow the system to be penetrated.
The challenge is to put all of the functionality which has access to content inside of a secure perimeter, while keeping the perimeter secure from any data leakage or privilege escalation. [...]
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com