An operating system enables smart cards in performing data processing functions such as basic arithmetic operations, encryption etc. A non volatile memory in the smart card stores an operating system. The operating system found on the majority of smart cards implements a standard set of commands (usually 20 - 30) to which the smart card responds. Smart card standards such as ISO 7816 and CEN 726 8 describe a range of commands that smart cards can implement. Most smart card manufacturers offer cards with operating systems that implement some or all of these standard commands (and possibly extensions and additions). The relationship between the smart card reader and the smart card is a master/slave relationship. The reader sends a command to the smart card, the card executes the command and returns the result (if any) to the reader and waits for another command.
Similar 'smart' technology is also available in other forms such as Universal Serial Bus (USB) tokens and smart buttons. Both these technologies have similar usage and provide similar programming technologies as smart cards. Smart buttons are battery operated and are contact based. They need a separate reader to function. On the other hand, USB tokens can be plugged into the PC USB ports directly.
Get your grade
or your money back
using our Essay Writing Service!
Since the choice of software technology and operating system will have tremendous impact on the usage and success of smart cards in the health care system, the author wishes to explore this topic in detail. In this chapter, we will first look at some of the features that are essential in a secure smart card operating system and then visit popular smart card operating systems with a special focus on Java Card.
3.8 Java Card Smart Card Operating Systems
Java Card technology allows Java based applications to run securely on smart cards. Multiple applications from different vendors can run on smart cards that employ Java Card technology. Applications based on Java can be installed on the smart cards even after the cards have been issued to the user. Java Card technology is designed to be compatible with preexisting smart card standards.
A smart card device supporting Java Card technology typically will have 8-bit to 32-bit CPU running at 3.7 MHz, a 1 Kilobyte of RAM and 32 Kilobyte of non-volatile, read only memory or more. Smart cards that are high performing might also include an separate cryptographic chip and processor, and encryption memory.
3.8.1 Java Card Platform Specification
The Java Card Platform Specification, currently in version 3.0.1, consists of 3 parts:
Java Card Virtual Machine (VM) Specification, includes the Java Card Virtual Machine instruction set and the file formats necessary to install libraries and applets into smart cards that are enabled with Java Card technology
Java Card Runtime Environment (RE) Specification, which further defines the behavior of the virtual machine during the runtime. The RE includes implementation of the virtual machine, API and
Java Card API Specification, which complements the RE by defining the core framework and extension Java packages and classes for smart-card applications. It includes class definitions.
A Java Card Development Kit (JCDK) is also available, which includes a reference implementation of the Java Card Virtual Machine and also Java Card Run Time, and other tools to support the development of applets using Java Card.
18.104.22.168 Java Card Application Elements
Figure 1Java Card Architecture
An application built on the Java Card platform is a secure and complete application containing the following components: backend application and systems, reader-side host application, reader-side card acceptance device and the card-side applets and environment. The detailed description of each of these elements is given below:
22.214.171.124 The Back-End Application and Systems
The services provided by the back-end applications support Java applets present in the card. For example, the back end application in case of an electronic payment system might provide access to debit card information.
126.96.36.199 The Reader-Side Host Application
The reader-side host application might reside in a computer, mobile phone, payment terminal, or a one of the security subsystems. The communication between the user, the Java Card applet, and the back-end application of the provider are handled by the host application.
Host-applications have been traditionally written in C language. The explosion in the use of Java language has resulted in the adoption of Java 2 Micro Edition (J2ME) for writing host applications for mobile devices.
Always on Time
Marked to Standard
Smart card vendors also provide APIs along with the development kit. These APIs support Java card applet and reader side applications. The Open Card Framework is one such API.
188.8.131.52 The Reader-Side Card Acceptance Device
Between the host application and the Java card device sits an interface device, Card Acceptance Device (CAD). The CAD supplies power to the card and also supports the card in communicating. CAD comes in a variety of forms: as a card reader attached to a computer or integrated into terminals such as the ones we see at London tube stations. CAD sends APDU commands from host application to card and relays the response back in the opposite direction. Some CADs have an integrated keyboard and screen.
184.108.40.206 The Card-Side Applets and Environment
As indicated in the figure above, the card might have one or more Java Card applets and supporting software - operating system and the run time - with it. The Java Card Runtime Environment (JCRE) consists of JCVM, Java Card Framework and APIs. It might also contain some useful extension APIs.
3.8.2 Communicating with Smart Card
Message passing model and the Java Card Remote Method Invocation (JCRMI) are two communication models available for communication between host applications and Java Card applets. Security and Trust Services API (SATSA), based on the Generic Connection Framework (GCF) API, lets one use either if the models to access the card.
220.127.116.11 The Message-Passing Model
All Java Card communications are based on the Messaging Passing Model. The message passing model is centered around the Application Protocol Data Unit (APDU). APDU is the logical data packet that is exchanged between the Java Card Framework and the CAD. The Java Card Framework receives and sends APDU commands to the appropriate applet. The apple processes the APDU and sends a response APDU. APDUs are conformant with ISO/IEC 7816-3 and 7816-4 standards. Communication between the reader and the card are generally based on one of the two protocols: byte oriented T=0 and block-oriented T=1.
Regardless of the operating system used and the intended application, all smart cards use the APDU messaging. Therefore APDU messaging is discussed in detail below. APDU command has two parts: header and body. Header is mandatory, whereas the body is optional.
Table 1APDU Command
CLA (Length: 1 byte): It might have one of the following values shown below Table 3.1.
ISO 7816-4 card instructions, such as for file access and security operations
20 to 0x7F
0x8n or 0x9n
ISO/IEC 7816-4 format you can use for your application-specific instructions, interpreting 'X' according to the standard
Application- or vendor-specific instructions
B0 to CF
ISO/IEC 7816-4 format you can use for application-specific instructions
D0 to FE
Application- or vendor-specific instructions
Reserved for protocol type selection
Table 3. 1 Possible CLA Values
INS (Length: 1 byte, Required Field): This field indicates a specific instruction within the instruction class identified by the CLA field. The ISO 7816-4 standard specifies the basic instructions to use for access to data on the card when it's structured according to an on-card file system as defined in the standard. Additional functions have been specified elsewhere in the standard, some of which are security functions. Table 3.2 below for a list of some of the ISO 7816 instructions. You can define your own application-specific INS values only when using an appropriate CLA byte value, according to the standard.
Table 3. 2 Possible INS values
P1 (Length: 1 byte, Required Field) and P2 (Length: 1 byte, Required Field): Theses field defines instruction parameter 1 and parameter 2 respectively. These fields can be used in qualifying the INS field or for transmitting input data.
This Essay is
a Student's Work
This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.Examples of our work
Lc (Length: 1 byte, Optional Field): This field is used to indicate the length of the data field in bytes.
Data field (Length: Variable, Optional Field): This field holds the command data and can be of variable length. The length of this field will be defined in the LC field mentioned above.
Le (Length: 1 byte, Optional Field): This field is sued to specify the maximum length of the data field (in bytes) of the response APDU
There are 4 variations to the command APDU depending on the command data and whether a response is required. These variations are important to the consideration of the developer only if byte-oriented T=0 protocol is used.
Figure 3. 1 possible variations of APDU command
18.104.22.168 The Response APDU
The response APDU has two parts: body and trailer. The body part is optional whereas the trailer is mandatory. The table below illustrates the parts of a response APDU
Table 3.3, Response APDU
Data field: This optional field of variable length. Any data returned by the applet is contained in this field.
SW1 (1 byte): This byte is the status word 1.Both the SW bytes are required.
SW2 (1 byte): This byte is the status word 1
The values of the status words (SW1 and SW2) are defined by ISO7816 standard.
22.214.171.124 The Processing APDU
Whenever, a APDU is to be sent to a selected applet, the APDU is sent to the applet as an argument via process() method call by JCRE. The applet accepts the APDU, processes it, generates a response and then returns the control back to JCRE. JCRE provides many classes and methods to help developers in creating applets. Both JCRE and the Java Card API are based on the ISO 7816 standard for smart cards. When a smart card is inserted into a CAD, it sends commands to a selected applet on the card. CAD can also send APDUs. Applets are identified by their Application Identifier (AID). Applets respond to the commands by sending out a status word (SW). In some case, they also send additional other data.
3.8.3 Java Card VM45
The Java Card Virtual Machine (JCVM) has two implementation parts: one part which is running on the card and another which is external to the card. The on-card part of the JCVM interprets the bytecodes, massages objects etc. The other part, external to the card, is used for development. It is commonly as a referred to as the Java Card Converter tool. It loads Java classes, verifies and prepares them for an execution on the card. The output given out by the converter tool is called a Converted Applet (CAP) file. A CAP file is an binary executable containing Java classes. The converter also verifies classes to make sure that they conform to the Java Card specification.
Though JCVM supports only a subset of the Java programming language, it retains many important features of the Java language including packages, objects, inheritance virtual methods etc. Given the memory constraints of a smart card device, the JCVM specification does not include many features.
3.8.4 Java Card API 44,46
The Java Card API does not include support for strings or for multi threading. It does not also include wrapper classes like Integer, and other classes like Class or System. The Java Card API supports only a subset of features and capabilities of Java. It includes a set of core classes for supporting Java Card applications. These core classes are present in the following packages: java.io, java.lang, java.rmi and javacard.framework. These packages do not include many classes and methods that are present in the traditional Java specification. javacard.framework package includes the specification which makes up the core Java Card Framework (JCF). It has definitions for Java Card applet (Applet), Personal Identification Number (PIN), Java Card System (JCSystem), Application Protocol Data Unit (APDU) and a utility class. Various ISO7816 constants and exceptions specific to Java Card are also defined in this package.
3.8.5 Java Card Runtime
The Java Card Runtime Environment (JCRE) includes the definition for the entire life cycle of the Java Card Virtual Machine (JCVM) and the applet cycle. It also defines applet selection and isolation, object sharing and object persistence. The run time provides an interface for all the services provided by the operating system. The run time interface is platform independent and this great flexibility in terms of development and interoperability. The run time specification includes JCVM, API and other extensions specific to the vendor. The figure illustrates the architecture and the runtime environment.
126.96.36.199 Applet Life-Cycle
Each applet in a card is uniquely identified by an Application ID (AID). According to the, ISO 7816-5 standard, AID is a sequences of 5 - 16 bytes of information. All applets will extend the Applet abstract case. The Applet class defines methods used by the run time to control the life cycle of applets. The applet is first downloaded into the card. The run time then invokes the Applet.install() static method in the downloaded applet and starts the applet lifecycle. The applet registers itself with the run time by invoking Applet.register() method. After the registration, applet is available for selection and APDU processing.
Figure 3. 2 Applet method operation
188.8.131.52 The Java Card Sessions and Logical Channels
A session of a smart card is the time duration when the card is powered on and it is actively exchanging APDUs with the reader. Java Card allows 16 applications to run simultaneously in a smart card through a concept called logical channels. Every session is allocated to one logical channel. Once the processing of an APDU starts, it cannot be interrupted. Each APDU contains reference to a logical channel. Applets can be designed to communicate with more than one logical at once. Such applets are called multiselectable.
Some card deployments have a default applet which will be automatically invoked after card reset. This is used for communicating on channel 0 or the base communication channel. Java Card allows the implementers to define their own default applets, but the implementation mechanism is not defined, it is vendor specific.
184.108.40.206 Applet Isolation and Object Sharing
Java Card platform allows applets from multiple vendors to coexist on the same card. Every applet is assigned to a context, which control the objects the applet has access to. The boundary between execution contexts is called an applet firewall. The applet firewall is an enhancement over the Java security sandbox concept. It is a combination of the class loader and access controller functionalities. The firewall allows objects to access only those methods and data that are within the same firewall. Objects can also be shared across firewalls securely. When a new object is created it is assigned the execution context of the calling object. A Java Card execution currently has a package scope.
3.8.6 Other Smart Card Operating system
Though Java Card is the predominant operating system for smart cards, it is not the only competitive operating system available for smart cards. MULTOS and Smartcard.NET are two other important operating systems for smart cards. A brief introduction to both these operating systems is provided in the next section.
220.127.116.11 MULTOS Operating system47
Applications for MULTOS operating system are written in C language. The programs written, regardless of the programming language used, are compiled into MULTOS Executable Language (MEL), which is language specific to MULTOS. It is based on Reduced Instruction Set Computer or RISC. One of the very important features of MULTOS is its robust security. It is rigorously and independently evaluated to ensure that MULTOS issuers, application programmers and providers of other MULTOS services can develop their offerings without elaborate considerations for security. MULTOS silicon providers have an obligation to undergo a rigorous evaluation and thorough testing process to interoperability, security and tamper resistance. This obligation is imposed by the MULTOS license. One of the recent developments with regards to MULTOS is the availability of a Java compiler for MULTOS programs.
MULTOS comes with a special card called the MULTOS application developer's card, which provides a simple and standard way of creating, deleting and loading certificates. MULTOS operating systems provides a platform independent way, similar to Java Card, to develop and deploy applications. The chips commonly used in the cards are developed mainly by two manufacturers - Infineon and Hitachi. MULTOS' platform independent nature ensures that applications built for Hitachi chips can run on Infineon chips and vice-a-versa.
Smartcard.NET is another important smart card operating system. It was developed by Microsoft Corporation and is built on Microsoft's .NET framework. It supports a variety of programming languages including C#, VB.NET etc. The system supports multithreading and makes use of virtual machine on the lines of Java. TCP/ IP protocol is used to establish communication in Smartcard.NET. Smartcard.NET can run is a system supporting a 32-bit processor, 16 Kilobytes of RAM and 512 Kilobytes of ROM.
3.8.7 Selection Criteria of Smart Card Operating system
In the above sections, we have presented a detailed discussion of the Java Card platform and discussed briefly the other two mainstream operating systems - MULTOS and Smartcard.NET. The selection of the operating system is critical to the functioning of the smart card system and thereby, critical to the success of health care initiatives employing smart cards. As smart cards operating systems are preloaded into the cards, the selection of the smart card operating system as an important bearing on the procurement of smart cards. The criteria for selection of an operating system for smart cards are given below:
The operating system shall support application interoperability between different vendors and platforms.
Operating system shall use APDU protocol for communication with the host application. APDU is cross platform and cross vendor communication protocol.
The operating system should have multiple providers. It is an important strategic criterion as the operating system will drive the selection of the card manufacturer. Having multiple manufacturers will ensure the continuity in availability of smart cards supporting the selected operating system.
The operating system of choice should support encryption algorithms and should be secure.
To reduce cost, it is important for a single smart card to allow installation of multiple applications. Therefore, the operating system of choice should allow applications from different vendors to be installed on a single car.
The operating systems should be backward compatible.
The operating system of choice should support multitasking. Different applications running on a smart card can exchange data and eliminate storage of redundant data. This frees up memory and also leads to better performance.
Operating systems should support biometric standards. This is very essential as biometric identification methods might be considered.
It is also preferable to choose an operating system that supports multiple programming languages. Support for multiple programming languages gives freedom to the developer to choose an appropriate programming language based on the requirements.