[E-Lang] MintMaker with ACLs

hal@finney.org hal@finney.org
Mon, 29 Jan 2001 11:33:45 -0800


Mark Miller writes:
> In this spirit, I'll pose the same challenge I posed to Chris Skalka: Please 
> write the MintMaker from the Ode 
> http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
> in terms of your proposal.  Feel free to invent a non-rigorous pseudo-code 
> notation.

Let me offer a very crude example, mostly to try to get a better
understanding on my own part of the relevant security features of the
MintMaker.

My Mint has a number of customers, each identified by a public account
number and a secret password.  Each customer has a balance, which is
the amount of money they have.  The Mint will receive a message from
a customer, giving his account number and authenticating himself with
his password.  The only message I'll show is one which transfers money
to another account, identified by account number:

    // account balances, indexed by account number
    int balance[];
    // passwords, indexed by account number
    String storedPassword[];

    // Message requesting transfer

    int transfer (int sourceAccount, String password, int destAccount, int amount)
    {
        if( password != storedPassword[sourceAccount )
            return ERROR_BADPASSWORD;
        if( balance[sourceAccount] < amount )
            return ERROR_INSUFFICIENTFUNDS;
        // Proceed with transfer
        balance[sourceAccount] -= amount;
        balance[destAccount]   += amount;
        return NOERROR;
    }

That's it.  To me this would be the most straightforward way of implementing
this kind of account-based money system.  It is at least in spirit an ACL
system because we're authenticating users by identity and controlling what
they can do on that basis.

Let me try to anticipate one criticism, which may or may not be relevant.
My first thought on looking at this was, the mint can cheat.  It can change
the balances any way it wants to.

But then I thought, in order to do this, the code would have to be changed.
As long as it runs the code above, it will only affect the balances in legal
ways.

So the question is, do we analyze implementations under the assumption
that we know what code they are running, or is it kosher to assume that
the attacker can change the code in any way he likes?  And specifically,
what does this imply for the E MintMaker?  Do we need to consider an
attacker who can change the code so that balances can be controlled
externally?  Or is this attack off limits?

It seems that to go down this route we need to look at the E program
in terms of who the parties are who are using it, and what their trust
relationships are.  This aspect often seems to me to be concealed
rather than revealed by the structure of E programs like the MintMaker.
Perhaps this is due to my inexperience with the language.

Hal