Identification information management method, server, and program

Abstract

To provide a technique for reducing the risk of unauthorized use of a service.SOLUTION: An issuing server 1 issues a decentralized identifier (DID), a private key associated with the DID, and a public key corresponding to the private key, based on a request from a user device 4. The issuing server 1 also identifies the type of the user device by communication with the user device 4. The issuing server 1 then stores the private key in a secure area corresponding to the type of the user device, and registers the DID and the public key in a blockchain-based registry.SELECTED DRAWING: Figure 4

Description

[Technical field]

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

[0002] 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 distributed manner using a distributed ledger system such as a blockchain. Patent Document 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. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2021-111412 A Summary of the Invention [Problem to be solved by the invention]

[0004] In the current DIDs, there is no provision 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. The type here may be interpreted as a specification, a function, or a setting.

[0005] 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, the DIDs-based service may be used fraudulently.

[0006] The present disclosure has been made in light of the above circumstances, and one of its objectives is to provide a technology capable of reducing the risk of unauthorized use of a service. [Means for solving the problem]

[0007] 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 from the device indicating a device type and identifying the device type; 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.

[0008] 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 illegally. As a result, the risk of the service being used illegally can be reduced.

[0009] In addition, the server included in the present disclosure is a server that manages identification information, and is configured to perform the following operations based on a request from a device used by a user: issue an identifier, a private key associated with the identifier, and a public key corresponding to the private key; obtain data indicating the type of the device from the device and 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.

[0010] 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 to request 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.

[0011] In addition, 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. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram showing an overall configuration of an ID management system. [Diagram 2] FIG. 2 is a diagram showing the configuration of a user device. [Diagram 3] FIG. 2 is a diagram illustrating a configuration of an issuing server. [Figure 4] FIG. 2 is a functional block diagram of an issuing server. [Diagram 5] FIG. 2 is a functional block diagram of a service server. [Figure 6] 1 is a flowchart showing a procedure for issuing and registering a key pair and a DID. [Figure 7] FIG. 1 is a diagram for explaining the configuration of a DID. [Figure 8] FIG. 1 is a diagram illustrating an example of a DID document. [Figure 9] FIG. 13 is a diagram showing another example of a DID document. [Figure 10] 1 is a flow chart illustrating a message validation process. [Figure 11] FIG. 1 is a diagram illustrating an example of a service providing method using a DID. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiment. The configuration disclosed below may be modified in various ways without departing from the scope of the present disclosure. Various modified examples may be appropriately combined as long as no technical contradiction occurs. The present disclosure also includes a configuration that is not explicitly shown and is formed by combining multiple modified examples. In the following description, the same reference numerals are used for components having the same function, and specific descriptions thereof may be omitted. When only a part of the configuration is mentioned, the description given elsewhere may be applied to the other parts.

[0014] <System configuration> The ID management system 100 of the present disclosure is a system that reduces the risk of unauthorized use of identification information (i.e., ID: Identifier) ​​used to authenticate an entity (in other words, a user) while absorbing differences in specifications for each user device 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.

[0015] The issuing server 1 is a server that issues a user's ID. The service server 2 is a server that provides any service to the user through communication with the user device 4. The service may be coupon distribution, diagnosis of the user device 4, virtual currency exchange, administrative procedures, dispatching a taxi, etc. 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 interpreted 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.

[0016] 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., a user). The ID in this embodiment is a decentralized identifier (DID), as described later. The registry 5 corresponds to a verifiable data registry (VDR).

[0017] The service DB 6 is a recording area for recording service data. Service data in the present disclosure is data necessary for providing a service. For example, in a service that delivers coupons according to user location information, data indicating the user's location may correspond to the service data. The service DB 6 may register a smart contract that automatically executes processing according to a registered message. The registry 5 and the service DB 6 may be logical storage.

[0018] 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 Fabric.

[0019] 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 separated. 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 functioning as the registry 5 and the service blockchain functioning 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 type or a private type.

[0020] Furthermore, when multiple services exist, an independent blockchain may exist for each service. The combination of nodes 3 forming the blockchain may be different 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.

[0021] <User device configuration> 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 mounted on 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.

[0022] The multiple user devices 4 may include devices of different types. The type here may be rephrased as specifications, functions, or settings. For example, the multiple user devices 4 may have different OSs (Operating Systems). Furthermore, the multiple user devices 4 may have different local storage mechanisms.

[0023] 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 a user's operation or automatically according to a program. Client software 40 is installed in each user device 4, which performs processing on the user device 4 side 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 in the issuing server 1.

[0024] 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.

[0025] The display 41 is a device that displays an image according to an input signal from the processor 44. The operation unit 42 is a device for receiving a user's instruction to the user device 4. The operation unit 42 may be a hardware switch or a touch panel laminated 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.

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

[0027] The normal storage 46 and the secure storage 47 are realized using a rewritable non-volatile storage medium. The normal storage 46 is a storage area accessible to various applications. The normal storage 46 may be an area in which data is stored without being encrypted. 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 a 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 interpreted as a storage in the normal world from one point of view.

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

[0029] 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 a desired confidentiality. The secure storage 47 may be a storage that incorporates a mechanism for automatically encrypting and storing data.

[0030] The actual storage area corresponding to the secure storage 47 may differ depending on the type of the user device 4. For an Android (registered trademark) smartphone, the secure storage 47 may be a storage area protected by a TEE or a 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 that runs on 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 that runs on Linux (registered trademark), the secure storage 47 may be a storage on the cloud protected by AWS (registered trademark) CloudHSM, Azure (registered trademark) Key Vault, or the like. Alternatively, the secure storage 47 may be a Trusted Storage.

[0031] 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 the secure areas for each type are defined.

[0032] The normal storage 46 or the secure storage 47 stores a device-oriented program that is executed by the processor 44. The device-oriented program includes client software 40. The processor 11 can function as the user device 4 in the following description by executing the client software 40. 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.

[0033] <Issue server configuration> The issuing server 1 is a server that performs processes related to issuing a DID and generating a key pair associated with the DID. A key pair is a pair of a private key and a public key. Details of the DID will be described 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.

[0034] 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.

[0035] 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 ROM (Read Only Memory) 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 realizing at least a part of the functions of the issuing server 1 shown as a block in FIG. 4.

[0036] 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 identification information management method.

[0037] The issuing server 1 includes the following functional blocks as shown in Fig. 4: 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, the registry registration unit F2, the type identification unit F3, and the 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.

[0038] <Service server configuration> 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 for providing the service.

[0039] As shown in FIG. 5, the service server 2 includes a message receiving unit G1, a verification unit G2, and a data registration unit G3 as functional blocks. 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 transmitted from the user device 4 using an issued DID to the blockchain. The message here may be rephrased as a request, a transaction, or service data. The operation of each functional block will be described later with reference to FIG. 9.

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

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

[0042] 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. The DID is an identifier having a format defined by the World Wide Web Consortium (W3C). As shown in FIG. 7, the 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 and the like follow. The DID method is a code that specifies the type of mechanism for operating the DID, in other words, the method of interpreting the identifier. The information of the DID method can be used by the service server 2 to specify the method of acquiring a document (a so-called DID document) indicating information associated with the DID. The DID method may be any method. The method-specific identifier is assigned a value that is unique within the method. An entity (DID subject) is uniquely determined by the combination of the method-specific identifier and the DID method. 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 the DID using any DID method. After step S102 is completed, the process proceeds to step S103.

[0043] In addition, 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.

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

[0045] Step S103 is a step in which the registry registration unit F2 performs preparation processing required for registering a DID and stores the DID and DID document in the registry 5. The preparation processing may include generating JSON-formatted data indicating the DID document. The preparation processing may also include transmitting the DID document to the client software 40 for content confirmation by the user, and signing the DID document using the private key generated in step S101.

[0046] A DID document may include, for example, a DID subject 61, a DID controller 62, a public key 63, a public key type 64, and a last update date 65, as shown in FIG. 8. The DID subject 61 indicates the owner of the DID (i.e., the user). The DID itself is stored in the DID subject 61. 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 with the change authority. The public key 63 is the public key generated in step S101. The public key type 64 indicates the type of the public key.

[0047] 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.

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

[0049] 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 be data indicating the type, specifications, or location of the secure storage 47 held by the user device 4. The device type data may be data indicating a combination of storage that the user device 4 can access. 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 the request to issue the DID. When step S104 is completed, the process proceeds to step S105.

[0050] Step S105 is a step in which the device registration unit F4 determines a storage destination of the private key according to the type of the user device 4. The storage destination of the private key is selected from various secure storages 47. For example, when 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 of the private key. When the requesting user device 4 is a device that runs on iOS, the device registration unit F4 designates an area protected by the Secure Enclave as the storage destination of the private key. Note that, when the requesting user device 4 does not hold a secure storage 47, the device registration unit F4 may designate a predetermined external storage as the storage destination. The predetermined 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 of the private key. When step S105 is completed, the process proceeds to step S106.

[0051] 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 separate 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.

[0052] 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 the public key may be stored in the normal storage 46 or in 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.

[0053] If the user device 4 does not have the storage destination of 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 of 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.

[0054] 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 having a certain level of security in the user device 4. This can reduce the risk of the private key being leaked.

[0055] <Service data / message registration process> Here, the operation of the user device 4 and the service server 2 for message transmission and reception will be described with reference to 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 transmit messages periodically. The conditions for transmitting the message may be designed as appropriate depending on the contents of the service. The descriptions of the message receiving unit G1, the verification unit G2, and the data registration unit G3 in the following description may be replaced with the service server 2 or its processor.

[0056] First, the user device 4 generates a message in step S201. The message includes data on 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, not the client software 40. Of course, the message may 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. When step S201 is completed, the processing proceeds to step S202.

[0057] 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.

[0058] The hash function used to create the digital signature may be SHA-256. Of course, the hash function may 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.

[0059] 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 a digital signature of the message.

[0060] Step S204 is a step in which 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.

[0061] 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 a message set transmitted from various types of user devices 4. When the message receiving unit G1 receives the message set, the process proceeds to step S206.

[0062] 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.

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

[0064] Step S208 is a step in which 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 checking against the hash function generated in step S207. In this disclosure, the hash value generated in step S208 is also referred to as a matching hash value. When step S208 is completed, the process proceeds to step S209.

[0065] Step S209 is a step in which the verification unit G2 judges 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 judges the message to be authentic. If the two hash values ​​do not match, the verification unit G2 judges the message to be fraudulent. If the verification unit G2 judges the message to be 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 judges the message to be authentic, in other words, if the two hash values ​​match, the verification unit G2 sends the received message to the data registration unit G3.

[0066] When the data registration unit G3 receives a message from the verification unit G2, it executes a process for registering 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).

[0067] The user device 4 may transmit the message set not only to the service server 2 but also to all other nodes forming the block chain. A plurality of 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 DB6.

[0068] According to the above configuration, the data related to the provision of the service can be recorded while ensuring authenticity using the mechanism of the blockchain. In addition, the private key used to verify the authenticity of the data is controlled by the issuing server 1 so as to be stored in the secure storage 47. This reduces the risk of the service being misused due to leakage of the private key, etc. In addition, since data verification or user authentication is performed on a DID basis, the servicer does not need to consider the type of the 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 is possible to standardize the authentication method for various user devices 4 while ensuring security.

[0069] <Modifications of Functional Layout> 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. 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.

[0070] The ID management system 100 may also include Encrypted Data Vaults (EDVs) that store additional data associated with the execution of a service. The EDVs may be constructed in the registry 5 or in the service DB 6. The additional data associated with the execution of a service may be information on the holder linked to the DID, a list of available services, and the like. The additional data related to a vehicle-specific service may include a vehicle identification number (VIN) and owner information.

[0071] In addition, the ID management system 100 may include a relay server that performs the creation of an electronic signature, etc. The relay server is a server that relays communication between a device in which the client software 40 cannot be installed and the service server 2. For convenience, in this disclosure, a device in which the client software 40 is not installed is referred to as a non-compatible device. The relay server itself holds a DID and a private key associated with the DID. The relay server authenticates a non-compatible 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 in which a digital signature formed by using its private key and its DID are attached to a message received from an authenticated non-compatible device, and transmit the message set to the service server 2. The relay server may also have a function of transferring data generated by the service server 2 or a smart contract to a non-compatible device.

[0072] <Example of our services> Here, the advantages of utilizing DID will be described by taking as an example a case where the ID management system 100 includes an LBS server 2a, which is a service server 2 that provides an 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 a coupon 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.

[0073] In the following description, the following is assumed. The owner of the user device 4 (i.e., the user) is a person who has the authority to use the coupon distribution service. In other words, 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 that 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.

[0074] 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 or a smartphone 4A. The LBS-BC 6a corresponds to the service DB 6.

[0075] In the situation illustrated in FIG. 11, the user device 4 generates a message set at a predetermined reporting interval while moving and transmits it to the LBS server 2a ((1) in the figure). The message set generated here is a data set including 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 including the location information of the user device 4, an identification number as a DID (i.e., a distributed identifier), and an electronic signature. The message set may not include 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.

[0076] 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). Upon obtaining the public key, the LBS server 2a uses the public key to verify the validity of the received message ((4) in the figure). The verification flow may be the same as steps S207 to S209.

[0077] 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 specific conditions, the smart contract SCa does not issue a coupon to the user.

[0078] 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 by 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 validity of the message by DID resolution. Processing related to coupon distribution, etc. may be executed by the smart contract SCa.

[0079] In addition, coupon distribution may also be performed on the LBS-BC61a (i.e., the blockchain). Coupon distribution may be a process of registering the fact that a user has a coupon as a transaction in 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 that can be obtained by DID resolution.

[0080] In the above configuration, when a user uses the coupon distribution service, the user only needs to transmit the identification number as the DID and the 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. In addition, the DID mechanism allows the user to control the information that he or she discloses to the servicer.

[0081] 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 in a specific area. This makes it possible to reduce the processing load of the LBS server 2a.

[0082] 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 a specific condition. This configuration makes it possible to reduce the data size of the LBS-BC 62a.

[0083] Although the above describes an aspect in which DIDs are used to verify received data in the service server 2, 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 and the user device 4. A service platform using the ID management system 100 can alleviate problems associated with the implementation of services that are expected to communicate with a variety of user devices 4.

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

[0085] [Technical thought 1] issuing, upon 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 indicative of a type of the device to identify a 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.

[0086] [Technical thought 2] The identification information management method according to technical idea 1, wherein the identifier is a distributed identifier including a string indicating a DID method and a DID method unique identifier.

[0087] [Technical thought 3] An identification information management method described in 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 in which data is stored without encryption.

[0088] [Technical thought 4] An identification information management method described in any one of technical ideas 1 to 3, which includes, if the device does not have the secure area, presenting a message to a user of the device encouraging the user to acquire the secure area.

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

[0090] [Technical Thought 6] A server for managing identification information, issuing, upon 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; obtaining data from the device indicative of a type of the device to identify a type of the device; Specifying a secure area in which to store the private key based on the identified type of the device; sending a signal to the device instructing the device to store the private key in the secure area; registering the identifier and the public key in a blockchain-based registry; A server that is configured to enforce the

[0091] [Technical Thought 7] The computer of the device used by the user accepting an identifier issuance request via an input device; transmitting a request signal to a server to request issuance of the identifier based on receipt of the request for issuance of the identifier; sending data to the server indicative of a type of the device; receiving, from the server, a private key associated with the identifier, and storing the private key in a storage area specified by the server.

[0092] [Technical Thought 8] The program according to Technical Idea 7 includes instructions for causing the computer to execute a process for displaying on a display a message prompting the user to obtain the storage area specified by the server if the storage area specified by the server is not available.

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

[0094] <Additional remarks (2)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowcharts and the order of execution of the processes can be changed as appropriate. The controls shown in each flowchart may be combined / executed in parallel to the extent that there is no contradiction. Expressions such as acquisition, determination, detection, generation, and calculation may be used interchangeably. An apparatus acquiring certain data also includes the apparatus generating the data based on a signal input from another apparatus / sensor. The apparatus, system, and method thereof described in this disclosure may be realized by a dedicated computer comprising a processor programmed to execute one or more functions embodied by a computer program. The apparatus and method described in this disclosure may be realized using a dedicated hardware logic circuit. The apparatus and method described in this disclosure may be realized by one or more dedicated computers configured by a combination of a processor that executes a computer program and one or more hardware logic circuits. The processor may be any computing core such as a CPU, MPU, GPU, DFP (Data Flow Processor), etc. Some or all of the functions of the processor 11 may be realized using any of a system-on-chip (SoC), an integrated circuit (IC), and a field-programmable gate array (FPGA). The computer program includes instructions to be executed by a computer. The computer program may be stored in 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. [Explanation of symbols]

[0095] 1 issuing server, 2 service server, 3 node, 4 user device, 5 registry, 6 service DB, 11 processor, 44 processor, 46 normal storage (normal area), 47 secure storage (secure area)

Claims

1. issuing, upon 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 indicative of a type of the device to identify a 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. 2. 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 that 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. receiving from the device a data set including a message, a signature value generated from the message and the private key, and the identifier; obtaining the public key associated with the identifier from the registry based on the identifier included in the data set; verifying the authenticity of the signature value using the public key; The method of claim 1 , further comprising: receiving the signature value as being valid and executing a process corresponding to the message.

6. A server for managing identification information, issuing, upon 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; obtaining data from the device indicative of a type of the device to identify a type of the device; Specifying a secure area in which to store the private key based on the identified type of the device; sending a signal to the device instructing the device to store the private key in the secure area; registering the identifier and the public key in a blockchain-based registry; A server that is configured to enforce the

7. The computer of the device used by the user accepting an identifier issuance request via an input device; transmitting a request signal to a server to request issuance of the identifier based on receipt of the request for issuance of the identifier; sending data to the server indicative of a type of the device; receiving, from the server, a private key associated with the identifier, and storing the private key in a storage area specified by the server.

Images