WO2001016707A1

WO2001016707A1 - Smart card operating system with interfaces

Info

Publication number: WO2001016707A1
Application number: PCT/US2000/000078
Authority: WO
Inventors: Todd Carper
Original assignee: Cryptec Systems, Inc.
Priority date: 1999-08-31
Filing date: 2000-01-05
Publication date: 2001-03-08

Abstract

A portable token, such as a smart card, is disclosed as having a true operating system (44). The operating system may include an Application Programming Interface (42) indexing a plurality of OS functions, or a Hardware Abstraction Layer (50) defining an interface between the OS and the hardward resources (46) of the smart card.

Description

Smart Card Operating System with Interfaces

FIELD OF THE INVENTION The present invention relates to the field of portable tokens, such as smart cards. More particularly, the present invention relates to a smart card having a true operating system (OS). The OS may be used in conjunction with an application programming interface (API) indexing a set of common OS functions, and/or a hardware abstraction layer (HAL) defining an interface between the OS and the smart card microprocessor.

BACKGROUND OF THE INVENTION Most consumers are familiar with credit cards, debit cards, and automatic teller machine (ATM) cards. Such cards are increasingly used to access, transfer and spend money. The back of these cards includes a magnetic strip storing encoded information about the cardholder and the account(s) accessible by the card. Terminals, including ATMs and merchant "point-of-sale" terminals, read the encoded information from the card and access the cardholder's account to complete a transaction. Besides the well-known credit and debit cards, stored value cards are becoming increasingly popular. Stored value cards are purchased or issued with a specific monetary value. When the cardholder desires to use the stored value card to purchase goods or services, the card is presented at the point of sale and the cost of the goods or services is deducted from the value of the card. The cardholder may continue to use the stored value card in this manner until all the value has been removed from the card. The card may then be discarded, or its value may be replenished. Such cards are commonly used to pay subway fares or to make long distance phone calls.

For many types of transactions, however, the current trend is away from credit/debit cards and stored value cards, and into a class of devices generally called smart cards. Rather than employing information encoded on a magnetic strip, smart cards include a microprocessor and a memory element embedded within a credit card size device. With a microprocessor, smart cards are able to interact with terminals across a broader range of transactions, and are able to communicate a broader, and a more detailed range of information regarding the cardholder, a cardholder account, transaction authorization, or other information.

The term "smart card" is used throughout as a convenient name for a broad class of devices sometimes referred to as portable tokens. Smart cards are the most common present form of portable tokens, but as will be seen hereafter the actual physical form of the portable token, as well as the specific means by which the portable token communicates data to the outside world are not the subject of the present invention.

Smart cards have been used in various applications for some time. Fig 1 shows an exemplary smart card 10. Roughly the size of a credit card, smart card 10 includes a microprocessor 12 with an integral memory element, and conductive contacts 13. Microprocessor 12 is typically a single wafer integrated circuit mounted on, or embedded within the otherwise plastic smart card. Conductive contacts 13 interface with a terminal to electrically transfer data between the terminal and the smart card. Other embodiments of the smart card do not include conductive contacts 13. Such "contactless" smart cards receive information via proximately coupling, such as magnetic coupling, or via remote coupling, such as radio communication.

The microprocessor 12 and conductive contacts 13 of Fig 1, are shown in some additional detail in Fig 2. Conductive contacts variously include power contacts, at least one input/output (I/O) port, a reset port, and a clock (elk) signal port. Microprocessor 12 comprises a central processing unit (CPU) 21 which is generically control logic including I/O circuitry 23. Terminal signals variously interface with CPU 21 through the conductive contacts 13 and I/O circuitry 23. Microprocessor 12 is associated with a memory element 20. The memory may be formed on the same integrated circuit as the microprocessor, or may be formed on a separate device. Generally, the memory includes Random Access Memory (RAM) 22, Read Only Memory (ROM) 24, and Read/Write memory, such as an Electrically Erasable Programable Read Only Memory (EEPROM) 26. However, some or all of these presently -used memory elements may be replaced by battery backed-up RAM, flash memory, or other electronic data storage media.

Operating power, a user input keypad, and a display for the smart card microprocessor are typically provided by a terminal. The term "terminal" broadly indicates any device exchanging information with a smart card using any number of data transfer means. A computer, ATM, merchant point-of-sale device, or security control device, are present examples of terminals.

The terminal nominally includes a mechanism detecting the presence of a properly positioned smart card. Upon detecting the smart card, the terminal provides power to the microprocessor, and typically sends a reset (RST) signal to the smart card. The smart card uses the RST signal to reset itself, or to initiate an internal reset function. After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal. The ATR signal communicates basic information concerning the smart card to the terminal. Once such basic information is successfully recognized by the terminal, communication, i.e., data transfer, between the smart card and the terminal can be established. Smart cards can be programmed to operate as stored value cards, credit cards, debit cards, ATM cards, calling cards, personal identity cards, critical record storage devices, etc. In these varied capacities, a smart card may, at least in theory, be designed to use a number of different application programs. In actual practice, however, an inability to readily develop applications has limited the type and number of applications placed on the conventional smart card. In fact, most conventional smart cards include only a single application, or at most a single type of application.

This is not surprising when one considers that from a programming perspective, conventional first generation smart cards are little more than an embedded application. Looking at Fig 3A, such first generation cards can be viewed as an application 30 stored in memory which runs a set of microprocessor-specific instructions on hardware resources

32. The term "hardware resources" is used to generically indicate the memory and logic circuits, with their associated interfaces, used to execute microprocessor instructions but may also include I/O circuits, power circuits, and the other hardware. Given the structure shown in Fig 3 A, each application must be written in a very low level, or machine level language. This language is specific to the microprocessor on which the application is intended to run.

The first generation, embedded application programming model offers at least one significant advantage - programming flexibility. Microprocessors are typically able to execute a significant set of instructions. Since an embedded application is written at the machine level, the full range of the microprocessor's instructions set may be accessed and utilized by the application. Unfortunately, such programming flexibility comes at a high price. In order to run an existing application on a different microprocessor, it must often be completely rewritten. Debugging, updating, and testing of embedded applications are arduous. Further, machine level programming is difficult and requires a great deal of hardware specific expertise. Embedded programmers are, thus, hard to find and expensive to retain.

All of these factors combine to restrict the number and quality of smart card applications. Further, the hardware specific nature of the resulting applications contributes to the incompatibility problems which characterize conventional smart cards.

Such conventional smart cards do not employ a true operating system. Rather, a specific application written according to the microprocessor instruction set is stored in

ROM and executed in accordance with commands received from a terminal. MPCOS, VisaCash, GSM, and Proton are examples of such first generation embedded applications.

A true operating system does not execute commands received from the outside world. Thus, in the context of a smart card, a true operating system will not (is unable to) execute commands received from a terminal. Rather, an operating system serves as a conduit and router for commands communicated from a terminal to an application stored on the smart card. Additionally, an operating system serves as a conduit through which an application utilizes the hardware resources. In other words, an operating system provides I/O functions and provides other functionality to applications running on the OS. Since first generation smart cards store only the application code, and since this code must necessarily executes commands received from the terminal, first generation smart cards do not include an operating system.

In an attempt to overcome the difficulties, limitations and expense associated with the programing of first generation smart cards, second generation smart cards incorporate an interpreter. An interpreter can be thought of as a library of commands. JAVA and

BASIC are common interpreters. A set of commands is defined and identified in the interpreter, any one of which may be "called" by an application. The term "call" or "calling" is used throughout to broadly describe a relationship between two pieces of code in which one piece invokes the other. Commands, functions, definitions and instructions may be used by having one piece of code call another pieces of code. The foregoing pieces of code may reside within the an application or the OS.

-A- Conceptually, an interpreter 33 can be thought of residing between application 30 and hardware resources 32, as shown in Fig 3B. Thus, an application running on a second generation smart card gains access to the hardware resources only through the interpreter which converts a command into one or more microprocessor instructions. The interpreter effectively provides a higher level of abstraction and a programming language reflecting this level of abstraction with which a broader class of programmers may effectively write applications. However, the definition of commands by the interpreter, which promotes programming efficiency and standardization, necessarily restricts programing flexibility, since an interpreter will never define the entire range of commands theoretically made possible by an unrestricted combination of the microprocessor instructions. Thus, by use of an interpreter, programming flexibility is traded away for programming ease and standardization. The use of an interpreter also slows program execution since commands must be converted into microprocessor instructions before execution. Further, since conventional smart cards implement the file structure defined by

ISO-7816, part 4, the use of an interpreter come as an additional penalty to programming flexibility. That is, ISO-7816, part 4 already confines an application programmer to a certain command set used to define a standard file architecture. On top of this restriction, the interpreter further confines the programmer to another fixed set of commands. If a particular functionality is not defined by a command in the interpreter's library, the functionality can not be implemented within an application.

For example, if some new smart card application desired the function of outputting data to a printer, this function could not be implemented if the interpreter lacked the necessary command, such as a "PRINT" command associated with desktop computers. Such functional inabilities attributable to the interpreter are particularly exasperating where a sequence of microprocessor instructions might be designed to implement the desired "new" function, but where the programmer lacks access to the microprocessor instruction set because of the obligatory presence of the interpreter.

To date, smart cards have failed to realize much of their inherent potential. Such failure stems, at least in part, from the restricted nature of smart card applications, many of which are little more than custom, embedded applications. The use of a "standard" file architecture, such as ISO-7816, part 4, and the use of static interpreters aids in the development of smart card applications, but does so at the price of programming flexibility.

SUMMARY OF THE INVENTION The present invention eliminates the trade-off between programming flexibility and programming efficiency which characterizes the conventional smart card. Rather, the present invention allows smart card programmers to utilize the full range of microprocessor instructions, with the attendant advantages in execution speed and programming flexibility, while at the same time having available a sophisticated set of operating system (OS) defined functions. The OS functions may be further defined or indexed in an application programming interface (API).

Within the present invention, the API provides all the benefits of an interpreter without its limitations. Like an interpreter, the API indexes a set of commands.

Applications running on a smart card according to the present invention may use the API to call functions resident in the OS. However, unlike conventional interpreters, use of the API is not mandatory. Further, unlike conventional smart card interpreters, the API may be modified in the field. In a smart card system according to the present invention, application programming is no longer held hostage to the particular type of microprocessor being used. Applications need not be written in machine language, nor need they be written in different forms to run on different microprocessors. In fact, applications may be written with reference to only the API and/or to the OS. Analogous to the API's relationship between the applications and the OS, the present invention also provides a hardware abstraction layer (HAL) which defines an interface between the OS and the hardware resources of the smart card. The HAL allows abstraction of the OS away from a specific microprocessor.

Accordingly in one aspect, the present invention provides a smart card system receiving a command from a terminal, the system comprising: a microprocessor capable of executing N instructions, and a memory, an operating system (OS) stored in the memory and defining a set of M functions, wherein each one of the M functions comprises one or more of the N instructions, an application programming interface (API) stored in the memory and indexing a set Q of the M functions, where Q is less than or equal to M, and at least one application stored in the memory and capable of executing the command by calling a function in the set of Q functions through the API, calling a function in the set of M functions through the OS, and directly executing at least one of the N instructions on the microprocessor.

In another aspect, the present invention provides a smart card receiving N commands from a terminal, the smart card comprising; a microprocessor, and a memory storing an operating system (OS) defining a set of M functions, and storing first and second applications, wherein the first application executes at least one of the N commands by consistent call to the set of M functions through the OS, and wherein the second application directly executes at least one the N commands in the microprocessor without call to the OS. In another aspect, the present invention provides a method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application and an operating system (OS), the OS defining a plurality of functions, the method comprising; receiving a command, and if the command is defined in the application in terms of one or more functions in the plurality of functions, executing the command by call to the one or more functions through the OS, while if the command is defined in the application in terms of one or more instructions in the set of instructions, directly executing the command on the microprocessor without call to the OS.

In yet another aspect, the present invention provides a method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application, an operating system (OS) defining a plurality of functions, and a hardware abstraction layer (HAL) defining an interface between the OS and microprocessor. The method comprising; first receiving a command, and if the command is defined in the application in terms of one or more functions in the plurality of functions, then calling the one or more functions through the

OS, converting the one or more functions by operation of the HAL into one or more instructions, and executing the one or more instructions in the microprocessor. However, if the command is defined in the application in terms of one or more instructions in the set of instructions, then directly executing the one or more instruction in the microprocessor without call to the OS or operation of the HAL. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an exemplary smart card;

Fig. 2 shows the integrated circuit portion of the exemplary smart card of Fig 1 in some additional detail; Fig. 3 A illustrates the software/hardware relationship of a conventional, first generation smart card;

Fig. 3B illustrates the software/hardware relationship of a conventional, second generation smart card;

Fig. 4 illustrates the software/hardware relationship of a smart card according to one aspect of the present invention; and

Fig. 5 illustrates the software/hardware relationship of a smart card according to another aspect of the present invention.

DETAILED DESCRIPTION For purposes of illustration, one aspect of the present invention can be viewed as having a software/hardware relationship like that shown in Fig 4. Within this relationship, one or more applications 40 are stored in memory and are capable of running on a smart card either through an operating system (OS) 44 or directly on the hardware resources.

The smart card system may also include an application programming interface (API) 42 interposed between application(s) 40 and OS 44 which runs on hardware resources 46. For purposes of explanation, the OS is said to implement or define a number of "functions." As used in this capacity, the term "function(s)" should not be read as denoting only classic functionally programming operations, such as "MOVE," "STORE,"

"LOOP," etc., but should be read as including any operation, or data state definable within the OS. Further, within this document, the term "instruction s)" is used to indicate programming code which may be directly implemented or executed in the hardware resources without interpretation or processing by another piece of code, such an interpreter or an OS. Typically, an OS function is defined by a collection or sequence of instructions.

However, an OS function might consist of only a single microprocessor instruction, or an OS function might be nothing more than a particular variable definition. Thus, the term "function(s)," as used throughout, should be construed as something having relation to or a definition within the OS. When present, the API further defines, or indexes, the OS functions, or more preferably a subset of the OS functions. In effect, the API forms a library of favorite, or most commonly used functions callable by applications on the smart card. In the common vernacular of programmers, the API is "glue" between the application(s) 40 and OS 44. Thus, as a command is executed by an application, one or more OS functions may be called through the API. Conceptually, the API may be thought of as a vector table in which OS functions are immediately cross-referenced with an address in memory to the code implementing the function. Any application written for the smart card may make use of the API, but unlike the conventional smart card employing an interpreter, the application is not required to operate within the set of functions indexed within the API. The API, thus, provides an efficiency resource defining certain standard functions, without constraining an application to the use of only the standard functions. An API allows shared data objects to be defined which may be referenced by any application running on the smart card. The API index of functions provides a reference for programmers during development of an application. As such, standardization and consistency of use are obtained. Further, the API provides an additional level of programming abstraction above the OS. By consistent recourse to the API, applications programmers may literally ignore the specific nature of the hardware resources accessed through the OS, and may also ignore much of the OS. This level of abstraction allows applications to be written in terms a standard API which are able to run on literally any microprocessor. The term "command" is used throughout to denote a data transaction between a terminal and a smart card application. As described above, because a smart card according to the present invention uses a true OS, the OS can not execute a command. Rather, the OS facilitates transmission of the command from a terminal to the application. When executed in the application, the command may result in one or more calls to the OS for certain functions. One or more of these calls may be made through the API, or may be made directly to the OS for functions which are not indexed within the API.

However, such function calls from the application to the OS, whether through the API or not, are optional — not mandatory. Within the present invention, a smart card application may be stored in native form. That is, the application may, in whole or in part, be complied down to machine executable object code capable of running directly on the hardware resources of the smart card without any call to the OS.

The advantages of this option are profound. For example, assume in year one that a competent OS defining an adequate plurality of functions is commercially implemented on large number of smart cards. Further, assume a very popular application "X" runs on the smart cards using this OS.

Next, assume in year two that a bright smart card applications programmer determines to implement an entirely new function within application X. The new function may be readily implemented using the existing microprocessor instruction set, albeit in a previously unheard of sequence. Thus, the new function has not been defined within the OS.

In this situation, the conventional first generation smart card would require a significant rewrite of the application. Further, since first generation smart cards run on a fixed, embedded version of application X, all existing smart cards must be replaced with new cards in order to implement an upgraded version of the application X including the new function. Conventional second generation smart cards can not implement the new function because the existing inteφreter does not define it. Thus, in order to upgrade application X in second generation smart cards, a new version of the interpreter must be written and downloaded onto each card. Since second generation smart cards store the interpreter in ROM, and generally lack a mechanism to perform field downloads, particularly in relation to an interpreter, such cards must be physically replaced in the field in order to provide customers with the upgraded version of application X.

Of note, a system and method for field downloading code into a smart card, whether such code is an application, a patch, an upgrade, an operating system, an API and/or a general piece of code, are disclosed in a commonly assigned application filed August 31, 1999, having U.S. Application No. 09/386,288, and entitled "System and

Method for Installing/De-Installing an Application on a Smart Card." The subject matter of this application is incorporated herein by reference.

In the context of a smart card system in which code may be quickly and easily downloaded in the field, the option of having an upgraded application X bypass the OS to directly execute the new function in the microprocessor is particularly profound. For example, the party owning and/or administering application X may not be the same party owning the OS, and/or the smart card. Thus, the owner of application X may lack the ability or authorization to amend the OS. Similarly, the new function may be highly proprietary and as such the owner of application X may not wish to disclose the function to the OS or smart card provider.

In any event, application X may be upgraded in the field to incorporate code, which when directly executed on the microprocessor, provides the new function without call to the OS. Such limited amendment of application X leaves all other applications on the smart card and the smart card OS untouched. That is, the OS need not be modified to implement the new function. As a result, the relationship between the OS and all other applications stored on the smart card is not altered. Alternatively, the OS might be upgraded to define the new function, and thereafter the API might be amended to index the new function.

In one embodiment of the present invention, the OS and one or more applications are stored in ROM. Additional applications may be stored in Read/Write memory, but at least the initial bulk of the applications are stored in ROM. This embodiment is presently preferred on a cost basis, but it is recognized that as the performance characteristics and relative cost of various memory types, i.e., as between ROM, EEPROM, and their substitutes like Flash, change over time this preference may also change.

As explained in the above referenced and incorporated, co-pending patent application, the smart card application or applications stored in ROM must include or consist of at least a "boot-program" capable of downloading data and installing an application from a terminal. This minimal application requirement exists because the OS is a true OS, i.e., one incapable of directly executing a command received from the terminal. Thus, when a smart card according to the present invention receives a first terminal command via an I/O loop defined by the OS, the command must go somewhere for execution. Accordingly, some minimal boot-program application must exist to receive and execute the initial command. Otherwise, the OS would merely cycle in a loop looking for the command's owner. The use of a true OS eliminates the possibility of an OS "back- door" which may be misused by a smart card hacker.

In another embodiment of the present invention, only the minimal boot-program is stored in ROM with the OS. All other applications are stored in Read/Write memory.

Finally, in yet another embodiment of the present invention, the OS and applications are stored in Flash, with some portion of EEPROM being available for use within the smart card system.

Another aspect of the present invention is illustrated in Fig. 5. In Fig. 5, the applications 40, API 42, OS 44 and hardware resources 46 are as described above with reference to Fig. 4. Additionally, a Hardware Abstraction Layer (HAL) 50 has been added. Conceptually, the HAL may be thought of as being inteφosed between the OS and the hardware resources. In one sense, the OS interfaces with the hardware resources through the HAL in the same manner as applications interface with the OS through the API.

The HAL is typically written in assembly code and defines "how" a function is executed in the hardware resources. For example, the OS may indicate the function of "Get byte Z." In response to this function, the HAL will indicate one or more microprocessor instructions which define a statement saying, in effect, "On this particular microprocessor, the function 'get byte Z' is implemented by use of the following sequence of instructions." In so doing, the HAL may incoφorate a card management system provided by the microprocessor.

Use of the HAL allows the OS to abstract away from a specific type of hardware. In effect, the OS becomes less sensitive, and perhaps completely insensitive, to the hardware environment of the smart card. As the OS becomes more generic, programming efficiency increases. In fact, since the hardware environment becomes largely irrelevant to the OS as well as the applications, the HAL allows an OS as well as applications to be developed on a desktop computer. Such an ability dramatically facilitates the development of code.

In order to realize the true potential of smart cards, the primitive programming confines of the conventional smart card must be removed. The present invention provides a software/hardware relationship between the applications, operating system, and hardware resources of a smart card which facilitate efficient program development while maintaining programming flexibility. The addition of an application programming interface and/or a hardware abstraction layer allows increased abstraction of applications and the operating system, respectively.

In effect, the present invention creates within the field of smart cards a program development and execution environment more closely approximating that of the desktop computer. With these advances, an expanded set of programmers will be able to efficiently develop a broader range of competent smart card applications.

Claims

What is claimed:

1. A smart card system receiving a command from a terminal, the system comprising: a microprocessor capable of executing N instructions, and a memory; an operating system (OS) stored in the memory and defining a set of M functions, wherein each one of the M functions comprises one or more of the N instructions; an application programming interface (API) stored in the memory and indexing a set Q of the M functions, where Q is less than or equal to M; and at least one application stored in the memory and capable of executing the command by performing at least one act in a group of acts consisting of: calling a function in the set of Q functions through the API; calling a function in the set of M functions through the OS; and directly executing at least one of the N instructions on the microprocessor.

2. The smart card system of claim 1, wherein the memory comprises a Read-Only - Memory (ROM) and Read/ Write memory.

3. The smart card system of claim 2, wherein the OS, the API and the application are is stored in ROM.

4. The smart card system of claim 2, wherein the OS, the API, and a boot-program are stored in ROM, and wherein the application is stored in Read/Write memory. 5. The smart card system of claim 1, wherein the OS is incapable of executing the command.

6. A smart card receiving N commands from a terminal, the smart card comprising: a microprocessor capable of executing instructions; and a memory storing an application, and an operating system (OS), the OS defining a set of functions, wherein each function comprises one or more of the instructions; the application being capable of executing one or more of the N commands by calling through the OS at least one function in the set of functions, and by directly executing at least one of the instructions on the microprocessor. 7. The smart card of claim 6, wherein the OS is incapable of executing any one of the N commands received from the terminal.

8. The smart card of claim 7, wherein the application comprises at least a boot routine capable of receiving data from the terminal and downloading the data to the smart card memory.

9. The smart card of claim 7, the memory further storing an application program interface (API) indexing a subset of the functions, wherein the application executes the one or more of the N commands by calling at least one function in the subset of functions through the API.

10. The smart card of claim 7, wherein the OS controls the receipt of commands from the terminal. 12. A smart card receiving N commands from a terminal, the smart card comprising: a microprocessor; and a memory storing an operating system (OS) defining a set of M functions, and storing first and second applications; wherein the first application executes at least one of the N commands by consistent call to the set of M functions through the OS; and, wherein the second application directly executes at least one the N commands in the microprocessor without call to the OS.

13. The smart card of claim 12, wherein the memory stores an application programming interface (API) indexing a set Q of the M functions, where Q is less than or equal to M.

14. The smart card of claim 13, wherein a call to a function in the set of Q functions by the first and second applications is made through the API.

15. A method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application and an operating system (OS), the OS defining a plurality of functions, the method comprising: receiving a command; if the command is defined in the application in terms of one or more functions in the plurality of functions, executing the command by call to the one or more functions through the OS; and, if the command is defined in the application in terms of one or more instructions in the set of instructions, directly executing the command on the microprocessor without call to the OS.

16. The method of claim 15, wherein the command is received from a terminal by operation of the OS.

17. The method of claim 16, further comprising: communicating the command from the OS to the application.

18. The method of claim 17, further comprising: generating a response in the application following execution of the command; communicating the response from the application to the OS; and, transmitting the response from the smart card to the terminal.

19. The method of claim 15, wherein the smart card memory stores an application programming interface (API) indexing a subset of the plurality of functions.

20. The method of claim 19, wherein if the command is defined in the application in terms of one or more functions in the subset of the plurality of functions, executing the command by call to the one or more functions through the API.

21. A smart card receiving a command from a terminal and comprising: a microprocessor and a memory defining hardware resources; the memory storing an operating system (OS) defining N functions, an application executing the command, and a hardware abstraction layer (HAL) defining an interface between the OS and the hardware resources.

22. The smart card of claim 21, wherein the application executes the command by calling at least one of the N functions through the OS, and wherein the at least one of the N functions is converted by the HAL into one or more machine level instructions for execution in the microprocessor.

23. The smart card of claim 22, wherein the content of the application is not determined by any relation to the content of the HAL.

24. The smart card of claim 23, wherein the memory also stores an application programing interface (API) indexing M of the N functions, where M is less than or equal to N.

25. The smart card of claim 24, wherein the application executes the command by calling at least one of the M functions through the API.

26. The smart card of claim 21 wherein the HAL is written in assembly language.

27. A method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application, an operating system (OS) defining a plurality of functions, and a hardware abstraction layer (HAL) defining an interface between the OS and microprocessor, the method comprising:

(i) receiving a command; (iia) if the command is defined in the application in terms of one or more functions in the plurality of functions,

(iial) calling the one or more functions through the OS, (iia2) by operation of the HAL, converting the one or more functions into one or more instructions, and (ϋa3) executing the one or more instructions in the microprocessor;

(iib) if the command is defined in the application in terms of one or more instructions in the set of instructions, directly executing the one or more instruction in the microprocessor without call to the OS or operation of the HAL.