User authentication method, authentication apparatus, electronic information storage medium, and program for terminal

Abstract

To provide a user authentication method, an authentication device, an electronic information storage medium, and a program for a terminal capable of achieving user authentication with higher security by using an existing system without separately preparing a device.SOLUTION: The user terminal 3 transmits a generation request of signature data corresponding to each of the common key encryption method and the public key encryption method to the IC card 2 in response to an authentication request from the authentication server 4, acquires an AC generated by the IC card 2 using an AC key according to the common key encryption method and an SDAD generated by the IC card 2 using an ICC private key according to the public key encryption method, verifies the SDAD using an ICC public key according to the public key encryption method, and transmits verification information indicating a result of the verification of the SDAD and an unverified AC to the authentication server 4.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] The present invention relates to technical fields such as user authentication methods for online payments. [Background technology]

[0002] Conventionally, an authentication service called 3D Secure has been used for identity verification in online payments, and authentication methods include password authentication and one-time password authentication via email or SMS (Short Message Service). For example, Patent Document 1 discloses that a payment card such as a credit card, debit card, or gift card generates a one-time password and provides the one-time password to a communication device such as a smartphone. In recent years, more secure device authentication has become known, and for example, device authentication using the FIDO specification is being considered and used. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7352008 Summary of the Invention [Problem to be solved by the invention]

[0004] However, more secure device authentication requires a dedicated device and a dedicated authentication system compatible with that device, which poses a challenge in terms of implementation costs.

[0005] Therefore, the present invention has been made in consideration of such problems and aims to provide a user authentication method, authentication device, electronic information storage medium, and terminal program that can achieve more secure user authentication by utilizing an existing system without preparing a separate device. [Means for solving the problem]

[0006] In order to solve the above problem, the invention described in claim 1 is a user authentication method executed between a terminal device used by a user, an electronic information storage medium owned by the user, and an authentication device that transmits a first authentication request to the terminal device, the method comprising: a first transmission step in which the terminal device transmits a generation request for signature data corresponding to each of a plurality of cryptographic operation methods to the electronic information storage medium in response to the first authentication request from the authentication device; a generation step in which the electronic information storage medium generates each of the plurality of types of signature data in response to the generation request from the terminal device; a second transmission step in which the electronic information storage medium transmits each of the generated signature data to the terminal device; a first verification step in which the terminal device verifies all or part of the plurality of types of signature data from the electronic information storage medium; a third transmission step in which the terminal device transmits verification information indicating the result of the verification of all or part of the signature data to the authentication device; and a determination step in which the authentication device makes an authentication determination for the user based on the verification information from the terminal device.

[0007] The invention described in claim 2 is characterized in that, in the user authentication method described in claim 1, the authentication device is capable of communicating with a transaction device for executing payment processing in response to a payment request from the terminal device, and further includes the steps of the transaction device sending a second authentication request to the authentication device when receiving the payment request from the terminal device, the authentication device sending the first authentication request to the terminal device in response to the second authentication request from the transaction device, and the authentication device sending authentication information indicating the result of the authentication decision of the user to the transaction device as information necessary for the transaction device to proceed with the payment processing.

[0008] The invention of claim 3 provides the user authentication method of claim 2, wherein the plurality of cryptographic operation methods include a symmetric key cryptosystem and a public key cryptosystem, and the signature data corresponding to each of the plurality of cryptographic operation methods includes first signature data generated using a symmetric key according to the symmetric key cryptosystem and second signature data generated using a private key according to the public key cryptosystem, the electronic information storage medium and the authentication device pre-store the symmetric key that is common between the electronic information storage medium and the authentication device, and the electronic information storage medium pre-stores the private key that is unique to the electronic information storage medium, and in the generating step, the electronic information storage medium generates the first signature data using the symmetric key according to the symmetric key cryptosystem and generates the second signature data using the private key according to the public key cryptosystem, and in the second transmitting step the electronic information storage medium transmits each of the generated first signature data and second signature data to the terminal device; in the first verification step, the terminal device verifies the second signature data from the electronic information storage medium using a public key that forms a pair with the private key in accordance with the public key cryptosystem; in the third transmission step, the terminal device transmits verification information indicating a result of the verification of the second signature data and the unverified first signature data to the authentication device; the user authentication method further includes a second verification step in which the authentication device verifies the unverified first signature data from the terminal device using the common key in accordance with the common key cryptosystem; and in the determination step, the authentication device determines that authentication is successful if the result of the verification of the first signature data indicates success and the result of the verification of the second signature data indicates success.

[0009] The invention described in claim 4 is characterized in that, in the user authentication method described in claim 3, in the third transmission step, the terminal device transmits verification information indicating the result of verification of the second signature data and the unverified first signature data to the authentication device only if the result of verification of the second signature data indicates success.

[0010] The invention described in claim 5 is characterized in that, in the user authentication method described in claim 3, if the result of verification of the second signature data indicates failure, the terminal device notifies the user of an error.

[0011] The invention of claim 6 is characterized in that, in the user authentication method of claim 3, the second authentication request and the generation request include signature target data generated by the authentication device, and in the generation step, the electronic information storage medium generates the first signature data using the common key and the signature target data in accordance with the common key cryptosystem, and generates the second signature data using the private key and the signature target data in accordance with the public key cryptosystem, and in the first verification step, the terminal device verifies the second signature data using the public key that forms a pair with the private key and the signature target data in accordance with the public key cryptosystem, and in the second verification step, the authentication device verifies the first signature data using the common key and the signature target data in accordance with the common key cryptosystem.

[0012] The invention described in claim 7 is an authentication device used in the user authentication method described in claim 2, characterized in that it comprises a first transmitting means for transmitting a second authentication request to the terminal device when the first authentication request is received, a judgment means for making an authentication judgment of the user based on the verification information from the terminal device, and a second transmitting means for transmitting authentication information indicating the result of the authentication judgment to the transaction device as information necessary for the transaction device to proceed to payment processing in accordance with the payment request.

[0013] The invention described in claim 8 is an electronic information storage medium used in the user authentication method described in claim 2, characterized in that it comprises a generation means for generating each of the multiple types of signature data in response to the generation request from the terminal device, and a third transmission means for transmitting each of the generated signature data to the terminal device.

[0014] The invention described in claim 9 is characterized in that, in the electronic information storage medium described in claim 8, the electronic information storage medium is an IC card issued to the user so that it can be used for payments related to electronic transactions.

[0015] The invention described in claim 10 is characterized in that a computer included in a terminal device used in the user authentication method described in claim 2 is made to function as a fourth transmission means that transmits a request for generating signature data corresponding to each of multiple types of cryptographic calculation methods to the electronic information storage medium in response to the second authentication request from the authentication device, a verification means that verifies all or part of the multiple types of signature data from the electronic information storage medium, and a fifth transmission means that transmits verification information indicating the result of verifying all or part of the signature data to the authentication device.

[0016] The invention described in claim 11 is characterized in that a computer included in a terminal device that is capable of communicating with an authentication device for authenticating a user of the terminal device and that is capable of communicating with an electronic information storage medium owned by the user is caused to execute the following steps: sending a request to generate signature data corresponding to each of a symmetric key cryptosystem and a public key cryptosystem to the electronic information storage medium in response to an authentication request from the authentication device; obtaining first signature data generated by the electronic information storage medium in accordance with the symmetric key cryptosystem using a symmetric key common between the electronic information storage medium and the authentication device, and second signature data generated by the electronic information storage medium in accordance with the public key cryptosystem using a private key unique to the electronic information storage medium; verifying the second signature data using a public key that forms a pair with the private key in accordance with the public key cryptosystem; and transmitting verification information indicating a result of verification of the second signature data and the first signature data to the authentication device. [Effects of the Invention]

[0017] According to the present invention, it is possible to realize user authentication with higher security by utilizing an existing system without preparing a separate device. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a diagram illustrating an example of a schematic configuration of an online payment system S. [Figure 2] FIG. 2 is a diagram illustrating an example of a schematic configuration of an IC card 2. [Figure 3] FIG. 10 is a conceptual diagram showing an example of a storage area in NVM 13 for storing the various data described above. [Figure 4] FIG. 2 is a diagram illustrating an example of a schematic configuration of a user terminal 3. [Figure 5] FIG. 2 is a diagram illustrating an example of a schematic configuration of an authentication server 4. [Figure 6] 10 is a sequence diagram showing an example of an operation from when the EC server 1 receives a payment request to when the EC server 1 proceeds with payment processing in accordance with the payment request. FIG. [Figure 7] 10 is a sequence diagram showing an example of an operation from when the EC server 1 receives a payment request to when the EC server 1 proceeds with payment processing in accordance with the payment request. FIG. [Figure 8] 10 is a sequence diagram showing an example of an operation from when the EC server 1 receives a payment request to when the EC server 1 proceeds with payment processing in accordance with the payment request. FIG. [Figure 9] 10 is a sequence diagram showing an example of an operation from when the EC server 1 receives a payment request to when the EC server 1 proceeds with payment processing in accordance with the payment request. FIG. DETAILED DESCRIPTION OF THE INVENTION

[0019] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described in detail below with reference to the accompanying drawings. The embodiment described below is an embodiment in which the present invention is applied to an online payment system.

[0020] [1. Configuration and Function of Online Payment System S] First, referring to FIG. 1, an overview of the configuration and functions of an online payment system S according to this embodiment will be described. FIG. 1 is a diagram showing an example of the schematic configuration of the online payment system S. As shown in FIG. 1, the online payment system S is configured to include an EC (Electronic Commerce) server 1 (an example of a transaction device), an IC (Integrated Circuit) card 2 (an example of an electronic information storage medium), a user terminal 3 (an example of a terminal device), and an authentication server 4 (an example of an authentication device). The EC server 1 and the user terminal 3, the user terminal 3 and the authentication server 4, and the EC server 1 and the authentication server 4 are capable of communicating with each other via a network NW. The network NW is configured to include, for example, the Internet and a mobile communication network. In addition, the IC card 2 and the user terminal 3 are capable of short-range wireless communication.

[0021] The EC server 1 is a server that provides an EC site for conducting e-commerce transactions related to goods or services over a network NW and is mainly operated by an acquirer (a company that manages merchants that accept payment cards). The EC server 1 also functions as a 3DS Requestor and 3DS Server to authenticate (verify the identity of) a user U who conducts e-commerce transactions through the EC site using an authentication protocol (authentication protocol for e-commerce transactions) called EMV (registered trademark) 3-D Secure (3DS). With these functions, when the EC server 1 receives a payment request related to an e-commerce transaction from a user terminal 3, it transmits an authentication request message (an example of a second authentication request) to the authentication server 4 via a directory server (DS). The DS is a server that performs functions such as routing messages between the EC server 1 and the authentication server 4. When the EC server 1 receives authentication information indicating the result of the authentication decision for the user U (authentication success) from the authentication server 4 via the DS, it executes a payment process in accordance with the payment request based on the authentication information.

[0022] The IC card 2 is an IC chip-equipped card owned by the user U, and is, for example, a payment card (e.g., a credit card, debit card, etc.) issued to the user U (card owner) so that it can be used for payments related to electronic commerce. The IC chip C mounted on the IC card 2 is also an example of an electronic information storage medium. The IC card 2 is also used for identity verification (authentication of the user U) when the user terminal 3 sends a payment request to the EC server 1. Such identity verification is performed by verifying the authenticity of the IC card 2. The IC card 2 may have a shape other than that of a typical payment card (i.e., a shape other than a rectangle).

[0023] The user terminal 3 is a terminal used by the user U for e-commerce, and may be, for example, a mobile terminal such as a smartphone or tablet, or a desktop personal computer. The user terminal 3 also has a function as a 3DS Client for authenticating the user U who conducts e-commerce through an EC site using the above authentication protocol. With this function, the user terminal 3 accesses the authentication server 4 when it sends a payment request for e-commerce to the EC server 1, and upon receiving a challenge request message (an example of a first authentication request) from the authentication server 4, it obtains verification data from the IC card 2, verifies the signature data (described later), and then returns a challenge response message to the authentication server 4.

[0024] The authentication server 4 is a server for authenticating a user U who conducts e-commerce through an EC site, and is mainly managed by an issuer (a company that issues a payment card). The authentication server 4 also functions as an Access Control Server (ACS) for authenticating the user U using the above authentication protocol. With this function, when the authentication server 4 receives an authentication request message from the EC server 1 via the DS, it transmits an authentication response message including access information to the authentication server 4 (e.g., a uniform resource locator (URL)) to the EC server 1 via the DS. This causes the access information to the authentication server 4 to be transmitted from the EC server 1 to the user terminal 3. When the user terminal 3 accesses the authentication server 4 in accordance with the access information, the authentication server 4 transmits a challenge request message to the user terminal 3. In response, when the authentication server 4 receives a challenge response message from the user terminal 3, it performs an authentication decision on the user U and transmits authentication information indicating the result of the authentication decision to the EC server 1 as information necessary for the EC server 1 to proceed with the payment process.

[0025] [1-1. IC Card 2 Configuration and Functions] Next, an overview of the configuration and functions of the IC card 2 will be described with reference to FIG. 2. FIG. 2 is a diagram showing an example of the schematic configuration of the IC card 2. As shown in FIG. 2, the IC card 2 includes an antenna AT and an IC chip C connected to the antenna AT. The antenna AT includes an antenna coil (not shown), receives a carrier wave (electromagnetic wave) emitted from the user terminal 3, outputs the resulting electrical signal to the IC chip C, and transmits the modulated signal output from the IC chip C as an electromagnetic wave. The IC chip C includes an I / O circuit 21, a random access memory (RAM) 22, a nonvolatile memory (NVM) 23, a read-only memory (ROM) 24, a central processing unit (CPU) 25, and a coprocessor 26 that performs cryptographic operations. The I / O circuit 21 includes a power generation circuit that generates power from the carrier wave received by the antenna AT and a modulation / demodulation circuit that modulates and demodulates input and output data, and has a function of performing short-range wireless communication (contactless communication) with the user terminal 3, such as near-field communication (NFC) conforming to ISO / IEC 14443 or the like. The IC chip C may be connected to a reader / writer connected to the user terminal 3, so that contact communication can be performed between the IC chip C and the user terminal 3 via the reader / writer.

[0026] The NVM 23 is a nonvolatile memory such as a flash memory or an electrically erasable programmable read-only memory. The NVM 23 stores an operating system (OS). Furthermore, the NVM 23 stores applications for executing processing on the OS in accordance with command application protocol data units (APDUs) received from the user terminal 3 via the I / O circuit 21 and returning response APDUs, as well as various data used in the processing. Such applications include, for example, a payment application for executing payment processing in accordance with the EMV (registered trademark) specification on the OS. The payment application defines multiple cryptographic algorithms (encryption algorithms) and is capable of generating multiple types of signature data according to each cryptographic algorithm. The command APDU includes at least a header section consisting of CLA, INS, P1, and P2, as defined in ISO / IEC 7816, and further includes a body section depending on the command type.

[0027] In this embodiment, preferred examples of the multiple types of encryption operation methods include common key encryption (symmetric key encryption) methods such as DES (Data Encryption Standard) and AES (Advanced Exception Standard), and public key encryption (asymmetric key encryption) methods such as RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography). Therefore, the multiple types of signature data include AC (Application Cryptogram) (an example of first signature data) and SDAD (Signed Dynamic Application Data) (an example of second signature data). AC is generated according to a common key encryption method using a common key (hereinafter referred to as an "AC key") shared between the IC card 2 and the EC server 1. On the other hand, SDAD is generated according to a public key encryption method using a private key (hereinafter referred to as an "ICC private key") unique to the IC card 2.

[0028] FIG. 3 is a conceptual diagram showing an example of storage areas in the NVM 23 for storing the various data described above. In the example of FIG. 3, the NVM 23 includes an AID storage area 231, an ICC private key storage area 232, an ICC public key certificate storage area 233, an issuer public key certificate storage area 234, a CA (Certificate Authorities) public key index storage area 235, an AC key storage area 236, an AC key index storage area 237, and a card number information storage area 238. Each storage area is assigned a record number. The AID storage area 231 stores an AID, which is an identifier for a payment application. The AID conforms to, for example, ISO / IEC 7816 and includes an RID. The RID is used to identify a payment scheme. For example, if the AID is "A0 00 00 00 03 10 10"(h), the "A0 00 00 00 03" portion represents the RID. An ICC private key is stored in the ICC private key storage area 232. An ICC public key certificate is stored in the ICC public key certificate storage area 233. The ICC public key certificate is a certificate of the ICC public key that forms a pair with the ICC private key, is signed using the issuer private key, and can be verified using the issuer public key that forms a pair with the issuer private key.

[0029] The issuer public key certificate storage area 234 stores an issuer public key certificate. The issuer public key certificate is a certificate of the issuer public key, is signed with a CA private key, and can be verified using a CA public key that is paired with the CA private key. The CA public key index storage area 235 stores a CA public key index. The CA public key index includes an identifier for uniquely identifying the CA public key used to verify the issuer public key. The AC key storage area 236 stores an AC key. The AC key index storage area 237 stores an AC key index corresponding to the AC key. The AC key index includes an identifier for uniquely identifying the AC master key for generating the AC key. The card number information storage area 238 stores the card number and sequence number of the cardholder. The sequence number is incremented by 1 each time an IC card 2 with the same card number is issued. For example, if the initial value is "00", "01" is added each time the IC card 2 is reissued. The storage areas 231 to 238 store the various data described above in the process of issuing the IC card 2, for example.

[0030] The CPU 25 executes a payment process conforming to, for example, the EMV (registered trademark) specification in accordance with a payment application. In this payment process, the CPU 25 functions as the generating means and third transmitting means of the present invention, generating and transmitting signature data. Specifically, the CPU 25 generates multiple types of signature data in response to a signature data generation request from the user terminal 3, the signature data corresponding to each of multiple cryptographic algorithms. For example, when the CPU 25 receives a GENERATE AC command APDU from the user terminal 3 via the I / O circuit 21, the CPU 25 interprets this as a signature data generation request and generates the multiple types of signature data. For example, the CPU 25 generates an AC using an AC key according to a symmetric key cryptosystem and generates an SDAD using an ICC private key according to a public key cryptosystem. The CPU 25 then transmits the generated AC and SDAD to the user terminal 3 as verification data. At this time, the CPU 25 may transmit a response APDU including the verification data and an AC key index to the user terminal 3 via the I / O circuit 21.

[0031] [1-2. Configuration and Functions of User Terminal 3] Next, an overview of the configuration and functions of the user terminal 3 will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of the schematic configuration of the user terminal 3. As shown in FIG. 4, the user terminal 3 includes a short-range wireless communication unit 31, a communication unit 32, an operation / display unit 33, a storage unit 34, and an information processing unit 35 (an example of a computer). The user terminal 3 may also include an audio output unit including a speaker. The short-range wireless communication unit 31 has a function of performing short-range wireless communication, such as NFC conforming to ISO / IEC 14443, with the IC card 2 (IC chip C). The communication unit 32 has a function of connecting to the network NW via a wireless base station of a mobile communication network and communicating with the EC server 1 and the authentication server 4. The operation / display unit 33 has an input function of accepting instructions from the user U using a finger, a pen, or the like, and a display function of displaying various information on a display.

[0032] The storage unit 34 includes, for example, a nonvolatile semiconductor memory and stores an OS. The storage unit 34 also stores an application (an example of a terminal program) for accessing an EC site and executing e-commerce processing on the OS in accordance with instructions from the user U, as well as various data used in the processing. Such applications include, for example, a payment application for executing payment processing in accordance with the EMV (registered trademark) specifications. The payment application defines multiple cryptographic algorithms, enabling verification of multiple types of signature data according to each cryptographic algorithm. In this embodiment, as described above, a symmetric key cryptosystem and a public key cryptosystem are preferably used as suitable examples of the multiple cryptographic algorithms. The storage unit 34 may also store a CA public key table that registers CA public key indexes and the RIDs described above in association with each other.

[0033] The information processing unit 35 includes RAM, ROM, a CPU, and the like, and executes payment processing in accordance with, for example, the EMV (registered trademark) specification in accordance with a payment application. In this payment processing, the information processing unit 35 functions as the fourth transmission means, verification means, and fifth transmission means of the present invention, requesting and verifying signature data, and transmitting the verification results. Specifically, when the information processing unit 35 transmits a payment request related to an electronic commerce transaction to the EC server 1, it accesses the authentication server 4 via the communication unit 32 and receives a challenge request message from the authentication server 4. In response to the challenge request message, the information processing unit 35 causes the IC card 2 to select a payment application, etc., via the short-range wireless communication unit 31, and transmits a GENERATE AC command APDU (an example of a generation request) to the IC card 2. As a result, the information processing unit 35 obtains the above-mentioned verification data from the IC card 2.

[0034] The information processing unit 35 then verifies all or part of the multiple types of signature data based on the verification data (i.e., performs a predetermined verification process). For example, the information processing unit 35 verifies the SDAD included in the verification data from the IC card 2 using an ICC public key in accordance with public key cryptography. The ICC public key may be obtained based on the CA public key and the issuer public key certificate and ICC public key certificate obtained from the IC card 2. The information processing unit 35 transmits a challenge response message including verification information indicating the result of the SDAD verification and an unverified AC to the authentication server 4 via the communication unit 32. The information processing unit 35 may transmit the challenge response message to the authentication server 4 only if the result of the SDAD verification indicates success. This reduces the processing load on the user terminal 3 and the authentication server 4. If the result of the SDAD verification indicates failure, the information processing unit 35 may notify the user U of an error via the operation / display unit 33 (e.g., display an error on a display). At this time, the information processing unit 35 may output a sound indicating the error from a speaker. The challenge response message may further include the AC key index, and the card number and sequence number obtained from the IC card 2.

[0035] [1-3. Configuration and Function of Authentication Server 4] Next, an overview of the configuration and functions of the authentication server 4 will be described with reference to FIG. 5. FIG. 5 is a diagram illustrating an example of the schematic configuration of the authentication server 4. As illustrated in FIG. 5, the authentication server 4 includes a communication unit 41, a storage unit 42, an information processing unit 43, and the like. The communication unit 41 is connected to the network NW and has a function of communicating with the EC server 1 and the user terminal 3. The storage unit 42 includes, for example, a solid-state drive (SSD) or a hard disk drive (HDD), and stores an OS. The storage unit 42 also stores an authentication program for executing authentication processing for the user U on the OS in response to an authentication request message from the EC server 1, as well as various data used in the authentication processing. The authentication application defines multiple cryptographic algorithms, enabling verification of multiple types of signature data according to each cryptographic algorithm. In this embodiment, as described above, a symmetric key cryptosystem and a public key cryptosystem are preferably used as suitable examples of the multiple cryptographic algorithms. The storage unit 42 may also store an AC master key table in which AC key indexes are registered.

[0036] The information processing unit 43 includes RAM, ROM, a CPU, etc., and executes authentication processing for the user U in accordance with an authentication application. In this authentication processing, it functions as the first transmitting means, determining means, second transmitting means, etc. of the present invention, and transmits an authentication request, an authentication determination for the user U, and the authentication determination result. Specifically, when the information processing unit 43 receives an authentication request message (an example of a second authentication request) from the EC server 1 via the DS, it transmits an authentication response message including access information to the authentication server 4 to the EC server 1 via the communication unit 41 and the DS. As a result, when there is access from the user terminal 3, the information processing unit 43 transmits a challenge request message (an example of a first authentication request) to the user terminal 3 via the communication unit 41. As a result, the information processing unit 43 obtains verification information indicating the verification result of the SDAD and unverified ACs, etc. from the user terminal 3.

[0037] Then, the information processing unit 43 performs an authentication determination of the user U (i.e., a determination of whether the authentication is successful or not) based on the verification information and the unverified AC. In performing this authentication determination, the information processing unit 43 may verify the unverified AC from the user terminal 3 using an AC key according to a common key cryptosystem. The AC key may be generated from an AC master key and the card number and sequence number acquired from the user terminal 3. If the result of the SDAD verification indicates success and the result of the AC verification indicates success, the information processing unit 43 determines that the authentication is successful (i.e., that the user U is authenticated). In other words, the authenticity of the IC card 2 is verified, thereby performing an authentication determination of the user U. The information processing unit 43 transmits authentication information indicating the result of the authentication determination (authentication successful or authentication failed) to the EC server 1 via the communication unit 41 as information necessary for the EC server 1 to proceed with the payment processing.

[0038] [2. Operation of Online Payment System S] Next, the operation of the online payment system S will be described with reference to Figures 6 to 9. In the operation described below, an example is taken of a case where the user terminal 3 accesses an EC site, causing the EC site's application to start, and a product purchase screen provided by the EC server 1 to be displayed on the user terminal 3. Note that the user U logs in after the user terminal 3 accesses the EC site and before a payment request is sent to the EC server 1. With the product purchase screen displayed on the user terminal 3, the user U selects a product to be purchased (for example, adds it to a product cart), and then selects (for example, taps or clicks) a payment start button on the product purchase screen, causing the product purchase screen to transition to a card information input screen.

[0039] Then, with the card information input screen displayed on the user terminal 3, the user U inputs card information (e.g., card number, name, expiration date) of the IC card 2, and then selects the payment button on the card information input screen. This causes a payment request for the product selected by the user U (i.e., a payment request related to e-commerce) to be sent from the user terminal 3 to the EC server 1. This payment request includes the card information input by the user U and purchase information for the selected product (e.g., including the product ID and price). Note that the payment request may also include card information that has been input and saved in advance by the user U.

[0040] 6 to 9 are sequence diagrams showing an example of the operation from when a payment request is received by the EC server 1 to when payment processing according to the payment request is carried out. In Fig. 6, when the EC server 1 receives a payment request from the user terminal 3, it transmits an authentication request message (an example of a second authentication request) including card information and the like included in the payment request to the authentication server 4 via the DS (step S1). Here, the DS identifies the authentication server 4 based on the card information and the like included in the authentication request message, and transmits the authentication request message to the authentication server 4.

[0041] Next, when the authentication server 4 receives the authentication request message from the EC server 1, it transmits an authentication response message including access information to the authentication server 4 to the EC server 1 via the DS (step S2). When the EC server 1 receives the authentication response message from the authentication server 4, it transmits the access information to the authentication server 4 to the user terminal 3 (step S3). The user terminal 3 accesses the authentication server 4 based on the access information from the EC server 1 (step S4).

[0042] Next, in response to access from the user terminal 3, the authentication server 4 transmits a challenge request message (an example of a first authentication request) to the user terminal 3 (step S5). Here, the challenge request message may include data to be signed by the authentication server 4 (i.e., input data for which a signature is to be generated). The data to be signed includes a random number, a country code, a date, etc.

[0043] Next, when the user terminal 3 receives the challenge request message from the authentication server 4, it notifies the user U to hold the IC card 2 over the user terminal 3 (for example, by displaying an error message on the display) (step S6), and enters a state of waiting for communication with the IC card 2. At this time, the user terminal 3 may output a sound from a speaker prompting the user U to hold the IC card 2 over the user terminal 3.

[0044] Next, when the IC card 2 is held over the user terminal 3, communication begins between the IC card 2 (IC chip C) and the user terminal 3 and an initialization sequence is performed (step S7), and the user terminal 3 sends a SELECT command APDU to the IC card 2 to select PPSE (Proximity Payment System Environment) (step S8).

[0045] Next, when the IC card 2 receives the SELECT command APDU (PPSE selection) from the user terminal 3, it selects a PPSE in accordance with the SELECT command APDU and transmits a response APDU to the SELECT command APDU to the user terminal 3 (step S9). Note that the response APDU to the SELECT command APDU (PPSE selection) includes the AID of the payment application installed in the IC card 2.

[0046] Next, after transmitting the SELECT command APDU in step S8, the user terminal 3 determines whether or not there is a reception error of the response APDU (step S10). For example, if the response APDU is not received from the IC card 2 within a predetermined time, the user terminal 3 determines that there is a reception error (step S10: YES), and notifies the user U of the error via the operation / display unit 33 (for example, displays an error on the display) (step S11). Next, the user terminal 3 transmits a challenge response message indicating authentication failure to the authentication server 4 (step S12).

[0047] Next, when the authentication server 4 receives a challenge response message indicating authentication failure from the user terminal 3, it transmits authentication information indicating authentication failure to the EC server 1 via the DS (step S13). When the EC server 1 receives the authentication information indicating authentication failure from the authentication server 4, it does not respond to the payment request and does not proceed to payment processing.

[0048] On the other hand, if the user terminal 3 determines in step S10 that there is no response APDU reception error by successfully receiving the response APDU from the IC card 2 (step S10: NO), it transmits a SELECT command APDU for selecting a payment application to the IC card 2 (step S14), as shown in Fig. 7. This SELECT command APDU includes the AID of the payment application. In other words, the user terminal 3 selects a payment application based on the AID included in the response APDU transmitted from the IC card 2 in step S9.

[0049] Next, upon receiving the SELECT command APDU (payment application selection) from the user terminal 3, the IC card 2 selects a payment application in response to the SELECT command APDU and transmits a response APDU to the SELECT command APDU to the user terminal 3 (step S15).

[0050] After transmitting the SELECT command APDU in step S14, the user terminal 3 determines whether or not there is a reception error in the response APDU, as in step S10 (step S16). The subsequent processes in steps S17 to S19 are the same as the processes in steps S11 to S13 described above.

[0051] On the other hand, in step S16, if the user terminal 3 determines that there is no reception error of the response APDU by successfully receiving the response APDU from the IC card 2 (step S16: NO), it transmits a GPO (Get Processing Options) command APDU for requesting an AFL (Application File Locator) or the like to the IC card 2 (step S20). Here, the GPO command APDU can also be referred to as a payment processing start command.

[0052] Next, upon receiving the GPO command APDU from the user terminal 3, the IC card 2 transmits a response APDU to the GPO command APDU, including an AFL (including, for example, a record number) indicating the storage area of ​​the application data to be read in response to the GPO command APDU, to the user terminal 3 (step S21). Here, the application data includes, for example, an ICC public key certificate, an issuer public key certificate, a CA public key index, a card number, and a sequence number.

[0053] After transmitting the GPO command APDU in step S20, the user terminal 3 determines whether or not there is a reception error in the response APDU, similarly to step S10 (step S22). The subsequent processes of steps S23 to S25 are similar to the processes of steps S11 to S13 described above.

[0054] On the other hand, in step S22, if the user terminal 3 determines that there is no reception error in the response APDU by successfully receiving the response APDU from the IC card 2 (step S22: NO), the user terminal 3 acquires the AFL from the response APDU and transmits a Read Record command APDU to the IC card 2 (step S26). For example, the record number assigned to the storage area of ​​the application data to be read is set in P1 in the header part of the Read Record command APDU.

[0055] Next, when the IC card 2 receives the Read Record command APDU from the user terminal 3, it reads application data (including, for example, the ICC public key certificate, the issuer public key certificate, the CA public key index, the card number, and the sequence number) from their respective storage areas in response to the Read Record command APDU, and transmits a response APDU to the Read Record command APDU containing the application data to the user terminal 3 (step S27).

[0056] After transmitting the Read Record command APDU in step S26, the user terminal 3 determines whether or not there is a reception error in the response APDU, as in step S10 (step S28). The subsequent processes in steps S29 to S31 are the same as the processes in steps S11 to S13 described above.

[0057] On the other hand, in step S28, if the user terminal 3 determines that there is no reception error of the response APDU by successfully receiving the response APDU from the IC card 2 (step S28: NO), it acquires application data from the response APDU (for example, temporarily stores it in RAM) and transmits a GENERATE AC command APDU (an example of a generation request) to the IC card 2 (step S32), as shown in Fig. 8. Here, if data to be signed has been acquired from the authentication server 4, the data portion of the GENERATE AC command APDU should preferably include the data to be signed.

[0058] Next, upon receiving the GENERATE AC command APDU from the user terminal 3, the IC card 2 generates an AC using an AC key according to the GENERATE AC command APDU in accordance with the symmetric key cryptography (step S33). If the GENERATE AC command APDU contains data to be signed, the IC card 2 generates an AC (an example of first signature data) using the AC key and the data to be signed in accordance with the symmetric key cryptography. For example, the AC is generated by a cryptographic operation (e.g., encryption) using the AC key and the data to be signed as input. Regardless of whether the GENERATE AC command APDU contains data to be signed, the IC card 2 may obtain a value that differs for each authentication, such as a random number or a transaction counter (ATC), and generate an AC using the AC key and the value according to the symmetric key cryptography. This makes it possible to reproduce an AC with a different value each time.

[0059] Next, the IC card 2 generates an SDAD using the ICC private key in accordance with public key cryptography (step S34). If the GENERATE AC command APDU contains data to be signed, the IC card 2 generates an SDAD (an example of second signature data) using the ICC private key and the data to be signed in accordance with public key cryptography. Regardless of whether the GENERATE AC command APDU contains data to be signed, the IC card 2 may obtain a value that differs for each authentication, such as a random number or transaction counter, as the data to be signed, and generate an SDAD using the ICC private key and the value in accordance with public key cryptography. This makes it possible to reproduce an SDAD with a different value each time.

[0060] Next, the IC card 2 transmits a response APDU to the GENERATE AC command APDU to the user terminal 3, the response APDU including verification data including the AD generated in step S33 and the SDAD generated in step S34, and an AC key index corresponding to the AC key used to generate the AC (step S35). Here, if the IC card 2 generates a random number as the data to be signed, the response APDU includes the data to be signed.

[0061] After transmitting the GENERATE AC command APDU in step S32, the user terminal 3 determines whether or not there is a reception error in the response APDU, as in step S10 (step S36). The subsequent processes in steps S37 to S39 are the same as the processes in steps S11 to S13 described above.

[0062] On the other hand, if the user terminal 3 determines in step S36 that there is no response APDU reception error by successfully receiving the response APDU from the IC card 2 (step S36: NO), it acquires verification data, an AC key index, etc. from the response APDU, and acquires a CA public key based on the RID included in the AID of the IC card 2 and the CA public key index (step S40). Next, the user terminal 3 uses the acquired CA public key to extract the issuer public key from the issuer public key certificate (step S41). Next, the user terminal 3 uses the extracted issuer public key to extract the ICC public key from the ICC public key certificate (step S42).

[0063] Next, the user terminal 3 verifies the SDAD included in the acquired verification data using an ICC public key (the ICC public key extracted in step S42) in accordance with public key cryptography (step S43), and obtains the result of the verification (success or failure). This verification can be performed using known techniques, and as an example, verification is performed by checking whether the SDAD can be successfully decrypted using the ICC public key. Alternatively, the user terminal 3 may verify the SDAD using an ICC public key and the data to be signed in accordance with public key cryptography. In this case, verification is performed by checking whether the data extracted from the SDAD using the ICC public key matches the data to be signed (if they match, the verification result is successful).

[0064] Next, the user terminal 3 determines whether the result of the verification in step S43 indicates success or not (step S44). If it is determined that the result of the verification does not indicate success (that is, indicates failure) (step S44: NO), the process proceeds to step S45. Note that the processes in steps S45 to S47 are the same as the processes in steps S11 to S13 described above.

[0065] On the other hand, if the user terminal 3 determines that the verification result indicates success (step S44: YES), it transmits a challenge response message including verification information indicating the result (success) of the verification in step S43 and the unverified AC (the AC included in the acquired verification data) to the authentication server 4 (step S48), as shown in Fig. 9. Here, the challenge response message may include the AC key index, card number, and sequence number acquired from the IC card 2. Furthermore, if a random number generated by the IC card 2 is acquired as data to be signed, the challenge response message includes the data to be signed.

[0066] Next, when the authentication server 4 receives the challenge response message from the user terminal 3, it acquires the verification information and the unverified AC etc. from the challenge response message, and acquires the AC key used in the IC card 2 (step S49). For example, the authentication server 4 identifies the AC master key from the AC key index, and acquires the AC key by deriving the AC key from the identified AC master key and the card number and sequence number acquired from the user terminal 3.

[0067] Next, the authentication server 4 verifies the acquired unverified AC using the AC key (the AC key acquired in step S49) according to a symmetric key cryptosystem (step S50), and obtains the result of the verification (success or failure). A known technique can be used for this verification method. For example, the AC is verified by checking whether it can be successfully decrypted using the AC symmetric key. Alternatively, the user terminal 3 may verify the AC using the AC key and the data to be signed according to a symmetric key cryptosystem. In this case, an AC is generated by a cryptographic operation using the AC key and the data to be signed as input, and the generated AC is verified by checking whether it matches the acquired unverified AC (if they match, the verification result is successful). If the result of the AC verification indicates failure, the authentication server 4 sends an error message to the user terminal 3.

[0068] Next, the authentication server 4 performs an authentication determination for the user U based on the result of the SDAD verification indicated in the acquired verification information and the result of the AC verification in step S50 (step S51). If the result of the SDAD verification indicates success and the result of the AC verification indicates success, the authentication is determined to be successful. Next, the authentication server 4 transmits authentication information indicating the result of the authentication determination in step S51 (authentication success or authentication failure) to the EC server 1 via the DS as information necessary for the EC server 1 to proceed with the payment processing (step S52).

[0069] Next, upon receiving the authentication information from the authentication server 4, the EC server 1 determines whether the result of the authentication determination for the user U indicates successful authentication based on the authentication information (step S53). If the EC server 1 determines that the result of the authentication determination for the user U indicates successful authentication (step S53: YES), it requests the acquirer's system to perform the subsequent payment process, and proceeds with the normal, general payment process (step S54).

[0070] On the other hand, if the EC server 1 determines that the result of the authentication determination of the user U does not indicate successful authentication (step S53: NO), it transmits error information indicating that the transaction is not possible to the user terminal 3 (step S55).

[0071] In the above operation example, the verification data including the AD and SDAD generated by the IC card 2 and the AC key index are transmitted to the user terminal 3 in a response APDU to the GENERATE AC command APDU (step S35). However, depending on the payment scheme, instead of the above operation example, the AD and SDAD may be generated by the IC card 2 in response to a GPO command APDU from the user terminal 3, and the verification data including the generated AD and SDAD and the AC key index may be transmitted to the user terminal 3 in a response APDU to the GPO command APDU (step S21). Alternatively, depending on the payment scheme, instead of the above operation example, the SDAD may be generated by the IC card 2 in response to a Read Record command APDU from the user terminal 3, and the generated SDAD may be transmitted to the user terminal 3 in a response APDU to the Read Record command APDU (step S27) (in this case, the AC and AC key index are transmitted in a response APDU to the GENERATE AC command APDU, as in the above operation example).

[0072] As described above, according to the above embodiment, the user terminal 3 is configured to send a request to generate signature data corresponding to each of the symmetric key cryptosystem and the public key cryptosystem to the IC card 2 in response to an authentication request from the authentication server 4, obtain an AC generated by the IC card 2 using the AC key according to the symmetric key cryptosystem and an SDAD generated by the IC card 2 using the ICC private key according to the public key cryptosystem, verify the SDAD using the ICC public key according to the public key cryptosystem, and transmit verification information indicating the results of the SDAD verification and the unverified AC to the authentication server 4. This makes it possible to achieve more secure user authentication by using an existing system without preparing a separate device. In other words, according to the above embodiment, a dedicated device and a dedicated authentication system corresponding to that device are not required, thereby reducing the introduction costs involved.

[0073] In the above embodiment, an example has been shown in which the IC card 2 generates an AC using an AC key according to a common key cryptosystem and generates an SDAD using an ICC private key according to a public key cryptosystem, but it may also be configured to generate multiple types of SDAD using respective ICC private keys according to multiple types of public key cryptosystems (e.g., RSA and ECC). In this case, the user terminal 3 acquires all of the multiple types of SDAD from the IC card 2, verifies them using the respective ICC public keys, and transmits verification information indicating the results of all of these verifications to the authentication server 4. Then, the authentication server 4 performs authentication determination for the user U based on the results of verification of all of the multiple types of SDAD indicated in the verification information from the user terminal 3.

[0074] Furthermore, in the above embodiment, the present invention has been described as being applied to an online payment system. However, the present invention can also be applied to door (or gate) opening systems other than online payment systems. In this case, the control device provided in the door (or gate) opening system is capable of communicating with the user terminal 3 and the authentication server 4. For example, when a user U carrying an IC card 2 and the user terminal 3 stands in front of the door (or gate), communication between the user terminal 3 and the control device begins, and the user terminal 3 sends a door (or gate) opening request to the control device. As a result, an authentication request is sent from the control device to the authentication server 4, and the user terminal 3 obtains access information to the authentication server 4 from the control device, as in the above embodiment. When the user terminal 3 accesses the authentication server 4 according to the access information, the authentication server 4 sends an authentication request to the user terminal 3.

[0075] Then, in response to an authentication request from the authentication server 4, the user terminal 3 transmits to the IC card 2 a request to generate signature data (e.g., AC and SDAD) corresponding to each of multiple cryptographic algorithms, as in the above embodiment. The IC card 2 generates each of the multiple types of signature data in response to the generation request from the user terminal 3 and transmits each of the generated signature data to the user terminal 3. The user terminal 3 verifies all or part of the multiple types of signature data from the IC card 2 and transmits verification information indicating the results of the verification of all or part of the signature data to the authentication server 4. The authentication server 4 performs an authentication decision on the user U based on the verification information from the user terminal 3 and transmits authentication information indicating the result of the authentication decision to the control device. Then, if the result of the authentication decision indicates success, the control device transmits a control signal to the door (or gate) driver to open the door (or gate). This opens the door (or gate). [Explanation of symbols]

[0076] 1. EC Server 2. IC card 3. User terminal 4 Authentication Server 21 I / O circuit 22 RAM 23 NVM 24 ROM 25 CPU 26 Coprocessors 32 Communications Department 33 Operation / display section 34 Storage section 35 Information Processing Department 41 Communications Department 43 Storage section 43 Information Processing Department S Online payment system

Claims

1. A user authentication method executed among a terminal device used by a user, an electronic information storage medium owned by the user, and an authentication device that transmits a first authentication request to the terminal device, comprising: a first transmission step in which the terminal device transmits, to the electronic information storage medium, a request for generating signature data corresponding to each of a plurality of cryptographic algorithms in response to the first authentication request from the authentication device; a generation step in which the electronic information storage medium generates each of the plurality of types of signature data in response to the generation request from the terminal device; a second transmission step in which the electronic information storage medium transmits each of the generated signature data to the terminal device; a first verification step in which the terminal device verifies all or part of the plurality of types of signature data from the electronic information storage medium; a third transmission step in which the terminal device transmits verification information indicating a result of verifying all or part of the signature data to the authentication device; a determination step in which the authentication device performs an authentication determination for the user based on the verification information from the terminal device; A user authentication method comprising:

2. the authentication device is capable of communicating with a transaction device for executing a settlement process in response to a settlement request from the terminal device; transmitting a second authentication request to the authentication device when the transaction device receives the settlement request from the terminal device; the authentication device transmitting the first authentication request to the terminal device in response to the second authentication request from the transaction device; a step in which the authentication device transmits authentication information indicating a result of authentication determination of the user to the transaction device as information necessary for the transaction device to proceed with the settlement process; 2. The user authentication method of claim 1, further comprising:

3. The plurality of cryptographic methods include a common key cryptosystem and a public key cryptosystem, the signature data corresponding to each of the plurality of cryptographic algorithms includes first signature data generated using a common key according to the common key cryptosystem and second signature data generated using a private key according to the public key cryptosystem; the electronic information storage medium and the authentication device store in advance the common key that is common between the electronic information storage medium and the authentication device, the electronic information storage medium stores in advance the private key unique to the electronic information storage medium; In the generating step, the electronic information storage medium generates the first signature data using the common key in accordance with the common key cryptosystem, and generates the second signature data using the private key in accordance with the public key cryptosystem; In the second transmission step, the electronic information storage medium transmits the generated first signature data and the generated second signature data to the terminal device, In the first verification step, the terminal device verifies the second signature data from the electronic information storage medium using a public key that forms a pair with the private key in accordance with the public key cryptosystem; In the third transmission step, the terminal device transmits verification information indicating a result of verification of the second signature data and the unverified first signature data to the authentication device; the user authentication method further includes a second verification step in which the authentication device verifies the unverified first signature data from the terminal device using the common key in accordance with the common key cryptosystem; 3. The user authentication method according to claim 2, wherein in the determination step, the authentication device determines that authentication is successful if the result of verification of the first signature data indicates success and the result of verification of the second signature data indicates success.

4. The user authentication method described in claim 3, characterized in that in the third transmission step, the terminal device transmits verification information indicating the result of verification of the second signature data and the unverified first signature data to the authentication device only if the result of verification of the second signature data indicates success.

5. 4. The user authentication method according to claim 3, wherein, if the result of the verification of the second signature data indicates failure, the terminal device notifies the user of an error.

6. the second authentication request and the generation request include signature target data generated by the authentication device; In the generating step, the electronic information storage medium generates the first signature data using the common key and the signature target data in accordance with the common key cryptosystem, and generates the second signature data using the private key and the signature target data in accordance with the public key cryptosystem; In the first verification step, the terminal device verifies the second signature data using a public key paired with the private key and the signature target data in accordance with the public key cryptosystem; 4. The user authentication method according to claim 3, wherein in the second verification step, the authentication device verifies the first signature data using the common key and the signature target data in accordance with the common key cryptosystem.

7. An authentication device used in the user authentication method according to claim 2, a first transmitting means for transmitting a second authentication request to the terminal device upon receiving the first authentication request; a determination means for determining authentication of the user based on the verification information from the terminal device; a second transmitting means for transmitting authentication information indicating the result of the authentication determination to the transaction device as information necessary for the transaction device to proceed to a settlement process according to the settlement request; An authentication device comprising:

8. 3. An electronic information storage medium used in the user authentication method according to claim 2, comprising: a generation means for generating each of the plurality of types of signature data in response to the generation request from the terminal device; a third transmission means for transmitting each of the generated signature data to the terminal device; An electronic information storage medium comprising:

9. 9. The electronic information storage medium according to claim 8, wherein the electronic information storage medium is an IC card issued to the user so that it can be used for settlement relating to electronic transactions.

10. A computer included in a terminal device used in the user authentication method according to claim 2, a fourth transmission means for transmitting a request for generating signature data corresponding to each of a plurality of cryptographic algorithms to the electronic information storage medium in response to the second authentication request from the authentication device; a verification means for verifying all or part of the plurality of types of signature data from the electronic information storage medium; a terminal program causing the terminal to function as a fifth transmitting means for transmitting verification information indicating a result of verification of all or part of the signature data to the authentication device;

11. A computer included in a terminal device that can communicate with an authentication device for authenticating a user of the terminal device and can communicate with an electronic information storage medium owned by the user, transmitting a request for generating signature data corresponding to each of a common key cryptosystem and a public key cryptosystem to the electronic information storage medium in response to an authentication request from the authentication device; acquiring first signature data generated by the electronic information storage medium using a common key common between the electronic information storage medium and the authentication device in accordance with the common key cryptosystem, and second signature data generated by the electronic information storage medium using a private key unique to the electronic information storage medium in accordance with the public key cryptosystem; verifying the second signature data using a public key paired with the private key according to the public key cryptosystem; transmitting verification information indicating a result of verification of the second signature data and the first signature data to the authentication device; A terminal program characterized by executing the above.

Images