WO2001054086A1 - Programming data carriers - Google Patents

Programming data carriers Download PDF

Info

Publication number
WO2001054086A1
WO2001054086A1 PCT/GB2000/004958 GB0004958W WO0154086A1 WO 2001054086 A1 WO2001054086 A1 WO 2001054086A1 GB 0004958 W GB0004958 W GB 0004958W WO 0154086 A1 WO0154086 A1 WO 0154086A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
load
application
processor
terminal
Prior art date
Application number
PCT/GB2000/004958
Other languages
French (fr)
Inventor
Piotr Wilczynski
Noel Allan George Stephens
Original Assignee
Softcard Solutions Limited
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 GB0001230A external-priority patent/GB0001230D0/en
Application filed by Softcard Solutions Limited filed Critical Softcard Solutions Limited
Priority to AU2001222074A priority Critical patent/AU2001222074A1/en
Publication of WO2001054086A1 publication Critical patent/WO2001054086A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms 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/10Mechanisms 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/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment 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/355Personalisation of cards for use
    • G06Q20/3552Downloading or loading of personalisation data

Definitions

  • the present invention relates to: programmed portable data carriers which are also known as "smart cards”; a method and apparatus for programming such carriers; a computer program product; a system for programming such carriers; and a programmable device for use in programming such carriers.
  • programmed portable data carriers which are also known as "smart cards”
  • a method and apparatus for programming such carriers e.g., a computer program product
  • a system for programming such carriers e.g., a computer program product
  • a system for programming such carriers e.g., a programmable device for use in programming such carriers.
  • Figures 1A and IB are schematic diagrams of known smart cards
  • Figure 2 is a schematic diagram of a known terminal
  • Figure 3 is a schematic simplified diagram of a previously proposed system for using and programming smart cards.
  • a smart card 1 comprises an integrated circuit memory device or an integrated circuit data processor including non-volatile memory such as EEPROM or FLASH. If the smart card comprises the memory device (and has no processor), it preferably also has some logic circuitry, for example cryptographic access logic, for deterring illicit access to stored data.
  • the memory device or processor is embedded in a carrier 3 of e.g. plastic.
  • the carrier may be a credit card as shown in Figure 1A, the memory device or processor being connected to electrical contacts 2 on the surface of the card for interfacing with a card reader.
  • the carrier may have other forms, such as SIM cards used in mobile phones as shown in Figure IB.
  • the smart card may operate without contacts using for example radio communications.
  • Such cards may contain important and confidential data such as data personal to the user and/or data allowing access to bank accounts.
  • the integrated circuit has a physical structure which deters illicit physical access to data held in the circuit.
  • logical operations are built into or programmed into the integrated circuit to additionally deter illicit access.
  • Other propriety security features may be provided.
  • cryptographic processes such as data encryption may be used to protect the data.
  • cryptographic processes may be used as part of the protocol to access the data to cryptographically authenticate the user and to provide data confidentiality, authenticity and integrity as it is transmitted from the smart card (chip) to the recipient typically via a terminal.
  • Smart cards are used with terminals, such as Point of Sale (POS) terminals, Automatic Teller Machines (ATM) mobile phones, electricity meters, set top TV boxes, vending machines, door access units, and gates at railway stations (i.e. mass transit etc).
  • POS Point of Sale
  • ATM Automatic Teller Machines
  • Typical uses include collecting cash from ATMs and transferring money using POS terminals when buying goods in shops.
  • Figure 2 schematically shows an illustrative terminal. It comprises: a card interface 4 for interfacing with a smart card; a processor 6 and memory 8 which at least read data from the smart card and which may also write data to the card; a display 10 for displaying instructions and /or data to users of the terminal; a keyboard 12 for entering data into the terminal; and a communications interface 14 such as a modem for communication via an external communications network.
  • Some terminals have one or more additional interfaces for receiving additional functional devices, e.g. additional processors, memory, communications interfaces etc.
  • FIG 3 is a schematic and simplified representation of a system for issuing cards and for using the cards.
  • a user 16 inserts a user card 1 into a terminal 18 such as an ATM.
  • a transaction is carried out and data required for the transaction and data resulting from the transaction is transmitted by a communications network to a server of a host system 22.
  • the server of the host system 22 is linked to a database 24 containing customer details.
  • cards are personalised in a personalization bureau 26, which may be linked to the server by a communications network 28 to gain access to essential data, which may include customer details from database 24 and required to personalise cards.
  • the data programmed into the cards and the identification of the cards into which the data is programmed is stored in the server 22 and/or database 24.
  • Programmed cards 1 are issued to users 16 as indicated at 30, e.g. by post. Whilst the system of Figure 3 is presented as a simple system, in fact the system is complex comprising large and expensive computing equipment, data storage and sophisticated security which requires a large investment of money and skilled personnel. Also the system is inflexible. The card issuing company may wish to issue new applications for cards in order to provide improved functions on cards. However to do that typically they cannot reprogram existing cards: they issue new cards. It is known that certain standards, e.g. MULTOS provide a mechanism for loading applications in the field in a secure manner using cryptographic techniques.
  • MULTOS provide a mechanism for loading applications in the field in a secure manner using cryptographic techniques.
  • the prior proposed system relies on the existence of the complex and expensive smart card personalization system 100 to centrally, and securely, generate the applications personalised for customer cards.
  • the present inventor has realised that, while such systems provide for secure generation of application load units at a card bureau and operating systems such as MULTOS provide a method for securely downloading the application units to a target smart card, the problem still exists of how to securely generate an application load unit and load it, in the field, onto a target smart card which has been inserted into an insecure terminal that may not always be connected to a bureau and or card issuer host system.
  • a method of programming a portable data carrier comprising the steps of: providing a terminal having a first interface for interacting with a target portable data carrier, the terminal including a processor; the processor or the combination of the terminal and the processor having data storage; storing in the said data storage one or more of a generic application and data for personalising the generic application for the carrier to be programmed; using the processor to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and using the combination of the processor and terminal to load the load data or load application into the target carrier via the first interface.
  • the processor installed in the terminal can operate as a personalization device for target smart cards independently (that is without connection to a central database and data processing system), provided, of course, that the terminal and smart card contain the required data. This allows a personalization system which is inexpensive and can be operated on a small scale e.g. for trials of new card applications.
  • the data storage stores a generic application and data for personalising the generic application.
  • the processor creates the combination of the generic application and the personalisation data for loading into the target carrier.
  • a version of the method includes the further step of installing the processor in the terminal.
  • Such a combination of a terminal and a processor may be connected by a communications system to a central data processing system from which it can obtain customer data, or generic applications, or both customer data and generic applications. It will be appreciated that the personalization then still occurs at the terminal.
  • a system has the advantage that the central system is independent of the terminal(s) used to personalise target cards.
  • the creation of a personalised application takes place at the terminal. Apart from any storage it provides, the terminal acts merely as a means for transferring the personalised application to the target data carrier.
  • Some minimal processing is required to manage the chip builder and to transfer code and data between the target smart card and the chip builder. This reduces the complexity of the central system and reduces the bandwidth required to transmit data from the control system to the terminal.
  • the customer data and/or the generic application(s) are preferably stored in the central system and transferred to the terminal(s) using a protocol such as XML.
  • the terminal acts merely to transfer customer data and the generic application(s) to the processor, and may store at least some of the customer data and the generic application(s) for the processor to use.
  • the processor is most preferably a smart card integrated circuit incorporating a Central Processor Unit and memory and which has a physical structure and other features, which make the chip secure against illicit interference (hacking).
  • the chip may be a known chip. This allows the system of the invention to be implemented economically and securely. Secure operating systems such as MULTOS are available for such chips. This allows security at the operating system and protocol level to be provided economically. This also allows security to be compatible with at least many of the target smart cards.
  • the present invention provides a system in which a personalised application is created at the terminal (and not at the central system as in the prior proposal) by a processor installed in the terminal, from a generic application and customer data stored in the processor or stored in the combination of the terminal and the processor.
  • the terminal can be "insecure” since all the security may be built into processor vii)
  • the processor can be networked to a host system and it would secure the communications with the host system. Thus an insecure terminal and insecure network arrangements could be used. vii) Low cost) and ix) Short time to launch a trial of new applications.
  • apparatus for programming a portable data carrier comprising: a terminal having a first interface for interacting with a target portable data carrier; a processor installed in the terminal; the processor or the combination of the terminal and the processor having data storage; the said data storage being ananged to store a generic application and data for personalising the generic application for the carrier to be programmed; and the processor being arranged to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and the combination of the processor and terminal being ananged to load the load data or load application into the target carrier via the first interface.
  • a processing device for use in a terminal for programming a portable data carrier, the processing device comprising a smart card chip including a processor and data storage, the chip being programmed to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and to load the load data or load application into the target earner via the first interface.
  • a system for programming portable data carriers at least one terminal, the or each terminal having a first interface for interacting with a target portable data carrier, and a processor installed in the terminal,
  • a method of programming portable data carriers in a system comprising: at least one terminal, the or each terminal having a first interface for interacting with a target portable data carrier, and a processor installed in the terminal, the processor or the combination of the terminal and the processor having data memory; a data storage system storing at least one generic application and data for personalising the or each generic application; and a communications system linking the data storage system to the terminal or terminals; the method comprising the steps of: transfening a generic application and personalising data to the combination of the terminal and processor for storage in the said data memory, being ananged storing the transfened generic application and personalising data in the said data memory generic; using the processor to create, from the generic application and the personalising data, a personalised application; and loading the personalised application into the target earner via the first interface.
  • a computer program product for running on a smart card chip having a processor and data memory, the product being arranged, when run on the chip, to access a generic application and personalising data stored in the data memory, to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application and/or personalising data; and to cause the load data or load application to be loaded into the target carrier.
  • Figure 4 is a schematic block diagram of a system in accordance with the present invention for programming smart cards
  • Figure 5 is a schematic block diagram of an integrated circuit for use in the system of Figure 4;
  • Figure 6 is a diagram illustrating the operation of the system of figure 4.
  • Figure 7 illustrates a data structure
  • Figures 8 and 9 are diagrams illustrating the operation of the system of figure 4.
  • an integrated circuit, refened to herein as chip 44, in accordance with an embodiment of the present invention, is provided in a terminal 42.
  • An example of the chip 44 is shown in Figure 5.
  • the terminal 42 is for example as shown in Figure 2 and has an interface 45 for receiving a target smart card 41.
  • the terminal 42 also has at least one additional interface 47 for receiving an additional smart card.
  • the chip 44 is preferably embedded in a smart card carrier and is received in the additional interface 47. Most preferably, the chip 44 in its carrier is housed within the terminal 42.
  • the target smart card 41 is programmed with an application and customer details by the chip 44 and terminal 42.
  • the terminal has an interface 46 coupling it to a database 50 containing customer details.
  • the database 50 is coupled to the interface 46 via a communications network 48.
  • the terminal is also coupled to an issuer 43 of generic applications via the interface and network.
  • the terminal is not coupled to the network.
  • the customer details and generic application are stored in the chip 44 or in the combination of chip and terminal.
  • the terminal may provide some storage for the Central Processor Unit, it otherwise acts merely to transfer the application and customer details from the chip 44 to the target card.
  • the terminal 42 contains software, which allows it to cooperate with the chip 44 to transfer the application and customer details from the chip to the target smart card 41. That software may be loaded into the terminal at manufacture or it may be loaded when installing the chip 44 or at any time in between. Alternatively, the software which loads the application and customer details from the chip 44 to the target card 41 may be stored in the chip 44, the terminal having software which allows the chip to control the terminal for that purpose. Chip 44
  • the chip 44 is a high security microprocessor smart card chip.
  • the chip 44 in this example is a smart card chip because such a chip provides enhanced data security as discussed above by virtue of its physical structure and other security features provided in it.
  • the chip may be a known chip available from known smart card chip manufacturers such as Siemens or Hitachi.
  • a prefened chip has the maximum storage cunently available and/or the maximum processing power in terms of operating speed cunently available.
  • the chip 44 is embedded in a canier which has the same physical size and format as a microprocessor smart card SIM module used in the mobile telephone industry.
  • the high security aspects of a smart card chip prevents or at least deters unauthorised access to any code, cryptographic key and other data contained within it.
  • the protection is both physical and logical using cryptographic means to further prevent unauthorised access to the data.
  • the chip 44 is programmed to create "Application Load Units" (ALU) from generic applications provided by a source 43 and customer data from the database 50 and, via the terminal 42, to load the ALU into the target smart card 41.
  • ALU Application Load Units
  • the terminal 42 containing the chip 44 is a stand alone terminal (i.e. not connected to network) and the ALUs are created from generic applications and customer data stored in the chip 44.
  • the ALU which is loaded into the target card is created by the chip 44 in the terminal and not by a central system.
  • the creation of ALUs is also refened to herein as "building".
  • the target smart card 41 preferably has a high security operating system installed.
  • An example of an operating system is MULTOS which is a high security multi-application operating system.
  • Other high security operating systems are known such as NOP and JAVACARD.
  • NOP and JAVACARD high security operating systems
  • the following description assumes the target smart card 41 has a microprocessor and the operating system is a high security operating system such as MULTOS and the chip 44 has the same operating system. However as will be made clear it is not essential that the chip 44 and target card 42 have the same operating system.
  • the chip 44 comprises:
  • a Central Processor Unit 513 running the operating system and accessing various stores described below via one or more data busses (not shown).
  • the volatile memory and the no n- volatile memory includes the following logical areas :- a storage area called a log store (511) used to store logging information.
  • the log store stores the serial number of the target smart card into which application load units (ALU) are loaded by the chip 44. Additionally the date of generation of the ALU is stored with serial number in the log store 511.
  • the log store also stores the result of the build and load process, e.g.. was it successful or not, and, if not, why not in the form of an enor code.
  • a key store 512 which is used to store any cryptographic keys required to allow the cryptographic calculations to be performed; a program and or script store 514 which stores a program which defines how the chip 44 generates the application load units; a unit store 515 for one or more generic application units.
  • the units include a code segment (516), data segment (517), optionally an application signature (518) and optionally one or more session keys used and key descriptions (519) used to encipher some or all of the code segments (516) and or some or all of the data segment (517); a store 520 for one or more optional load certificates or load keys that are used by the card to determine if the load can take place.
  • Load certificates are a means by which a target card can test the authenticity of any application and/or data, which is loaded into the target card. If the load certificate is absent or inconect the target card does not accept the downloaded application and/or data.
  • the certificate may be cryptographic or non-cryptographic e.g. a password or PIN or challenge and response mechanisms based on the knowledge of some secret or some sort of digital signature; and a temporary or buffer store 521 for data that is received by the chip 44.
  • the buffer store is used to store customer details. Other data may be stored in the chip 44 for example the serial number of the terminal apparatus, code version number and application data version number.
  • a facility may be provided to allow secure storage of the application units and optionally the customer data, in the insecure terminal.
  • the facility would be used if the chip 44 has insufficient memory and the terminal has spare memory capacity.
  • the application units are stored enciphered and read into the chip 44 via an interface 47, where they are deciphered and placed into the unit storage area 515.
  • the key to decipher the application unit would be stored in key store 512.
  • the key store 512 may also store a key to protect any generic application stored in the insecure terminal.
  • the chip 44 may further include circuitry 522 to provide all the on screen messages for user interaction such that the terminal apparatus is controlled by the chip 44 thus greatly reducing the complexity of the terminal apparatus. Thus the cost of a terminal may be reduced.
  • the chip 44 may include the control logic 523 and programming for all communication and security procedures with the host system / application issuer. Terminal 42
  • the embodiments of the invention assume that the terminal 42 does not require any physical modification (except installation of the chip 44) to operate with the chip 44. As discussed above, the embodiments of the invention also assume that the terminal 42 has an operating system and any other software which allows it to transfer, to the target card, the application load units (ALUs) in the form of APDUs created by the chip 44. The terminal merely acts to transfer ALUs to the target card.
  • ALUs application load units
  • the terminal 42 may be as shown in Figure 2.
  • the display 10 is not essential to the operation of the present invention although it may be essential for other functions of the terminal.
  • it may be replaced by LEDs which indicate various operational states such as "ready, waiting for target card”, “loading completed”, “enor” etc.
  • the terminal has the interface 46 with the communications network 48 via which it can communicate with a database 50 containing customer data and the source 43 of "generic applications" to be programmed with the customer data into a target smart card 41 by the combination of the chip 44 and the terminal 42.
  • the terminal 42 may be an ATM terminal or a POS terminal for example. Operation
  • ALUs which are loaded into the target smart card 41.
  • the chip 44 stores a generic application. It combines the generic application with the customer details in accordance with Rules in conjunction with an optional template to "personalise” the application and creates therefrom the ALUs which load the personalised application into the target card.
  • a template is a map which indicates the layout of the data.
  • Rules are in essence scripts that instruct the chip 44 to combine the generic application with the customer details. For example a rule may specify that a particular piece of data is taken from a storage location and put it in a specified position in code.
  • the program in the program store 514 combined with the rules defines how to build the personalised application which is downloaded into the target card 41. Templates simplify the process of creating different applications and reduce the size of the generic program in store 514.
  • the script program and rules are preferably stored together in store 514 but could be stored separately.
  • Example 1 One illustrative way of operating the chip 44 and terminal 42 will be described by way of example with reference to Figures 4, 8 and 9. This way of operating assumes the terminal 42 communicates with the database 50 and source 43 via the communications network 48. This illustrative way also assumes that the target card and the chip 44 have the same operating system. Referring to Figure 8:-
  • the chip 44 is activated by inputting a PIN number using the keyboard of the terminal.
  • the target card 41 is inserted into the interface 45 of the terminal 42.
  • the chip 44 receives from the target card: a) the serial number of the target card; b) the public cryptographic key of the target card; and c) a cryptographic certificate issued by a certification authority. Provision of the public key and/or the certificate is prefened but may be omitted in some implementations of the invention.
  • the chip 44 validates the cryptographic signature of the public key.
  • S5. The customer details are transmitted from the database 50 in encrypted form to the terminal 42 via network 48 and interface 46.
  • the generic application is transmitted from the application issuer 43 to the terminal 42 via network 48 and interface 46.
  • the chip stores the code and data of the generic application in the unit stores 516, 517, 518 and 519.
  • the chip stores the customer data in the buffer store 521. If the data representing the generic application and/or the customer data is too big to store in the chip 44, it may be stored in the terminal.
  • the terminal may be insecure, in which case the data is stored in the terminal in encrypted form.
  • Data which is transmitted to the terminal and chip via the network 48, is encrypted using a transport key.
  • the data is decrypted using a transport key previously stored in the key store 512 of the chip.
  • the chip 44 builds the ALUs and
  • Steps S7 and S8 are described in more detail below.
  • the chip records in the log store 511 the serial number of the target card into which the ALUs are loaded. The loading may be unsuccessful. The chip also records in the log store whether the loading was successful or not. The log store may also record the date of loading. It may also store data identifying the application(s), which are loaded.
  • the chip and terminal transmit the contents of the log store to the Application issuer 43 via the network 48.
  • the issuer 43 may check the log transmitted to it.
  • the log is not deleted from chip builder until the application issuer has acknowledge conect receipt of the log.
  • the chip may receive from the issuer 43 a new script or program for storage in store 514 and/or one or more generic application units for storage in unit stores 516 to 519.
  • the bandwidth of the communications link may be smaller than if the personalised application is transmitted from the central system to the terminal. This is because it is then necessary to send the generic application, which may be large only once (and then send each individual instance of the specific data. If pre-built applications are sent by the central system, the specific data combined with the generic application is sent many times. Example 2.
  • the chip 44 and terminal are either not connected to the network 48 or operate without using the network 48.
  • the chip 44 contains all the data it requires without needing to use the network 48.
  • the chip 44 is programmed with all the data before it is installed in the terminal.
  • the operation of the terminal and chip is as described in Example 1 except that steps S5, S6 and SI 1 are omitted.
  • the customer details are pre-stored in store 521 and the generic application are pre-stored in stores 516 to 519. Alternatively, the customer details and generic application are stored encrypted in the terminal. Step S7. Building ALUs
  • An ALU comprises one or more Application Program Data Units (APDU) defined in ISO 7816 and the ALU is transmitted using the ISO 7816 protocol.
  • APDU Application Program Data Unit
  • APDU has a header and a data container. Each APDU contains upto 255 bytes of data.
  • An ALU may contain many kilo bytes of data and thus may comprise many tens of
  • the chip 44 creates target APDUs to be loaded into the target smart card.
  • the generic application is stored in the form of APDUs which are ready to be run on the target card.
  • the APDUs of the generic application are loaded into the Central Processor Unit 513 of the chip 44.
  • load APDUs are created.
  • the load APDUs wrap the APDUs of the generic application as shown in Figure 7. That fs the generic APDUs are contained in the data containers of the load APDUs to be loaded into the CPU 513
  • the load APDUs contain load commands.
  • the Central Processor Unit 513 of the chip 44 prepares the "Application Load
  • Unit using a generic “Application Load Unit” held in unit store 515 which is personalised using the customer data and the generic application provided by the issuer
  • code 43 which is stored as code in code store 516, data in data store 517, an application signature stored in store 518 and, preferably, a session key in store 519.
  • the preparation of the Application Load Unit includes enciphering any data and code that need to be confidential using the public key obtained from the target smart card. Those skilled in the art will be aware of the different ways of doing this including the use of session keys.
  • the authenticity of the public key is verified in a previous step using the certificate of the public key.
  • the application signature is a known digital signature method, which allows the detection of any illicit interference with the code and data.
  • the signature is dependent on the data associated with the signature.
  • a load certificate is sent to the target card with the application to be downloaded.
  • Step S8 - loading the APDUs into the target card
  • the terminal includes the processor 6 shown in Figure 2.
  • the processor 6 and chip 44 operate together according to a transfer program to transfer APDUs from the chip 44 to the target card.
  • the processor 6 of the terminal may contain the entire transfer program and control the transfer, interacting with the chip 44.
  • the chip 44 may contain the entire transfer program, the processor 6 of the terminal containing sufficient instructions to be controlled by the chip 44.
  • one example of the transfer program which is contained in the terminal, operates as follows.
  • the terminal reacts to the insertion of a target card into the user card interface 4 of Figure 2 to boot up the card, and read from it target card data required by the chip 44 to build an application for transfer.
  • target card data may include, inter alia, the serial number and identity of the operating system of the target card.
  • the terminal then boots up the chip 44 and sends the target card data to the chip 44.
  • the terminal gets an APDU created by the chip 44 transfers it to the target card, and receives from the card a result and reports the result to the chip 44. That process is repeated for all the APDUs to be transfened.
  • the target smart card reads the code and data transfened to it via the terminal 42.
  • the target card verifies that the download is legitimate by examining the load certificate; verifies the application signature to detect any interference with the data; and deciphers the data using methods which are known to those skilled in the art.
  • the target card then operates in accordance with the code and data transfened to it in the target APDUs.
  • Some target cards comprise a memory device (and no processor), and preferably also some logic circuitry, for example cryptographic access logic, for detemng illicit access to stored data.
  • the terminal 42 transfers the data from the chip 44 to the target card.
  • the target chip has a hardwired bus protocol such as I2C.
  • the I2C protocol is a common serial memory protocol.
  • the chip 44 builds a data image, and provides access codes if the memory card has some hardwired access logic.
  • Example 2 in which a preprogrammed smart card chip 44 is used in a standard smart card terminal to load ALUs into a target smart card, allows an organisation, such as a Bank, to experiment with new applications in smart cards without the need to set up or use an expensive support system having a customer database and a server linked to the terminal by a communications network.
  • Small numbers of target smart cards can be economically programmed.
  • target cards already issued to customers can be easily and inexpensively reprogrammed at existing terminals equipped with the chip 44 without the need for the expensive support system.
  • the terminals do not need to be connected to expensive networked infrastructure.
  • Existing terminals can be used with only the provision of the chip 44 and perhaps a minor modification of the software in the terminal to operate with the chip 44.
  • the terminals can be insecure because the chip 44 incorporates the essential security.
  • Example 1 which uses the central host system allows issued target cards to be securely reprogrammed at insecure terminals by installing the chips 44 in the terminals.
  • Example 1 has the advantages that: the bandwidth needed to transfer data from the central system to the target card is reduced; insecure terminals can be used; and existing terminals can be used with only the provision of the chip 44 and perhaps a minor modification of the software in the terminal to operate with the chip 44.
  • the terminals can be insecure because the chip 44 incorporates the essential security.
  • the invention provides a computer program product which is loaded into e.g. a standard smart card chip having a processor as described above and which when run on the chip when installed in a suitable terminal allows the chip to create and load ALUs into a target smart card as described above.
  • a program product may be supplied on a data carrier, such as in a smart card as described above. It may be supplied on other data carriers for down loading into a smart card chip. It may be supplied over a, preferably secure, data transmission system.
  • a generic application is personalised with customer specific data and the resulting personalised application is downloaded into a target card. That process may be repeated for many target cards for respective customers having different customer data.
  • the invention is not limited to that.
  • the invention may be used to download, to every card of a batch of target cards, the same generic application "personalised" with data which is common top the batch.
  • An example of that is producing a batch of cards all having the same bank sort code, the sort code being the personalising data.
  • the invention may be used to download to a batch of cards, or to individual cards, a generic application. The invention may then be used again, at a later time, to personalise the generic application, which has already been downloaded.
  • the operating systems of the chip 44 and the target card may be different.
  • the identity of the target card's operating system is transfened from the target card to the chip 44.
  • the chip 44 then creates target
  • the terminal may be a mobile phone the communications interface being the transmitter/receiver of the mobile phone.
  • a mobile phone has two card interfaces, one for the SIM for operating the phone and another for another card, e.g. a SIM acting as an e-commerce device, e.g. an electronic wallet.
  • the chip 44 of the invention may be built into the SIM for operating the phone, whereby the chip 44 can download new applications into the other card.
  • the chip 44 is most preferably a smart card chip because of the security such a chip provides. However, at least in principle the chip 44 may be an "ordinary" insecure microprocessor: The invention would operate with such an ordinary microprocessor but would not be secure. Security of an ordinary microprocessor could be enhanced by cryptography and by encasing the microprocessor in a secure housing.
  • the chip 44 could be incorporated in, or integrated in, the processor 6 of the terminal 42 of Figure 2. Such a terminal would have only one processor, rather than two as in the embodiments described above. The single processor would carry out the functions of the present invention.
  • the personalising data could be entered using a keyboard 12 of the terminal rather than being prestored in the terminal and/or chip 44 or being downloaded from the central data processing system.
  • Some of the embodiments described above combine a generic application with personalising data and download the combination into the target card.
  • Other embodiments combine a generic application with data common to a batch of cards and download the combination to the batch.
  • a personalised version of the code of an application is built by taking a generic application and adding or deleting code or applets from it. In essence, a set of functions are added or removed from the generic application for a specific target card or batch of target cards.
  • Such a personalised version of the generic application may be combined with personalising data as described above.
  • the personalised version and/or the combination of it with data is downloaded into a target card as described above. Provision of such personalised versions of generic applications requires conesponding load certificates.

Abstract

An integrated circuit chip (44) in accordance with an embodiment of the present invention, is provided in a terminal (42). The terminal (42) has an interface (45) for receiving a target smart card. The target smart card (41) is programmed with an 'application' and customer details by the combination of the chip (44) and the terminal (42). The terminal (42) also has at least one additional interface (47) for receiving an additional smart card. The chip (44) is a smart card chip having a physical structure and incorporating logical and other features which make it secure. It is preferably embedded in a smart card carrier and is received in the additional interface (47). Most preferably, the chip (44) in its carrier is housed within the terminal (42).

Description

Pro jamming Data Carriers
The present invention relates to: programmed portable data carriers which are also known as "smart cards"; a method and apparatus for programming such carriers; a computer program product; a system for programming such carriers; and a programmable device for use in programming such carriers. For convenience the term
"smart card " will be used hereinafter.
Background to the present invention will be described with reference to Figures 1 to 3 of which:
Figures 1A and IB are schematic diagrams of known smart cards; Figure 2 is a schematic diagram of a known terminal; and
Figure 3 is a schematic simplified diagram of a previously proposed system for using and programming smart cards.
Referring to Figure 1 , a smart card 1 comprises an integrated circuit memory device or an integrated circuit data processor including non-volatile memory such as EEPROM or FLASH. If the smart card comprises the memory device (and has no processor), it preferably also has some logic circuitry, for example cryptographic access logic, for deterring illicit access to stored data. The memory device or processor is embedded in a carrier 3 of e.g. plastic. The carrier may be a credit card as shown in Figure 1A, the memory device or processor being connected to electrical contacts 2 on the surface of the card for interfacing with a card reader. The carrier may have other forms, such as SIM cards used in mobile phones as shown in Figure IB. The smart card may operate without contacts using for example radio communications.
Such cards may contain important and confidential data such as data personal to the user and/or data allowing access to bank accounts. To make the data secure, the integrated circuit has a physical structure which deters illicit physical access to data held in the circuit. In addition, logical operations are built into or programmed into the integrated circuit to additionally deter illicit access. Other propriety security features may be provided. Furthermore, cryptographic processes such as data encryption may be used to protect the data. Also cryptographic processes may be used as part of the protocol to access the data to cryptographically authenticate the user and to provide data confidentiality, authenticity and integrity as it is transmitted from the smart card (chip) to the recipient typically via a terminal.
Several known standards or suggestions for standards exist in the area of Smart Cards : ISO/IEC 7816, ISO 10536, MULTOS ™, Java ™ Card, Windows Card ™, for instance.
Smart cards are used with terminals, such as Point of Sale (POS) terminals, Automatic Teller Machines (ATM) mobile phones, electricity meters, set top TV boxes, vending machines, door access units, and gates at railway stations (i.e. mass transit etc). Typical uses include collecting cash from ATMs and transferring money using POS terminals when buying goods in shops.
Figure 2 schematically shows an illustrative terminal. It comprises: a card interface 4 for interfacing with a smart card; a processor 6 and memory 8 which at least read data from the smart card and which may also write data to the card; a display 10 for displaying instructions and /or data to users of the terminal; a keyboard 12 for entering data into the terminal; and a communications interface 14 such as a modem for communication via an external communications network. Some terminals have one or more additional interfaces for receiving additional functional devices, e.g. additional processors, memory, communications interfaces etc.
Figure 3 is a schematic and simplified representation of a system for issuing cards and for using the cards. Referring to Figure 3, a user 16 inserts a user card 1 into a terminal 18 such as an ATM. A transaction is carried out and data required for the transaction and data resulting from the transaction is transmitted by a communications network to a server of a host system 22. The server of the host system 22 is linked to a database 24 containing customer details. Before issue, cards are personalised in a personalization bureau 26, which may be linked to the server by a communications network 28 to gain access to essential data, which may include customer details from database 24 and required to personalise cards. The data programmed into the cards and the identification of the cards into which the data is programmed is stored in the server 22 and/or database 24. Programmed cards 1 are issued to users 16 as indicated at 30, e.g. by post. Whilst the system of Figure 3 is presented as a simple system, in fact the system is complex comprising large and expensive computing equipment, data storage and sophisticated security which requires a large investment of money and skilled personnel. Also the system is inflexible. The card issuing company may wish to issue new applications for cards in order to provide improved functions on cards. However to do that typically they cannot reprogram existing cards: they issue new cards. It is known that certain standards, e.g. MULTOS provide a mechanism for loading applications in the field in a secure manner using cryptographic techniques.
The prior proposed system relies on the existence of the complex and expensive smart card personalization system 100 to centrally, and securely, generate the applications personalised for customer cards. The present inventor has realised that, while such systems provide for secure generation of application load units at a card bureau and operating systems such as MULTOS provide a method for securely downloading the application units to a target smart card, the problem still exists of how to securely generate an application load unit and load it, in the field, onto a target smart card which has been inserted into an insecure terminal that may not always be connected to a bureau and or card issuer host system.
According to one aspect of the present invention there is provided a method of programming a portable data carrier comprising the steps of: providing a terminal having a first interface for interacting with a target portable data carrier, the terminal including a processor; the processor or the combination of the terminal and the processor having data storage; storing in the said data storage one or more of a generic application and data for personalising the generic application for the carrier to be programmed; using the processor to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and using the combination of the processor and terminal to load the load data or load application into the target carrier via the first interface.
The processor installed in the terminal can operate as a personalization device for target smart cards independently (that is without connection to a central database and data processing system), provided, of course, that the terminal and smart card contain the required data. This allows a personalization system which is inexpensive and can be operated on a small scale e.g. for trials of new card applications.
In a preferred embodiment, the data storage stores a generic application and data for personalising the generic application. The processor creates the combination of the generic application and the personalisation data for loading into the target carrier. A version of the method includes the further step of installing the processor in the terminal.
Such a combination of a terminal and a processor may be connected by a communications system to a central data processing system from which it can obtain customer data, or generic applications, or both customer data and generic applications. It will be appreciated that the personalization then still occurs at the terminal. Such a system has the advantage that the central system is independent of the terminal(s) used to personalise target cards. The creation of a personalised application takes place at the terminal. Apart from any storage it provides, the terminal acts merely as a means for transferring the personalised application to the target data carrier. Some minimal processing is required to manage the chip builder and to transfer code and data between the target smart card and the chip builder. This reduces the complexity of the central system and reduces the bandwidth required to transmit data from the control system to the terminal.
The customer data and/or the generic application(s) are preferably stored in the central system and transferred to the terminal(s) using a protocol such as XML. The terminal acts merely to transfer customer data and the generic application(s) to the processor, and may store at least some of the customer data and the generic application(s) for the processor to use.
The processor is most preferably a smart card integrated circuit incorporating a Central Processor Unit and memory and which has a physical structure and other features, which make the chip secure against illicit interference (hacking). The chip may be a known chip. This allows the system of the invention to be implemented economically and securely. Secure operating systems such as MULTOS are available for such chips. This allows security at the operating system and protocol level to be provided economically. This also allows security to be compatible with at least many of the target smart cards.
In one embodiment, the present invention provides a system in which a personalised application is created at the terminal (and not at the central system as in the prior proposal) by a processor installed in the terminal, from a generic application and customer data stored in the processor or stored in the combination of the terminal and the processor.
This has advantages as follows or creates the following possibilities: i) A user does not need to bring a carrier back to a personalisation bureau for changing applications stored in the card. ii) An expensive network infrastructure is not essential to add applications onto carriers already issued. iii) Existing carriers can be used with new applications. iv) Since a network is not essential to install new applications, it is not necessary to interfere with existing terminals - it is possible to use other stand- alone terminals. v) If it is decided to upgrade existing terminals, the modification is a very simple insertion of the processor into the terminal and perhaps an upgrade of the software in the terminal so it operates with the processor. vi) The terminal can be "insecure" since all the security may be built into processor vii) The processor can be networked to a host system and it would secure the communications with the host system. Thus an insecure terminal and insecure network arrangements could be used. vii) Low cost) and ix) Short time to launch a trial of new applications. According to another aspect of the invention, there is provided apparatus for programming a portable data carrier, comprising: a terminal having a first interface for interacting with a target portable data carrier; a processor installed in the terminal; the processor or the combination of the terminal and the processor having data storage; the said data storage being ananged to store a generic application and data for personalising the generic application for the carrier to be programmed; and the processor being arranged to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and the combination of the processor and terminal being ananged to load the load data or load application into the target carrier via the first interface.
According to a further aspect of the invention, there is provided a processing device for use in a terminal for programming a portable data carrier, the processing device comprising a smart card chip including a processor and data storage, the chip being programmed to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and to load the load data or load application into the target earner via the first interface.
According to yet another aspect of the invention, there is provided a system for programming portable data carriers, at least one terminal, the or each terminal having a first interface for interacting with a target portable data carrier, and a processor installed in the terminal,
According to a yet further aspect of the invention, there is provided a method of programming portable data carriers in a system comprising: at least one terminal, the or each terminal having a first interface for interacting with a target portable data carrier, and a processor installed in the terminal, the processor or the combination of the terminal and the processor having data memory; a data storage system storing at least one generic application and data for personalising the or each generic application; and a communications system linking the data storage system to the terminal or terminals; the method comprising the steps of: transfening a generic application and personalising data to the combination of the terminal and processor for storage in the said data memory, being ananged storing the transfened generic application and personalising data in the said data memory generic; using the processor to create, from the generic application and the personalising data, a personalised application; and loading the personalised application into the target earner via the first interface.
According to another aspect of the invention, there is provided a computer program product for running on a smart card chip having a processor and data memory, the product being arranged, when run on the chip, to access a generic application and personalising data stored in the data memory, to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application and/or personalising data; and to cause the load data or load application to be loaded into the target carrier.
For a better understanding of the present invention, reference will now be made by way of example to the accompanying drawings in which:
Figure 4 is a schematic block diagram of a system in accordance with the present invention for programming smart cards;
Figure 5 is a schematic block diagram of an integrated circuit for use in the system of Figure 4;
Figure 6 is a diagram illustrating the operation of the system of figure 4;
Figure 7 illustrates a data structure;
Figures 8 and 9 are diagrams illustrating the operation of the system of figure 4.
Overview
Refening to Figure 4, an integrated circuit, refened to herein as chip 44, in accordance with an embodiment of the present invention, is provided in a terminal 42. An example of the chip 44 is shown in Figure 5. The terminal 42 is for example as shown in Figure 2 and has an interface 45 for receiving a target smart card 41. The terminal 42 also has at least one additional interface 47 for receiving an additional smart card. The chip 44 is preferably embedded in a smart card carrier and is received in the additional interface 47. Most preferably, the chip 44 in its carrier is housed within the terminal 42. In accordance with embodiments of the present invention, the target smart card 41 is programmed with an application and customer details by the chip 44 and terminal 42.
In one embodiment, the terminal has an interface 46 coupling it to a database 50 containing customer details. The database 50 is coupled to the interface 46 via a communications network 48. The terminal is also coupled to an issuer 43 of generic applications via the interface and network. In another embodiment, the terminal is not coupled to the network. The customer details and generic application are stored in the chip 44 or in the combination of chip and terminal.
Although the terminal may provide some storage for the Central Processor Unit, it otherwise acts merely to transfer the application and customer details from the chip 44 to the target card. The terminal 42 contains software, which allows it to cooperate with the chip 44 to transfer the application and customer details from the chip to the target smart card 41. That software may be loaded into the terminal at manufacture or it may be loaded when installing the chip 44 or at any time in between. Alternatively, the software which loads the application and customer details from the chip 44 to the target card 41 may be stored in the chip 44, the terminal having software which allows the chip to control the terminal for that purpose. Chip 44
In a prefened implementation the chip 44 is a high security microprocessor smart card chip. The chip 44 in this example is a smart card chip because such a chip provides enhanced data security as discussed above by virtue of its physical structure and other security features provided in it. The chip may be a known chip available from known smart card chip manufacturers such as Siemens or Hitachi. A prefened chip has the maximum storage cunently available and/or the maximum processing power in terms of operating speed cunently available. In a prefened implementation the chip 44 is embedded in a canier which has the same physical size and format as a microprocessor smart card SIM module used in the mobile telephone industry. As is commonly known to those skilled in the art, the high security aspects of a smart card chip prevents or at least deters unauthorised access to any code, cryptographic key and other data contained within it. The protection is both physical and logical using cryptographic means to further prevent unauthorised access to the data.
In one embodiment, the chip 44 is programmed to create "Application Load Units" (ALU) from generic applications provided by a source 43 and customer data from the database 50 and, via the terminal 42, to load the ALU into the target smart card 41. In another embodiment, the terminal 42 containing the chip 44 is a stand alone terminal (i.e. not connected to network) and the ALUs are created from generic applications and customer data stored in the chip 44. In both embodiments the ALU which is loaded into the target card is created by the chip 44 in the terminal and not by a central system. The creation of ALUs is also refened to herein as "building".
The target smart card 41 preferably has a high security operating system installed. An example of an operating system is MULTOS which is a high security multi-application operating system. Other high security operating systems are known such as NOP and JAVACARD. The following description assumes the target smart card 41 has a microprocessor and the operating system is a high security operating system such as MULTOS and the chip 44 has the same operating system. However as will be made clear it is not essential that the chip 44 and target card 42 have the same operating system.
Refening to Figure 5, the chip 44 comprises:
A Central Processor Unit 513 running the operating system and accessing various stores described below via one or more data busses (not shown). Associated with the Central Processor Unit 513 is volatile and non-volatile memory. The volatile memory and the no n- volatile memory includes the following logical areas :- a storage area called a log store (511) used to store logging information. The log store stores the serial number of the target smart card into which application load units (ALU) are loaded by the chip 44. Additionally the date of generation of the ALU is stored with serial number in the log store 511. The log store also stores the result of the build and load process, e.g.. was it successful or not, and, if not, why not in the form of an enor code. a key store 512 which is used to store any cryptographic keys required to allow the cryptographic calculations to be performed; a program and or script store 514 which stores a program which defines how the chip 44 generates the application load units; a unit store 515 for one or more generic application units. The units include a code segment (516), data segment (517), optionally an application signature (518) and optionally one or more session keys used and key descriptions (519) used to encipher some or all of the code segments (516) and or some or all of the data segment (517); a store 520 for one or more optional load certificates or load keys that are used by the card to determine if the load can take place. Load certificates are a means by which a target card can test the authenticity of any application and/or data, which is loaded into the target card. If the load certificate is absent or inconect the target card does not accept the downloaded application and/or data. The certificate may be cryptographic or non-cryptographic e.g. a password or PIN or challenge and response mechanisms based on the knowledge of some secret or some sort of digital signature; and a temporary or buffer store 521 for data that is received by the chip 44. The buffer store is used to store customer details. Other data may be stored in the chip 44 for example the serial number of the terminal apparatus, code version number and application data version number.
A facility may be provided to allow secure storage of the application units and optionally the customer data, in the insecure terminal. The facility would be used if the chip 44 has insufficient memory and the terminal has spare memory capacity. In this case, the application units are stored enciphered and read into the chip 44 via an interface 47, where they are deciphered and placed into the unit storage area 515. The key to decipher the application unit would be stored in key store 512. The key store 512 may also store a key to protect any generic application stored in the insecure terminal.
The chip 44 may further include circuitry 522 to provide all the on screen messages for user interaction such that the terminal apparatus is controlled by the chip 44 thus greatly reducing the complexity of the terminal apparatus. Thus the cost of a terminal may be reduced. The chip 44 may include the control logic 523 and programming for all communication and security procedures with the host system / application issuer. Terminal 42
The embodiments of the invention assume that the terminal 42 does not require any physical modification (except installation of the chip 44) to operate with the chip 44. As discussed above, the embodiments of the invention also assume that the terminal 42 has an operating system and any other software which allows it to transfer, to the target card, the application load units (ALUs) in the form of APDUs created by the chip 44. The terminal merely acts to transfer ALUs to the target card.
The terminal 42 may be as shown in Figure 2. The display 10 is not essential to the operation of the present invention although it may be essential for other functions of the terminal. For the purposes of embodiments of the present invention it may be replaced by LEDs which indicate various operational states such as "ready, waiting for target card", "loading completed", "enor" etc.
In one embodiment, the terminal has the interface 46 with the communications network 48 via which it can communicate with a database 50 containing customer data and the source 43 of "generic applications" to be programmed with the customer data into a target smart card 41 by the combination of the chip 44 and the terminal 42. The terminal 42 may be an ATM terminal or a POS terminal for example. Operation
Operation Overview Referring to Figure 6, in overview, the chip 44 generates Application Load
Units (ALUs) which are loaded into the target smart card 41. The chip 44 stores a generic application. It combines the generic application with the customer details in accordance with Rules in conjunction with an optional template to "personalise" the application and creates therefrom the ALUs which load the personalised application into the target card. A template is a map which indicates the layout of the data.
Rules are in essence scripts that instruct the chip 44 to combine the generic application with the customer details. For example a rule may specify that a particular piece of data is taken from a storage location and put it in a specified position in code. The program in the program store 514 combined with the rules defines how to build the personalised application which is downloaded into the target card 41. Templates simplify the process of creating different applications and reduce the size of the generic program in store 514. The script program and rules are preferably stored together in store 514 but could be stored separately. Example 1. One illustrative way of operating the chip 44 and terminal 42 will be described by way of example with reference to Figures 4, 8 and 9. This way of operating assumes the terminal 42 communicates with the database 50 and source 43 via the communications network 48. This illustrative way also assumes that the target card and the chip 44 have the same operating system. Referring to Figure 8:-
Sl.The chip 44 is activated by inputting a PIN number using the keyboard of the terminal.
52. The target card 41 is inserted into the interface 45 of the terminal 42.
53. The chip 44 receives from the target card: a) the serial number of the target card; b) the public cryptographic key of the target card; and c) a cryptographic certificate issued by a certification authority. Provision of the public key and/or the certificate is prefened but may be omitted in some implementations of the invention.
S4. The chip 44 validates the cryptographic signature of the public key. S5. The customer details are transmitted from the database 50 in encrypted form to the terminal 42 via network 48 and interface 46.
56. The generic application is transmitted from the application issuer 43 to the terminal 42 via network 48 and interface 46.
The chip stores the code and data of the generic application in the unit stores 516, 517, 518 and 519. The chip stores the customer data in the buffer store 521. If the data representing the generic application and/or the customer data is too big to store in the chip 44, it may be stored in the terminal. The terminal may be insecure, in which case the data is stored in the terminal in encrypted form.
Data, which is transmitted to the terminal and chip via the network 48, is encrypted using a transport key. The data is decrypted using a transport key previously stored in the key store 512 of the chip. Referring to Figure 9:-
57. The chip 44 builds the ALUs and
58. Loads them into the target card 41, the terminal merely transferring the ALUs unmodified to the target card.
Steps S7 and S8 are described in more detail below.
59. The chip records in the log store 511 the serial number of the target card into which the ALUs are loaded. The loading may be unsuccessful. The chip also records in the log store whether the loading was successful or not. The log store may also record the date of loading. It may also store data identifying the application(s), which are loaded.
S10. The chip and terminal transmit the contents of the log store to the Application issuer 43 via the network 48. The issuer 43 may check the log transmitted to it. The log is not deleted from chip builder until the application issuer has acknowledge conect receipt of the log. SI 1. The chip may receive from the issuer 43 a new script or program for storage in store 514 and/or one or more generic application units for storage in unit stores 516 to 519.
Because the personalised application is built at the terminal by the chip 44, the bandwidth of the communications link may be smaller than if the personalised application is transmitted from the central system to the terminal. This is because it is then necessary to send the generic application, which may be large only once (and then send each individual instance of the specific data. If pre-built applications are sent by the central system, the specific data combined with the generic application is sent many times. Example 2.
In a cunently prefened embodiment, the chip 44 and terminal are either not connected to the network 48 or operate without using the network 48. The chip 44 contains all the data it requires without needing to use the network 48. For example the chip 44 is programmed with all the data before it is installed in the terminal. The operation of the terminal and chip is as described in Example 1 except that steps S5, S6 and SI 1 are omitted. The customer details are pre-stored in store 521 and the generic application are pre-stored in stores 516 to 519. Alternatively, the customer details and generic application are stored encrypted in the terminal. Step S7. Building ALUs
ALUs
An ALU comprises one or more Application Program Data Units (APDU) defined in ISO 7816 and the ALU is transmitted using the ISO 7816 protocol. Each
APDU has a header and a data container. Each APDU contains upto 255 bytes of data. An ALU may contain many kilo bytes of data and thus may comprise many tens of
APDUs.
The chip 44 creates target APDUs to be loaded into the target smart card. In a prefened embodiment, the generic application is stored in the form of APDUs which are ready to be run on the target card.. The APDUs of the generic application are loaded into the Central Processor Unit 513 of the chip 44. To load the APDUs into the CPU 513 load APDUs are created. The load APDUs wrap the APDUs of the generic application as shown in Figure 7. That fs the generic APDUs are contained in the data containers of the load APDUs to be loaded into the CPU 513 The load APDUs contain load commands.
The Central Processor Unit 513 of the chip 44 prepares the "Application Load
Unit" using a generic "Application Load Unit" held in unit store 515 which is personalised using the customer data and the generic application provided by the issuer
43 which is stored as code in code store 516, data in data store 517, an application signature stored in store 518 and, preferably, a session key in store 519.
The preparation of the Application Load Unit includes enciphering any data and code that need to be confidential using the public key obtained from the target smart card. Those skilled in the art will be aware of the different ways of doing this including the use of session keys.
The authenticity of the public key is verified in a previous step using the certificate of the public key.
The application signature is a known digital signature method, which allows the detection of any illicit interference with the code and data. The signature is dependent on the data associated with the signature. By dynamically iii) recalculating the signature and by enciphering the data as in i) and ii) above, the code and data is further protected during the transfer from the terminal to the target card. Also the confidentiality and authenticity of the data is ensured. A load certificate is sent to the target card with the application to be downloaded.
Step S8.- loading the APDUs into the target card
The terminal includes the processor 6 shown in Figure 2. The processor 6 and chip 44 operate together according to a transfer program to transfer APDUs from the chip 44 to the target card. The processor 6 of the terminal may contain the entire transfer program and control the transfer, interacting with the chip 44. Alternatively, the chip 44 may contain the entire transfer program, the processor 6 of the terminal containing sufficient instructions to be controlled by the chip 44.
In outline, one example of the transfer program, which is contained in the terminal, operates as follows. The terminal reacts to the insertion of a target card into the user card interface 4 of Figure 2 to boot up the card, and read from it target card data required by the chip 44 to build an application for transfer. Such target card data may include, inter alia, the serial number and identity of the operating system of the target card. The terminal then boots up the chip 44 and sends the target card data to the chip 44. The terminal then gets an APDU created by the chip 44 transfers it to the target card, and receives from the card a result and reports the result to the chip 44. That process is repeated for all the APDUs to be transfened.
The target smart card reads the code and data transfened to it via the terminal 42. The target card verifies that the download is legitimate by examining the load certificate; verifies the application signature to detect any interference with the data; and deciphers the data using methods which are known to those skilled in the art. The target card then operates in accordance with the code and data transfened to it in the target APDUs. Example 3
Some target cards comprise a memory device (and no processor), and preferably also some logic circuitry, for example cryptographic access logic, for detemng illicit access to stored data. For such "memory only smart cards", the terminal 42 transfers the data from the chip 44 to the target card. However on the memory only target smart card there is no concept of APDUs; instead the target chip has a hardwired bus protocol such as I2C. The I2C protocol is a common serial memory protocol. For memory only cards, the chip 44 builds a data image, and provides access codes if the memory card has some hardwired access logic. Summary
Example 2, in which a preprogrammed smart card chip 44 is used in a standard smart card terminal to load ALUs into a target smart card, allows an organisation, such as a Bank, to experiment with new applications in smart cards without the need to set up or use an expensive support system having a customer database and a server linked to the terminal by a communications network. Small numbers of target smart cards can be economically programmed. Also target cards already issued to customers can be easily and inexpensively reprogrammed at existing terminals equipped with the chip 44 without the need for the expensive support system. The terminals do not need to be connected to expensive networked infrastructure. Existing terminals can be used with only the provision of the chip 44 and perhaps a minor modification of the software in the terminal to operate with the chip 44. The terminals can be insecure because the chip 44 incorporates the essential security.
Example 1 which uses the central host system allows issued target cards to be securely reprogrammed at insecure terminals by installing the chips 44 in the terminals. Example 1 has the advantages that: the bandwidth needed to transfer data from the central system to the target card is reduced; insecure terminals can be used; and existing terminals can be used with only the provision of the chip 44 and perhaps a minor modification of the software in the terminal to operate with the chip 44. The terminals can be insecure because the chip 44 incorporates the essential security. Computer Program Product
It will be appreciated that, in one aspect, the invention provides a computer program product which is loaded into e.g. a standard smart card chip having a processor as described above and which when run on the chip when installed in a suitable terminal allows the chip to create and load ALUs into a target smart card as described above. Such a program product may be supplied on a data carrier, such as in a smart card as described above. It may be supplied on other data carriers for down loading into a smart card chip. It may be supplied over a, preferably secure, data transmission system.
Modifications The foregoing description refers by way of example to MULTOS. However other high security operating systems such as JAVACARD and NOP are known and could be used.
In the foregoing illustrative description, a generic application is personalised with customer specific data and the resulting personalised application is downloaded into a target card. That process may be repeated for many target cards for respective customers having different customer data. However the invention is not limited to that. The invention may be used to download, to every card of a batch of target cards, the same generic application "personalised" with data which is common top the batch.
An example of that is producing a batch of cards all having the same bank sort code, the sort code being the personalising data. Furthermore the invention may be used to download to a batch of cards, or to individual cards, a generic application. The invention may then be used again, at a later time, to personalise the generic application, which has already been downloaded.
The operating systems of the chip 44 and the target card may be different. Thus in an embodiment of the invention, when the target card is inserted into a terminal for the downloading of a new application, the identity of the target card's operating system is transfened from the target card to the chip 44. The chip 44 then creates target
APDUs consistent with the operating system of the target card.
Referring to Figure 2, the terminal may be a mobile phone the communications interface being the transmitter/receiver of the mobile phone. Such a mobile phone has two card interfaces, one for the SIM for operating the phone and another for another card, e.g. a SIM acting as an e-commerce device, e.g. an electronic wallet. The chip
44 of the invention may be built into the SIM for operating the phone, whereby the chip 44 can download new applications into the other card.
The chip 44 is most preferably a smart card chip because of the security such a chip provides. However, at least in principle the chip 44 may be an "ordinary" insecure microprocessor: The invention would operate with such an ordinary microprocessor but would not be secure. Security of an ordinary microprocessor could be enhanced by cryptography and by encasing the microprocessor in a secure housing. The chip 44 could be incorporated in, or integrated in, the processor 6 of the terminal 42 of Figure 2. Such a terminal would have only one processor, rather than two as in the embodiments described above. The single processor would carry out the functions of the present invention.
The personalising data could be entered using a keyboard 12 of the terminal rather than being prestored in the terminal and/or chip 44 or being downloaded from the central data processing system.
Some of the embodiments described above combine a generic application with personalising data and download the combination into the target card. Other embodiments combine a generic application with data common to a batch of cards and download the combination to the batch. In a further embodiment, a personalised version of the code of an application is built by taking a generic application and adding or deleting code or applets from it. In essence, a set of functions are added or removed from the generic application for a specific target card or batch of target cards. Such a personalised version of the generic application may be combined with personalising data as described above. The personalised version and/or the combination of it with data is downloaded into a target card as described above. Provision of such personalised versions of generic applications requires conesponding load certificates.

Claims

1. A method of programming a portable data canier comprising the steps of: providing a terminal having a first interface for interacting with a target portable data canier, the terminal including a processor; the processor or the combination of the terminal and the processor having data storage; storing in the said data storage one or more of a generic application and data for personalising the generic application for the carrier to be programmed; using the processor to create a load application or load data for loading into the target canier, the load data or load application being derived by the processor from the stored generic application or personalising data; and using the combination of the processor and terminal to load the load data or load application into the target canier via the first interface.
2. A method according to claim 1, wherein the load application is derived from the generic application by adding to it or removing from it code for implementing one or more functions.
3. A method according to claim 1 or 2, comprising the step of using the said processor to create, from the generic application and the personalising data, a personalised load application for loading into the target carrier.
4. A method according to claim 1, comprising the step of using the processor and terminal to load a generic application as the load application into the target carrier.
5. A method according to claim 1 or 2, comprising the step of using the processor to create, for a batch of target earners, the same personalised load application from a generic application and personalising data common to the batch of target caniers, and the step of using the combination of the terminal and the processor to load the said same load application into the batch of target carriers.
6. A method according to any preceding claim, wherein the said processor comprises a smart card integrated circuit.
7. A method according to any preceding claim, comprising the step of storing the generic application as application program data units (APDUs) in the said storage.
8. A method according to claim 7, wherein the processor has a central processing unit, and comprising the step of wrapping the said APDUs of the generic application in load APDUs for loading into the central processing unit of the processor.
9. A method according to any preceding claim, comprising the step of combining the load application and the personalising data according to predetermined rules
10. A method according to claim 9, wherein the said rules are stored in the processor.
11. A method according to claim 9 or 10, comprising the step of changing the rules.
12. A method according to any preceding claim wherein the said storage is in the said processor.
13. A method according to any one of claims 1 to 11, wherein the said storage is in the said terminal.
14. A method according to claim 13, wherein the generic application and/or the personalising data is stored in the said storage in the terminal in encrypted form.
15. A method according to any preceding claim comprising the step of installing the processor in the terminal.
16. A method according to claim 15, wherein the generic application and /or the said personalising data is stored in the processor before installation of the processor in the terminal.
17. A method according to any preceding claim, comprising the step of dynamically recalculating an application signature.
18. A method according to any preceding claim, comprising the step of verifying a cryptographic certificate associated with a public key of the target carrier.
19. A method according to any preceding claim, comprising the step of dynamically enciphering a session key and associated data using a public key of the target carrier.
20. Apparatus for programming a portable data carrier, comprising: a terminal having a first interface for interacting with a target portable data carrier; a processor installed in the terminal; the processor or the combination of the terminal and the processor having data storage; the said data storage being ananged to store a generic application and data for personalising the generic application for the carrier to be programmed; and the processor being ananged to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and the combination of the processor and terminal being ananged to load the load data or load application into the target carrier via the first interface.
21. A system for programming portable data carriers, comprising: at least one terminal, the or each terminal having a first interface for interacting with a target portable data canier, and a processor installed in the terminal, the processor or the combination of the terminal and the processor having data memory, the said data memory being ananged to store a generic application and data for personalising the generic application for the canier to be programmed, and the processor being ananged to create a load application or load data for loading into the target canier, the load data or load application being derived by the processor from the stored generic application or personalising data and the combination of the processor and terminal being ananged to load the load data or load application into the target canier via the first interface; a data storage system storing at least one generic application and data for personalising the or each generic application; and a communications system linking the data storage system to the terminal or terminals for transfening a generic application and personalising data to the combination of the terminal and processor for storage in the said data memory.
22. An apparatus or system according to claim 20 or 21, wherein the processor is a smart card integrated circuit.
23. Apparatus, device or system according to claim 20, 21 or 22, wherein the terminal has two processing devices, one being the said processor.
24. Apparatus, device or system according to claim 23, wherein the terminal comprises a single processing device which incorporates the said processor.
25. A processing device for use in a terminal for programming a portable data canier, the processing device comprising a smart card chip including a processor and data storage, the chip being programmed to create a load application or load data for loading into the target canier, the load data or load application being derived by the processor from the stored generic application or personalising data; and to load the load data or load application into the target canier via the first interface.
26. A device according to claim 25, wherein the processor is a smart card integrated circuit
27. Apparatus, device or system according to any one of claims 20 to 26 wherein the processor is arranged to derive the load application from the generic application by adding to it or removing from it code for implementing one or more functions.
28. Apparatus, device or system according to any one of claims 20 to 26 wherein the said processor is ananged to create, from the generic application and the personalising data, a personalised load application for loading into the target carrier.
29. Apparatus, device or system according to any one of claims 20 to 26 wherein the said processor and terminal are arranged to load a generic application as the load application into the target carrier.
30. Apparatus, device or system according to any one of claims 20 to 26 wherein the said processor is ananged to create, for a batch of target carriers, the same personalised load application from a generic application and personalising data common to the batch of target carriers, and to use the combination of the terminal and the processor to load the said same load application into the batch of target caniers.
31. Apparatus, device or system according to any one of claims 20 to 30, wherein there is defined in the said storage a storage area for cryptographic keys.
32. Apparatus, device or system according to any one of claims 20 to 31, wherein there is defined in the said storage and a storage area for a program script.
33. Apparatus, device or system according to any one of claims 20 to 31, wherein there is defined in the said storage at least one storage area for a generic application load unit.
34. Apparatus, device or system according to any one of claims 20 to 33, wherein there is defined in the said storage, a storage area for logging execution steps.
35. Apparatus, device or system according to any one of claims 20 to 34, wherein there is defined in the said storage an area for storing Application Load Certificates or load keys.
36. A method of programming portable data carriers in a system comprising: at least one terminal, the or each terminal having a first interface for interacting with a target portable data canier, and a processor installed in the terminal, the processor or the combination of the terminal and the processor having data memory; a data storage system storing at least one generic application and/or data for personalising the or each generic application; and a communications system linking the data storage system to the terminal or terminals; the method comprising the steps of: transferring a generic application and/or personalising data to the combination of the terminal and processor for storage in the said data memory, storing the transfened generic application and/or personalising data in the said data memory; using the processor to create a load application or load data for loading into the target canier, the load data or load application being derived by the processor from the stored generic application or personalising data; and using the combination of the processor and terminal to load the load data or load application into the target carrier via the first interface.
37. A method according to claim 36, wherein the load application is derived from the generic application by adding to it or removing from it code for implementing one or more functions.
38. A method according to claim 36 or 37, comprising the step of using the said processor to create, from the generic application and the personalising data, a personalised load application for loading into the target carrier.
39. A method according to claim 36, comprising the step of using the processor and terminal to load a generic application as the load application into the target carrier.
40. A method according to claim 36 or 37, comprising the step of using the processor to create, for a batch of target caniers, the same personalised load application from a generic application and personalising data common to the batch of target caniers, and the step of using the combination of the terminal and the processor to load the said same load application into the batch of target carriers.
41. A method according to any one of claims 36 to 40, wherein the said generic application and/or the said personalising data is transfened from the said data processing system to the said combination using the XML protocol.
42.- A method according to any one of claims 36 to 41, comprising the step of remotely updating a script stored in the processor via the said communications system.
43. A method according to any one of claims 36 to 42, comprising the step of remotely updating the generic application via the said communications system.
44. A method according to any one of claims 36 to 42, wherein the said generic application is stored in storage in the terminal in encrypted form.
45. A method according to any one of claims 36 to 44, wherein the said personalisation data is stored in storage in the terminal in encrypted form.
46. A computer program product for running on a smart card chip having a processor and data memory, the product being ananged, when run on the chip, to access a generic application and personalising data stored in the data memory, to create a load application or load data for loading into the target carrier, the load data or load application being derived by the processor from the stored generic application or personalising data; and to cause the load data or load application to be loaded into the target canier.
47. A product according to claim 46, wherein the load application is derived from the generic application by adding to it or removing from it code for implementing one or more functions.
48. A product according to claim 46 or 47, ananged to create, from the generic application and the personalising data, a personalised load application for loading into the target carrier.
49. A product according to claim 46, ananged to load a generic application as the load application into the target carrier.
50. A product according to claim 46 or 47, ananged to create, for a batch of target caniers, the same personalised load application from a generic application and personalising data common to the batch of target carriers, and to cause the said same load application to be loaded into the batch of target caniers.
51. A product according to claim 46, ananged to implement the step of using the said processor to create, from the generic application and the personalising data, a personalised application for loading into the target carrier.
52. A product according to any one of claims 46 to 51, ananged to implement the step of storing the generic application as application program data units (APDUs) in the said data memory.
53. A product according to claim 52, for use with a processor having a central processing unit the product being ananged to implement the step of wrapping the said APDUs of the generic application in load APDUs for loading into the central processing unit of the processor.
54. A product according to any one of claims 46 to 53, arranged to implement the step of combining the generic application and the personalising data according to predetermined rules
55. A product according to any one of claims 46 to 54 , ananged to implement the step of dynamically recalculating an application signature.
56. A product according to any one of claims 46 to 55, arranged to implement the step of verifying a cryptographic certificate associated with a public key of the target carrier.
57. A product according to any one of claims 46 to 56, ananged to implement the step of dynamically enciphering a session key and associated data using a public key of the target carrier.
PCT/GB2000/004958 2000-01-19 2000-12-21 Programming data carriers WO2001054086A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001222074A AU2001222074A1 (en) 2000-01-19 2000-12-21 Programming data carriers

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB0001230A GB0001230D0 (en) 2000-01-19 2000-01-19 Smart card application builder system
GB0001230.2 2000-01-19
GB0021457.7 2000-08-31
GB0021457A GB2358500A (en) 2000-01-19 2000-08-31 Programming data carriers

Publications (1)

Publication Number Publication Date
WO2001054086A1 true WO2001054086A1 (en) 2001-07-26

Family

ID=26243430

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2000/004958 WO2001054086A1 (en) 2000-01-19 2000-12-21 Programming data carriers

Country Status (2)

Country Link
AU (1) AU2001222074A1 (en)
WO (1) WO2001054086A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10328238A1 (en) * 2003-06-24 2005-01-20 Giesecke & Devrient Gmbh Chip card initialization and personalization method in which chip card data is loaded using a common PC and read-write units that contain stored data blocks in which a part of the data to be loaded is stored
EP1942470A1 (en) 2006-12-29 2008-07-09 Legic Identsystems AG Authentication system
WO2011095337A1 (en) * 2010-02-05 2011-08-11 Giesecke & Devrient Gmbh Completion of portable data carriers
EP2405409A1 (en) * 2010-07-06 2012-01-11 Gemalto SA Interconnected standalone multiprocessor devices, and adapted customisation method
US11010652B2 (en) 2019-05-09 2021-05-18 Capital One Services, Llc Orientationless chip layout for a transaction card

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4855578A (en) * 1986-08-28 1989-08-08 Kabushiki Kaisha Toshiba Portable storage medium processing system
US5036461A (en) * 1990-05-16 1991-07-30 Elliott John C Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
WO1997039424A1 (en) * 1996-04-15 1997-10-23 Ubiq Incorporated System and apparatus for smart card personalization
WO1998052162A2 (en) * 1997-05-15 1998-11-19 Mondex International Limited Secure multiple application card system and process

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4855578A (en) * 1986-08-28 1989-08-08 Kabushiki Kaisha Toshiba Portable storage medium processing system
US5036461A (en) * 1990-05-16 1991-07-30 Elliott John C Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
WO1997039424A1 (en) * 1996-04-15 1997-10-23 Ubiq Incorporated System and apparatus for smart card personalization
WO1998052162A2 (en) * 1997-05-15 1998-11-19 Mondex International Limited Secure multiple application card system and process

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10328238A1 (en) * 2003-06-24 2005-01-20 Giesecke & Devrient Gmbh Chip card initialization and personalization method in which chip card data is loaded using a common PC and read-write units that contain stored data blocks in which a part of the data to be loaded is stored
DE10328238B4 (en) * 2003-06-24 2013-03-14 Giesecke & Devrient Gmbh Method for loading smart cards with initialization and / or personalization data
EP1942470A1 (en) 2006-12-29 2008-07-09 Legic Identsystems AG Authentication system
WO2008080909A1 (en) * 2006-12-29 2008-07-10 Legic Identsystems Ag Authentication system
CN101583982B (en) * 2006-12-29 2013-01-23 励智识别技术有限公司 Authentication system
US9064365B2 (en) 2006-12-29 2015-06-23 Legic Identsystems Ag Authentication system
WO2011095337A1 (en) * 2010-02-05 2011-08-11 Giesecke & Devrient Gmbh Completion of portable data carriers
US9076280B2 (en) 2010-02-05 2015-07-07 Giesecke & Devrient Gmbh Completion of portable data carriers
EP2405409A1 (en) * 2010-07-06 2012-01-11 Gemalto SA Interconnected standalone multiprocessor devices, and adapted customisation method
WO2012004025A1 (en) * 2010-07-06 2012-01-12 Gemalto Sa Interconnected autonomous multiprocessor device, and adapted customization method
US11010652B2 (en) 2019-05-09 2021-05-18 Capital One Services, Llc Orientationless chip layout for a transaction card

Also Published As

Publication number Publication date
AU2001222074A1 (en) 2001-07-31

Similar Documents

Publication Publication Date Title
US7707408B2 (en) Key transformation unit for a tamper resistant module
GB2358500A (en) Programming data carriers
US6230267B1 (en) IC card transportation key set
EP0985203B1 (en) Key transformation unit for an ic card
US7917760B2 (en) Tamper resistant module having separate control of issuance and content delivery
US5923759A (en) System for securely exchanging data with smart cards
EP0981807B1 (en) Integrated circuit card with application history list
US7523495B2 (en) Methods and systems for IC card application loading
US20040025021A1 (en) Smart card and settlement terminal
KR101968156B1 (en) Mobile terminal, transaction terminal, and method for carrying out a transaction at a transaction terminal by means of a mobile terminal
JP2002507297A (en) Payment methods and systems
US6662151B1 (en) System for secured reading and processing of data on intelligent data carriers
WO1999040549A1 (en) System and method for controlling access to computer code in an ic card
WO2001054086A1 (en) Programming data carriers
EP0807907A1 (en) System for securely accessing data from smart cards
US20060156001A1 (en) Personalisation of security modules
JP2000507380A (en) Safety module
KR100198825B1 (en) Electronic money-bag terminal

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP