4 expanded posts ยท every known parent and child
By popular request, DigiCash is releasing the protocol specs. The specs are available at http://www.digicash.com/ecash/protocol.html Please be aware that the doccument is work in progess. More specifications, including byte level descriptions of the message format will be added throughout the weekend. --Lucky Green at -- Mark Twain Ecash Support <mailto:support@marktwain.com> <http://www.marktwain.com/ecash.html>
In article <199512030127.RAA03496@cory.EECS.Berkeley.EDU>, Ian Goldberg <iang@cory.EECS.Berkeley.EDU> wrote: >Since the payer_code is not supposed to be sent around, how is it sent to >the bank in order to cancel a payment? The document says "This allows him >to cancel the payment (deposit in his account)...", which seems to indicate >that a cancellation is just a deposit (made out to someone else), accompanied >by an appropriate payer_code. It is important that an eavesdropper not >be able to ever see the payer_code that corresponds to a payment, or >else she could present both to the bank and say "cancel this payment", >and get the money "back". After reading the responses to my questions/comments, it seems that, if Charlie (the customer) wants to cancel a payment, his ecash client sends a copy of the payment, including the payer_code field (which evidently was not in the original payment), to the mint. The mint accepts the payment because the payer_code was supplied. However, the payer_code is sent _in the clear_. Thus: How to steal ecash: This method can be used by Mitch, an active eavesdropper, though all he really needs to be able to do is selectively remove or delay packets in transit. Mitch taps either his target, or, better yet, the mint, and watches for deposits to the mint that have the payer_code filled in (a cancelled payment). He delays that packet, and sends the identical deposit to the mint himself (with his own userID in the userhdr, of course). The mint, being unable to know who withdrew the coin originally, has no reason to believe it wasn't Mitch, and so happily deposits the money "back" in Mitch's account. Mitch is then free to release the delay on the original packet, and Charlie's deposit fails (as the coin has already been deposited). So: do I win anything? :-) Disclaimer: Don't do this. Then again, is it illegal to copy ecash? I doubt it's considered counterfeiting. What about creating ecash out of thin air (say I had a magic factoring box (like a quantum computer (well, not yet)))? - Ian "IANAL, but IAA security-wise net.citizen..."
Lucky Green <mtwain@netcom.com> wrote, to our great pleasure:
> By popular request, DigiCash is releasing the protocol specs.
>
> The specs are available at
> http://www.digicash.com/ecash/protocol.html
>
> Please be aware that the doccument is work in progess. More
> specifications, including byte level descriptions of the message
> format will be added throughout the weekend.
I read these specs for a little while last night. Here are some of my
questions/comments. To prevent this message from becoming huge, I won't
quote much from the protocol document itself; the URL is above if you want it.
I'll ignore the spelling/grammar; they can be fixed later.
Also: would people prefer if this discussion were moved to the ecash
mailing list (ecash@digicash.com)? I _would_ prefer that this was discussed
in public, though, and not just with DigiCash.
First: Could you put some kind of protocol version number (so we know when
the protocol changes) and document version number (so we know when the
document changes, and can reference a particular version) somewhere near
the top of the document?
I realize that the document is incomplete. For example, it is missing
a description of the SETUP_REQ message and response. From what I can gather
from other wording in the document, this message is used to get the bank's
public key. I would hope this key is certified in some way. Alternatively,
I notice that the ecash client, in the routine ec_cash_setup, passes a value
called hard_n (a 768-bit composite) to check_sig. Does this mean that
the bank's public key (or at least the public key used to sign the message
containing that bank's real public key) is fixed, and hardcoded into the
client?
What is the function f, used in the payment_hdr to hash the payer_code
and desc fields, as well as in WITHDRAW3 to calculate N = f(n) * r**h?
There is reason to believe it is SHA, but I thought I saw some stuff in the
client that indicated that the output of f is 132 _bytes_ long (but I'm
not exceptionally sure of this, not having source and all).
What are the flags used in the Withdraw Request and the payment_hdr?
Please clarify what parts of the payment_hdr are shipped around. The document
says that the shop checks if the descr_hash matches the description.
Since the description is in the second part of the payment_hdr, does that
mean that both parts are sent to the shop? Noticing that the payer_code
(which the payer is supposed to keep secret) is in the second part, this
doesn't seem to be right. Also, the document states that the payment hash
is not sent from the payer to the shop or from the shop to the mint. However,
the payment hash is just the SHA of the first part of the payment_hdr,
which _is_ sent around, so although the payment hash isn't transmitted
per se, it can certainly be calculated.
What is the expries field in the payment_hdr? Note that it's an int rather
than a time.
A (very slight) privacy concern: the payer's bank is sent in the clear,
which gives a very small amount of information about the identity of the
payer. More on who knows what later.
Is it in fact the case that all coins on one payment use the same payment hash
when encrypting their signatures (the field sig in onl_coin)?
If (M,e) is the mint's public modulus/exponent, and (N,h) is public mod/exp
for a particular coin denomination, are the following statements true:
o If n is the coin number (in onl_coin, assumedly the same n as used in the
withdraw request), and hdr is the first part of the payment header,
then sig (in onl_coin) equals
([ SHA(hdr) XOR ((f(n)^(1/h)) mod N) ] ^ e) mod M
o A deposit (which contains a userID in the userhdr, a payment_hdr in
the dep record, and a pair (n,sig) for each coin) is accepted by the bank iff
([ SHA(payment_hdr) XOR ((sig^(1/e)) mod M) ] ^ h) mod N = f(n)
_and_ either payment_hdr.shop_accID corresponds to userID,
or a payer_code is supplied such that
payment_hdr.payer_hash = f(payer_code).
Since the payer_code is not supposed to be sent around, how is it sent to
the bank in order to cancel a payment? The document says "This allows him
to cancel the payment (deposit in his account)...", which seems to indicate
that a cancellation is just a deposit (made out to someone else), accompanied
by an appropriate payer_code. It is important that an eavesdropper not
be able to ever see the payer_code that corresponds to a payment, or
else she could present both to the bank and say "cancel this payment",
and get the money "back".
Where is the facility for tracing double spenders? Perhaps it's just
part of the "incomplete" part of the document, but I can't even see
where it would fit in to what we've got; neither the withdrawal nor the
payment messages seem to encode _any_ information about the payer in
the coins, and the bank cannot seem to know who withdrew the coin that
ended up being spent twice (due to the blinding).
Is there a way to change the public key associated with an account?
Is it just a meeter of sending another OPENACC1 message?
Exactly what kind of anonymity/privacy/security does ecash offer?
Let's examine who knows what.
Our cast of characters:
Charlie, the customer
Sam, the shopkeeper
the Bank (for simplicity, both Charlie and Sam use the same Bank for now)
Eve, a passive eavesdropper
Mitch, an active Man-In-The-CHannel
the Government (which may try to force others to reveal information)
Depending on which channels Eve and Mitch have access to, and whether or
not they can tell, by examining the channel, or by selection, the
identities of one or more of the communicating parties, they can get
varying amounts of information. I'll assume they have access to
all communications for now.
Not knowing the SETUP_REQ protocol is problematic. As mentioned above,
steps need to be taken to prevent Mitch from getting Charlie's password
and using it to usurp his account. We will assume that it turns out OK,
and that Charlie can successfully open an account with a private key known
only to him, and that he correctly knows the bank's public key.
[ As this is getting long, I've snipped a bit from here. I'll put it
back, with more detail, when the protocol document is more complete,
and my questions above have been answered. ]
In short, a couple of things:
Eve and Mitch know how much was paid to whom, and for what. If they
can tell (say, by TCP header) who was sending the payment or receiving
the payment request, they know who paid as well.
If Eve or Mitch can determine either r (the blinding factor) used in
the withdrawal, or the payer_code, used in the payment, they can steal the
money. This has ramifications to Doug's "agnostic" banks; more security
has to be added to the present ecash system if unblinded withdrawals are
allowed. This also brings up the "Netscape" question: how are these numbers
generated? Does it have to do with that 25 character string you enter
at the beginning? I've noticed a bit in the program that seeds a RNG with
(time(0) ^ ((getpid()<<16)|getuid())). I think publication of _at least_
the code pertaining to blinding factor and payer_code generation is
_absolutely vital_.
I think I'll stop here; comments from anyone, and especially answers to my
questions from DigiCash people, are welcome. I'm sorry if it's not as
complete as you (or I) would like; I'm quite tired, as my building had
two fire alarms in a row at 3am this morning...
- Ian "Well, it's a start..."thank you for the sterling analysis. I for one am following this with enormous interest, even though some of the details are lost on me right now. I can't recall if you were party to the earlier thread on "digital coin launderies", and I know some of it was off line. I hope you will keep some of the following in mind as you go. One of the major questions about digicash/MTB$ is whether and how money might be laundered. The question subsumes the following (among others): 1) What information about Charlie/customer is encoded onto the coin? (There must be some, right, since the serial number is blinded?) Since the bank doesn't know what serial number it is signing, it needs to put info about Charlie onto the coin so that it can track him down if he double spends. Lacking such info, the bank can refuse to honor a double-spent coin, but has no way to know who the double-spender is. 2) How does Charlie (customer) software store the coin internally? 3) Is there a way [how hard is it] for charlie to extract a coin and either (i) copy it and/or (ii) send it to David [3rd party] in such a way that David could insert it into David's MTB software and then spend it to Sam without Sam or the Bank noticing that anything was wrong. If Charlie and David do this, David now has a coin that is from his point of view both payee and payor anonymous, although Charlie has a risk that David will double-spend and expose Charlie to the bank's wrath. 4) what information if any is encoded onto a coin when Charlie spends it to Sam? A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin@law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here.