PREPAID MEMORY CARDS
With regard to electronic payment systems, we must not neglect memory cards. They are produced in very large numbers in the form of prepaid electronic purses, and they are used in many applications. This situation will certainly not change over the next few years. Although memory cards will slowly but surely be replaced by microcontroller smart cards, their strength lies in their unparalled lowprice. The most common application for prepaid electronic payment cards is prepaid telephone cards, which are widely used in many countries and simply discarded once they have been used up. A memory card4 only has to contain some control logic and an irreversible down counter to allow it to do its job. More recent versions also support unilateral authentication of the card by the terminal. For this purpose, the logic unit has been enhanced by adding a simple encryption function, whose task is to encrypt a random number received from the terminal using a secret key stored in the card and return the result to the terminal. This is the only way the terminal can be sure that the memory card being used is genuine. Beside the fact that it is difficult to ensure the authenticity of memory cards, they have another drawback that limits their use as a general-purpose medium for electronic payments. Since such cards can easily be manipulated, it is difficult to construct a payment system that can support a variety of independent service providers (such as kiosks and taxis). This is because secure communications between the terminal and the card are not possible, so proper accounting of the amounts paid, and thus overall system monitoring, are in principle only possible using indirect methods. Due to their low cost, memory cards enjoy advantages with respect to microcontroller cards in certain very restricted application areas, but they are not particularly suitable for open applications in payment systems. Future electronic payment systems will doubtless use predominantly microcontroller smart cards, since they are significantly more versatile.

ELECTRONIC PURSES
The idea of implementing an electronic purse in a smart card goes back to the early days of smart card technology. However, only since the mid-1990s has this concept been realized, since that was when the development of large systems first began. If we take a normal purse containing coins and banknotes as a reference, we can easily see which properties electronic money has in the eye of the user. Money must be put into a purse before it can be used, which means it cannot be used like a debit or credit card, where payment is only made on or after receipt of the goods or services. Instead, it is used like a telephone card, which must be paid in advance. The actual payment process must be quick and simple, since otherwise the level of user acceptance will be low. Furthermore, all payments from a purse are anonymous, which means that it is not possible to reconstruct who bought what at which time. The most annoying characteristic of a purse becomes apparent if it is lost, since the money in it is then irretrievably gone. However, this does not necessarily have to be true of an electronic purse. The primary advantage of a purse, or rather of the money it contains, is that it is accepted everywhere within a given country. It is precisely this factor that is missing in most existing electronic purse systems. With a telephone card, all you can do is make telephone calls, and nothing else. This is typical of a closed application. An ideal electronic purse, on the other hand, can be used in more than one sector, and thus allow its user to make payments in many different businesses using a single purse.

The CEN EN 1546 standard
The European Commission decided in 1990 to have the Comit′e Europ′een de Normalisation (CEN) produce a European standard for a multisector electronic purse system. Work on the standard started in 1991. Up to 1998, the various project teams had spent around eight manyears on developing this standard. Since a number of independent experts have participated in this effort, it very unlikely that there are any security gaps in this standard. It is thus already quasi-evaluated. The essential parts are presently no longer subject to change, and they will be published as a European standard after the final vote takes place. The EN 1546 standard is a public standard, and the processes of its individual functions are described in great detail. It is therefore very suitable for demonstrating payment and loading processes in an electronic purse system. With many existing systems, these processes cannot be described in the same level of detail, since the relevant commands, processes and internal functions are confidential. This standard is thus very useful for illustrating the fundamental external and internal processes of an electronic purse system. The typical application areas are clearly indicated by the first systems based on this standard. The Danish system operator Danmt has introduced a purse compliant with this standard into its existing system. In Austria, the Eurocheque card issued throughout the country includes an electronic purse (called Quick) based on the EN 1546 standard, in addition to other applications. However, the largest international application of this standard is the Visa Cash system. This is one of several electronic purses offered by Visa. The essential features of the international specification for electronic purse systems, which is titled ‘Common Electronic Purse Specifications’ (CEPS), are also based on EN 1546. The EN 1546 standard is titled ‘Inter-Sector Electronic Purse’ and is divided into four parts. The first part, ‘Definition, concepts and structures’, describes the overall system. This basic document defines and explains, in abstract form, all of the logical components and their interconnections. In the second part, these basic concepts are used to describe the security architecture of the overall system and its individual components. This includes not only mechanisms for maintaining security, but also possible attacks and the corresponding necessary countermeasures. Part three, ‘Data elements and interchanges’, contains descriptions and definitions of the data elements needed for the electronic purse system. It also describes the commands related to the smart cards and security modules and their associated responses. The final part describes the state machines and states for the devices used. It employs a symbolic representation similar to well-known flowchart diagrams. This formal notation, which is known as SDL notation, is derived from the CCITT Z.100 recommendation. This standard, which encompasses around 300 pages, thus contains a complete description of an electronic purse system, including the smart cards, the terminals with their security modules and the background and clearing systems. Its objective is to establish a common standard for large electronic purse systems with very many smart cards and wide geographical distribution. The advantage of a general standard for electronic purse systems is primarily that it allows individual, independently operated systems to be mutually compatible. As with GSM, this gives the user the option of being able to use his or her card in the future to make payments using the systems belonging to other purse providers. This is an essential prerequisite for the success of this sort of payment system. However, a small comment is in order at this point. The EN 1546 standard provides a large amount of freedom with regard to actual implementation, and it regards itself as more of a framework than a precise specification of individual bits and bytes. It is thus perfectly possible for two different systems to be fully compliant with this standard but mutually incompatible, for example because they use different cryptographic algorithms. The basic elements of the system architecture are shown in Figure 12.7. The purse provider bears the overall responsibility for the system and is also the system manager. He is comparable to a GSM network operator. The term ‘purse holder’ is defined in the standard to refer to the user of the electronic purse. This is the person who makes payments using the electronic purse application in the card and receives goods or services in return. There are also three other parties that perform functions in the system. The ‘service provider’ offers goods or services that are accepted by the user and paid using an electronic purse. The ‘acquirer’ is responsible for establishing and managing the data links between the purse issuer and the service providers. He may also consolidate the individual transactions arriving from the payment facilities, so that the purse provider only receives collective certificates. The ‘load agent’ is the counterpart of the service provider, since he can reload the electronic purse in exchange for a payment. These five parties need not all be real persons or firms; they may also be virtual. However, real technical components are allocated to each of them, classified according to their level of security. Components that are regarded as secure prevent any external manipulation of the data that are processed or stored within them. With components regarded as non-secure, such manipulation is at least theoretically possible. However, the system as a whole is designed such that the manipulation of any of the components identified as non-secure in Figure 12.8 will not affect the overall security of the system. Here the abbreviation ‘IEP’ stands for ‘inter-sector electronic purse’ and refers to an intersector electronic purse application in a smart card. A purchase device is used to pay for received goods or services. It is a terminal with keypad and display, and it must also have a security module. The term ‘secure application module’ (SAM) is used in the standard to refer to all types of security modules. A SAM contains all secret keys necessary for transactions between the IEP and the central computer of the purse provider. Naturally, the keys never leave the security module, but are used only inside the SAM by the cryptographic algorithms. In many cases, therefore, the links between the system’s secure components are all direct. The non-secure components are only used to transparently relay sensitive data. Smart cards have made it possible to convert the idea of an electronic purse system into reality. They thus form the central subject of the system description in the CEN EN 1546 standard. All of the associated files, commands, states and processes are defined and described in this standard. In order to define the entire system, there are similar parts that address the security module and the other components. However, since this is a standard rather than a specification, the purse provider is naturally given a great degree of freedom and many options. A variety of functions can be used to construct the purse. For example, a simple system that only allows loading and paying with the purse can be easily implemented. This can be further enhanced with functions for canceling payments, modifying purse parameters and converting currencies. The exact selection of the many complex options is largely left to the purse provider, who must choose the options that best meet his particular needs. The most important aspects of an intersector electronic purse system with regard to the IEP, which is the smart card, are described below.

EN 1546 data elements
Designations for all data elements were introduced to allowthe data used in the entire system for the electronic purse application to be referred to unambiguously. Data flows and data processing can be represented, simply and unambiguously, in a mathematically correct notation using these very short designations. The standard also contains a simple data dictionary, which describes the corresponding data contents and associated formats for the standardized data elements.

Files
The complete electronic purse application is contained in a dedicated DF in the smart card. All of the files necessary for proper operation are contained in this DF. In addition, information relating to the card, the chip, other applications and the like is stored in several files directly under the MF. The data elements needed for operating the electronic purse are contained in six EF files located in a DF for the purse. These files are listed and briefly described in Table 12.3. The EFIEP file specifies the general parameters of the purse, which form the basis for all transactions that take place. The EFIK file contains specific information for every available key. EFBAL contains the amount that is currently in the purse and available to the user. The log files are used exclusively to record all transactions, separated by function. Only with these files is it possible to cancel a payment or handle errors. There are separate log files for loading, paying, modifying the purse parameters and making currency conversions. All log files have a cyclic structure, in order to record the most recent transactions.

Commands
The files form the foundation of the purse, and the commands are built on this foundation. Eight of these commands are needed for operating the purse system. Three commands belong to the ISO/IEC 7816-4 standard: SELECT FILE, READ BINARY and READ RECORD. These commands are only used to select the electronic purse application using its AID and subsequently read various data from the purse files as necessary. The other five commands were developed specifically for use with electronic purses. They are always used in pairs for individual transactions, since in principle they act as a sort of mutual authentication. During authentication, data needed for the transaction are also exchanged. The corresponding commands and responses are naturally structured such that any manipulations at the interface between the card and terminal can be immediately detected, resulting in immediate termination of the transaction and logging of the event. All purse commands directly access data elements in the purse files for both reading and writing. The files are automatically selected by the operating system prior to these accesses. For instance, basic purse data are occasionally needed while a command is being processed. In this case, the operating system selects the EFIEP file, and the desired data element is provided to the command. All transactions, as well as the most important data, are recorded in suitable log files during the command–response cycle. The standard does not provide commands for verifying or changing PINs, since these functions are not needed for the proper operation of the purse. However, additional commands for PIN verification and management can be included in the purse application as necessary, without causing any interference or problems with the existing purse commands.

States
As may already be apparent from the command summary, each transaction consists of an introductory initialization command and a subsequent command that completes the transaction.
In order to fix the sequence of commands, state diagrams are used to define the necessary states and state transitions in the application. This naturally requires the card to contain a state machine. Depending on its current state, the card will accept or reject various commands.

Cryptographic algorithms
The entire security of the system is based on a cryptographic algorithm. The messages exchanged between the components all have appended signatures to allow manipulations to be
detected. This is the only protection for messages, which are always exchanged in plaintext. The message exchange is structured such that any desired type of cryptographic algorithm can be used to generate the signature. The symmetric DES algorithm is currently most commonly used, but the standard also allows asymmetric algorithms such as RSA or DSS. This algorithm independence is a great advantage, since it considerably extends the useful life and flexibility of the standard.9 Procedures The standard does not just specify files, commands and states, but also describes and explains the associated procedures. These are specified in detail in terms of their data elements, using a pseudolanguage similar to Basic. This is necessary because the security of some processes strongly depends on the sequence of the operations used for processing commands inside the card. During a transaction, for example, the appropriate log file must always be updated before the response is sent to the terminal.The processes and transactions for all components are also precisely specified. Descriptions are provided for the following electronic purse processes for smart cards:
–loading
–paying
–canceling a payment
–correcting an error
–converting currencies
–changing the purse parameters.
The commands for reading files can of course also be used for monitoring purposes. However, the actions involved may vary, depending on the purse provider and the objective of the monitoring. The structure of all specified procedures is determined by a fundamental principle, which is that it must never be possible to create electronic money by manipulating data transmissions between the components or by abruptly terminating a transaction. The worst consequence of such actions is limited to the destruction of electronic money. This automatically excludes certain types of attack. Incidentally, this principle is incorporated in the designs of nearly all electronic purse systems. Each process is basically divided into three phases. Complete initialization of the participating components occurs in the first phase. Actual execution of the transaction takes place in the second phase. The third phase, which is optional, is used to confirm the previous actions. Successful completion of the first two phases amounts to unilateral (or optionally, mutual) authentication of the two components. In all of the procedures, unilateral or mutual authenticatin is interleaved with the actual purse functions (payment, loading, etc.). This minimizes the time required for the purse transactions and increases security, since it significantly reduces the number of commands needed to perform the functions. This is similar to the situation with the standard ISO commands INTERNAL AUTHENTICATE and EXTERNAL AUTHENTICATE, which can be replaced by the non-standard command MUTUAL AUTHENTICATE without affecting functionality or security.

Procedure for loading a purse
Before an electronic purse can be used to make payments, it must first be loaded. The procedure for this is shown in Figure 12.11, which illustrates the option in which the electronic purse is loaded online using a terminal that is directly connected to a background system with its associated security module (PPSAM). Other options are also possible according to the standard, such as loading the purse using a security module in a terminal (LSAM). However, the procedure described here is commonly used in current systems, since it gives the system operator complete control over loading. In the example shown in Figure 12.11, an electronic purse (IEP) is loaded by the background system via a terminal (LDA) using a security module (PPSAM). The card user first inserts his card into the terminal, which executes a reset. In the ATR, the card sends the terminal various general parameters for the subsequent communication process. After this, the terminal selects the electronic purse DF in the card. Once this has been done successfully, the card user inserts the amount of money to be loaded into the terminal using an acceptable currency. This information is then sent to the PPSAM via the first purse command. The PPSAM verifies the indicated currency and the amount still allowed to be loaded. In response, it returns three data elements to the terminal. The terminal appends the load amount (MLDA) and the associated currency (CURRLDA) to the data elements received from the PPSAM and sends all of this information to the IEP using the ‘INITIALIZE IEP for Load’ command. The IEP then checks, among other things, whether the purse balance after the load amount is added would exceed the maximum allowable amount in the purse (BALmaxIEP). If it would not, the IEP increments a transaction counter (NTIEP), computes the session key (KSESIEP) and generates a signature (S1). These are returned to the terminal, along with several other data elements. Following this command, the terminal simply relays the received data elements to the PPSAM. Here they are checked against the permitted range of values, and a card-specific key (KDPPSAM) and a session key (KSESPPSAM) are generated. If the subsequent verification of signature S1 is successful, the card has been authenticated, since it must know the secret key for computing S1. The PPSAM then generates signature S2 and sends it to the terminal, along with the key information (IKPPSAM). The terminal again only relays these data elements to the card, this time using the command LOAD IEP. The IEP now verifies signature S2. If this is successful, the PPSAM has also been authenticated by the IEP. The balance in the purse (BALIEP) is then increased. The IEP next generates a third signature (S3), which is sent to the terminal for confirmation that the balance has been successfully increased. The final command transfers this signature to the PSAM, which completes the entire loading transaction. The procedure just described is one of many possible options. It is frequently used in practice, since it is very common to perform purse-loading transactions online. EN 1546 also includes options for loading via a special loading security module (LSAM). Such decentralized modules can be built into special loading terminals, such as cash dispensers.

Procedure for paying with a purse
The following example, which is illustrated in Figure 12.12, demonstrates a payment procedure using the components required for this function: the electronic purse (IEP), the terminal (PDA) and the security module in the terminal (PSAM). After the purse card has been inserted in the terminal, the terminal executes a reset in order to request ATRs from the PSAM and the IEP. If either of these ATRs does not match the expected value, the terminal aborts the payment procedure. If the ATRs match their expected values, the terminal selects the purse DF in the IEP. If this file cannot be selected, the procedure is also aborted. For reasons of clarity, however, these processes and general error handling are not shown here. After selecting the purse DF in the IEP card, the terminal sends the initialization command ‘INITIALIZE IEP for Purchase’. The IEP receives this command, increments the transaction counter, computes a key (KSESIEP) and generates a signature (S1) for the various data elements. It then sends these data elements and the signature to the terminal. The terminal next sends the initialization command ‘INITIALIZE PSAM for Purchase’ to the PSAM. This command simply relays the data elements received from the card to the PSAM. The PSAM verifies these data elements, which means that the expiry date (DEXPIEP), currency (CURRIEP), cryptographic algorithm used (ALGIEP) and the other received data are compared with values stored in the PSAM. If all of the comparisons are successful, the transaction counter (NTPSAM) is incremented. If any of the comparisons fails (e.g., if the expiry date of the IEP has been reached), command processing is immediately terminated and an appropriate return code is sent to the terminal (PDA). The PSAM next generates a derived key using the data provided by the IEP and generates a session key, and then it checks signature S1. If the signature is correct, it follows that all of the transferred data are authentic, and the IEP has also been authenticated by the PSAM. In other words, the PSAM knows that the card containing the electronic purse is genuine. Next, the PSAM also generates a signature (S2), which is sent to the terminal along with several other data elements. The user now enters amount to be paid (MPDA) and the associated currency (CURRPDA) at the terminal. The terminal then sends the entered amount (MPDA) and the data elements previously received from the PSAM to the card, using the DEBIT IEP command. The IEP now checks whether there is enough money in the purse to make the payment. If there is, it verifies signature S2. If the signature is correct, the data have not been manipulated during transmission, and the PSAM has also been authenticated by the IEP, since only a genuine PSAM can possess the secret key needed to generate signature S2. The appropriate amount is subtracted from the purse balance, a third signature (S3) is generated to confirm the debit transaction just performed and the log file is updated. Signature S3 and the debited amount are sent via the terminal to the PSAM, which verifies S3. If this signature is correct, the amount debited in the IEP is added to an internal data element (MTOTPSAM). The following command,PSAMComplete Purchase, updates thePSAMbalance by adding MTOTPSAM to the purse balance (TM). Finally, the PSAM receives a signature (S4) to confirm that the payment transaction has been successfully completed. The procedure described above is a very simple example of the various payment procedures described in EN 1546. There are also other possibilities, including an especially fast debiting procedure for card phones and a procedure that allows a receipt to be generated at the end of the transaction. Files, commands and procedures are also specified for all other important system components, just as they are specified for the cards as described above. This primarily applies to the security modules, since system security relies solely on these modules. Statistical methods may be employed to monitor the overall operation of the system, which in the case of large applications may consist of tens of thousands of terminals and several hundred thousand smart cards. Maintaining full accounting for every individual card would conflict with the demand for anonymity, and would anyhow require far too much computation. However, as tests have shown, the security of the overall system can be continuously monitored at an acceptable cost using random samples. The European EN 1546 standard established one of the foundations for multisector smart card electronic purse systems using smart cards. Nearly all procedures and functions that were in common use when the standard was generated and that were onsidered worthwhile are included in the standard. There is only one function that has not yet been described, although it is very important for card users. This is the ‘purse-to-purse transaction’, which means transferring electronic money directly from one purse to another. There is presently no description of this type of money transfer in the EN 1546 standard.