MXPA98007968A - Method of safe loading of commands on an intelligent card - Google Patents

Abstract

The invention relates to the method of secure loading and validation of commands on a smart card, especially in the case where the specific request commands are loaded by a request provider, i.e., devices that are not in line with Regarding the issuer of the card, you must ensure that the commands are valid, the invention provides a method that involves the protection of the commands by means of the authentication codes, these codes being produced using two different keys: a key is stored by the issuer of the card, the other by a trusted third party, a further authentication code, produced using a key from a set of keys, can be used to selectively validate the commands for individual requests

Description

METHOD OF SECURE CARD OF EM COMMANDS AN INTELLIGENT CARD BACKGROUND AND BRIEF DESCRIPTION The present invention relates to a method for loading commands into a smart card. More specifically, the present invention relates to a method for loading application-specific commands out of order on a smart card. In modern payment systems »the use of electronic means of payment becomes increasingly important. Electronic payment means, such as memory cards or smart cards, are gaining acceptance as their applications expand. In many countries electronic cards are being used for public telephones and the like. More advanced cards are able to contain electronic "bags" in addition to other functionalities. Such advanced payment means contain "in addition to a memory" a processor capable of running adaptive programs. It should be noted that in this text "the terms smart card or card will be used to denote electronic payment means having at least one integrated electronic circuit comprising a processor and a memory. The current form of the so-called smart card is not important. The programs that run in the processor of a smart card determine the services offered by the card »that is» the functions and structures of the associated data (for example »bag, user identification, fidelity program) of the smart card it depends on the software present on the card. As time passes, "the need usually arises in updating card programs", for example, in order to add new functions to improve an existing function. At this extreme, the student should be able to accept new programs which can be replaced by other programs. However, it must be ensured that the new programs loaded are valid. The authentication of the programs may be relatively easy to achieve by using a protocol for secure data exchange between a card issuer and the card. However, "other parties" such as request providers "will want to be able to load new applications (and therefore new commands) into a card without having to do this via the card issuer.

Bf-EYE PESGRIPC3CPN PE INATIO It is an object of the invention to overcome the disadvantages mentioned above and others and to provide a method which allows commands to be loaded and activated on a smart card in a secure manner. Another additional object of the present invention is to provide a method which allows specific application commands to be loaded on a smart card through an application provider at the same time as being able to guarantee the integrity of the commands. These and other objects are achieved by the secure command loading method on a smart card on the one hand, the card being edited on the other hand, and the method according to the invention comprises the steps of: a second part which produces a first code of authenticity of the command using a first key »a third party that produces a second code of authenticity of the command using a second key» transfer of commands with the codes of the card »the card validating the command by the reproduction of the first and second code of authenticity using the first and second keys respectively and comparing the reproduced codes with the transferred codes. In the method of the present invention * the authenticity of the commands is then safeguarded by having two different parts and preferably i dependent which produces a code of authenticity: the second part, which is usually the card issuer »and the third part »which is usually a reliable independent party, such as the central bank. Once both authenticity codes have been produced * it is virtually impossible to alter the commands without this being noticed by the means of authenticity codes. The first part »the application provider» has proof that the first and second part have "certified" the command. Preferably the third part stores copies of the command. It will be understood that the method of the invention applies to both the loading of single commands and the loading of a set of commands. The transfer of the card has a subsequent validation and are preferably repeated when the validations fail »the use of the loaded commands being blocked until the validation happens. This prevents the invalidation of the commands »ie, the commands affected by transmission errors or manipulations »to be executed by the card. Advantageously »the loaded commands are permanent when the validation fails a predetermined number of times» the number being preferably less than 10. The disabling of the loaded commands can be executed by changing the key of the second part. In this way »the indefinite reload of adulterated commands can be completed. The loaded commands can be specific application commands »that is, commands that directly influence the applications of the card. Such commands are commonly used in machine language, which in principle allows the manipulation of card applications. By the use of the method of the present invention, the use of such commands is controlled and ensured by means of the integrity of the applications. The first and / or second code authenticity are preferably authenticated code messages produced according to the standardization of the IAEN. American National Standardization Institute (American National Standardization Inst tute) X9.19. Advantageously »an additional authentication code is produced by the second part» said additional code does not involve the first or second key. This allows the first party a valuation review without the influence of the method as such.

BRIEF DESCRIPTION PE LQS PIBUJQS Figure 1 shows a smart card as it can be used in the method of the present invention. Figure 2 schematically shows the integrated circuit of the smart card of Figure 1. Figure 3 shows schematically the exchange of data in the method of the present invention. Figure A schematically shows the structures of the data on a smart card. Figure 5 schematically shows a flag recorder as used in the method of the present invention. Figure 6 schematically shows an illustrative embodiment of the method of the present invention.

DETAILED DESCRIPTION OF PREFERRED MODALITIES The smart card or TI 1 shows by way of example in Figure 1 comprises a substrate 2 in which an integrated circuit is embedded. The integrated circuit is provided with contact 3 to contact a card reader or the like. It should be noted that the present invention can also be applied in the case of so-called contactless smart cards. The integrated circuit 10 shows schematically and by way of example in FIG. 2 comprising a proctor 11. a memory 12 and an input / output circuit 13. The memory may comprise a volatile memory (RAM) partial memory for the data that is They store temporarily and a non-volatile memory (ROM) to store data sem permanently or permanently. The last part is preferably a type of EEPROM memory. The data stored in the non-volatile part can contain both programming data (instructions, programs) and payment data, that is, data related to monetary transactions. It will be understood that the separate memory (not shown) can be provided to store the instruction set of the processor 11. The input-output circuit 13 can communicate with external devices via the contact (not shown in Figure 2) • such as the contact 3 shown in figure 1. The integrated circuit 10 can be contained in card 1 of figure l. An embodiment of the method according to the invention is shown schematically by means of the example in figure 3. A first part »for example a PS application provider» offers functions of the card to its customers. An IT smart card is issued by the second party »an ET card issuer. According to the invention »a reliable third party TPC is involved in the validation of the commands» as is explained later. A COM command set may be produced by the issuer of the ET card or by any external source on the order of the PS request provider. It should be noted that the COM command set may comprise one or more commands. This is the method as described here can be applied to individual commands or to a set of commands. In the following description a single command plus a set will be used as an example to explain the method of the invention. The commands can be ßer specific commands in the request (CES) or general purpose commands (CPG). As shown in figure 3, the PS request provider offers a command (COM) to the ET card issuer for authentication. A first ACl code authentication »based on the COM command» is produced by the transmitter of the ET card using a first key Kl. Even more for the ACl code the command set can optionally receive a additional authentication code AC4 (four) which does not involve the use of a key »at least not the key Kl. The additional authentication code AC4 works to provide an additional verification to the command »regardless of the keys used in the order of the authentication codes. The computation of the additional authentication code AC4 may involve the first ACl authentication code. In this case »the additional authentication code can be written as CA4 = F ^ OM» CAI), where F denotes a function by which the code is determined. The authentication of the code CAI »and optionally the additional authentication of the CA4 code» is transferred to the PS request provider »where it is temporarily stored. According to the present invention, the COM command is also offered to a trusted third party TPC. The third part produces a second authentication of the CA2 code of the COM command »using a second key K2. The second authentication of the CA2 code is transferred to the PS request provider. The third part is for example a central bank or an institution included in the issuer of the card and the service provider. The PS request provider can produce a third authentication code CA3 using a third key K3. It should be noted that the key K3 may comprise a set of keys (as denoted by the asterisk) "each individual key corresponding within an individual card request and / or an individual card file. The key K3 »which can thus consist of a set of K3-1 keys. K3-2. etc. »can be used to selectively load commands into a specific request and / or files on the card. This will also be explained in reference to figures 4 and 5. It should be noted that the third key (K3) may vary between requests »the third authentication code (CA3) also varies. This is »the third authentication code (CA3) can constitute a specific request authentication code. It should be noted that the third authentication code can be checked in both the COM command and the first and second authentication codes, thus providing double authentication. In this case, a third authentication code can be written as MAC3 = FK3 (C0M, CAI, CA2), where F denotes a function by which the code is determined. The authentication codes CAI and CA2, as well as the authentication codes CA3 and CA4 »are preferably produced using authentication message schemes involving the designation of digits. Such a scheme is for example »written in the standard IAEN (ANSI) X9.19. It will be understood that the current scheme (or schemes) used in producing the message of the authentication codes is not essential to the present invention. The additional authentication code can also be produced using encryption (for example using a public key, or it can be produced using the so-called arbitrary element selection function) CAI and CA2 authentication codes as well as optional CA3 authentication codes and CA4 »canN be attached to the command, or be associated with the command in another way.In figure 3. the command and its associated authentication codes ß denote by: COM, CAI, CA2 C.CA3, CA4-1, loe bracket indicate the optional codes The current order in which the command and its codeßassociatedßbe transferred tran can of course vary.When receiving the command by the card CS »the card reproduces the authentication codes CAÍ and CA2 using the keys Kl and K2 which have been saved on the card previously The codes reproduced CAÍ 'and CA2"are compared with the codes received CAÍ and CA2. reproduced and received are identical »the validation of the commands has been successful and the commands can be activated. This activation can be done by assigning (or reallocating) a certain flag). If the validation fails, that is, if the corresponding codes received and reproduced are not identical, a request for retransmission of commands may be issued. A retransmit counter keeps track of the number of retransmissions and inhibits retransmission if a predetermined number (for example 5) is exceeded.

The card is therefore preferably arranged in such a way that the commands loaded inside the card can not be used until they are activated. That is, the loaded commands are blocked until they are released as a result of a positive validation. This prevents the invalidated commands from being executed by the card. Figure 4 schematically shows the structure β of the data in a smart card "such as card 1 of figure 1. according to the preferred embodiment of the present invention. The structure of the data is saved in practice in a memory, such as the memory 12 of FIG. 2. A master file called AM contains »among others» references for other files. Other files are associated with individual ap ica ons. In Figure 4, they show several called application files (AA1, AA2 »AA3). Each request (or request file) ASI »AS2 may comprise one or more ßubarchivoß, for example, program files and data files. As shown in Figure 4, each request contains a corresponding key: application 1 contains the key K3-1, application 2 contains the key K3-2, etc. These keys K3-i correspond with the keys K3-i of the set of keys K3 * of figure 3 (and denoting the ith ßolici ud). As mentioned before, the card was able to regenerate authentication codes (for example ACl »AC2) of a command. using one or more keys (for example Kl, K2). and to compare the regenerated codes (for example AC1, AC2) with codes received in order to verify the received commands. This is if the regenerated and received authentication codes (for example CA2 and CA2 ') do not match »the corresponding command is not loaded inside the card» or at least is assured of execution. Similarly, the key of the K3 * game can be used to select the command load in the individual requests, the object request (for example PS2) being indicated by the corresponding key (for example K3-2). In case a certain command must be loaded in more than one request, the K3 key may contain an unused card. As illustrated in figure 4, the master file AM contains a registration flag BR. In Figure 5, the BR eß region flag interpreted in greater detail. The flag region BR comprises a plurality of flags F-1, F-2, ... of for example one bit each. Each flag corresponds to the processor command (11 in figure 2) of the card. The processor and / or its software is arranged in such a way that the execution of the command is inhibited if its corresponding flag is placed. The update command, which updates the memory site »can for example only be executed if F-3 is placed. Thus an additional protection is provided against the inadvertent or unauthorized execution of (specific application) commands.

The flag recorder can be controlled by an appropriate command, for example the flag-i-array, where i is the flag number. If the commands concerned ßon command of ßpecific request, all ß banderee ßon preferably arranged at the beginning, in this way preventing the execution of the specific commands of the solitude. A flag can be reestablished by the command validation command (for example, validation), ie if the authenticity of the commands has been verified and the execution of the command is allowed. It will be understood that the BR flag recorder may be located in other files than that of the AM master file, and that more than one flag recorder may be contained in a card. The flow chart of Figure 6 schematically shows one embodiment of the method of the present invention. On page 100, the procedure is initialized. Eßto can involve the production of one or more commands and offer the command for the PS request provider, which can instead transfer the command to the ET card issuer and the third part of the TPC. In step 101, the transmitter of the ET card produces a first authentication code CAI of the command (COM in FIG. 3) using the first key Kl. The CAI code is transferred to the PS request provider. The command could have been transferred to the transmitter of the ET card in step 101 or previously, for example in page 100.

Similarly, in step 102, the third part TPC produces a second authentication code CA2 of the command (COM in Figure 3) using the second key K2. The code CA2 is transferred to the PS request provider. The command may be transferred to the third party in step 102 or previously, for example in step 100. In step 103, the PS request provider transfers the COM command with the associated authentication codes CAI and CA2 to the smart card TI (cf figure 3). In step 104, the TI smart card essentially reproduces the codes CAÍ and CA2 by producing authentication codes CAlr and CA2f of the COM command. using the keys Kl and K2 respectively. In step 105 »the code reproduced CAÍ 'is compared with the code received CAÍ. If the codes are the same »the control is transferred in page 106, otherwise the procedure is evicted. If the procedure is evicted, the COM command received by the eß card is effectively inhibited »either by deleting the command or by installing a flag on the flag recorder. A retransmission of the COM command and its associated authentication codes may be required. Preferably the number of retransmissions is monitored and the retransmission can be terminated if the try number exceeds a predetermined number "for example" three or five. In page 106, the reproduced code CA2 »is compared to the received code CA2. If the codes are equal, the control is transferred to page 107, otherwise the procedure is evicted. In step 107, the smart card IT gives capability to the COM command, for example for the restoration of a corresponding flag in the RB flag recorder (see figure 5). The COM command can now be invoked and executed. On the 10T page, the procedure ends. In the diagram of figure 6, only essential steps of the preferred embodiment have been shown. Additional steps, such as the determination and evaluation of the third and fourth authentication codes CA3 and CA4, have been omitted for the purpose of clarity. It will then be understood by those skilled in the art that the modalities described above are given by way of example only and that any modification or addition is possible without departing from the scope of the present invention.

Claims (12)

NQYEPAP PE THE INVENTION CLAIMS

1. - A method of secure command loading (COM) on a smart card (IT) by a first party (PS) »the card (IT) being issued by a second party (ET). the method comprising the steps of: the second part (ET) that produces a first authentication code (CAI) and a command using a first key (Kl). a third party (TPC) producing a second authentication code (CA2) of the command using a second key (K2), transferring the COM command with the codes (CAI, CA2) to the card, the card (IT) which gives validation to the (COM) command by reproducing the first (CAI) and the second (CA2) authentication code using the first (Kl) and second (K2) keys respectively and comparing the reproduced codes (CAÍ ', CA2') with the transferred codes (CAI, CA2).

2. The method according to claim 1, further characterized in that the transfer of the card (TI) and the subsequent validation are repeated when the validation fails, the use of a loaded command (COM) being blocked until the validation has success.

3. The method according to claim 2 »further characterized in that in the loaded command (COM) eß permanently deßhabi litated ßi the validation fails in a predetermined number (N) of times» the number (N) preferably being less than 10.

The method according to the claim 3 »further characterized in that the disabling is executed by the card (l) by changing the key (Kl) of the second part (ET) stored in the card.

5. The method according to any of the conformities with the previous claims, characterized in that in the command (COM) is a command of ßpecitud specific request (CSE).

6. The method according to any of the ß conformity of the preceding claims further characterized in that the first (CAI) and / or second (CA2) authentication code are message authentication codes produced according to the standardization of IAEN (ANSI) X9.19.

7. The method according to any of the conformities with the preceding claims, further characterized by the ßolicitudeß being provided with a third individual key (eg K3-2) for the validation of the command provided with the third authentication code (CA3), and said third authentication code being produced using the third individual key (K3-2). S. "The method according to any of the conformities with the preceding claims, further characterized in that in the second part (ET) produces a lß

fourth authentication code (CA4) of the command (COM), and said fourth code (CA4) that does not involve the first (Kl) or second key (CA2).

9. The method according to any of the conformities with the preceding claims, further characterized in that the card comprises a flag recorder (RB). each flag (F-1, F-2, ...) corresponding to the command of the processor (11), the execution of the command being inhibited if its flag (for example F2) is set.

10. The card (1), comprising a substrate (2) and an integrated circuit (10) having a processor (11) and a memory (12), the memory containing keys (for example Kl, K2). characterized in that the integrated circuit (10) is arranged to regenerate, using at least two keys (for example Kl, K2), the authentication codes (CAI, CA2) of the received command (COM) and to compare regenerated authentication codes ( CAÍ ', CA2 ») with the received authentication codes código (CAÍ, CA2).

11. The compliance card according to claim 10 »the memory (12) comprising a data structure having individual requests (for example Sil» SI2). each request containing an individual key (for example K3-1 »K3-2) to regenerate authentication codeß and load commandß selectively associated with the authentication codeß.

12. - The card in accordance with the claim

10 or 11 'memory (12) comprising a flag register (RB) "each flag (Fl. F-2" ...) corresponding with a command processor (11), and the command execution ßiendo inhibited its ßi flag (for example F-2) is established.

SUMMARY OF THE INVENTION

The invention refers to the method of secure loading and validation of commandß on a smart card! espec ally, in the case where loe eßpecíficoß comandoß of SSOL cation SSON charged by a supplier of applications 'ie' dispoßitivoß not eßtán in line with reßpecto to em sor card must aßegurarße that loe comandoß ßean val idoß; the invention provides a method involving the protection of comandoß loe via loe códigoß authentication, eßtoß códigoß being produced using different claveß Doss: a key is stored by the card issuer, the other by a trusted third party; A higher authentication code, produced using a key from a key set, can be used to selectively validate the commands for individual requests.

FZ / elt-tamm * P9B / 908F