Previous Table of Contents Next


Assembly Language Card Programs

Although they're the least likely and most demanding of the smart card programming scenarios, there are situations in which a system designer will want to consider extending an existing smart card operating system or creating a new and unique smart card. For example, you might wish to add a new encryption algorithm or mode of communication to a smart card.

To build a custom smart card, an application system designer would typically work with a smart card manufacturer, such as Schlumberger or Gemplus, and possibly a smart card chip manufacturer, such as Motorola, Siemens, or Philips. It might be possible to modify and extend existing operating systems and libraries owned by these manufacturers to incorporate custom features as opposed to creating a completely new operating system for the smart card. Both Schlumberger and Gemplus produce off-the-shelf cards that can be extended after manufacture. Some functions on smart cards, such as communications and card file services, are common to almost all smart cards; the creator of a custom card would not want to reproduce these. A small number of independently developed smart card operating systems are available for licensing.

Creating a custom-built smart card is expensive both in time and in money. Table 1.2 lists some hypothetical cases. You should probably budget at least two years and at least $1 million. Furthermore, it is unlikely that the resultant card will interoperate with any existing host software or systems, so there might be additional time and money expenses on the host side of the system. For all but the largest organizations and applications, assembly language programming of smart cards should be considered only for closed, mission-critical systems where compatibility is not a consideration.

Table 1.2. Comparison of smart card programming projects.
Software Type Application Development Time Typical Program Size Card Type Used Difficulty Expense

Host 6 months 10 KLOC Off-the-shelf Medium Low
Application card 1 year 1 KLOC Java Card Medium Medium
System card 2 years 4 KLOC Custom High High

Each smart card chip manufacturer has its own procedures for building a smart card chip containing a custom assembly language program and operating system. These procedures are discussed in detail in Chapter 3, “Some Basic Standards for Smart Cards,” as are procedures for getting these chips made into cards.

Smart Card Software Security

Smart card software security is, not surprisingly, based on cryptography. Keys are stored in files on the card and algorithms and protocols are implemented in software on the card. Cryptography is used primarily to authenticate system entities, such as users, cards, and terminals, and to encrypt communications between the smart card and the outside world. The cryptographic functions built into a smart card for its own security requirements may also be used to implement security functionality in other systems. The protections provided by the former obviously enhance the security of the latter.

Before a smart card can provide access to its resources, it must determine with whom it is dealing. Similarly, before it is accepted by other entities, it must be able to prove who it is. Therefore, one of the first tasks a smart card performs when it is activated is to authenticate entities outside itself, primarily the person who inserted it into the terminal and the terminal into which it has been inserted, and to authenticate itself to some or all of these entities.

An authentication procedure may be as simple as demonstrating the possession of a shared secret such as a 4-digit PIN, or it may be as complicated as demonstrating the ability to encode an offered message called a challenge with a particular key and algorithm or continuously following a defined transaction protocol. If at any point in an authentication process an entity reveals that it is not who it claims to be, all further communication with the entity is blocked. A record of these failed attempts may be kept on the smart card and after a certain number of failures with no intervening success having been reached, the card may block all further access or destroy itself and its contents completely.

Encryption can be applied to all message traffic to and from the smart card or only to particular messages. If a smart card is communicating with two applications simultaneously, it may be using a different encryption key or technique with each.

Smart card programmers typically do not have to design new authentication or encryption algorithms. Rather, they use the facilities that are built into the smart card. These facilities have been field tested and come with a certain level of assurance of correctness. Designing new algorithms is not easy, and validating the correctness of a new algorithm is probably not a subtask that a smart card application developer wants to assume. Table 1.3 lists a number of cryptographic algorithms which find use in various smart cards.

Table 1.3. Examples of smart card encryption algorithms.
Algorithm Sample Uses

DES Communication channels
A3 and A8 GSM mobile telephone
Elliptic curve Digital signature
TSA7 Health records
RSA Digital signature


Previous Table of Contents Next