Previous | Table of Contents | Next |
This chapter describes application program interfaces for card software (that is, programming interfaces for the parts of application programs written to run on the processor inside the smart card itself, as opposed to application software written to run on a terminal or a host computer connected to a smart card reader containing a smart card). A number of special considerations must be taken into account when building card software that is unfamiliar to most application programmers. These special considerations include a limited and multipart memory system, a constant concern for data security, a basic distrust of users and network peers, and the possibility that power can be removed from the computer at any moment.
It is useful to distinguish between public and supported programming interfaces designed for third-party application programmers (typically outside the organization that built the interface) and internal interfaces that are part of good software engineering. A smart card operating system, like any other operating system, is built from a collection of modules which provide services on internal system interfaces to other modules. These system interfaces may change from one operating system release to the next, depending on evolutionary demands being made on the system. Application programming interfaces, on the other hand, are much more stable system interfaces and dont change from one operating system release to the next. They are, in a sense, a guarantee of functionality from the programmers building the operating system to the programmers building applications to run on top of the operating system. Since opening smart cards up to customer-provided software is a relatively recent phenomena, it will be important to ensure that software written to run on the card is sitting on a firm foundation.
It is also useful to make the distinction between writing programs in a high-level programming language and writing programs in microcontroller-specific assembly language. When writing in a high-level language such as C, Forth, or Java, the application programmer is typically presented with a well thought-out and thoroughly integrated set of services that have been explicitly designed to work together to ease the task of writing application software. One of the design goals of a good high-level programming interface is to provide help in dealing with the special considerations of smart card programming, such as those listed in this chapter.
When card software is written in assembly language, on the other hand, one can access data anywhere in memory and call upon any available entry point. Even when these entry points are part of public interfaces, they may be from different software providers and may, in fact, place calls on each other. For example, a call on a cryptographic routine may in turn generate a call on a communication routine which in turn calls a memory management routine. It is up to the assembly language programmer to understand and abide by the rules assembly language routines must obey so that they work together successfully and dont step on each others toes. Because space and time are at such a premium inside a smart card, smart card system software is much more tightly coupled than typical operating system software, so these programming rules are much more complex than most assembly language programmers are used to.
Not only is allowing third-party and end-user software onto the smart card platform a recent innovation, there are still members of the smart card community who think this is a terrible idea and shouldnt be permitted at all. Beyond simply protecting their business interests, these people worry most about the creation of counterfeit cards. A counterfeit card is a card that looks like a real card to a terminal but isnt a real card. Imagine, for example, a card that could convince a candy machine that it was a valid VisaCash or Mondex card and cause the machine to vend a candy bar without actually debiting a VisaCash or Mondex purse.
Historically, the possibility of counterfeit cards has been controlled by limiting access to information about smart cards, controlling who can put software onto a smart card, and carefully reviewing all smart card software before it is released for public use. Of late, it has become obvious that if the smart card computing platform is to flourish, it needs applications and this means thousands, not tens, of application program developers. These application programmers need access to information about smart card systems and access to the smart card processor.
To their great credit, the big issuers of smart cards dont practice security through obscurity. Visa, for example, makes the specifications for its Chip Card Payment Service and Secure Electronic Transaction protocol available on its Web site to encourage application programmers to develop applications that use these systems. This policy has the beneficial side effect of enabling the whole world to study and comment on the security of these systems. Not only have both systems been improved through this process, but trust in the use of the systems has also been strengthened.
On the other hand, there are certainly smart card systems out there built on wholly unwarranted assumptions about the cards that will be stuck into the systems terminals. These systems can and probably will be compromised by counterfeit cards created by unethical smart card programmers. The best response is better system design, better education, and better law enforcement, instead of securing the candy machine by hiding it in a closet.
Previous | Table of Contents | Next |