MONETA: An Anonymity Providing Lightweight Payment System for Mobile Devices

1. MONETA: An Anonymity Providing Lightweight Payment System for Mobile Devices Krzysztof Piotrowski, Peter Langendörfer, Damian Kulikowski

2. Outline • Motivation • System characteristics • System overview • Protocol • Conclusions

3. Motivation Design an e-cash system with the following features: Anonymous Lightweight Secure for all parties Off-line Impossible to provide all these features together in a full range – compromise needed.

4. System characteristics • Only one type of indivisible coin one cent coin • Limited anonymity based on pseudonyms revocable in case of double spending • Coin created completely by the user and signed in blind Chaum blind signature • Eavesdropping proof / Money theft proof • Straight money path BANK  USER  SERVICE  BANK • Limited transferability USER_1  BANK  USER_2 • Off-line

5. Lightweight ECC priv. RSA pub. • Combined asymmetricsecurity architecture makes our system lightweight and provides a high level of security. • Identity revealing approach based on ECC to reduce effort. + ECC pub. RSA priv. ECC priv. RSA pub. ECC pub. RSA priv. RSA key pair ECC key pair CLIENTINFRASTRUCTURE

6. Parties of the system • MONETA Certificate Authority - the trusted party - acts as a judge in case of problems - registers clients (users) and service providers (services) • Bank - allowed to issue e-cash tokens • Client - generates the money flow (the most important party) - withdraws money from the bank and uses it to pay the service • Service Provider - supplies the client with services (goods) and get paid for it

7. User’s identities • ANR - Account number in the bank - identifies each bank user - assigned by the bank while creating the account - links directly to user’s real life identity • UID - User ID in the system - identifies each system user - obtained from MCA during registration - kind of pseudonym - can be changed from time to time To prevent money tracking it is important to keep these two identities impossible to link.

8. Hidden identity – creation To provide revocable anonymity we use the hidden identity approach: • The bank chooses an elliptic curve (EC) and a point P on this curve • The bank reveals this information to all interested parties • The user chooses three random numbers s, b1 and b2 for each coin • Calculates four EC points (A, B, C and D) A = (ANR • s) * P, B = b1 * P, C = s * P, D = b2 * P • These points form the hidden identity data • The user stores numbers s, b1 and b2 along with the coin.

9. Hidden identity – verification • During the payment the service challenges the user with a number x • The user responds with a pair of values calculated as follows: f(x) = ANR • s • x + b1 g(x) = s • x + b2 • The service verifies client’s response: f(x) * P = A * x + B g(x) * P = C * x + D • The service stores the response and uses it during the refund procedure

10. Hidden identity – double spending detection If bank received one coin more than once it can calculate the spender’s ANR using responses it got from services: f(x1), g(x1) - first response pair f(x2), g(x2) - second response pair f(x1) - f(x2) ANR = g(x1) - g(x2) If the responses are equal then this calculation does not work, but this means that the service tried to refund one coin twice.

11. The structure of the coin BankID A, B, C and D DATE HashUID SIGNATURE • BankID - identifies the bank that issued the coin • A, B, C and D - hidden identity data (four EC points) • DATE - the creation date of the coin • HashUID - hash value of UID, DATE and points A, B, C and D • SIGNATURE - the issuer’s signature

12. The protocol 1. Withdrawal 2. Payment 3. Service refund 4. Client refund

13. Mutual authentication • Performed before each part of the protocol • Based on exchange of certain information: Withdrawal Client - PIN Bank - Account’s SECRET Payment Client and service prove their ownership of the certificate Refund Client or service - PIN Bank - Account’s SECRET

14. Withdrawal BANK MESSAGE CLIENT FROM AUTHENTICATION AMOUNT_ SEND (AMOUNT) NEM_ERR DOES THE USER HAVE ENOUGH MONEY ON THE ACCOUNT ? N EXCEPTION HANDLING ? Y AMOUNT_ACK CREATE AMOUNT OF COINS, FOR EACH: - CHOOSE s, b1 and b2 , - CALCULATE POINTS, - HASH_ID = H(POINTS, UID, TIME), - CALCULATE Hc = H(COIN WITHOUT SIGNATURE), - BLIND Hc: Hc’ = BLIND(Hc). Hc_SEND SIGN ALL Hc’ VALUES: SIG’ = SIGN(Hc’); WITHDRAW MONEY FROM USER’S ACCOUNT (AMOUNT of Hc’) SIG_SEND UNBLIND THE SIGNATURES: SIG = UNBLIND(SIG’); CREATE COMPLETE COINS BY ADDING THE SIGNATURES; TEST THE SIGNATURES (COINS). (AMOUNT of SIG’) N SIG_ERR ARE THE SIGNATURES (COINS) OK? EXCEPTION HANDLING ? (INDEXES) Y WD_DONE TERMINATE CONNECTION

15. Payment SERVICE MESSAGE CLIENT FROM AUTHENTICATION CHALL_SEND CHOOSE CHALLENGE (CHALLENGE) COIN_SEND MOVE COIN FROM WALLET TO BUFFER_WALLET (COIN) N EXCEPTION HANDLING USER AND COIN VALID? UPDATE STATUS ? Y N COIN_INFO COIN ACCEPTED? ? (STATUS) Y CALCULATE RESPONSE: RESf = f(CHALLENGE), RESg = g(CHALLENGE) RES_SEND (RESf, RESg) N RESPONSE OK? UPDATE STATUS ? EXCEPTION HANDLING Y N RES_INFO PUT COIN INTO BUFFER_WALLET DECREASE PRICE RESPONSE ACCEPTED? ? (RECEIPT) Y DECREASE PRICE TRANSFER_DONE N Y ? (RECEIPT) PRICE == 0 ? PAY_DONE MOVE COINS FROM BUFFER_WALLET TO WALLET (GOODS) REMOVE COINS FROM BUFFER_WALLET PAY_DONE TERMINATE CONNECTION

16. Refund • Refund • Similar to payment • - client refund • the bank sends a challenge - client responds • - service refund • the service sends all data collected during payment procedure

17. Results and conclusions • Significant reduction of computational effort on the client side With the factor in range between 2 and 5+ • Pure software solution - no hardware observers needed • Suitable for any network electronic commerce purpose • Implemented in Java • Payment module for our location aware middleware PLASMA Potential improvements: • Diverse values • Divisibility • Coin size reduction • Enhanced certificate management

18. The End THANK YOU FOR YOUR ATTENTION