elecom's Chipper project, and in Singapore City University's and Hang Seng Bank's CitySmart program.
In about two years, however, smartcard technology will be mature enough to offer yet another level of convenience. At that time, you'll be able to decide what kind of ticketing, payment, and loyalty programs you want to have running on your card. All you'll need to do is get a so-called white card, or lifestyle card, and load the applications you want.
Rapid advances in the design and manufacture of components have driven the growth of the smartcard industry. Smartcard technology will mushroom into what analysts es
timate will be a $16 billion market by the year 2005. "The smartcard industry's investments in research have led to improvements that, just a few years ago, no one would have dreamt about," says Russel McCullagh, a senior technical marketing manager with Motorola Semiconductors (Glasgow, U.K.).
But on the other hand, proprietary card OSes and incompatible standards are hampering the growth of the industry. To ensure the success of multiple applications on one card, interoperability is indispensable. Several standardization initiatives are addressing the interoperablility of cards, readers, and applications (see the sidebar "A Group of 'Standards'").
Java's Pivotal Role
Not surprisingly, Java's multiplatform capabilities and inherent security features will play a pivotal role in the next generation of multifunctional cards. Through the Java Card API standard, this programming language entails shorter development and testing cycles because it relieves developers from the traditional chip-ma
sking process, which can take up to four months. Because of its popularity in the developer community, Java is open to anyone who can develop applications using common development tools.
The Java Card 2.0 API includes an object-oriented programming model, which allows for the definition of classes, interfaces, and packages with dynamic and static fields and methods. "Thousands of Java developers have the opportunity to write high-level, object-oriented applications that run securely on smartcards," says Fabien Thiriet, Cyberflex product manager at Schlumberger Electronic Transactions (Montrouge, Cedex, France). Any smartcard that integrates with a Java Card 2.0-compatible virtual machine (VM) can run these applications, even if the microcontroller and card OSes are different. This concept enables multiple applications to run on one card.
"The ultimate opportunity for Java Cards lies in the possibility of cryptographically separating the card issuer from the application issuer," says Jelte van der
Hoek of DigiCash (Amsterdam). Capitalizing on Java Card applets, called cardlets, consumers can use their white card and decide which cardlets they want to put on a card. Although application issuers might guarantee hassle-free and secure interoperation only with certified cards, the choice remains with the user.
Schlumberger's second-generation Java-based Cyberflex card can be dynamically added to or updated at any time. In this case, the white-card issuer provides the service of adding applications, but the user can download or update new services as well. Early Cyberflex adopters report that typical applications, such as single-sign-on password management and remote banking authentication, require between 1.5 and 2 KB of memory, making it possible to store up to three applications on a white card.
Due to the very limited resources of today's mostly 8-bit-processor cards, the Java Card API lacks some of Java's important features, such as unicode characters, floating-point numbers, double data ty
pes, exceptions, threads, and garbage control. The use of floating-point numbers alone requires about 2 KB of memory, which application writers today would rather use for mission-critical purposes.
Thus, the Java Card interface is no more than a smartcard-specific subset of the Java programming language. But new hardware improvements, due to arrive on the market in the next 18 to 24 months, will enable 32- and even 64-bit data types, making Java Cards viable multifunctional systems.
32-bit Processor Cores
Traditional smartcard microprocessors typically use the Motorola 6805 or Intel 8051 instruction set, which allows them to address 64 KB of 8-bit memory. But because of the cost constraints of large applications and the limitations of the microcontrollers' plastic housing, most applications in use today offer only up to 20 KB of memory. But better cryptography and more sophisticated OSes and VMs require more memory resources and the ability to perform real-time operations.
In an at
tempt to solve this problem, Gemplus's GemXpresso Java Card uses an implementation of ARM's 32-bit RISC ARM7 processor. This processor not only provides for 32-bit computations but also offers 20 MIPS of computing power, which can allow applications to run up to 60 times faster than on existing 8-bit processor cards. "This extra computing power is definitely an advantage in the context of Java," explains Arnaud Chain, multimedia marketing director at Gemplus (Gémenos, Cedex, France). "Dealing with high-level objects requires a lot more resources than directly addressing low-level functions on the card." The new ARM processor, for example, allows application developers to deal directly with 32-bit integers, which is a lot easier than cutting 32 bits into many 8-bit parts.
In addition, GemXpresso rapid application development (RAD) tools offer advanced memory management and a partial garbage-collection algorithm to increase programming flexibility. These features allow for Java stacks up to 1 KB, t
hus eliminating a severe constraint of the Java Card platform.
Patrice Peyret, director of the Smart Card group at JavaSoft, believes that the introduction of these 32-bit processor cards will accelerate the creation of new applications. "The combination of more-powerful hardware and Java Card's advanced software architecture will allow the speedy development of more advanced smartcard applications," she says.
Faster Memory
The industry's current move to replace EEPROM memory technology with ferroelectric RAM (FeRAM) will further propel the efficiency of smartcards. Companies such as Motorola and Matsushita have been working on the development of FeRAM for five years. Now several manufacturers are furnishing their next-generation cards with this technology. The first FeRAM-based cards will become commercially available by the end of 1999.
FeRAM is a nonvolatile technique that speeds memory access to as much as 20 times faster than EEPROM technology. Also, FeRAM-based smartcards offe
r a significant increase of memory capacities -- up to 128 KB. These features -- coupled with very low power consumption, greater endurance, and a cell programming method ideally suited for large memory arrays -- make FeRAM an attractive alternative for smartcard manufacturers.
This increase in computing power and memory, as well as the use of a high-level programming language, will allow the processing of more complex mathematical functions, which is simply not possible with 8-bit processor cores. However, the extra MIPS will also help smartcard manufacturers capitalize on advances in biometrics and cryptography. This, in turn, might allow the creation of single-application banking, GSM, and health-insurance cards.
But there are questions concerning the uptake of multiapplication cards. "The current growth of the market is predominantly driven by closed systems, single applications, and national programs," says McCullagh. "The key to a real market expansion is an open software scenario, and this
requires true multiapplication standards, much like in the PC world."
Adds DigiCash's van der Hoek: "With the current Java Card standard release, there's still the problem of loading the smartcard. The issuer must still create a download instruction for an application on a specific card." This defeats the purpose of standardizing on a common API, because if card issuers have to be involved before an application can be added, then the card might as well be programmed in a manufacturer-specific language.
As a result, this limits a consumer's freedom to mix and match applications and cards. "Only when Java Card applets can be downloaded with public-key technology and when processing inside the card is publicly verifiable by consumer organizations will the real power of Java surface," says van der Hoek.
A Not-So-Open Standard
The potential problems of a not-so-open Java Card standard might be avoided by vertical-market solutions. The Java Card Forum is now working on Vertical Market Ext
ensions for banking and telecommunications. For example, cards issued by banks might come with additional subsidiary applications that allow consumers to tailor cards to their needs. A multiapplication card issued by, say, a health-care organization piggybacking an insurance program and a government agency's identification application would no doubt be a useful product.
Tom Lebsack, director of marketing and business development at Schlumberger's Austin Product Center, says that "it's just logical that issuers control cards." According to the Java Card Forum, such multiapplication cards are close to a commercial introduction.
Today's applications are specifically tied to the card OS (COS) of a particular card, which in turn is usually tied to a specific chip. Most existing COSes allow only one application per card. Last May, however, eight of the leading card manufacturing and issuing companies, including Gemplus, Hitachi, Mastercard International, Mondex International, Motorola, and Siemens, anno
unced a new open multiapplication COS, called
MULTOS
. Although MULTOS is not the only multiapplication COS, it has the widest industry support today.
MULTOS enables a number of different products or services to be held securely and independently on a single card. Because MULTOS is compatible with most international standards, such as ISO 7816, GSM, and EMV (short for Europay, MasterCard, and Visa), products from different industries can coexist on the same card. MULTOS makes it possible, for example, to combine subscriber identification data for GSM phones with EMV credit or debit products and an airline's frequent-flyer scheme.
To securely download or delete applications, MULTOS uses Application Load Certificates (ALCs) and Application Delete Certificates (ADCs), which are specific to cards and applications. By using ALCs, MULTOS verifies that an application was initiated correctly after download. It checks the validity and integrity of the application, allocates a protected
and isolated memory area, and locks the new program into this secure space. This way, applications are strictly separated from each other so they cannot interfere with one another.
Due to MULTOS's security architecture, card users can customize their cards and download new services via phone or the Internet. This architecture also lets card issuers add applications and introduce security upgrades without discommoding their customers. Applications on the card are kept separate by secure firewalls, allowing for only the selective disclosure of private (but not secret) information.
This identification-verification scheme allows the operation of only authorized applications and ensures that applications have access only to their specific information base. It also guarantees the security and integrity of each application.
MULTOS includes the MULTOS Executable Language (MEL) and an API that developers can, for example, access from the C programming language. This, together with the COS's interpre
ter concept, might enable developers to sell hardware-independent applications. In addition, because of MULTOS's wide industry support, it might eventually become a standard for issuers operating in the finance, retail, media, and telecommunications sectors.
Although MULTOS and the Java Card API share the same goal of an open industry platform, they are not 100 percent compatible. Therefore, they are competing models. Today it seems that, for security reasons, developers must choose one or the other because MULTOS and Java interpreters cannot coexist. Only one interpreter at a time can be in control of application execution.
But Sun Microsystems and Mondex have already announced that they are working on a Java Card 2.0 API for MULTOS, which would allow Java or MEL to act as a primary application-development language. Java Card-based applications would then be able to run on Java's VM on top of MULTOS. Says Lebsack: "We believe that Java, in combination with an open, multiapplication OS, is where t
he industry should go."
Where to Find
DigiCash BV
Amsterdam, The Netherlands
Phone: +31 20 6652611
Fax: +31 20 6685486
E-mail: Info@Digicash.nl
Internet: http://www.digicash.com
Smarter Smartcards
