Information processing method, information processing device, information processing system, and program

Abstract

The present disclosure relates to an information processing method, an information processing device, an information processing system, and a program that make it possible to make more secure linkage with services based on credentials using information on a secure component. The present disclosure is applicable to a service provision system that is based on credentials using information on a secure component by acquiring an SEID of a terminal device, issuing a credential including the SEID, and comparing the SEID supplied from the terminal device and the SEID of the credential.

Description

Information processing method, information processing device, information processing system, and program

[0001] The present disclosure relates to an information processing method, an information processing device, an information processing system, and a program, and in particular to an information processing method, an information processing device, an information processing system, and a program that enable more secure collaboration with services using credentials that utilize information on a secure component.

[0002] Device Binding is realized by acquiring and including in advance in a credential a public key corresponding to the private key held by the entity certified by the credential, and by simultaneously proving possession of the private key (digital signature) when presenting the credential. Holder Binding prevents the use of the aforementioned private key unless authentication and verification processes using the holder's biometric information or knowledge memory are successful, thereby confirming that the person who is able to use the private key in question is the person in question or the user (holder) who registered the private key (see Non-Patent Documents 1 and 2).

[0003] The secure components within a device where a credential holder stores his or her private key include secure areas with hardware and software tamper resistance, such as the Trusted Execution Environment (TEE), Secure Element (SE), and Secure Enclave. Tamper resistance refers to the ability of a device or system to prevent external analysis or modification of its internal confidential data and operations. This can be achieved through hardware-based detection functions such as sensors, software-based methods that separate the program execution environment (address management), or a combination of these. For example, some chips have a separate coprocessor for cryptographic calculations, but only limited sensors for detecting infrared rays and acceleration. These combinations of functions and implementations are the result of a trade-off between security and cost, and fall within the scope of the combination between SE and TEE in this patent.

[0004] For numerical verification, the evaluation assurance level (EAL) achieved through certification under the Common Criteria defined in ISO / IEC 15408 can be used to determine whether a chip is an SE or a TEE. SEs can generally achieve EAL4 and the highest level 5 of Advanced methodical vulnerability analysis (AVA_VAN) for tamper resistance against vulnerability analysis, so they are often described as EAL4+ with AVA_VAN.5. On the other hand, TEEs cannot achieve high scores in similar vulnerability analyses, and typically achieve EALs of 2 or 3, giving them different security capabilities than SEs.

[0005] TEEs create an isolated execution environment using software within existing application processors, so they do not require special hardware and can be manufactured relatively inexpensively, and are therefore installed in many devices on the market. However, their security is weak, and there is a risk that device-bound credentials may be issued to devices whose private keys can be analyzed.

[0006] On the other hand, a solution using a hardware tamper-resistant SE Applet (Google defines a Strong Box keymaster as a package that runs on a separate CPU and includes secure storage, a high-quality true random number generator, and anti-tamper functionality, providing side-channel resistance) offers high security, but is expensive, including operational costs, due to the separate CPU, and has not been widely adopted.

[0007] When binding using a key, the credential issuer must be responsible for verifying that the key is stored in the secure component.

[0008] However, if a credential is issued for a key pair that is not on the secure component due to a credential issuer's negligence, the private key can be duplicated, which increases the risk that the credential will also be duplicated, potentially resulting in the service provider verifying and using the duplicated credential being subject to fraudulent impersonation.

[0009] In this case, the service provider cannot know whether the issuer's policy is being implemented correctly, so they can only trust the credential issuer, and if this continues, the credentials will be duplicated, which will increase the damage to the service provider.

[0010] Therefore, a technique has been proposed in which a verifier detects a duplicate certificate by using proof of possession of a key (see Patent Document 1).

[0011] The technology of Patent Document 1 prevents the reuse of credentials obtained from other parties by signing a temporary random number value called a nonce with a private key linked to the identifier of the credential.

[0012] ISO / IEC 18013-5:2021 (ISO / IEC 18013-5:2021 - Personal identification - ISO-compliant driving license - Part 5: Mobile driving license (mDL) application) draft-ietf-oauth-selective-disclosure-jwt-07 (draft-ietf-oauth-selective-disclosure-jwt-07 - Selective Disclosure for JWTs (SD-JWT)

[0013] JP 2023-18431 A

[0014] However, even in the method of Patent Document 1, it is assumed that the owner of the key is the legitimate holder of the credential, and if the key is leaked or shared by a malicious credential holder, it becomes possible to make countless copies of the credential and share it.

[0015] The present disclosure has been made in light of such circumstances, and in particular aims to make collaboration with services using credentials that utilize information on secure components more secure.

[0016] An information processing method according to one aspect of the present disclosure is an information processing method including an acquisition process for acquiring an SEID of a terminal device, and an issuance process for issuing a credential including the SEID.

[0017] An information processing device, information processing system, and program according to one aspect of the present disclosure are an information processing device, information processing system, and program that include an acquisition unit that acquires an SEID of a terminal device, and an issuance unit that issues a credential that includes the SEID.

[0018] In one aspect of the present disclosure, an SEID of a terminal device is obtained, and a credential including the SEID is issued.

[0019] 14 is a diagram illustrating an example configuration of an information processing system that uses a credential including a device key. FIG. 15 is a diagram illustrating an overview of the information processing system of the present disclosure. FIG. 16 is a diagram illustrating an example configuration of a first embodiment of the information processing system of the present disclosure. FIG. 17 is a diagram illustrating an example configuration of a first embodiment of the information processing system of the present disclosure. FIG. 18 is a diagram illustrating an example configuration of a credential in the information processing system of FIG. 3. FIG. 19 is a flowchart illustrating credential issuance processing in the information processing system of FIG. 3. FIG. 19 is a flowchart illustrating credential verification processing in the information processing system of FIG. 3. FIG. 20 is a diagram illustrating an example UI display when a credential not including an SEID is used as a school commuter certificate. FIG. 21 is a diagram illustrating an example UI display when a credential including an SEID is used as a school commuter certificate. FIG. 22 is a diagram illustrating an example UI display when a credential not including an SEID is used as a live ticket. FIG. 23 is a diagram illustrating an example UI display when a credential including an SEID is used as a live ticket. FIG. 24 is a diagram illustrating a first application example of the first embodiment of the information processing system of the present disclosure. FIG. 25 is a diagram illustrating a second application example of the first embodiment of the information processing system of the present disclosure. FIG. 26 is a flowchart illustrating credential verification processing by the information processing system of FIG. 12. FIG. 27 is a diagram illustrating an example configuration of a second embodiment of the information processing system of the present disclosure. FIG. 28 is a flowchart illustrating credential issuance processing by the information processing system of FIG. FIG. 15 is a flowchart illustrating a credential issuance process by the information processing system of FIG. 14. FIG. 16 is a diagram illustrating a configuration example of a third embodiment of an information processing system of the present disclosure. FIG. 17 is a flowchart illustrating a credential issuance process by the information processing system of FIG. 17. FIG. 18 is a diagram illustrating a configuration example of a fourth embodiment of an information processing system of the present disclosure. FIG. 19 is a flowchart illustrating a credential issuance process by the information processing system of FIG. 19. FIG. 20 is a diagram illustrating a configuration example of a general-purpose computer.

[0020] Preferred embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings. In this specification and drawings, components having substantially the same functional configurations are designated by the same reference numerals, and redundant description will be omitted.

[0021] Hereinafter, embodiments of the present technology will be described in the following order.

[0022] 1. Overview of the present disclosure 2. First embodiment 3. First application example of the first embodiment 4. Second application example of the first embodiment 5. Second embodiment 6. Third embodiment 7. Fourth embodiment 8. Example of execution by software

[0023] <<1. Overview of the Present Disclosure>> The present disclosure aims to, in particular, increase the duplication resistance of credentials associated with terminals and terminal owners, and to make it possible to more safely link with services using credentials that utilize information on secure components. Therefore, an overview of the present disclosure will first be described.

[0024] First, we will explain information processing systems that provide services using credentials including private keys generated based on the SE, TEE, and Secure Enclave of a user's mobile device, such as Verifiable Credentials proposed by the non-profit standards organization W3C, mdoc (mobile document) defined in ISO / IEC 18013-5, and Digital Travel Credentials, which are digitized passports defined by ICAO, the International Civil Aviation Organization.

[0025] FIG. 1 shows an example of the configuration of an information processing system that provides services using credentials including private keys generated based on an SE, a TEE, and a Secure Enclave.

[0026] The information processing system 11 in FIG. 1 is composed of a mobile terminal (Device) 31, a credential issuing server 61 managed and operated by a credential issuer (Issuing Authority) 32, and a service provider server (Service Provider) 71 managed and operated by a service provider 33.

[0027] The mobile terminal 31 is carried by a user, requests the credential issuing server 61 to issue a credential CR, and stores the issued credential CR. When the mobile terminal 31 attempts to receive a service provided by the service provider 33, it presents the stored credential to the service provider server 71, and if the credential is verified, the user can receive the service.

[0028] More specifically, the mobile terminal 31 includes a credential storage application (Wallet App) 51 and a secure component 52 with a signature function.

[0029] The credential storage application 51 requests the credential issuing server 61 to issue a credential, and in response to this request, acquires and stores the issued credential in the credential issuing server 61 .

[0030] Furthermore, when receiving a service from the service provider server 71 , the credential storage application 51 reads out the stored credentials and presents them to the service provider server 71 .

[0031] The secure component with signature function 52 consists of an SE (Secure Element) and a TEE (Trusted Execution Environment), and when issuing a credential, generates a private key and a public key based on the SE, TEE, Secure Enclave, etc. in response to a request from the credential storage application 51.

[0032] At this time, the secure component with signature function 52 generates a public key certificate (Attestation) that proves that the public key has been generated, associates the generated public key, which is the device key, with the public key certificate, and supplies them to the credential storage application 51.

[0033] When the credential storage application 51 requests the credential issuing server 61 to issue a credential, it also supplies a public key, which is a device key.

[0034] In addition, when requesting the provision of a service from the service provider server 71, in response to the request from the service provider server 71, the credential storage application 51 controls the secure component with signature function 52 to sign the credential with the private key corresponding to the public key which is the device key, and presents the credential to the service provider server 71.

[0035] When the issuance of a credential is requested by the mobile terminal 31, the credential issuing server 61 issues a credential CR by inserting a device key, which is a public key supplied together with the request. At this time, the credential issuing server 61 signs the credential CR with an issuer private key out of a pair of issuer private key and issuer public key prepared in advance, and supplies the credential CR to the mobile terminal 31.

[0036] The credential storage application 51 acquires and stores the credential CR, which is supplied by the credential issuing server 61 and includes its own public key and is signed with the issuer's private key.

[0037] When the credential storage application 51 attempts to receive a service provided by the service provider 33, it signs the stored credential CR with a private key corresponding to the public key which is the device key, and supplies it to the service provider server 71 as a credential CR'.

[0038] When a mobile terminal 31 requests the provision of a service by a service provider 33, the service provider server 71 requests and acquires a credential CR', and then extracts a public key which is a device key of the mobile terminal 31 by verifying the signature of the acquired credential CR' with the issuer public key of the credential issuing server 61.

[0039] Furthermore, the service provider server 71 verifies the signature of the credential CR′ using the device key of the extracted mobile terminal 31 .

[0040] The process for issuing credentials based on the above configuration is as follows:

[0041] That is, in process St1 (FIG. 1), the credential storage application 51 of the mobile terminal 31 controls the secure component with signature function 52 to generate a pair of a private key and a public key based on the TEE, SE, and Secure Enclave.

[0042] In process St2, the credential storage application 51 of the mobile terminal 31 requests the credential issuing server 61 to issue a credential together with the device key, which is the public key generated in the secure component with signature function 52.

[0043] In process St3, the credential issuing server 61 issues a credential including a device key (public key) based on the credential issuance request from the mobile terminal 31, generates a pair of an issuer private key and an issuer public key, and signs the credential CR with the issuer private key. Note that, here, the credential signed with the issuer private key is referred to as the credential CR.

[0044] Then, in process St 4 , the credential issuing server 61 supplies the generated credential CR to the mobile terminal 31 .

[0045] As a result, the credential storage application 51 of the mobile terminal 31 stores the credential CR provided by the credential issuing server 61 .

[0046] Next, the process for receiving a service provided by the service provider server 71 is as follows.

[0047] That is, when the credential storage application 51 of the mobile terminal 31 requests the service provider server 71 to provide a service, in process St11, the service provider server 71 requests the credential CR from the credential storage application 51.

[0048] In process St 12 , the credential storage application 51 controls the secure component with signature function 52 to sign the credential CR with its own private key, thereby generating a credential CR′ and presenting it to the service provider server 71 .

[0049] In process St13, the service provider server 71 verifies the signature of the credential CR' supplied from the credential storage application 51 using the issuer public key, and extracts the public key that is the device key of the mobile terminal.

[0050] Furthermore, in process St 14 , the service provider server 71 verifies the signature of the credential CR′ using the public key of the extracted mobile terminal 31 .

[0051] If the signature verification proves to be satisfactory, the credential CR′ is recognized as authentic, and the service is provided to the mobile terminal 31 .

[0052] However, in the case of the information processing system 11 of FIG. 1, for example, if a credential is issued by the credential issuing server 61 using a public key that is not managed by the secure component with signature function 52 due to some kind of fraudulent activity or mistake, the credential will be duplicated.

[0053] Therefore, a technology has been proposed that prevents the reuse of credentials obtained from other parties by signing a temporary random number called a nonce with a private key linked to the credential identifier.

[0054] However, this method also assumes that the key owner is the legitimate holder of the credential, and if the key is leaked or shared by a malicious credential holder, it becomes possible to copy and share the credential countless times.

[0055] Therefore, in the present disclosure, a credential including a unique SEID (Secure Element IDentifier) ​​held by a secure component installed in a device such as the mobile terminal 31 is issued, thereby increasing the copy resistance of the credential and enhancing security of collaboration with services that use secure components such as an SE, a TEE, or a Secure Enclave. The SEID may be any identification information held by the secure component. For example, the SEID may be a unique identifier based on an industry standard, such as CPLC (Card Product Life Cycle) Data used in the credit card industry, or information that ensures uniqueness in communication, such as a UID or PUPI (Pseudo-Unique PICC Identifier) ​​used in NFC chips. In addition to the SEID, other SEIDs may also be considered, such as the International Mobile Subscriber Identity (IMSI) and Mobile Subscriber Integrated Services Digital Network Number (MSISDN) used in SIMs, the Integrated Circuit Card Identifier (ICCID) standardized by ISO / IEC 7812, and the eUICC Identifier (EID) used in eSIMs.

[0056] Therefore, in this disclosure, similar effects can be achieved using various identification information held by secure components. However, for ease of understanding, the term SEID will be used hereafter. The reason for the "similar effects" is that, for example, when using identifiers that cannot be changed at all from the information written at the time of shipment from the factory, high reliability and security strength are considered. Alternatively, if the information is written by the chip vendor during mass production of the chip and there is no software program that can modify or alter it from the operating system or application, there is no way to change it in the market, so reliability is also increased. On the other hand, information that is realized by businesses writing it in the market for user use, such as phone numbers, is likely to change during operation depending on the user's purpose. This could lead to a loss of consistency in the market, and it may not be possible to operate it in the same way as the aforementioned identifiers.

[0057] The SEID considered in this disclosure is assumed to be identification information that can be written by the chip vendor at the time of shipment from the factory or from a server that can write to the SE in the market, commonly known as the SEI-TSM (Secure Element Issuer-Trusted Service Manager).In terms of chip operation, if the identification information is written as the SEID by the SEI-TSM before the user uses electronic money or transportation services, and is operated as identification information that does not change thereafter while using the service in the market or until the aforementioned service is deleted, it can be determined to be identification information that can be used sufficiently in this disclosure.

[0058] In particular, by managing the keys required for normal credentials in the TEE and obtaining the SEID from the SE, it provides a simple method for improving security by using only the SEID, which can be obtained without installing a special program (sometimes a JavaCard Applet in the case of an SE equipped with JavaCard OS) into the SE, while still using inexpensive TEEs that are widely available on the market.In addition, as mentioned above, SEs are tamper-resistant and resistant to external hacking, making them a solution that uses highly reliable information.

[0059] FIG. 2 shows an example configuration for explaining an overview of an information processing system according to the present disclosure, which issues credentials including a unique SEID (Secure Element IDentifier) ​​held by a secure component installed in a mobile terminal 31.

[0060] The information processing system 101 in Figure 2 is composed of a mobile terminal (Device) 131 held by a user, a credential issuing server 161 managed and operated by a credential issuer (Issuing Authority) 132, and a service provider server 171 managed and operated by a service provider (Service Provider) 133.

[0061] The mobile terminal 131, the credential issuing server 161, and the service provider server 171 have configurations corresponding to the mobile terminal 31, the credential issuing server 61, and the service provider server 71 in Fig. 1, and have the same basic functions. However, the mobile terminal 131 differs in that it holds a credential that includes the SEID, because it extracts the SEID from the SEID-holding secure component 152 and requests the issuance of a credential that includes the SEID.

[0062] More specifically, the mobile terminal 131 includes a credential storage application (Wallet App) 151 and an SEID holding secure component 152 .

[0063] The basic function of the credential storage application 151 is the same as that of the credential storage application 51, but when receiving a service from the service provider server 171, the credential storage application 151 presents its own SEID to the service provider server 171 along with the stored credential.

[0064] The SEID holding secure component 152 holds an SEID, and when issuing a credential, supplies the SEID in response to a request from the credential storage application 151 .

[0065] When the credential storage application 151 requests the credential issuing server 161 to issue a credential, it also supplies the SEID.

[0066] In addition, when requesting the provision of a service from the service provider server 171, in response to the request from the service provider server 171, the credential storage application 151 presents the credential CR to the service provider server 171 via a first channel, and then controls the SEID holding secure component 152 to read the SEID and provide it to the service provider server 171 via a second channel.

[0067] When the mobile terminal 131 requests the issuance of a credential, the credential issuing server 161 issues a credential CR by inserting the SEID supplied together with the request. At this time, the credential issuing server 161 generates a pair of a corresponding issuer private key and an issuer private key, signs the credential CR with the generated issuer private key, and supplies it to the mobile terminal 131.

[0068] The credential storage application 151 acquires and stores the credential CR, which is supplied by the credential issuing server 161 and includes its own SEID and is signed with the issuer's private key.

[0069] When the credential storage application 151 attempts to receive a service provided by the service provider 133, it supplies the stored credential CR to the service provider server 171 via a first channel, and the service provider server then requests an SEID from the mobile terminal using a second channel, reads the SEID from the SEID-holding secure component 152, and supplies it to the service provider server 171 via the second channel.

[0070] When the mobile terminal 131 requests the provision of a service by the service provider 133, the service provider server 171 requests and acquires a credential CR via the first channel, and then verifies the signature of the acquired credential CR with the issuer public key of the credential issuing server 161. If the signature verification is successful, the credential can be trusted, and the service provider server 171 extracts the SEID of the secure component 152 installed in the mobile terminal 131 from the credential.

[0071] Furthermore, the service provider server 171 verifies the SEID by comparing the SEID of the secure component 152 installed in the mobile terminal 131 extracted from the credential with the SEID provided via the second channel. When verifying the SEID via the second channel, which is different from the channel used to present the credential, a verification method other than simple comparison may be used depending on the type of SEID. For example, if the SEID included in the credential is an MSISDN or IMSI, the service provider server can verify the association between the mobile terminal and the credential by making a voice call, sending an SMS push, or the like using the MSISDN or IMSI included in the credential obtained via the first channel.

[0072] The process for issuing credentials based on the above configuration is as follows:

[0073] That is, in process St31 (FIG. 2), the credential storage application 151 of the mobile terminal 131 controls the SEID holding secure component 152 to read the SEID.

[0074] In process St32, the credential storage application 151 of the mobile terminal 131 sends the SEID read from the SEID holding secure component 152 and a request to the credential issuing server 161 to issue a credential.

[0075] In process St33, the credential issuing server 161 issues a credential including an SEID based on a credential issuance request from the mobile terminal 131, generates a pair of an issuer private key and an issuer public key, and signs the credential CR with the issuer private key.

[0076] Then, in process St 34 , the credential issuing server 161 provides the generated credential CR to the mobile terminal 131 .

[0077] As a result, the credential storage application 151 of the mobile terminal 131 stores the credential CR including the SEID supplied by the credential issuing server 161 .

[0078] Next, the process for receiving a service provided by the service provider server 171 is as follows.

[0079] That is, when the credential storage application 151 of the mobile terminal 131 requests the service provider server 171 to provide a service, in process St51 (FIG. 2), the service provider server 171 requests the credential CR from the credential storage application 151.

[0080] In process St52, the credential storage application 151 presents the credential CR to the service provider server 171 via the first channel, and then controls the SEID holding secure component 152 to read the SEID and present it to the service provider server 171 via the second channel.

[0081] In process St 53 , the service provider server 171 verifies the signature of the credential CR supplied from the credential storage application 151 via the first channel using the issuer public key, and extracts the SEID of the secure component 152 installed in the mobile terminal 131 .

[0082] Furthermore, in the 54th process St54, the service provider server 171 compares and verifies the SEID of the secure component 152 installed in the extracted mobile terminal 131 with the SEID supplied from the mobile terminal 131 via the second channel.

[0083] If the two SEIDs match and there is no problem with the verification, the credential CR is recognized as authentic and the service is provided to the mobile terminal 131.

[0084] With the above-described configuration, the present disclosure increases the duplication resistance of credentials and makes binding with services that use SEs and TEEs more secure.

[0085] <<2. First Embodiment>> Next, a configuration example of an information processing system according to the present disclosure will be described with reference to FIG.

[0086] FIG. 3 shows an example configuration of an information processing system according to the present disclosure that issues credentials including a Secure Element IDentifier (SEID) unique to a device such as a mobile terminal.

[0087] The information processing system 201 in Figure 3 is composed of a mobile terminal (Device) 231 held by a user, a credential issuing server 261 managed and operated by a credential issuer 232, and a service provider server (Service Provider) 271 managed and operated by a service provider 233.

[0088] The mobile terminal (Device) 231, the credential issuing server 261, and the service provider server 271 have configurations corresponding to the mobile terminal (Device) 131, the credential issuing server 161, and the service provider server 171 in Figure 2, and have the same basic functions.

[0089] In addition, the mobile terminal (Device) 231, the credential issuing server 261, and the service provider server 271 are configured to be able to communicate with each other via a communication line such as the Internet, although this is not shown, and are able to exchange data and programs.

[0090] More specifically, the mobile terminal 231 includes a credential storage application (Wallet App) 251 , an SEID acquisition application (SE Manager) 252 , an SEID holding secure component 253 , and a client application (Service Provider Client App) 254 .

[0091] The credential storage application (Wallet App) 251 controls the SEID acquisition application 252 to read the SEID from the SEID holding secure component 253, cache it, and then acquire the SEID cached in the SEID acquisition application 252.

[0092] Furthermore, the credential storage application 251 requests the credential issuing server 261 to issue a credential together with the acquired SEID. In response to this request, the credential storage application 251 then acquires and stores the credential CR issued by the credential issuing server 261.

[0093] The SEID acquisition application 252 (SE Manager) is an application program for acquiring an SEID from the SEID holding secure component 253 controlled by the credential storage application 251. More specifically, the SEID acquisition application 252 accesses the SEID holding secure component 253, reads out the stored SEID, and caches it. The SEID acquisition application 252 also provides the cached SEID to the credential storage application 251.

[0094] The SEID holding secure component 253 is specifically an SE, which holds an SEID, and when issuing a credential or requesting the provision of a service, it allows access from the SEID acquisition application 252 and supplies the SEID in response to a request from the credential storage application 251.

[0095] When a client application (Service Provider Client App (hereinafter also referred to as SPC App)) 254 requests the provision of a service provided by the service provider 233, it requests the provision of the service from the service provider server 271, and in response, the service provider server 271 verifies the credentials, and if there are no problems with the verification, the service is provided.

[0096] When the credential issuance server 261 receives a credential issuance request from the mobile terminal 231, it issues a credential CR by inserting the SEID provided along with the request. At this time, the credential issuance server 261 signs the credential CR with the issuer private key, using a corresponding issuer private key pair stored in advance, and provides the credential CR to the mobile terminal 231. The key pair stored in advance is generated by the issuer when the credential issuance server 261 operates the corresponding service; if there are multiple applicable services, multiple issuer private keys are generated and stored accordingly. At this time, the private key to be used can be correctly selected by specifying the service to be used in the issuance request from the mobile terminal 231.

[0097] When a mobile terminal 231 requests the provision of a service by a service provider 233, the service provider server 271 requests and obtains a credential CR, and then verifies the signature of the obtained credential CR with the issuer public key of the credential issuing server 261.If the signature of the credential CR can be correctly verified, the credential CR can be trusted, and therefore the SEID of the SEID-holding secure component 253 installed on the mobile terminal 231 is extracted.

[0098] Furthermore, the service provider server 271 compares the SEID of the SEID-holding secure component 253 installed in the extracted mobile terminal 231 with the SEID obtained from the credential CR to verify whether they match, and if verified, begins providing the service.

[0099] Based on the above configuration, the process of issuing credentials in the information processing system 201 of FIG. 3 is outlined below.

[0100] That is, in process St71 (FIG. 3), the credential storage application 251 of the mobile terminal 231 controls the SEID acquisition application 252, which controls the SEID holding secure component 253 to read and cache the SEID.

[0101] In process St72 , the credential storage application 251 acquires the SEID cached in the SEID acquisition application 252 .

[0102] In process St73, the credential storage application 251 sends the acquired SEID to the credential issuing server 261, requesting the issuance of a credential.

[0103] In process St74, the credential issuing server 261 issues a credential including an SEID based on a credential issuance request from the mobile terminal 231, generates a pair of an issuer private key and an issuer public key, and signs the credential CR with the issuer private key.

[0104] Then, in process St75 , the credential issuing server 261 supplies the generated credential CR to the mobile terminal 231 .

[0105] As a result, the credential storage application 251 of the mobile terminal 231 stores the credential CR including the SEID supplied by the credential issuing server 261 .

[0106] Next, the outline of the process when receiving a service provided by the service provider server 271 is as follows.

[0107] That is, when the client application 254 requests the service provider server 271 to provide a service, in process St91, the service provider server 271 requests the credential storage application 251 to send the credential CR.

[0108] In process St92, the credential storage application 251 controls the SEID acquisition application 252 to read and cache the SEID stored in the SEID holding secure component 253. Furthermore, the credential storage application 251 acquires the SEID cached in the SEID acquisition application 252 and presents it to the service provider server 271 together with the credential CR.

[0109] In process St93, the service provider server 271 verifies the signature of the credential CR supplied from the credential storage application 251 using the issuer public key, and extracts the SEID of the mobile terminal.

[0110] Furthermore, in process St 94 , the service provider server 271 compares and verifies the SEID directly supplied from the mobile terminal 231 with the SEID of the mobile terminal 231 that has been extracted.

[0111] If the two SEIDs match and there is no problem with the verification, the service provider server 271 recognizes that the credentials CR are authentic and provides the service to the mobile terminal 231 .

[0112] With the above-described configuration, the present disclosure makes it possible to increase the duplication resistance of credentials and to make binding with services that use SEID more secure.

[0113] <SEID Verification> Next, details of SEID verification will be described with reference to FIG.

[0114] As shown in FIG. 4, methods for verifying the SEID of credentials that include an SEID can be broadly divided into online presentation of credentials via a network 291 such as the Internet, and offline presentation of credentials that are presented without going through a network 291 such as the Internet using a non-contact communication device 292 such as NFC (Near Field Communication) defined in ISO / IEC 14443 or ISO / IEC 18092 or Bluetooth (registered trademark) defined by the Bluetooth (registered trademark) SIG.

[0115] For online presentation via the network 291 shown on the left side of Figure 4, verification is performed by comparing the SEID in the credential through the series of processes described above with the SEID stored in the SEID-holding secure component 253 and acquired and presented by the client application 254 via the SEID acquisition application 252.

[0116] On the other hand, for offline presentation via the non-contact communication device 292 shown on the right side of Figure 4, in addition to the verification method similar to the online presentation described above, the non-contact communication device 292 reads the SEID stored in the SEID-holding secure component 253 directly from the SEID-holding secure component or indirectly via an SEID acquisition app, etc., and verifies it by comparing it with the SEID certified in the credential.

[0117] <Credential Issuance Processing by the Information Processing System of FIG. 3> Next, the credential issuance processing by the information processing system of FIG. 3 will be described with reference to the flowchart of FIG.

[0118] In step S31, the credential storage application (Wallet App) 251 determines whether or not a credential issuance request has been made by the user by operating a touch panel or the like (not shown), and repeats the same process until an issuance request is made.

[0119] If it is determined in step S31 that a credential issuance request has been made, the process proceeds to step S32.

[0120] In step S32, the credential storage application 251 requests the SEID acquisition application (SE Manager) 252 to acquire an SEID.

[0121] In response to this, in step S51, the SEID acquisition application 252 requests the SEID from the SEID-holding secure component (SE) 253.

[0122] In response to this, in step S71, the SEID held in the SEID holding secure component 253 is read by the SEID acquisition application 252, and the read SEID is cached.

[0123] In step S52, the SEID cached in the SEID acquisition application 252 is read out and supplied by the credential storage application 251.

[0124] In step S33, the credential storage application 251 requests the credential issuing server 261 to issue a credential together with the SEID.

[0125] In step S91, the credential issuing server 261 receives a credential issuance request and an SEID.

[0126] In step S92, the credential issuing server 261 generates a pair of an issuer private key and an issuer public key.

[0127] In step S93, the credential issuing server 261 issues a credential including the SEID.

[0128] In step S94, the credential issuing server 261 signs the issued credential with the issuer's private key.

[0129] In step S95, the credential issuing server 261 supplies the credential signed with the issuer private key to the credential storage application 251 of the mobile terminal 231.

[0130] In step S34, the credential storage application 251 stores the credential signed with the issuer's private key, which is supplied from the credential issuing server 261.

[0131] Through the above processing, a credential including an SEID is issued by the credential issuing server 261 and stored in the credential storage application 251 .

[0132] <Credential Verification Process by Information Processing System of FIG. 3> Next, the credential verification process by the information processing system 201 of FIG. 3 will be described with reference to the flowchart of FIG.

[0133] In step S121, the client application (SPC App) 254 determines whether or not a user has operated a touch panel (not shown) or the like to request the service provider to use the service, and repeats the same process until a request for use is received.

[0134] If it is determined in step S121 that a service utilization request has been made to the service provider, the process proceeds to step S122.

[0135] In step S122, the client application 254 requests the service provider server 271 to use the service.

[0136] In response to this, in step S181, the service provider server 271 requests the credential storage application 251 of the mobile terminal 231 to present the credential.

[0137] In step S101, the credential storage application 251 displays, on a touch panel or the like (not shown), a message indicating that a credential presentation request has been made, and displays an image inquiring whether or not to accept the credential presentation request.

[0138] In step S102, the credential storage application 251 determines whether or not the touch panel or the like is operated to present the credential, and repeats the same process until the credential is presented. If the credential is not presented, the process ends.

[0139] In step S102, if the request to present credentials is accepted, the process proceeds to step S103.

[0140] In step S103 , the credential storage application 251 presents the stored credential CR on a touch panel or the like (not shown), and also supplies the credential CR including the SEID to the service provider server 271 .

[0141] In step S182, the service provider server 271 acquires the credentials including the SEID and verifies the signature using the issuer public key.

[0142] In step S183, the service provider server 271 holds the SEID included in the credential by verifying the signature of the credential with the issuer public key.

[0143] In step S184, the service provider server 271 requests the SEID from the client application 254.

[0144] In step S123, the client application 254 requests the SEID from the SEID acquisition application 252.

[0145] In step S141, the SEID acquisition application 252 requests the SEID holding secure component 253 for an SEID.

[0146] In step S161, the SEID held in the SEID holding secure component 253 is read by the SEID acquisition application 252 and cached.

[0147] In step S142, the SEID cached in the SEID acquisition application 252 is read by the client application 254.

[0148] In step S124, the client application 254 supplies the read SEID to the service provider server 271.

[0149] In step S185, the service provider server 271 compares the SEID obtained from the credentials held by the service provider server 271 with the SEID provided by the client application 254, and verifies the SEID based on whether or not they match.

[0150] In step S186, the service provider server 271 notifies the verification result. That is, if both SEIDs match, the service provider server 271 notifies that the SEID has been verified and that the service is ready to be provided.

[0151] In step S126, when the client application 254 is notified that the service provision is ready based on the result of the SEID verification, the client application 254 requests the provision of the service and starts using the service.

[0152] If the two do not match in step S186, a notice that the service cannot be provided is sent in step S125, and the service cannot be provided.

[0153] Through the above process, when using a credential that includes an SEID, it is confirmed that the SEID included in the credential matches the SEID of the terminal being used, so even if the credential is duplicated, it cannot be used.

[0154] As a result, it becomes possible to make binding with services that use SEID more secure.

[0155] <Example of credentials being a school commute certificate> For example, as shown in Figure 7, consider the case where an application for a school commute certificate, as shown in display V1, results in the issuance of a credential consisting of a school commute certificate that does not include an SEID, as shown in display V2, and the credential is stored in the credential storage application 251.

[0156] Display V1 is a display screen for requesting the issuance of a commuter certificate, and from top to bottom, the student information shows the school name "XX University," the faculty / department "Faculty of Economics," the name "Taro Tanaka," the student number "13441123," and the main campus "●● Campus XX Prefecture **1-1-1." Additionally, buttons are displayed to select either "New: Commuter Certificate" or "Change of Section / Certificate Renewal" as the application category.

[0157] Furthermore, it is shown that the nearest stations to the home are "JR Line," "●AAA Station," "〇BBB Station," and "〇CCC Station."

[0158] It also shows that the nearest stations to home are "JR Line," "●AAA Station," "〇BBB Station," and "〇CCC Station," and the nearest stations to school are "JR Line," "XXX Station," and "YYY Station."

[0159] In display V1, the bottom row displays a button labeled "APPLY" that is operated to instruct an application.

[0160] That is, when the button labeled "Apply" at the bottom of display V1 is operated, an application process is carried out to issue credentials consisting of a commuter certificate, based on the information displayed as a commuter certificate application in display V1.

[0161] Furthermore, when an application process is performed using display V1 and credentials that do not include an SEID as a school commute certificate are stored in the credential storage application 251, the information on the stored credentials is displayed as display V2.

[0162] In display V2, the contents of the school commuter certificate, which is a credential that does not include an SEID, are listed as follows: school name "XX University," faculty / department "Faculty of Economics," name "Taro Tanaka," student number "13441123," and main campus "●● Campus XX Prefecture **1-1-1." In other words, the credential displayed in display V2 does not include an SEID.

[0163] When the credentials shown in display V2 are used to apply for a student commuter pass to the transportation company that is the service provider 233, display V3 for the student commuter pass application is displayed. Display V3 shows routes 1 and 2, and allows you to select the purchase period. Below that, a button labeled "Upload certificate" and a button labeled "Back" are displayed.

[0164] Here, when the button labeled "Upload Certificate" in display V3 is operated, the school commuting certificate, which is a selectable credential registered as "School District Certificate," is displayed as an option as shown in display V4.

[0165] In display V4, the commuter certificates are displayed as selectable credentials, with "2023.04.01" and "2022.08.25" written on the left, and the commuter certificate on the left with "2023.04.01" written on the right is selected.

[0166] Below that, it says "Route approved," notifying the student that the route for the school commute certificate with "2023.04.01" written on the left has been approved.

[0167] Furthermore, below that, a button labeled "Proceed to checkout" and a button labeled "Back" are displayed.

[0168] When the button labeled "Proceed to purchase" in display V4 is pressed, the message "Student commuter pass being issued" is displayed, and the commuter pass is issued using the credentials consisting of the student commuter certificate, and the SEID of the mobile device is displayed, as shown in display V5. In display V5, the SEID is displayed as "8901-2345-6789-0123-4567-8901."

[0169] That is, following the flow of displays V1 to V5, a student commuter pass is issued using credentials consisting of a legitimate student commuter certificate.

[0170] However, since the credential consisting of the school commuter certificate in Figure 7 does not include an SEID, even if display V2 is copied and a credential consisting of a fraudulent school commuter certificate displayed in display V12 is duplicated, a school commuter pass can be issued in the same way as a credential consisting of a legitimate school commuter certificate, as shown in displays V13 to V15.

[0171] On the other hand, since the credentials disclosed herein include an SEID, for example, when an application is made for a school commute certificate as shown in display V31 (same as display V1) in Figure 8, the SEID information included in the school commute certificate, which is a credential, is registered under the notation "Main Campus" in addition to the information in display V2, as shown in display V32.

[0172] In display V32, the SEID included in the credential is written as "8901-2345-6789-0123-4567-8901."

[0173] After that, if you upload the certificate as shown in displays V3 and V4 and corresponding displays V33 and V34 and proceed with the purchase procedure, the SEID of the mobile device will match the SEID included in the credentials, and you will be able to issue a student commuter pass.

[0174] On the other hand, as shown in display V42, even if display V32 is copied and credentials consisting of a fraudulent school commuter certificate are duplicated, and even if they are uploaded as shown in displays V43 and V44 and the purchase procedure is proceeded with, if the SEID on the mobile device does not match the SEID contained in the credentials, the message "SEID did not match" will be displayed and the school commuter pass will not be issued.

[0175] In display V45, the SEID contained in the credential, which is the "certificate SEID," is displayed as "8901-2345-6789-0123-4567-8901," while the "terminal SEID" is displayed as "8998-7654-3210-9876-5432-1098," indicating that the two do not match.

[0176] In this way, since the SEID is included in the student commuter certificate as a credential, even if it is duplicated, it will not match the SEID on the device when compared with the SEID on the device when purchasing a student commuter pass, making it possible to prevent fraudulent use.

[0177] <Example of credentials being a live ticket> Consider a case where, for example, as shown in FIG. 9, a live ticket purchase display such as that shown in display V61 is displayed, and credentials consisting of a live ticket that does not include an SEID, such as that shown in display V62, are issued and stored in the credential storage application 251.

[0178] In display V61, from the top of the figure, there is a notation indicating the purchase of a live ticket for the "XX Exhibition," and below that it says "Please select the performance date and time," and four options are displayed, with a box placed around the top option, "December 6, 2023, 15:00-17:00," indicating that it has been selected.

[0179] Below that, it says "Select Venue" and displays two options, with a box around "Tokyo Venue" indicating that it has been selected.

[0180] In display V61, the button labeled "Proceed to purchase procedure," which is operated when instructing a purchase, is displayed in the second position from the bottom, and below that is a button labeled "Back."

[0181] That is, when the button labeled "Proceed to purchase procedure" in display V61 is operated, the information displayed as the live ticket in display V2 is issued as a credential.

[0182] Furthermore, when a purchase process is performed using display V61 and credentials that do not include an SEID as a live ticket are stored in the credential storage application 251, information about the stored credentials is displayed as display V62.

[0183] Display V62 shows the contents of the live ticket as a credential that does not include SEID, including the performance name "XXX Exhibition," the venue number "1344123," the name "Taro Tanaka," the venue "Tokyo," and the time "15:00-17:00." In other words, the credential displayed in display V62 does not include SEID.

[0184] When the credential shown in display V62 is used and presented offline to a contactless communication device 292 installed at the entrance of a live concert venue, for example, the SEID of the mobile terminal is read. In this example, it is shown that the SEID of the terminal is "8901-2345-6789-0123-4567-8901."

[0185] Then, as shown in display V63, the live tickets that are registered credentials are displayed as a list, and in the figure, it is shown that the live ticket for the ``XX Exhibition'' on the left has been selected.

[0186] Below that are displayed buttons labeled "Present Selected Ticket," which are operated when presenting the selected ticket, and "Back." When the button labeled "Present Selected Ticket" is operated, the live ticket is presented to the live ticket seller, which is the service provider 233, as shown in display V64, and the message "Ticket Authenticated" is displayed, allowing the live ticket to be used (for example, for entry into the venue).

[0187] That is, following the flow of displays V61 to V64, admission to the live concert venue is possible using credentials consisting of a legitimate live concert ticket.

[0188] However, since the credential consisting of the school commuter certificate in Figure 9 does not include an SEID, even if display V62 is copied and the credential consisting of the fraudulent live concert ticket displayed in display V72 is duplicated, it is possible to enter the live concert venue in the same way as with the credential consisting of the legitimate live concert ticket, as shown in displays V73 to V74.

[0189] On the other hand, since the credentials disclosed herein include an SEID, for example, when a live ticket shown in display V81 (identical to display V61) in Figure 10 is purchased, the SEID information included in the live ticket, which is the credential, is registered under the "time" notation in addition to the information in display V62, as shown in display V82.

[0190] In display V82, the SEID included in the credential is written as "8901-2345-6789-0123-4567-8901."

[0191] Thereafter, when the live ticket is presented as in the displays V83 and V84 corresponding to the displays V63 and V64, the SEID of the mobile terminal matches the SEID included in the credentials, and the live ticket is authenticated.

[0192] On the other hand, as shown by display V92, even if display V82 is copied and credentials consisting of an unauthorized live ticket are duplicated, the SEID of the mobile terminal is read when the ticket is presented offline to contactless communication device 292. Here, it is shown that "8998-7654-3210-9876-5432-1098" is read as the SEID of the terminal.

[0193] In other words, the SEID "8901-2345-6789-0123-4567-8901" contained in the credential does not match the terminal's SEID "8998-7654-3210-9876-5432-1098."

[0194] Therefore, even if a live ticket is presented as shown in displays V93 and V94, the SEID of the mobile terminal will not match the SEID contained in the credentials, so the message "SEID did not match" will be displayed and the live ticket will not be authenticated.

[0195] In this way, since the SEID is included in the live ticket as a credential, even if it is duplicated, it will not match the SEID on the device when the live ticket is purchased, making it possible to prevent fraudulent use such as resale of the live ticket.

[0196] (Example of Credentials as Electronic Money Value Charges) Another use case is a token, where a certificate provided as a credential is used to charge electronic money or other value. Assuming there is a desire to fix the person who assigns the electronic money value, an SEID is assigned to the credential. For example, a credential is set up that specifies a charge of "10,000 yen" for Edy (registered trademark) and the SEID of the device owned by the recipient, "8901-2345-6789-0123-4567-8901." The SEID of the device owned by the recipient is extracted from the user's device during user registration and registered along with the user information. While there are systems that identify recipients by phone number or other information and transfer funds, unlike account numbers, the connection between phone numbers and people is fluid. Even if the recipient's status has changed since the last time they were sent, the recipient's current status may not be confirmed when sending. Therefore, confirming the combination of the phone number and the SEID owned by the device is expected to provide higher security.

[0197] When a credential is presented online to a verifier with credential verification capabilities, the verifier verifies the signature attached to the credential. Depending on the type of electronic money, signature verification is performed using a public key from a pre-determined electronic money service provider. It is also possible that a public key from a consortium, such as the Electronic Money Promotion Association or the Electronic Money Promotion Study Group, which is jointly operated by electronic money service providers, is used. If signature verification is successful, the next step is to confirm the details and send an issuance request, including the amount to be charged, to the electronic money charge server. When charging, the electronic money charge server obtains the SEID of the terminal that received the credential and verifies whether the SEID, "8901-2345-6789-0123-4567-8901," listed on the credential can be extracted from the terminal. This process establishes a binding with the terminal for which the credential is issued, preventing unauthorized charging to other mobile devices and ensuring secure charging.

[0198] (Example of a credential being a car membership card) Another use case is when a certificate provided as a credential is used as a vehicle membership card. For example, by registering an SEID in a credential, it is possible to limit the SEs that can register a Digital Car Key (DCK) when renting a car. Limiting the SEs that can issue a DCK ensures that the key can only be assigned to a pre-bound mobile device, rather than to an unspecified number of people, making it a safe approach from an operational standpoint. For example, if an SEID is registered only to a family member's mobile phone, only that family member can register a DCK. Therefore, even if a malicious attacker were to steal the key registration data, it would not be able to store and use it.

[0199] (Example of a certificate containing the normal value of a breathalyzer test.) Another use case is one in which a breathalyzer generates a credential. The Road Traffic Act was amended in 2022 to require alcohol tests for companies with a certain number of company vehicles with white license plates. Starting December 1, 2023, breathalyzer tests will be mandatory. Therefore, breathalyzer tests are required every time employees enter or exit a company vehicle. In this case, assume that a certificate is issued containing the normal value of the breathalyzer, indicating that the alcohol level is below the normal limit. This certificate includes the SEID of the device owned by the user who is expected to use the car. By providing this certificate to an online or offline verifier, DCK distribution can be limited to SEs with the corresponding SEID on the server. Limiting the SEs that can issue DCKs ensures that keys can only be assigned to pre-bound mobile devices, rather than to an unspecified number of people, providing a secure operational approach.

[0200] (Example of credentials being an employee ID card) One possible use case is when a certificate provided as a credential is used as an employee ID card. Suppose Company A, which encourages BYOD (Bring Your Own Device), signs up for lines on behalf of its employees for their mobile devices. Company A issues employee ID cards that include the EID of the eSIM installed in the employee's mobile device. When the employee activates a corporate contracted profile, they present the employee ID card to the telecommunications carrier to prove they are an employee of Company A. Because the telecommunications carrier can provision the profile to the EID included in the employee ID card issued by Company A, the profile will not be activated on any eSIM other than those on devices approved by Company A, preventing unauthorized use of the line.

[0201] <<3. First Application Example of First Embodiment>> In the above, an example has been described in which the mobile terminal 231 includes a credential storage application (Wallet App) 251, an SEID acquisition application (SE Manager) 252, an SEID-holding secure component 253, and a client application (Service Provider Client App) 254, and the credential storage application 251 uses the SEID acquisition application 252 to acquire an SEID from the SEID-holding secure component 253.

[0202] However, without providing the SEID acquisition application 252, the credential storage application (Wallet App) 251 and the client application (Service Provider Client App) 254 may acquire the SEID directly from the SEID holding secure component 253 via the OS API.

[0203] FIG. 11 shows an example of the configuration of an information processing system in which a credential storage application (Wallet App) 251 directly acquires an SEID from an SEID-holding secure component 253 via an OS API, without providing an SEID acquisition application 252.

[0204] The information processing system 201' in FIG. 11 is similar in basic configuration to the information processing system 201 in FIG. 3, but is configured with a mobile terminal 231' instead of the mobile terminal 231.

[0205] The mobile terminal 231' differs from the mobile terminal 231 in that it does not have an SEID acquisition application 252, and the credential storage application (Wallet App) 251 and the client application (Service Provider Client App) 254 acquire the SEID directly from the SEID holding secure component 253 via the OS API 331.

[0206] Note that the process is the same as that of the mobile terminal 231, except that the SEID acquisition application 252 is not provided and the credential storage application (Wallet App) 251 and the client application (Service Provider Client App) 254 acquire the SEID directly from the SEID-holding secure component 253 via the OS API 331. Therefore, the credential issuance process and credential verification process will not be described here.

[0207] <<4. Second Application Example of First Embodiment>> In the above, an example has been described in which the credential verification process is performed by the service provider server 271 itself.

[0208] However, when a service is requested, a service issuance command generation server may be added that generates a service issuance command, encrypts the service issuance command with an individual key based on the SEID and master key contained in the credentials, supplies it to the mobile terminal 231, and presents the service issuance command decrypted using the SEID to the service provider server 271, thereby allowing the service to be provided.

[0209] In other words, the authentication process between the terminal's SEID and the credential's SEID can be performed as key authentication, in which the service issuance command generation server encrypts the service issuance command with an individual key generated from the SEID and master key and supplies it to the mobile terminal, and the mobile terminal then properly decrypts it using the SEID and presents it to the service provider server.

[0210] FIG. 12 shows an example of the configuration of an information processing system that performs credential verification processing by key authentication using an individual key generated based on the SEID and master key included in the credential.

[0211] The information processing system 201 ″ in FIG. 12 shows only the configuration required for credential verification processing, and is made up of a mobile terminal 231 ′, a service provider server 271 ′, and a service issuing command generating server (SE Manager Backend Server) 301 .

[0212] The mobile terminal 231' has the same basic functions as the mobile terminal 231, but is provided with a client application 254' instead of the client application 254. When requesting the provision of a service from the service provider server 271', the client application 254' presents credentials including an SEID. The credentials may be presented online or offline.

[0213] The service provider server 271 ′ extracts the SEID contained in the credential and supplies it to the service issuing command generating server 301 .

[0214] When the service issuance command generation server 301 receives an SEID from the service provider server 271', it generates an individual key from the SEID and the master key, and generates a service issuance command for realizing the service requested by the mobile terminal 231', encrypts it with the individual key, and supplies it to the mobile terminal 231'.

[0215] This individual key is generated by generating a unique string using identity-based encryption (IBE) including information indicating the master key, SEID, key length, and target algorithm, as well as information to avoid duplication even within the same SE, such as the AID information of the target SD, and then encrypting the string. For example, a key derivation function (KDF) for deriving an additional key from an existing encryption key, as defined in NIST SP800-108 or the like, may be used. Types of KDFs include counter mode KDFs, feedback mode KDFs, double pipeline mode KDFs, and KMAC-based KDFs, but any type is within the scope of this disclosure.

[0216] The client application 254' of the mobile terminal 231' decrypts the encrypted service issuing command using the SEID, and supplies the decrypted service issuing command to the service provider server 271', thereby receiving the service.

[0217] That is, in this configuration, the service provider server 271' retains the SEID of the credential, but the process of acquiring and verifying the SEID of the mobile terminal 231' is eliminated. Instead, the SEID of the credential is supplied from the service provider server 271' to the service issuing command generation server 301. The service issuing command generation server 301 then encrypts the service issuing command with an individual key that uses the SEID of the credential and the master key, and supplies the encrypted service issuing command to the mobile terminal 231'.

[0218] The mobile terminal 231' uses the SEID of its own terminal to decrypt the service issuing command that has been encrypted with the SEID of the credential and the individual key generated using the master key.

[0219] In other words, unless the SEID of the credential and the SEID of the mobile terminal match, the service issuing command cannot be decrypted, and therefore the service issuing command cannot be presented to the service provider server 271', and the service cannot be provided.

[0220] As a result, the service issuing command is encrypted with an individual key using the SEID of the credential and the master key, and then decrypted with the SEID of the mobile terminal 231', whereby the two SEIDs are compared and verified.

[0221] The outline of the above processing is as follows:

[0222] In process St111 (FIG. 12), the client application 254′ presents the credentials including the SEID to the service provider server 271′.

[0223] In process St 112 , the service provider server 271 ′ verifies the signature of the credential with the issuer private key, extracts the SEID, and supplies the extracted SEID of the credential to the service issuing command generating server 301 .

[0224] In process St113, the service issuing command generation server 301 generates an individual key based on the SEID of the credential and the master key. At this point, the service issuing command generation server 301 notifies the client application 254 that the individual key is ready.

[0225] In response to this notification, in process St114, the client application 254 requests the service issuing command generating server 301 to issue a service issuing command.

[0226] In process St115, the service issuing command generating server 301 generates a service issuing command in response to this request and encrypts it with an individual key.

[0227] Then, in process St 116 , the service issuing command generating server 301 supplies the service issuing command encrypted with the individual key to the client application 254 .

[0228] In process St117, the client application 254 decrypts the service issuing command encrypted with the individual key using the SEID, and presents it to the service provider server 271'.

[0229] In process St118, the service provider server 271' starts providing the service to the mobile terminal 231' based on the service issuing command.

[0230] Through the above processing, the service issuance command is encrypted with an individual key generated from the SEID of the credential and the master key, and then decrypted with the SEID of the mobile terminal 231'. Both SEIDs are verified, and if they match, the service issuance command is decrypted and can be presented to the service provider server 271', making it possible to receive the service.

[0231] <Credential Verification Processing by the Information Processing System of FIG. 12> Next, the credential verification processing by the information processing system 201' of FIG. 12 will be described with reference to the flowchart of FIG.

[0232] The processes of steps S201 to S203, S221 to S222, S281, and S282 in FIG. 12 are similar to the processes of steps S101 to S103, S121 to S122, and S181 and S182 in FIG. 6, and therefore will not be described again.

[0233] That is, in step S282, the credential including the SEID is signature verified using the issuer public key, and the included SEID is obtained by the service provider server 271'', and then in step S283, the service provider server 271' supplies the SEID to the service issuance command generation server 301.

[0234] In step S291, upon acquiring the SEID, the service issuing command generating server 301 derives an individual key based on the SEID and the master key.

[0235] In step S292, the service issuing command generating server 301 issues a session ID and supplies the session ID and a notification indicating that the individual key is ready to the service provider server 271.

[0236] In step S284, the service provider server 271' provides the client application 254' with a notification indicating that the individual key is ready and the session ID.

[0237] In step S223, the client application 254' requests the SEID acquisition application 252 to issue a service together with the session ID.

[0238] In step S241, the SEID acquisition application 252 requests the service issuing command generating server 301 to issue a service together with a session ID.

[0239] In step S 293 , the service issuing command generating server 301 generates a service issuing command, encrypts it with an individual key, and supplies it to the SEID acquisition application 252 .

[0240] In step S242, the SEID acquisition application 252 supplies the service issuing command encrypted with the individual key to the SEID holding secure component 253.

[0241] In step S261, the SEID-holding secure component 253 decrypts the service issuing command encrypted with the SEID.

[0242] In step S262, the SEID-holding secure component 253 supplies the decrypted service issuing command to the SEID acquisition application 252.

[0243] In step S243, the SEID acquisition application 252 notifies the service issuing command generation server 301 that the acquisition of the service issuing command has been completed.

[0244] In step S294, the service issuing command generation server 301 receives a notification indicating that the service issuing command has been obtained, and notifies the SEID acquisition application 252 of this.

[0245] In step S244, when the SEID acquisition application 252 receives a notification from the service issuance command generation server 301 indicating that the issuance of the service issuance command has been completed, it notifies the client application 254 that the issuance of the service issuance command has been completed.

[0246] In step S224, the client application 254 supplies a service issuing command to the service provider server 271'.

[0247] In step S285, the service provider server 271' starts providing the service to the mobile terminal 231' based on the service issuing command.

[0248] In step S225, the client application 254 starts using the service.

[0249] Furthermore, in step S261, if the service issuance command cannot be decrypted, that is, if the SEID of the credential does not match the SEID of the mobile terminal, the service issuance command cannot be presented to the service provider server 271', and therefore the service cannot be provided.

[0250] Through the above process, the credential is issued with the SEID included, and when it is used, it is confirmed which SEID the credential was issued to, so even if the credential is duplicated, it cannot be used.

[0251] The service issuance command is encrypted with an individual key generated from the SEID of the credential and the master key, and then decrypted with the SEID of the mobile terminal 231'.The two SEIDs are compared and verified, and if they match, the service issuance command is decrypted and can be presented to the service provider server 271', making it possible to receive the service.

[0252] As a result, it becomes possible to make binding with services that use SEID more secure.

[0253] <<5. Second embodiment>> In the above, an example has been described in which, when issuing a credential, an SEID is supplied from the mobile terminal 231 and a request for issuance of a credential is made to the credential issuing server 261, whereby a credential including the SEID is issued and stored in the mobile terminal 231.

[0254] However, it does not provide a countermeasure against a so-called replay attack, in which the SEID sent along with a credential request is stolen and the stolen SEID is used to issue a credential, resulting in a duplicated credential.

[0255] Therefore, in order to counter replay attacks, the SEID may be signed and provided to the credential issuing server.

[0256] FIG. 14 shows an example of the configuration of an information processing system in which a signature is applied to an SEID and the SEID is supplied to a credential issuing server in order to counter replay attacks.

[0257] The information processing system 201A in FIG. 14 is composed of a mobile terminal 231A and a credential issuing server 261A managed and operated by a credential issuer.

[0258] 14 and subsequent figures, only the configuration for issuing credentials is shown, and the configuration for verifying credentials is omitted. However, it is assumed that the configuration for verifying credentials is the same as the configuration in the information processing system 201 or 201″ described with reference to FIG. 3 or FIG. 12.

[0259] The mobile terminal 231A includes a credential storage application 251A, an SEID acquisition application 252A, an SEID holding secure component 253A-1, and a secure component with signature function 253A-2.

[0260] The secure component with signature function 253A-2 generates a pair of public and private client keys for signing credentials, and supplies the public key body of the client key and reference information to the private key of the client key (information indicating which private key to use) to the SEID acquisition application 252A, which caches them.

[0261] When the credential storage application 251A requests the credential issuance server 261A to issue a credential, it also supplies the public key of the client key cached in the SEID acquisition application 252A.

[0262] The credential storage application 251A receives a server challenge consisting of a random number corresponding to the client key supplied from the credential issuing server 261A, and supplies it to the SEID acquisition application 252A.

[0263] When the SEID acquisition application 252A receives the server challenge, it reads the SEID from the SEID holding secure component 253A and requests a signature from the secure component with signature function using the server challenge, the SEID, and reference information to the private key of the client key. The secure component with signature function signs the server challenge and SEID supplied from the SEID holding secure component with the specified private key and supplies them to the SEID holding secure component. The SEID holding secure component supplies the supplied signature to the credential storage application 251A.

[0264] The credential storage application 251A provides the server challenge signed with the private key of the client key and the SEID to the credential issuing server 261A.

[0265] The credential issuing server 261A verifies the signatures of the server challenge and the SEID using the public key of the client key associated with the server challenge, and issues a credential including the signature-verified SEID.

[0266] The credential issuing server 261A signs the generated credential using the issuer private key of a pair of issuer private key and issuer public key stored in advance, and provides the credential to the mobile terminal 231A. The mobile terminal 231A stores the credential provided by the credential issuing server 232A.

[0267] With the above configuration, the credential issuance process can be summarized as follows:

[0268] In process St201 (FIG. 14), the secure component with signature function 253A-2 generates a public key and a private key for the client key, and supplies them to the SEID acquisition application 252A, which caches them.

[0269] In process St202, the credential storage application 251A acquires the public key of the client key cached in the SEID acquisition application 252A.

[0270] In process St203, the credential storage application 251A requests the credential issuing server 261A to issue a credential together with the public key of the client key.

[0271] In process St204, the credential issuing server 261A generates a random number in association with the client key, and issues the generated random number as a server challenge.

[0272] In process St205, the credential issuing server 261A transmits a server challenge to the credential storage application 251A of the mobile terminal 231A.

[0273] In process St206, the credential storage application 251A provides a server challenge to the SEID acquisition application 252A.

[0274] In process St207, the SEID acquisition application 252A reads the SEID from the SEID holding secure component 253A via the OS API.

[0275] In process St208, the SEID acquisition application 252A signs the server challenge and the SEID together with the private key corresponding to the client key.

[0276] In process St209, the credential storage application 251A obtains the server challenge and SEID signed with the private key corresponding to the client key.

[0277] In process St210, the credential storage application 251A provides the server challenge and SEID, which are signed with the private key corresponding to the client key, to the credential issuing server 261A.

[0278] In process St211, the credential issuing server 261A verifies the server challenge and SEID, which have been signed with the private key corresponding to the client key, using the public key corresponding to the client key, and issues a credential including the SEID.

[0279] In process St212, the credential issuing server 261A signs the generated credential using the issuer private key of the pair of issuer private key and issuer public key stored in advance, and provides the credential to the mobile terminal 231A. The credential storage application 251A stores the credential provided by the credential issuing server 232A.

[0280] Through the above process, when a credential is requested to be issued, the SEID supplied from the mobile terminal 231A to the credential issuing server 261 is signed with the private key of the client key together with the server challenge. Therefore, even if the SEID is stolen during transfer, as long as the server challenge generated by the credential issuing server 261A changes each time, a signature that can be verified with the public key of the client key stored in the credential issuing server 261A in association with the server challenge cannot be generated, and therefore a credential cannot be issued fraudulently.

[0281] <Credential Issuance Processing by the Information Processing System of FIG. 14> Next, the credential issuance processing by the information processing system 201 of FIG. 14 will be described with reference to the flowcharts of FIGS. 15 and 16. FIG.

[0282] In step S331 (FIG. 15), the credential storage application (Wallet App) 251A determines whether or not a credential issuance request has been made by the user by operating a touch panel or the like (not shown), and repeats the same process until a credential issuance request is made.

[0283] If it is determined in step S331 that a credential issuance request has been made, the process proceeds to step S332.

[0284] In step S332, the credential storage application 251A requests the SEID acquisition application (SE Manager) 252 to prepare for credential issuance.

[0285] In response to this, in step S351, the SEID acquisition application 252A controls the secure component with signature function 253A-2 to generate and acquire a pair of private and public keys for the client key.

[0286] In response to this processing, in step S371, the secure component with signature function 253A-2 generates a pair of private key and public key of the client key, and supplies the public key body of the client key and reference information to the private key of the client key (information indicating which private key to use) to the SEID acquisition application 252A, which caches them.

[0287] In step S352, the SEID acquisition application 252A generates a device challenge.

[0288] In step S353, the SEID acquisition application 252A signs the device challenge with the private key of the client key.

[0289] In step S354, the SEID acquisition application 252A supplies the device challenge, the device challenge signed with the private key of the client key, and the public key of the client key to the credential storage application 251A.

[0290] In step S333, the credential storage application 251A requests the credential issuing server 261A to prepare for issuing a credential along with the device challenge, the device challenge signed with the private key of the client key, and the public key of the client key.

[0291] In step S391, the credential issuing server 261A verifies the signature of the device challenge signed with the private key of the client key using the public key of the client key.

[0292] In step S392, the credential issuing server 261A stores the public key of the client key used for signature verification.

[0293] In step S393, the credential issuing server 261A generates a server key pair consisting of a server public key and a server private key, and a server challenge consisting of a random number generated based on the client key. Furthermore, the credential issuing server 261A signs the generated server challenge and client challenge with the server private key.

[0294] In step S394, the credential issuing server 261A supplies the server challenge signed with the server private key and the client challenge to the credential storage application 251A of the mobile terminal 231A.

[0295] In step S334, the credential storage application 251A verifies the signatures of the server challenge and the client challenge using the server public key, and provides the server challenge to the SEID acquisition application 252A.

[0296] In step S335 (FIG. 16), the credential storage application 251A requests the SEID from the SEID acquisition application 252A.

[0297] In response to this, in step S355, the SEID acquisition application 252 requests the SEID from the SEID holding secure component 253A-1.

[0298] Then, in step S372, the SEID held in the SEID holding secure component 253A-1 is read by the SEID acquisition application 252A, and the read SEID is cached.

[0299] In step S356, the SEID acquisition application 252A signs the SEID and the server challenge with the private key of the client key.

[0300] In step S357, the SEID and the server challenge signed with the private key of the client key are read by the credential storage application 251A.

[0301] In step S336, the credential storage application 251A supplies the SEID signed with the private key of the client key and the server challenge to the credential issuing server 261.

[0302] In step S395, the credential issuing server 261A obtains the SEID signed with the private key of the client key and the server challenge.

[0303] In step S396, the credential issuing server 261A verifies the signature of the SEID and the server challenge, which have been signed with the private key of the client key, using the public key of the client key.

[0304] In step S397, the credential issuance server 261A notifies the credential storage application 251A of the mobile terminal 231A of the signature verification result. That is, if there is no problem with the signature verification, it is notified that the credential issuance preparation is complete.

[0305] In step S337, the credential storage application 251A requests the issuance of a credential based on the verification result.

[0306] In step S398, the credential issuing server 261A issues a credential including the SEID, signs it with the issuer's private key, and supplies it to the credential storage application 251A.

[0307] In step S338, the credential storage application 251A acquires and stores the credential.

[0308] Through the above process, when requesting the issuance of a credential including an SEID, the SEID supplied from the mobile terminal 231A to the credential issuing server 261A, along with the server challenge, is signed with the private key of the client key. Therefore, even if the SEID is stolen during transfer, it cannot be used unless the signature can be verified using the public key of the client key.

[0309] As a result, it becomes possible to manage SEIDs securely, and more secure bindings can be realized.

[0310] <<6. Third Embodiment>> In the above, an example has been described in which, as a countermeasure against replay attacks, when a request is made for the issuance of a credential including an SEID, the SEID supplied from the mobile terminal 231A to the credential issuing server 261A is signed with the private key of the client key together with the server challenge.

[0311] However, instead of sending the SEID to the credential issuing server, the SEID may be replaced with a token and supplied, and the credential issuing server may acquire the SEID from an SEID acquisition server that has separately acquired the SEID in association with the token.

[0312] FIG. 17 shows an information processing system in which an SEID is replaced with a token and supplied to a credential issuing server, and the credential issuing server acquires the SEID from an SEID acquisition server that acquires the SEID in association with the token.

[0313] The information processing system 201B of Figure 17 is composed of a mobile terminal 231B, a credential issuing server 261B managed and operated by a credential issuer 232B, and an SEID acquisition server 341B that pre-encrypts the SEID of the mobile terminal 231B and acquires it in association with a token, and when the token is supplied from the credential issuing server 261B, supplies the SEID registered in association with the token.

[0314] The mobile terminal 231B includes a credential storage application 251B, an SEID acquisition application 252B, and an SEID holding secure component 253B.

[0315] The credential storage application 251B supplies a credential issuance request to the credential issuing server 261B, and then acquires the session ID and server public key certificate supplied by the credential issuing server 261B.

[0316] The credential storage application 251B supplies the session ID and server public key certificate provided by the credential issuing server 261B to the SEID acquisition application 252B, which then registers the SEID in the SEID acquisition server 341B and obtains a token to be exchanged in association with the SEID acquisition application 252B.

[0317] The credential storage application 251B supplies the acquired token to the credential issuing server 261B, and acquires and stores the issued credential in response.

[0318] When the SEID acquisition application 252B acquires the session ID and server public key certificate supplied from the credential storage application 251B, it supplies them together with an SEID acquisition request to the SEID acquisition server 341B. In response, the SEID acquisition application 252B receives an E2EE (End to End Encryption) session start request from the SEID acquisition server 341B, supplies it to the SEID holding secure component 253B for storage, and also supplies an E2EE session OK notification to the SEID acquisition server 341B.

[0319] Furthermore, when the SEID acquisition application 252B acquires an SEID acquisition command encrypted with the private key of the session key, it supplies it to the SEID holding secure component 253B, which decrypts it with the public key of the session key, and encrypts the SEID with the common key of the session key in accordance with the SEID acquisition command, and supplies it to the SEID acquisition server 341B.

[0320] Then, when the encrypted SEID is acquired and stored in the SEID acquisition server 341B, the SEID acquisition application 252B acquires the associated registered token and supplies it to the credential storage application 251B.

[0321] When the SEID acquisition server 341B receives an SEID acquisition request together with the session ID and server public key certificate from the SEID acquisition application 252B of the mobile terminal 231B, it supplies an E2EE session start request to the SEID holding secure component 253 via the SEID acquisition application 252B.

[0322] When the SEID acquisition server 341B acquires the E2EE start OK signal supplied in response to the E2EE session start request, it encrypts the SEID acquisition command with the session key and supplies it to the SEID holding secure component 253 .

[0323] Furthermore, based on the SEID acquisition command, the SEID acquisition server 341B acquires the SEID encrypted with the common key of the session key supplied from the SEID holding secure component 253 via the SEID acquisition application 252B, and decrypts it with the common key of the session key.

[0324] Then, the SEID acquisition server 341B issues a token including the session ID and registers it in association with the SEID and the server public key certificate.

[0325] Thereafter, when the SEID acquisition server 341B receives a token encrypted with the server private key from the credential issuing server 261B, it verifies the signature using the server public key certificate registered in association with the token and exchanges it for the corresponding SEID.

[0326] When the credential issuance server 261B receives a credential issuance request from the credential storage application 251B of the mobile terminal 231B, it issues a session ID and supplies the server public key certificate, which is one of the server public key certificate and server private key pairs that it has stored in advance, to the credential storage application 251B along with the session ID.

[0327] When the credential issuing server 261B receives the token supplied from the credential storage application 251B, it encrypts it with the server private key, presents it to the SEID acquisition server 341B, and acquires the corresponding SEID in exchange for the token.

[0328] When the credential issuing server 261B acquires the SEID, it generates a credential including the SEID acquired from the SEID acquisition server, signs the generated credential using the issuer private key of the issuer public key and issuer private key pair that it has previously stored, and supplies the credential to the credential storage application 251B of the mobile terminal 231B.

[0329] Based on the above configuration, the operation of the information processing system 201B in FIG. 17 is outlined below.

[0330] That is, in process St231 (FIG. 17), the credential storage application 251B supplies a credential issuance request to the credential issuing server 261B.

[0331] In process St232, the credential issuing server 261B issues a session ID.

[0332] In process St233, the credential issuing server 261B supplies the server public key certificate, of the server public key certificate and server private key stored in advance, to the credential storage application 251B together with the issued session ID.

[0333] In process St234, the credential storage application 251B acquires the session ID and server public key certificate provided by the credential issuing server 261B, and provides the session ID and server public key certificate to the SEID acquisition application 252B.

[0334] In process St235, the SEID acquisition application 252B provides the session ID and the server public key certificate to the SEID acquisition server 341B.

[0335] In process St236, the SEID acquisition server 341B supplies an E2EE session start request to the SEID holding secure component 253 via the SEID acquisition application 252B.

[0336] In process St237, the SEID holding secure component 253B supplies a notification of the E2EE session OK to the SEID acquisition server 341B.

[0337] In process St238, the SEID acquisition server 340B encrypts an SEID acquisition command with the session key in response to the E2EE start OK supplied in response to the E2EE session start request, and supplies the command to the SEID holding secure component 253B.

[0338] In process St239, the SEID holding secure component 253B decrypts the SEID acquisition command encrypted with the common key of the session key supplied from the SEID acquisition server 341B using the common key of the session key, and then encrypts the SEID with the public key of the session key based on the SEID acquisition command and supplies it to the SEID acquisition server 341B.

[0339] In process St240, the SEID acquisition server 341B acquires the SEID encrypted with the session key and decrypts it with the session key.

[0340] In process St241, the SEID acquisition server 341B issues a token including a session ID, and stores the SEID and the server public key certificate in association with each other.

[0341] In process St242, the SEID acquisition server 340B supplies the token to the SEID acquisition application 252B of the mobile terminal 231B.

[0342] In process St243, the SEID acquisition application 252B supplies the acquired token to the credential storage application 251B, which then stores the token.

[0343] In process St244, the credential storage application 251B provides the token to the credential issuing server 261B.

[0344] In process St245, when the credential issuing server 261B receives the token supplied from the credential storage application 251B, it signs it with the server private key.

[0345] In process St246, the credential issuing server 261B presents the token signed with the server private key to the SEID acquisition server 341B.

[0346] In process St247, the SEID acquisition server 341B verifies the token presented by the credential issuing server 261B using the server public key certificate, and provides the corresponding SEID in exchange for the token.

[0347] In process St248, when the credential issuing server 261B acquires the SEID, it generates a credential including the acquired SEID and signs it with the issuer private key of the issuer public key and issuer private key pair that it has previously stored.

[0348] Then, in process St249, the credential issuing server 261B supplies the signed credential to the credential storage application 251B of the mobile terminal 231B.

[0349] Through the above series of processes, first, the mobile terminal 231B encrypts the SEID required for credential issuance with a session key, registers it with the SEID acquisition server 341B, and acquires a corresponding token. Then, the mobile terminal 231B requests the issuance of a credential and provides the token to the credential issuance server 261B. The credential issuance server 261B presents the token to the SEID acquisition server 341B to obtain an SEID in exchange, issues a credential, and provides it to the mobile terminal 231B.

[0350] As a result, there is no exchange of SEID between the mobile terminal 231B and the credential issuing server 261B, making it possible to prevent replay attacks.

[0351] <Credential Issuance Processing by the Information Processing System of FIG. 17> Next, the credential issuance processing by the information processing system 201B of FIG. 17 will be described with reference to the flowchart of FIG.

[0352] In step S431, the credential storage application (Wallet App) 251B determines whether or not a credential issuance request has been made by the user by operating a touch panel or the like (not shown), and repeats the same process until an issuance request is made.

[0353] If it is determined in step S431 that a credential issuance request has been made, the process proceeds to step S432.

[0354] In step S432, the credential storage application 251B requests the credential issuing server 261B to prepare for issuing a credential.

[0355] In step S481, the credential issuing server 261B generates a session ID and requests the credential storage application 251B of the mobile terminal 231B to submit an SEID along with the generated session ID and the server public key certificate from among the server private key and server public key certificate that have been previously stored.

[0356] In step S433, the credential storage application 251B requests the SEID acquisition application 252B to acquire the SEID along with the session ID and the server public key certificate.

[0357] In step S451, the SEID acquisition application 252B requests the SEID acquisition server 341B to acquire an SEID along with the session ID and server public key certificate.

[0358] In step S491, the SEID acquisition server 341B requests the SEID acquisition application 252B to establish an E2EE session.

[0359] In step S452, the SEID acquisition application 252B requests the SEID holding secure component 253 to establish an E2EE session.

[0360] In step S471, the SEID holding secure component 253 notifies the SEID acquisition application 252 that the E2EE session has been successfully established.

[0361] In step S453, the SEID acquisition application 252 notifies the SEID acquisition server 341B of the establishment of an E2EE session.

[0362] In step S 492 , the SEID acquisition server 341 B encrypts a command requesting an SEID with the session key and sends the command to the SEID acquisition application 252 .

[0363] In step S454 , the SEID acquisition application 252 acquires a command requesting the SEID encrypted with the session key, and supplies the command to the SEID holding secure component 253 .

[0364] In step S472, the SEID holding secure component 253 decrypts the encrypted command requesting the SEID with the session key.

[0365] In step S 473 , the SEID holding secure component 253 reads the SEID based on the command requesting the SEID, encrypts it with the session key, and supplies it to the SEID acquisition application 252 .

[0366] In step S455, the SEID acquisition application 252 supplies the SEID encrypted with the session key to the SEID acquisition server 341B.

[0367] In step S493, when the SEID acquisition server 341B acquires the SEID encrypted with the session key, it decrypts it with the session key to acquire the SEID, and issues a token including the session ID and signs it with the server public key.

[0368] In step S494, the SEID acquisition server 341B associates and registers the token, the server public key certificate, and the SEID.

[0369] In step S495, the SEID acquisition server 341B supplies the token to the SEID acquisition application 252.

[0370] In step S456, the SEID acquisition application 252 supplies the token to the credential storage application 251B.

[0371] In step S434, the credential storage application 251B submits the token to the credential issuing server 261B.

[0372] In step S482, the credential issuing server 261B checks the session ID in the token.

[0373] In step S483, the credential issuing server 261B encrypts the token with the server private key and supplies it to the SEID acquisition server 341B, while requesting an SEID.

[0374] In step S496, the SEID acquisition server 341B verifies the signature of the token from the credential issuing server 261B using the server public key certificate.

[0375] In step S497, the SEID acquisition server 341B reads out the SEID registered in association with the token, and supplies it to the credential issuing server 261B.

[0376] In step S484, the credential issuing server 261B notifies the credential storage application 251 of the mobile terminal 231B that preparations for issuing a credential including an SEID have been completed.

[0377] In step S435, the credential storage application 251B requests the credential issuing server 261B to issue a credential.

[0378] In step S485, the credential issuance server 261B issues a credential including an SEID based on the credential issuance request, signs the credential with the issuer private key of the issuer public key / issuer private key pair that it has previously stored, and supplies the credential to the credential storage application 251 of the mobile terminal 231B.

[0379] In step S436, the credential storage application 251B acquires and stores the credential signed with the issuer private key supplied from the credential issuing server 261B.

[0380] When requesting the issuance of a credential including an SEID through the above series of processes, the SEID is not supplied from the mobile terminal 231A to the credential issuing server 261A, making it possible to prevent replay attacks and suppress duplication.

[0381] Furthermore, because the SEID is registered to the SEID acquisition server 341B from the mobile terminal 231B via a highly confidential E2EE session, the risk of theft or leakage can be reduced. When the SEID is registered to the SEID acquisition server 341B, a corresponding token is provided, and this token can be used instead of the SEID when requesting the issuance of a credential, enabling the SEID to be managed safely.

[0382] Furthermore, the credential issuing server 261B encrypts the token with the server private key and presents it to the SEID acquisition server 341B, and the SEID is supplied based on signature verification using the server public key certificate, making it possible to safely supply the SEID to the credential issuing server 261B.

[0383] As a result, it becomes possible to manage SEIDs securely, and more secure bindings can be realized.

[0384] <<7. Fourth Embodiment>> In the above, a method for issuing credentials using a token has been described, but an applet may be provided in the SEID-holding secure component, and the SEID may be supplied from the applet to the credential issuing server.

[0385] FIG. 19 shows an example of the configuration of an information processing system in which an applet is provided in an SEID-holding secure component, and the SEID is supplied from the applet to a credential issuing server.

[0386] The information processing system 201C in FIG. 19 is composed of a mobile terminal 231C and a credential issuing server 261C managed and operated by a credential issuer 232C.

[0387] The mobile terminal 231C is composed of a credential storage application 251C, an SEID acquisition application 252C, and an SEID holding secure component 253C. The credential storage application 251C, the SEID acquisition application 252C, and the SEID holding secure component 253C have basic functions similar to those of the credential storage application 251A, the SEID acquisition application 252A, and the SEID holding secure component 253A in FIG. 3 .

[0388] However, the SEID-holding secure component 253C is provided with an applet 253Ca.

[0389] Applet 253Ca is pre-installed with a client public key certificate signed by the SE Root private key and a private key for the client key. "Pre-installed" refers to being configured at the SE vendor's factory, the chip vendor's factory, or the OS vendor's factory before shipping to the market. Furthermore, if a private key is configured before shipping to the market, a chained client public key certificate can be created for a key pair generated within the chip after shipping to the market. Therefore, the present disclosure does not limit the scope to pre-installed keys; additional keys configured during operation in the market can be used without any impact on the configuration. This client public key, public key certificate, and its paired private key may be stored within a specific applet or in an area commonly accessible to SEs as a Controlling Authority Security Domain (CASD) defined by the industry organization GlobalPlatform. Separating the management of the private key from the part requesting signing of the SEID allows an applet that only requests signing of the SEID to be downloaded and installed later on the SE, making it possible to add additional functions beyond signing the SEID after release to the market. This allows for the credential to easily expand to include personal information stored in the credential by linking the information in the credential and verifying information other than the SEID. In other words, even while operating based on a TEE that manages information that is difficult to trust, using information stored on the SE side allows the two secure components to work together, enabling the issuance of reliable credentials. When the credential issuing server 261C requests an SEID, the applet 253Ca signs the SEID with the private key of the client key.

[0390] The credential storage application 251C reads the SEID signed with the client private key and the client public key certificate from the applet 253Ca of the SEID holding secure component 253C via the SEID acquisition application 252C.

[0391] The credential storage application 251C supplies the SEID signed with the read client private key and the client public key certificate to the credential issuing server 261C.

[0392] Then, the credential storage application 251C acquires and stores the SEID signed with the supplied client private key and the credential issued based on the client public key certificate.

[0393] The credential issuing server 261C has the SE Root private key and the corresponding SE Root public key installed in advance. If the credential issuing server does not hold the SE Root public key, it can obtain a Root public key certificate from the corresponding CA (Controlling Authority) using the CA ID (Controlling Authority Identificator) listed in the SE Root public key certificate. Therefore, when the credential issuing server 261C obtains the SEID and client public key certificate signed with the client private key from the credential storage application 251 of the mobile terminal 231C, it uses the SE Root public key to signature-verify the client public key certificate and also uses the verified client public key certificate to signature-verify the SEID.

[0394] The credential issuing server 261C generates a signature using the issuer's private key for the information that forms the basis of the credential, including the signature-verified SEID, generates the credential, and supplies it to the credential storage application 251C of the mobile terminal 231C.

[0395] With the above-described configuration, the process of issuing a credential in the information processing system 201C in FIG. 19 is outlined below.

[0396] In process St270, a client public key certificate certified by the SE Root private key and a client private key are pre-installed in the applet 253Ca of the SEID holding secure component 253C. Also, in St270′, the SE Root public key is pre-installed in the credential issuing server 261C.

[0397] In process St271, when the applet 253Ca receives an SEID acquisition request from the credential issuing server 261C via the credential storage application 251 and the SEID acquisition application 252, the applet 253Ca of the SEID holding secure component 253C signs the SEID with the private key of the client key.

[0398] In process St272, the credential storage application 251 reads the SEID signed with the private key of the client key and the client public key certificate signed with the SE Root private key from the applet 253Ca of the SEID holding secure component 253C.

[0399] In process St273, the credential storage application 251 supplies the SEID signed with the private key of the read client key and the client public key certificate signed with the SE Root private key to the credential issuing server 261C.

[0400] In process St274, the credential issuing server 261C obtains the SEID signed with the private key of the client key and the client public key certificate signed with the SE Root private key, verifies the client public key certificate with the SE Root public key, and verifies the signature of the SEID with the verified client public key.

[0401] In process St275, the credential issuing server 261C generates a signature using the issuer's private key for the information that forms the basis of the credential, including the signature-verified SEID, generates the credential, and supplies it to the credential storage application 251 of the mobile terminal 231C.

[0402] In process St276, the credential storage application 251 stores the credential provided by the credential issuing server 261C.

[0403] In the above processing, the SEID is signed by the applet 253Ca in the SEID-holding secure component 253C and then supplied to the credential issuing server 261C, making it possible to prevent tampering with the SEID.

[0404] <Credential Issuance Processing by the Information Processing System in Fig. 19> Next, the credential issuance processing by the information processing system in Fig. 19 will be described with reference to the flowchart in Fig. 20. As described above, it is assumed that a client public key certificate certified by the SE Root private key and a client private key are pre-installed in the applet 253Ca of the SEID-holding secure component 253C, and that the SE Root public key is pre-installed in the credential issuing server 261C.

[0405] In step S531, the credential storage application (Wallet App) 251C determines whether or not a credential issuance request has been made by the user by operating a touch panel or the like (not shown), and repeats the same process until an issuance request is made.

[0406] If it is determined in step S531 that a credential issuance request has been made, the process proceeds to step S532.

[0407] In step S532, the credential storage application 251C requests the credential issuing server 261C to prepare for issuing a credential.

[0408] In step S591, the credential issuing server 261C prepares to issue a credential.

[0409] In step S533, the credential storage application 251C requests the SEID acquisition application 252C to acquire an SEID together with a server challenge.

[0410] In step S551, the SEID acquisition application 252C requests the SEID together with a server challenge from the applet 253Ca of the SEID holding secure component 253C.

[0411] In step S571, the applet 253Ca of the SEID-holding secure component 253C signs the SEID and the server challenge with the private key of the client key.

[0412] In step S572, the applet 253Ca of the SEID holding secure component 253C supplies the client-signed SEID and the server challenge to the SEID acquisition application 252C.

[0413] In step S552, the SEID acquisition application 252 provides the client-signed SEID and the server challenge to the credential storage application 251C.

[0414] In step S534, the credential storage application 251C provides the SEID signed by the client and the server challenge to the credential issuing server 261C.

[0415] In step S592, the credential issuing server 261C obtains the SEID signed by the client and the server challenge.

[0416] In step S593, the credential issuing server 261C verifies the signature of the SEID signed by the client using the public key of the client key.

[0417] In step S594, the credential issuance server 261C notifies the credential storage application 251C of the result of the signature verification using the public key of the client key of the SEID signed by the client. In other words, if there is no problem with the verification, a notification is sent that preparation for credential issuance has been completed.

[0418] In step S535, the credential storage application 251 requests the credential issuing server 261C to issue a credential.

[0419] In step S595, the credential issuance server 261C issues a credential including an SEID based on the credential issuance request, generates a pair of an issuer public key and an issuer private key, signs the SEID with the issuer private key, and supplies it to the credential storage application 251C of the mobile terminal 231C.

[0420] In step S536, the credential storage application 251C acquires and stores the credential provided by the credential issuing server 261C.

[0421] Through the above processing, the SEID is signed by the applet 253Ca in the SEID-holding secure component 253C and then supplied to the credential issuing server 261C, making it possible to prevent tampering with the SEID.

[0422] As a result, it becomes possible to manage SEIDs securely, and more secure bindings can be realized.

[0423] In addition, in Figure 20, an example has been described in which the mobile terminal 231C is composed of a credential storage application 251C, an SEID acquisition application 252C, and an SEID holding secure component 253C. However, as in the case of the information processing system 201' in Figure 11, the SEID acquisition application 252C may be omitted, and the credential storage application 251C and the SEID holding secure component 253C may be made accessible via an OS API.

[0424] <<8. Example of Execution by Software>> The above-described series of processes can be executed by hardware, but can also be executed by software. When the series of processes is executed by software, the program constituting the software is installed from a recording medium into a computer incorporated in dedicated hardware, or into, for example, a general-purpose computer that can execute various functions by installing various programs.

[0425] 21 shows an example of the configuration of a general-purpose computer. This computer has a built-in CPU (Central Processing Unit) 1001. An input / output interface 1005 is connected to the CPU 1001 via a bus 1004. A ROM (Read Only Memory) 1002 and a RAM (Random Access Memory) 1003 are connected to the bus 1004.

[0426] The input / output interface 1005 is connected to an input unit 1006 including input devices such as a keyboard and a mouse through which a user inputs operation commands, an output unit 1007 that outputs a processing operation screen and images of processing results to a display device, a storage unit 1008 including a hard disk drive or the like that stores programs and various data, and a communication unit 1009 including a LAN (Local Area Network) adapter or the like that executes communication processing via a network typified by the Internet. Also connected is a drive 1010 that reads and writes data from / to a removable storage medium 1011 such as a magnetic disk (including a flexible disk), an optical disk (including a CD-ROM (Compact Disc-Read Only Memory) and a DVD (Digital Versatile Disc)), a magneto-optical disk (including an MD (Mini Disc)), or a semiconductor memory.

[0427] The CPU 1001 executes various processes in accordance with a program stored in a ROM 1002 or a program read from a removable storage medium 1011 such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, installed in a storage unit 1008, and loaded from the storage unit 1008 into a RAM 1003. The RAM 1003 also stores data necessary for the CPU 1001 to execute various processes as appropriate.

[0428] In a computer configured as described above, the CPU 1001 performs the above-described series of processes by, for example, loading a program stored in the memory unit 1008 into the RAM 1003 via the input / output interface 1005 and the bus 1004 and executing it.

[0429] The program executed by the computer (CPU 1001) can be provided by being recorded on a removable storage medium 1011 such as a package medium, for example. The program can also be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.

[0430] In a computer, a program can be installed in the storage unit 1008 via the input / output interface 1005 by inserting a removable storage medium 1011 into the drive 1010. The program can also be received by the communication unit 1009 via a wired or wireless transmission medium and installed in the storage unit 1008. Alternatively, the program can be installed in advance in the ROM 1002 or the storage unit 1008.

[0431] The program executed by the computer may be a program that processes in chronological order according to the order described in this specification, or may be a program that processes in parallel or at the required timing, such as when called.

[0432] 21 respectively realize the functions of the mobile terminals 231, 231', 231'', 231A to 231C, the credential issuing servers 261, 261A to 261C, and the service provider servers 271, 271'. In particular, the CPU 1001 in Figure 21 realizes the functions of the credential storage application 251, SEID acquisition application 252, credential issuance server 261, and service provider server 271 in Figures 1 and 11, the service issuance command generation server 311 in Figure 12, the credential storage application 251A, SEID acquisition application 252A, and credential issuance server 261A in Figure 14, the credential storage application 251B, SEID acquisition application 252B, credential issuance server 261B, and SEID acquisition server 341B in Figure 17, and the credential storage application 251C, SEID acquisition application 252C, applet 253Ca of the SEID holding secure component 253C, and credential issuance server 261C in Figure 19.

[0433] In this specification, a system refers to a collection of multiple components (devices, modules (components), etc.), regardless of whether all of the components are housed in the same housing. Therefore, multiple devices housed in separate housings and connected via a network, and a single device housed in a single housing with multiple modules, are both systems.

[0434] Furthermore, the embodiments of the present disclosure are not limited to the above-described embodiments, and various modifications are possible within the scope of the gist of the present disclosure.

[0435] For example, the present disclosure can be configured as a cloud computing system in which a single function is shared and processed collaboratively by multiple devices via a network.

[0436] Furthermore, each step described in the above flowchart can be executed by one device, or can be shared and executed by a plurality of devices.

[0437] Furthermore, when one step includes multiple processes, the multiple processes included in that one step can be executed by one device or can be shared and executed by multiple devices.

[0438] The present disclosure may also be configured as follows. <1> An information processing method including: an acquisition process for acquiring an SEID of a terminal device; and an issuance process for issuing a credential including the SEID. <2> The information processing method according to <1>, further including an issuer key generation process for generating an issuer private key and an issuer public key, wherein the issuance process signs the issued credential including the SEID with the issuer private key. <3> The information processing method according to <2>, further including a verification process for verifying the credential by comparing the SEID included in the credential with the SEID of the terminal device. <4> The information processing method according to <3>, wherein the verification process verifies the signature of the credential with the issuer public key, and verifies the credential by comparing the SEID included in the signature-verified credential with the SEID of the terminal device. <5> The information processing method of <1>, further including: a command supply process of encrypting a predetermined command based on an SEID included in the credential and supplying the encrypted predetermined command to the terminal device; and a verification process of verifying the credential by presenting the predetermined command decrypted based on the SEID of the terminal device. <6> The information processing method of <5>, wherein the command supply process generates an individual key by ID-based encryption using the SEID included in the credential and a master key, encrypts the predetermined command with the individual key, and supplies the encrypted predetermined command to the terminal device, and the verification process verifies the credential by presenting the predetermined command decrypted with the SEID of the terminal device. <7> The information processing method of <1>, wherein the acquisition process acquires an SEID signed with a private key of a client key of the terminal device, and the issuance process signature-verifies the SEID signed with the private key of the client key of the terminal device with a public key of the client key, and issues the credential including the signature-verified SEID.<8> The information processing method according to <7>, wherein the acquisition process acquires the SEID and a challenge consisting of a random number associated with the public key of the client key of the terminal device, signed with the private key of the client key, and the issuance process signature-verifies, with the public key of the client key, the challenge and the SEID signed with the private key of the client key of the terminal device, and issues the credential including the signature-verified SEID. <9> The information processing method according to <8>, further comprising a challenge generation process of acquiring the public key of the client key from the terminal device, generating the challenge consisting of a random number associated with the acquired public key of the client key, and supplying the challenge to the terminal device, wherein the acquisition process acquires the challenge and the SEID signed with the private key of the client key and supplied from the terminal device, and the issuance process signature-verifies, with the public key of the client key, the challenge and the SEID signed with the private key of the client key of the terminal device, and issues the credential including the signature-verified SEID. <10> The information processing method according to <1>, wherein the acquisition process acquires a token corresponding to the SEID of the terminal device, and acquires the SEID from the SEID acquisition server by presenting the token to an SEID acquisition server that acquires the SEID of the terminal device. <11> The information processing method according to <10>, further comprising a server key generation process of issuing a session ID, a server public key certificate certifying a server public key, and a server private key corresponding to the server public key, and supplying the session ID and the server public key certificate to the terminal device, wherein when acquiring the SEID from the terminal device, the SEID acquisition server also acquires the session ID, issues the token including the session ID and supplies it to the terminal device, and registers the acquired SEID of the terminal device and the server public key certificate in association with the token, and wherein the acquisition process acquires the SEID registered in association with the token from the SEID acquisition server by presenting the token to the SEID acquisition server.<12> The information processing method according to <11>, wherein the acquisition process signs the token with the server private key and presents it to the SEID acquisition server, the SEID acquisition server verifies the signature of the token signed with the server private key using the server public key certificate registered in association with the token, and when the signature of the token is verified by the SEID acquisition server, the acquisition process acquires the SEID registered in association with the token from the SEID acquisition server. <13> The information processing method according to <12>, wherein the SEID acquisition server acquires the SEID through an E2EE session with the terminal device. <14> The information processing method according to <13>, wherein the SEID acquisition server acquires the SEID, encrypted with a session key of the E2EE session with the terminal device, by decrypting it with the session key of the E2EE session. <15> The information processing method according to <14>, wherein the SEID is encrypted with the session key of the E2EE session in a secure component that stores the SEID of the terminal device. <16> The information processing method according to <1>, wherein the acquisition process includes pre-storing a Root public key corresponding to a Root private key held in a secure component of the terminal device, acquiring an SEID signed with a private key of a client key of the terminal device and a client public key certificate signed with the Root private key, signature-verifying the client public key certificate with the Root public key, and further signature-verifying the SEID signed with the private key of the client key with the client public key certificate whose signature has been verified with the Root public key, and the issuance process issues the credential including the signature-verified SEID. <17> The information processing method according to <16>, wherein the secure component in the terminal device that holds the SEID includes an applet, and the applet signs the SEID with the client key of the terminal device. <18> An information processing device including: an acquisition unit that acquires an SEID of a terminal device; and an issuance unit that issues a credential including the SEID.<19> A program that causes a computer to function as an acquisition unit that acquires an SEID of a terminal device, and an issuer that issues a credential including the SEID. <20> An information processing system including: an acquisition unit that acquires an SEID of a terminal device, and an issuer that issues a credential including the SEID.

[0439] DESCRIPTION OF SYMBOLS 201, 201', 201'', 201A to 201C Information processing system, 231, 231', 231A to 231C Mobile terminal, 232, 232', 232A to 232C Credential issuer, 233 Service provider, 251 Credential storage application, 252 SEID acquisition application, 253, 253A-1 SEID retention secure component, 253A-2 Signature function secure component, 254, 254' Client application, 261, 261A to 261C Credential issuing server, 271 Service provider server, 311 Service issuance command generation server, 341B SEID acquisition server

Claims

1. An information processing method including: an acquisition process for acquiring an SEID of a terminal device; and an issuance process for issuing a credential including the SEID.

2. The information processing method according to claim 1, further comprising an issuer key generation process for generating an issuer private key and an issuer public key, wherein the issuing process signs the issued credential including the SEID with the issuer private key.

3. The information processing method according to claim 2, further comprising a verification process for verifying the credentials by comparing the SEID included in the credentials with the SEID of the terminal device.

4. The information processing method according to claim 3, wherein the verification process verifies the signature of the credential with the issuer public key, and verifies the credential by comparing the SEID included in the signature-verified credential with the SEID of the terminal device.

5. The information processing method according to claim 1, further comprising: a command supply process for encrypting a specified command based on the SEID included in the credential and supplying the encrypted specified command to the terminal device; and a verification process for verifying the credential by presenting the specified command decrypted based on the SEID of the terminal device.

6. The information processing method according to claim 5, wherein the command supply process generates an individual key using ID-based encryption with an SEID and a master key included in the credential, encrypts the specified command with the individual key, and supplies the encrypted specified command to the terminal device, and the verification process verifies the credential by presenting the specified command decrypted with the SEID of the terminal device.

7. The information processing method according to claim 1, wherein the acquisition process acquires an SEID signed with a private key of a client key of the terminal device, and the issuance process verifies the signature of the SEID signed with the private key of the client key of the terminal device with a public key of the client key, and issues the credential including the signature-verified SEID.

8. The information processing method according to claim 7, wherein the acquisition process acquires the SEID and a challenge consisting of a random number associated with the public key of the client key of the terminal device, signed with the private key of the client key, and the issuance process verifies the challenge and the SEID signed with the private key of the client key of the terminal device using the public key of the client key, and issues the credential including the SEID whose signature has been verified.

9. The information processing method according to claim 8, further comprising a challenge generation process of acquiring a public key of the client key from the terminal device, generating the challenge consisting of a random number associated with the acquired public key of the client key, and supplying the challenge to the terminal device, wherein the acquisition process acquires the challenge and the SEID signed with the private key of the client key and supplied from the terminal device, and the issuance process signature-verifies the challenge and the SEID signed with the private key of the client key of the terminal device with the public key of the client key, and issues the credential including the signature-verified SEID.

10. The information processing method according to claim 1, wherein the acquisition process acquires a token corresponding to the SEID of the terminal device, and acquires the SEID from the SEID acquisition server by presenting the token to the SEID acquisition server that acquires the SEID of the terminal device.

11. The information processing method according to claim 10, further comprising a server key generation process for issuing a session ID, a server public key certificate certifying a server public key, and a server private key corresponding to the server public key, and supplying the session ID and the server public key certificate to the terminal device, wherein when the SEID acquisition server acquires the SEID from the terminal device, it also acquires the session ID, issues the token including the session ID and supplies it to the terminal device, and registers the acquired SEID of the terminal device and the server public key certificate in association with the token, and the acquisition process acquires the SEID registered in association with the token from the SEID acquisition server by presenting the token to the SEID acquisition server.

12. The information processing method of claim 11, wherein the acquisition process signs the token with the server private key and presents it to the SEID acquisition server, the SEID acquisition server verifies the signature of the token signed with the server private key using the server public key certificate registered in association with the token, and when the signature of the token is verified by the SEID acquisition server, the acquisition process acquires the SEID registered in association with the token from the SEID acquisition server.

13. The information processing method according to claim 12, wherein the SEID acquisition server acquires the SEID through an E2EE session with the terminal device.

14. The information processing method according to claim 13, wherein the SEID acquisition server acquires the SEID by decrypting the SEID encrypted with a session key of the E2EE session with the terminal device using the session key of the E2EE session.

15. The information processing method according to claim 14, wherein the SEID is encrypted with the session key of the E2EE session in a secure component that holds the SEID of the terminal device.

16. The information processing method according to claim 1, wherein the acquisition process includes pre-storing a root public key corresponding to a root private key stored in a secure component of the terminal device, acquiring an SEID signed with the private key of a client key of the terminal device and a client public key certificate signed with the root private key, verifying the signature of the client public key certificate with the root public key, and further verifying the signature of the SEID signed with the private key of the client key with the client public key certificate whose signature has been verified with the root public key, and the issuance process issues the credential including the signature-verified SEID.

17. The information processing method according to claim 16, wherein the secure component in the terminal device that holds the SEID comprises an applet, and the applet signs the SEID with the client key of the terminal device.

18. An information processing device comprising: an acquisition unit that acquires an SEID of a terminal device; and an issuance unit that issues a credential including the SEID.

19. A program that causes a computer to function as an acquisition unit that acquires the SEID of a terminal device and an issuance unit that issues credentials including the SEID.

20. An information processing system comprising: an acquisition unit that acquires an SEID of a terminal device; and an issuance unit that issues a credential including the SEID.

Images