DigitalCash RK
DigitalCash RK
Key Properties
Secure
Anonymous Portable Reusable User-friendly
However, Credit cards are not digital cash, because they fail to meet some essential requirements for digital cash. Three parities in digital cash: a customer, a merchant, and the bank. Desired Security Requirements for Digital Cash: - Security: The digital cash cannot be forged and/or reused by a user illegally. - Privacy (Untraceability) : Nobody, including the bank, cannot reveal the relationship btw the identities of customers and the digital cash. It includes both unlinkability and anonymity. - Transferability: Digital cash can be transferred btw customers without the help from the bank.
Off-Line Payment: To verify the validity of e-cash, a user does not need to enquire the bank. - Divisibility: A user can subdivide a piece of e-cash into smaller pieces of e-cash in small denominations.
- Independence: The use of e-cash does not rely on any physical locations and/ or special devices.
Bank
Withdraw Coins
Deposit Coins
Payment
User
Merchant
Cons
Communications overhead between merchant and the bank. Huge database of coin records.
Others
T.R.D . Temperresistant device
User
Merchan t
The basic idea: Using secret splitting technique to escrow users identity.
Disadvantages
Might not prevent double spending immediately More expensive to implement
Bank
m
(m)d
spend
(m)d
send
(m)d
d is secret key of the Bank
(m)d
verify
Blind Signatures
r = (m)be rd = (mbe)d
message
Bank could keep a record of r Remove blinding factor (mbe)d = (m)dbed b-1 md
m1
, ,
mk
m1b1e
, ,
mkbke
Untraceable remaining one and sends it back Digital Cash Bank signs the
(mibei)d = midbi
Customer
bi-1 mid
Problem!
When the merchant receives the coin, it still has to be
verified The merchant has to have a connection with the bank at the time of sale This protocol is anonymous but not portable
Secret Splitting
A method that splits the user ID in to n parts
Each part on its own is useless but when combined will
reveal the user ID Each user ID is XOR with a one time Pad, R
Cont
E.g. User ID = 2510, R = 1500:
2510 XOR 1500 = 3090 The user ID can now be split into 2 parts, I.e. 1500 and
3090 On their own they are useless but when XOR will reveal the user ID I.e 1500 XOR 3090 = 2510
A Typical Coin
Header Information Serial number Transaction Item pairs of user IDs
User ID:
A Typical Coin
1500 XOR 3090 = 2510 4545 XOR 6159 = 2510 5878 XOR 7992 = 2510
User ID
Blanking
Randomly blank one side of each identity pair
User ID:
0 4545 5878
Blanking
Randomly blank one side of each identity pair
User ID:
0 4545 5878
3090 0 7992
User ID:
0 4545 5878
3090 0 0
User ID:
1500 4545 0
0 0 7992
0 4545 5878
3090 0 0
1500 4545 0
0 0 7992
0 4545 5878
3090 0 0
1500 4545 0
0 0 7992
User ID
Reusability
Once the coin has been spent the merchant has to
deposit it to the bank Therefore, coin can only be spent once Convenience, ability to give change, unnecessary transactions between bank and merchant Banks database size less serial numbers Solution Add the new User ID to the coin
Setup
ID=HIREN
ID=AMIT
ID=KEVIN
Coins
Users Coin User ID:
A AM AMI
MIT IT T
max Transactions
Other proposals something that costs 4.99 What if you what buy
and you have 5 coin? Would have a file for every coin
4 2 1 1 1 2 1 2 2
Sender
Message-signature pair
Signer
View of protocol
Judge
Conclusion
Feasible from a purely technological perspective
Anonymous is at the heart of the government's attack Cannot attract funding
Advantages:
Convenience
Secure Handling costs Time saving Transaction Costs
Global Disadvantages
Safety Issue
Physical Securities Users Issue
Legal problems