Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-15 Thread Russell Nelson
Adam Back writes: > So there are practical limits stemming from realities to do with code > complexity being inversely proportional to auditability and security, > but the extra ring -1, remote attestation, sealing and integrity > metrics really do offer some security advantages over the curre

Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-13 Thread Tim Dierks
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

Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-13 Thread James A. Donald
-- On 12 Aug 2002 at 16:32, Tim Dierks wrote: > I'm sure that the whole system is secure in theory, but I > believe that it cannot be securely implemented in practice and > that the implied constraints on use & usability will be > unpalatable to consumers and vendors. Or to say the same thing

trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-12 Thread Adam Back
I think you are making incorrect presumptions about how you would use Palladium hardware to implement a secure DRM system. If used as you suggest it would indeed suffer the vulnerabilities you describe. The difference between an insecure DRM application such as you describe and a secure DRM appl