Cryptogram: Palladium Only for DRM

[Peter N. Biddle]

Hey Ed - I think that we may be in agreement. Most of what you say below
makes sense to me.

This is how I have been describing trust recently - including it so that you
will at least understand where I am coming from when I use the term (cribbed
directly from a recent slide deck).

I can't trust anything (a component, an entity, etc.) unless.
    I know who/what it is, and that it's not an imposter
    I know its state-it has been properly initialized
    I know that it cannot be tampered with
    I know that my communication with it is private and tamper-proof
These are four elements of trust
    I still need to be able to verify (trust) that the component behaves
properly in an ongoing manner

Everyone has different perspectives on "trust," some even contextual
    "Doctrine of Multiple Trustors": trust is multi-way, not two-way
        It is up to each party to determine its own trust criteria, and to
use mechanisms (e.g., certification) to measure and assert those criteria
        Anything / everything can be certified to be trusted by anyone /
anything
     Many "things" (HW or SW) will be certified by more than one entity
        Each entity may be measuring different facets of trust

I'd love to see your papers.

P

----- Original Message -----
From: "Ed Gerck" <egerck at nma.com>
To: "Peter" <PeterNBiddle at hotmail.com>
Cc: <cryptography at wasabisystems.com>
Sent: Wednesday, September 18, 2002 10:04 AM
Subject: Re: Cryptogram: Palladium Only for DRM


> Peter:
>
> The question of "what is trust" might fill this listserver for months.
> But, if we want to address some of the issues that Pd (and, to some
> extent, PKI) forces on us then we must be clear what we mean when
> we talk about  trust in a communication system -- what is a trusted
> certificate, a trusted computer? Trusted for what? What happens
> when I connect two computers that are trusted on matters of X --
> are they trusted together on matters of X, less or more? What do
> we mean by trustworthy?
>
> I can send you some of my papers on this but the conclusion I arrived
> is that in terms of a communication process, trust has nothing to do with
> feelings or emotions.
>
> Trust is qualified reliance on information, based on factors independent
of
> that information.
>
> In short, trust needs multiple, independent channels to be communicated.
> Trust cannot be induced by self-assertions -- like, "trust me!"  or "trust
Pd!"
> More precisely, "Trust is that which is essential to a communication
channel
> but cannot be transferred using that channel."  Please see the topic
"Trust Points"
> by myself in "Digital Certificates: Applied Internet Security" by Jalal
Feghhi,
> Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-130980-7, pages
> 194-195, 1998.
>
> That said, the option of being *able* to define your own signatures on
what
> you decide to trust does not preclude you from deciding to rely on someone
> else's signature.  BTW, this has been used for some time with a hardened
version
> of Netscape, where the browser does not use *any* root CA cert unless you
sign
> it first.
>
> Thanks for your nice  comment ;-)
>
> Ed Gerck
>
>
>
> Peter wrote:
>
> > 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
>

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