## n‐Count Technology

Within an n‐Count based payment system, the payment device (which can be a card, secure element in an NFC handset or SIM), hereafter referred to as “card,” is organized in batches, where each batch has an identifier k. In any one batch, cards have the same secret key, denoted by C_{k}. In a payment transaction the card gives its batch identity to the terminal and the terminal selects a pre‐computed transaction “nCounter” suitable for that particular payment.

### n‐Counters

In order to make the reception of electronic value by the terminal possible, the terminal must be loaded with n‐Counters that are pre‐computed by the eMoney issuer as specified by the merchant. Each n‐Counter has a number of parameters, i.e. its unit value (u), its size (N), the identifier of the cards that can use it (card batch identifier k) and the identifier of the merchant terminal that it belongs to (T_{ID}). Furthermore each particular Counter has a unique identifier called Chain ID (C_{ID}). The merchant determines how many and what kind of n‐Counters (e.g. unit value of €1 or size of 50) it needs and the eMoney issuer performs the precomputation and sends the requested n‐Counters. The eMoney Issuer stores the parameters of all the n‐Counters created. The terminal stores the parameters of the n‐Counters that it possesses. The card does not store n‐Counter parameters; it only stores the card batch identifier (k) and the secret key (C_{k}).

At the core of an n‐Counter is a chain of cryptographic numbers: x = {x_{0} , x_{1} , x_{2} , …, x_{N} }, where N is the length of the chain. The n‐Counter has a current value, the cryptographic number x_{n}. Initially the n‐Counter value is x_{N} that represents zero funds. When the n‐Counter current value is x_{0} the n‐Counter is said to be full with maximum funds and can no longer be used and a new one needs to be downloaded from the eMoney issuer.

The start of the chain i.e. x_{0} is calculated by performing a keyed one‐way function G on the n‐Counter parameters using the secret card key C_{k}. A second cryptographic one‐way function F, known by all parties, is used to calculate the rest of the chain. The computation of the keyed one‐way function G can only be done by the eMoney issuer or by the card.

### Payment protocol

The payment is performed between a card and a terminal with the pre‐computed input of the eMoney issuer who is also responsible for the issuance of the card and its stored value. The value transfer between the card and the terminal is as follows:

### Cryptography

The eMoney issuer and the card possess the secret card key so only they can compute x_{0}. Furthermore x_{1}=F(x_{0}), x_{2}=F(x_{1}) and generally x_{n}=F(x_{n-1}), where F is a suitable cryptographic one‐way function and 0≤n≤N. So the numbers in the chain are obtained by iterating F.

Suppose given x_{n} we would like to calculate its predecessor x_{n-1}. Since F is a one‐way function, it is computationally infeasible to find x_{n-1} from x_{n}. The only efficient way is to start from x_{0} and by iterating F on x_{0} obtain x_{n-1}. Only the card and the eMoney issuer can do this computation.

Assume the terminal possesses a number x_{n} in the chain and asks a payment of m units from the card. For this the card needs to provide the terminal with the m‐th predecessor (i.e. x_{n-m}) of the given number x_{n}. The terminal cannot calculate this number, because it does not know x_{0} and cannot calculate pre‐images of the one‐way function F. However, the card is able to compute a predecessor, since it can calculate x_{0}. On the other hand when the terminal receives x_{n-m} it can check whether it is really the m‐th predecessor of x_{n} by iterating the function F m times on it.