WO2001016874A1 - Gestionnaire de transactions de carte a puce - Google Patents

Gestionnaire de transactions de carte a puce Download PDF

Info

Publication number
WO2001016874A1
WO2001016874A1 PCT/US2000/000084 US0000084W WO0116874A1 WO 2001016874 A1 WO2001016874 A1 WO 2001016874A1 US 0000084 W US0000084 W US 0000084W WO 0116874 A1 WO0116874 A1 WO 0116874A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
data
smart card
record
memory
Prior art date
Application number
PCT/US2000/000084
Other languages
English (en)
Inventor
Todd Carper
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
Application filed by Cryptec Systems, Inc. filed Critical Cryptec Systems, Inc.
Publication of WO2001016874A1 publication Critical patent/WO2001016874A1/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
    • 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/082—Features insuring the integrity of the data on or in the card

Definitions

  • a method of securely performing a transaction on a smart card receiving a command from a terminal, wherein the command requires changing an original data object stored in smart card memory comprising: copying the original data object into a transaction record; and setting a transaction record indicator.
  • transaction record indicator comprises a global data object established in a reserve portion of EEPROM.
  • original data object comprises an original data record.
  • copying the original data object into the transaction record comprises creating a transaction data record in the file directory.
  • transaction data record identifies an address in memory at which a copy of the original data record is located.
  • the original data object comprises an original data record stored in a file directory in memory, and additional data associated with the original data record.
  • copying the original data object into the transaction record comprises creating a transaction data record in the file directory, wherein the transaction data record contains a field identifying at least one address in memory at which a copy of the original data record and a copy of the additional associated data are located.
  • a method of executing a transaction between a terminal and a smart card comprising a microprocessor and a memory, the memory storing an application and an operating system (OS), the OS comprising a transaction manager, and the method comprising: receiving a command in the OS from the terminal, wherein the command requires changing an original data object; communicating the command from the OS to the application; calling the transaction manager from the application; by operation of the transaction manager, copying the original data object into a transaction record; and setting a transaction record indicator in memory.
  • OS operating system
  • command comprises a series of commands received in the OS from the terminal and communicated to the application, wherein during the series of commands the application calls the transaction manager.
  • a method of activating a smart card comprising: upon receiving power from a terminal, beginning a start-up routine; as part of the start-up routine and before beginning an input/output routine by which an application stored on the smart card receives a command from the terminal, determining whether an uncompleted transaction remains pending in the smart card.
  • determining whether an uncompleted transaction remains pending in the smart card comprises interrogating a transaction record indicator stored in non- volatile memory.
  • the method further comprises: locating a transaction data record in memory; determining from the transaction data record an original data object which was the subject of the uncompleted transaction; and recreating the original data object from the transaction data record. 19. The method of claim 18, further comprising: after recreating the original data object, resetting the transaction record indicator, deleting the transaction data record, and completing the start-up routine.
  • completing the start-up routine comprises sending an answer-to-reset (ATR) signal from the smart card to the terminal.
  • ATR answer-to-reset
  • the start-up routine comprises sending a multiple byte answer-to-reset (ATR) signal from the smart card to the terminal.
  • the smart card upon receiving power from a terminal and beginning the start-up routine, the smart card sends part of the ATR signal to the terminal before determining whether an uncompleted transaction remains pending in the smart card.
  • the smart card comprises a memory storing the application and an operating system (OS), the OS performing the start-up routine and comprising a transaction manger, wherein the method further comprises: upon determining from the transaction record indicator, as part of the start-up routine that an uncompleted transaction remains pending in the smart card, calling the transaction manager; and by operation of the transaction manger, locating the transaction data record in memory; determining from the transaction data record the original data object which was the subject of the uncompleted transaction; recreating the original data object from the transaction data record; resetting the transaction record indicator; and
  • OS operating system
  • a method of changing an original data object in a smart card comprising a memory storing an application and an operating system (OS), the OS comprising a transaction manager, and the method comprising: calling the transaction manager from either the OS or the application; and by operation of the transaction manager, copying the original data object into a transaction record, and setting a transaction record indicator.
  • OS operating system
  • a method of activating a smart card to accomplish a transaction with a terminal comprising an non-volatile memory containing a file directory storing one or more data records and containing a transaction record indicator, the method comprising: upon receiving power in the smart card, interrogating the transaction record indicator; and upon determining in response to the interrogation of the transaction record indicator that a transaction record in stored in memory, interrogating the file directory to locate the transaction record.
  • each data record stored in the file directory comprises a type field, the type field indicating whether or not a data record is a transaction data record.
  • the present invention relates to the field of portable tokens, such as smart cards. More particularly, the present invention relates to a transaction manager preferably found in a smart card operating system which assures the integrity of data stored on the card.
  • Stored value cards are purchased from a vendor, or issued from a vending machine with a specific monetary value. When the card user desires 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 make phone calls. Many stored value cards resembled credit card. They have a plastic body with a magnetic strip on the back.
  • the magnetic strip When used in a transaction, the magnetic strip is read from and/or written to by an external device, generically referred to hereafter as a terminal.
  • an external device generically referred to hereafter as a terminal.
  • the magnetic strip encoding of data on stored value cards does not provide a high degree of data security. Furthermore, the magnetic strip offers little, if any, real processing capability beyond simply storing data.
  • smart cards include a microprocessor with a memory element embedded within a plastic card. With a microprocessor, smart cards are capable of interacting with a wide variety terminals to accomplish a broad range of transactions. Compared with conventional stored value cards, smart cards are able to communicate a broader and a more detailed range of information regarding the cardholder, the cardholder account(s), the card issuer, transaction authorization(s) and capabilities, 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 a 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 built-in microprocessor 12 with an integral memory element, and conductive contacts 13.
  • Microprocessor 12 is typically a single wafer integrated circuit (IC) 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 proximate ly 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 further comprises a memory element 20, typically including Random Access Memory (RAM) 22, Read Only Memory (ROM)
  • EEPROM Electrically Erasable Programable Read Only Memory
  • terminals I/O connection type
  • a terminal must 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 then resets, and/or initiates an internal initialization function. After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal.
  • RST reset
  • ATR answer-to-reset
  • the physical structure of smart cards is established by ISO- 7816.
  • ISO standard 7816 has largely led to uniformity in the physical construction and communication protocol of smart cards, the standard does not effectively specify an operating system or an application programming format.
  • conventional smart cards When functioning as stored value cards, conventional smart cards can be programmed and re-programmed to contain a particular value as desired by the cardholder.
  • a merchant terminal at a point of sale may be able to simply deduct value from the smart card, or the smart card may be designed to require the cardholder to input a personal identification number (PIN) before value is deducted from the card.
  • PIN personal identification number
  • a fraudulent user In one class of favored attack, generally referred to a "card yank," a fraudulent user, or “hacker” will monitor the memory state of a smart card during critical periods of a financial transaction in which data is being written to the smart card memory. Within such periods, the memory may, in whole or in part, transition through an undefined state. Once potential periods of undefined memory state are identified, the hacker terminates the transaction during these periods in an attempt to acquire an undefined, or
  • the undefined, or wrongly defined memory state may later be interrupted in a subsequent transaction as having a substantially higher value than that otherwise authorized had the "yanked" transaction run to completion.
  • the problem of smart card data integrity may arise in circumstances where a terminal fails during a transaction. Loss of power, or some other "glitch" within the terminal may result in an undefined memory state for a smart card in use during the terminal failure.
  • the undefined memory state may be interpreted in a subsequent transaction as having either a higher value, or a lower value than that properly assignable to the card. Either situation is unacceptable.
  • An example illustrating the problem of conventional smart card data integrity will now be presented with reference to Figs. 3A and 3B. In these examples, it is assumed that the smart card is being used as a stored value card.
  • EEPROM 30 When used as a stored value card, conventional smart cards typically used one of two approaches. In a first approach illustrated in Fig. 3 A, at least one block of EEPROM 30 is rewritten every time a new value is stored on the card.
  • the EEPROM used in conventional smart cards has a minimum data block size of 16 bytes. Thus, at least 16 bytes of EEPROM must be rewritten every time a new value is stored on the smart card. This may take up to 10 milliseconds.
  • the 16 byte EEPROM data block 30 of Fig. 3 A is nominally implemented in a number of memory cells (4 cells are indicated in Fig 3 A). Every value capable of being stored in this EEPROM data block will produce a unique array of data bits across the combined set of memory cells. Since each bit-storing element in the memory cell is nonvolatile, i.e., it remains persistent until changed, an opportunity exists to interrupt the process of rewriting the entire array of data bits, and thereby create an erroneous stored value.
  • -4- EEPROM data block conceptually illustrates the rewriting process.
  • a hacker is able to determine when the rewriting process is underway.
  • the data actually stored in the memory cell array will be a combination of the partially rewritten data and partially remaining "old," i.e., not-rewritten data.
  • This combination of data may be subsequently interrupted as having a value very different from the data originally stored on the smart card, or the new data which should have been stored on the smart card had the transaction run to completion. If the original value is very low, the hacker has potentially much to gain and very little to lose by repeatedly yanking a smart card.
  • the present invention ensures data integrity for smart card data objects changed during a transaction, or changed by operation of a smart card application or the OS.
  • the present invention provides a method of securely performing a smart card transaction upon receiving a command from a terminal, where the command requires change of an original data object stored in smart card memory.
  • the method comprises copying the original data object into a transaction record, and setting a transaction record indicator.
  • the method may also comprise, after setting the transaction record indicator, changing the original data object, and, after successfully changing the original data object, deleting the transaction record and resetting the transaction record indicator.
  • the transaction record indicator contemplated above may be a global data object established in a reserved portion of EEPROM.
  • the original data object may be a data record stored in a file directory established in EEPROM.
  • the method creates a transaction data record in the file directory, where the transaction data record may identify an address in memory at which a copy of the original data record is located.
  • the original data object may comprise an original data record stored in a file directory in memory, and additional data associated with the original data record.
  • the method when copying the original data object into the transaction record, creates a transaction data record in the file directory, wherein the transaction data record contains a field identifying at least one address in memory at which a copy of the original data record and a copy of the additional associated data are located.
  • the present invention provides a method of executing a transaction between a terminal and a smart card, the smart card comprising a microprocessor and a memory, the memory storing an application and an operating system (OS), the OS comprising a transaction manager.
  • the method comprises receiving a command in the OS from the terminal, wherein the command requires changing an original data object, communicating the command from the OS to the application, calling the transaction manager from the application, by operation of the transaction manager, copying the original data object into a transaction record, and setting a transaction record indicator in memory.
  • OS operating system
  • the method may also include, after setting the transaction record indicator, returning to the application and changing the original data object in accordance with the command, after successfully changing the original data object, calling the transaction manager, and by operation of the transaction manager, deleting the transaction record and resetting the transaction record indicator.
  • the command may comprise a series of commands received in the OS from the terminal and communicated to the application, wherein during the series of commands the application calls the transaction manager, such that the OS functions as a true OS, being incapable of executing any one of the series of commands received from the terminal.
  • the present invention provides a method of activating a smart card comprising; upon receiving power from a terminal, beginning a start-up routine, and as part of the start-up routine before beginning an input/output routine by which an application stored on the smart card receives a command from the terminal, determining whether an uncompleted transaction remains pending in the smart card.
  • the presence of an uncompleted transaction pending in the smart card may be determined by interrogating a transaction record indicator stored in non- volatile memory.
  • the method further comprises; locating a transaction data record in memory, determining from the transaction data record an original data object which was the subject of the uncompleted transaction, and recreating the original data object from the transaction data record. After recreating the original data object, the method may include resetting the transaction record indicator, deleting the transaction data record, and completing the start-up routine.
  • a method in which upon completing the start-up routine, an answer-to-reset (ATR) signal is sent from the smart card to the terminal. If the ATR signal includes multiple bytes, upon receiving power from a terminal and beginning the start-up routine, the smart card may send only a part of the ATR signal to the terminal before determining whether an uncompleted transaction remains pending in the smart card.
  • ATR answer-to-reset
  • the present invention provides a method for activating a smart card to accomplish a transaction with a terminal, the smart card comprising an nonvolatile memory containing a file directory storing one or more data records and containing a transaction record indicator, the method comprising; upon receiving power in the smart card, interrogating the transaction record indicator, and upon determining in response to the interrogation of the transaction record indicator that a transaction record in stored in memory, interrogating the file directory to locate the transaction record.
  • the data record(s) stored in the file directory may include a type field indicating whether or not a data record is a transaction data record.
  • Fig. 1 illustrates an exemplary smart card
  • Fig. 2 illustrates the integrated circuit portion of the exemplary smart card in some additional detail
  • Fig. 3 A and 3B conceptually illustrate a conventional stored value transaction on a smart card
  • Fig. 4 conceptually illustrates a smart card memory portion having data records and data objects adapted for use within the present invention
  • Fig. 5 conceptually illustrates a data record structure adapted for use with the present invention
  • Fig. 6 is a method flowchart generally illustrating the one aspect of the present invention.
  • Fig. 7 conceptually illustrates a smart card memory portion having data records and data objects accessed and manipulated by the method illustrated by the flowchart in Fig. 6;
  • Fig. 8 is a method flowchart generally illustrating another aspect of the present invention.
  • Fig. 9 is a method flowchart generally illustrating yet another aspect of the present invention.
  • reaction as used herein broadly describes any exchange of data between the smart card and a terminal, or between one application on the smart card and the OS or another application.
  • the present invention provides a mechanism by which the state of the smart card memory is rolled-back to a point where data integrity is assured following an interrupted transaction.
  • the program code implementing this mechanism is called a "transaction manager.”
  • the transaction manager may be located in one or more applications, but as presently preferred, the code capable of implementing the transaction manager is resident in the smart card operating system (OS).
  • the OS is preferably stored in ROM, but may be stored, wholly or in part in EEPROM.
  • the OS is a "true" OS in the sense that it does not execute any command received from a terminal. Rather, the OS provides an I/O routine by which commands are transferred from the terminal to an application running on the smart card, and provides a number of functions which may be called by any one of the smart card applications.
  • the transaction manger is one such OS function and may be called by any application or any other OS function running on the smart card.
  • calling is used throughout to broadly describe a relationship between two pieces of code in which one piece invokes the other.
  • the transaction manager may be called anytime a data record stored in memory is to be changed. Use of the transaction manager is permissive in many instances, but may be mandatory in others according to the protocols of the OS or application(s) being run.
  • the transaction manager protects the integrity of data records
  • the transaction manager ensures that once the smart card commits to a transaction, the card will either successfully create a new data record as a result of the completed transaction, or roll-back the "old" data record in the event that the transaction is interrupted.
  • some context is needed. While the context provided below illustrates the nature and operation of the transaction manager, the transaction manager is not limited to this specific context.
  • Fig. 4 illustrates the EEPROM portion of a smart card memory.
  • EEPROM is the most common form of Read/Write memory used in present portable tokens. However, the present invention contemplates any form of Read/Write memory, including flash memory, in place of the given example.
  • the EEPROM 40 of Fig. 4 comprises a set of global data objects 41. These global data objects may be defined by the smart card manufacturer, the smart card issuer, the smart card operating system, and/or one or more applications running on the smart card. Typically, a portion of EEPROM is reserved or set aside for the storage of global data objects 41.
  • the global data objects may include just about anything from a single bit flag to an entire application.
  • the transaction manager relies on a global data object called a global transaction (TRANS) indicator 43.
  • TRANS global transaction
  • the global transaction indicator is a single bit flag indicating whether or not a transaction data record (TRANS REC) is stored in memory.
  • the transaction indicator might be implemented as a data record in the file directory, provided sufficient security mechanisms are in place to assure the integrity of such a data record).
  • EEPROM 40 further comprises a file directory 44 containing one or more data records (0, 1, . . . , N-l, N). Each data record indicates a data object stored in memory. Like the global data objects, data objects stored in memory and indicated by a data record in file directory 44 may take just about any form.
  • the transaction data record of the present invention may be stored in a memory location defined within the global data objects, or in some other set-aside memory location in non- volatile memory. However, in one preferred embodiment of the present invention, the transaction data record is stored in file directory 44. Since each data record in the file directory is stored with a known structure or format, a transaction data record will have the
  • Data records within a file directory may be distinguished, for example, by their type field. While not required as part of the present invention, use of a standard data record structure provides notable benefits.
  • nonvolatile memory In order to properly reconstruct a memory management record for the smart card, every relevant file, record, data object, and application must be stored in nonvolatile memory in some form recognizable to a routine which constructs the memory management record. Only data stored in non- volatile memory survives a loss of power in the smart card. Accordingly, all data intended to be "persistent" must be stored in nonvolatile memory. (For purposes of this explanation, the non-volatile memory element is presumed to be an EEPROM. However, other types of non- volatile memory might be. used).
  • a data record structure is defined for all data stored in EEPROM which is intended to be persistent.
  • This data record structure is recognized by the OS and by applications, and is specifically recognized by a routine which creates the memory management record.
  • the exact nature, size, and characteristics of this "standard" data record structure can be left to the individual programmer. The example which follows is merely a presently preferred example.
  • a data record may be an application, a file, or any other type of persistent data.
  • an original data record 45 stored in file directory 44 may reference an actual data object 46 associated with original data record 45, but stored elsewhere in memory.
  • Fig. 5 illustrates a 16-byte data record structure comprising a 2-byte ID field, a 1-byte ownership field, a 1-byte type field, a 4-byte data field, a 2-byte data length field, and a 6-byte label field.
  • the type field and the label field are user definable. That is, an application's programmer may use these data record fields for any purpose whatsoever. The memory manager, and the OS in general, do not care what these fields contain. They are merely variable data fields associated with a data record.
  • the type field might indicate whether the data record is an application, a file, or some other type data object, like a transaction data record.
  • 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
  • the ownership field includes ownership information.
  • the present example the
  • -12- 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 EEPROM, at which the actual data may be found, for example, the actual data 46 shown in Fig. 4.
  • Some transactions will not require the services of a transaction manager. These transactions do not create or change a significant data record in the smart card, and as such do not require the security offered by use of the transaction manager.
  • the method illustrated by Fig 6 assumes a transaction 60 in which a significant data object is changed from one value to another, as in the case where the smart card is being used as a stored value card.
  • the application performing this transaction will call the transaction manager 61.
  • transaction manager creates a transaction data record 71 in file directory 44.
  • transaction data record 71 references a copy of original data object 45.
  • the copy is denoted by 45'.
  • transaction record 71 merely references a copy 45' of the original data object. See, 71 A in Fig. 7. If, however, original data object
  • transaction data record 71 references a copy of the original data record 45' and a copy of the actual data 46' associated with the original data record 45. See, 71B in Fig. 7.
  • transaction data record 71 references a copy of the original data record 45' and a copy of the actual data 46' associated with the original data record 45. See, 71B in Fig. 7.
  • the transaction manager sets a global transaction indicator in memory 63.
  • This indicator may be located anywhere in non-volatile memory, but as presently preferred is consistently stored at a memory location found in the space storing global data objects.
  • the global transaction indicator indicates that a transaction is pending and that a transaction record associated with the, as yet uncompleted transaction, is stored in memory.
  • the present invention is well adapted to securely administer a sequence of nested transactions. That is, the transaction manger may be called and effectively used to securely handle a second and subsequent transactions within the first and subsequent transactions. In order to accomplish this, the transaction manager is repeatedly called and a series of transaction records are created in the file directory.
  • the smart card start-up merely resolves each transaction record as it scrolls through the file directory, as explained in greater detail below.
  • the global transaction indicator may prioritize a nested sequence of transactions. Thus, upon re-powering the smart any unresolved transactions are cleared according to their creation priority, for example, last-created, first-cleared.
  • the application returns and continues the transaction 64.
  • the application Upon successfully completing the transaction 65, the application again calls the transaction manager 66, which deletes the transaction record 67, and resets the global transaction indicator 68.
  • the smart card is always aware of the presence of an uncompleted transaction. Accordingly, the smart may will not operate upon re-powering the smart card in a subsequent session with a terminal until all pending transaction have been cleared. In this manner, all "old" data is rolled back before a subsequent transaction session is begun.
  • Fig. 8. In the method illustrated by this flowchart, it is assumed that a smart card has just been activated within a terminal. As part of a start-up routine, the smart card OS determines whether an unresolved transaction is present 81. If an unresolved transaction is
  • the transaction record is located 82, the original data object, in whatever state it is presently found, is deleted 83, and then recreated using the transaction record 84.
  • the term "original” is used here to indicate the data object being modified when the transaction was interrupted.
  • the global transaction indicator is reset 85, and the transaction record is cleared 86.
  • the smart card is now able to return to the start-up routine having "rolled-back" correct data into the original data object.
  • the roll-back routine of Fig 8 will be further described in the context of a stored value application.
  • the original data object 45, along with its associated data 46, contain stored value information.
  • the smart card enters its start-up routine.
  • the OS looks at the global transaction indicator 43. Since this flag is set, the OS knows a transaction remains pending from the previous terminal session. In this case, the stored value data, i.e. the original data object 45/46 remains incorrectly defined or undefined.
  • transaction record 71 is located by, for example, having the OS scroll through the file directory looking for any data record having a type field indicator corresponding to a transaction record.
  • Transaction record 71 indicates the location in memory storing a copy of original data object 7 IB.
  • the original data object record stored in the file directory, with its unknown data state, is deleted and replaced (or rewritten) by the contents of transaction data record 71.
  • the global transaction indicator 43 is cleared, and transaction record 71, with its associated data object 7 IB, is deleted.
  • FIG. 9 Another aspect of the present invention is described with reference to the flowchart in Fig. 9.
  • ISO-7816 defines the ATR signal used by conventional smart cards to initiate communication with a terminal. Given the relatively simple nature of conventional smart card operation, the existing ATR protocol does not necessarily
  • the terminal contemplate a lengthy "start-up" routine including rolling back data for one or more uncompleted transactions. It is possible, therefore, for the terminal to prematurely terminate a session when an ATR signal is not received within an anticipated period of time.
  • the conventional ATR signal comprises multiple bytes of data.
  • the present invention uses this fact, to avoid "timing-out" during the Reset/ ATR exchange between a terminal and a smart card. For example, looking a Fig. 9, upon receiving power and a reset signal, the smart card begins a start-up routine 91. Soon after beginning the start-up routine, the smart card returns one or more bytes of the ATR signal 92 to essentially "hold" the terminal while completing the start-up routine 93. Once the start-up routine is complete, the smart card sends the remaining portion of the ATR signal 94 before entering an I/O loop, or performing some other function.
  • the transaction manager of the present invention precludes successful card yank attacks, and generally ensures data integrity otherwise threatened by transaction interruptions. This feature is particularly important in smart cards running multiple applications. Since each application may read/write data into memory, and potentially read write data common to other applications and the smart card OS, data integrity must be assured at all times, uncompleted transactions notwithstanding.
  • the present invention has been described using several examples.
  • the context needed to explain the transaction manager includes some assumptions regarding data record use and storage, data record structure, data object organization in memory, and the type of memory (EEPROM) commonly used. These contextual aspects, among others, are used to explain the broader concepts associated with the use of a transaction manager within a smart card.
  • the transaction manager is limited to the disclosed examples and teaching context, but is defined by the attached claims.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un gestionnaire de transactions (61) compris dans un système de fonctionnement de carte à puce qui garantit l'intégrité des données lors de transactions avec ladite carte. Ces transactions modifient la valeur d'un objet de données (41) stockée dans la carte à puce (10).
PCT/US2000/000084 1999-08-31 2000-01-05 Gestionnaire de transactions de carte a puce WO2001016874A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38628799A 1999-08-31 1999-08-31
US09/386,287 1999-08-31

Publications (1)

Publication Number Publication Date
WO2001016874A1 true WO2001016874A1 (fr) 2001-03-08

Family

ID=23524967

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/000084 WO2001016874A1 (fr) 1999-08-31 2000-01-05 Gestionnaire de transactions de carte a puce

Country Status (1)

Country Link
WO (1) WO2001016874A1 (fr)

Cited By (6)

* 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
EP1533706A1 (fr) * 2002-06-10 2005-05-25 Ken Sakamura Carte a circuit integre, dispositif de terminal et procede de communication de donnees
EP2595341A1 (fr) 2011-11-17 2013-05-22 Sven Sauter Gestion des droits d'utilisateurs et système de contrôle d'accès avec restriction de durée
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 (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4053735A (en) * 1975-08-07 1977-10-11 Foudos James N Assured-check computer-based bank credit disbursing system
US5930363A (en) * 1995-03-17 1999-07-27 Transmo Limited Card charging systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4053735A (en) * 1975-08-07 1977-10-11 Foudos James N Assured-check computer-based bank credit disbursing system
US5930363A (en) * 1995-03-17 1999-07-27 Transmo Limited Card charging systems

Cited By (12)

* 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
EP1533706A1 (fr) * 2002-06-10 2005-05-25 Ken Sakamura Carte a circuit integre, dispositif de terminal et procede de communication de donnees
EP1533706A4 (fr) * 2002-06-10 2006-05-10 Ken Sakamura Carte a circuit integre, dispositif de terminal et procede de communication de donnees
US7357329B2 (en) 2002-06-10 2008-04-15 Ken Sakamura IC card, terminal device, and data communication method
EP2595341A1 (fr) 2011-11-17 2013-05-22 Sven Sauter Gestion des droits d'utilisateurs et système de contrôle d'accès avec restriction de durée
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

Similar Documents

Publication Publication Date Title
JP3543327B2 (ja) スマートカードからのデータ読出し
Shelfer et al. Smart card evolution
US6256690B1 (en) System and method for facilitating multiple applications on a smart card
US5844218A (en) Method and system for using an application programmable smart card for financial transactions in multiple countries
TWI420399B (zh) 在管理共享平衡之單一付費器件上用於多重儲存值應用共存之技術
EP1113387A2 (fr) Carte à puce comportant une mémoire non volatile avec un mappage nouveau
US6480935B1 (en) Smart card memory management system and method
US6179205B1 (en) System and method for locking and unlocking and application in a smart card
EP0858644B1 (fr) Systeme et procede pour charger des applications dans une carte a puce
US7281101B2 (en) Memory device storing data relating to specific application programs
US6808111B2 (en) Terminal software architecture for use with smart cards
US4983816A (en) Portable electronic device
WO2012162351A1 (fr) Procédé et système de transactions combicard ayant un mécanisme de mise à jour de paramètres d'application
EP0981805A1 (fr) Carte a circuit integre avec fonction interpreteur
WO2001016874A1 (fr) Gestionnaire de transactions de carte a puce
Lassus Smart-cards-a cost-effective solution against electronic fraud
EP1384197B1 (fr) Procédé de fabrication de cartes à puce
JP3195122B2 (ja) Ｉｃカードに与える命令フォーマットのチェック方法
JP7452748B1 (ja) 電子情報記憶媒体、ｉｃチップ、ｉｃカード、バリュー値記録方法、及びプログラム
KR100580380B1 (ko) 스마트 카드를 이용한 지불 방법 및 그 장치
JPH05298497A (ja) Ｉｃカードの情報処理方法
AU2002254795B2 (en) Method of manufacturing smart cards
JP2004038286A (ja) 携帯可能電子媒体及び携帯可能電子媒体の発行システム
JP3234011B2 (ja) Ｉｃカード
JP2022164009A (ja) 電子情報記憶媒体、処理方法、及びプログラム

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

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