IHP Im Technologiepark Frankfurt (Oder) Germany IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved MONETA: An Anonymity Providing Lightweight Payment System for Mobile Devices Krzysztof Piotrowski, Peter Langendörfer, Damian Kulikowski

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Outline Motivation System characteristics System overview Protocol Conclusions

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Lightweight Combined asymmetric security architecture makes our system lightweight and provides a high level of security. Identity revealing approach based on ECC to reduce effort. ECC priv. ECC pub. RSA pub. RSA priv. ECC priv. RSA pub. ECC pub. RSA priv. CLIENT INFRASTRUCTURE + ECC key pair RSA key pair

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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, b 1 and b 2 for each coin Calculates four EC points (A, B, C and D) A = (ANR s) * P, B = b 1 * P, C = s * P, D = b 2 * P These points form the hidden identity data The user stores numbers s, b 1 and b 2 along with the coin.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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 + b 1 g(x) = s x + b 2 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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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(x 1 ), g(x 1 ) - first response pair f(x 2 ), g(x 2 ) - second response pair f(x 1 ) - f(x 2 ) ANR = g(x 1 ) - g(x 2 ) If the responses are equal then this calculation does not work, but this means that the service tried to refund one coin twice.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved The protocol 1. Withdrawal 2. Payment 3. Service refund 4. Client refund

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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

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

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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Refund Similar to payment - client refund the bank sends a challenge - client responds - service refund the service sends all data collected during payment procedure

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved 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

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved The End THANK YOU FOR YOUR ATTENTION