Tuesday, 18 September 2012

Basic concept of digital cash


Digital Cash


What is Digital Cash?
Digital cash aims to mimic the functionality of paper cash, by providing such properties of anonymity and transferability of payment. Digital cash is intended to be implemented data which can be copied, stored, or given as payment (for example, attached to an email message, or via a USB stick, bluetooth, etc).  Just like paper currency and coins, digital cash is intended to represent value because it is backed by a trusted third party (namely, the government and the banking industry).
Most money is already paid in electronic form; for example, by credit or debit card, and by direct transfer between accounts, or by on-line services such as PayPal. This kind of electronic money is not digital cash, because it doesn't have the properties of cash (namely, anonymous and off-line transferability between holders).

How does Digital Cash work?


The figure shows the basic operation. User A obtains digital cash "coins" from her bank (and the bank deducts a corresponding amount from her account).  The user is now entitled to use the coins by giving them to another user B, which might be a merchant. B receives e-cash during a transaction and see that it has been authorized by a bank. They can then pay the cash into their account at the bank.
Ideal properties of a Digital Cash system
Ideal properties:
  1. Secure. Alice should be able to pass digital cash to Bob without either of them, or others, able to alter or reproduce the electronic token.
  2. Anonymous. Alice should be able to pay Bob without revealing her identity, and without Bob revealing his identity. Moreover, the Bank should not know who Alice paid or who Bob was paid by. Even stronger, they should have the option to remain anonymous concerning the mere existence of a payment on their behalf.
  3. Portable. The security and use of the digital cash is not dependent on any physical location. The cash should be able to be stored on disk or USB memory stick, sent by email, SMS, internet chat, or uploaded on web forms. Digital cash should not be restricted to a single, proprietary computer network.
  4. Two-way. Peer-to-peer payments are possible without either party required to attain registered merchant status (in contrast with today's card-based systems). Alice, Bob, Carol, and David share an elaborate dinner together at a trendy restaurant and Alice pays the bill in full. Bob, Carol, and David each should then be able to transfer one-fourth of the total amount in digital cash to Alice.
  5. Off-line capable. The protocol between the two exchanging parties is executed off-line, meaning that neither is required to be host-connected in order to proceed. Availability must be unrestricted. Alice can freely pass value to Bob at any time of day without requiring third-party authentication.
  6. Wide acceptability. The digital cash is well-known and accepted in a large commercial zone. With several digital cash providers displaying wide acceptability, Alice should be able to use her preferred unit in more than just a restricted local setting.
  7. User-friendly. The digital cash should be simple to use from both the spending perspective and the receiving perspective. Simplicity leads to mass use and mass use leads to wide acceptability. Alice and Bob should not require a degree in cryptography as the protocol machinations should be transparent to the immediate user.












These are ideal properties, and no known system satisfies them all.

Categorization of payment systems
Implementations of payment systems that don't satisfy all the requirements may be conveniently classified according to these criteria:
  1. Anonymous or identified. Anonymous e-cash works just like real paper cash. Once anonymous e-cash is withdrawn from an account, it can be spent or given away without leaving a transaction trail. This however, can be considered contentious. Identified payment systems such as credit card payment, or payment by Paypal leave an audit trail, and the identity of the payee and the payer is known to the Bank, and (usually) to each other.
  2. Online or offline. Online means you need to interact with a bank (via a network) to conduct a transaction with a third party. Offline means you can conduct a transaction without having to directly involve a bank.
  3. Requiring a trusted platform. Some protocols may require a trusted platform, such as a smart card. Smart cards are small plastic cards like credit cards, bearing a chip. They are tamper-resistant and can force Alice and Bob to adhere to the protocol. This is convenient for the protocol designer, but threatens to tie users to proprietary interfaces and to remove transparency of the system. In contrast, internet protocols endorsed by the IETF are open and can be interoperably implemented by anyone.





Two big problems
How can we guarantee anonymity? If the bank can see which coins it gives to A, and later it sees the same coins coming back from B. it can infer that A has paid them to B (possibly via an intermediary).
How can we avoid double spending? Because electronic files can be duplicated, a big challenge for digital cash is how to stop users spending money twice. On-line solutions achieve this by making the payee check with the bank before acknowledging payment. Off-line solutions have to use more elaborate methods.

Cryptographic primitives
Some technical concepts are needed to understand digital cash protocols.
  • Blind signatures. Suppose Charlie wants Dianne to sign a message m, but does not want Dianne to know the contents of the message. This might seem like a strange thing -- why would Diane sign something without knowing what it is? But the concept has useful applications in situations involving anonymity, such as digital cash. The arrangement works like this:
    • Charlie "blinds" the message m, with some random number b (the blinding factor). This results in blind(m,b).
    • Dianne signs this message, resulting in sign(blind(m,b),d), where d is Dianne's private key.
    • Charlie then unblinds the message using b, resulting in unblind(sign(blind(m,b),d),b). The functions are designed so that this reduces to sign(m,d), i.e. Dianne's signature on m.



Details of how blind signatures can be implemented using RSA are given in another lecture.

  • Secret splitting. Suppose I have a secret message string m, and I want to give part of it to Alice and part of it to Bob, in such a way that neither of them individually can tell anything about the secret, but if they get together then they can reconstruct it.
    • One way might be to split the secret string into two parts, m1 and m2, such that m = m1.m2, i.e. concatening m1 and m2 yields m. This is not very satisfactory because Alice and Bob each learns the first half or the second half of the message.
    • A better way is to invent a random number r, and XOR m with r. Give r to Alice, and m XOR r to Bob. Now neither of them knows anything about the secret, because each of them has what looks like a completely random string. However, if they get together, they can obtain m by calculating r XOR (m XOR r) -- that is indeed m.
    • This can be generalised to any number of participants.









    Online Digital Cash










    Let's look at how each component works.
    Withdrawing coins

    The following protocol is used in order to create a single coin of a given denomination, say m.
    1. The customer creates k units of money m. Each unit contains some header information, the denomination, and a unique serial number. The serial number is randomly generated and would be long enough so that collision does not take place (e.g. 64-bit serial number has a probability of collision of 1/264). So the money would have the format:
    m1 = (header info, denomination, serial number), …, mk = (header info, denomination, serial number).
    1. The customer blinds each of them with different binding factors bi, and sends them to the bank for signing.
    2. The bank randomly chooses k-1 of them to check, and leaves one unit i.
    3. The customer gives the bank all the blinding factors except the one for unit i
    4. The bank can now check the content to make sure the customer has not tried to cheat (e.g. by putting an amount larger than the agreed amount m). There is still a chance that the bank would not check the unit that is fraudulent but the probability of this happening deceases as we increase the size of k
    5. If all checks out, the bank signs the remaining unit with its private key d and sends it back to the customer.
    6. The customer un-blinds it by using bi to obtain the coin m signed by the bank.










    Thus, a coin consists of a signed message from the bank, asserting the value of the coin. Importantly, the bank does not know the serial number of the coins. That is how we obtain anonumity.

    Spending and depositing coins
    These procedures are straight forward. To spend the coins, just give them to the payee. To redeem them, just give them to the bank. The bank will check their validity and credit your account.
    To tackle the double spending problem, the payee has to verify the coin with the bank at the point of sale in each of the transactions. This verification of the legitimacy of the coin requires extra bandwidth and is a potential bottleneck of the system especially when the traffic is high. The real time verification also means there is a need for the synchronization between bank servers.

    Pros and Cons of the online digital cash system
    Here is the summary of the pros and cons of the online system:
    Pros
    • Provides fully anonymous and untraceable digital cash:
    • No double spending problems (coins are checked in real time during the transaction).
    • No additional secure hardware required
    Cons
    • Communications overhead between merchant and the bank.
    • Huge database of coin records -- the bank server needs to maintain an ever-growing database for all the used coins’ serial numbers.
    • Difficult to scale, need synchronization between bank servers.
    • Coins are not reusable


    Offline Digital Cash








    In the off-line scheme, the withdrawal and disposal of the coins are very similar to the one in the on-line scheme; the main difference is in how coins are spent, in order to prevent double-spending without the need to verify with the bank. This is achieved by adding an additional component in the model: it is a trusted party, which performs a digital transformation of the coin when it is transferred between users. This trusted party may be implemented as a tamper–resistant device. In a real life example, you could think of it as a smart card reader at the point of sale, although note that it is not required to be on-line. The device is trusted by the bank and by users, and is used to verify the authenticity of the coin and to address the double-spending problem. It does not prevent users from double-spending, but it provides a means to trace them if they do double-spend. This has to be carefully designed, in order to keep anonymity. Secret splitting is used to allow the user to be anonymous as long as he/she doesn’t double spend. Details are given below.
    In this system, coins are reusable. The merchant can spend the coin elsewhere with other parties through another tamper-resistant device before the coin is finally deposited back to the bank for verification.
    In additional to the secret splitting method, in order to add extra security to the offline system, there could be a link between the bank and the temper-resistant device which allows the T.R.D. to download a blacklist of double spenders in a set period of time when the traffic is low. This reduces the chance of people double spending their money in the first place.
    How off-line protocol works
    A coin will contain the following:
    • Serial number – a unique number that identifies the coin
    • Denomination – the actual value of the coin
    • Validity Period
    • Transaction list – has an arbitrary number of transaction items.






    Withdrawing and depositing the coins is the same as in the on-line method, but spending the coins is different. Print Page

    No comments:

    Post a Comment