moneta: an anonymity providing lightweight payment system for mobile devices

IHPIm Technologiepark 2515236 Frankfurt (Oder)

Germany

IHP Im Technologiepark 25 15236 Frankfurt (Oder) Germany www.ihp-microelectronics.com © 2004 - All rights reserved

MONETA: An Anonymity Providing Lightweight Payment System for Mobile Devices

Krzysztof Piotrowski, Peter Langendörfer, Damian Kulikowski


Outline

• Motivation

• System characteristics

• System overview

• Protocol

• Conclusions


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.


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


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


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


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.


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.


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


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.


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


The protocol

1. Withdrawal

2. Payment

3. Service refund

4. Client refund


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


Withdrawal

BANK MESSAGE CLIENT

AMOUNT_ACK

Hc_SEND

NEM_ERR? EXCEPTION HANDLING

EXCEPTION HANDLING

DOES THE USER HAVE ENOUGH MONEY ON THE ACCOUNT ?

Y

N

?Y

NARE THE SIGNATURES (COINS) OK?

AMOUNT_ SEND

(AMOUNT)

(AMOUNT of Hc’)

SIG_SEND

FROM AUTHENTICATION

TERMINATE CONNECTIONWD_DONE

SIG_ERR

(AMOUNT of SIG’)

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).

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)


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

NUSER AND COIN VALID? UPDATE STATUS

(STATUS)

?

Y

NRESPONSE 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

PAY_DONE

TRANSFER_DONE

REMOVE COINS FROM BUFFER_WALLET

MOVE COINS FROM BUFFER_WALLET TO WALLET

TERMINATE CONNECTION

(GOODS)

(RECEIPT)


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


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


The End

THANK YOU FOR YOUR ATTENTION

moneta: an anonymity providing lightweight payment system for mobile devices

Documents