New security issues raised by open cards

Abstract

The methods, languages and tools for developing a smart card system share some characteristics with those of the embedded domain. Until recently, smart card programs were written in hand coded native assembly language. All programs (drivers, operating system, libraries, applications) were developed as a monolithic piece of code burned in the smart card ROM. Therefore, not only are traditional card systems difficult to develop (low-level programming language, very reduced-feature microcontroller, specific code for every microprocessor) but they also cannot support any evolution of their applications since all the application code is burned forever with the runtime engine in the ROM. Moreover, the production of such a monolithic program dedicated to a specific hardware and with ad hoc functions for the application domain consumes most of the card development cycle. In order to issue a card application, it is required (i) to write precise specifications, (ii) to write or re-write the basic software (akin to an operating system) for possibly multiple platforms, (iii) to develop specific functions for the application, and (iv) to verify this software prior to deploying it on thousands or millions of cards. This process is timeconsuming and costly. Since defining specifications for products that will be available long after is risky, this process has been inadequate for the creation of new markets. As it requires a long time it also severely limits the ability of a card issuer to quickly deploy new applications in accordance with the market needs.