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 current
Russell Nelson[SMTP:[EMAIL PROTECTED]] writes:
You're wearing your programmer's hat when you say that. But the
problem isn't programming, but is instead economic. Switch hats. The
changes that you list above may or may not offer some security
advantages. Who cares? What really matters
Adam Back writes:
+---++
| trusted-agent | user mode |
|space | app space |
|(code ++
| compartment) | supervisor |
| | mode / OS |
+---++
| ring -1 / TOR |
At 07:30 PM 8/12/2002 +0100, Adam Back wrote:
(Tim Dierks: read the earlier posts about ring -1 to find the answer
to your question about feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
The addition of an additional security ring with a secured,
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
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
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
