24 1092-3063/99/$10.00 © 1999 IEEE IEEE Concurrency

The Smart Card: Don’tLeave Home Without It

in smart-card technology are bringing along-held dream of IT developers closerto reality: the vision of a very small, port-able computer that contains all of theuser’s personal data in a highly secure formand performs many additional functions.

Developers hope smart cards will com-bine conventional identification documentswith an electronic purse and a bank accountaccess card for telebanking transactions.Another goal is to be able to insert the cardsinto an Internet terminal for e-business.Smart cards might also provide access tomail functions; replace key chains by actingas a multipurpose digital key; serve as a ticketfor public transportation systems; or serveas a key card for a previously booked hotelroom. Multipurpose smart cards, to or fromwhich we can dynamically load or deletefunctions, are on their way to achieving suchgoals. Human imagination is our only limit.

Historical bytes

The last three years have seen a rise in smart-card-enabled products. At the same time,various smart-card initiatives have come intoexistence that address some of the smart-cardstory, which began back in the late 1960s.

The first smart-card-related research

dates back to 1968, when two Germaninventors, Jürgen Dethloff and HelmutGrötrupp, patented their idea of using plas-tic cards as a carrier for micro chips (visitwww.cardshow.com/museum for a smart-cardtimeline). However, not until 1976 was thesemiconductor industry capable of produc-ing chip cards at acceptable prices. Then,after Roland Moreno patented the chip cardand ways of producing it, companies suchas CII-Honeywell Bull (now CP8 Transac),Dassault Systems, Flonic-Schlumberger,IBM, Philips, and Thomson started pro-ducing chip cards in larger numbers.1

Driven by the Groupement Carte àMémoire, a French consortium, the firstfield trials took place in 1981 with a bank-ing chip card in the cities of Blois, Caen, andLyon. Other field trials followed in the sameyear with a telepay card, identification cardsfor the US government, and other projects.France Télécom initiated the first phonechip card in 1984. That same year, the chipcard spread through other parts of Europewith a bank card trial in Norway. Othercountries and companies—among themMasterCard and then Visa—followed.

Today, smart cards are used in a wide vari-ety of applications ranging from buildingaccess systems to electronic payment schemes,

In this first of three

related articles, the

author introduces Smart

Cards, discussing both

their background and

where they’re headed

in the future.

Mobile Computing

The term smart card generally refers to a plastic card—the size

of an ordinary credit card—with a chip that holds a micro-

processor and a data-storage unit. Such cards have standard-

ized electrical contacts for drawing power and for communi-

cating with external devices. Furthermore, the newest advancements

Dirk HusemannIBM Research Division

Zurich Research Laboratory

from conditional access methods for satel-lite TV to electronic signature applications,and from loyalty programs to public trans-portation applications. The Smart Card In-dustry Association (www.scia.org) estimatesthat in the year 2000, around 2.8 billionsmart cards will be distributed—with thelargest percentages in Europe (40%) andAsia (30%).

What makes a smart card“smart”? A chip card uses an integrated circuit chipfor data storage, while a smart card is achip card that also contains a CPU andsome means of storing programs—forexample, ROM and EEPROM (elec-tronically erasable programmable read-only memory). It is a small computer withits own operating system, programs, anddata. Access to data stored on a smart cardoccurs under the control of the operat-ing system. Thus, not only can we imple-ment fairly sophisticated access-controlschemes to protect data stored on thecard, we can also implement public keysignature schemes to have the card per-form electronic signatures, for example.Some smart cards also offer additionalfeatures, such as fingerprint sensors, acontactless interface, or even a display.

In contrast, a magnetic-stripe card isjust a piece of plastic offering unprotecteddata storage. Anyone with a (relativelycheap) magnetic-stripe-card reader can

access the data and tamper with it. Also,these cards store only a fraction of the datathat a chip card or a smart card can store.

Most of the phone cards are just mem-ory cards with additional logic to prevent(unauthorized) recharging. Memory cardsare sometimes called synchronous cards—our access to the chip and its effect on thestored data is immediate. Smart cards arecalled asynchronous cards—we send a com-mand to the smart card, and the smartcard processes the command and eventu-ally comes back with an answer.

In most cases, smart cards look verymuch like a magnetic-stripe card, but witha CPU chip in the upper-left-hand corner(see Figure 1). Some smart cards come “dis-guised” in a different form—for exampleas rings (Dallas Semiconductor’s JavaRingis an example of a ring-shaped smart“card”)—or do not appear to have a CPU,as in the case of contactless smart cards (seeFigure 2). All smart cards, however, havecommon features: an operating system thatcontrols access to the card’s data and func-tions, stored in ROM; data stored in EEP-ROM; and RAM for transient results (stackor heap). Typically, the CPU on any givensmart card will be of the old 8-bit variant—although some cards with 16-bit and 32-bit CPUs are on the market.

Selecting standards

The International Organization for Stan-dardization (ISO) specifies physical char-

acteristics (ISO 7816-1); contact locationand dimension (ISO 7816-2); and electri-cal signals along with low-level transport(ISO 7816-3) and high-level application(ISO 7816-4) communication protocols.Part 4 of ISO 7816 is of particular interestas it specifies the standard communica-tion-protocol data units, Application Pro-tocol Data Units (APDU). Moreover, ISO7816-4 describes how the data storage ona smart card might be organized as a filesystem.

ISO 7816 also addresses issues such asnumbering systems and registration pro-cedures for smart-card applications, tag-length-value data structures, enhancedsmart-card commands (mutual authentica-tion, SQL access, and encryption), andmore. The European TelecommunicationsStandards Institute has issued its own set ofsmart-card protocols, CEN726, that definealmost the same things as ISO 7816—illus-trating the fractured nature of the smart-card world. Fortunately, CEN726 and ISO7816 agree on the APDU format, basicinstruction set, and return codes.

Although ISO 7816 lays the ground-work for smart cards, it is not very specificconcerning interoperability. Most of theAPDU definitions ISO 7816-4 contains areoptional, and—being a true ISO stan-dard—ISO 7816-4 has many loopholes.Consequently, in theory we could create asmart card claiming to be ISO 7816 com-pliant, even though no application otherthan our own could talk to this card. Ad-dressing this problem of vague specifica-tions are a variety of industry smart-cardstandards—some competing with eachother, others complementary to each other.

Prominent representatives of theseadditional—and somewhat vertical mar-ket-oriented—industry standards are Figure 1. An example of a typical smart card.

Figure 2. The JavaRing—a ring-shaped smart card.

April–June 1999 25

26 IEEE Concurrency

• the Groupe Spéciale Mobile subscriberidentity module (GSM SIM) smart-card specifications;

• the EMV Payment System specifica-tion by Europay, MasterCard, andVisa;

• Visa’s Open Platform specification; and • the international Common Elec-

tronic Purse Standard (CEPS)—towhich electronic purse schemes suchas VisaCash, Mondex, Proton, Geld-Karte, and Chipper are converting.

In addition to the above-mentionedindustry standards, there are a plethoraof proprietary smart-card solutions, typ-ically developed by one smart-card man-ufacturer for a particular application.

Smart-cardcommunicationTo really communicate with a smart card,we need the equivalent of a magnetic-stripe-card reader—a smart-card termi-nal. Even here, the smart-card industryhas not yet reached a consensus on whatto call this device. Candidates includesmart-card terminal, smart-card reader,card acceptance device, or smart-card slot(for the remainder of this article, I’ll usethe term smart-card terminal). The samediversity of standards that we saw on thesmart-card level we encounter here again.

Although all smart-card terminalsclaim to implement the relevant parts ofISO 7816, we nevertheless find a widevariety of behaviors. Some smart-cardterminals hide the fact that an insertedsmart card can only speak one of the twolow-level transport communication pro-tocols that ISO 7816-3 defines; othersexpect the application to deal with thevarious protocols. Some terminals willexchange only application-specific pro-tocol data units; others will pass on trans-port-protocol data units. In addition,some will deal with certain error condi-tions themselves, while others expect theapplication to do so; and some will auto-matically retrieve an answer-to-resetAPDU from the card, while others willnot even automatically provide power toan inserted smart card.

In the last couple of years, developers

have attempted to standardize the behav-ior of smart-card terminals and defineconvenient and easy-to-use interfaces forthe application programmer—namely,CT-API, PC/SC, and the OpenCardFramework (OCF). Of the three efforts,CT-API is probably the oldest effort orig-inating with the German health-card pro-gram. Many European smart-card termi-nals implement the CT-API. It specifiesa low-level interface that provides directaccess to the smart-card terminal. In addi-tion, it prescribes operational character-istics of smart-card terminals.

PC/SC is an industry standard drivenby Microsoft to define a smart-card API(visit www.smartcardsys.com). In its currentimplementation, it is Windows-9X basedand many card terminals support it; mostof the PC-card-based smart-card termi-nals, for example, implement the specifi-cations. Compared with CT-API, it offersan advanced architecture sporting aninterface driver and resource-managerconcept that ties in nicely with Microsoft’sWindows 9X runtime environment.

The OpenCard Consortium’s OCF is aJava-based cross-platform framework thataddresses not only smart-card terminals butalso smart-card application issues (visitwww.opencard.org). On the terminal level, itdefines a software interface and expects thesmart-card terminal drivers—CardTermi-nal components—to deal with and hide thetransport-level communication from theapplication. OpenCard’s CardService layerprovides a set of interfaces for CardServicemodules that provide access to smart-cardfunctionality; for example, OpenCard’s FileSystem CardService offers a standard APIfor accessing file-system services on a smartcard—independent of the smart card beingused. With OCF, the application pro-grammer concentrates on the logic of herapplication instead of dealing with the var-ious and sometimes subtle differencesbetween different smart-card terminals andsmart cards. OpenCard can make use ofPC/SC as a card-terminal layer on theWindows platform.

Expanding the domain

Efforts such as the OCF or PC/SC thataim to provide well-defined and depend-

able interfaces between smart cards andsmart-card-enabled applications are be-coming increasingly important. So far,smart-card programming has been thedomain of the smart-card manufacturers,requiring intimate knowledge of thesmart-card operating system on a partic-ular card. Very rarely would you en-counter the same smart-card operatingsystem on cards from different manufac-turers. Recent industry efforts, however,are about to change the rules of this game.

The JavaCard Forum, for example,defines a Java virtual machine and a set ofJava system classes that run on smart-cardprocessors; thus, anyone versed in Javawill be able to develop and run code forJavaCard smart cards (visit www.javacard.forum.org). The JavaCard Forum—which much of the smart card industrysupports—is not the only such initiative.Multos is another initiative aimed at pro-viding a common smart operating-systemplatform. Originating with Mondex, it isnow owned and driven by the MAOSCOConsortium (visit www.multos.com). Mul-tos comprises the API, operating system,and silicon chip. Also, part of the Multosstory is the assembler language MEL(Multos Executable Language), in whichall Multos application are written.

Other efforts to provide an open, pro-grammable smart-card platform includethe Microsoft SmartCard for Windows,an operating system for smart cards thatwill execute VisualBasic; first beta versionswere announced for the first quarter of1999 (visit www.microsoft.com/presspass/press/1998/oct98/smrtcdpr.htm). A moreconcrete, touchable Basic-based solutionis available from the German companyZeitControl, the BasicCard (visit www.plastikkarten.de/index_e.htm?zc-easye.htm).In its Compact Basic Card incarnation, itoffers 9 Kbytes of ROM code, 1 Kbyte ofEEPROM, and 256 bytes of RAM alongwith a virtual machine to execute Zeit-Control’s P-Code.

Magnetic vs. smart

With so many industry efforts and com-panies dedicated to smart cards, and withtheir obvious advantage over magnetic-stripe cards, why are magnetic-stripe

April–June 1999 27

cards still in use? Whether to prefer asmart-card-based solution depends on

• the value of the services or goods;• whether the application operates

online or offline;• whether the application requires

some protected functionality;• the number of applications supported.

A smart-card-based solution works ifthe value you’re protecting or potential lossis high. However, if your access points arealways connected to your network andyour solution works online, then a mag-netic-stripe card might be preferablebecause you can detect fraud and misusein real time. If you require some function-ality of the card—for example, an elec-tronic signature—then a smart card is theonly alternative. Smart cards can also sup-port multiple applications whose data areasneed to be protected against one another.

The more smart cards become a reality,and the more they become accessible tononspecialist IT solution providers (forexample, through JavaCard-based smartcards), the less we’ll see of magnetic-stripecards. Furthermore, the price of smart-card deployment has already rapidlydecreased, and the average cost of a smartcard is now $2 to $16.

The mobile smart card

Smart cards are great for mobile appli-cations because they

• are small and easy to carry around;• provide a secure data container;• can be used for authentication pur-

poses using elaborate schemes; and • offer metering features.

Not surprisingly, smart cards have beencompared to agents that act on yourbehalf and represent you to an applicationor a system. An electronic signature thatyour smart card carries out representsyour signature. Also, (almost) arbitraryauthentication schemes (some involvingadditional input from you, such as a PINor your fingerprint) can be implementedon a smart card and can prove that you area legitimate user of some service.

Furthermore, a smart card not only pro-tects your personal data from unauthorizedaccess, but also protects the card issuer orservice provider’s data. Thus, businessescan implement shared secret schemes andrest assured that customers will not be ableto manipulate the data placed on the smartcards. Another attractive feature is that witha lot of these schemes, no back channel toa central server or network is required. Also,even though smart cards only offer a limitedamount of storage capacity, through the useof Remotely Keyed Encryption Protocols,a card’s storage can be increased almost infi-nitely—at the cost of requiring networkconnectivity.2

As smart cards are something inherentlymobile, we might wonder whether there isa case of nonmobile smart cards. One use isas a security access module (SAM) for appli-cations involving cryptography. Typically,the smart card is installed once and remainsin the device that requires its SAM services;an example is smart-card based cash regis-ters for electronic payment schemes.

ALTHOUGH INDUSTRY initiatives suchas the JavaCard Forum or the OpenCardConsortium are facilitating access tosmart-card functionality, we still facesome interesting challenges:

• Multiapplication cards have not yet fullyarrived; we still need viable solutions forcontrolling application installation anddeinstallation while the cards are in use.

• Owning a card is also an open issue:is it the customer who possesses thecard who owns it and has a say overits content (as is the case with today’sPCs), or is it some issuing organiza-tion? Who owns the private data?

• As we increasingly come to rely on smartcards, we need proper life-cycle man-agement systems: what happens if youlose your card with all the cryptographickeys to your PC’s file system? Withouta (trustable) backup system, you mightas well reformat that file system. Howdo we move applications from one cardonto another? I certainly would like tokeep my health records separate frommy employer’s cafeteria card.

There are also security issues. Althoughsmart cards are much more secure than amagnetic-stripe card, there are neverthelessways of getting to a smart card’s secrets.3Paul Kocher of Cryptography Researchcame up with an approach of differentialpower analysis, where you “draw mathe-matical inferences from the fluctuating elec-trical power consumption of the chip.”4

Other attacks include direct physical attacksof the smart card’s chip by chemical andelectronic means.5 Although countermea-sures are being implemented, smart-cardsecurity remains an important issue.

The next issue of Concurrency will fea-ture another two articles on smart cards:one will focus in more detail on the Java-based OpenCard Framework, and theother will take a closer look at the Java-Card platform and IBM’s JavaCard inparticular, so stay tuned.

References1. J. Ferrari et al., Smart Cards: A Case Study,

IBM Int’l Tech. Support Organization,SG24-5239-00, Oct. 1998; http://publib.boulder.ibm.com/pubs/pdfs/redbooks/sg245239.pdf.

2. P. Biget, “The Vault, an Architecture forSmartcards to Gain Infinite Memory,”Proc. Third Smart Card Research andAdvanced Application Conf., Springer-Verlag, New York, to be published, 1999.

3. P. Wayner, “Code Breaker Cracks SmartCards’ Digital Safe,” New York Times, 22June, 1998; www.nytimes.com/library/tech/98/06/biztech/articles/22card.html.

4. P. Kocher, “Timing Attacks on Implemen-tations of Diffie-Hellman, RSA, DSS, andOther Systems,” Dec. 1995; www.cryptog-raphy.com/timingattack.

5. R. Anderson and M. Kuhn, “Tamper Resis-tance—A Cautionary Note,” SecondUSENIX Workshop on Electronic Com-merce Proc., USENIX Assoc., Berkeley,Calif., Nov. 1996, pp. 1–11; www.cl.cam.ac.uk/users/rja14/tamper.html.

Dirk Husemann is a research staff memberin the Applied Computer Science departmentof IBM Research’s Zurich Research Lab. Hismain research interest is in pervasive andubiquitous computing. He received his MAand PhD in computer science at the Univer-sity of Erlangen-Nürnberg, Germany. He isa member of the IEEE, IEEE ComputerSociety, and USENIX. Contact him athud@zurich.ibm.com.