Anonymous Banking
From senator-bedfellow.mit.edu!PIRANHA.LCS.MIT.EDU!douzzer Sat Jan 8 00:46:36 EST 1994
Article: 10677 of alt.privacy
Path: senator-bedfellow.mit.edu!PIRANHA.LCS.MIT.EDU!douzzer
From: douzzer@PIRANHA.LCS.MIT.EDU (Daniel G. Pouzzner)
Newsgroups: alt.privacy
Subject: anonymous banking (followup to silly@ugcs.caltech.edu, "The Totally Private Bank", 4jan94)
Date: 8 Jan 1994 04:59:33 GMT
Organization: gaia
Lines: 165
Message-ID: <2glejl$rne@senator-bedfellow.MIT.EDU>
NNTP-Posting-Host: piranha.lcs.mit.edu
(signed portion begins with this line inclusive)
i think your idea is quite thoroughly workable, especially if legal
bullshit can be shoveled out of the way.
you need to use public key cryptography.
here's how it works:
a center is established which holds a widely published/advertised
keypair (well, the public half is advertised, anyway..).
when an individual wants an account, it (the individual) generates a
keypair and a temporary arbitrary identifier. the public key,
temporary identifier, and account type desired are then encrypted with
the center's public key and mailed to the center.
at the central point, a (new) permanent arbitrary identifier is
associated with (assigned to) the received public key, and a new entry
is added to the central database (with the key and permenent id, plus
fields for balance, last time of activity, time of creation, etc etc).
a message in the name of the *temporary* identifier is created at the
central point which can be anonymously retrieved, but which is
encrypted using the new account's public key. the message is signed
using the center's private key, and contains the permanent id, plus
any other initial account information appropriate for inclusion. this
includes the precise terms of the account, i.e. monthly service
charges, interest rates, etc. the account does not become active until
after
1) the message is retrieved. when it is retrieved the central copy is
deleted.
2) the message is decrypted, then signed and re-encrypted using
(respectively) the account-holder-to-be's private key and the
center's public key. this new message is sent to the center.
if (1) and (2) are not completed within a predefined interval, the
provisional unactivated account is expunged.
a message queue similar to the message described in the last paragraph
is created with a name corresponding to the *permanent* identifier.
communications from the center intended for the account holder are
spooled into this queue, and can be anonymously retrieved. (again,
they are encrypted, so they're just garbage for anyone but the account
holder.)
in order to execute a transaction:
a connection is opened to the center. only one connection per
identifier can exist at a time. opening a connection is an initially
unauthenticated (anonymous) operation, and the connection only becomes
named after the initial message is sent by the account holder to the
center.
the account holder constructs [1] a message describing the desired
transaction, signs it with its private key, encrypts it with the
center's public key, and sends it to the center. minimally, the
message will contain the permanent id and transaction description.
the center will respond by evaluating the message, performing the
query, constructing [2] a message with the time, transaction result,
and appending some random data, signing it with its private key,
encrypting it all with the account holder's public key, and sending
this back.
if [3] a confirming response consisting of a decryption and
reencryption/signing of the time, transaction description, transaction
result, and random data block is not received from the account holder
within a preset interval, or if an invalid confirmation is received,
the transaction is cancelled in its entirety, the center attempts to
notify the account holder that this has happened, and the connection
is closed.
otherwise the (signed, encrypted) confirming response is appended to a
log, the transaction is made permanent, the database is updated, and
[4] a final receipt is constructed, signed, encrypted, and sent back
to the account holder. the information in the receipt is also appended
to a log signed and encrypted using the center's private and public
keys.
if the account holder receives the receipt within the timeout
interval, the connection is closed. else a request for another try at
the receipt is sent. if there's a total net outage at this stage of
the session, both ends will eventually overrun the timeout and retry
criteria, and generation of a receipt will be necessarily delayed.
--> this demands that the account holder place trust in the center,
which is not ideal.
the final receipt once received relaxes the demand of mutual trust.
once the account holder has that receipt, he has irrefutable proof
that the transaction occured as the holder claims. on the other hand,
if the account holder does not get hold of the receipt, he hasn't a
leg to stand on.
in the case where an account holder claims a transaction occured, and
the center denies it, the account holder must produce the final
receipt or his claim is thrown out.
in the case where an account holder claims a transaction did not
occur, and the center says it did, the center must provide a log
containing the time and full transaction description signed by the
account holder, *plus* the random data block, all signed by the
account holder. clearly, then, there's a receipt for both ends, and
the center just stacks them all together in a log.
ok, now that that's out of the way, the overall themes are these:
-account holders are anonymous. the parties legally responsible for
the center are *not* anonymous.
-withdrawls are implicitly authenticated using the cryptographic
protocols outlines above
-deposits are fundamentally anonymous.
-account inquiries of any type must be authenticated just as
withdrawls are. it's a withdrawl of information instead of money;
the distinction is easily lost.
-the loss of account holder anonymity is *not* necessary in cases of
contested claims. instead, the account holder is identified by a
keypair, which reveals information only concerned with the account
itself. this is implicit in the registration process.
-"collection points" that are capable of turning electronic money into
physical money and vice-versa must be established. once again, an
account holder need not betray its anonymity to perform a
transaction. instead, private booths with ATMs perform the
transactions, the only difference being a lack of the usual
"spy-eye."
-the center must have a mechanism of charging account holders for its
services. both the account holder and the center have documents that
certify the terms of their agreement irrefutably. charges will be
levied on accounts in accord with these terms. this raises an
important issue: how can account holders be prevented from
performing transactions that leave them too little balance to cover
the service fee? the answer is to use continuous methods to charge
for service, rather than discrete. specifically, an account balance
is not a number, but in fact an expression with parameters which
can, at any instant, be converted into an equivalent "external"
quantity and a new set of parameters.
-the closing of an account is an atomic operation that reduces the
equivalent instantaneous balance of the account to zero (by
transfering it to another account or converting it to external form
(physical or otherwise)), and subsequently deactivates the account.
the identifier is retired indefinitely.
-if account balance dips below a certain instantaneous equivalent
value <= 0, the center reserves the right to automatically
deactivate the account. this is part of the terms, but important
enough to enumerate here.
contrary to appearances i didn't spend much time on this so i might
have missed some obvious points. i'm not really as technopedantic as
this thing makes me sound, by the way. :-)
(signed portion ends with this line inclusive)
-----BEGIN PGP MESSAGE-----
Version: 2.2
iQCVAgUALS48O3RebeI5/yZ3AQHFEgQA3gfc0jomq/w70W+idrJhl7u9gBJHwa9U
64sXBs5DksLLyaVWvmKlxbXltFJViotfcsfkFsthrEJBn60GUpBhfW5HmaAhDkpL
puah4TIIC81hqLgt1Liq8pPwP+IxT8DPXnqIQ09TnBxORnm0ELQUl2kCQDPVpYsp
/woPc2NM5OE=
=a/oD
-----END PGP MESSAGE-----
--
-daniel douzzer@athena.mit.edu
Key fingerprint = 0B 99 0D 4F E8 55 9A 95 43 C1 7F B5 DF 8F E3 33
finger douzzer@ai.mit.edu for public key
(finger douzzer@piranha.lcs.mit.edu for independent copy)