Re: Restricted storage

[Bas Wijnen]

On Wed, May 31, 2006 at 08:23:53PM -0400, Jonathan S. Shapiro wrote:
> > > No, it's nonsense.  The program storing the encryption keys doesn't know
> > > if the storage is opaque.  It doesn't care either.  It's the user who
> > > cares.  And it's the user who chooses to use opaque storage (or not).
> > > The user can trust that the program runs on opaque storage, not because
> > > the programmer guarantees this (by putting a check in the program), but
> > > simply by providing opaque storage to the program.  (Intentional
> > > side-effect is that storage which is given to some other user cannot be
> > > checked for opaqueness.  This can be "fixed", but I'd rather not do that
> > > if possible.)
> > [...]
> > 
> > Which Object(s) in the system represent the user and her choices?

The user's shell.  And no other programs.  And the shell can indeed verify
opaqueness, because it knows that it has a capability to all memory, but it's
missing this one.  It can also verify by keeping track of when it asked for
opaque memory from the session manager.  It can not verify this for any memory
that it received from some other user.  That is intentional.

> Indeed. And while we are about it: where do you propose to store keys
> that are used for group signatures?

In some place that cannot be destroyed by any of the members of the group, but
only by the group administrators.  That is, in a special user account created
specially for that group.

> The objects holding such keys must be shared, and all parties need to be
> able to verify the storage safety and the identity (in the sense of "what
> binary is executing here") of the key management object.

Yes.  They can do that socially.  This user account can be very limited, and
only allow to do safe things (such as starting a key manager on opaque
storage).  In that case, since the session cannot be used for anything useful
(including reading its data), the storage doesn't even need any special
technique to make it opaque: it's automatically opaque because there is no way
to read it (or pass the capability on, even if it has it).  (Note that this is
just theoretical.  In practice, to avoid trusting too much code, making the
memory really opaque is a very good idea.)

The fact that this session does indeed behave this way must be guaranteed by
the machine owner (or by the OS designer, if we're using TC).  This party is
in the position to compromise the keys anyway, so from them you cannot get
more than a social guarantee.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature