DigiCash releases protocol specs!
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.
participants (4)
-
iagoldbe@csclub.uwaterloo.ca -
Ian Goldberg -
Mark Twain Ecash Support -
Michael Froomkin