Cards are now the payment instrument that banks prefer customers to use for spontaneous transactions. They are gradually replacing (in some countries, have replaced) cheques and other paper instruments for these transaction types, and even have a rôle to play in many regular or business transactions.

Using a card removes a manual process (capturing the transaction details) and with it the scope for errors that any manual process offers. Cards help customers to use lower-cost channels (such as ATMs and the internet) and, in the case of smart cards, also actively help in managing many risks: by forcing the user to authenticate him- or herself, by managing transaction ‘velocities’ – i.e., the rate of spending – and by offering the merchant or acceptor the opportunity to verify the identity of the bank or its membership of a valid card scheme. In some cases the card acts as the agent of the bank, authorising or cryptographically signing transactions on the bank's behalf.

There is also a marketing and psychological side to the bank–card-holder relationship: the card carries the bank's brand and is the permanent reminder in the customer's pocket. In a competitive business, where customers may have accounts with many banks, the card that is ‘front of wallet’, i.e., used most often, identifies the bank that has raised the level of its relationship from pure account-holding to that of a preferring customer.

Smart cards in daily life

Cards are so much part of our daily lives that we do not even think about their functions, the technology behind them or the things that make them special.

Cards are behind some of the biggest changes in behaviour in the Western world since 1970 – the way we enter buildings, pay for goods in shops, speak to our friends and business partners. Back in 1970 it would have been difficult to imagine the ease with which we now draw money from ATMs in foreign countries, or that many ten-year-olds would have their own telephones.

Many of these changes have helped to spread technology as well, benefiting a wide range of people in poorer countries and remote areas. Where there is no reliable telecommunications network, the ability to store a patient's health records in a card can save lives. In most African and many Asian countries, there are many more mobile telephones than fixed lines; these telephones not only use cards to provide security and added functions, but may themselves act as terminals for other card-based applications, such as microfinance.

It's not all good news, of course: some of these changes have been made necessary by the increasing need for security, while others have increased efficiency but have incurred a cost in reduced personal service and social interaction. And not all card projects have been equally successful.

We must now digress from our discussion of the technology of cards and readers to cover another two sets of technologies that have a major impact on cards, and are likely to grow in importance in the coming years: biometrics and cryptography. This chapter will cover biometrics and Chapter 5 will address cryptography and the security of cards.

In most smart-card applications, the card is associated with a person; it represents a key to that person's details in a database. It is, therefore, very important to be able to identify the person who is using the card and to ensure that he or she is the person whose details are being unlocked. Often (for example in an access control or passport application), this is the main purpose of the card or application. In other cases the purpose is to allow access to data stored about that person.

In most card-based systems we need to do this automatically, although sometimes there is a human element as well (for example, inserting the card could call up an image of the card-holder, which can be checked while the user is entering his or her password or verifying a fingerprint).

Many people feel that a human check is better than any automatic check, however this is definitely not true when the population being checked is large.

Another science – some would say art – that is very important to smart cards is cryptography. Cryptography is an essential part of many of the security functions for which smart cards are used. This chapter can only give an overview of the issues that are relevant to smart cards, and readers seeking a deeper understanding of algorithms and cryptography generally are referred to the further reading suggested in Appendix B.

Cryptography

Algorithms

Modern cryptography combines algorithms (mathematical transformations) and key management techniques to secure data in many different ways. The main algorithms used change only very slowly, since only thoroughly tested and well understood algorithms are used for important security functions. People outside the security industry often feel that a newly developed or secret algorithm should be more secure, but the history of cryptography has shown that only a very few algorithms remain unbroken after many years. Nearly all others succumb sooner or later to some easy attacks – once an attack is known the algorithm is useless.

Algorithms are divided into two groups: symmetric algorithms (like the Data Encryption Standard ANSI X3.92 or its more modern and stronger replacement, the Advanced Encryption Standard FIPS-197 1) use the same key for encryption and decryption. Public-key algorithms (such as RSA 2) use a different key for encryption and decryption: the owner keeps one key private while the other is published.

The term ‘multi-application card’ is used in different ways by different groups of people: the marketing department sees the card in terms of selling features, the IT department according to the technologies used by the card, and the operations department looks at the number of processes the card supports.

This chapter explores the definitions of the term and sets the framework within which the remainder of the book will use it.

Single-function cards

Most smart cards have a single function. There is a simple reason for this: the card issuer has issued the card to solve a specific problem or to provide a specific service. The relationship between the card issuer and the card-holder is generally not complex, while most card issuers are in one well-defined business. So there is no reason for the card issuer to provide multiple functions on the card, which in most cases would add to the cost.

Smart cards are, in many cases, replacing a magnetic stripe or visual identification card, which generally had only one function. So, for example, the earliest smart cards were used mainly for public telephones: they held value that could be loaded by the telephone company and decremented by the user making calls, and this was their only function. Many schools issue cards to their pupils for recording attendance at classes, while companies issue cards to their employees for access to buildings. These cards need no further functions.

Having looked at the technology available to create a multi-application card scheme, we now turn to the business requirements – what are organisations trying to achieve when they launch a multi-application scheme? What are their underlying aims and how do these differ from sector to sector? If several parties are co-operating on a scheme and they each have different aims, this may cause problems from the start.

In this chapter, I will consider the requirements that are common to all multi-application schemes, and in the next five chapters I will look at some key sectors that have implemented smart-card schemes. In each case, there is scope for combining applications within one sector or across sectors: combinations within a sector may be difficult for reasons of competition or service scope, whereas across sectors the issues may be cultural or organisational. I will explore these in more detail in the last few chapters of the book.

Card issuing

Issuers generally have one of two motives for issuing a card: the first is to provide a simple record of entitlement (proof that some money has been paid or that a person may enter an office). This type of card is often short lived and it is probably a simple data carrier, adding little value. Typically, the requirement for such a card is to provide the record of entitlement at the lowest possible cost consistent with an adequate level of security and reliability. Such cards are very unlikely to carry multiple applications.

We saw in the previous chapter that the application selection function plays a pivotal rôle in the design of any card-reading terminal. In this chapter, I will review the requirements for application selection and the options for cards and terminals to implement this function.

Scope and functions

Application selection is required for any microprocessor card, not only for multi-application cards, since it is the process by which the card application is started up.

For memory and wired-logic cards, even though there is no firmware ‘application’ on the card, the initial process is similar but application selection is implicit. In this case the terminal must select the appropriate supporting program and functions.

Where either the card or the terminal is multi-application, in the widest sense described in Chapter 2, application selection plays a pivotal rôle in determining which of the applications will be run; it links the technical protocol-handling functions with the logical transaction flow.

In some cases, the application to be selected is known before the card is inserted, either from the context of the transaction, or because an operator or user has already selected a function. In other cases the card and terminal must agree the selection, or offer a choice to the operator.

Card initialisation

Power up and reset

The process starts with powering up of the card and the way the card responds to the reset signal: its answer-to-reset (ATR).

History

Multos was originally developed by Mondex International, the developers of one of the world's first electronic purses.

Mondex foresaw that issuers of electronic money would want to allow the e-cash application to reside on any smart card, not just ones issued by financial institutions. Hence, the electronic purse could find itself co-residing with other applications, such as a club membership or a credit–debit function, on the same card. It was also envisaged that applications on the smart card might be updated or added during the life of the card. And to protect the e-cash application from attack by fraudsters or hackers, it was essential that the multi-application smart-card platform must be secure and controlled by the card issuer.

Having worked on the electronic purse card for some years, the banks that owned Mondex could see the wide range of potential applications for the technology and, in particular, for the security functions it could offer. High levels of security, proof of security and tight control by the card issuer were key requirements. The design objectives of Multos were, therefore, fourfold:

• A very high security platform;

• A platform-independent programming language and application architecture;

• The ability for multiple applications to share card memory and data in a secure and controlled way;

• The ability to download applications after the card has been issued, but without the risk that unauthorised applications could be loaded or could corrupt existing applications.

Multos products first appeared in 1996, and in the same year the Maosco consortium was formed (by smart-card manufacturers and integrators, telcos and payment-card schemes MasterCard and American Express) to manage the specifications and to promote the operating system as an open standard.

This chapter picks up the story from Chapter 3 and looks at advances and variants in chip and card technology, particularly those that affect multi-application cards.

Microcontrollers

Architecture

The microcontroller chip is at the heart of smart-card technology; as we saw in Figure 1.2 an increasing proportion of all smart-card chips use one.

As in all computing, more advanced operating systems and applications are demanding more power from the processor. But while microprocessors for mainstream computing are able to satisfy the demand for more power by increasing the number of transistors packed onto the chip, and hence the heat generated, smart-card chips are limited in both the area of the chip (25 mm2 is normally considered the limit for reliability) and the amount of heat that can be dissipated.

A growing number of chips, therefore, make use of reduced instruction-set computing (RISC) cores, which give faster processing for a given power input. Separating the cryptography into its own processor can also help, and it is also more efficient if the input–output is handled by its own processor. Longer word sizes (32 bit words are now the norm in mainstream computers, and 64 bits quite common) are less beneficial in smart cards, and a 32 bit processor does not necessarily give a better speed–power ratio than 16 bits.

Cards can be tailored to the specific applications they will run: Multos cards have for some time been tailored to running the specific code that this operating system generates, and some processors are now optimised to run Java byte code directly.

The previous five chapters have identified almost 100 suitable applications for smart cards, each with demonstrable benefits in some situations. Few people would imagine that all these applications could all reside on one card, although this would be technically possible, even today.

It is, therefore, useful to consider which applications have a good ‘fit’, so that they could share a card. Two perspectives are equally important:

• The card and application issuers must find it both easy and profitable to work together;

• For the card-holder, there should be a logical connection between the applications.

This chapter looks at each of these in turn: what makes it easy for organisations to work together and what are the barriers? And what ‘domains of use’ make sense to the card-holder?

Corporate culture

Probably the first factor that affects any co-operation or partnership between organisations concerns their corporate cultures and the personalities of the individuals involved. A large, slow-moving, risk-averse organisation is unlikely to make a good partner for a small, entrepreneurial business.

This, and indeed most of the organisational and commercial effects described in this chapter, can apply to multi-application projects involving several departments in one company, as well as to multiple companies. A successful co-operation in one country may not be transferable to other national operations of the same company.

In the case of card projects, attitudes to card-holders and users can vary widely, even within a sector.

Any card issued by a central or local government is liable to be branded as an ‘identity card’. In many Western liberal countries that poses automatic grounds for suspicion of the issuer's motives; this chapter explores some of these motives and the issues surrounding government-issued cards.

Databases and cards

All card systems depend on a central database in some form. But for government cards in particular, it is important to distinguish card projects from the databases that underlie them. The growth in government ID card projects has been accompanied by growing concerns, from civil liberties groups in particular, about the potential loss of privacy these projects entail, and the potential for abuse and discrimination.

In practice, the use of large-scale databases is expanding strongly and does offer some scope for abuse; a correctly implemented card system linked to these databases offers the potential to control access to the data and give individuals more power over the way their own data are used. It is ironic that much of the opposition to identity cards implies that the use of a card represents an infringement of privacy, whereas a well-implemented card system should actually help to manage the privacy risk and to give citizens a degree of control over access to their records that they are unlikely to gain without such a card.

History

In 1996, smart-card manufacturer Schlumberger demonstrated a card operating system to which it had added Java bytecode interpreter functions for a small number of methods. This initial implementation was very limited and involved an intermediate format, but it attracted considerable interest because it offered, for the first time, an opportunity for mainstream computer programmers to become involved in smart-card application development.

At the same time as Schlumberger was working on this development, Visa was working with Integrity Arts (a subsidiary of another smart-card manufacturer, Gemplus) to specify an ‘open’ smart-card operating system that could work on any manufacturer's card, permit the use of programmer-friendly development tools and allow applications to be downloaded to the card.

The two streams of activity together triggered Sun Microsystems to buy Integrity Arts and to endorse a specification for a Java implementation on a smart card, known as JavaCard 1.0, which drew on both efforts. Gemplus and Schlumberger joined with other smart-card companies to form the JavaCard Forum, which released the JavaCard 2.0 API at the end of 1997. This second release was considerably more detailed and allowed many more practical implementations.

However, even this version did not ensure portability of applications between smart-card platforms, and did not define in any detail the mechanisms for downloading applications to the card. To overcome these limitations, Visa published its Visa Open Platform specification in 1998, which defined mechanisms for secure applet download and on-card management.

Telephone cards

The very first smart cards were issued in the mid 1980s as disposable prepaid cards for public telephones. They replaced magnetic stripe, optical or inductive cards with a technology that was generally more reliable; over 95% of all telephone cards for automatic use now employ smart card technology. The competition is not from other card-based systems but from centralised systems where the account is held on a host system rather than on the card itself (even if a card is used to deliver the account number to the user).

The business requirement for a public telephone operator is to eliminate the collection of cash in telephones using a reliable system with a minimum of moving parts. Coin-operated telephones are expensive to build, since they must be very robust; they are expensive to operate (the cash must be collected regularly) and to maintain (coin mechanisms frequently become jammed or are vandalised).

Smart cards can be sold by retailers like any other goods and so can be made very widely available. The ‘float’ of value sold but not yet used is available to the operator and can earn interest (although it does still represent a liability in accounting terms). Smart cards, therefore, offer a very convenient and portable way to sell value; however they also have some disadvantages:

• The cards themselves must be manufactured and distributed; card cost may be as low as 8–10 cents but as a proportion of the smallest denomination value (which may be $2 or even less) this is still substantial. In addition, the distributors and retailers need to make a margin, which may be 5–15% of the card value;

• […]

In previous chapters, I have listed many potential barriers to a successful multi-application chip-card scheme, but also several ‘enablers’ – factors that will contribute to making a project successful.

This chapter is set out as a checklist; it sets these barriers and enablers against the phases of a project and should help those planning or implementing a multi-application project to make the right decisions at the right time.

Defining the project scope and road-map

For any project, clear definitions of scope and objectives are critical for success. In the case of a multi-application-card project, the business objectives must be clear and should drive the scope of the project. For the initiating organisation, its own business objectives must come first and should not be derailed by those of other partners.

There is a strong tendency for the scope of multi-application projects to grow during the life of the project: what is known as ‘function creep’. Whilst it is important to keep an eye open for changing circumstances, and some additional functions or markets may make good sense, any change to the original scope must be weighed against its effect on the business objectives and timescales.

Many multi-application projects will start with some basic features and add others as time goes on. It is very helpful to design a road-map that answers the questions:

• What do we have now?

• What will we add at each stage and how long will that take?

• What will we have at the end of this stage?