Cryptogram: Palladium Only for DRM

[Peter]

I disagree with your first sentence (I believe that Pd must be trustworthy
for *the user*), but I like much of the rest of the first paragraph.

I am not sure what value my mother would find in defining her own
signatures. She doesn't know what they are, and would thus have no idea on
who or what to trust without some help.

What my mother might trust is some third party (for example she might trust
Consumer's Union). We assumed we needed a structure which lets users
delegate trust to people who understand it and who are investing in
"branding" their take on the trustworthiness of a given "thing" (think UL
label, Good Housekeepking Seal of Approval, etc.). I totally agree that some
small segment of users will have an active interest in managing the trust on
their machines directly (like, maybe, us) but any architecture that you want
to be used by "normal" PC users needs to also let users delegate this
managment to others who can manage it for users (just like we might decide
to use others to manage our retirement funds, defend us in a court of law,
or operate on our kidneys).

To delegate trust, you need to start out trusting something to do that
delegation. That's part of what Pd is addressing - Pd needs to be
trustworthy enough so that when a user sets policy (eg "don't run any SW in
Pd which isn't signed by the EFF" or "don't run any SW which isn't
debuggable"), it is enforced.

P

----- Original Message -----
From: "Ed Gerck" <egerck at nma.com>
Cc: <cryptography at wasabisystems.com>
Sent: Tuesday, September 17, 2002 2:51 PM
Subject: Re: Cryptogram: Palladium Only for DRM


>
> It may be useful to start off with the observation that Palladium will not
be
> the answer for a platform that *the user* can trust.  However, Palladium
> should raise awareness on the issue of what a user can trust, and what
not.
> Since a controling element has to lie outside the controled system, the
solution
> for a trustworthy system is indeed an independent module with processing
> capability -- but which module the user should be able to control..
>
> This may be a good, timely opening for a solution  in terms of a "write
code"
> approach, where an open source trustworthy (as opposed to trusted)
> secure execution module TSEM (e.g., based on a JVM with permission
> and access management) could be developed and -- possibly -- burned on a
> chip set for a low cost system. The TSEM would require user-defined
> signatures to define what is trustworthy to *the user*, which would set a
higher
> bar for security when compared with someone else defining what is
> trustworthy to the user.  The TSEM could be made tamper-evident, too.
>
> Note: This would not be in competition with NCipher's SEE, because
NCipher's
> product is for the high-end market and involves commercial warranties,
> but NCipher's SEE module is IMO a good example.
>
> Comments?
>
> Ed Gerck
>
>
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com
>

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com