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
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
--
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
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
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
