Re: Use Cases for Encapsulation and Identification

[Jonathan S. Shapiro]

On Mon, 2006-05-01 at 21:59 +0200, Marcus Brinkmann wrote:

> At Mon, 01 May 2006 14:52:32 -0400,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > The best mechanism (indeed, the *only* mechanism that really works) for
> > electronic money that I know about is described here:
> 
> I have not studied electronic money.  So, please bear with me if this
> is an ignorant question.  I have to ask because the answer could save
> both of us a lot of time.
> 
> My understanding is that e-money is implemented using public key
> cryptography, and independent of any operating system platform.
> 
> What am I missing here?

This is the distributed case, but the cryptography is only used to
reduce the problem down to the local situation. In smart contracts, the
problem to be solved is different. You have a bunch of processes (or
activities) running on the same machine within a common (OS) runtime,
and you wish to implement a market for computation. In this case, all of
the exchanges of currency are *local* exchanges of funds. The challenge
is to protect the currencies and the banks.

The hard part of this problem is that you cannot distributed the purses
using hierarchical methods without exposing the money in them.

The URL that I supplied actually gives a very nice statement of the
problem. It is part of a longer paper that was *exceptionally* well
received at Financial Cryptography, which is probably the leading
conference in such matters.

> > 2. Health Privacy, or Equivalently, Privacy of Personal Information
> > 
> > We wish to build a computer support system for a hospital. In this
> > application, it is necessary that different types of users are given
> > different levels of access according to their role and their
> > professional relationships to different patients.
> 
> This example is not confined, so it is already disqualified.

I am sorry, but it *is* confined. There are two feasible
implementations. Both use confinement, but in different forms:

  1. The client application is authorized to use some particular
     capability (and only that capability) to the database. To
     prevent the *user* from wielding that capability, it is
     provided to the user (for use in authorization) in an opaque
     bag (a KeySET).

  2. The client application has *no* initial authority. The user
     instantiates the application (more precisely, the user agent does
     this, and the user agent invokes a *generic* capability to the
     database, presenting the client application. The database
     authenticates the application and conditionally gives the
     application the appropriate read-write access (if any).

Both scenarios rely on confinement to impose the guarantee that the
application cannot leak authority to third parties.

> However, to play along: The computer that runs this application will
> in all likelihood not be a general- or even multiple-purpose computer.
> (To use it for more than one purpose could already constitute a
> violation of the regulation, because it increases the risk of a
> compromise).

Marcus: you do not know what you are talking about. In the real world,
these computers are so overwhelmingly multipurpose that it is a wonder
that the hospital operates at all. Perhaps you imagine that money grows
on trees. I actually do some work with people at the Johns Hopkins
Hospital. Believe me when I tell you that your statement is uninformed
fantasy.

> Ownership (in the sense I am talking about) will be completely within
> the hands of the responsible administrator of the hospital, and users
> will only be able to access it through a fixed system-configured
> interface.  Because there is only a fixed configuration, it is easy to
> fulfill the requirements you stated.  In fact, they could be fulfilled
> on MS-DOS.

I do not know how. This absolutely *requires* a separation kernel. Also
the HIPAA regulations preclude a hierarchical resolution. The
administrator of the hospital is NOT permitted to have universal access
to patient data. They are permitted only to make authorizing decisions
(and at that, not by themselves!).

So the administrator of the hospital definitely does NOT own the data
(in the sense that you are talking about).


shap