LaMeH@CkeR

Smartcard operating systems history

?€?The smart card’s Chip Operating System (frequently referred to simply as COS; and sometimes referred to as the Mask) is a sequence of instructions, permanently embedded in the ROM of the smart card. Like the familiar PC DOS or Windows Operating System, COS instructions are not dependent on any particular application, but are frequently used by most applications?€[2].

The history of the smart card operating systems is closely related to the evolution of the smart card chips (ICC), they were designed for. In the mid of the 1980?€™s [3], a typical smart card had 6 Kbytes of ROM, 128 bytes of RAM and 3 Kbytes of EEPROM. Thus programs written in low level language were constructed directly upon the hardware (ICC) of the smart card. This was the main reason why these functions were typically included into libraries, to prevent programmers from writing every application from the beginning. During the years more functions were added to these libraries that were of course optimized to the properties of a specific micro-controller each time. This library orientated approach is known as the first generation of smart card operating systems [3]. The libraries containing the functions were burned into the ROM in order to provide the basic functionality to the smart card operating system, so the libraries remained the same until the card termination.

Multi-application operating systems

The need of the market for open and global standardization, but also for higher compatibility, modularity and hardware independency led to further evolution of the smart card operating systems, the so called third generation chip operating systems. The demand for more resources in third generation operating systems also helped to evolve chip capabilities (e.g. increase computing power).

In third generation operating systems the concept of modular layered architecture was introduced. The goals of layered operating systems are modularity and portability. In the layered approach the whole functionality of the hardware (meaning the ICC) is not used directly but encapsulated by a layer located directly above the physical layer. This layer provides a well specified hardware independent interface to the above lying layers (HAL) [3]; dynamic application loading now became easy since less information is needed to describe the technical features of the card.

In third generation operating systems two software technologies prevailed, the multi-function operating systems (GeldKarte, Chipper, MFC) and multi-application operating systems. Multi-function systems allow multiple applications to run on the same software platform, but without the guarantee that the applications will not interfere with one another. Multi-function platforms that are based on platform specific executable code are referred to as MFC platforms [1]. No application isolation is achieved in this model. A multi-application operating system allows multiple applications to run on the same software platform, but with the guarantee that applications do not interfere with one another.

Application independence or waterproofing can be achieved with two ways:

1. Interpreter: The application code is compiled into a byte code file and afterwards it converts to a more appropriate format so as to be executed by the proprietary platform. The interpreter is now responsible to verify the application code in order to eliminate the risk of letting the application to perform maliciously.

2. Memory manager: The memory manager checks each memory address to see if the application performs prohibited memory reading, with the use of boundary registers. The term bound registers refers to the registers that are used are limits.

Monolithic versus Multi-application platforms

Monolithic-application platforms are burned into ROM during the smart card fabrication stage, the operating system along with the vendor application are masked all together. Monolithic platforms are not flexible, do not support more than one application, and are hard to maintain.

Multi-application platforms now days have prevailed for obvious such as platform portability, software modularity, application isolation and hardware independency this are the key characteristics for multi-application platforms success.

The smartcard multi-application platforms

The most attractive feature in a multi-application platform is the dynamic application management. The term dynamic application management refers to the ability of the platform to allow the controlling authority of the card to update the card once it is in the field [1]. To be more specific when using the term dynamic application management, we mean the execution, locking, unlocking, and deleting of card applications software remotely in a well formed and secure manner. Because of this feature lots of security issues arise, such

1.WfSC

In the summer of 1998, Microsoft has launched a new business unit promoting a chip card OS, named ?€?Windows for Smart Cards?€™ (WFSC) [1]. The operating system is masked put into ROM during the fabrication stage of the SC while the applications are also masked into the ROM or loaded into the EEPROM. Dynamic application management is available in the WFSC platform. The issuer has to define his own security mechanisms for the card management. The availability of the complete version 1.0 specification is imminent. Only a part of the version 1.0 specification is available [1]. As application development tools the existing Visual Basic software development kit will can be used there id going also some support for C API?€™s.

2.Multos

MULTOS is a secure operating system which has been specifically designed for SC systems [1]. MULTOS platform makes use of the MEL VM along with the operating system. Dynamic application management is also available in MULTOS platform. Waterproofing between the applications is guaranteed by the kernel. This means that the applications do not need to be certified. Current implementations of MULTOS platform use an 8 bit CPU along with a cryptographic co-processor (in order to perform RSA calculations). The memory requirements are 4K for the Virtual Machine, 7K for the executive and 7K for the libraries. (including EMV functionality) 7K.

3.Java-card

Java Card is an operating system also designed for SC systems. A software implementation of the Java Card VM on an 8 bit CPU yields about 3000 instructions per second [1]. This has an impact on application execution speed (Java Card applications are much slower than C applications). The Java Card VM is based on an open specification, which is controlled by SUN Microsystems (Open Platform). Java Card applications do not need to be certified since the VM guarantees waterproofing between applications (through the use of Java card sand box model). More details about the Java Card platform will follow in the next chapter.

Refrences:

[1]

Peter Johannes, Chip Programme ?€“ MAOS Platforms, 10 April 2000, date retrieved: 22-06-2005
URL: http://www.multos.com/library/pdf/00-04-10%20Europay-maos-report.pdf

[2]

Jacquinot Consulting, Inc, What is the COS?, July 20 2005, date retrieved: 30-07-2005
URL: http://www.cardwerk.com/smartcards/smartcard_operatingsystems.aspx

[3]

Felix Pletzer, Architecture of a portable Smart Card Operating System, 17-May-2004, date retrieved: 19-07-2005
URL:http://www.iaik.tu-graz.ac.at/teaching/10_seminare-projekte/01_Telematik%20Bakkalaureat/Seminararbeit_Pletzer.pdf