Electronic information storage medium, IC chip, IC card, authentication processing method, and program

Abstract

The present invention provides an electronic information storage medium, IC chip, IC card, authentication processing method, and program that are easily adaptable to changes in the specifications of conventional connections and can conserve resources such as memory used. [Solution] When the secure element (SE) 1 receives a first command from an external device 2 indicating the start of a first authentication process, it stores identification information that can identify the connection in memory based on predetermined information contained in the first command. After the completion of the first authentication process, if the secure element (SE) 1 receives a second command from the external device 2 indicating the start of a second authentication process, and it is determined that the second authentication process is a series of authentication processes following the first authentication process, it executes the second authentication process as an additional authentication process for the current connection, and calculates a session key to be used in the session after the connection based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process.

Description

Technical Field

[0001] The present invention relates to the technical field of secure elements and the like that can establish a session with an external device and perform encrypted communication.

Background Art

[0002] Conventionally, in secure elements (e.g., mounted on IC cards or IoT devices) compliant with specifications such as GlobalPlatform (registered trademark), a session is established with an external device (in other words, a secure channel is opened) to perform encrypted communication. As an encrypted communication protocol for establishing such a session, for example, as disclosed in Patent Document 1, SCP (Secure Channel Protocol) 01, SCP02, SCP03, etc. have been conventionally used, and in recent years, SCP10 using an encryption operation method called RSA (Rivest Shamir Adleman asymmetric algorithm) has become widespread. On the other hand, the evolution of computer technology has beneficial aspects such as realizing accurate simulations in a short period, but also has aspects that threaten the security of encryption technology. The existence of quantum computers and Shor's algorithm is an example of a threat that endangers current public key encryption technology. In recent years, the standardization of quantum-resistant encryption that can counter this threat has been progressing, but encryption technology inherently always has the possibility of being endangered, and it is required to use multiple encryption technologies in operation and to be able to replace encryption technologies.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] Incidentally, traditionally, only one cryptographic technology was selected for the connection (authentication procedure) performed with an external device to establish a session. However, in recent years, mechanisms that allow the selection of multiple cryptographic technologies have been considered. For example, a mechanism has been proposed in which the external device combines the information necessary for multiple cryptographic technologies and transmits it to the secure element. However, in such a proposal, the secure element would need to receive and store more data at once compared to when the connection was established using only one cryptographic technology. This would require a significant change to the specifications of the conventional connection and would place a heavy burden on the secure element, which has limited memory and other resources.

[0005] Therefore, the present invention has been made in view of these points, and aims to provide an electronic information storage medium, an IC chip, an IC card, an authentication processing method, and a program that can easily adapt to changes in the specifications of conventional connections and can save resources such as memory used. [Means for solving the problem]

[0006] To solve the above problems, the invention described in claim 1 is an electronic information storage medium capable of executing an authentication process multiple times in a connection performed with an external device to establish a session with the external device, comprising: a first receiving means for receiving a first command from the external device indicating the start of a first authentication process; a storage means for storing discrimination information in memory that can identify the connection based on predetermined information contained in the first command; a second receiving means for receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process; a determination means for determining whether the second authentication process is a series of authentication processes following the first authentication process in the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information contained in the second command; and, if the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, a calculation means for calculating a session key used in the session based on first authentication information obtained in the first authentication process and second authentication information obtained in the second authentication process.

[0007] The invention described in claim 2 is characterized in that, in the electronic information storage medium described in claim 1, if the determination means determines that the second authentication process is not a series of authentication processes following the first authentication process, the processing means further includes a means for erasing the first authentication information obtained in the first authentication process and executing the second authentication process as an authentication process for a new connection.

[0008] The invention described in claim 3 is characterized in that, in the electronic information storage medium described in claim 1 or 2, the predetermined information is a connection ID that identifies the connection.

[0009] The invention described in claim 4 is characterized in that, in the electronic information storage medium described in claim 1 or 2, the predetermined information is a random number generated by the external device.

[0010] The invention described in claim 5 is characterized in that, in the electronic information storage medium described in claim 1 or 2, the cryptographic methods used in the first authentication process and the second authentication process, which are performed on the same connection, are different from each other.

[0011] The invention described in claim 6 is characterized in that, in the electronic information storage medium described in claim 1 or 2, the keys used in the first authentication process and the second authentication process, which are performed on the same connection, are different from each other.

[0012] The invention described in claim 7 is an IC chip capable of performing an authentication process multiple times in a connection performed with an external device to establish a session with the external device, comprising: a first receiving means for receiving a first command from the external device indicating the start of a first authentication process; a storage means for storing discrimination information in memory that can identify the connection based on predetermined information contained in the first command; a second receiving means for receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process; a determination means for determining whether the second authentication process is a series of authentication processes following the first authentication process in the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information contained in the second command; and, if the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, a calculation means for calculating a session key used in the session based on first authentication information obtained in the first authentication process and second authentication information obtained in the second authentication process.

[0013] The invention described in claim 8 is an IC card capable of performing multiple authentication processes in a connection performed with an external device to establish a session with the external device, comprising: a first receiving means for receiving a first command from the external device indicating the start of a first authentication process; a storage means for storing discrimination information in memory that can identify the connection based on predetermined information included in the first command; a second receiving means for receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process; a determination means for determining whether the second authentication process is a series of authentication processes following the first authentication process in the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command; and, if the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, a calculation means for calculating a session key used in the session based on first authentication information obtained in the first authentication process and second authentication information obtained in the second authentication process.

[0014] The invention described in claim 9 is an authentication processing method performed by an electronic information storage medium capable of performing multiple authentication processes in a connection performed with an external device to establish a session with the external device, comprising: receiving a first command from the external device indicating the start of a first authentication process; storing discrimination information capable of identifying the connection based on predetermined information included in the first command in the memory of the electronic information storage medium; receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process; determining whether the second authentication process is a series of authentication processes following the first authentication process in the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command; and, if it is determined that the second authentication process is a series of authentication processes following the first authentication process, calculating a session key to be used in the session based on first authentication information obtained in the first authentication process and second authentication information obtained in the second authentication process.

[0015] The invention described in claim 10 is characterized in that a computer included in an electronic information storage medium capable of executing authentication processes multiple times in a connection performed with an external device to establish a session with the external device includes: a first receiving means for receiving a first command from the external device indicating the start of a first authentication process; a storage means for storing discrimination information in memory that can identify the connection based on predetermined information included in the first command; a second receiving means for receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process; a determination means for determining whether the second authentication process is a series of authentication processes following the first authentication process in the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command; and, if the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, a calculation means for calculating a session key used in the session based on first authentication information obtained in the first authentication process and second authentication information obtained in the second authentication process. [Effects of the Invention]

[0016] According to the present invention, it is possible to easily adapt to changes in the specifications of conventional connections and to save resources such as memory used. [Brief explanation of the drawing]

[0017] [Figure 1] This figure shows an example of the hardware configuration of SE1. [Figure 2] This sequence diagram shows an example of operation when a symmetric-key cryptographic algorithm is used in a connection between SE1 and external device 2. [Figure 3] This flowchart shows an example of processing by the CPU 15 when an INITIALIZE UPDATE is received from external device 2. [Figure 4]It is a flowchart showing a processing example 2 by the CPU 15 when INITIALIZE UPDATE is received from the external device 2. [Figure 5] It is a flowchart showing a processing example 3 by the CPU 15 when INITIALIZE UPDATE is received from the external device 2. [Figure 6] It is a sequence diagram showing an operation example when a public key cryptography algorithm is used in a connection implemented between SE1 and the external device 2. [Figure 7] It is a flowchart showing a processing example 4 by the CPU 15 when MUTUAL AUTHENTICATE is received from the external device 2. [Figure 8] It is a flowchart showing a processing example 5 by the CPU 15 when MUTUAL AUTHENTICATE is received from the external device 2. [Figure 9] It is a sequence diagram showing an operation example related to a session implemented between SE1 and the external device 2. [Embodiments for Carrying Out the Invention]

[0018] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. The embodiments described below are embodiments when the present invention is applied to a secure element (hereinafter referred to as "SE").

[0019] [1. Configuration and Function of SE1] First, the configuration and function of SE1 according to this embodiment will be described with reference to Figure 1. Figure 1 is a diagram showing an example of the hardware configuration of SE1. SE1 is, for example, a tamper-resistant IC chip and is an example of an electronic information storage medium capable of performing authentication processing multiple times in a connection (authentication procedure) performed with an external device 2 to establish a session (encrypted communication) with the external device 2. SE1 is mounted on an IC card such as a credit card, cash card, or My Number card. Alternatively, SE1 may be mounted on an electronic device such as an IoT device or a smartphone. In this case, SE1 may be mounted as a small IC card that can be detachably attached to the electronic device, or it may be mounted on an embedded circuit board as an eUICC (Embedded Universal Integrated Circuit Card) so that it cannot be easily removed or replaced from the electronic device.

[0020] As shown in Figure 1, SE1 includes an I / O circuit 11, RAM (Random Access Memory) 12, NVM (Nonvolatile Memory) 13, ROM (Read Only Memory) 14, CPU (Central Processing Unit) 15 (an example of a computer), and a coprocessor 16 that performs cryptographic calculations, etc. SE1 may also be equipped with a random number generator (not shown). The I / O circuit 11 serves as the interface with the external device 2. Communication between SE1 and the external device 2 may be contactless or contactless. In the case of contactless communication, communication between SE1 and the external device 2 is performed via, for example, an IC card or an antenna (not shown) mounted on an electronic device. During communication between SE1 and the external device 2, command APDUs (Application Protocol Data Units) and response APDUs as defined in ISO / IEC 7816-3, etc., are exchanged. Examples of external devices 2 include transaction terminals installed in stores and mobile terminals of IoT device administrators.

[0021] NVM13 is non-volatile memory such as flash memory or Electrically Erasable Programmable Read-Only Memory. The OS (Operating System) is stored in NVM13. Furthermore, NVM13 stores a connection application that defines the authentication process performed in connection with external device 2, a session application that defines various processes (e.g., payment processing) performed in session with external device 2, and a cryptographic application that defines the cryptographic algorithm (cryptographic calculation method) used in the connection and session. There are two types of cryptographic algorithms: symmetric-key cryptography and public-key cryptography. NVM13 stores at least one of the following: a symmetric-key cryptography application that defines symmetric-key cryptography and a public-key cryptography application that defines public-key cryptography. Examples of symmetric-key cryptography algorithms include DES (Data Encryption Standard) and AES (Advanced Exception Standard). Examples of public-key cryptography algorithms include RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). Common-key cryptographic applications that define ECC include, for example, the ECDH (Elliptic curve Diffie-Hellman key exchange) protocol and parameters.

[0022] When a symmetric-key cryptography application is stored in NVM13, NVM13 stores a common symmetric key CK shared between SE1 and external device 2, and a key ID that identifies the symmetric key CK. Since the method for sharing the symmetric key CK is publicly known, a detailed explanation is omitted. Furthermore, NVM13 may store multiple distinct symmetric keys CKn, and key IDs that identify each symmetric key CKn (n=1,2,3,...). If the symmetric-key cryptography application supports multiple types of symmetric-key cryptography algorithms (e.g., DES and AES), for example, symmetric key CK1 can be used for DES while symmetric key CK2 is used for AES. However, even if the symmetric-key cryptography application supports only one type of symmetric-key cryptography algorithm, multiple symmetric keys CKn may be used interchangeably by key specification from external device 2.

[0023] Furthermore, when a public-key cryptography application is stored in NVM13, NVM13 stores the key pair KPc (a pair of private key SKc and public key PKc) unique to SE1, a key ID that identifies the key pair KPc, and a public key certificate Cc, etc. The public key certificate Cc is the certificate of the public key PKc and is associated with the key ID of the key pair KPc that includes the public key PKc. In this case, the storage unit of external device 2 stores the key pair KPe (a pair of private key SKe and public key PKe) unique to external device 2, a key ID that identifies the key pair KPe, and a public key certificate Ce, etc. The public key certificate Ce is the certificate of the public key PKe and is associated with the key ID of the key pair KPe that includes the public key PKe. NVM13 also stores verification information to verify the origin of the public key certificate Ce. The verification information includes, for example, the public key paired with the private key used to sign the public key certificate Ce (e.g., the certificate authority's private key), or the location information of that public key. External device 2 also stores verification information for verifying the origin of the public key certificate Cc.

[0024] Furthermore, NVM13 may store multiple distinct key pairs KPcn (pairs of private key SKcn and public key PKcn), key IDs that identify each key pair KPcn, and multiple distinct public key certificates Ccn. If a public key cryptography application supports multiple types of public key cryptography algorithms (e.g., RSA and ECC), for example, key pair KPc1 and public key certificate Cc1 can be used for RSA, while key pair KPc2 and public key certificate Cc2 can be used for ECC. However, even if a public key cryptography application supports only one type of public key cryptography algorithm, multiple key pairs KPcn may be used interchangeably by key specification from an external device 2.

[0025] The CPU 15 functions as a first receiving means, second receiving means, storage means, determination means, calculation means, processing means, and transmission means according to the selected connection application, and performs authentication processing multiple times in the connection established with the external device 2. More specifically, when the CPU 15 receives a first command APDU from the external device 2 indicating the start of the first authentication processing, it stores (temporarily stores) discrimination information that can identify the connection in memory (e.g., RAM 12) based on predetermined information contained in the first command APDU. The predetermined information and discrimination information are information for determining whether or not to perform additional authentication in the same connection (additional authentication determination). Examples of the predetermined information include a connection ID that identifies the connection, a random number generated by the external device 2, and an additional authentication flag. Examples of discrimination information include a connection ID that identifies the connection, a random number generated by the external device 2, and a counter value indicating the number of times the additional authentication flag has been received. The initial value of the counter value is, for example, "0", and it is incremented by 1 each time the additional authentication flag is received. A command APDU includes at least a header section consisting of CLA (Instruction Class), INS (Instruction Code), and P1 and P2 (Parameters), and depending on the command type, it may also include a body section.

[0026] When a symmetric-key cryptographic algorithm is used in the connection, the first command APDU, which indicates the start of the first authentication process, can be modified to include INITIALIZE UPDATE. In this case, the first authentication process (initial authentication process) is initiated when INITIALIZE UPDATE is sent from external device 2. When the INITIALIZE UPDATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the INITIALIZE UPDATE and sends a response APDU to the INITIALIZE UPDATE to external device 2. In this process, first authentication information (e.g., a random number) is obtained. When the response APDU is received by external device 2, external device 2 sends EXTERNAL AUTHENTICATE. When the EXTERNAL AUTHENTICATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the EXTERNAL AUTHENTICATE and sends a response APDU to the EXTERNAL AUTHENTICATE to external device 2.

[0027] On the other hand, when a public-key cryptography algorithm is used in the connection, MUTUAL AUTHENTICATE can be applied to the first command APDU, which indicates the start of the first authentication process. In this case, it is desirable that SE1 and external device 2 verify the origin of each other's public key certificates using the verification information described above before the start of the first authentication process. After the verification of the origin of each other's public key certificates is successful, the first authentication process (initial authentication process) is started when external device 2 sends MUTUAL AUTHENTICATE. When the MUTUAL AUTHENTICATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the MUTUAL AUTHENTICATE and sends a response APDU for the MUTUAL AUTHENTICATE to external device 2. In this process, the first authentication information (for example, a shared secret) is obtained.

[0028] Then, after the completion of the first authentication process, when the CPU 15 receives a second command APDU from the external device 2 indicating the start of the second authentication process, it determines whether the second authentication process is part of a series of authentication processes following the first authentication process on the same connection as the first authentication process (i.e., additional authentication determination) based on the discrimination information stored in memory and predetermined information contained in the second command APDU. If the CPU 15 determines that the second authentication process is part of a series of authentication processes following the first authentication process, it executes the second authentication process as an additional authentication process on the current connection. Subsequently, the CPU 15 calculates the session key to be used in the session after the same connection based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process. On the other hand, if the CPU 15 determines that the second authentication process is not part of a series of authentication processes following the first authentication process, it erases the first authentication information obtained in the first authentication process (discards the session after the connection) and executes the second authentication process as an authentication process on a new connection different from the current connection.

[0029] Here, if a symmetric-key cryptographic algorithm is used in the connection, the second command APDU, which indicates the start of the second authentication process, can also be subjected to INITIALIZE UPDATE, just like the first command APDU. In this case, the second authentication process is initiated when the external device 2 sends INITIALIZE UPDATE. When the INITIALIZE UPDATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the INITIALIZE UPDATE and sends a response APDU to the INITIALIZE UPDATE to external device 2. In this process, second authentication information (e.g., a random number) is obtained. When the response APDU is received by external device 2, external device 2 sends EXTERNAL AUTHENTICATE. When the EXTERNAL AUTHENTICATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the EXTERNAL AUTHENTICATE and sends a response APDU to the EXTERNAL AUTHENTICATE to external device 2. Furthermore, the symmetric-key cryptographic algorithms used in the first authentication process and the second authentication process (i.e., the additional authentication process) performed on the same connection may be the same, or they may be different, for example, DES and AES.

[0030] On the other hand, when a public-key cryptography algorithm is used in the connection, MUTUAL AUTHENTICATE can be applied to the second command APDU, which indicates the start of the second authentication process, in the same way as the second command APDU. In this case as well, it is desirable for SE1 and external device 2 to verify the origin of each other's public key certificates using the verification information described above before the start of the second authentication process. After the verification of the origin of each other's public key certificates is successful, the second authentication process starts when external device 2 sends MUTUAL AUTHENTICATE. When the MUTUAL AUTHENTICATE sent from external device 2 is received via the I / O circuit 11, the CPU 15 executes processing corresponding to the MUTUAL AUTHENTICATE and sends a response APDU to the MUTUAL AUTHENTICATE to external device 2. In this process, the second authentication information (for example, a shared secret) is obtained. Furthermore, the public-key cryptographic algorithms used in the first authentication process and the second authentication process (i.e., the additional authentication process) performed on the same connection may be the same, or they may be different, for example, RSA and ECC.

[0031] [2. Operations related to the connection between SE1 and external device 2] Next, the operation related to the connection between SE1 and external device 2 will be explained separately in Example 1 and Example 2.

[0032] (Example 1) In Example 1, an example of operation when a symmetric-key cryptographic algorithm is used in a connection between SE1 and external device 2 will be described with reference to Figures 2 to 5. Figure 2 is a sequence diagram showing an example of operation when a symmetric-key cryptographic algorithm is used in a connection between SE1 and external device 2. As a premise for Figure 2, for example, external device 2 has determined the number of authentication processes required for the same connection (two times in the example of Figure 2), and SE1 and external device 2 store the symmetric key CK1 for DES and key ID[1] that identifies the symmetric key CK1, and the symmetric key CK2 for AES and key ID[2] that identifies the symmetric key CK2, etc. (key ID[1] and key ID[2] are different from each other). That is, in the example of Figure 2, the cryptographic algorithms used in at least the first authentication process and the second authentication process executed in the same connection are different from each other. Furthermore, it is assumed that an initial sequence (e.g., reset and initial response) is performed between SE1 and external device 2 before the operation shown in Figure 2 begins, and thereafter, SE1 selects and responds with a connection application and a session application in response to a SELECT (command APDU) from external device 2.

[0033] When the operation shown in Figure 2 begins, the external device 2 generates a random number Re1 (step S1) and sends an INITIALIZE UPDATE to SE1 (step S2). Thus, the first authentication process begins. Here, the body of the INITIALIZE UPDATE consists of Lc, DATA, and Le, where Lc indicates the length of DATA and Le indicates the length of the response APDU to be sent to the INITIALIZE UPDATE. DATA stores at least the random number Re1 and the technical ID[1] in TLV format. The technical ID[1] indicates the symmetric-key cryptographic algorithm to be used (e.g., DES) and the key ID[1] of the symmetric key CK1 to be used. Alternatively, the technical ID[1] may indicate only the key ID[1] of the symmetric key CK1 to be used. Furthermore, the above-mentioned connection ID or additional authentication flag may be stored in TLV format in DATA. Furthermore, information indicating the number of authentication processes required for the same connection (e.g., remaining attempts) may be stored in TLV format in DATA. However, if the number of authentication attempts is predetermined between SE1 and external device 2, information indicating that number does not need to be stored in DATA.

[0034] Next, when SE1 receives an INITIALIZE UPDATE from external device 2, it obtains a random number Re1 and a technical ID[1] from the INITIALIZE UPDATE and executes processing corresponding to the INITIALIZE UPDATE (step S3). The technical ID[1] obtained in this way identifies the symmetric key cryptographic algorithm (e.g., DES) and the symmetric key CK1 to be used. Furthermore, if the INITIALIZE UPDATE contains a connection ID, that connection ID is obtained. Alternatively, if the INITIALIZE UPDATE contains an additional authentication flag, that additional authentication flag is obtained. In addition, if the INITIALIZE UPDATE contains information indicating the number of authentication processes, that information is obtained.

[0035] In the process corresponding to INITIALIZE UPDATE, SE1 generates a random number Rc1. Here, the random number Rc1 may be generated by a random number generator, or it may be generated by pseudorandom number calculation by CPU15. Next, SE1 calculates (generates) the session key SK1 using a symmetric-key cryptographic algorithm (e.g., DES) with the common key CK1, the random number Re1, and the random number Rc1. For example, CPU15 calculates the session key SK1 by having the coprocessor 16 perform cryptographic calculations according to the symmetric-key cryptographic application. Note that the method for calculating (generating) the session key is publicly known, so a detailed explanation is omitted, but for example, three types of session keys SK1enc (for encryption), SK1mac (for MAC (Message Authentication Code)), and SK1dek (for key update) are calculated from the random number Re1 and the random number Rc1.

[0036] Next, SE1 calculates the authentication code ACc1 using a symmetric-key cryptographic algorithm (e.g., DES) with, for example, the session key SK1enc, random number Re1, random number Rc1, and a pre-set specific value. For example, CPU 15 causes coprocessor 16 to perform cryptographic operations according to the symmetric-key cryptographic application (for example, encrypting random number Re1, random number Rc1, and the specific value with the session key SK1enc) to calculate the authentication code ACc1. Next, SE1 stores the first authentication information, including random number Re1 and random number Rc1, in memory. In the process shown in step S3, discrimination information is also stored in memory, but the details of this process will be described later with reference to Figures 3 to 5. Next, SE1 sends a response APDU to external device 2 that includes the random number Rc1 and the authentication code ACc1 in TLV format and also includes a SW (status word) indicating successful completion (step S4).

[0037] Next, when external device 2 receives the response APDU from SE1, it obtains the random number Rc1 and the authentication code ACc1 from the response APDU, and in step S5, it first calculates the session key SK1 (e.g., session key SK1enc, SK1mac, SK1dek) using a symmetric-key cryptographic algorithm (e.g., DES) with the common key CK1, the random number Re1, and the random number Rc1. Next, external device 2 verifies the authentication code ACc1 using, for example, the session key SK1enc. If the verification is successful (e.g., the authentication code ACc1 is successfully decrypted using the session key SK1enc), external device 2 calculates the authentication code ACe1 using a symmetric-key cryptographic algorithm (e.g., DES) with, for example, the session key SK1enc, the random number Re1, the random number Rc1, and a pre-set specific value. Next, external device 2 stores the first authentication information, including the random numbers Re1 and Rc1, in memory. Next, external device 2 sends EXTERNAL AUTHENTICATE to SE1 (step S6). Here, the body of the EXTERNAL AUTHENTICATE consists of Lc and DATA, where the authentication code ACe1 and the technical ID[1] are stored in TLV format.

[0038] Next, when SE1 receives EXTERNAL AUTHENTICATE from external device 2, it obtains the authentication code ACe1 and the technical ID[1] from EXTERNAL AUTHENTICATE and verifies the authentication code ACe1 using, for example, the session key SK1enc (step S7). If the verification (device authentication) is successful, SE1 sends a response APDU indicating the authentication result (success) to external device 2 (step S8). Thus, the first authentication process is completed. Note that the authentication result (success) may also be sent to external device 2 by a response APDU in the second authentication process (step S16).

[0039] Next, when external device 2 receives the response APDU from SE1, it generates a random number Re2 (step S9). Then, external device 2 sends an INITIALIZE UPDATE to SE1 (step S10). This starts the second authentication process. Here, the DATA in the body of the INITIALIZE UPDATE contains at least the random number Re2 and the technical ID[2] in TLV format. The technical ID[2] indicates the symmetric-key cryptographic algorithm to be used (e.g., AES) and the key ID[2] of the symmetric key CK2 to be used. Alternatively, the technical ID[2] may indicate only the key ID[2] of the symmetric key CK2 to be used. Furthermore, the DATA may also contain a connection ID or additional authentication flags in TLV format, similar to the case of the first authentication process. Furthermore, the DATA may also contain information in TLV format indicating the number of authentication processes required on the same connection (e.g., remaining attempts), similar to the case of the first authentication process. In Example 1, it is assumed that Technical ID [1] and Technical ID [2] are different from each other, but Technical ID [1] and Technical ID [2] may be the same.

[0040] Next, when SE1 receives an INITIALIZE UPDATE from external device 2, it obtains a random number Re2 and a technical ID[2] from the INITIALIZE UPDATE and executes processing corresponding to the INITIALIZE UPDATE (step S11). The technical ID[2] obtained in this way identifies the symmetric key encryption algorithm (e.g., AES) and the symmetric key CK2 to be used. Furthermore, if the INITIALIZE UPDATE contains a connection ID, that connection ID is obtained. Alternatively, if the INITIALIZE UPDATE contains an additional authentication flag, that additional authentication flag is obtained. In addition, if the INITIALIZE UPDATE contains information indicating the number of authentication processes, that information is obtained.

[0041] In the process corresponding to INITIALIZE UPDATE, SE1 generates a random number Rc2. Next, SE1 calculates the session key SK2 using a symmetric-key cryptographic algorithm (e.g., AES) with the common key CK2, random number Re2, and random number Rc2. For example, CPU 15 causes coprocessor 16 to perform cryptographic operations according to the symmetric-key cryptographic application, thereby calculating the session keys SK2enc, SK2mac, and SK2dek. Next, SE1 calculates the authentication code ACc2 using a symmetric-key cryptographic algorithm (e.g., AES) with the session key SK2enc, random number Re2, random number Rc2, and a pre-set specific value. Next, SE1 stores the second authentication information, including the random numbers Re2 and Rc2, in memory. In the process shown in step S11, an additional authentication determination is performed, but the details of this process will be described later with reference to Figures 3 to 5. Next, SE1 sends a response APDU to external device 2 that includes a random number Rc2 and an authentication code ACc2 in TLV format, and also includes SW indicating successful completion (step S12).

[0042] Next, when external device 2 receives the response APDU from SE1, it obtains the random number Rc2 and the authentication code ACc2 from the response APDU, and in step S13, it first calculates the session key SK2 (e.g., session key SK2enc, SK2mac, SK2dek) using a symmetric-key cryptographic algorithm (e.g., AES) with the common key CK2, random number Re2, and random number Rc2. Next, external device 2 verifies the authentication code ACc2 using the session key SK2enc. If this verification is successful, external device 2 calculates the authentication code ACe2 using a symmetric-key cryptographic algorithm (e.g., AES) with the session key SK2enc, random number Re2, random number Rc2, and a pre-set specific value. Next, external device 2 stores the second authentication information, including the random numbers Re2 and Rc2, in memory. Next, external device 2 sends EXTERNAL AUTHENTICATE to SE1 (step S14). Here, the body of the EXTERNAL AUTHENTICATE consists of Lc and DATA, where the authentication code ACe2 and the technical ID[2] are stored in TLV format.

[0043] Next, when SE1 receives EXTERNAL AUTHENTICATE from external device 2, it obtains the authentication code ACe2 and technical ID[2] from EXTERNAL AUTHENTICATE and verifies the authentication code ACe2 using, for example, the session key SK2enc (step S15). If this verification (device authentication) is successful, SE1 sends a response APDU indicating the authentication result (success) to external device 2 (step S16). Thus, the second authentication process is completed.

[0044] Next, when external device 2 receives the response APDU from SE1, it terminates the connection and establishes a session with SE1. In other words, in the example in Figure 2, the session is not yet started when authentication is successful in the first authentication process, and the session is started when authentication is successful in the subsequent second authentication process. The operation related to the session performed between SE1 and external device 2 will be described later.

[0045] (Example 1 - Processing Example 1) Next, referring to Figure 3, we will explain example 1 of the processing performed by CPU 15 when an INITIALIZE UPDATE is received from external device 2. Figure 3 is a flowchart of example 1 of the processing performed by CPU 15 when an INITIALIZE UPDATE is received from external device 2. In processing example 1, the identification information is assumed to be the connection ID.

[0046] The process shown in Figure 3 is initiated when an INITIALIZE UPDATE is received. When the process shown in Figure 3 is initiated, the CPU 15 determines whether the received INITIALIZE UPDATE contains a connection ID based on the Lc and DATA(TLV) in the body of the INITIALIZE UPDATE (step S101). If it is determined that the INITIALIZE UPDATE contains a connection ID (step S101: YES), the process proceeds to step S102. On the other hand, if it is determined that the INITIALIZE UPDATE does not contain a connection ID (step S101: NO), the process proceeds to step S104.

[0047] In step S102, the CPU 15 determines whether the connection ID has already been stored in memory as identification information. For example, if the storage area for identification information in memory is FFFF...(h), it is determined that the connection ID has not been stored (step S102: NO), and the process proceeds to step S103. On the other hand, if it is determined that the connection ID has been stored (step S102: YES), the process proceeds to step S108.

[0048] In step S103, the CPU 15 stores the connection ID included in the received INITIALIZE UPDATE into the storage area in memory. Next, as explained in step S3 shown in Figure 2, the CPU 15 generates a random number Rc1 (step S104), calculates a session key SK1 (e.g., session keys SK1enc, SK1mac, SK1dek) (step S105), calculates an authentication code ACc1 (step S106), stores the first authentication information (step S107), and proceeds to the response (sending the response APDU).

[0049] In step S108, the CPU 15 determines whether the connection ID stored in memory matches the connection ID included in INITIALIZE UPDATE (additional authentication determination). If it is determined that the two connection IDs do not match (for example, if it is determined that the second authentication process is not part of a series of authentication processes following the first authentication process on that connection) (step S108: NO), the process proceeds to step S109. On the other hand, if it is determined that the two connection IDs match (step S108: YES), the process proceeds to step S111.

[0050] In step S109, the CPU 15 erases all authentication information stored in memory. Next, the CPU 15 erases the connection ID stored in memory (step S110) and proceeds to step S104. For example, the connection ID is erased by writing FFFF···(h) to the storage area in memory used to store identification information.

[0051] In step S111, the CPU 15 generates a random number Rck (k≧2). For example, if in step S108 it is determined that the second authentication process is a series of authentication processes following the first authentication process on the connection, then k=2, and a random number Rc2 is generated. Next, the session key SKk (e.g., session keys SKkenc, SKkmac, SKkdek) is calculated (step S112), the authentication code ACck is calculated (step S113), the k-th (k≧2) authentication information is stored (step S114), and the process proceeds to step S115. If k is 3 or greater, the external device 2 may specify either DES or AES as the encryption algorithm.

[0052] In step S115, the CPU 15 determines whether the additional authentication is complete or not. For example, if the number of authentication processes requiring the kth authentication process has been reached, it is determined that the additional authentication is complete (step S115: YES), the connection ID stored in memory is erased (step S116), and the process proceeds to the response. On the other hand, if it is determined that the additional authentication is not complete (step S115: NO), the process proceeds to the response.

[0053] (Example 1 - Processing Example 2) Next, referring to Figure 4, we will describe example 2 of the processing performed by the CPU 15 when an INITIALIZE UPDATE is received from external device 2. Figure 4 is a flowchart of example 2 of the processing performed by the CPU 15 when an INITIALIZE UPDATE is received from external device 2. In processing example 2, the identification information is assumed to be a random number Re1 generated by external device 2, and if the kth (for example, the second) authentication process after the first authentication process is a series of authentication processes following the first authentication process (i.e., an additional authentication process), then the random number Rek received after the random number Re1 is configured to match the random number Re1. However, in this case, if the technical ID [1] and technical ID [2] are the same, an INITIALIZE UPDATE that is exactly the same as one that has been processed before will be received, which may be a replay attack, so it is necessary to reject the processing as an error.

[0054] The process shown in Figure 4 is started when INITIALIZE UPDATE is received. When the process shown in Figure 4 is started, the CPU 15 determines whether or not the random number Re1 is already stored in memory as discrimination information (step S201). For example, if the storage area for discrimination information in memory is FFFF...(h), it is determined that the random number Re1 is not already stored (step S201: NO), and the process proceeds to step S202. On the other hand, if it is determined that the random number Re1 is already stored (step S201: YES), the process proceeds to step S207.

[0055] In step S202, the CPU 15 stores the random number Re1 included in the received INITIALIZE UPDATE into the above-mentioned storage area in memory and proceeds to step S203. Note that the processing in steps S203 to S206 is the same as the processing in steps S104 to S107 shown in Figure 3.

[0056] In step S207, the CPU 15 determines whether the random number Re1 stored in memory matches the random number Rek (or, in the case of a second authentication process, the random number Re2) included in INITIALIZE UPDATE (additional authentication determination). If it is determined that the two random numbers do not match (for example, if it is determined that the second authentication process is not part of a series of authentication processes following the first authentication process on that connection) (step S207: NO), the process proceeds to step S208. On the other hand, if it is determined that the two random numbers match (step S207: YES), the process proceeds to step S210.

[0057] In step S208, the CPU 15 erases all authentication information stored in memory. Next, the CPU 15 erases the random number Re1 stored in memory (step S209) and proceeds to step S203. For example, the random number Re1 is erased when FFFF···(h) is written to the storage area in memory used to store discrimination information.

[0058] Note that the processing in steps S210 to S214 is the same as the processing in steps S111 to S115 shown in Figure 3. In step S215, the random number Re1 stored in memory is erased, and the process proceeds to the response.

[0059] (Example 1 - Processing Example 3) Next, referring to Figure 5, we will describe example 3 of the processing performed by CPU 15 when an INITIALIZE UPDATE is received from external device 2. Figure 5 is a flowchart of example 3 of the processing performed by CPU 15 when an INITIALIZE UPDATE is received from external device 2. In processing example 3, the identification information is assumed to be a counter value indicating the number of additional authentication flags received.

[0060] The process shown in Figure 5 is initiated when an INITIALIZE UPDATE is received. When the process shown in Figure 5 is initiated, the CPU 15 determines whether or not the received INITIALIZE UPDATE contains an additional authentication flag based on the Lc and DATA(TLV) in the body of the INITIALIZE UPDATE (step S301). If it is determined that the INITIALIZE UPDATE contains an additional authentication flag (step S301: YES), the process proceeds to step S302. On the other hand, if it is determined that the INITIALIZE UPDATE does not contain an additional authentication flag (step S301: NO), the process proceeds to step S304.

[0061] In step S302, the CPU 15 determines whether the counter value in memory is at its initial value (for example, 0). For example, if it is determined that the counter value is at its initial value (i.e., the first authentication process is underway) (step S302: YES), the process proceeds to step S303. On the other hand, if it is determined that the counter value is not at its initial value (step S302: NO), the process proceeds to step S308.

[0062] In step S303, CPU 15 increments the counter value by 1 and proceeds to step S304. Note that the processing in steps S304 to S307 is the same as the processing in steps S104 to S107 shown in Figure 3.

[0063] In step S308, the CPU 15 determines whether the counter value is at the upper limit (additional authentication determination). The upper limit is set to, for example, the number of authentication processes required + 1. If it is determined that the counter value is at the upper limit (for example, that the second authentication process is not part of the series of authentication processes following the first authentication process on that connection) (step S308: YES), the process proceeds to step S309. On the other hand, if it is determined that the counter value is not at the upper limit (step S308: NO), the process proceeds to step S311.

[0064] In step S309, the CPU 15 erases all authentication information stored in memory. Then, the CPU 15 initializes the counter value (for example, sets it to 0) (step S310) and proceeds to step S304.

[0065] In step S311, the CPU 15 increments the counter value by 1 and proceeds to step S312. The processing in steps S312 to S315 is the same as the processing in steps S111 to S114 shown in Figure 3.

[0066] (Example 2) Example 2 describes an example of operation when a public-key cryptography algorithm is used in a connection between SE1 and external device 2, with reference to Figures 6 to 8. Figure 6 is a sequence diagram showing an example of operation when a public-key cryptography algorithm is used in a connection between SE1 and external device 2. As a premise for Figure 6, it is assumed that, for example, external device 2 has determined the number of authentication processes required for the same connection (2 times in the example of Figure 6), and that SE1 stores multiple key pairs for ECC, KPc1, KPc2, key IDs[1], ID[2] that identify each key pair KPc1, KPc2, and multiple public key certificates for ECC, Cc1, Cc2, etc. Furthermore, it is assumed that external terminal 2 stores multiple key pairs for ECC, KPe1, KPe2, key IDs[1], ID[2] that identify each key pair KPe1, KPe2, and multiple public key certificates for ECC, Ce1, Ce2, etc. Furthermore, it is assumed that an initial sequence is performed between SE1 and external device 2 before the operation shown in Figure 6 begins, and thereafter SE1 selects a connection application in response to a SELECT from external device 2. In the example in Figure 6, the cryptographic algorithms used in at least the first and second authentication processes performed on the same connection are identical.

[0067] SE1 may store the ECC key pair KPc1, the RSA key pair KPc2, key IDs[1] and ID[2] that identify the respective key pairs KPc1 and KPc2, the ECC public key certificate Cc1, and the RSA public key certificate Cc2, etc. Similarly, external terminal 2 may store the ECC key pair KPe1, the RSA key pair KPe2, key IDs[1] and ID[2] that identify the respective key pairs KPe1 and KPe2, the ECC public key certificate Ce1, and the RSA public key certificate Ce2, etc. In other words, in Embodiment 2 as well, the cryptographic algorithms used in at least the first authentication process and the second authentication process executed on the same connection may be different from each other.

[0068] When the operation shown in Figure 6 begins, the external device 2 sends GET DATA (command APDU) to SE1 (step S41). Here, the body of GET DATA consists of Lc, DATA, and Le, where Lc indicates the length of DATA and Le indicates the length of the response APDU to be sent in response to GET DATA. DATA stores the certificate ID[1] in TLV format. The certificate ID[1] indicates the public-key cryptographic algorithm to be used (e.g., ECC) and the key ID[1] of the key pair KPc1 to be used. Alternatively, the certificate ID[1] may indicate only the key ID[1] of the key pair KPc1 to be used.

[0069] Next, when SE1 receives GET DATA from external device 2, it obtains a certificate ID[1] from the GET DATA and, based on the obtained certificate ID[1], identifies the public key cryptographic algorithm (e.g., ECC), the key pair to be used KPc1, and the public key certificate Cc1. Then, SE1 obtains the identified public key certificate Cc1 from NVM13 and sends a response APDU to external device 2 that includes the public key certificate Cc1 and SW indicating successful completion (step S42).

[0070] Next, when external device 2 receives a response APDU from SE1, it obtains the public key certificate Cc1 from the response APDU and verifies the origin of the public key certificate Cc1 based on the verification information (step S43). For example, the signature is verified using the public key that is paired with the private key used to sign the public key certificate Cc1. If the verification is successful, external device 2 sends a PERFORM SECURITY OPERATION (command APDU) to SE1 (step S44). Here, the body of the PERFORM SECURITY OPERATION consists of Lc and DATA, and the public key certificate Ce1 is stored in TLV format in DATA.

[0071] Next, when SE1 receives a PERFORM SECURITY OPERATION from external device 2, it obtains the public key certificate Ce1 from the PERFORM SECURITY OPERATION and verifies the origin of the public key certificate Ce1 based on the verification information (step S45). For example, the signature is verified using the public key that is paired with the private key used to sign the public key certificate Ce1. If the verification is successful, SE1 sends a response APDU indicating the verification result (success) to external device 2 (step S46).

[0072] Next, when external device 2 receives the response APDU from SE1, it generates a temporary key pair TKPe1 consisting of a temporary private key TSKe1 and a temporary public key TPKe1 (step S47). Here, the temporary private key TSKe1 is, for example, a random number generated by external device 2. The temporary public key TPKe1 is generated, for example, by an ECDH operation based on the temporary private key TSKe1 and a point on an elliptic curve according to the ECDH protocol. Next, external device 2 sends MUTUAL AUTHENTICATE (command APDU) to SE1 (step S48). Thus, the first authentication process begins. Here, the body of MUTUAL AUTHENTICATE consists of Lc, DATA, and Le, where Lc indicates the length of DATA and Le indicates the length of the response APDU to be sent to MUTUAL AUTHENTICATE. DATA contains at least the temporary public key TPKe1 in TLV format. Furthermore, DATA may also contain the connection ID or additional authentication flags described above in TLV format. Furthermore, DATA may store information in TLV format indicating the number of authentication processes required for the same connection (e.g., the remaining number of processes). However, if the number of authentication processes is predetermined between SE1 and external device 2, it is not necessary to store information indicating that number in DATA.

[0073] Next, when SE1 receives a MUTUAL AUTHENTICATE from external device 2, it obtains the temporary public key TPKe1 from the MUTUAL AUTHENTICATE and performs processing according to the MUTUAL AUTHENTICATE (step S49). Furthermore, if the MUTUAL AUTHENTICATE contains a connection ID, that connection ID is obtained. Alternatively, if the MUTUAL AUTHENTICATE contains an additional authentication flag, that additional authentication flag is obtained. In addition, if the MUTUAL AUTHENTICATE contains information indicating the number of authentication processes, that information is obtained.

[0074] In processing according to MUTUAL AUTHENTICATE, SE1 calculates shared secret A1 using a public-key cryptography algorithm (e.g., ECC) with the temporary public key TPKe1 and the private key SKc1. Next, SE1 generates a temporary key pair TKPc1 using the temporary private key TSKc1 and the temporary public key TPKc1. Here, the temporary private key TSKc1 is a random number generated, for example, by the random number generator of SE1, or by pseudo-random number calculation by CPU15. The temporary public key TPKc1 is generated, for example, by an ECDH operation based on the temporary private key TSKc1 and a point on an elliptic curve according to the ECDH protocol. Next, SE1 calculates shared secret B1 using a public-key cryptography algorithm (e.g., ECC) with the temporary public key TPKe1 and the temporary private key TSKc1. Next, SE1 calculates the session key SK1 using a public-key cryptography algorithm (e.g., ECC) with shared secret A1 and shared secret B1. For example, the CPU 15 causes the coprocessor 16 to perform cryptographic calculations according to the public-key cryptography application, thereby calculating the session keys SK1enc, SK1mac, and SK1dek.

[0075] Next, SE1 calculates authentication code ACc1 using a public-key cryptography algorithm (e.g., ECC) with the session key SK1 (e.g., session key SK1enc), shared secret A1, shared secret B1, and a pre-set specific value. For example, CPU 15 causes coprocessor 16 to perform cryptographic operations according to the public-key cryptography application (e.g., encrypting shared secret A1, shared secret B1, and the specific value with session key SK1enc) to calculate authentication code ACc1. Next, SE1 stores the first authentication information, including shared secret A1 and shared secret B1, in memory. In the process shown in step S49, discrimination information is also stored in memory, but the details of this process will be described later using Figures 7 and 8. Next, SE1 sends a response APDU to external device 2 that includes the temporary public key TPKc1 and authentication code ACc1 in TLV format, and also includes SW indicating successful completion (step S50).

[0076] Next, when external device 2 receives the response APDU from SE1, it obtains the temporary public key TPKc1 and authentication code ACc1 from the response APDU, and in step S51, first calculates the shared secret A1 using the temporary public key TPKc1 and the private key SKe1 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 calculates the shared secret B1 using the temporary public key TPKc1 and the temporary private key TSKe1 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 calculates the session key SK1 (e.g., session key SK1enc, SK1mac, SK1dek) using the shared secrets A1 and B1 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 verifies the authentication code ACc1 using, for example, the session key SK1enc. If the verification is successful, external device 2 stores the first authentication information, including the shared secrets A1 and B1, in memory. Thus, the first authentication process is completed.

[0077] Next, external device 2 sends GET DATA to SE1 (step S52). Here, the DATA in the body of GET DATA contains the certificate ID[2] in TLV format. The certificate ID[2] indicates the public key cryptographic algorithm to be used (e.g., ECC) and the key ID[2] of the key pair KPc2 to be used. Alternatively, the certificate ID[2] may indicate only the key ID[2] of the key pair KPc2 to be used.

[0078] Next, when SE1 receives GET DATA from external device 2, it obtains the certificate ID[2] from the GET DATA and, based on the obtained certificate ID[2], identifies the public key cryptographic algorithm (e.g., ECC), the key pair to be used KPc2, and the public key certificate Cc2. Then, SE1 obtains the identified public key certificate Cc2 from NVM13 and sends a response APDU to external device 2 that includes the public key certificate Cc2 and SW indicating successful completion (step S53).

[0079] Next, when external device 2 receives a response APDU from SE1, it obtains the public key certificate Cc2 from the response APDU and verifies the origin of the public key certificate Cc2 based on the verification information (step S54). For example, the signature is verified using the public key that is paired with the private key used to sign the public key certificate Cc2. If the verification is successful, external device 2 sends PERFORM SECURITY OPERATION to SE1 (step S55). Here, the public key certificate Ce2 is stored in TLV format in the DATA field of the PERFORM SECURITY OPERATION body.

[0080] Next, when SE1 receives a PERFORM SECURITY OPERATION from external device 2, it obtains the public key certificate Ce2 from the PERFORM SECURITY OPERATION and verifies the origin of the public key certificate Ce2 based on the verification information (step S56). For example, the signature is verified using the public key that is paired with the private key used to sign the public key certificate Ce2. If the verification is successful, SE1 sends a response APDU indicating the verification result (success) to external device 2 (step S57).

[0081] Next, when external device 2 receives the response APDU from SE1, it generates a temporary key pair TKPe2 consisting of a temporary private key TSKe2 and a temporary public key TPKe2 (step S58). Here, the temporary private key TSKe2 is, for example, a random number generated by external device 2. The temporary public key TPKe2 is generated, for example, by an ECDH operation based on the temporary private key TSKe2 and a point on an elliptic curve according to the ECDH protocol. Next, external device 2 sends MUTUAL AUTHENTICATE to SE1 (step S59). Thus, the second authentication process begins. Here, the DATA in the body of MUTUAL AUTHENTICATE contains at least the temporary public key TPKe2 in TLV format. Furthermore, the connection ID or additional authentication flags described above may also be stored in TLV format in DATA. Furthermore, as in the case of the first authentication process, information indicating the number of authentication processes required for the same connection (e.g., remaining attempts) may also be stored in TLV format in DATA.

[0082] Next, when SE1 receives a MUTUAL AUTHENTICATE from external device 2, it obtains the temporary public key TPKe2 from the MUTUAL AUTHENTICATE and performs processing according to the MUTUAL AUTHENTICATE (step S60). Furthermore, if the MUTUAL AUTHENTICATE contains a connection ID, that connection ID is obtained. Alternatively, if the MUTUAL AUTHENTICATE contains an additional authentication flag, that additional authentication flag is obtained. In addition, if the MUTUAL AUTHENTICATE contains information indicating the number of authentication processes, that information is obtained.

[0083] In processing according to MUTUAL AUTHENTICATE, SE1 calculates shared secret A2 using a public-key cryptographic algorithm (e.g., ECC) with the temporary public key TPKe2 and the private key SKc2. Next, SE1 generates a temporary key pair TKPc2 using the temporary private key TSKc2 and the temporary public key TPKc2. Here, the temporary public key TPKc2 is generated, for example, by an ECDH operation based on a point on an elliptic curve according to the ECDH protocol with the temporary private key TSKc2. Next, SE1 calculates shared secret B2 using a public-key cryptographic algorithm (e.g., ECC) with the temporary public key TPKe2 and the temporary private key TSKc2. Next, SE1 calculates the session key SK2 (e.g., session key SK2enc, SK2mac, SK2dek) using a public-key cryptographic algorithm (e.g., ECC) with shared secrets A2 and B2.

[0084] Next, SE1 calculates the authentication code ACc2 using a public-key cryptographic algorithm (e.g., ECC) with, for example, the session key SK2enc, shared secret A2, shared secret B2, and a pre-set specific value. Next, SE1 stores the second authentication information, including shared secrets A2 and B2, in memory. In the process shown in step S60, discrimination information is also stored in memory, but the details of this process will be described later with reference to Figures 7 and 8. Next, SE1 sends a response APDU to the external device 2 that includes the temporary public key TPKc2 and the authentication code ACc2 in TLV format, and also includes SW indicating successful completion (step S61).

[0085] Next, when external device 2 receives the response APDU from SE1, it obtains the temporary public key TPKc2 and authentication code ACc2 from the response APDU, and in step S62, it first calculates the shared secret A2 using the temporary public key TPKc2 and private key SKe2 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 calculates the shared secret B2 using the temporary public key TPKc2 and temporary private key TSKe2 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 calculates the session key SK2 (e.g., session key SK2enc, SK2mac, SK2dek) using the shared secrets A2 and B2 with a public key cryptographic algorithm (e.g., ECC). Next, external device 2 verifies the authentication code ACc2 using, for example, the session key SK2enc. If the verification is successful, external device 2 stores the second authentication information, including the shared secrets A2 and B2, in memory. Thus, the second authentication process is completed.

[0086] Next, external device 2 terminates the connection and establishes a session with SE1. In other words, even in the example in Figure 6, the session is not yet started when authentication is successful in the first authentication process, and the session is started when authentication is successful in the subsequent second authentication process. The operation related to the session performed between SE1 and external device 2 will be described later.

[0087] (Example 2 - Processing Example 4) Next, referring to Figure 7, we will describe example 4 of the processing performed by the CPU 15 when MUTUAL AUTHENTICATE is received from external device 2. Figure 7 is a flowchart of example 4 of the processing performed by the CPU 15 when MUTUAL AUTHENTICATE is received from external device 2. In processing example 4, the identification information is assumed to be the connection ID.

[0088] The process shown in Figure 7 is initiated when a MUTUAL AUTHENTICATE is received. When the process shown in Figure 7 is initiated, the CPU 15 determines whether or not the received MUTUAL AUTHENTICATE contains a connection ID based on the Lc and DATA(TLV) in the body of the MUTUAL AUTHENTICATE (step S401). If it is determined that the MUTUAL AUTHENTICATE contains a connection ID (step S401: YES), the process proceeds to step S402. On the other hand, if it is determined that the MUTUAL AUTHENTICATE does not contain a connection ID (step S401: NO), the process proceeds to step S404.

[0089] In step S402, the CPU 15 determines whether the connection ID has already been stored in memory as identification information. If it is determined that the connection ID has not been stored (step S402: NO), the process proceeds to step S403. On the other hand, if it is determined that the connection ID has been stored (step S402: YES), the process proceeds to step S410.

[0090] In step S403, the CPU 15 stores the connection ID contained in the received MUTUAL AUTHENTICATE in the storage area of ​​memory. Next, as explained in step S49 shown in Figure 6, the CPU 15 calculates the shared secret A1 (step S404), generates a temporary key pair TKPc1 (step S405), calculates the shared secret B1 (step S406), calculates the session key SK1 (e.g., session keys SK1enc, SK1mac, SK1dek) (step S407), calculates the authentication code ACc1 (step S408), stores the first authentication information (step S409), and proceeds to the response (sending the response APDU).

[0091] In step S410, the CPU 15 determines whether the connection ID stored in memory matches the connection ID included in MUTUAL AUTHENTICATE (additional authentication determination). If it is determined that the two connection IDs do not match (step S410: NO), the process proceeds to step S411. On the other hand, if it is determined that the two connection IDs match (step S410: YES), the process proceeds to step S413.

[0092] In step S411, the CPU 15 erases all authentication information stored in memory. Next, the CPU 15 erases the connection ID stored in memory (step S412) and proceeds to step S404.

[0093] In step S413, the CPU 15 generates a shared secret Ak. For example, if in step S410 it is determined that the second authentication process is a series of authentication processes following the first authentication process on the connection, then k=2, and a shared secret A2 is generated. Next, a temporary key pair TKPck is generated (step S414), the shared secret Bk is calculated (step S415), the session key SKk (for example, session keys SKkenc, SKkmac, SKkdek) is calculated (step S416), the authentication code ACck is calculated (step S417), the k-th authentication information is stored (step S418), and the process proceeds to step S419.

[0094] In step S419, the CPU 15 determines whether the additional authentication is complete or not. For example, if the number of authentication processes requiring the kth authentication process has been reached, it is determined that the additional authentication is complete (step S419: YES), the connection ID stored in memory is erased (step S420), and the process proceeds to the response. On the other hand, if it is determined that the additional authentication is not complete (step S419: NO), the process proceeds to the response.

[0095] (Example 2 - Processing Example 5) Next, referring to Figure 8, we will describe example 5 of the processing performed by the CPU 15 when MUTUAL AUTHENTICATE is received from external device 2. Figure 8 is a flowchart of example 5 of the processing performed by the CPU 15 when MUTUAL AUTHENTICATE is received from external device 2. In processing example 5, the identification information is assumed to be a counter value indicating the number of additional authentication flags received.

[0096] The process shown in Figure 8 is initiated when a MUTUAL AUTHENTICATE is received. When the process shown in Figure 8 is initiated, the CPU 15 determines whether or not the received MUTUAL AUTHENTICATE contains an additional authentication flag based on the Lc and DATA(TLV) in the body of the MUTUAL AUTHENTICATE (step S501). If it is determined that the MUTUAL AUTHENTICATE contains an additional authentication flag (step S501: YES), the process proceeds to step S502. On the other hand, if it is determined that the MUTUAL AUTHENTICATE does not contain an additional authentication flag (step S501: NO), the process proceeds to step S504.

[0097] In step S502, the CPU 15 determines whether the counter value in memory is at its initial value (for example, 0). For example, if it is determined that the counter value is at its initial value (i.e., the first authentication process is underway) (step S502: YES), the process proceeds to step S503. On the other hand, if it is determined that the counter value is not at its initial value (step S502: NO), the process proceeds to step S510.

[0098] In step S503, the CPU 15 increments the counter value by 1 and proceeds to step S504. Note that the processing in steps S504 to S509 is the same as the processing in steps S404 to S409 shown in Figure 7.

[0099] In step S510, the CPU 15 determines whether the counter value is at the upper limit (additional authentication determination). The upper limit is set to, for example, the number of authentication processes required + 1. If it is determined that the counter value is at the upper limit (step S510: YES), the process proceeds to step S511. On the other hand, if it is determined that the counter value is not at the upper limit (step S510: NO), the process proceeds to step S513.

[0100] In step S511, the CPU 15 erases all authentication information stored in memory. Next, the CPU 15 initializes the counter value (step S512) and proceeds to step S504.

[0101] In step S513, the CPU 15 increments the counter value by 1 and proceeds to step S514. Note that the processing in steps S514 to S519 is the same as the processing in steps S413 to S418 shown in Figure 7.

[0102] [3. Operations related to sessions conducted between SE1 and external device 2] Next, with reference to Figure 9, the operation of a session conducted between SE1 and external device 2 will be described. Figure 9 is a sequence diagram showing an example of the operation of a session conducted between SE1 and external device 2. As explained in Figure 2 or Figure 6, when the connection between SE1 and external device 2 is successfully terminated, SE1 and external device 2 each calculate a common session key SK used in the session based on the first to k (in the examples of Figures 2 and 6, k=2) authentication information stored in memory. For example, if a symmetric-key cryptographic algorithm is used in the above-mentioned connection, SE1 and external device 2 each calculate (regenerate) the session keys SKenc, SKmac, and Skdek using a symmetric-key cryptographic algorithm (e.g., DES or AES) with random numbers Rc1 to Rck and random numbers Re1 to Rek included in the stored authentication information. On the other hand, if a public-key cryptography algorithm is used in the connection described above, SE1 and external device 2 each calculate (regenerate) the session keys SKenc, SKmac, and Skdek using a public-key cryptography algorithm (e.g., ECC) with the shared secrets A1-Ak and B1-Bk contained in the stored authentication information.

[0103] In Figure 9, external device 2 encrypts a predetermined command APDU (for example, a command APDU for executing transaction processing) using the session key SKenc, generates a MAC using the session key SKmac, and adds the generated MAC to the encrypted command APDU (hereinafter referred to as the "encrypted command") (step S81). Next, external device 2 sends the encrypted command and MAC to SE1 (step S82). Next, when SE1 receives the encrypted command and MAC, it verifies the MAC using the session key SKmac (step S83). If the verification is successful, SE1 decrypts the encrypted command and executes processing corresponding to the decrypted command APDU (step S84). Next, SE1 encrypts a response APDU containing SW indicating the processing result using the session key SKenc, generates a MAC using the session key SKmac, and adds the generated MAC to the encrypted response APDU (hereinafter referred to as the "encrypted response") (step S85). Next, SE1 sends the encrypted response and MAC to external device 2 (step S86). From this point onward, confidential communication will continue.

[0104] As described above, according to the above embodiment, when SE1 receives a first command APDU from external device 2 indicating the start of the first authentication process, it stores in memory identification information that can identify the connection based on predetermined information contained in the first command APDU. After the completion of the first authentication process, when SE1 receives a second command APDU from external device 2 indicating the start of the second authentication process, it determines whether the second authentication process is performed on the same connection as the first authentication process, based on the identification information stored in memory and predetermined information contained in the second command APDU, and a series of authentication processes following the first authentication process. The system is configured to determine whether or not an authentication process is being performed, and if it is determined that the second authentication process is part of a series of authentication processes following the first authentication process, it will execute the second authentication process as an additional authentication process for the current connection. Based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process, it will calculate the session key to be used in the session after that connection. This makes it easier to adapt to changes in the specifications of conventional connections (because the APDU command indicating the start of the authentication process can use the same specifications as before), and also saves resources such as memory used.

[0105] For example, in a system where external device 2 combines information necessary for multiple encryption technologies and transmits it to SE1 in a single command, it is necessary to store in memory, for example, session keys SK1enc, SK1mac, SK1dek, SK2enc, SK2mac, SK2dek (a total of 6), authentication codes ACc1, ACc2, and random numbers Re1, Re2, Rc1, Rc2 when the command is received. However, according to the above embodiment, it is sufficient to store the random numbers Re1 and Rc1 obtained in the first authentication process as the first authentication information in memory, and the random numbers Re2 and Rc2 obtained in the second authentication process as the second authentication information in memory (i.e., it is not necessary to store the session keys and authentication codes in memory), thus saving memory compared to the above system. Furthermore, according to the above embodiment, if an authentication error occurs, it is not necessary to transmit subsequent information, which also leads to increased communication efficiency.

[0106] In Example 1, INITIALIZE UPDATE and EXTERNAL AUTHENTICATE were given as examples of command APDUs used for authentication, and in Example 2, MUTUAL AUTHENTICATE was given as an example of a command APDU used for authentication. However, the commands used for authentication may differ depending on the cryptographic technology used for authentication, and the command APDUs and response APDUs for the first and second authentication processes do not necessarily have to be the same; any procedure for device authentication and key sharing is sufficient. Furthermore, in Example 1, a case where a symmetric-key cryptographic algorithm is used in both the first and second authentication processes was given as an example, and in Example 2, a case where a public-key cryptographic algorithm is used in both the first and second authentication processes was given as an example. However, for example, the system may be configured so that a symmetric-key cryptographic algorithm is used in the first authentication process and a public-key cryptographic algorithm is used in the second authentication process. Alternatively, the system may be configured so that a public-key cryptographic algorithm is used in the first authentication process and a symmetric-key cryptographic algorithm is used in the second authentication process. [Explanation of Symbols]

[0107] 1 SE 2 External equipment 11 I / O circuit 12 RAM 13 NVM 14 ROM 15 CPU 16 coprocessors

Claims

1. An electronic information storage medium capable of performing authentication processing multiple times in a connection performed with an external device in order to establish a session with the external device, A first receiving means that receives a first command from the external device indicating the start of a first authentication process, A storage means for storing in memory identification information that can identify the connection based on predetermined information contained in the first command, A second receiving means receives a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process, A determination means that determines whether the second authentication process is a series of authentication processes following the first authentication process on the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command, If the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, the calculation means calculates a session key to be used in the session based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process. An electronic information storage medium characterized by comprising the following features.

2. The electronic information storage medium according to claim 1, further comprising processing means for deleting the first authentication information obtained in the first authentication process and executing the second authentication process as an authentication process for a new connection, if the determination means determines that the second authentication process is not a series of authentication processes following the first authentication process.

3. The electronic information storage medium according to claim 1 or 2, characterized in that the predetermined information is a connection ID that identifies the connection.

4. The electronic information storage medium according to claim 1 or 2, characterized in that the predetermined information is a random number generated by the external device.

5. The electronic information storage medium according to claim 1 or 2, characterized in that the cryptographic methods used in the first authentication process and the second authentication process, respectively, which are performed on the same connection, are different from each other.

6. The electronic information storage medium according to claim 1 or 2, characterized in that the keys used in the first authentication process and the second authentication process, respectively, which are performed on the same connection, are different from each other.

7. An IC chip capable of performing authentication processing multiple times in a connection performed with an external device to establish a session with the external device, A first receiving means that receives a first command from the external device indicating the start of a first authentication process, A storage means for storing in memory identification information that can identify the connection based on predetermined information contained in the first command, A second receiving means receives a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process, A determination means that determines whether the second authentication process is a series of authentication processes following the first authentication process on the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command, If the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, the calculation means calculates a session key to be used in the session based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process. An IC chip characterized by having the following features.

8. An IC card capable of performing authentication processing multiple times in a connection made with an external device in order to establish a session with the external device, A first receiving means that receives a first command from the external device indicating the start of a first authentication process, A storage means for storing in memory identification information that can identify the connection based on predetermined information contained in the first command, A second receiving means receives a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process, A determination means that determines whether the second authentication process is a series of authentication processes following the first authentication process on the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command, If the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, the calculation means calculates a session key to be used in the session based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process. An IC card characterized by having the following features.

9. An authentication method performed by an electronic information storage medium capable of performing authentication processing multiple times in a connection made with an external device to establish a session with the external device, The steps include receiving a first command from the external device indicating the start of a first authentication process, The steps include storing identification information that allows the connection to be identified based on predetermined information contained in the first command in the memory of the electronic information storage medium, The steps include receiving a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process, A step of determining whether the second authentication process is a series of authentication processes following the first authentication process on the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command, If it is determined that the second authentication process is a series of authentication processes following the first authentication process, the steps include calculating a session key to be used in the session based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process, A method for authentication processing characterized by including the following:

10. A computer contained in an electronic information storage medium capable of performing authentication processing multiple times in a connection made with an external device in order to establish a session with the external device, A first receiving means that receives a first command from the external device indicating the start of a first authentication process, A storage means for storing in memory identification information that can identify the connection based on predetermined information contained in the first command, A second receiving means receives a second command from the external device indicating the start of a second authentication process after the completion of the first authentication process, A determination means that determines whether the second authentication process is a series of authentication processes following the first authentication process on the same connection as the first authentication process, based on the discrimination information stored in the memory and predetermined information included in the second command, A program characterized in that, when the determination means determines that the second authentication process is a series of authentication processes following the first authentication process, it functions as a calculation means for calculating a session key used in the session based on the first authentication information obtained in the first authentication process and the second authentication information obtained in the second authentication process.

Images