WO2001016865A1 - Systeme et procede d'installation/desinstallation d'une application sur une carte a puce - Google Patents

Systeme et procede d'installation/desinstallation d'une application sur une carte a puce Download PDF

Info

Publication number
WO2001016865A1
WO2001016865A1 PCT/US2000/000082 US0000082W WO0116865A1 WO 2001016865 A1 WO2001016865 A1 WO 2001016865A1 US 0000082 W US0000082 W US 0000082W WO 0116865 A1 WO0116865 A1 WO 0116865A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
memory
smart card
data object
read
Prior art date
Application number
PCT/US2000/000082
Other languages
English (en)
Other versions
WO2001016865A8 (fr
Inventor
Todd Carper
David Hemmo
An Van Le
Original Assignee
Cryptec Systems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/386,288 external-priority patent/US6390374B1/en
Application filed by Cryptec Systems, Inc. filed Critical Cryptec Systems, Inc.
Publication of WO2001016865A1 publication Critical patent/WO2001016865A1/fr
Publication of WO2001016865A8 publication Critical patent/WO2001016865A8/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G06K19/077—Constructional details, e.g. mounting of circuits in the carrier
    • G06K19/07716—Constructional details, e.g. mounting of circuits in the carrier the record carrier comprising means for customization, e.g. being arranged for personalization in batch
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the present invention relates to the field of portable tokens such as smart cards. More particularly, the present invention relates to a smart card capable of dynamically installing or de-installing one or more applications. Installation/de-installation may be done in the field through a terminal, or through an un-secure source such as the Internet.
  • 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.
  • smart cards 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, a smart card is able to interact with a greater variety of terminals across a broader range of transactions. In this broader range of transactions, the smart card is able to communicate more information regarding the cardholder, cardholder account, transaction authorization, etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • RAM Random Access Memory
  • ROM Read Only Memory
  • EEPROM Electrically Erasable Programable Read Only Memory
  • 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.
  • Terminal broadly indicates any device exchanging information with a smart card using any type or number of data transfer means.
  • a computer, ATM, merchant point-of-sale device, telephone, or security control device, are present examples of terminals.
  • a broad class of terminals nominally include 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.
  • RST reset
  • the smart card After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal.
  • ATR answer-to-reset
  • ISO International Standards Organization
  • the ATR is a multi-byte signal communicating 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.
  • a smart card may, at least in theory, be designed to use a number of different application programs.
  • an inability to readily develop and operate applications from a variety of sources has limited the type and number of applications placed on the conventional smart card.
  • 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 programming and implementation perspectives, a conventional first generation smart cards is little more than an embedded application.
  • 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.
  • 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.
  • 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. Because conventional first generation smart cards store their embedded application in ROM, there is no real opportunity to significantly change or modify the application once smart cards are fielded. This presents a real problem to smart card issuers, since operating/programming errors and oversights, collectively and generically called "bugs," are continually identified following release of any smart card application. Historically, severe bugs may only be remedied by physically replacing smart cards in the field with cards having an improved version of the application. Card issuers and users generally learn to live with less severe bugs.
  • EEPROM Electrically erasable programmable read-only memory
  • the EEPROM address thus allows subsequent programming steps to be grafted into the existing application stored in ROM.
  • the issuer identifies an error in the application in relation to the creation of data object D.
  • the conventional filtering approach would first create an "incorrect" D according to the ROM based application steps, and thereafter delete the incorrect data object D, and then re-create it using the EEPROM based application steps identified in the filtering instructions.
  • a true operating system does not execute commands received from the outside world.
  • a true operating system will not (is unable to) execute commands received from a terminal.
  • an operating system serves as a conduit and router for commands communicated from a terminal to an application stored on the smart card.
  • an operating system serves as a conduit through which an application utilizes the hardware resources.
  • 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.
  • 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.
  • 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.
  • an inte ⁇ reter 33 can be thought of residing between application 30 and hardware resources 32, as shown in Fig 3B.
  • an application running on a second generation smart card gains access to the hardware resources only through the inte ⁇ reter which converts a command into one or more microprocessor instructions.
  • the inte ⁇ reter 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.
  • the definition of commands by the inte ⁇ reter which promotes programming efficiency and standardization, necessarily restricts programing flexibility, since an inte ⁇ reter will never define the entire range of commands theoretically made possible by an unrestricted combination of the microprocessor instructions.
  • programming flexibility is traded away for programming ease and standardization.
  • the use of an inte ⁇ reter also slows program execution since commands must be converted into microprocessor instructions before execution.
  • Such functional inabilities attributable to the inte ⁇ reter 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 inte ⁇ reter.
  • both the application and the inte ⁇ reter of second generation smart cards are stored in ROM.
  • the process of correcting bugs is thus complicated by the possibility of fixing code in one or both of the inte ⁇ reter and the application.
  • Even where modification or upgrading to a fielded smart card application can be accommodated in the conventional smart card the physical process of reprogramming must be performed in a "trusted" device. That is, a terminal controlled by the smart card issuer must used to reprogram the smart card application in order to ensure code integrity. This is true because conventional smart cards, in and of themselves, do not have the processing capability or sophistication to verify new programming code.
  • conventional smart cards merely store security keys which are exported to the trusted machine during the security routine used to authenticate the new code.
  • the trusted machine not the smart card, performs the security routine.
  • Such a process requires that the smart card export proprietary security keys. Once exported, the smart card loses control over the keys, thereby creating a number of additional opportunities for hackers to breach the card's security.
  • the present invention provides a system and method by which one or more applications may be securely installed on a smart card. Additionally, the present invention provides a system and method by which one or more applications may be securely de- installed from a smart card. The capabilities of a true operating system running on the smart card are used to facilitate the install and de-install operations.
  • the present invention allows a clear definition to be drawn between manufacture of the smart card and it's programming.
  • a method of manufacturing a smart card is provided, where the smart card comprises a microprocessor and a memory, the memory comprising ROM and read/write memory.
  • the method comprises storing at least a portion of an operating system (OS) in ROM, storing at least a boot application in ROM, and following complete manufacture of the smart card, providing the smart card to an issuer without material data stored in read/write memory.
  • the material data comprises either a file structure or a security key.
  • the present invention provides a method of initializing a smart card.
  • the method comprises; powering the smart card via a terminal, determining whether the smart card has ever previously been powered, and upon determining that the smart card has never previously been powered, performing an first- power initialization routine.
  • OS operating system
  • the first-power initialization routine comprises initializing the read write memory, locating the application in ROM, and installing the application in read/write memory.
  • the application may comprise a boot application allowing insertion of a new data object into read/write memory, and a call to a download manager in the OS.
  • an initialization routine may be performed which comprises building a memory management record, and sending an Answer-To-Reset (ATR) signal to the terminal.
  • the initialization routine might further comprise; determining whether a transaction record is present in memory, and upon determining that a transaction record is present in memory calling a transaction manager, and by operation of the transaction manager, clearing the transaction record.
  • the smart card before performing either the smart card may send a first portion of the ATR signal to the terminal, and wherein the step of sending the ATR signal to the terminal following the step of building the memory management record comprises sending a second portion of the ATR signal to the terminal.
  • the ROM-based boot application is installed upon first-power initialization and used to download a new application data object which is ultimately converted to a new application.
  • the boot application will return a command table when installed, the commands in the table allowing for the download of the new application data object and calling of a download manager.
  • the download manager When called the download manager will in turn call the new application data object.
  • the new application data object will creating a command table for the new application which is stored in read/write memory.
  • the boot application may perform a security verification routine on the new application data object.
  • the present invention provides a method of downloading a second application from a terminal into a smart card memory, the memory storing an operating system (OS) and a first application, the method comprising; calling the first application from the terminal, by operation of the first application, inserting a new application data object in memory, and converting the new application data object into the second application.
  • the first application may verify the authenticity of the new application data object using a digital signature, for example.
  • the step of converting the new application data object into the second application comprises; calling a download manager in the OS, calling the second application from the download manager, and generating a command table for the second application.
  • Command tables and other persistent data records within the context of the present invention may be stored and accessed in a file directory using an efficient data record structure using OS based file manager.
  • the present invention provides a method of de-installing an application on a smart card, the smart card comprising a microprocessor and a memory, the memory storing an operating system (OS) and the application, the method comprising; deleting all data objects associated with the application, and deleting all data record associated with the application.
  • step of deleting all data objects associated with the application, and deleting all data record associated with the application comprises; beginning with a 1 st data object associated with the application and continuing through the N" 1 data object associated with the application, for each data object, deleting the data object by operation of the application, and calling the file manager, and by operation of the file manager, deleting the data record associated with the data object.
  • the method may thereafter delete the application data record from memory, and by operation of the memory manager reallocate memory space associated with the application as being available.
  • 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 is a flowchart illustrating a portion of an exemplary start-up routine including a first initialization routine and an initialization routine;
  • Fig. 5 is a flowchart illustrating a portion of an exemplary start-up routine including an ATR return
  • Fig. 6 is a flowchart illustrating an exemplary routine by which a new application is downloaded
  • Fig. 7 is a flowchart illustrating and exemplary routine to accomplish an install event, within the download routine of Fig. 6;
  • Fig. 8 illustrates an exemplary structure for a data record used within the present invention
  • Fig. 9 conceptually illustrates a portion of read/write memory to further describe an install event
  • Fig. 10 is a flowchart illustrating an exemplary routine by which a new application is de-installed.
  • SIMs and SAMs are physically "cut-down" versions of the classic smart card, and are used with telephones and other spaces smaller than that typically provided by larger terminals.
  • SIMs and SAMs are physically "cut-down" versions of the classic smart card, and are used with telephones and other spaces smaller than that typically provided by larger terminals.
  • SIMs and SAMs are physically "cut-down" versions of the classic smart card, and are used with telephones and other spaces smaller than that typically provided by larger terminals.
  • the size, shape, nature, and composition of the material encapsulating or mounting the microprocessor and memory element are not relevant or limiting to the present invention.
  • the term “smart card” should be broadly read as encompassing any self-contained combination of microprocessor and memory element capable of performing a transaction with another device, generally referred to as a terminal.
  • issuer denotes the party responsible for at least one application on the smart card. That is, the issuer is the party ultimately responsible for the development, implementation, security, and/or utility of an application running on the smart card.
  • the manufacturer and the issuer may be the same party, but are more likely than not different commercial entities.
  • An issuer may sell or distribute smart cards directly or through various middlemen until they reach the ultimate customer, the "user.”
  • the present invention avoids these problems by providing a smart card which may be delivered from the manufacturer to an issuer without any data stored in read/write memory.
  • the issuer may thus completely define an application without sharing proprietary information with the manufacturer.
  • the present invention accomplishes this result by providing a smart card having a true operating system (OS), as defined above.
  • OS operating system
  • the OS is said to implement or define a number of functions.
  • functions 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.
  • an OS function is defined by a collection or sequence of instructions.
  • an OS function might consist of only a single microprocessor instruction, or an OS function might be nothing more than a particular variable definition.
  • the term function(s), as used throughout should be construed as something having relation to or a definition within the OS.
  • the OS is used in conjunction with an Application Programing Interface (API) and/or a Hardware Application Layer (HAL).
  • API Application Programing Interface
  • HAL Hardware Application Layer
  • the API further defines, or indexes, the OS functions, or more preferably a subset of the OS functions.
  • the API forms a library of favorite, or most commonly used functions callable by applications on the smart card.
  • the API is "glue" between the applications and OS.
  • 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 inte ⁇ reter, 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.
  • command is used throughout to denote a data or control transaction between a terminal and a smart card application, or between one application and another.
  • the OS can not execute a command. Rather, the OS facilitates transmission of the command from a terminal (or another application) to 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.
  • 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 conventional first generation smart card would require a significant rewrite of the application. Further, since the 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.
  • Second generation smart cards can not implement the new function because the existing inte ⁇ reter does not define it.
  • a new version of the inte ⁇ reter must be written and downloaded onto each card. Since second generation smart cards store the inte ⁇ reter in ROM, and generally lack a mechanism to perform field downloads, particularly in relation to an inte ⁇ reter, such cards must be physically replaced in the field in order to provide customers with the upgraded version of application X.
  • the option of having an upgraded application X bypass the OS to directly execute the new function in the microprocessor is particularly profound.
  • the party owning and/or administering application X may not be the same party owning the OS, and or the smart card.
  • the owner of application X may lack the ability or authorization to amend the OS.
  • 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.
  • application X may be upgraded in the field to inco ⁇ orate 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 and the 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.
  • the OS might be upgraded to define the new function, and thereafter the API might be amended to index the new function.
  • the process by which, in another aspect, the present invention amends, or replaces ROM-based programs such as the OS, API, and HAL or ROM based applications is referred to as "patching.” Patching is described in a commonly assigned application filed August 31, 1999 having U.S.
  • 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 programs will be 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 change.
  • the smart card memory must store at least a "boot" application. That is, because a true OS is unable to execute any command received from a terminal, some application must be resident on the smart card to receive an execute at least one beginning command. Assuming a conventional relationship in which a manufacturer is asked to mask an application(s) into ROM, and define read/write memory in relation to the application s), a smart card according to the present invention operates normally, as explained below. However, the present invention provides much more.
  • a minimal smart card which when physically produced and delivered to the issuer for programming, includes the typical hardware resources, i.e., a microprocessor and a memory.
  • the memory will store the OS and the boot application in ROM.
  • Read/write memory typically an EEPROM
  • the OS defines a plurality of functions including a "download manager.”
  • the download manager is a piece of code which is capable of taking a data object stored in memory and converting it into a working application on the smart card.
  • the data object thus converted is called an "application data object" to distinguish it from other types of data objects stored in memory.
  • the download manager often cooperates with a file manager and a memory manager. These two managers, as presently preferred, are described in a commonly assigned application filed August 31, 1999 having U.S. Application No. 386,286 and entitled Smart Card Memory Management System and Method.” The subject matter of this application is inco ⁇ orated herein by reference.
  • the boot application stored in ROM must be capable of executing at least two commands, or their equivalent: (1) inserting a data object in read write memory, and (2) calling the download manager. This statement is particularly true for the current example of a minimal smart card delivered to the issuer without anything loaded in read/write memory. In other words, the boot application accomplishes at least one task - downloading a second application. This second application may have any form, and may even be a new or more sophisticated boot application. Before performing this task, however, the boot application must, like all other applications running on a smart card according to the present invention, must be "installed.” Before explaining the install routine, an exemplary start-up routine will be described. This start-up routine, which may include many other features and functions not described here, will be explained with reference to the flowchart shown in Fig. 4.
  • the first-power initialization routine is a specialized version of the initialization routine which is run one time following manufacture of the smart card.
  • the first-power initialization routine may be run at the manufacturer's facility, at the issuer's facility, or at a terminal in the field when the smart card is first used. Both the first-power initialization routine and the initialization routine are preferably part of the OS, but may be included as part of one or more smart card applications.
  • the first-power initialization routine comprises; defining the smart card starting environment (41), locating an application in memory (42), and installing the application (43).
  • the definition of the smart card starting environment will very from card to card, but as presently preferred will at least establish a portion of read/write memory for storing global data objects, define a file directory in read/write memory, and initialize other variable, data, and file structures in memory.
  • defining the smart card starting environment creates a place for subsequently installed application to live.
  • the boot application stored in ROM is located (42), and installed (43). This is the case in the present example which assumes that the only application stored in ROM is the boot application.
  • the present invention is also applicable to smart cards storing multiple applications in memory (i.e., ROM and/or read/write memory). Any application stored in memory might be installed during the first power initialization routine, but as explained above, an ability within the smart card to download additional applications requires that the application, whatever it other characteristics and wherever it is stored, be able to execute commands inserting a data object and calling the download manager.
  • the smart card ends the first power initialization routine and begins the initialization routine.
  • the initialization routine may vary from card to card and from issuer to issuer, but as presently preferred the initialization routine comprises at least; building a memory management record (44), clearing a pending transaction, if any, (45), and sending an ATR to the terminal indicating that the smart card is ready begin a transaction (46).
  • a preferred routine by which the memory management record is built is described in the commonly assigned application referenced and inco ⁇ orated above entitled "Smart Card Memory
  • the conventional ATR signal comprises multiple bytes of data.
  • the present invention uses this fact, to avoid "timing-out" during the Reset signal/ ATR exchange routine between a terminal and a smart card. For example, looking a Fig. 5, upon receiving power and a reset signal, the smart card begins a start-up routine (51). Soon after beginning the start-up routine, the smart card returns one or more bytes of the ATR signal (52) to essentially hold the terminal while completing the start-up routine (53). Once the start-up routine is complete, the smart card sends the remaining portion of the ATR signal (54) before entering an I/O loop, or performing some other function. As described above, the smart card must install an application as part of the first- power initialization routine.
  • Installed applications may have many forms, and may perform many tasks.
  • an installed application might be completely new to the smart card, or it might be an upgrade to an existing application.
  • a new application might be persistent in the smart card until de-installed, or might be a one-use application which runs once and de-installs itself immediately thereafter.
  • the upgrade process simply downloads and installs the upgrade application, and deletes the existing application.
  • the upgrade application might overwrite all or some of the existing application in read/write memory.
  • patching As noted above, where an application is written in ROM, wholly or in part, the process of upgrading, replacing, or amended such ROM-based applications is referred to as patching. Thus, as used herein, the concept of a "patch" has meaning with regard to ROM-based code.
  • Applications, the OS, and API are ready examples of typical ROM- based programs which may be patched. Patches are typically one-use applications which create read/write memory-based code. Once established patch code is viewed as just another type of application which, in turn, may be upgraded or replaced by a "new application.”
  • the term "application” as used herein it not limited to just self-contained programs, but encompasses pieces of code which form part of a present, future, or existing application, whether such application is stored in ROM or in read/write memory.
  • an existing application is called (61).
  • the term "existing application” is used to denote any responsive piece of code on the smart card.
  • An existing application may be stored in ROM or in read/write memory. It may be a boot application or any other type of application.
  • the existing application then receives a command to insert a "new data object" (62). Once the new data object is stored in read/write memory, the existing application receives a command to make a "new application" (63).
  • the process of making a new application from the new data object may include an authentication routine (64). Once the new data object has been authenticated, the existing application calls the download manager (65). The download manager operates on the new data object to create the new application. This routine is referred to as an "install event" (66), and will be described in more detail below.
  • the "call" to the existing application, and/or the commands to download the new data object and make the new application may come from a terminal, another application running on the smart card, or the OS.
  • the new data object is authenticated by the existing application before the download manager is called to perform the install event.
  • the OS may provide the resource necessary to install a new application
  • the existing application maintains the security mechanisms by which creation of the new application is allowed. This is an important feature in a system which allows multiple applications from multiple vendors to be run on the same smart card using a common operating system. Each issuer thus retains complete security control over the downloading of upgrade and replacement applications.
  • the security mechanism need not be left to the OS and/or shared with the smart card manufacturer.
  • this ability to authenticate new programming code "on card” allows a smart card according to the present invention to be updated, or to have a new application added in the field through a non-secure transmission medium like the Internet.
  • conventional smart cards can only facilitate upgrades, if at all, on trusted machines.
  • the new data object need not be immediately installed. Rather, it may be left inertly residing in read/write memory until needed, if ever.
  • a rarely used but marketable option to an application might be stored in read/write memory as a data object, without the overhead of a fully installed application segment, until required, if ever, by a user. Once needed, it may be installed and run as part of the application.
  • the install event described above is further described in relation to the flowchart shown in Fig. 7.
  • the install event is controlled by the download manager, which is preferably part of the OS.
  • the download manager When called by an application, or within the OS, to create a new application the download manager is always called in relation to a new data object, i.e., a data object stored in memory but not yet formed into a new application.
  • the download manager may be forced to relocate the new data object in read/write memory (71) prior to making the new application.
  • the new data object is called by the download manager (72).
  • the new data object is really a new application data object as compared with other types of data objects stored in memory.
  • the new application data object will return a command table (73).
  • the download manager will call the file manager (74) which will define within the file directory a data record associated with the command table (75). Having previously established a data record in the file directory for the new application data object, this data record must be updated by cooperation of the download manager and the file manager to reflect the conversion of the new application data object into a new application (76).
  • the command table may have various structures or be implemented in any number of different algorithms.
  • the command table serves to identify every command executable by the new application.
  • the smart card OS When a command is received in the OS via an I O loop, for example, the smart card OS will seek to identify an application "owning" the command, i.e., an application able to execute the command. This is done by reference to the one or more command tables stored in memory. Like all persistent data objects and files in memory, each command table must be referenced in a file directory.
  • the new application may create any number of additional data objects associated with the new application.
  • additional data objects may be data, variables, files, records, sub-applications or anything else required by the new application. Any additional data object intended to be persistent in memory will have an associated data record stored in the file directory.
  • Fig. 8 shows an exemplary structure for a data record.
  • each data record in the file directory is stored with a known structure or format.
  • a command table data record will have the same basic structure as all other data records in the file directory.
  • Data records within a file directory may be distinguished, for example, by their type field.
  • use of a standard data record structure provides notable benefits. As one of ordinary skill will understand, the exact nature, size, and characteristics of this "standard" data record structure can be left to the individual programmer. The explanation which follows is merely a presently preferred example.
  • the type field and the label field are user definable. That is, an application's programmer may use these data record fields for any pu ⁇ ose whatsoever.
  • the download manager, file manager, memory manager, and the OS in general, do not demand that these fields be defined. They are merely variable data fields associated with a data record.
  • the type field might indicate that the associated data object is an application, a command table, a file, or some other type data object.
  • the label field might indicate the access type for the data record.
  • the ID field identifies the data record within the file system administered by the OS.
  • the ownership field includes ownership information.
  • the ownership field of the data record contains the unique ownership byte previously described. Only the OS may access and define the ID and ownership fields in each data record.
  • the data field and the data length field are related within each data record.
  • the data length field specifies the size of the data field. In the preferred embodiment, the data field is allocated 4 bytes, it's maximum data size. Thus, if the data length field indicates that the data is 4 bytes or less in size, then the data field stores the actual data associated with the data record. If, however, the data length field indicates that the data field is greater than 4 bytes in size, the data field stores a 4-byte data pointer indicating the beginning address, elsewhere in read/write memory at which the actual data may be found.
  • An example of an install event will now be described with reference to Fig. 9. A new application data object 90 has already been stored in read/write memory 99.
  • the new application data object When called by the download manager, the new application data object returns at least a command table 92 which is stored in read/write memory.
  • a command table data record 95 is created in the file directory 98.
  • Other data objects, A and B may also be created in read/write memory as part of the install event. If such optional data objects are intended to be persistent with read/write memory, each must define a corresponding data record in the file directory.
  • the new application data object data record indicated ownership by the "existing application.”
  • the existing application the boot application in the minimal smart card example
  • the download manager the new application data object at that time.
  • the ownership field for the new application data record indicates ownership by the OS. That is, henceforth, the OS "own” the new application and deal with it as with all other previously installed applications.
  • the type field which once indicated a "data” type for the new application data object, is changed to an "application” type once the new application has been installed. With its data record properly defined in the file directory and having a defined command table, the new application is ready to receive commands from the OS I/O loop, for example.
  • Smart Card Memory Management System and Method discloses a system and method for reallocating read write memory space.
  • a presently preferred method for de-installing an application on a smart card will be explained with reference to the flowchart shown in Fig. 10.
  • the illustrated de-install event begins when the smart card receives a de-install application command in the OS from a terminal (101).
  • the OS locates the application "owning" this command (102).
  • a de-install event may arise from operation of an application on the smart card. That is, during operation, a first application may require de-installation of a second application or even de-installation of itself.
  • the application executing the de-install event calls the download manager (103).
  • the download manager calls the application to be de-installed (104).
  • the application executing the de-install event may de-install itself or de-install some other application.
  • the ability of a first application to delete a second application requires the first (executing) application to "own" the second (de-installed) application. Such ownership is readily indicated by the ownership field of associated data record for the second application, for example.
  • the application to be deleted first deletes all associated data objects (105).
  • the process of deleting data objects typically includes removing the data record associated each data object from the file directory. Again, all associated data objects may be readily recognized in memory by scanning through the file directory searching for data records having particular ownership field information.
  • the file manager is called (106). The file manager will then delete the file directory entry for the data record associated with the de-installed application (107).
  • the memory manager is called (108), and memory space once allocated to the now de-installed application is reallocated as being "available" (109).
  • the present invention provides a system and method for securely downloading new applications and existing application upgrades.
  • a true smart card operating system is the only efficient way to accomplish secure implementation and operation of multiple applications from different vendors on a single card. Further, as smart cards begin to accept multiple applications from different vendors, the card's ability to install and deinstall applications must operate without impacting the smart card operating system or other existing applications. Since there are relatively few smart card manufacturers which provide cards for all issuers, each smart card issuer will require a system which allows them complete control over the programming of the card.
  • the present invention has been described using several examples. The context needed to explain the download manager, initialization routine and install/de-install events includes some assumptions regarding data record use and storage, data record structure, data object organization in memory, and the type of memory commonly used. These contextual aspects are used to effectively explain the broader inventive concepts of the present invention. However, the present invention is not limited to the disclosed examples and teaching context. Rather the present invention is defined by the attached claims.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Stored Programmes (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Abstract

L'invention concerne une série de sous-programmes d'intérêt (51, 53) qui permettent l'installation solide d'une application sur une carte à puce (10) ou autre jeton portable et sa désinstallation. On utilise les possibilités d'un vrai système de fonctionnement installé sur une carte à puce pour faciliter l'installation/la désinstallation (104, 107).
PCT/US2000/000082 1999-08-31 2000-01-05 Systeme et procede d'installation/desinstallation d'une application sur une carte a puce WO2001016865A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/386,288 US6390374B1 (en) 1999-01-15 1999-08-31 System and method for installing/de-installing an application on a smart card
US09/386,288 1999-08-31

Publications (2)

Publication Number Publication Date
WO2001016865A1 true WO2001016865A1 (fr) 2001-03-08
WO2001016865A8 WO2001016865A8 (fr) 2001-04-12

Family

ID=23524971

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/000082 WO2001016865A1 (fr) 1999-08-31 2000-01-05 Systeme et procede d'installation/desinstallation d'une application sur une carte a puce

Country Status (1)

Country Link
WO (1) WO2001016865A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032244A1 (fr) * 2001-10-10 2003-04-17 Schlumberger Systemes Gestion de transmission des multiplets dans une carte intelligente
EP1365362A1 (fr) * 2002-05-15 2003-11-26 Omega Electronics S.A. Système d'identification electronique sans contact
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
US9607189B2 (en) 2015-01-14 2017-03-28 Tactilis Sdn Bhd Smart card system comprising a card and a carrier
US10037528B2 (en) 2015-01-14 2018-07-31 Tactilis Sdn Bhd Biometric device utilizing finger sequence for authentication
US10395227B2 (en) 2015-01-14 2019-08-27 Tactilis Pte. Limited System and method for reconciling electronic transaction records for enhanced security

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4727244A (en) * 1985-07-16 1988-02-23 Casio Computer Co., Ltd. IC card system
US5070233A (en) * 1988-06-24 1991-12-03 Oki Electric Industry Co., Ltd. Ic card reader/writer and ic card transactions processing apparatus capable of producing various frequency clock pulses
US5310999A (en) * 1992-07-02 1994-05-10 At&T Bell Laboratories Secure toll collection system for moving vehicles

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4727244A (en) * 1985-07-16 1988-02-23 Casio Computer Co., Ltd. IC card system
US5070233A (en) * 1988-06-24 1991-12-03 Oki Electric Industry Co., Ltd. Ic card reader/writer and ic card transactions processing apparatus capable of producing various frequency clock pulses
US5310999A (en) * 1992-07-02 1994-05-10 At&T Bell Laboratories Secure toll collection system for moving vehicles

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
WO2003032244A1 (fr) * 2001-10-10 2003-04-17 Schlumberger Systemes Gestion de transmission des multiplets dans une carte intelligente
CN100423025C (zh) * 2001-10-10 2008-10-01 雅斯拓股份有限公司 智能卡中字节传输的管理
EP1365362A1 (fr) * 2002-05-15 2003-11-26 Omega Electronics S.A. Système d'identification electronique sans contact
US9607189B2 (en) 2015-01-14 2017-03-28 Tactilis Sdn Bhd Smart card system comprising a card and a carrier
US10037528B2 (en) 2015-01-14 2018-07-31 Tactilis Sdn Bhd Biometric device utilizing finger sequence for authentication
US10147091B2 (en) 2015-01-14 2018-12-04 Tactilis Sdn Bhd Smart card systems and methods utilizing multiple ATR messages
US10223555B2 (en) 2015-01-14 2019-03-05 Tactilis Pte. Limited Smart card systems comprising a card and a carrier
US10229408B2 (en) 2015-01-14 2019-03-12 Tactilis Pte. Limited System and method for selectively initiating biometric authentication for enhanced security of access control transactions
US10275768B2 (en) 2015-01-14 2019-04-30 Tactilis Pte. Limited System and method for selectively initiating biometric authentication for enhanced security of financial transactions
US10395227B2 (en) 2015-01-14 2019-08-27 Tactilis Pte. Limited System and method for reconciling electronic transaction records for enhanced security

Also Published As

Publication number Publication date
WO2001016865A8 (fr) 2001-04-12

Similar Documents

Publication Publication Date Title
US6390374B1 (en) System and method for installing/de-installing an application on a smart card
US6338435B1 (en) Smart card patch manager
US6256690B1 (en) System and method for facilitating multiple applications on a smart card
US6808111B2 (en) Terminal software architecture for use with smart cards
US5901303A (en) Smart cards, systems using smart cards and methods of operating said cards in systems
Chen Java card technology for smart cards: architecture and programmer's guide
US9400668B2 (en) Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US6402028B1 (en) Integrated production of smart cards
EP1272983B1 (fr) Production integree de cartes a puce
US20040123152A1 (en) Uniform framework for security tokens
US6357665B1 (en) Configuration of IC card
US20050188360A1 (en) Method and apparatus for providing an application on a smart card
US20050184164A1 (en) Method and apparatus for installing an application onto a smart card
WO1998052153A2 (fr) Carte a circuit integre avec fonction interpreteur
US20040123138A1 (en) Uniform security token authentication, authorization and accounting framework
WO1997050063A2 (fr) Systeme portable sûr de gestion transactionnelle destine a des unites programmables intelligentes
WO2001016865A1 (fr) Systeme et procede d'installation/desinstallation d'une application sur une carte a puce
JP4742469B2 (ja) 複数のｏｓを用いるｉｃカード、ｉｃカード処理装置および処理方法
WO2001016873A1 (fr) Gestionnaire de correcteur de carte a puce
WO2001016707A1 (fr) Système d'exploitation de cartes à puce doté d'interfaces
KR100588408B1 (ko) 스마트 카드 저장 정보 자동 삭제 방법 및 시스템
EP3926504B1 (fr) Masquage et démasquage d'instances d'applet de carte java
KR200315677Y1 (ko) 운영체계를 기반으로 하는 신용카드 단말기
Jean et al. Using some database principles to improve cooperation in multi-application smart cards
RU2673394C2 (ru) Способ установки приложения на защищенный элемент

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): SG

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

AK Designated states

Kind code of ref document: C1

Designated state(s): SG

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i

Free format text: PAT. BUL. 10/2001 UNDER (51) REPLACE THE EXISTING SYMBOLS BY "G06K 7/00, 5/00, 19/06"

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)