Identification information management method, server, and program

Abstract

In the present invention, an issuance server (1) issues, on the basis of a request from a user device (4), a decentralized identifier (DID), a secret key associated with the DID, and a public key corresponding to the secret key. The issuance server (1) also identifies the type of the user device (4) through communication with the user device. The issuance server (1) then stores the secret key in a secure area corresponding to the type of the user device, and registers the DID and the public key in the registry of a blockchain base.

Description

Identification information management method, server, and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2023-107836 filed in Japan on June 30, 2023, and the contents of the original application are incorporated by reference in their entirety.

[0002] The present disclosure relates to a technique for verifying the validity of received data.

[0003] One method for managing digital identities is DIDs (Decentralized Identifiers), proposed by the World Wide Web Consortium. DIDs is a technology / mechanism for managing digital identities in a decentralized manner using a distributed ledger system such as a blockchain. Patent Literature 1 discloses a method for authenticating a user attempting to log in to a platform using the DIDs mechanism. A digital signature generated using a private key is used for user authentication and data verification.

[0004] Japanese Patent Application Laid-Open No. 2021-111412

[0005] In the current DIDs, there are no regulations regarding the storage location of the private key in the user device, and there is no mechanism to restrict the storage location of the private key. In addition, the security level of the medium in which the private key is stored may differ depending on the type of the user device. Here, the type may be interpreted as a specification, a function, or a setting.

[0006] For this reason, depending on the type of user device, the private key may be stored in a storage area with a low security level. A low security level increases the risk of the private key being leaked. If the private key is leaked from the user device, DIDs-based services may be used fraudulently.

[0007] The present disclosure has been made in light of the above circumstances, and one of its objectives is to provide a technology that can reduce the risk of fraudulent use of services.

[0008] The identity management method disclosed herein includes issuing, based on a request from a device, an identifier, a private key associated with the identifier, and a public key corresponding to the private key; obtaining data indicating the type of the device from the device and identifying the type of the device; specifying a secure area in which to store the private key based on the identified device type; storing the private key in the secure area; and registering the identifier and the public key in a blockchain-based registry.

[0009] According to the above method, the storage location of the private key is set to an area that is predefined as a secure area according to the device type. This reduces the risk of the private key being leaked and used fraudulently. As a result, the risk of the service being used fraudulently can be reduced.

[0010] The server included in the present disclosure is a server that manages identification information, and is configured to issue an identifier, a private key associated with the identifier, and a public key corresponding to the private key based on a request from a device used by a user, obtain data indicating the type of the device from the device, identify the type of the device, specify a secure area in which to store the private key based on the identified device type, send an instruction signal to the device to store the private key in the secure area, and register the identifier and the public key in a blockchain-based registry.

[0011] The program included in the present disclosure includes instructions to cause a computer provided in a device used by a user to receive a request for issuance of an identifier via an input device, send a request signal to a server requesting issuance of an identifier based on the reception of the request for issuance of the identifier, send data indicating the type of the device to the server, receive a private key associated with the identifier from the server, and store the private key in a memory area specified by the server.

[0012] Note that the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure.

[0013] 1 is a diagram showing the overall configuration of an ID management system; 2 is a diagram showing the configuration of a user device; 3 is a diagram showing the configuration of an issuing server; 4 is a functional block diagram of an issuing server; 5 is a functional block diagram of a service server; 6 is a flowchart showing the procedure for issuing and registering a key pair and a DID; 7 is a diagram for explaining the configuration of a DID; 8 is a diagram showing an example of a DID document; 9 is a diagram showing another example of a DID document; 10 is a flowchart showing a message verification process; 11 is a diagram for explaining an example of a service provision method using a DID;

[0014] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiments. The configurations disclosed below may be implemented with various modifications within the scope of the gist. Various modified examples may be implemented in appropriate combinations within the scope of no technical contradiction. The present disclosure also includes configurations that are not explicitly stated and are formed by combining multiple modified examples. In the following description, components having the same function may be assigned the same reference numerals, and specific descriptions thereof may be omitted. When only a portion of a configuration is mentioned, descriptions given elsewhere may apply to other parts.

[0015] <System Configuration> The ID management system 100 of the present disclosure is a system that reduces the risk of fraudulent use of identification information (i.e., ID: Identifier) ​​used to authenticate entities (i.e., users) while accommodating differences in specifications between user devices 4. The ID management system 100 may include an issuing server 1, a service server 2, multiple nodes 3, and multiple types of user devices 4.

[0016] The issuing server 1 is a server that issues user IDs. The service server 2 is a server that provides any service to the user through communication with the user device 4. The services may include coupon distribution, diagnosis of the user device 4, virtual currency transactions, administrative procedures, and taxi dispatch. The node 3 is a computer that performs mining in the blockchain. The issuing server 1, the service server 2, and the node 3 participate in the blockchain network. The issuing server 1 and the service server 2 may also be considered as one of the nodes 3 belonging to the blockchain network. Note that the node 3 is an optional element. If the blockchain accessed by the issuing server 1 is a private blockchain, the node 3 may be omitted. Hereinafter, the issuing server 1, the service server 2, and the node 3 will also be collectively referred to as the issuing server 1, etc.

[0017] The issuing server 1, etc., includes a storage device for storing blockchain data. The issuing server 1, etc., is also configured to be able to share blockchain data. The issuing server 1, etc., includes a registry 5 and a service DB 6 as storage areas realized using the blockchain. DB stands for database. The registry 5 is a storage area that records an ID for each entity (e.g., user). In this embodiment, the ID is a decentralized identifier (DID), as described below. The registry 5 corresponds to a verifiable data registry (VDR).

[0018] The service DB 6 is a storage area for storing service data. Service data in the present disclosure refers to data necessary for providing a service. For example, in a service that distributes coupons based on a user's location information, data indicating the user's location may be service data. The service DB 6 may store a smart contract that automatically executes processing based on a registered message. The registry 5 and the service DB 6 may be logical storages.

[0019] The blockchain that functions as the registry 5 and the service DB 6 may be a consortium blockchain. In other embodiments, the blockchain may be a public / private blockchain. The blockchain may be implemented using Hyperledger (registered trademark) Fabric.

[0020] In this embodiment, the registry 5 and the service DB 6 are realized on one blockchain, but the method of realizing the registry 5 and the service DB 6 is not limited to this. The blockchain for the registry 5 and the blockchain for the service DB 6 may be separate. The combination of nodes 3 forming the blockchain including the registry 5 may be different from the combination of nodes 3 forming the blockchain including the service DB 6. The ID management blockchain that functions as the registry 5 and the service blockchain that functions as the service DB 6 may have different formats and constituent members. The ID management blockchain is a consortium type, while the service blockchain may be a public or private type.

[0021] Furthermore, if multiple services exist, an independent blockchain may exist for each service. The combination of nodes 3 forming the blockchain may differ for each service. Furthermore, the registry 5 does not necessarily have to be formed on the blockchain. In other words, the place where the DID is stored does not have to be the blockchain. The place where the DID is stored may be a specific database.

[0022] <Configuration of User Device> Here, the user device 4 will be described. The user device 4 may be a smartphone 4A, a vehicle 4B, a server 4C, or the like. The vehicle 4B may be interpreted as an electronic control unit (ECU) or a computer installed in the vehicle. The server 4C may be an on-premise server or a cloud server. Alternatively, the user device 4 may be a laptop, a desktop PC, a tablet, or the like.

[0023] The multiple user devices 4 may include devices of different types. Here, the term "type" may refer to specifications, functions, or settings. For example, the multiple user devices 4 may have different operating systems (OS). Furthermore, the multiple user devices 4 may have different local storage mechanisms.

[0024] Each user device 4 is configured to be able to communicate with the issuing server 1 and the service server 2 via the Internet. The user device 4 can send and receive data to and from the issuing server 1 based on user operation or automatically according to a program. Client software 40 is installed on each user device 4, and performs processing on the user device 4 related to the issuance of a DID. The client software 40 communicates data with the issuing server 1. The client software 40 may be software that pairs with a server program installed on the issuing server 1.

[0025] As shown in FIG. 2, the user device 4 includes a display 41, an operation unit 42, a communication module 43, a processor 44, a memory 45, a normal storage 46, and a secure storage 47.

[0026] The display 41 is a device that displays an image in response to an input signal from the processor 44. The operation unit 42 is a device for receiving user instructions for the user device 4. The operation unit 42 may be a hardware switch or a touch panel stacked on the display 41. The operation unit 42 outputs a signal corresponding to a user operation to the processor 44. The communication module 43 is a circuit module for connecting to the Internet and communicating with the issuing server 1. The communication module 43 may be a wireless communication module for cellular communication such as 4G or 5G.

[0027] The processor 44 is configured to execute various types of arithmetic processing and may be a central processing unit (CPU) or a graphics processing unit (GPU), etc. The memory 45 may be a random access memory (RAM).

[0028] The normal storage 46 and the secure storage 47 are realized using rewritable non-volatile storage media. The normal storage 46 is a storage area accessible by various applications. The normal storage 46 may be an area where data is stored without encryption. The normal storage 46 corresponds to a normal area. Note that the resources of the user device 4 may be divided into a normal world and a secure world using technology such as Trusted Execution Environment (TEE). When the resources of the user device 4 are divided into a normal world and a secure world, the normal storage 46 may be considered, from one perspective, as storage within the normal world.

[0029] The secure storage 47 is an area that is separated from the normal storage 46 and has a certain level of confidentiality and integrity. The secure storage 47 may be a storage area that is physically separated from the normal storage 46. The secure storage 47 may be a storage area that is accessible only to a specific kernel / application. In another embodiment, the secure storage 47 may be a storage area that is virtually separated from the normal storage 46. In one aspect, the secure storage 47 may be understood as storage in a secure world that is isolated from the normal world.

[0030] The secure storage 47 may be an area to which a predetermined data storage method is applied. The predetermined data storage method is preferably a storage method that has been confirmed by the designer of the issuing server 1 or a third party organization to have the desired confidentiality. The secure storage 47 may be a storage that incorporates a mechanism for automatically encrypting and storing data.

[0031] The actual storage area corresponding to the secure storage 47 may vary depending on the type of user device 4. For an Android (registered trademark) smartphone, the secure storage 47 may be a storage area protected by a TEE or Secure Element provided by the Android KeyStore. The TEE may be an environment implemented by Intel (registered trademark) SGX or Arm TrustZone (registered trademark). For a user device 4 running iOS (registered trademark), such as an iPhone (registered trademark), the secure storage 47 may be a storage area protected by a Secure Enclave. For a user device 4 running Linux (registered trademark), the secure storage 47 may be a storage area protected by a Secure Enclave. The secure storage 47 may be cloud storage protected by AWS (registered trademark) CloudHSM, Azure (registered trademark) Key Vault, or the like. Alternatively, the secure storage 47 may be trusted storage.

[0032] Additionally, a USB memory type hardware wallet or the like may also be included in the secure storage 47. The secure storage 47 may be configured to be removable from the user device 4. The secure storage 47 corresponds to a secure area. A storage area that the issuing server 1 regards as a secure area (secure storage 47) may be defined in advance in the issuing server 1. The issuing server 1 may have data (e.g., a list / table) in which secure areas of each type are defined.

[0033] The normal storage 46 or the secure storage 47 stores a device-oriented program, which is a program executed by the processor 44. The device-oriented program includes client software 40. By executing the client software 40, the processor 11 can function as the user device 4 described below. For example, the user device 4 accepts a user operation for issuing a DID via the operation unit 42. In response to the user operation, the user device 4 also transmits a signal to the issuing server 1 requesting the issuance of a DID.

[0034] <Configuration of Issuing Server> The issuing server 1 is a server that performs processes related to issuing a DID and generating a key pair linked to the DID. A key pair is a pair of a private key and a public key. Details of the DID will be described separately later. As shown in FIG. 3 , the issuing server 1 includes a processor 11, a communication interface 12, a memory 13, and a storage 14.

[0035] The processor 11 is configured to perform arithmetic processing based on data received from other devices. The processor 11 may be a CPU or a GPU. The communication interface 12 is a circuit module that enables the processor 11 to communicate with other devices. The communication interface 12 may include a circuit for connecting to the Internet.

[0036] The memory 13 is a rewritable volatile storage medium. The memory 13 may be a RAM. The memory 13 may be a component for temporarily storing data received from other devices, calculation results by the processor 11, programs, etc. The storage 14 is a rewritable nonvolatile memory. The storage 14 is realized by at least one type of non-transitory tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 14 may include multiple types of storage media, such as a read-only memory (ROM) and a flash memory. The storage 14 stores a server program, which is a program executed by the processor 11. The server program may be a program for implementing at least some of the functions of the issuing server 1, which is shown as a block in FIG. 4 .

[0037] The server program and the client software 40 may be developed and implemented using a software development kit (SDK) that is applicable to various types of user devices 4. Execution of the server program and the client software 40 corresponds to execution of an identity management method.

[0038] As shown in Fig. 4, the issuing server 1 includes functional blocks: an issuing unit F1, a registry registration unit F2, a type identification unit F3, and a device registration unit F4. Each functional block may be realized by the processor 11 executing a server program. The issuing unit F1, registry registration unit F2, type identification unit F3, and device registration unit F4 are functional blocks related to the registration of key pairs and DIDs. The operation of each functional block will be described later with reference to Fig. 6.

[0039] <Configuration of Service Server> The service server 2 is a computer including a processor, a communication interface, a memory, and a storage, similar to the issuing server 1. The storage stores a program executed by the processor to provide the service.

[0040] As shown in FIG. 5, the service server 2 includes functional blocks: a message receiving unit G1, a verification unit G2, and a data registration unit G3. Each functional block may be realized by a processor executing a predetermined program. The message receiving unit G1, the verification unit G2, and the data registration unit G3 are functional blocks for adding a message sent from the user device 4 using an issued DID to the blockchain. The message here may also be referred to as a request, transaction, or service data. The operation of each functional block will be described later using FIG. 9.

[0041] <Issuance of Key Pair and DID> Here, the operation of the issuing server 1 related to the issuance of a key pair and a DID will be described with reference to Figure 6. The flowchart shown in Figure 6 may start when the issuing server 1 receives a DID issuance request from the user device 4. The term "client software 40" below may be replaced with the user device 4 or the processor 44. Furthermore, the terms "issuing unit F1," "registry registration unit F2," "type identification unit F3," and "device registration unit F4" below may be replaced with the issuing server 1 or the processor 11. Hereinafter, the user device 4 that sent the DID issuance request or the owner of the user device 4 will also be referred to as the "requester."

[0042] In step S101, the issuing unit F1 generates a key pair of a public key and a private key for the requester. The key pair may be generated by any method, such as RSA. When step S101 is completed, the process proceeds to step S102.

[0043] In step S102, the issuing unit F1 generates a code to be used as a DID based on the public key generated in step S101. A DID is an identifier having a format defined by the World Wide Web Consortium (W3C). As shown in FIG. 7, a DID includes a scheme, a DID method, and a method-specific identifier. Each element is separated by a colon. The scheme is a prefix indicating that a DID method, etc., follows. The DID method is a code that specifies the type of mechanism for operating the DID, in other words, how to interpret the identifier. The DID method information can be used by the service server 2 to identify how to obtain a document (a so-called DID document) that indicates information associated with the DID. The DID method may be any method. A unique value is assigned to the method-specific identifier within the method. The combination of the method-specific identifier and the DID method uniquely defines an entity (DID subject). The method-specific identifier may be generated differently for each DID method. The method for generating the method-specific identifier may be any generation method. The issuing unit F1 may be configured to issue a DID using any DID method. When step S102 is completed, the process proceeds to step S103.

[0044] Note that the generation of the key pair and the issuance of the DID may be performed by separate devices. The functions of the issuing unit F1 may be divided into multiple parts. Also, some or all of the functions of the issuing unit F1 may be provided in another server. Furthermore, some or all of the functions of the issuing unit F1 may be provided in the client software 40. If the key generation function is provided outside the issuing server 1, step S101 may be a step of obtaining the key pair. If the DID issuance function is provided outside the issuing server 1, step S102 may be a step of obtaining the issued DID.

[0045] The issuing unit F1 may also include an API (Application Programming Interface) for accepting DID issuance requests from various types of user devices 4. The issuing unit F1 may include multiple reception APIs corresponding to multiple device types, respectively, which allows the issuing unit F1 to accommodate differences in the types of request sources.

[0046] In step S103, the registry registration unit F2 performs the preparation process required for registering the DID and stores the DID and DID document in the registry 5. The preparation process may include generating JSON format data representing the DID document. The preparation process may also include sending the DID document to the client software 40 for user confirmation, and signing the DID document using the private key generated in step S101.

[0047] 8, the DID document may include a DID subject 61, a DID controller 62, a public key 63, a public key type 64, and a last update date 65. The DID subject 61 indicates the owner of the DID (i.e., the user). The DID subject 61 stores the DID itself. The DID controller 62 represents an entity authorized to make changes to the DID document. The DID controller 62 may be represented by the DID of the entity authorized to make changes. The public key 63 is the public key generated in step S101. The public key type 64 represents the type of the public key.

[0048] The DID document shown in Figure 8 is an example. A DID document may include data on the type, owner, and services available to the user. Data on available services may be described separately from the main body using a specified property such as "Service." In addition, DID documents related to the use of services may be created separately for each service. Figure 9 is an example of a document for a service. Multiple DID documents may be created for one DID. DID documents may be created for each purpose / use and stored in a distributed manner. The items included in a DID document may be described separated by properties according to the purpose / content.

[0049] The DID document may be stored in the registry 5 in an encrypted format so that it can be restored using a predetermined function called a resolver. The resolver may differ depending on the DID method. In this disclosure, obtaining information contained in a DID document linked to a DID using a resolver is also referred to as DID resolving. Obtaining a public key linked to a DID may also be included in one form of DID resolution.

[0050] When step S103 is completed, the process proceeds to step S104. In step S104, the type identification unit F3 acquires device type data from the client software 40. The device type data is data indicating the type of the user device 4. The device type data may be data indicating the OS or model of the user device 4. The device type data may also be data indicating the type, specifications, or location of the secure storage 47 held by the user device 4. The device type data may also be data indicating a combination of storage accessible by the user device 4. The type identification unit F3 may acquire the device type data by requesting the client software 40 to transmit the device type. In another embodiment, the device type data may be included in a request to issue a DID. When step S104 is completed, the process proceeds to step S105.

[0051] In step S105, the device registration unit F4 determines a storage destination for the private key according to the type of the user device 4. The storage destination for the private key is selected from various secure storages 47. For example, if the requesting user device 4 is an Android-based smartphone, the device registration unit F4 designates an area used by the TEE as the storage destination for the private key. Furthermore, if the requesting user device 4 is a device running iOS, the device registration unit F4 designates an area protected by the Secure Enclave as the storage destination for the private key. Note that if the requesting user device 4 does not have a secure storage 47, the device registration unit F4 may designate a specified external storage as the storage destination. The specified external storage may be a secure storage 47 on the cloud or a hardware wallet. The device registration unit F4 may designate multiple types of secure areas as the storage destination for the private key. After step S105 is completed, the process proceeds to step S106.

[0052] In step S106, the device registration unit F4 transmits a data set including the private key storage destination, the private key, and the DID to the client software 40. This information may be transmitted in multiple messages. If the client software 40 has functions related to key generation and DID issuance, the data transmitted by the device registration unit F4 may be a message specifying the private key storage destination. Transmission of data already acquired by the client software 40 may be omitted. In response to step S106, the client software 40 executes step S107.

[0053] Step S107 is a step in which the client software 40 stores the private key in the secure storage 47 based on an instruction from the device registration unit F4. The process of storing the private key in the secure storage 47 may be performed in cooperation with the software / hardware that forms the secure storage 47. The DID and public key may be stored in the normal storage 46 or the secure storage 47. The client software 40 may also obtain information other than the public key contained in the DID document from the issuing server 1 and store it in any storage. The client software 40 may be configured to store the DID document in the normal storage 46 or the secure storage 47.

[0054] If the user device 4 does not have the storage destination for the private key specified by the issuing server 1, the client software 40 may display on the display 41 a message urging the user to obtain the specified secure storage 47. If a hardware wallet is specified as the storage destination for the private key and the hardware wallet is not connected, the client software 40 may display a guide image requesting the user to connect the hardware wallet to the user device 4.

[0055] In this way, the issuing server 1 controls the operation of the user device 4 so that the private key is stored in an area with a certain level of security in the user device 4. This reduces the risk of the private key being leaked.

[0056] <Service Data / Message Registration Process> Here, the operation of the user device 4 and the service server 2 related to message transmission and reception will be described using the flowchart shown in FIG. 10. The flowchart shown in FIG. 10 may be started in response to the occurrence of a trigger in the user device 4 to transmit a message (in other words, data) to the service server 2. The transmission trigger may be designed as appropriate. The user device 4 may be programmed to periodically transmit messages. The message transmission conditions may be designed as appropriate depending on the content of the service. The descriptions of the message receiving unit G1, verification unit G2, and data registration unit G3 below may be replaced with the service server 2 or its processor.

[0057] First, the user device 4 generates a message in step S201. The message includes data about an item to be registered in the service DB 6. In other words, the message has a payload according to the service provided by the service server 2. The message may be generated by a predetermined application rather than the client software 40. Of course, the message may also be generated by the client software 40. The following processing of the user device 4 may also be performed by the client software 40 or another application. After step S201 is completed, the processing proceeds to step S202.

[0058] In step S202, the user device 4 converts the message generated in step S201 using a predetermined hash function to generate a hash value. The hash value is data used to create a digital signature. The hash value generated in step S202 may be referred to as a digest value of the message.

[0059] The hash function used to create the digital signature may be SHA-256. Of course, the hash function may also be SHA-1, SHA512, MD-5, RIPEMD-160, etc. SHA stands for Secure Hash Algorithm. MD stands for Message Digest algorithm. RIPEMD stands for Race Integrity Primitive Evaluation Integrity Primitives Evaluation Message Digest. When step S202 is completed, the process proceeds to step S203.

[0060] In step S203, the user device 4 encrypts the hash value generated in step S202 using a private key. The encryption method may be RSA or the like. The encrypted hash value corresponds to the digital signature of the message.

[0061] In step S204, the user device 4 transmits a data set including the message generated in step S201, the digital signature generated in step S203, and the DID to the service server 2. When step S204 is completed, the process proceeds to step S205. In this disclosure, the data set in which the digital signature and the DID are added to the message body is also referred to as a message set.

[0062] Step S205 is a step in which the message receiving unit G1 receives a message set transmitted from the user device 4. The message receiving unit G1 may include an API for receiving message sets transmitted from various types of user devices 4. When the message receiving unit G1 receives the message set, the process proceeds to step S206.

[0063] In step S206, the verification unit G2 obtains a public key from the registry 5 using the DID included in the received message set as a key. The public key associated with the DID may be obtained by DID resolution. When step S206 is completed, the process proceeds to step S207.

[0064] In step S207, the verification unit G2 decrypts the digital signature included in the message set using the public key acquired in step S206 to restore the hash value of the message. After step S207 is completed, the process proceeds to step S208. Of course, the order of the processes may be changed as needed.

[0065] In step S208, the verification unit G2 generates a hash value by converting the message body included in the message set using a common hash function. The common hash function is a hash function used by the user device 4 to create an electronic signature. The hash value generated in step S208 is an element for comparison with the hash function generated in step S207. In this disclosure, the hash value generated in step S208 is also referred to as a comparison hash value. When step S208 is completed, the process proceeds to step S209.

[0066] Step S209 is a step in which the verification unit G2 determines the authenticity of the message by comparing the hash value generated in step S207 with the hash value generated in step S208. If the two hash values ​​match, the verification unit G2 determines that the message is valid. If the two hash values ​​do not match, the verification unit G2 determines that the message is fraudulent. If the verification unit G2 determines that the message is fraudulent, in other words, if the two hash values ​​do not match, the verification unit G2 discards the received message. If the two hash values ​​do not match, the verification unit G2 may return an error message to the sender. On the other hand, if the verification unit G2 determines that the message is valid, in other words, if the two hash values ​​match, it sends the received message to the data registration unit G3.

[0067] When the data registration unit G3 receives a message from the verification unit G2, it executes a process to register the message in the blockchain (step S210). For example, the data registration unit G3 temporarily stores the message in a transaction pool. When a predetermined number of messages have accumulated in the transaction pool, the data registration unit G3 generates a block and adds it to the blockchain. The consensus algorithm for adding the block may be any algorithm, such as PoW (Proof of Work) or PoC (Proof of Consensus).

[0068] The user device 4 may transmit the message set not only to the service server 2 but also to all other nodes forming the blockchain. Multiple nodes 3 may execute the processes of steps S205 to S210. Additionally, the data registration unit G3 may be configured to transmit the message whose validity has been confirmed to all other nodes forming the service DB 6.

[0069] According to the above configuration, data related to the provision of services can be recorded while ensuring authenticity using a blockchain mechanism. Furthermore, the private key used to verify the authenticity of the data is controlled by the issuing server 1 so that it is stored in the secure storage 47. This reduces the risk of unauthorized use of the service due to leaks of the private key, etc. Furthermore, because data verification or user authentication is performed based on the DID, the servicer does not need to consider the type of user device 4. By incorporating a mechanism for controlling the storage location of the private key in the user device 4 in a system that performs authentication using the DID, it becomes possible to standardize authentication methods for a variety of user devices 4 while ensuring security.

[0070] <Variations of Functional Arrangement> The service server 2 may be integrated with the issuing server 1. That is, the issuing server 1 may include a message receiving unit G1, a verification unit G2, and a data registration unit G3 related to a certain service. The functional arrangement of the ID management system 100 may be changed as appropriate. Furthermore, the ID management system 100 may include multiple service servers 2. One or multiple smart contracts may be registered in the service DB 6. A smart contract is a program that automatically executes a predetermined process corresponding to a service when a registered message (in other words, a transaction) satisfies a predetermined condition.

[0071] The ID management system 100 may also include an Encrypted Data Vault (EDV) that stores additional data associated with the execution of a service. The EDV may be constructed in the registry 5 or the service DB 6. The additional data associated with the execution of a service may be information about the holder linked to the DID, a list of available services, etc. The additional data related to a vehicle-specific service may include a vehicle identification number (VIN) and owner information.

[0072] Additionally, the ID management system 100 may include a relay server that performs tasks such as creating digital signatures. The relay server relays communication between a device on which the client software 40 cannot be installed and the service server 2. For convenience, in this disclosure, a device on which the client software 40 is not installed is referred to as a non-compliant device. The relay server itself holds a DID and a private key associated therewith. The relay server authenticates a non-compliant device / its user using information other than the DID, such as a password, a one-time passcode, or biometric information. The relay server may generate a message set by attaching a digital signature using its private key and its DID to a message received from an authenticated non-compliant device, and transmit the message set to the service server 2. The relay server may also have a function for forwarding data issued by the service server 2 or a smart contract to a non-compliant device.

[0073] <Example of Service> Here, the advantages of utilizing DID will be described using an example in which the ID management system 100 is equipped with an LBS server 2a, which is a service server 2 that provides LBS (Location Based Service). LBS is a service that uses location information of a user device 4. For example, the LBS server 2a may be a server that acquires location information of a user device 4. For convenience, in this disclosure, a service that distributes coupons to a user device 4 (or a user) based on the user device 4 entering a specific area is referred to as a coupon distribution service. Note that the entry of the user device 4 into the specific area may be detected when the location information of the user device 4 satisfies a specific condition.

[0074] The following description is based on the following assumptions: The owner of the user device 4 (i.e., the user) is a person authorized to use the coupon distribution service. That is, data indicating that the coupon distribution service is available is registered in the user's DID document. The ID management system 100 includes an LBS-BC 6a, which is a blockchain for the LBS. The LBS server 2a is a node participating in the network of the LBS-BC 6a. The LBS-BC 6a includes a smart contract SCa that is compatible with the coupon distribution service.

[0075] The smart contract SCa may be a program that issues a coupon to a user associated with a message (transaction) whose location information satisfies a specific condition, based on the message being registered. The user device 4 may be a vehicle 4B, a smartphone 4A, or the like. The LBS-BC 6a corresponds to the service DB 6.

[0076] In the example situation shown in FIG. 11 , while the user device 4 is moving, it generates a message set at predetermined reporting intervals and transmits it to the LBS server 2a ((1) in the figure). The message set generated here is a data set containing data for LBS as a message body. The message body may be the location information of the user device 4. The message set may be a data set containing the location information of the user device 4, an identification number (i.e., a distributed identifier) ​​as a DID, and an electronic signature. The message set may not contain personal information other than the distributed identifier. The location information may be the calculation result of a GNSS (Global Navigation Satellite System) receiver. The GNSS may be GPS, Galileo, IRNSS, QZSS, or BeiDou. The reporting interval may be 10 seconds, 1 minute, 10 minutes, etc.

[0077] When the LBS server 2a receives the message set, it performs processing for DID resolution ((2) in the figure). As a result, the LBS server 2a obtains a public key linked to the DID of the message set from the registry 5 ((3) in the figure). After obtaining the public key, the LBS server 2a uses the public key to verify the authenticity of the received message ((4) in the figure). The verification flow may be the same as steps S207 to S209.

[0078] If the LBS server 2a determines that the received message is valid as a result of the above verification, it registers the message in the LBS-BC 61a ((5) in the figure). If the location information included in the registered message satisfies specific conditions, the smart contract SCa issues a coupon to the user ((6) in the figure). If the location information included in the registered message does not satisfy the specific conditions, the smart contract SCa does not issue a coupon to the user.

[0079] The function of verifying whether the sender of the location information (in other words, the user) has the right to use the coupon distribution service may be provided by the LBS server 2a or the smart contract SCa. Whether the sender of the location information has the right to use the service may also be determined based on DID resolution / DID document. The LBS server 2a may be a server that only has the function of receiving a message set from the user device 4 and verifying the legitimacy of the message through DID resolution. Processing related to coupon distribution, etc. may be executed by the smart contract SCa.

[0080] In addition, coupon distribution may also be performed on the LBS-BC 61a (i.e., the blockchain). Coupon distribution may be a process of registering the fact that a user has a coupon as a transaction on the blockchain, rather than distributing the coupon to the user's specific email address / phone number / address. According to the above configuration, a coupon distribution service provider (i.e., a servicer) can distribute coupons to users without personal information such as the user's email address. In another example, the smart contract SCa or the LBS server 2a may be configured to send coupon data to an email address obtainable by DID resolution.

[0081] In the above configuration, when a user uses the coupon distribution service, they only need to send their identification number as a DID and their location information to the LBS server 2a. In other words, the user does not need to provide personal information other than the distributed identifier to the servicer. This makes it easier to protect the user's privacy. Furthermore, the DID mechanism allows the user to control the information they disclose to the servicer.

[0082] Furthermore, by utilizing the smart contract SCa, the LBS server 2a does not need to determine whether the location information provided by the user device 4 is located in a specific area, thereby reducing the processing load on the LBS server 2a.

[0083] In another embodiment, the LBS server 2a may be configured to register a message in the LBS-BC 62a only if the received message is authentic and the location information included in the message satisfies specific conditions. This configuration makes it possible to reduce the data size of the LBS-BC 62a.

[0084] The above describes an aspect in which DIDs are used to verify received data in the service server 2, but the above disclosure may also be applied to user authentication processing. According to the above configuration, user authentication and data verification are performed using the DID mechanism. Therefore, specific authentication and verification methods can be standardized regardless of the nature of the service or the user device 4. A service platform using the ID management system 100 can alleviate problems associated with implementing services that are expected to communicate with a variety of user devices 4.

[0085] <Additional Remarks (1)> The present disclosure also includes the following technical ideas.

[0086] [Technical Idea 1] An identification information management method including: issuing, based on a request from a device, an identifier, a private key associated with the identifier, and a public key corresponding to the private key; acquiring data indicating the type of the device from the device and identifying the type of the device; specifying a secure area in which to store the private key based on the identified type of the device; storing the private key in the secure area; and registering the identifier and the public key in a blockchain-based registry.

[0087] [Technical Concept 2] The identification information management method according to Technical Concept 1, wherein the identifier is a distributed identifier including a character string indicating a DID method and a DID method unique identifier.

[0088] [Technical Idea 3] The identification information management method according to Technical Idea 1 or 2, wherein the secure area is a storage area that is physically or logically separated from a normal area, which is a storage area where data is stored without encryption.

[0089] [Technical Idea 4] The identification information management method according to any one of Technical Ideas 1 to 3, further comprising, if the device does not have the secure area, presenting a message to a user of the device prompting the user to acquire the secure area.

[0090] [Technical Idea 5] The identification information management method according to any one of Technical Ideas 1 to 4, further comprising: receiving from the device a data set including a message, a signature value generated based on the message and the private key, and the identifier; obtaining from the registry the public key associated with the identifier based on the identifier included in the data set; verifying the validity of the signature value using the public key; and, upon determining that the signature value is valid, executing processing according to the message.

[0091] [Technical Idea 6] A server that manages identification information, the server being configured to: issue an identifier, a private key associated with the identifier, and a public key corresponding to the private key, based on a request from a device used by a user; acquire data indicating the type of the device from the device, and identify the type of the device; designate a secure area in which to save the private key, based on the identified type of the device; send an instruction signal to the device to cause the private key to be saved in the secure area; and register the identifier and the public key in a blockchain-based registry.

[0092] [Technical Idea 7] A program including instructions to cause a computer included in a device used by a user to execute the following: accept a request for issuance of an identifier via an input device; based on the acceptance of the request for issuance of the identifier, send a request signal to a server requesting issuance of the identifier; send data indicating the type of the device to the server; receive a private key associated with the identifier from the server, and store the private key in a storage area specified by the server.

[0093] [Technical Idea 8] The program according to Technical Idea 7, including instructions to cause the computer to execute a process for displaying on a display a message prompting the user to acquire the storage area specified by the server if the storage area specified by the server does not exist.

[0094] Note that the present disclosure also includes an identification information management method in which the step of registering the identifier and public key in a blockchain-based registry in Technical Idea 1 is omitted. Furthermore, registering the identifier and public key in a blockchain-based registry in Technical Idea 1 may be replaced by registering the identifier and public key in a registry that can be referenced by a service server. The present disclosure also includes a configuration in which Technical Ideas 2 to 5 are also applied to Technical Ideas 6 and 7.

[0095] <Supplementary Note (2)> The various flowcharts shown in this disclosure are merely examples, and the number of steps constituting the flowcharts and the execution order of the processes can be changed as appropriate. The controls shown in each flowchart may be combined / executed in parallel to the extent consistent. Expressions such as "acquire," "determine," "detect," "generate," and "calculate" may be interchangeable. Acquiring data by a device also includes generating the data based on a signal input from another device / sensor. The devices, systems, and methods described in this disclosure may be implemented by a dedicated computer comprising a processor programmed to execute one or more functions embodied in a computer program. The devices and methods described in this disclosure may be implemented using dedicated hardware logic circuits. The devices and methods described in this disclosure may be implemented by one or more dedicated computers configured by combining a processor executing a computer program with one or more hardware logic circuits. The processor may be any computing core, such as a CPU, MPU, GPU, or DFP (Data Flow Processor). Some or all of the functions of the processor 11 may be implemented using a system-on-chip (SoC), an integrated circuit (IC), or a field-programmable gate array (FPGA). The computer program includes instructions to be executed by a computer. The computer program may be stored on a computer-readable non-transitory tangible recording medium. The recording medium for the computer program may be a variety of media, such as a hard-disk drive (HDD), a solid-state drive (SSD), or a flash memory.

Claims

1. A method for managing identity information, comprising: issuing, upon a request from a device, an identifier, a private key associated with the identifier, and a public key corresponding to the private key; obtaining data from the device indicating a type of the device, and identifying the type of the device; specifying a secure area in which to store the private key based on the identified type of the device; storing the private key in the secure area; and registering the identifier and the public key in a blockchain-based registry.

2. The method of claim 1, wherein the identifier is a distributed identifier including a character string indicating a DID method and a DID method unique identifier.

3. The identification information management method according to claim 1, wherein the secure area is a storage area that is physically or logically separated from a normal area, which is a storage area in which data is stored without being encrypted.

4. The method of claim 1, further comprising, if the device does not have the secure area, presenting a message to a user of the device prompting the user to obtain the secure area.

5. The identification information management method of claim 1, further comprising: receiving from the device a data set including a message, a signature value generated based on the message and the private key, and the identifier; obtaining from the registry the public key associated with the identifier based on the identifier included in the data set; verifying the validity of the signature value using the public key; and executing processing corresponding to the message upon determining that the signature value is valid.

6. A server that manages identification information, the server being configured to: issue, upon a request from a device used by a user, an identifier, a private key associated with the identifier, and a public key corresponding to the private key; acquire data indicating the type of the device from the device, and identify the type of the device; designate a secure area in which to store the private key based on the identified type of the device; send an instruction signal to the device to cause the private key to be stored in the secure area; and register the identifier and the public key in a blockchain-based registry.

7. A program including instructions for causing a computer included in a device used by a user to execute the following steps: accept a request for issuance of an identifier via an input device; based on the acceptance of the request for issuance of the identifier, send a request signal to a server requesting issuance of the identifier; send data indicating the type of the device to the server; receive a private key associated with the identifier from the server, and store the private key in a memory area specified by the server.

Images