Re: Restricted storage

On Wed, 2006-05-31 at 18:49, Bas Wijnen 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?

-Eric

Re: Restricted storage

On Wed, 2006-05-31 at 20:02 -0400, Eric Northup wrote:
> On Wed, 2006-05-31 at 18:49, Bas Wijnen 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?
> 
> -Eric

Indeed. And while we are about it: where do you propose to store keys
that are used for group signatures? 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.

shap

Re: Restricted storage

Scribit Bas Wijnen dies 01/06/2006 hora 00:49:
> (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.)

Then just don't bother to implement opaque storage and let users take
care of it on a social basis. Unverifiable opaque storage is of no use,
or I didn't understand it's purpose.

Confusingly,
Nowhere man
--

-- 
nowhere.man <at> levallois.eu.org
OpenPGP 0xD9D50D8A

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: Restricted storage

On Thu, Jun 01, 2006 at 02:58:17AM +0200, Pierre THIERRY wrote:
> Scribit Bas Wijnen dies 01/06/2006 hora 00:49:
> > (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.)
> 
> Then just don't bother to implement opaque storage and let users take
> care of it on a social basis. Unverifiable opaque storage is of no use,
> or I didn't understand it's purpose.

In case of encryption keys, the idea is that even the user doesn't need access
to the private part (except through a well-defined interface which doesn't
expose the private keys themselves, that is signing and decrypting), and that
must not be exposed to the world, not even by accident.

An accident includes the compromising the user's shell, by the way.  So this
means nobody, not even the user himself, must be able to read that data.
However, there is no need to verify this: the user knows that he can't read it
(and in fact can verify this by trying), and that's enough.  It's obvious that
nobody else can read it, so no verification is needed for that either.

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.

Re: Restricted storage

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.

Re: Restricted storage

On Thu, 2006-06-01 at 10:02 +0200, Bas Wijnen wrote:
> It's obvious that
> nobody else can read it, so no verification is needed for that either.

Statements of the form "It's obvious that..." have absolutely no place
in engineering design discussions. Either there is a principled argument
that can and should be clearly stated, or it really isn't obvious.

shap

Re: Restricted storage

On Thu, 2006-06-01 at 10:20 +0200, Bas Wijnen wrote:
> On Wed, May 31, 2006 at 08:23:53PM -0400, Jonathan S. Shapiro wrote:
> > 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.

Ah. So you propose that the computational "right of assembly" should be
present only with the consent of the system administrator?

> > 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.

No. The entire point of the need to verify is that you *can't* do that
socially, because you are forming a collaboration in which the parties
do not have absolute trust in each other. Where absolute trust exists,
no verification is necessary.

I will note only that absolute trust has never been observed in the
wild, and people have been looking for it since (at least) the beginning
of recorded history. And I don't just mean computationally.

shap

Re: Restricted storage

At Wed, 31 May 2006 20:02:55 -0400,
Eric Northup <digitale <at> digitaleric.net> wrote:
> 
> On Wed, 2006-05-31 at 18:49, Bas Wijnen 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 answer is not at all different from EROS/Coyotos and systems with
"trusted computing" components, with or without remote attestation.
The difference is not which objects represent the user and their
choices[1], but where your confidence comes from that these objects
actually represent the users and their choices faithfully.  Formal
verification doesn't help in principle: You still have to put
confidence into the modellers and provers, and in the implementation
of the hardware.

"Trusted computing" components are not components that you _can_
trust, but which you _have to_ trust in order to have confidence.
They are the components that can break your security policy.

Re: Restricted storage

At Thu, 01 Jun 2006 05:21:21 -0400,
"Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:
> 
> On Thu, 2006-06-01 at 10:20 +0200, Bas Wijnen wrote:
> > On Wed, May 31, 2006 at 08:23:53PM -0400, Jonathan S. Shapiro wrote:
> > > 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.
> 
> Ah. So you propose that the computational "right of assembly" should be
> present only with the consent of the system administrator?

Can you pelase define what you mean by "computational 'right of
assembly'"?  The term is entirely void of meaning to me.

> > > 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.
> 
> No. The entire point of the need to verify is that you *can't* do that
> socially, because you are forming a collaboration in which the parties
> do not have absolute trust in each other. Where absolute trust exists,
> no verification is necessary.
>
> I will note only that absolute trust has never been observed in the

Re: Restricted storage

At Thu, 1 Jun 2006 10:02:48 +0200,
Bas Wijnen <shevek <at> fmf.nl> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> On Thu, Jun 01, 2006 at 02:58:17AM +0200, Pierre THIERRY wrote:
> > Scribit Bas Wijnen dies 01/06/2006 hora 00:49:
> > > (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.)
> > 
> > Then just don't bother to implement opaque storage and let users take
> > care of it on a social basis. Unverifiable opaque storage is of no use,
> > or I didn't understand it's purpose.
> 
> In case of encryption keys, the idea is that even the user doesn't need access
> to the private part (except through a well-defined interface which doesn't
> expose the private keys themselves, that is signing and decrypting), and that
> must not be exposed to the world, not even by accident.

For that reason I have some of my encryption keys on a smart card, on
which they were generated (the OpenPGP smart card).  Smart cards give
me the advantages of opaque storage that I care about, while reducing
the risks that I see in it to a bare minimum.

In fact, if I were not so lazy, I probably would have generated the
key on an off-line computer, and then uploaded it to the card while
storing a print-out of the secret key in a secure place.  That would
be even better, but my needs are rather modest so I didn't.