TOMIN: Trustworthy Mobile Cash with Expiration-date Attached

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. Outline • Introduction • Motivation • Scheme • Security Analysis • Performance Evaluation • Advantage vs. Weakness • Comment

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. 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. Scheme (1/2) Phase Customer Bank Merchant IDM PK: (e, n)PV: d Initial C:random r, seed define v = w∥δ hi = Hw(seed) m = hi||li||v. α= reH(m) mod n Withdraw Verifies v α,v (deduct w) β Unblind C: s = r-1β mod n = H(m)dmod n Deposit C: hi-x = Hi-x(m) F = H(x∥hi-x∥IDM∥δ1) G =H(m∥s∥F) m, s, x, hi-x, IDM, δ1, G w:The amount to withdraw. δ:Expiration date. IDM: Merchant’s identity. li: The length of the hash chain. δ1: Deposit date. x: The amount to pay and to deposit.

6. Scheme (2/2) Phase Bank Customer Merchant m, s, x, hi-x, IDM, δ1, G Deposit Verifies δ1 m, s, x, hi-x, IDM, δ1, G Verifiesδ1, v, δ (deposit w) Check hifresh se = H(m) mod n hi = Hx(hi-x) m’ = hi-x ||li-x ||v s’ = H(m’)d mod n m’, s’ Store m, s m’, s’

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. 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. Performance Evaluation(1/3) • Computation cost Table A Performance comparison between our scheme and related schemes. P1: Computational cost of the customer. P2: Computational cost of the merchant. P3: Computational cost of the bank. P4: Number of rounds in the scheme. Th: Execution times for hash functions. Texp: Execution times for exponential operations.

10. Performance Evaluation(2/3) • Storage Analysis Table A storage comparison between our scheme and related schemes. P1: Storage size of the m-cash. P2: Public keys. P3: M-cash. 40-bit length: IDM、li、r、seed、x、w 64-bit length: δandδ1 1024-bit length: Large prime in modular operation. 128-bit length: One-wayhash function.

11. Performance Evaluation(3/3) • Capability comparison Table A general comparision between our scheme and related schemes. P1: Withdrawal date. P2: Expiration date. P3: Deposit date. P4: Controls customer’s database. P5: Operations used to attach the date. P6: Multiple payments. P7: Need to withdraw for each payment. P8: Attaches the merchant’s identity to the m-cash. H(.) = One-way hash function. (e, n) = Exponential operation.

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 aremore efficient than previous works • Weakness • Customer must spend the m-cash before expiring

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