1. TOMIN: Trustworthy Mobile Cash with Expiration-date Attached Author: Rafael Martínez-Peláez and Francisco Rico-Novella. Source: Journal of Software, 2010, Vol. 5, No. 6, pp.579-584. Presenter: Tsuei-Hung Sun ( 孫翠鴻 ) Date: 2010/12/3

2. 2 Outline  Introduction  Motivation  Scheme  Security Analysis  Performance Evaluation  Advantage vs. Weakness  Comment

3. 3 Introduction  Mobile Cash (m-cash) ■An extension of electronic cash (e-cash) for mobile devices ■Mobile commerce Real point of sale Virtual point of sale Person-to-person transaction ■Providing privacy to customers ■Low computational cost

4. 4 Motivation  Bank needs to store all used m-cash to prevent double spending  Mobile device has limit computing ability and storage  The propose scheme ■Using expiration date to prevent bank’s database growing uncontrollably ■Using deposit date to calculating the interest on the m-cash ■Linking m-cash with Merchant’s ID to protect attack steal the e-cash to use

5. 5 α,v C: random r, seed define v = w ∥ δ h i = H w (seed) m = h i ||l i ||v. α = r e H(m) mod n β C: s = r -1 β mod n = H(m) d mod n Phase Initial Withdraw Unblind Bank Customer Merchant ID M (deduct w) Deposit m, s, x, h i-x, ID M, δ 1, G C: h i-x = H i-x (m) F = H(x ∥ h i-x ∥ ID M ∥ δ 1 ) G =H(m ∥ s ∥ F) PK: (e, n) PV: d Verifies v w: The amount to withdraw. δ: Expiration date. ID M : Merchant’s identity. l i : The length of the hash chain. δ 1 : Deposit date. x: The amount to pay and to deposit. Scheme (1/2)

6. 6 Phase BankCustomer Merchant Deposit (deposit w) m, s, x, h i-x, ID M, δ 1, G m’, s’ Verifiesδ 1, v, δ Check h i fresh s e = H(m) mod n h i = H x (h i-x ) s’ = H(m’) d mod n m’ = h i-x ||l i-x ||v Store m, s m’, s’ Verifies δ 1 m, s, x, h i-x, ID M, δ 1, G Scheme (2/2)

7. 7 Security Analysis (1/2)  Withdrawal step ■Bank cannot link signature to Customer ■Bank verifies the correct of pre-defined format  Unblind step ■Customer cannot forge another m-cash (m,s)

8. 8 Security Analysis (2/2)  Deposit step ■Customer cannot use m-cash after the expiration date ■Merchant cannot obtain private information about Customer ■Attacker cannot deposit the m-cash (m,s) into bank account ■Merchant cannot use the renew m-cash (m’,s’)

9. 9 Performance Evaluation(1/3)  Computation cost P 1 : Computational cost of the customer. P 2 : Computational cost of the merchant. P 3 : Computational cost of the bank. P 4 : Number of rounds in the scheme. Table A Performance comparison between our scheme and related schemes. T h : Execution times for hash functions. T exp : Execution times for exponential operations.

10. 10 Performance Evaluation(2/3)  Storage Analysis Table A storage comparison between our scheme and related schemes. P 1 : Storage size of the m-cash. P 2 : Public keys. P 3 : M-cash. 40-bit length: ID M 、 l i 、 r 、 seed 、 x 、 w 64-bit length: δandδ 1 1024-bit length: Large prime in modular operation. 128-bit length: One-way hash function.

11. 11 Performance Evaluation(3/3)  Capability comparison P 1 : Withdrawal date. P 2 : Expiration date. P 3 : Deposit date. P 4 : Controls customer’s database. P 5 : Operations used to attach the date. P 6 : Multiple payments. P 7 : Need to withdraw for each payment. P 8 : Attaches the merchant’s identity to the m-cash. H(.) = One-way hash function. (e, n) = Exponential operation. Table A general comparision between our scheme and related schemes.

12. 12 Advantage vs. Weakness  Advantage ■The expiration date prevent the bank’s database from growing uncontrollably ■Attaching merchant’s identity into m-cash that can prevents any eavesdropper to deposit the m-cash into his or her bank account ■The storage capacity and computational cost are more efficient than previous works  Weakness ■Customer must spend the m-cash before expiring

13. 13 Comment  Transaction records may be linked together after pay the first m-cash  This scheme can’t calculate interest correctly