On Mon, Aug 12, 2002 at 01:52:39PM +0100, Ben Laurie wrote:
AARG!Anonymous wrote:
[...] What Palladium can do, though, is arrange that the app can't get at previously sealed data if the OS has meddled with it. The sealing is done by hardware based on the app's hash. So if the OS has changed the app per the above, it won't be able to get at old sealed data.
I don't buy this: how does Palladium know what an app is without the OS' help?
Here's a slightly updated version of the diagram I posted earlier: +---------------+------------+ | trusted-agent | user mode | | space | app space | | (code +------------+ | compartment) | supervisor | | | mode / OS | +---------------+------------+ | ring -1 / TOR | +----------------------------+ | hardware / SCP key manager | +----------------------------+ Integrity Metrics in a given level are computed by the level below. The TOR starts Trusted Agents, the Trusted Agents are outside the OS control. Therefore a remote application based on remote attestation can know about the integrity of the trusted-agent, and TOR. ring -1/TOR is computed by SCP/hardware; Trusted Agent is computed by TOR; The parallel stack to the right: OS is computed by TOR; Application is computed OS. So for general applications you still have to trust the OS, but the OS could itself have it's integrity measured by the TOR. Of course given the rate of OS exploits especially in Microsoft products, it seems likley that the aspect of the OS that checks integrity of loaded applications could itself be tampered with using a remote exploit. Probably the latter problem is the reason Microsoft introduced ring -1 in palladium (it seems to be missing in TCPA). Adam -- http://www.cypherspace.org/adam/ --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com