Identification information management method, server, and program

Abstract

The present invention relates to an identification information management method, a server, and a program, in which an issuing server (1) issues, on the basis of a request from a user device (4), a distribution identifier (DID), a private key associated with the DID, and a public key corresponding to the private key. Furthermore, the issuing server (1) determines the type of the user equipment (4) by communicating with the user equipment (4). Furthermore, the issuing server (1) stores the private key in a secure area corresponding to the type of the user equipment, and registers the DID and the public key in a blockchain-based registry.

Description

[0001] Cross-reference to related applications

[0002] This application is based on Japanese Patent Application No. 2023-107836, filed in Japan on June 30, 2023, by reference to the contents of the application on which the reference is made in its entirety. Technical Field

[0003] This disclosure relates to techniques for verifying the legitimacy of received data. Background Technology

[0004] As a method for managing digital identities, the World Wide Web Consortium (WHC) advocates for DIDs (Decentralized Identifiers). DIDs are technologies / structures that use distributed ledger systems such as blockchain to manage digital identities in a distributed manner. Patent Document 1 discloses a method for authenticating users who want to log in to a platform using a structure based on DIDs. Digital signatures generated using private keys are used in user authentication and data verification.

[0005] Patent document 1: Japanese Patent Application Publication No. 2021-111412.

[0006] Existing DIDs do not specify the location for storing private keys on user equipment, nor do they restrict the structure of that storage location. Furthermore, the security level of the medium storing the private key may differ depending on the type of user equipment. Here, "type" can be interpreted as specification, function, or configuration.

[0007] In such a scenario, depending on the type of user device, it's possible that the private key is stored in a low-security storage area. If the security level is low, the risk of private key leakage is high. Assuming the private key is leaked from the user device, DID-based services could be misused. Summary of the Invention

[0008] This disclosure is made based on the above circumstances, and one of its purposes is to provide technology that can reduce the possibility of services being misused.

[0009] The identification information management method disclosed herein includes the following processing: issuing an identifier, a private key associated with the identifier, and a public key corresponding to the private key based on a request from the device; obtaining data representing the type of the device from the device to determine the type of the device; specifying a secure area as the storage destination for the private key based on the determined type of the device; storing the private key in the secure area; and registering the identifier and public key in a blockchain-based registry.

[0010] According to the method described above, the location for storing the private key is set as a predefined secure area corresponding to the device type. This reduces the possibility of the private key being leaked and misused. Consequently, the risk of the service being misused is reduced.

[0011] Furthermore, the server included in this disclosure is a server for managing identification information, which is configured to perform the following processes: based on a request from a device used by a user, issuing an identifier, a private key associated with the identifier, and a public key corresponding to the private key; obtaining data representing the type of the device from the device and determining the type of the device; specifying a secure area as the destination for storing the private key based on the determined type of the device; sending an indication signal to the device for storing the private key in the secure area; and registering the identifier and public key in a blockchain-based registry.

[0012] The program included in this disclosure includes commands that cause a computer equipped with a device used by a user to perform the following processes: accepting a request for the issuance of an identifier via an input device; sending a request signal for the issuance of the identifier to a server based on the accepted request for the issuance of the identifier; sending data indicating the type of the device to the server; and receiving a private key associated with the identifier from the server and storing the private key in a storage area designated by the server.

[0013] Furthermore, the reference numerals in parentheses within the scope of the claims indicate the correspondence between specific units described in the embodiments described later as an example, and do not limit the technical scope of this disclosure. Attached Figure Description

[0014] Figure 1 This is a diagram showing the overall structure of the ID management system.

[0015] Figure 2 It is a diagram representing the structure of user equipment.

[0016] Figure 3 This is a diagram showing the structure of the distribution server.

[0017] Figure 4 This is a functional block diagram of the distribution server.

[0018] Figure 5 This is a functional block diagram of the service server.

[0019] Figure 6 It is a flowchart showing the order of key pair issuance and registration of DID.

[0020] Figure 7 This is a diagram used to illustrate the structure of DID.

[0021] Figure 8This is a diagram representing an example of a DID document.

[0022] Figure 9 This is a diagram representing another example of a DID document.

[0023] Figure 10 This is a flowchart representing the message verification process.

[0024] Figure 11 This is a diagram illustrating an example of a service provisioning method that uses DID. Detailed Implementation

[0025] Hereinafter, embodiments of the present disclosure will be described using the accompanying drawings. The present disclosure is not limited to the embodiments described below. The structures disclosed below can be implemented with various modifications without departing from the spirit of the matter. Various modifications can be appropriately combined without creating technical inconsistencies. The present disclosure also includes undisclosed structures formed by combining multiple modifications. In the following description, components with the same function are labeled with the same reference numerals, and sometimes their specific descriptions are omitted. When only a part of the structure is mentioned, the descriptions described in other parts can be applied to other parts.

[0026] <System Structure>

[0027] The ID management system 100 disclosed herein is a system that absorbs the differences in specifications of each user device 4 and reduces the possibility that the identification information (i.e., ID: Identifier) ​​used for entity (in other words, user) authentication may be misused. 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.

[0028] Issuing Server 1 is the server that issues user IDs. Service Server 2 is the server that provides arbitrary services to users via communication with User Device 4. Services may include coupon distribution, diagnostics of User Device 4, cryptocurrency exchange, administrative procedures, taxi dispatch, etc. Node 3 is the computer that performs mining within the blockchain. Issuing Server 1, Service Server 2, and Node 3 participate in the blockchain network. Issuing Server 1 and Service Server 2 can also be understood as being part of Node 3 within the blockchain network. Furthermore, Node 3 is an arbitrary element. If the blockchain accessed by Issuing Server 1 is a private blockchain, Node 3 can be omitted. Hereafter, Issuing Server 1, Service Server 2, and Node 3 will also be collectively referred to as Issuing Server 1, etc.

[0029] Issuance server 1, etc., includes a storage device for storing blockchain data. Furthermore, issuance server 1, etc., is configured to share blockchain data. Issuance server 1, etc., includes a registry 5 and a service DB6 as a storage area implemented using the blockchain. DB is an abbreviation for database. Registry 5 is a storage area that records the ID of each entity (e.g., a user). As described later, the ID in this embodiment is a distributed identifier (DID: Decentralized Identifier). Registry 5 is equivalent to VDR (Verifiable Data Registry).

[0030] Service DB6 is a recording area for storing service data. Service data in this disclosure refers to the data required for the provision of the service. For example, in a service that distributes coupons based on a user's location information, data representing the user's location can be considered service data. Smart contracts that automatically execute processing corresponding to the registered messages can be registered in Service DB6. Registry 5 and Service DB6 can be logical storage.

[0031] The blockchain that functions as Registry 5 and Service DB6 can be a consortium blockchain. In other implementations, the blockchain can also be a public / private blockchain. The blockchain can be implemented using Hyperledger (registered trademark) Fabric.

[0032] Furthermore, in this embodiment, registry 5 and service DB6 are implemented on a single blockchain, but the implementation method of registry 5 and service DB6 is not limited to this. The blockchain for registry 5 and the blockchain for service DB6 can also be separate. The combination of nodes 3 forming the blockchain containing registry 5 and the combination of nodes 3 forming the blockchain containing service DB6 can be different. The form and constituent members of the ID management blockchain that functions as registry 5 and the service blockchain that functions as service DB6 can be different. Alternatively, the ID management blockchain can be consortium-based, while the service blockchain can be public or private.

[0033] Furthermore, in the presence of multiple services, each service can have its own independent blockchain. The combination of nodes 3 forming the blockchain for each service can be different. Additionally, the registry 5 does not necessarily need to be formed on a blockchain. In other words, the location where the DID is stored does not have to be a blockchain. The location where the DID is stored can also be a specific database.

[0034] <User Equipment Structure>

[0035] Here is a description of user device 4. User device 4 can be a smartphone 4A, a vehicle 4B, or a server 4C, etc. Vehicle 4B can be understood as an electronic control unit (ECU) or computer installed in the vehicle. Server 4C can be a locally deployed server or a cloud server. In addition, user device 4 can be a laptop, desktop PC, tablet, etc.

[0036] Multiple user devices 4 may contain devices of different types. Here, "type" can also be interpreted as specifications, functions, or settings. For example, the operating systems (OS) of the multiple user devices 4 may be different. Additionally, the local storage structures of the multiple user devices 4 may differ.

[0037] User equipment 4 is configured to communicate with distribution server 1 and service server 2 via the Internet. User equipment 4 can send and receive data with distribution server 1 based on user actions or automatically according to a program. Each user equipment 4 is equipped with client software 40 that performs user equipment-side processing related to DID distribution. The client software 40 communicates with distribution server 1. This client software 40 may be software paired with server program installed on distribution server 1.

[0038] like Figure 2 As shown, user equipment 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.

[0039] Display 41 is a device for displaying images corresponding to input signals from processor 44. Operation unit 42 is a device for receiving user instructions to user equipment 4. Operation unit 42 may be a hardware switch or a touch panel overlaid on display 41. Operation unit 42 outputs signals corresponding to user operations to processor 44. Communication module 43 is a circuit module connected to the Internet for communicating with distribution server 1. Communication module 43 may be a wireless communication module for cellular communication such as 4G or 5G.

[0040] Processor 44 is a structure that performs various calculations. Processor 44 can be a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit), etc. Memory 45 can be RAM (Random Access Memory).

[0041] Normal storage 46 and secure storage 47 are implemented using rewritable, non-volatile storage media. Normal storage 46 is a storage area accessible to various applications. Normal storage 46 can be an area where data is stored without encryption. Normal storage 46 is equivalent to a normal area. Furthermore, the resources of user device 4 can also be divided into a normal world and a secure world using technologies such as Trusted Execution Environment (TEE). When the resources of user device 4 are divided into a normal world and a secure world, normal storage 46 can be understood from one perspective as storage within the normal world.

[0042] Secure storage 47 is a region with a certain level of confidentiality and security, separate from normal storage 46. Secure storage 47 can be a storage area physically separated from normal storage 46. Secure storage 47 can be a storage area accessible only to specific kernel / applications. In other embodiments, secure storage 47 can also be a storage area virtually separated from normal storage 46. Secure storage 47 can be understood in one sense as storage within a secure world isolated from the normal world.

[0043] Secure storage 47 may also be an area where a prescribed data storage method is applied. The prescribed data storage method is preferably one that has been confirmed by the designer of the distribution server 1 or a third-party organization to have the desired confidentiality. Secure storage 47 may be a storage device equipped with a structure that automatically encrypts and stores data.

[0044] The storage area of ​​the entity equivalent to secure storage 47 may vary depending on the type of user device 4. For Android smartphones, secure storage 47 may be a storage area protected by a TEE or Secure Element provided by the Android KeyStore. The TEE may also be an environment installed via Intel SGX or Arm TrustZone. For user devices 4 operating on iOS, such as iPhones, secure storage 47 may be a storage area protected by Secure Enclave. For user devices 4 operating on Linux, secure storage 47 may be a storage area protected by Secure Enclave. Secure storage 47 may also be cloud storage protected by AWS CloudHSM, Azure Key Vault, etc. Additionally, secure storage 47 may also be Trusted Storage.

[0045] Additionally, USB storage-type hardware wallets, etc., can also be included in secure storage 47. Secure storage 47 can also be configured to be removable from user device 4. Secure storage 47 is equivalent to a secure area. The storage area that the issuing server 1 considers as a secure area (secure storage 47) can be predefined in the issuing server 1. The issuing server 1 can have data (e.g., linked lists / tables) defining each type of secure area.

[0046] The normal storage 46 or the secure storage 47 stores a program executed by the processor 44, i.e., a device-oriented program. The device-oriented program includes client software 40. By executing the client software 40, the processor 11 is able to function as the user device 4 described below. For example, the user device 4 accepts user operations for DID issuance via the operation unit 42. Furthermore, in response to the aforementioned user operations, the user device 4 sends a signal requesting DID issuance to the issuance server 1.

[0047] <Structure of the Distribution Server>

[0048] Issuing server 1 is the server responsible for issuing DIDs and generating the key pairs associated with those DIDs. The key pair consists of a private key and a public key. Further details about DIDs will be discussed later. Figure 3 As shown, the distribution server 1 includes a processor 11, a communication interface 12, a memory 13, and a storage device 14.

[0049] Processor 11 is a structure that performs computational processing based on data received from other devices. Processor 11 can be a CPU or GPU, etc. Communication interface 12 is a circuit module for communication between processor 11 and other devices. Communication interface 12 may include circuitry for connecting to the Internet.

[0050] Memory 13 is a rewritable volatile storage medium. Memory 13 may be RAM. Memory 13 may be a component used to temporarily store received data from other devices, calculation results from processor 11, and programs, etc. Memory 14 is a rewritable non-volatile memory. Memory 14 may be implemented using at least one non-transitory tangible storage medium, such as semiconductor memory, magnetic media, and optical media. Memory 14 may include various types of storage media such as ROM (Read Only Memory) and flash memory. Memory 14 stores a program executed by processor 11, i.e., a server program. The server program may be used to implement... Figure 4 The program, shown as a block, contains at least a portion of the functions of the distribution server 1.

[0051] The server program and client software 40 can be developed and installed using an SDK (Software Development Kit) that can be applied to various types of user equipment 4. Executing the server program and client software 40 is equivalent to executing the identification information management method.

[0052] like Figure 4 As shown, the distribution server 1 includes a distribution unit F1, a registry registration unit F2, a type determination unit F3, and a device registration unit F4 as functional modules. Each functional module can be implemented by the processor 11 executing a server program. The distribution unit F1, registry registration unit F2, type determination unit F3, and device registration unit F4 are functional modules related to the registration of key pairs and DIDs. Figure 6 The actions of each functional module will be described later.

[0053] <Server Structure>

[0054] Service server 2, like distribution server 1, is a computer containing a processor, communication interface, memory, and storage. The storage contains programs executed by the processor for providing services.

[0055] like Figure 5 As shown, service server 2 has a message receiving unit G1, a verification unit G2, and a data registration unit G3 as functional modules. Each functional module can be implemented by a processor executing a prescribed program. The message receiving unit G1, the verification unit G2, and the data registration unit G3 are functional modules used to append messages sent from user device 4 using the issued DID to the blockchain. These messages can also be interpreted as requests, transactions, or service data. Figure 9 The actions of each functional module will be described later.

[0056] <Key Pairs and DID Issuance>

[0057] Use here Figure 6 The actions of the issuing server 1 related to the issuance of key pairs and DIDs are explained. Figure 6 The flowchart shown begins upon receiving a DID issuance request from user device 4 by the issuing server 1. The subsequent description of client software 40 can be replaced by user device 4 or processor 44. Furthermore, the descriptions of the issuing unit F1, registry registration unit F2, type determination unit F3, and device registration unit F4 can be replaced by issuing server 1 or processor 11. Later, user device 4, which will send the DID issuance request, or its owner, is also recorded as the request source.

[0058] Step S101 is the step where the issuing department F1 generates a key pair of public and private keys for the request source. The key pair can be generated using any method such as RSA. If step S101 is completed, the process proceeds to step S102.

[0059] Step S102 is the step where the issuing department F1 generates code, which is used as a DID, based on the public key generated in step S101. A DID is an identifier with a format defined by the W3C (World Wide Web Consortium). For example... Figure 7 As shown, a DID includes a Scheme, a DID Method, and a Method-Specific Identifier. These elements are separated by colons. The Scheme is a prefix followed by the DID Method, etc. The DID Method is a code specifying the type of structure using the DID, in other words, the method of interpreting the identifier. The information from the DID Method can be used by the service server 2 to determine the method for obtaining the document (so-called DID document) representing the information associated with the DID. The DID Method can be any method. The Method-Specific Identifier is assigned a unique value within the method. The entity (DID subject) is uniquely identified by the combination of the Method-Specific Identifier and the DID Method. The method for generating the Method-Specific Identifier can differ for each DID Method. The method for generating the Method-Specific Identifier can be any method. The issuing unit F1 can be configured to issue DIDs using any DID Method. If step S102 is completed, the process proceeds to step S103.

[0060] Furthermore, key pair generation and DID issuance can be implemented by different devices. The functions of the issuance unit F1 can be divided into multiple parts. Additionally, some or all of the functions of the issuance unit F1 can be located on other servers. Moreover, some or all of the functions of the issuance unit F1 can be provided by the client software 40. When the key generation function is located outside the issuance server 1, step S101 can be the step of obtaining a key pair. When the DID issuance function is located outside the issuance server 1, step S102 can be the step of obtaining the issued DID.

[0061] Additionally, the distribution unit F1 can include APIs (Application Programming Interfaces) for accepting distribution requests for DIDs from various types of user devices 4. The distribution unit F1 can include multiple acceptance APIs corresponding to each of the multiple device types. Thus, the distribution unit F1 is able to accommodate differences in the type of request source.

[0062] Step S103 is the preparatory process required for the registration of the DID by the Registry Registry F2, which involves saving the DID and the DID document in the Registry 5. The preparatory process may include generating data in JSON format representing the DID document. Alternatively, the preparatory process may include sending the DID document to the client software 40 for user verification, and signing the DID document using the private key generated in step S101.

[0063] For example, such as Figure 8 As shown, a DID document may contain 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 represents the owner (i.e., the user) of the DID. The DID itself is stored in the DID subject 61. The DID controller 62 represents the entity granted permission to modify the DID document. The DID controller 62 may be represented by the DID of the entity with modification permissions. The public key 63 is the public key generated in step S101. The public key type 64 represents the type of public key.

[0064] Figure 8 The DID document shown is an example. A DID document can contain data about the type, owner, and services that a user can use. The data about the services that can be used can also be described separately from the body using a defined attribute such as "Service". Furthermore, the DID documents related to the use of services can be created separately for each service. Figure 9 This is an example of a service-oriented document. Multiple DID documents can be created for a single DID. DID documents can be created for each purpose / use and stored distributed. The items contained in a DID document can be divided and described by attributes corresponding to its purpose / content.

[0065] Furthermore, the DID document can be stored in encrypted form in the registry in a way that allows it to be recovered using a defined function such as a resolver. The resolver can vary depending on the DID method. In this disclosure, using a resolver to retrieve the information contained in the DID document associated with the DID is also referred to as DID resolving. Retrieving the public key associated with the DID can also be included in one method of DID resolving.

[0066] If step S103 is completed, the process proceeds to step S104. Step S104 is the step where the type determination unit F3 obtains device type data from the client software 40. Device type data is data indicating the type of user device 4. Device type data may be data indicating the OS or model of user device 4. Device type data may also be data indicating the type, specifications, or location of the secure storage 47 held by user device 4. Device type data may also be data indicating a combination of storage devices that user device 4 can access. The type determination unit F3 can obtain device type data by requesting the client software 40 to send the device type. In other embodiments, device type data may also be included in the DID issuance request. If step S104 is completed, the process proceeds to step S105.

[0067] Step S105 is the step where the device registration unit F4 determines the storage destination for the private key corresponding to the type of user device 4. The storage destination for the private key is selected from various secure storage devices 47. For example, if the requesting source user device 4 is an Android-based smartphone, the device registration unit F4 designates the region used by the TEE as the storage destination for the private key. Alternatively, if the requesting source user device 4 is an iOS device, the device registration unit F4 designates the region protected by the SecureEnclave as the storage destination for the private key. Furthermore, if the requesting source user device 4 does not maintain a secure storage device 47, the device registration unit F4 may also designate a specified external storage device as the storage destination. The specified external storage device can be a secure storage device 47 in the cloud or a hardware wallet. The device registration unit F4 may also designate multiple types of secure regions as the storage destination for the private key. If step S105 is completed, the process proceeds to step S106.

[0068] Step S106 is the step where the device registration unit F4 sends the storage destination of the private key, the private key, and the dataset containing the DID to the client software 40. This information can also be sent in multiple messages. Furthermore, if the client software 40 has the functions involved in key generation and DID issuance, the data sent by the device registration unit F4 can be a message specifying the storage destination of the private key. Sending data already acquired by the client software 40 can be omitted. Upon receiving step S106, the client software 40 executes step S107.

[0069] Step S107 is the step in which the client software 40 saves the private key to the secure storage 47 based on the instruction from the device registration department F4. The process of saving the private key to the secure storage 47 can be implemented through cooperation with the software / hardware that forms the secure storage 47. The DID and public key can also be saved to either the normal storage 46 or the secure storage 47. The client software 40 also obtains information other than the public key contained in the DID document from the issuing server 1, and can save this information to any storage device. The client software 40 can be configured to save the DID document to either the normal storage 46 or the secure storage 47.

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

[0071] In this way, the issuing server 1 controls the actions of the user device 4 to ensure that the private key is stored in a secure area on the user device 4. This reduces the risk of private key leakage.

[0072] <Service Data / Message Registration and Processing>

[0073] Use here Figure 10 Use Figure 10 The flowchart shown illustrates the actions of user equipment 4 and service server 2 involved in message sending and receiving. Figure 10 The flowchart shown can be initiated when the user equipment 4 receives a message (in other words, data) transmission trigger generated by the service server 2. The transmission trigger can be designed appropriately. The user equipment 4 can also be programmed to send messages periodically. The message transmission conditions can be designed appropriately according to the content of the service. The subsequent recording of the message receiving unit G1, the verification unit G2, and the data registration unit G3 can be replaced by the service server 2 or its processor.

[0074] First, in step S201, user equipment 4 generates a message. The message contains data about items that should be registered with service DB6. In other words, the message has a payload corresponding to the service provided by service server 2. The message can be generated by a specified application, rather than by client software 40. Of course, message generation can also be performed by client software 40. The following processing of user equipment 4 can also be performed by client software 40, or by other applications. If step S201 is completed, the process proceeds to step S202.

[0075] Step S202 is the step in which user equipment 4 uses a prescribed hash function to transform the message generated in step S201, thereby generating a hash value. This hash value is the data used to create the electronic signature. The hash value generated in step S202 can be described in other words as a message digest value.

[0076] The hash function used to create the electronic signature can be SHA-256. Of course, the hash function can also be SHA-1, SHA512, MD-5, RIPEMD-160, etc. SHA is an abbreviation for Secure Hash Algorithm. MD stands for Message Digest algorithm. RIPEMD stands for Race Integrity PrimitiveEvaluation Integrity Primitives Evaluation Message Digest. If step S202 is completed, the process proceeds to step S203.

[0077] Step S203 is the step where user equipment 4 encrypts the hash value generated in step S202 using its private key. The encryption method can be RSA, etc. The encrypted hash value is equivalent to a digital signature of the message.

[0078] Step S204 is the step where user equipment 4 sends the dataset containing the message generated in step S201, the electronic signature generated in step S203, and the DID to service server 2. If step S204 is completed, the process moves to step S205. In this disclosure, the dataset for which the message body has been given an electronic signature and DID is also referred to as a message set.

[0079] Step S205 is the step where the message receiving unit G1 receives a message set sent from the user equipment 4. The message receiving unit G1 may include an API for receiving message sets sent from various types of user equipment 4. If the message receiving unit G1 receives a message set, the process proceeds to step S206.

[0080] Step S206 is the step where the verification unit G2 uses the DID contained in the received message set as the key to obtain the public key from the registry 5. The public key associated with the DID can be obtained through DID resolution. If step S206 is completed, the process proceeds to step S207.

[0081] Step S207 is the step where the verification unit G2 uses the public key obtained in step S206 to decrypt the electronic signature contained in the message set and restore the hash value of the message. If step S207 is completed, the process proceeds to step S208. Of course, the order of processing can be changed appropriately.

[0082] Step S208 is the step in which the verification unit G2 uses a shared hash function to transform the message body contained in the message set, thereby generating a hash value. The shared hash function is the hash function used by the user equipment 4 in the creation of the electronic signature. The hash value generated by step S208 is an element used for comparison with the hash function generated by step S207. In this disclosure, the hash value generated by step S208 is also referred to as the comparison hash value. If step S208 is completed, the process proceeds to step S209.

[0083] Step S209 is the step where 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 the message is valid. If the two hash values ​​do not match, the verification unit G2 determines the message is invalid. In the case of an invalid message, that is, if the two hash values ​​do not match, the verification unit G2 discards the received message. In the case of a inconsistent hash value, the verification unit G2 may also return an error message to the sending source. On the other hand, if the message is valid, that is, if the two hash values ​​match, the verification unit G2 sends the received message to the data registration unit G3.

[0084] If the data registration department G3 receives a message from the verification department G2, it executes the process of registering the message on the blockchain (step S210). For example, the data registration department G3 temporarily stores the message in the transaction pool. Upon receiving a predetermined number of messages accumulated in the transaction pool, the data registration department G3 generates a block and appends it to the blockchain. The consensus algorithm for appending the block can be any algorithm such as PoW (Proof of Work) or PoC (Proof of Consensus).

[0085] Furthermore, user equipment 4 can send message sets not only to service server 2, but also to all other nodes forming the blockchain. Multiple nodes 3 can perform the processing steps S205 to S210. Additionally, the data registration unit G3 can be configured to send messages confirming legitimacy to all other nodes forming service DB6.

[0086] Based on the above structure, the blockchain structure can be used to ensure authenticity while recording the data involved in the service provision. Furthermore, the private key used for verifying data authenticity is controlled by the issuing server 1 and stored in secure storage 47. Therefore, the risk of unauthorized use of the service due to private key leakage can be reduced. Additionally, data verification or user authentication is performed based on DID, so the service provider does not need to consider the type of user device 4. The structure controlling the storage location of the private key in the user device 4 within the DID authentication system ensures security and allows for the sharing of authentication methods across multiple user devices 4.

[0087] <Example of a variation in functional configuration>

[0088] Service server 2 can also be integrated with issuing server 1. That is, issuing server 1 can also have a message receiving unit G1, a verification unit G2, and a data registration unit G3 involved in a certain service. The functional configuration of ID management system 100 can be appropriately modified. In addition, ID management system 100 can contain multiple service servers 2. One or more smart contracts can be registered in service DB6. A smart contract is a program that automatically executes the prescribed processing corresponding to the service when the registered message (in other words, transaction) meets the prescribed conditions.

[0089] Additionally, the ID management system 100 may also have an EDV (Encrypted Data Vault) for storing ancillary data related to the execution of accompanying services. The EDV can be built within the registry 5 or within the service DB6. Ancillary data related to the execution of accompanying services may include information about the holder associated with the DID, a list of available services, etc. Ancillary data related to vehicle-specific services may include the Vehicle Identification Number (VIN) and owner information.

[0090] Additionally, the ID management system 100 may also include a relay server for generating proxy electronic signatures, etc. The relay server is a server that relays communication between devices that cannot install client software 40 and service server 2. For convenience, in this disclosure, devices without client software 40 are referred to as non-corresponding devices. The relay server maintains its own DID and the private key associated with it. The relay server uses information other than the DID, such as passwords, one-time passwords, and biometric information, to authenticate the non-corresponding device / user. The relay server can generate a message set that includes an electronic signature generated using its own private key and its own DID appended to messages received from the authenticated non-corresponding device, and sends it to service server 2. Furthermore, the relay server may have the function of forwarding data from service server 2 or smart contracts to non-corresponding devices.

[0091] <An example of a service>

[0092] Here, taking the case where the ID management system 100 has an LBS server 2a that serves as a service server 2 providing LBS (Location Based Service) as an example, the advantages of effectively using DID will be explained. LBS is a service that uses the location information of user device 4. For example, LBS server 2a can be a server that obtains the location information of user device 4. For convenience, in this disclosure, the service of distributing coupons to user device 4 (or user) based on user device 4 entering a specific area is referred to as a coupon distribution service. Furthermore, user device 4 entering a specific area can be detected by the user device 4's location information meeting specific conditions.

[0093] In the following description, the following premise applies: The owner of user device 4 (i.e., the user) is the person authorized to use the coupon distribution service. That is, data indicating the ability to use the coupon distribution service is registered in the user's DID document. The ID management system 100 has a blockchain for LBS, namely LBS-BC6a. LBS server 2a is a node participating in the LBS-BC6a network. LBS-BC6a has a smart contract SCa suitable for the coupon distribution service.

[0094] A smart contract (SCa) can be a program that issues coupons to users associated with a message (transaction) based on registered location information that meets specific conditions. User device 4 can be a vehicle 4B, a smartphone 4A, etc. LBS-BC6a is equivalent to service DB6.

[0095] exist Figure 11In the illustrated scenario, user equipment 4, while in motion, generates a message set at a predetermined reporting interval and sends it to LBS server 2a ((1) in the figure). The message set generated here is a dataset containing data for LBS as the message body. The message body may be the location information of user equipment 4. The message set may be a dataset containing the location information of user equipment 4, an identification number as a DID (i.e., a distribution identifier), and an electronic signature. The message set may not contain personal information other than the distribution identifier. The location information may be the result of calculation by a GNSS (Global Navigation Satellite System) receiver. GNSS may be GPS, Galileo, IRNSS, QZSS, or BeiDou. The reporting interval may be 10 seconds, 1 minute, 10 minutes, etc.

[0096] If LBS server 2a receives a message set, it performs processing for DID resolution (Figure (2)). LBS server 2a then obtains the public key associated with the DID of the message set from registry 5 (Figure (3)). If LBS server 2a obtains the public key, it uses it to verify the legitimacy of the received message (Figure (4)). The verification process can be the same as steps S207-S209.

[0097] If the LBS server 2a determines that the above verification result is valid and the received message is legitimate, it registers the message in LBS-BC61a (Figure (5)). If the location information contained in the registered message meets certain conditions, the smart contract SCa issues coupons to the user (Figure (6)). If the location information contained in the registered message does not meet certain conditions, the smart contract SCa does not issue coupons to the user.

[0098] Furthermore, the function of verifying whether the source of the location information (in other words, the user) has the right to use the coupon distribution service can be provided by the LBS server 2a or by the smart contract SCa. Whether the source of the location information has the right to use the service can also be determined based on the DID resolution / DID document. The LBS server 2a is a server that only has the function of receiving message sets from user device 4 and verifying the legality of the messages through the DID resolution. The processing involved in coupon distribution, etc., can be executed by the smart contract SCa.

[0099] Furthermore, coupon distribution can also be implemented on LBS-BC61a (i.e., blockchain). Coupon distribution doesn't necessarily involve sending coupons to a user's specific email address / phone number / residence; instead, the act of a user possessing a coupon is recorded as a transaction on the blockchain. Based on this structure, the coupon distribution service provider (i.e., the service provider) can distribute coupons to users even without their personal information such as email addresses. In other examples, the smart contract SCa or LBS server 2a can be configured to send coupon data to email addresses that can be obtained through DID resolution.

[0100] In the above structure, when using the coupon distribution service, users only need to send their identification number (DID) and location information to the LBS server 2a. In other words, users do not need to provide personal information other than the distribution identifier to the service provider. Therefore, it is easy to protect user privacy. In addition, through the DID structure, users can control the information disclosed by the service provider.

[0101] Furthermore, by effectively utilizing smart contracts SCa, LBS server 2a does not need to determine whether the location information provided by user device 4 exists in a specific area. Therefore, the processing load of LBS server 2a can be reduced.

[0102] Furthermore, in other embodiments, the LBS server 2a can also be configured to register a message with LBS-BC62a only if the received message is authentic and the location information contained in the message meets specific conditions. According to this structure, the data size of LBS-BC62a can be reduced.

[0103] The above describes the use of DIDs for verifying received data in service server 2, but the above disclosure can also be applied to user authentication processing. Based on the above structure, user authentication and data verification are implemented using a DID structure. Therefore, regardless of the nature of the service or the user device 4, specific authentication and verification methods can be shared. The service platform using the ID management system 100 can mitigate the problems involved in implementing services that are expected to communicate with various user devices 4.

[0104] <Postscript (1)>

[0105] This disclosure also includes the following technical ideas.

[0106] [Technical Idea 1]

[0107] A method for managing identification information includes the following processing:

[0108] Based on a request from the device, issue an identifier, a private key associated with that identifier, and a public key corresponding to that private key;

[0109] Obtain data representing the type of the aforementioned equipment from the aforementioned equipment, and determine the type of the aforementioned equipment;

[0110] Based on the type of the aforementioned device, a secure area is designated as the destination for storing the aforementioned private key.

[0111] Store the aforementioned private key in the aforementioned secure area; and

[0112] Register the aforementioned identifier and public key in a blockchain-based registry.

[0113] [Technical Idea 2]

[0114] According to the identification information management method described in Technical Idea 1, in which,

[0115] The above identifier is a distribution identifier that includes a string representing the DID method and a DID (Decentralized Identifier) ​​method-specific identifier.

[0116] [Technical Idea 3]

[0117] According to the identification information management method described in technical concept 1 or 2, wherein,

[0118] The aforementioned secure area is a storage area that is physically or logically separated from the normal area, which is a storage area where data is stored without being encrypted.

[0119] [Technical Idea 4]

[0120] According to any one of the technical ideas 1 to 3, the identification information management method includes:

[0121] If the aforementioned device does not have the aforementioned secure area, a message will be sent to the user of the aforementioned device urging them to obtain the aforementioned secure area.

[0122] [Technical Idea 5]

[0123] According to any one of the technical ideas 1 to 4, the identification information management method further includes:

[0124] Receive a dataset from the aforementioned device, the dataset containing a message, a signature value generated based on the aforementioned message and the aforementioned private key, and the aforementioned identifier;

[0125] Based on the identifiers contained in the dataset, obtain the public key associated with the identifiers from the registry.

[0126] Use the aforementioned public key to verify the validity of the aforementioned signature value; and

[0127] If the above signature value is found to be valid, perform the corresponding processing for the above message.

[0128] [Technical Idea 6]

[0129] One type of server is a server that manages identification information, in which...

[0130] The above-mentioned server is configured to perform the following processes:

[0131] Based on a request from a user's device, issue an identifier, a private key associated with that identifier, and a public key corresponding to that private key;

[0132] Obtain data representing the type of the aforementioned equipment from the aforementioned equipment, and determine the type of the aforementioned equipment;

[0133] Based on the type of the aforementioned device, a secure area is designated as the destination for storing the aforementioned private key.

[0134] Send an indication signal to the device to store the private key in the secure area; and

[0135] Register the aforementioned identifier and public key in a blockchain-based registry.

[0136] [Technical Idea 7]

[0137] A program comprising commands that cause a computer equipped with a device used by a user to perform the following processes:

[0138] The request to issue an identifier is accepted via the input device;

[0139] Based on the acceptance of the above-mentioned identifier issuance request, a request signal for the issuance of the above-mentioned identifier is sent to the server;

[0140] Send data indicating the type of the aforementioned device to the aforementioned server; and

[0141] Receive a private key associated with the identifier from the server and store the private key in a storage area specified by the server.

[0142] [Technical Idea 8]

[0143] According to the procedure described in Technical Idea 7, in which,

[0144] The command includes a message that causes the computer to perform a process of displaying a message urging the acquisition of the storage area specified by the server on a monitor when the computer does not have the storage area specified by the server.

[0145] Furthermore, the identification information management method that omits the step of registering the identifier and public key in a blockchain-based registry, as described in Technical Idea 1, is also included in this disclosure. Additionally, the step of registering the identifier and public key in a blockchain-based registry in Technical Idea 1 can be replaced by registering the identifier and public key in a registry that the service server can reference. The application of Technical Ideas 2-5 to the construction of Technical Ideas 6-7 is also included in this disclosure.

[0146] <Postscript (2)>

[0147] The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowcharts and the execution order of the processes can be appropriately changed. The controls shown in the flowcharts can be combined / executed in parallel without contradiction. Acquisition, determination, detection, generation, and calculation can be interchanged. Acquiring data by a device also includes generating that data based on signals input from other devices / sensors. The devices, systems, and methods described in this disclosure can also be implemented using a dedicated computer, which constitutes a processor programmed to perform one or more functions embodied in a computer program. The devices and methods described in this disclosure can also be implemented using dedicated hardware logic circuits. The devices and methods described in this disclosure can also be implemented using more than one dedicated computer, which consists of a processor executing a computer program and more than one hardware logic circuit. The processor can be any processing core such as a CPU, MPU, GPU, DFP (Data Flow Processor), etc. Some or all of the functions of processor 11 can also be implemented using any of a system-on-chip (SoC), an integrated circuit (IC), or a field-programmable gate array (FPGA). A computer program contains instructions that are executed by a computer. A computer program can be stored on a computer-readable, non-transferable tangible recording medium. The recording medium for a computer program can be a variety of media, such as a hard disk drive (HDD), a solid state drive (SSD), or flash memory.

Claims

1. An identification information management method including the following processes: issuing 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; acquiring data indicating a type of the device from the device, and determining the type of the device; specifying a secure area as a storage destination of the private key based on the determined 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 identification information management method according to claim 1, wherein the identifier is a distributed identifier including a string indicating a DID method, and a DID method-specific identifier.

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

4. The identification information management method according to Claim 1, wherein in a case where the device does not have the secure area, prompting a user of the device with a message urging acquisition of the secure area. further including receiving a data set from the device, the data set including the message, a signature value generated based on the message and the private key, and the identifier; 5. The identification information management method according to Claim 1, wherein acquiring the public key associated with the identifier from the registry based on the identifier included in the data set; verifying the signature value using the public key; and in a case where the signature value is accepted as being legitimate, performing a process corresponding to the message.

6. A server that is a server that manages identification information, wherein the server is configured to implement the following processes, including: issuing 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; acquiring data indicating a type of the device from the device, and determining the type of the device; specifying a secure area as a storage destination of the private key based on the determined type of the device; transmitting an instruction signal for storing the private key in the secure area to the device; and registering the identifier and the public key in a blockchain-based registry.

7. A program including commands that cause a computer provided in a device used by a user to perform the following processes, including: accepting issuance of an identifier via an input device; transmitting a request signal requesting issuance of the identifier to a server based on acceptance of the issuance request of the identifier; transmitting data indicating a type of the device to the server; and receiving a private key associated with the identifier from the server, and storing the private key in a storage area specified by the server. ​ ​

Images