Vehicle-side device, user terminal, and data guarantee method

Abstract

The present invention comprises: a vehicle-related information acquisition unit (111) that acquires, from a vehicle, vehicle-related information including vehicle information; a vehicle-related information storage unit (113) that stores the acquired vehicle-related information; a falsification presence / absence verification unit (114) that verifies the presence or absence of falsification of the stored vehicle-related information; and a data output unit (116) that enables verification of at least a vehicle-side signature, which is a signature using a secret key of a vehicle DID, by imparting, to the vehicle-related information, the vehicle-side signature and a verification result for the presence or absence of falsification from the falsification presence / absence verification unit (114), and that, in a case where the verification result is no falsification, registers the vehicle-related information on a DLT network, and directly or indirectly outputs the vehicle-related information to a terminal of a guarantee institution issuing verification of the vehicle-related information.

Description

Vehicle-side device, user terminal, and data assurance method CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-101463 filed in Japan on June 24, 2024, the contents of which are incorporated by reference in their entirety.

[0002] The present disclosure relates to a vehicle-side device, a user terminal, and a data assurance method.

[0003] Decentralized identity (DID), proposed by the World Wide Web Consortium, is a well-known technology for managing digital identities. DID attempts to distribute digital identities using a distributed ledger system such as a blockchain, allowing users to manage their own IDs. A DID is known as a key element of DID.

[0004] For example, Patent Document 1 discloses a method for authenticating a user attempting to log in to a platform using a DID. Patent Document 1 describes that, based on a target user's DID, a DID document associated with the target user's DID is obtained from a blockchain network, the target user's public key is obtained from the DID document, the target user's public key is used to verify the user signature, and it is verified whether the target user is the true owner of the target user's DID, thereby preventing theft or counterfeiting of digital IDs.

[0005] It is also known that by linking verifiable credentials (VC) to a DID, it is possible to prove that the VC is owned by an individual linked to the DID.

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

[0007] Using distributed ID technology, it is conceivable that a vehicle may provide its own vehicle information to a service provider to receive some kind of vehicle service. In this case, by using a VC that includes vehicle information and is linked to the vehicle's DID, it is conceivable that it would be possible to prove that the VC was issued to an entity corresponding to the DID linked to the VC. However, although the VC makes it possible to prove that it was issued to an entity corresponding to the DID linked to the VC, it does not guarantee the authenticity of the vehicle information contained therein. Therefore, even if a service provider receives a VC that includes vehicle information, it has been difficult to provide vehicle services assuming that the vehicle information is correct.

[0008] One object of this disclosure is to provide a vehicle-side device, a user terminal, and a data assurance method that make it easier for a service provider to provide vehicle services by assuming that the vehicle information is correct, even when a VC containing vehicle information is sent to the service provider that provides vehicle services using the vehicle information.

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

[0010] In order to achieve the above object, the vehicle-side device of the present disclosure utilizes distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network, which is a network of nodes on the distributed ledger system. The vehicle-side device is used in a vehicle and can be used in a distributed ID system, and includes a vehicle-side information acquisition unit that acquires vehicle information from the vehicle, which is information about the vehicle, a vehicle-side storage unit that stores the vehicle information acquired by the vehicle-side information acquisition unit, and a storage unit that stores the vehicle information stored in the vehicle-side storage unit. The system is equipped with a tampering verification unit that verifies whether the vehicle information has been tampered with, and a data output unit that assigns to the vehicle information a vehicle-side signature, which is a signature using the private key of the vehicle DID, which is the vehicle's distributed identifier, and the verification result of whether the vehicle information stored in the vehicle-side storage unit has been tampered with by the tampering verification unit, and if at least the vehicle-side signature can be verified and the verification result shows no tampering, registers the vehicle information in the distributed ledger network and outputs the vehicle information directly or indirectly to a guarantee agency terminal, which is a terminal of the guarantee agency that issues a VC for the vehicle information.

[0011] In order to achieve the above object, the data assurance method of the present disclosure is a data assurance method that can be used in a distributed ID system, which uses distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network, which is a network of nodes on the distributed ledger system. The data assurance method includes a vehicle-side information acquisition step of acquiring vehicle information from a vehicle, which is information about the vehicle, a vehicle-side storage step of storing the vehicle information acquired in the vehicle-side information acquisition step, and a vehicle-side storage step of storing the vehicle information acquired in the vehicle-side information acquisition step. and a data output process of attaching to the vehicle information a vehicle-side signature, which is a signature using the private key of the vehicle DID, which is the vehicle's distributed identifier, and the verification result of the tampering verification process for the vehicle information stored in the vehicle-side storage process, and registering the vehicle information in the distributed ledger network and issuing a VC for the vehicle information, directly or indirectly outputting the vehicle information to a guarantee agency terminal, which is a terminal of a guarantee agency that issues a VC for the vehicle information, if at least the vehicle-side signature can be verified and the verification result shows no tampering.

[0012] According to the above configuration, vehicle information bearing a vehicle-side signature, which is a signature based on the private key of the vehicle DID, and the verification result of whether the vehicle information stored in the vehicle has been tampered with is output directly or indirectly from the vehicle to a guarantee agency terminal. If the guarantee agency terminal can verify at least the vehicle-side signature and the verification result indicates no tampering, it registers the vehicle information in a distributed ledger network and issues a VC for the vehicle information. Therefore, a VC for the vehicle information is issued only if the vehicle information stored in the vehicle has not been tampered with and the vehicle information output by the vehicle has not been rewritten. Furthermore, since the VC is issued after the vehicle information is registered in the distributed ledger network, it is also easy to verify whether the vehicle information included in the issued VC has been tampered with. Therefore, it is possible to provide a VC with guaranteed authenticity of the vehicle information to a service provider that provides vehicle services using the vehicle information. As a result, even when a VC containing vehicle information is sent to a service provider that provides vehicle services using the vehicle information, the service provider can more easily provide vehicle services assuming the vehicle information is correct.

[0013] In order to achieve the above-mentioned object, the user terminal of the present disclosure is a user terminal carried by a user that can be used in a distributed ID system, and that uses distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network, which is a network of nodes on the distributed ledger system. The user terminal includes: an output request unit that makes an output request to a vehicle, requesting that the vehicle output vehicle information, which is information about the vehicle that has been acquired and stored in the vehicle; a terminal-side information acquisition unit that acquires, in response to the output request from the output request unit, vehicle information that has been appended with a vehicle-side signature, which is a signature made with the private key of the vehicle DID, which is the vehicle's distributed identifier, and a verification result, which has been verified by the vehicle to determine whether the vehicle information stored in the vehicle has been tampered with; and a relay unit that also appends a user terminal-side signature, which is a signature made with the private key of the user terminal DID, which is the user terminal's distributed identifier, to the vehicle information acquired by the terminal-side information acquisition unit and that has been appended with the vehicle-side signature and verification result, and registers the vehicle information in the distributed ledger network and transmits the vehicle information to a guarantee agency terminal that is a terminal of a guarantee agency that issues a VC for the vehicle information.

[0014] According to the above configuration, the user terminal indirectly outputs vehicle information from the vehicle to the guarantee agency terminal, the vehicle information being accompanied by a vehicle-side signature, which is a signature based on the private key of the vehicle DID, a user terminal-side signature, which is a signature based on the private key of the user terminal DID, and a verification result of whether the vehicle information stored in the vehicle has been tampered with. If the guarantee agency terminal can verify the vehicle-side signature and the user terminal-side signature and the verification result indicates no tampering, it registers the vehicle information in the distributed ledger network and issues a VC for the vehicle information. Therefore, a VC for the vehicle information is issued only if the vehicle information stored in the vehicle has not been tampered with and if neither the vehicle information output by the vehicle nor the vehicle information relayed by the user terminal has been rewritten. Furthermore, since the VC is issued after the vehicle information is registered in the distributed ledger network, it is also easy to verify whether the vehicle information included in the issued VC has been tampered with. As a result, even when a VC containing vehicle information is sent to a service provider that provides vehicle services using the vehicle information, the service provider can more easily provide vehicle services assuming the vehicle information is correct. Therefore, it becomes possible to provide a VC with the authenticity of the vehicle information to a service provider that uses the vehicle information to provide a vehicle service. As a result, even when a VC including the vehicle information is sent to a service provider that uses the vehicle information to provide a vehicle service, the service provider can more easily provide the vehicle service assuming that the vehicle information is correct.

[0015] FIG. 1 is a diagram showing an example of a schematic configuration of an authentication system in embodiment 1. FIG. 2 is a diagram showing an example of a schematic configuration of a vehicle unit in embodiment 1. FIG. 3 is a diagram showing an example of a schematic configuration of a user terminal. FIG. 4 is a diagram showing an example of a schematic configuration of a guarantee agency terminal in embodiment 1. FIG. 5 is a sequence diagram for explaining an example of data flow in the authentication system. FIG. 6 is a diagram showing an example of a schematic configuration of an authentication system in embodiment 2. FIG. 7 is a diagram showing an example of a schematic configuration of a vehicle unit in embodiment 2. FIG. 8 is a diagram showing an example of a schematic configuration of a guarantee agency terminal in embodiment 2.

[0016] A number of embodiments for the purpose of disclosure will be described with reference to the drawings. For the sake of convenience, parts having the same functions as parts shown in the drawings used in the previous explanations in the number of embodiments will be given the same reference numerals, and their description may be omitted. For parts given the same reference numerals, the explanations in other embodiments may be referred to.

[0017] (First Embodiment) <Overview of Authentication System 1> Hereinafter, a first embodiment of the present disclosure will be described with reference to the drawings. The authentication system 1 shown in Fig. 1 uses distributed ID technology and verifiable credentials (VC) for authentication. As shown in Fig. 1, the authentication system 1 includes a vehicle 10, a user terminal 20, a guarantee agency terminal 30, a service provider terminal 40, and a distributed ledger network (hereinafter referred to as DLT network) 50. The authentication system 1 corresponds to a distributed ID system.

[0018] Decentralized ID technology is a decentralized identity (ID) technology proposed by the World Wide Web Consortium (W3C). Decentralized ID technology is a technology that distributes and manages digital identities using a distributed ledger system such as a blockchain. In decentralized ID technology using VC, a certificate is used that provides a proof that guarantees the authenticity of the attribute information of an individual or other target. This certificate corresponds to the VC. A VC is also called a verifiable credential. In decentralized ID technology using VC, a decentralized identifier (hereinafter referred to as DID) assigned to each target is linked to the VC, making it possible to prove that the VC was issued to the target corresponding to the DID linked to the VC. Targets that have DIDs are not limited to individuals, but also include objects such as cars.

[0019] In distributed ID technology, a DID is associated one-to-one with a DID document that holds data related to the DID. Distributed ID technology has a mechanism for obtaining a DID document by resolving the DID. The DID is generated on the target side, but when the DID is registered, the DID and DID document are stored in the registry of the DLT network 50. Note that, to avoid overloading the capacity of the registry of the DLT network 50, the registry may store a link to the DID document. The following explanation uses an example in which the registry stores a link to the DID document. Registering a DID can utilize existing DID registration architecture. As an example, a DID can be registered in the DLT network 50 using a mechanism such as the Client-managed Secret Mode proposed by the Decentralized Identity Foundation (DIF).

[0020] A DID is an identifier having a format defined by the W3C. A DID includes a scheme, a DID method, and a method-specific identifier. Each element is separated by a colon. A scheme is a prefix indicating that a DID method, etc., follows. A DID method is a code that specifies the type of mechanism that operates the DID, in other words, how to interpret the identifier. DID method information can be used to identify how to obtain a DID document that indicates information associated with the DID. A DID method defines a registry, etc., where the DID is registered. A DID method may be any method. A method-specific identifier is assigned a unique value within the method. A DID subject is uniquely determined by the combination of the method-specific identifier and the DID method. A method-specific identifier may be generated differently for each DID method. A method-specific identifier may be generated using any method.

[0021] A DID document is serialized in JSON or JSON-LD format. A DID document includes a DID subject, DID controller, public key, public key type, and last update date. The DID subject indicates the entity that has the DID. The DID subject stores the DID itself. The DID controller represents the entity that has been granted permission to make changes to the DID document. The DID controller may be represented by the DID of the entity that has the permission to make changes. The public key is a verification key for authenticating the DID subject. The public key is paired with a private key. The public and private key pair can be generated using any method, such as RSA. The public key type indicates the type of public key. A DID document can be stored in a registry in encrypted format so that it can be restored using a predetermined function called a resolver. The resolver can vary depending on the DID method. Using a resolver to obtain information contained in a DID document associated with a DID is also called DID resolving. Note that obtaining a public key associated with a DID may also be included in one form of DID resolution.

[0022] In this embodiment, the vehicle 10, the user terminal 20, and the service provider terminal 40 are assumed to have a DID. Hereinafter, the DID of the vehicle 10 will be referred to as a vehicle DID. Hereinafter, the DID of the user terminal 20 will be referred to as a user terminal DID. Hereinafter, the DID of the service provider terminal 40 will be referred to as a provider terminal DID. Hereinafter, the description will continue assuming that the vehicle DID, user terminal DID, and provider terminal DID have all been registered in the DLT network 50. In other words, the registry of the DLT network 50 stores the vehicle DID, user terminal DID, and provider terminal DID, as well as links to DID documents associated with each DID.

[0023] In this embodiment, the vehicle 10 is owned by a user Us of the user terminal 20. The vehicle 10 has a vehicle DID as described above. The vehicle 10 includes a vehicle unit 100. Details of the vehicle unit 100 will be described later.

[0024] The user terminal 20 is a terminal carried by a user Us. The owner of the user terminal 20 is the user Us. Examples of the user terminal 20 include a multi-function mobile phone, a tablet terminal, and a notebook PC. The following explanation will be given using an example in which the user terminal 20 is a multi-function mobile phone. The user terminal 20 is mainly composed of a computer including, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the user terminal 20 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit. The configuration of the user terminal 20 will be described in detail later.

[0025] The guarantee agency terminal 30 is a terminal of a guarantee agency that guarantees the authenticity of the vehicle information output from the vehicle 10. Examples of guarantee agencies include the OEM (Original Equipment Manufacturer) that manufactures the vehicle 10, a supplier that sells the vehicle 10, and a third-party guarantee agency that is not involved in the manufacture and sale of the vehicle 10. The guarantee agency terminal 30 may be, for example, a server connected to a network. The guarantee agency terminal 30 is mainly composed of a computer that includes, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the guarantee agency terminal 30 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit. The configuration of the guarantee agency terminal 30 will be described in detail later.

[0026] The service provider terminal 40 is a terminal of a service provider that provides information about vehicle services (hereinafter, service-related information). As described above, the service provider terminal 40 has a provider terminal DID. The service provider terminal 40 may be, for example, a server connected to a network. An example of a service provider is a used car appraisal service provider that appraise the selling price of used cars. In this case, the service-related information is the appraisal result. The appraisal result may include, in addition to the appraised selling price, appraisal items and evaluation results for each appraisal item. The following explanation will be continued using an example in which the service provider terminal 40 is a server of a used car appraisal service provider.

[0027] The DLT network 50 is a network of nodes on a distributed ledger system. The nodes of the DLT network 50 are computers such as servers. As an example, the DLT network 50 may be a blockchain network. The DLT network 50 includes the above-mentioned registry. The registry corresponds to a Verifiable Data Registry (VDR). The registry may be logical storage. The nodes of the DLT network 50 are mainly composed of computers equipped with, for example, a processor, volatile memory, non-volatile memory, I / O, and buses connecting these. In the nodes of the DLT network 50, at least some of the functions performed by a processor may be performed by a circuit. The circuit referred to here is a hardware circuit.

[0028] <General Configuration of Vehicle Unit 100> Next, the general configuration of the vehicle unit 100 will be described with reference to Fig. 2. As shown in Fig. 2, the vehicle unit 100 includes an on-board ECU 101, a near field communication module (hereinafter referred to as NFCM) 102, and a wide area communication module (hereinafter referred to as WFCM) 103.

[0029] The NFCM 102 is a communication module for performing short-range wireless communication. When a communication connection is established between the NFCM 102 and the user terminal 20, the NFCM 102 performs short-range wireless communication with the user terminal 20. The short-range wireless communication is, for example, wireless communication with a maximum communication range of several tens of meters. For example, wireless communication compliant with Bluetooth (registered trademark) Low Energy may be used as the short-range wireless communication.

[0030] The WFCM 103 transmits and receives information to and from a network external to the vehicle via wireless communication. That is, it performs wide-area communication. The WFCM 103 communicates with the DLT network 50.

[0031] The on-board ECU 101 is an electronic control device used in the vehicle 10. The on-board ECU 101 is mainly composed of a computer including, for example, a processor, a volatile memory, a non-volatile memory, an I / O, and a bus connecting these. Note that the on-board ECU 101 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit. The on-board ECU 101 corresponds to a vehicle-side device. The configuration of the on-board ECU 101 will be described below.

[0032] Here, the schematic configuration of the on-board ECU 101 will be described using FIG. 2 . As shown in FIG. 2 , the on-board ECU 101 includes functional blocks, such as a vehicle-related information acquisition unit 111, a storage processing unit 112, a vehicle-related information storage unit 113, a tampering verification unit 114, a request reception unit 115, and a data output unit 116. The execution of processing by a computer of each functional block of the on-board ECU 101 corresponds to the execution of a data assurance method. The on-board ECU 101 may implement all of its functions by software execution by a processor. The on-board ECU 101 may also implement some or all of its functions in hardware using one or more circuits, etc. The on-board ECU 101 may also implement some or all of its functional blocks by a combination of software execution by a processor and hardware circuits.

[0033] The vehicle-related information acquisition unit 111 acquires vehicle-related information including at least vehicle information (hereinafter referred to as vehicle information). The vehicle-related information acquisition unit 111 corresponds to a vehicle-side information acquisition unit. The processing in the vehicle-related information acquisition unit 111 corresponds to a vehicle-side information acquisition step. The vehicle-related information acquisition unit 111 may be configured to acquire vehicle information such as the vehicle identification number, model year, grade, and vehicle name that is stored in advance in a non-volatile memory of the vehicle, for example. The vehicle-related information acquisition unit 111 may be configured to acquire the mileage information, which is part of the vehicle information, from a meter ECU, for example. The vehicle-related information acquisition unit 111 may be configured to acquire the collision detection result, which is part of the vehicle information, from an ECU related to collision detection, such as an airbag ECU, for example. The vehicle-related information acquisition unit 111 may be configured to acquire the location information history of a GNSS (Global Navigation Satellite System) receiver, which is part of the vehicle information, from a navigation device, for example. GPS is an example of a GNSS. In addition to the vehicle information, the vehicle-related information acquisition unit 111 may also acquire personal information of the user Us who is the owner of the vehicle 10 as the vehicle-related information. The personal information acquired by the vehicle-related information acquisition unit 111 is personal information that can be acquired from the vehicle 10. Examples of personal information that can be acquired from the vehicle 10 include credit card information, address, etc. The vehicle-related information acquisition unit 111 may be configured to acquire credit card information, for example, from an ETC (registered trademark) in-vehicle unit. The vehicle-related information acquisition unit 111 may be configured to acquire address information, for example, from a navigation device. The vehicle-related information acquisition unit 111 may be configured to sequentially acquire information that changes over time, such as mileage.

[0034] The storage processing unit 112 stores the vehicle-related information acquired by the vehicle-related information acquisition unit 111 in the vehicle-related information storage unit 113. The storage processing unit 112 stores this vehicle-related information in the vehicle-related information storage unit 113 in a state that is difficult to tamper with and allows for verification of whether or not tampering has occurred. The non-volatile memory of the in-vehicle ECU 101 may be used as the vehicle-related information storage unit 113. The vehicle-related information storage unit 113 corresponds to a vehicle-side storage unit. The processing in the storage processing unit 112 corresponds to a vehicle-side storage step. The storage processing unit 112 may store the vehicle-related information in the vehicle-related information storage unit 113 in the same manner as the logger processing described in Japanese Patent No. 7176488. The storage processing unit 112 converts the vehicle-related information acquired by the vehicle-related information acquisition unit 111 into a hash chain-like data structure using a hash function, and stores the converted information in the vehicle-related information storage unit 113. A hash function such as SH-256 may be used as the hash function.

[0035] The storage processing unit 112 creates one block based on a predetermined number or capacity of vehicle-related information. Then, the data of this block is input to a hash function, and the resulting hash value is included in the next block, thereby generating a blockchain consisting of a large number of blocks linked in a linear chain. The storage processing unit 112 calculates a hash value to be stored as main data in each block based on the specified number or capacity of vehicle-related information acquired by the vehicle-related information acquisition unit 111. The storage processing unit 112 stores the vehicle-related information acquired by the vehicle-related information acquisition unit 111 in a specified file path within the memory area of ​​the vehicle-related information storage unit 113. The storage processing unit 112 stores the generated blockchain data in the vehicle-related information storage unit 113. The blockchain generated by the storage processing unit 112 is hereinafter referred to as an in-vehicle blockchain. The storage processing unit 112 also stores linking information linking a specific block to the file path of the vehicle-related information included in that specific block in the vehicle-related information storage unit 113.

[0036] The storage processing unit 112 updates the block hash value and block number stored in the secure area of ​​the in-vehicle ECU 101. Access to the secure area is possible by executing a predetermined command that enables access to the secure area, such as a secure monitor call. The block hash value is a hash value based on the current final block of the in-vehicle blockchain. The block hash value is a 256-bit value (character string) obtained as the output by an arithmetic process in which all data in the final block is input into a hash function. The block number is a unique value assigned to the final block and indicates the number of the current final block in the in-vehicle blockchain when the initial block is set to "0." The block number also indicates the number of blocks currently linked to the in-vehicle blockchain. The storage processing unit 112 updates the block hash value and block number in the secure area each time a new block is generated and its hash value is calculated. When vehicle-related information is sequentially acquired by the vehicle-related information acquisition unit 111, the storage processing unit 112 sequentially performs the above-mentioned process. The storage processing unit 112 is not limited to the example of this embodiment, and the vehicle-related information may be stored in the vehicle-related information storage unit 113 by any other method as long as the storage method allows verification of whether or not the information has been tampered with.

[0037] The tampering verification unit 114 verifies whether the vehicle-related information stored in the vehicle-related information storage unit 113 has been tampered with. The processing by this tampering verification unit 114 corresponds to a tampering verification step. For example, the tampering verification unit 114 may perform this verification when the vehicle-related information stored in the vehicle-related information storage unit 113 is output from the data output unit 116, which will be described later. For example, the tampering verification unit 114 may perform this verification when an output request is received by the request receiving unit 115, which will be described later. The tampering verification unit 114 may verify whether the vehicle-related information stored in the vehicle-related information storage unit 113 has been tampered with, for example, as follows. The result of the verification of whether the vehicle-related information has been tampered with will be referred to hereinafter as a tampering verification result.

[0038] The tampering verification unit 114 may verify whether the vehicle-related information stored in the vehicle-related information storage unit 113 has been tampered with using the block hash stored in the secure area. The tampering verification unit 114 identifies a block number linked to the file path of the vehicle-related information requested to be output, based on the linking information. The tampering verification unit 114 recalculates hash values ​​for each of the identified blocks (hereinafter referred to as "specific blocks") and blocks newer than the specific blocks, and verifies consistency with the in-vehicle blockchain. The tampering verification unit 114 verifies whether the vehicle-related information has been tampered with based on whether the hash value based on the recalculated final block matches the block hash value stored in the secure area. If the hash value of the recalculated final block matches the block hash value, the tampering verification unit 114 verifies that the vehicle-related information has not been tampered with. On the other hand, if the recalculated hash value of the final block does not match the block hash value, it is verified that there is a possibility that the vehicle-related information has been tampered with.

[0039] The request receiving unit 115 receives an output request from the user terminal 20, which requests output of vehicle-related information including at least vehicle information. The output request from the user terminal 20 may be configured to include the user terminal DID of the requesting user terminal 20 and a signature assigned using the private key of the user terminal 20. In this case, the private key of the user terminal 20 may be stored in a secure area of ​​the user terminal 20. Hereinafter, this signature assigned using the private key of the user terminal 20 will be referred to as a user terminal-side signature.

[0040] The request receiving unit 115 may receive an output request transmitted via short-range wireless communication, for example, via the NFCM 102. Note that the request receiving unit 115 may also be configured to receive an output request made by means other than short-range wireless communication. As an example, the output request may be made by presenting a two-dimensional code such as a QR code (registered trademark). In this case, a two-dimensional code indicating the content of the output request is generated in the user terminal 20 and displayed, for example, on a display of the user terminal 20. The request receiving unit 115 may receive the output request read by a reading device that reads this two-dimensional code. In this case, the vehicle unit 100 may include a two-dimensional code reading device.

[0041] The data output unit 116 outputs the vehicle-related information stored in the vehicle-related information storage unit 113. When the request receiving unit 115 receives an output request, the data output unit 116 outputs the vehicle-related information stored in the vehicle-related information storage unit 113. The data output unit 116 outputs the vehicle-related information with a vehicle-side signature and a tampering verification result attached to it. The vehicle-side signature is a signature using the private key of the vehicle DID of the vehicle 10. As described above, the tampering verification result is the verification result of whether the vehicle-related information has been tampered with by the tampering verification unit 114. The data output unit 116 directly or indirectly outputs the vehicle-related information with the vehicle-side signature and the tampering verification result attached to it to the warranty agency terminal 30. In this embodiment, a case will be described in which the data output unit 116 indirectly outputs the vehicle-related information to the warranty agency terminal 30. The data output unit 116 outputs the vehicle-related information to the user terminal 20, thereby indirectly outputting the vehicle-related information to the warranty agency terminal 30 via the user terminal 20. This processing by the data output unit 116 corresponds to a data output step. The data output unit 116 may also add the vehicle DID of the vehicle 10 to the vehicle-related information before outputting it. In the following, the explanation will be continued assuming that the data output unit 116 also adds the vehicle DID of the vehicle 10 to the vehicle-related information before outputting it.

[0042] The data output unit 116 may be configured to output vehicle-related information when it is authenticated that the user is authorized to output data from the vehicle 10 (hereinafter referred to as an authorized user). If the data output unit 116 cannot authenticate that the user is an authorized user, it does not need to output vehicle-related information. When the above configuration is adopted, the on-board ECU 101 may be configured to include an authentication unit that performs this authentication. When the above configuration is adopted, the output request from the user terminal 20 may include the user terminal DID and user terminal side signature described above.

[0043] Authentication may be performed, for example, as follows: The authentication unit transmits a request for a DID document (hereinafter referred to as a document request) linked to the user terminal DID included in the output request from the user terminal 20 to the DLT network 50. This DID document is a DID document that includes a public key for authenticating the user Us, which is linked to the user terminal DID of the user terminal 20. The document request includes the user terminal DID included in the output request. The document request can be transmitted to the DLT network 50 via the WFCM 103. The authentication unit then acquires the DID document transmitted from the DLT network 50 via the WFCM 103. The authentication unit extracts the public key included in the acquired DID document. The authentication unit decrypts the user terminal side signature included in the output request from the user terminal 20 with this public key, and if decryption is successful, verifies that the user terminal 20 belongs to the user Us. Next, if the user Us is registered as an authorized user in the vehicle 10, it is sufficient to authenticate that the user terminal 20 belongs to the authorized user. Registration of the authorized user may be achieved, for example, by storing the user terminal DID in advance in the non-volatile memory of the vehicle 10. Alternatively, this may be achieved by including the vehicle DID of the vehicle 10 as an object that the DID controller has the authority to change among the user terminal DIDs included in the output request. Note that by registering the public key of the user terminal DID of the authorized user in the on-board ECU 101 in advance, authentication may be possible without an online connection to the DLT network 50.

[0044] <Overall Configuration of User Terminal 20> Next, the overall configuration of the user terminal 20 will be described with reference to Fig. 3. As shown in Fig. 3, the user terminal 20 includes a control unit 200, a near field communication module (hereinafter referred to as NFCM) 201, and a wide area communication module (hereinafter referred to as WFCM) 202.

[0045] The NFCM 201 is a communication module for performing short-range wireless communication. When a communication connection is established between the NFCM 102 of the vehicle 10, the NFCM 201 performs the above-mentioned short-range wireless communication with the NFCM 102. The WFCM 202 performs the above-mentioned wide-area communication. The WFCM 202 communicates with the guarantee agency terminal 30. The WFCM 202 communicates with the service provider terminal 40. The WFCM 202 communicates with the DLT network 50.

[0046] The control unit 200 is mainly composed of a computer including, for example, a processor, volatile memory, non-volatile memory, I / O, and a bus connecting these. Note that the control unit 200 may have a circuit that performs at least some of the functions of a processor. The circuit here refers to a hardware circuit.

[0047] As shown in FIG. 3 , the control unit 200 includes functional blocks, such as an output request unit 211, a vehicle-related information acquisition unit 212, a relay unit 213, a first VC acquisition unit 214, a first VC storage unit 215, a VC transmission unit 216, a second VC acquisition unit 217, and a second VC storage unit 218. The execution of the processing of each functional block of the control unit 200 by a computer also corresponds to the execution of a data assurance method. The control unit 200 may implement all of its functions by software execution by a processor. Some or all of its functions may be configured as hardware using one or more circuits, etc. Some or all of its functional blocks may be implemented by a combination of software execution by a processor and hardware circuits.

[0048] The output request unit 211 makes an output request to the vehicle 10, requesting that the vehicle 10 output vehicle-related information acquired and stored in the vehicle 10. The output request unit 211 may attach the user terminal DID and user terminal side signature of the user terminal 20 to the output request. The output request can be made by various means. For example, the output request may be made by short-range wireless communication via the NFCM 201, as described above. For example, the output request may be made by presenting a two-dimensional code, as described above. The processing by the output request unit 211 corresponds to an output request step.

[0049] The vehicle-related information acquisition unit 212 acquires vehicle-related information output from the vehicle 10 in response to an output request from the output request unit 211. The vehicle-related information acquired by the vehicle-related information acquisition unit 212 includes the vehicle DID, the vehicle-side signature, and the tampering verification result. The vehicle-related information acquisition unit 212 may acquire the vehicle-related information output from the vehicle 10 via the NFCM 201. The vehicle-related information acquisition unit 212 corresponds to a terminal-side information acquisition unit. Furthermore, the processing by the vehicle-related information acquisition unit 212 corresponds to a terminal-side information acquisition step. The vehicle-related information acquisition unit 212 may be configured to acquire vehicle-related information output from the vehicle 10 when the above-mentioned authentication is established in the vehicle 10. In this way, the vehicle-related information is not output when authentication is not established, making it possible to prevent user terminals 20 other than the authorized user Us of the vehicle 10 from acquiring the vehicle-related information from the vehicle 10.

[0050] The relay unit 213 also assigns the user terminal signature of the user terminal 20 to the vehicle-related information acquired by the vehicle-related information acquisition unit 212, to which the vehicle DID, vehicle signature, and tampering verification result have been assigned, and transmits the vehicle-related information to the warranty agency terminal 30. The processing by the relay unit 213 corresponds to a relay step. In the example of this embodiment, it is assumed that the vehicle DID of the vehicle 10 is also assigned to this vehicle-related information. The relay unit 213 may also assign the user terminal DID of the user terminal 20 to the vehicle-related information and output it. In the following, the explanation will be continued assuming that the relay unit 213 also assigns the user terminal DID of the user terminal 20 to the vehicle-related information and outputs it. If the vehicle-related information satisfies predetermined conditions, the warranty agency terminal 30 that has received the vehicle-related information registers the vehicle-related information in the DLT network 50 and issues a VC for the vehicle-related information. In this embodiment, the predetermined condition is that the signature of the vehicle DID and the signature of the user terminal DID can be verified, and the tampering verification result indicates no tampering. The processing at the guarantee agency terminal 30 will be described in detail later.

[0051] The VC of the vehicle-related information is issued when the vehicle-related information stored in the vehicle 10 has not been tampered with and when neither the vehicle-related information output by the vehicle 10 nor the vehicle-related information relayed by the user terminal 20 has been rewritten. Furthermore, since the vehicle-related information is registered in the DLT network 50 when the VC is issued, it is easy to verify whether the vehicle-related information included in the issued VC has been tampered with. Therefore, with the above configuration, even when a VC including vehicle-related information is transmitted to a service provider that provides vehicle services using the vehicle-related information, the service provider can easily provide vehicle services assuming that the vehicle-related information is correct. Therefore, it is possible to provide a VC with guaranteed authenticity of the vehicle-related information to a service provider that provides vehicle services using the vehicle-related information. As a result, even when a VC including vehicle-related information is transmitted to a service provider that provides vehicle services using the vehicle-related information, the service provider can easily provide vehicle services assuming that the vehicle-related information is correct.

[0052] The first VC acquisition unit 214 acquires the vehicle-related information VC transmitted from the warranty agency terminal 30 in response to the transmission of vehicle-related information to the warranty agency terminal 30 by the relay unit 213. As described above, the warranty agency terminal 30 that has received the vehicle-related information registers the vehicle-related information in the DLT network 50 and issues a VC for the vehicle-related information if predetermined conditions are satisfied. The first VC acquisition unit 214 acquires the VC for this vehicle-related information that is issued by the warranty agency terminal 30 if predetermined conditions are satisfied in response to the transmission of the vehicle-related information.

[0053] The first VC storage unit 215 stores the vehicle-related information VC acquired by the first VC acquisition unit 214. The first VC storage unit 215 may be a non-volatile memory of the user terminal 20. Preferably, the vehicle-related information VC is not transmitted from the user terminal 20 to the vehicle 10 and is not stored in the vehicle 10. This prevents personal information of the user Us from leaking from the vehicle-related information VC stored in the vehicle 10, even if the owner of the vehicle 10 is changed from the user Us. Furthermore, storing the vehicle-related information VC in the user terminal 20 provides the following advantages: The user Us can use the user terminal 20 to receive services from the service provider terminal 40 using the vehicle-related information VC at any time they like. The user Us can receive these services using the user terminal 20 even when the vehicle 10 is not nearby. This further improves convenience for the user Us.

[0054] The VC transmission unit 216 transmits the vehicle-related information VC stored in the first VC storage unit 215 to the service provider terminal 40. For example, when the user terminal 20 receives an operation input from the user Us to use a used car appraisal service by the service provider terminal 40, the user terminal 20 may transmit the vehicle-related information VC to the service provider terminal 40. The VC transmission unit 216 may transmit the vehicle-related information VC to the service provider terminal 40 via the WFCM 202. Note that the VC transmission unit 216 may transmit the vehicle-related information VC in a format included in a VP (Verifiable Presentation).

[0055] The second VC acquisition unit 217 acquires service-related information VC transmitted from the service provider terminal 40 when the vehicle-related information VC transmitted from the VC transmission unit 216 can be verified by the DLT network 50. The service-related information VC is a VC including the service-related information and a proof for verification obtained from the DLT network 50 based on the service-related information provided by the service provider terminal 40 on the basis of the vehicle-related information included in the vehicle-related information VC. Note that being able to verify may be rephrased as "verification established." Not being able to verify may be rephrased as "verification not established."

[0056] When the service provider terminal 40 acquires the vehicle-related information VC transmitted from the user terminal 20, it transmits the vehicle-related information VC to the DLT network 50, causing the DLT network 50 to verify the vehicle-related information VC. The DLT network 50 performs verification using a proof included in the vehicle-related information VC. The verification may be performed, for example, as follows. The DLT network 50 generates a hash value from the vehicle-related information included in the vehicle-related information VC requested for verification, using a hash function managed in the DLT network 50 in association with the vehicle-related information VC. The verification may then be performed by determining whether the generated hash value matches a hash value corresponding to the proof of the vehicle-related information VC registered in the DLT network 50. The verification result of the vehicle-related information VC in the DLT network 50 is transmitted to the service provider terminal 40. If the verification result is successful, the service provider terminal 40 uses the vehicle-related information included in the vehicle-related information VC to generate service-related information to be provided based on the vehicle-related information. In the example of this embodiment, the service-related information is the appraisal result of the selling price of the vehicle 10. The service provider terminal 40 registers the generated service-related information in the DLT network 50. In this case, the service provider terminal 40 may register the service-related information by linking it to the provider terminal DID. After this registration, the DLT network 50 returns the service-related information VC, which is a VC linked to the provider terminal DID and includes the service-related information and a proof for verification, to the user terminal 20. Note that the service provider terminal 40 may transmit the service-related information VC in a format included in a VP. If the verification result is unsuccessful, the service provider terminal 40 does not generate service-related information based on the vehicle-related information.

[0057] The above-described processing in the service provider terminal 40 may be executed by a control unit of the service provider terminal 40. The control unit of the service provider terminal 40 is mainly composed of a computer including, for example, a processor, a volatile memory, a non-volatile memory, an I / O, and a bus connecting these. The control unit of the service provider terminal 40 may have a circuit that performs at least some of the functions performed by the processor. The circuit referred to here is a hardware circuit.

[0058] The second VC storage unit 218 stores the service-related information VC acquired by the second VC acquisition unit 217. The non-volatile memory of the user terminal 20 may be used as the second VC storage unit 218. Although the service-related information VC relates to services for the vehicle 10, it is not transmitted from the user terminal 20 to the vehicle 10 and is not stored in the vehicle 10. This allows the user terminal 20 to also store the service-related information VC, so that even if the owner of the vehicle 10 changes, it is possible to prevent personal information about the user Us contained in the service-related information VC from leaking from the vehicle 10. Furthermore, storing the service-related information VC in the user terminal 20 provides the following advantages: The user Us can receive services using the service-related information VC at any time using the user terminal 20. The user Us can receive these services using the user terminal 20 even when the vehicle 10 is not nearby. This also improves convenience for the user Us. An example of providing a service using the service-related information VC is buying a used car using the appraisal result of the selling price of the vehicle 10.

[0059] <General Configuration of Guarantee Agency Terminal 30> Next, the general configuration of the guarantee agency terminal 30 will be described with reference to Fig. 4. As shown in Fig. 4, the guarantee agency terminal 30 includes a control unit 300 and a wide area communication module (hereinafter referred to as WFCM) 301.

[0060] The WFCM 301 performs the wide area communication described above. The WFCM 301 communicates with the guarantee agency terminal 30. The WFCM 202 communicates with the user terminal 20. The WFCM 301 communicates with the DLT network 50.

[0061] The control unit 300 is mainly composed of a computer including, for example, a processor, a volatile memory, a non-volatile memory, an I / O, and a bus connecting these. Note that the control unit 300 may have a circuit that performs at least some of the functions of a processor. The circuit referred to here is a hardware circuit.

[0062] As shown in FIG. 4 , the control unit 300 includes functional blocks of a vehicle-related information acquisition unit 311, a document request unit 312, a document acquisition unit 313, a verification unit 314, a registration unit 315, a VC acquisition unit 316, and a VC transmission unit 317. The control unit 300 may realize all of the functions executed by the control unit 300 by executing software with a processor. The control unit 300 may also realize some or all of the functions executed by the control unit 300 as hardware using one or more circuits, etc. The control unit 300 may realize some or all of the functional blocks included in the control unit 200 by combining software execution with a processor and hardware circuits.

[0063] The vehicle-related information acquisition unit 311 acquires the vehicle-related information transmitted from the relay unit 213. The vehicle-related information acquisition unit 311 may acquire the vehicle-related information transmitted from the relay unit 213 via the WFCM 301. In the example of this embodiment, the vehicle-related information is assumed to be provided with a vehicle-side signature, a vehicle DID, a user terminal-side signature, a user terminal DID, and a tampering verification result.

[0064] The document request unit 312 requests DID documents linked to the vehicle DID and user terminal DID assigned to the vehicle-related information acquired by the vehicle-related information acquisition unit 311. Hereinafter, this request will be referred to as a document request. The document request unit 312 transmits the document request to the DLT network 50. The requested DID documents are a DID document linked to the vehicle DID and a DID document linked to the user terminal DID. The DID document linked to the vehicle DID includes a public key paired with the private key of the vehicle 10. This public key is a public key for verifying the vehicle-side signature. The DID document linked to the user terminal DID includes a public key paired with the private key of the user terminal 20. This public key is a public key for verifying the user terminal-side signature. The document request includes the vehicle DID and user terminal DID included in the output request. In other words, the document request unit 312 transmits a document request including the vehicle DID and user terminal DID to the DLT network 50. The document request unit 312 may transmit a document request including the vehicle DID and a document request including the user terminal DID to the DLT network 50. The document request unit 312 may transmit the document request to the DLT network 50 via the WFCM 301.

[0065] Upon receiving this document request, the DLT network 50 obtains from the VDR the DID document linked to the DID included in the document request. The DLT network 50 obtains from the VDR the DID document linked to the vehicle DID and the DID document linked to the user terminal DID. In this embodiment, the DLT network 50 obtains the DID document from the VDR linked to the DID document linked to the DID. The DLT network 50 then transmits the obtained DID document to the WFCM 301 of the guarantee agency terminal 30 that made the document request.

[0066] The document acquisition unit 313 acquires the DID documents transmitted from the DLT network 50 in response to a document request from the document request unit 312. The document acquisition unit 313 acquires the DID documents linked to the vehicle DID and the DID documents linked to the user terminal DID. The document acquisition unit 313 may acquire the DID documents transmitted from the DLT network 50 via the WFCM 301.

[0067] The verification unit 314 extracts the public key included in the DID document acquired by the document acquisition unit 313. The verification unit 314 extracts the public key of the vehicle DID (hereinafter referred to as the vehicle public key) from the DID document linked to the vehicle DID. The verification unit 314 extracts the public key of the user terminal DID (hereinafter referred to as the user terminal public key) from the DID document linked to the user terminal DID. The verification unit 314 uses the extracted vehicle public key to verify the vehicle-side signature attached to the vehicle-related information acquired by the vehicle-related information acquisition unit 311. The vehicle-side signature can be verified by checking whether it can be decrypted with the vehicle public key. If the vehicle-side signature can be decrypted with the vehicle public key, the vehicle-side signature is deemed to have been verified. The verification of the vehicle-side signature is to verify that the vehicle-related information output by the vehicle 10 has not been rewritten. The verification unit 314 uses the extracted user terminal public key to verify the user terminal-side signature attached to the vehicle-related information acquired by the vehicle-related information acquisition unit 311. The user terminal side signature can be verified by checking whether it can be decrypted using the user terminal public key. If the user terminal side signature can be decrypted using the user terminal public key, the user terminal side signature is considered to have been verified. The verification of the user terminal side signature is a verification that the vehicle-related information relayed by the user terminal 20 has not been rewritten.

[0068] The verification unit 314 verifies whether or not predetermined conditions (hereinafter, "authenticity conditions") regarding the authenticity of the vehicle-related information acquired by the vehicle-related information acquisition unit 311 are satisfied. In the example of this embodiment, these authenticity conditions consist of the following three conditions. The first is that the verification of the vehicle-side signature described above is successful. Satisfying the first condition ensures that the vehicle-related information output by the vehicle 10 has not been rewritten. The second is that the verification of the user terminal-side signature described above is successful. Satisfying the second condition ensures that the vehicle-related information relayed by the user terminal 20 has not been rewritten. The third is that the tampering verification result given to the vehicle-related information acquisition unit 311 shows no tampering. Satisfying the third condition ensures that the vehicle-related information stored in the vehicle 10 has not been rewritten.

[0069] If the verification unit 314 can verify the authenticity conditions described above, the registration unit 315 performs the following registration. The registration unit 315 registers the vehicle-related information acquired by the vehicle-related information acquisition unit 311 and the vehicle DID and user terminal DID assigned to the vehicle-related information in the DLT network 50. This registration corresponds to the registration of a VC. The registration unit 315 simply registers the VC by transmitting this vehicle-related information, vehicle DID, and user terminal DID to the DLT network 50 via the WFCM 301. In response to this, the DLT network 50 registers the VC by linking the vehicle-related information transmitted from the registration unit 315 with the vehicle DID and user terminal DID transmitted from the registration unit 315 and storing them in a registry. Furthermore, when a VC is registered, the DLT network 50 returns a VC (hereinafter referred to as vehicle-related information VC) that is linked to the vehicle DID and the user terminal DID and includes the vehicle-related information and a proof for verification to the guarantee agency terminal 30. The proof of the vehicle-related information VC is, for example, a hash value generated from the vehicle-related information using a hash function. The hash function used to generate this proof may be linked to the vehicle-related information VC and managed by the DLT network 50.

[0070] According to the above configuration, it is possible to verify, using the DLT network 50, that the vehicle-related information VC is linked to an authorized user of the vehicle 10. More specifically, since the vehicle-related information VC is linked to the vehicle DID and the user terminal DID, it is possible to identify that the vehicle-related information VC belongs to an authorized user of the vehicle 10. The proof included in the vehicle-related information VC is generated by the DLT network 50. Therefore, it is also possible to use this proof to verify that the vehicle-related information included in the vehicle-related information VC has not been changed since the vehicle-related information VC was registered.

[0071] The VC acquisition unit 316 acquires the vehicle-related information VC transmitted from the DLT network 50 in response to the registration of the VC by the registration unit 315. The VC transmission unit 317 transmits the vehicle-related information VC acquired by the VC acquisition unit 316 to the user terminal 20.

[0072] <Data Flow in Authentication System 1> Here, an example of data flow in the authentication system 1 will be described using the sequence diagram of Fig. 5. The sequence diagram of Fig. 5 shows an example of data flow among the vehicle 10, the user terminal 20, the warranty agency terminal 30, the service provider terminal 40, and the DLT network 50. The sequence diagram of Fig. 5 will be described using an example in which the vehicle-related information stored in the vehicle 10 has not been tampered with until it reaches the warranty agency terminal 30.

[0073] First, at t1, the output request unit 211 of the user terminal 20 makes the above-mentioned output request to the vehicle 10. At t2, the request receiving unit 115 of the vehicle 10 receives the output request. Then, the data output unit 116 of the vehicle 10 outputs the vehicle-related information stored in the vehicle-related information storage unit 113 to the user terminal 20. The data output unit 116 adds the vehicle DID of the vehicle 10, the vehicle-side signature, and the tampering verification result to the vehicle-related information, and outputs the information.

[0074] At t3, the vehicle-related information acquisition unit 212 of the user terminal 20 acquires the vehicle-related information output at t2. This vehicle-related information is assigned the vehicle DID, vehicle-side signature, and tampering verification result. Then, at t3, the relay unit 213 of the user terminal 20 further assigns the user terminal DID and user terminal-side signature of the user terminal 20 to this vehicle-related information and transmits it to the warranty agency terminal 30. The vehicle-related information transmitted to the warranty agency terminal 30 will be assigned the vehicle DID, vehicle-side signature, user terminal DID, user terminal-side signature, and tampering verification result.

[0075] At t4, the vehicle-related information acquisition unit 311 of the warranty agency terminal 30 acquires the vehicle-related information transmitted at t3. Then, the document request unit 312 of the warranty agency terminal 30 transmits a document request to the DLT network 50. This document request is a request for DID documents linked to the vehicle DID and user terminal DID that were assigned to the acquired vehicle-related information.

[0076] At t5, the DLT network 50, which has received the document request, reads the DID document requested in the document request and transmits it to the warranty agency terminal 30. At t6, the document acquisition unit 313 of the warranty agency terminal 30 acquires the DID document transmitted from the DLT network 50. The verification unit 314 of the warranty agency terminal 30 extracts the vehicle public key and user terminal public key contained in the acquired DID document. The verification unit 314 verifies whether the aforementioned authenticity conditions are met based on the vehicle public key and user terminal public key and the information attached to the vehicle-related information acquired at t4. The information attached to the vehicle-related information used for this verification is, as described above, the vehicle-side signature, the user terminal-side signature, and the tampering verification result. In this embodiment, the vehicle-related information stored in the vehicle 10 has not been tampered with until it reaches the warranty agency terminal 30, so the verification unit 314 verifies that the authenticity conditions are met.

[0077] At t7, the registration unit 315 of the warranty agency terminal 30 registers the vehicle-related information acquired at t4, as well as the vehicle DID and user terminal DID assigned to the vehicle-related information, in the DLT network 50. At t8, the DLT network 50 associates the transmitted vehicle-related information with the transmitted vehicle DID and user terminal DID and stores them in a registry, thereby registering the vehicle-related information VC. The registered vehicle-related information VC is then transmitted to the warranty agency terminal 30. At t9, the VC acquisition unit 316 of the warranty agency terminal 30 acquires the vehicle-related information VC transmitted from the DLT network 50. The VC transmission unit 317 of the warranty agency terminal 30 then transmits the acquired vehicle-related information VC to the user terminal 20.

[0078] At t10, the first VC acquisition unit 214 of the user terminal 20 acquires the vehicle-related information VC transmitted from the guarantee agency terminal 30 and stores it in the first VC storage unit 215. Therefore, the user Us can carry the vehicle-related information VC on the user terminal 20 and freely present it to the service provider.

[0079] At t11, the VC sending unit 216 of the user terminal 20 sends the vehicle-related information VC stored in the first VC storage unit 215 to the service provider terminal 40. At t12, the service provider terminal 40 acquires the vehicle-related information VC sent from the user terminal 20. Then, the service provider terminal 40 transmits the acquired vehicle-related information VC to the DLT network 50, causing the vehicle-related information VC to be verified.

[0080] By verifying this vehicle-related information VC, the service provider can confirm whether the vehicle-related information has been rewritten in the vehicle 10, the user terminal 20, and the guarantee agency terminal 30. It is difficult for the service provider to provide services if there is a possibility that the vehicle-related information is incorrect or if there is no one to guarantee the authenticity of the vehicle-related information. In contrast, the configuration of this embodiment allows the service provider to verify the authenticity of the vehicle-related information. This increases the service provider's motivation to provide services assuming that the vehicle-related information provided by the user Us is correct. Furthermore, the guarantee agency operating the guarantee agency terminal 30 may be able to collect fees for guaranteeing the vehicle-related information from the user Us and the service provider.

[0081] At t13, the DLT network 50 acquires the vehicle-related information VC transmitted from the service provider terminal 40. Then, the DLT network 50 verifies the authenticity of the vehicle-related information VC using the proof included in the vehicle-related information VC and transmits the verification result to the service provider terminal 40. In the example of this embodiment, the warranty agency terminal 30 has performed the above-mentioned authenticity verification and registered the vehicle-related information VC, so the verification of the vehicle-related information VC is successful.

[0082] At t14, the service provider terminal 40 receives the verification result indicating that the vehicle-related information VC has been verified, transmitted from the DLT network 50. Then, the service provider terminal 40 generates service-related information using the vehicle-related information included in the vehicle-related information VC, and registers the generated service-related information in the DLT network 50. In the registration, the service-related information may be registered in association with the provider terminal DID.

[0083] At t15, the DLT network 50 associates the transmitted service-related information with the transmitted provider terminal DID and stores it in a registry, thereby registering the service-related information VC. The registered service-related information VC is then transmitted to the service provider terminal 40. At t16, the service provider terminal 40 acquires the service-related information VC transmitted from the DLT network 50 and transmits it to the user terminal 20. At t17, the second VC acquisition unit 217 of the user terminal 20 acquires the service-related information VC transmitted from the service provider terminal 40 and stores it in the second VC storage unit 418.

[0084] (Embodiment 2) In the first embodiment, the vehicle-related information of the vehicle 10 is output to the warranty agency terminal 30 via the user terminal 20, but this is not necessarily limited to this. For example, the vehicle-related information of the vehicle 10 may be output to the warranty agency terminal 30 without going through the user terminal 20 (hereinafter, referred to as embodiment 2). An example of the configuration of embodiment 2 will be described below with reference to the drawings. <Outline of Authentication System 1a> First, the authentication system 1a of embodiment 2 will be described with reference to FIG. 6. As shown in FIG. 6, the authentication system 1a includes a vehicle 10, a warranty agency terminal 30, a service provider terminal 40, and a DLT network 50. In the authentication system 1a, the vehicle 10 includes a vehicle unit 100a instead of the vehicle unit 100. The authentication system 1a does not include a user terminal 20. Except for these points, the authentication system 1a is similar to the authentication system 1 of embodiment 1. The authentication system 1a also corresponds to a distributed ID system.

[0085] <General Configuration of Vehicle Unit 100a> Here, the general configuration of the vehicle unit 100a will be described using Fig. 7. As shown in Fig. 7, the vehicle unit 100a includes an on-board ECU 101a, an NFCM 102, and a WFCM 103. The vehicle unit 100a is similar to the vehicle unit 100 of the first embodiment except that the vehicle unit 100a includes the on-board ECU 101a instead of the on-board ECU 101.

[0086] Next, the schematic configuration of the in-vehicle ECU 101a will be described using Figure 7. As shown in Figure 2, the in-vehicle ECU 101 includes, as functional blocks, a vehicle-related information acquisition unit 111, a storage processing unit 112, a vehicle-related information storage unit 113, a tampering verification unit 114, a request reception unit 115a, a data output unit 116a, a first VC acquisition unit 117, a first VC storage unit 118, a VC transmission unit 119, a second VC acquisition unit 120, and a second VC storage unit 121. The in-vehicle ECU 101a includes the request reception unit 115a and the data output unit 116a instead of the request reception unit 115 and the data output unit 116. The in-vehicle ECU 101a includes the first VC acquisition unit 117, the first VC storage unit 118, the VC transmission unit 119, the second VC acquisition unit 120, and the second VC storage unit 121. Except for these points, the in-vehicle ECU 101a is similar to the in-vehicle ECU 101 of the first embodiment. The in-vehicle ECU 101a also corresponds to a vehicle-side device.

[0087] The request receiving unit 115a receives an output request from an occupant of the vehicle 10 requesting output of vehicle-related information including at least vehicle information. The request receiving unit 115a may receive the output request from the occupant via a user input unit of the vehicle 10. Examples of the user input unit include a touch switch integrated with an in-vehicle display and a mechanical switch such as a steering switch. Alternatively, a voice input device that receives input of a voice command may be used as the user input unit.

[0088] The data output unit 116a is similar to the data output unit 116 of the first embodiment, except for some differences in processing. The following describes these differences. The data output unit 116a outputs the vehicle-related information, to which the vehicle-side signature and the tampering verification result have been attached, to the warranty agency terminal 30a. In other words, the data output unit 116a outputs the vehicle-related information directly to the warranty agency terminal 30a without going through the user terminal 20. The data output unit 116a simply causes the WFCM 103 to output the vehicle-related information. This processing by the data output unit 116a also corresponds to a data output step. The data output unit 116a may also attach the vehicle DID of the vehicle 10 to the vehicle-related information and output it. The following description will be continued assuming that the data output unit 116a also attaches the vehicle DID of the vehicle 10 to the vehicle-related information and outputs it.

[0089] The warranty company terminal 30a receives the vehicle-related information, and if a predetermined condition is met, the warranty company terminal 30a registers the vehicle-related information in the DLT network 50 and issues a VC for the vehicle-related information. In this embodiment, the predetermined condition is that the signature of the vehicle DID can be verified and the tampering verification result shows no tampering. The processing at the warranty company terminal 30a will be described in detail later.

[0090] A VC of vehicle-related information is issued when the vehicle-related information stored in the vehicle 10 has not been tampered with and when the vehicle-related information output by the vehicle 10 has not been rewritten. Furthermore, since the issuance of a VC is performed after the vehicle-related information is registered in the DLT network 50, it is also easy to verify whether the vehicle-related information included in the issued VC has been tampered with. Therefore, even with the above configuration, even when a VC including vehicle-related information is transmitted to a service provider that provides vehicle services using the vehicle-related information, the service provider can easily provide vehicle services assuming that the vehicle-related information is correct. As a result, even when a VC including vehicle-related information is transmitted to a service provider that provides vehicle services using the vehicle-related information, the service provider can easily provide vehicle services assuming that the vehicle-related information is correct.

[0091] The first VC acquisition unit 117 acquires the vehicle-related information VC transmitted from the warranty agency terminal 30a in response to the transmission of vehicle-related information from the data output unit 116a to the warranty agency terminal 30. As described above, the warranty agency terminal 30a receives the vehicle-related information and, if predetermined conditions are satisfied, registers the vehicle-related information in the DLT network 50 and issues a VC for the vehicle-related information. The first VC acquisition unit 117 acquires the VC for this vehicle-related information issued by the warranty agency terminal 30a in response to the transmission of the vehicle-related information and, if predetermined conditions are satisfied. The first VC storage unit 118 stores the vehicle-related information VC acquired by the first VC acquisition unit 117. The non-volatile memory of the in-vehicle ECU 101a may be used as the first VC storage unit 118.

[0092] The VC transmission unit 119 transmits the vehicle-related information VC stored in the first VC storage unit 118 to the service provider terminal 40. For example, when the in-vehicle ECU 101 receives input from the occupant to use the used car appraisal service provided by the service provider terminal 40, the in-vehicle ECU 101 may transmit the vehicle-related information VC to the service provider terminal 40. This input from the occupant may be received via the user input unit described above. The VC transmission unit 119 may transmit the vehicle-related information VC to the service provider terminal 40 via the WFCM 103. Note that the VC transmission unit 119 may transmit the vehicle-related information VC in a format included in a VP.

[0093] The second VC acquisition unit 120 acquires service-related information VC transmitted from the service provider terminal 40 when the vehicle-related information VC transmitted from the VC transmission unit 119 can be verified on the DLT network 50. The service-related information VC may be the same as that described in embodiment 1. Verification of the vehicle-related information VC at the service provider terminal 40 may also be performed in the same manner as described in embodiment 1. The second VC storage unit 121 stores the service-related information VC acquired by the second VC acquisition unit 120. The second VC storage unit 121 may be a non-volatile memory of the in-vehicle ECI 101a.

[0094] <General Configuration of the Guarantee Agency Terminal 30a> Here, the general configuration of the guarantee agency terminal 30a will be described using Fig. 8. As shown in Fig. 8, the guarantee agency terminal 30a includes a control unit 300a and a WFCM 301. The guarantee agency terminal 30a is similar to the guarantee agency terminal 30 of the first embodiment, except that it includes a control unit 300a instead of the control unit 300.

[0095] Next, the schematic configuration of the control unit 300a will be described with reference to FIG. 8. As shown in FIG. 4, the control unit 300 includes functional blocks such as a vehicle-related information acquisition unit 311a, a document request unit 312a, a document acquisition unit 313, a verification unit 314a, a registration unit 315a, a VC acquisition unit 316, and a VC transmission unit 317a. The control unit 300a includes the vehicle-related information acquisition unit 311a instead of the vehicle-related information acquisition unit 311. The control unit 300a includes the document request unit 312a instead of the document request unit 312. The control unit 300a includes the verification unit 314a instead of the verification unit 314. The control unit 300a includes the registration unit 315a instead of the registration unit 315. The control unit 300a includes the VC transmission unit 317a instead of the VC transmission unit 317. Except for these points, the control unit 300a is similar to the control unit 300 of the first embodiment.

[0096] The vehicle-related information acquisition unit 311a acquires vehicle-related information transmitted from the WFCM 103 of the vehicle 10. The vehicle-related information acquisition unit 311a may acquire this vehicle-related information via the WFCM 301. In the example of this embodiment, the vehicle-side signature, the vehicle DID, and the tampering verification result are attached to this vehicle-related information.

[0097] The document request unit 312a transmits a document request to the DLT network 50, requesting a DID document linked to the vehicle DID assigned to the vehicle-related information acquired by the vehicle-related information acquisition unit 311a. As described above, the DID document linked to the vehicle DID includes a vehicle public key paired with the private key of the vehicle 10. The document request unit 312a transmits the document request to the DLT network 50 via the WFCM 301. Upon receiving this document request, the DLT network 50 acquires, from the VDR, the DID document linked to the vehicle DID included in the document request. The acquired DID document is then transmitted to the WFCM 301 of the warranty agency terminal 30a that made the document request.

[0098] The verification unit 314a extracts the vehicle public key included in the DID document acquired by the document acquisition unit 313. The verification unit 314a uses the extracted vehicle public key to verify the vehicle-side signature attached to the vehicle-related information acquired by the vehicle-related information acquisition unit 311a. The vehicle-side signature may be verified in the same manner as described in the first embodiment. The verification unit 314a verifies whether or not predetermined conditions (hereinafter, "authenticity conditions") regarding the authenticity of the vehicle-related information acquired by the vehicle-related information acquisition unit 311a are satisfied. In the example of this embodiment, these authenticity conditions consist of the following two conditions. The first condition is that the aforementioned vehicle-side signature is verified. Satisfying the first condition ensures that the vehicle-related information output by the vehicle 10 has not been tampered with. The second condition is that the tampering verification result attached to the vehicle-related information acquisition unit 311 shows no tampering. Satisfying the second condition ensures that the vehicle-related information stored in the vehicle 10 has not been tampered with.

[0099] If the verification unit 314a verifies the authenticity conditions, the registration unit 315a performs the following registration. The registration unit 315a registers the vehicle-related information acquired by the vehicle-related information acquisition unit 311a and the vehicle DID assigned to the vehicle-related information in the DLT network 50. This registration corresponds to the registration of a VC. The registration unit 315a simply registers the VC by transmitting the vehicle-related information and the vehicle DID to the DLT network 50 via the WFCM 301. In response to this, the DLT network 50 registers the VC by linking the vehicle-related information transmitted from the registration unit 315a with the vehicle DID transmitted from the registration unit 315 and storing them in a registry. Furthermore, when the VC is registered, the DLT network 50 returns the vehicle-related information VC, which includes the vehicle-related information linked to the vehicle DID and a proof for verification, to the guarantee agency terminal 30a. The proof of the vehicle-related information VC may be the same as that described in the first embodiment.

[0100] According to the above configuration, it is possible to verify, using the DLT network 50, that the vehicle-related information VC is linked to the vehicle 10. More specifically, since the vehicle-related information VC is linked to the vehicle DID, it is possible to identify that the vehicle-related information VC belongs to the vehicle 10. Furthermore, it is possible to verify, using the proof included in the vehicle-related information VC, that the vehicle-related information included in the vehicle-related information VC has not been changed since the vehicle-related information VC was registered.

[0101] The VC transmitter 317a transmits the vehicle-related information VC acquired by the VC acquisition unit 316 to the vehicle 10. The VC transmitter 317a may transmit the vehicle-related information VC to the vehicle 10 via the WFCM 301.

[0102] The present disclosure is not limited to the above-described embodiments, and various modifications are possible within the scope of the claims. Embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also within the technical scope of the present disclosure. Furthermore, the control unit and method described in the present disclosure may be implemented by a special-purpose computer comprising a processor programmed to execute one or more functions embodied in a computer program. Alternatively, the apparatus and method described in the present disclosure may be implemented by a circuit. Alternatively, the apparatus and method described in the present disclosure may be implemented by one or more special-purpose computers configured by combining a processor executing a computer program with one or more circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory tangible recording medium.

[0103] In this disclosure and claims, the term "processor" refers to one or more hardware processors configured to execute the processing defined by computer program code (i.e., one or more instructions of a computer program) included in a computer program by loading the code each time. In other words, a "processor" is a hardware device that executes one or more programmed processes. Therefore, computer program code can also be considered software that can define the processing of the processor depending on its content. For example, a "processor" may be a general-purpose or specific-purpose processor, such as a CPU, microprocessor, GPU, or DFP (Data Flow Processor), but is not limited to these.

[0104] In this disclosure and in the claims, the term "memory" refers to one or more hardware memories that are non-transitory tangible recording media configured to store computer program code and / or data accessible to a processor. The "memory" may be implemented using memory technologies such as SRAM, SDRAM, non-volatile / flash-type memory, or other types of memory. Computer program code constituting a program may be stored in the memory and executed by a processor to cause the processor to perform the various functions described above.

[0105] In this disclosure or in the claims, the term "circuit" refers to one or more hardware logic circuits configured to perform specific processing defined by a pre-designed circuit configuration. In other words (and in contrast to "processor"), a "circuit" in this disclosure or in the claims refers to a hardware device that performs specific processing based on a circuit configuration, rather than a software program such as a computer program code. For example, a "circuit" may include custom ICs such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array) designed using a Hardware Description Language (HDL). In other words, a "circuit" in this disclosure or in the claims includes all hardware circuits except a processor that executes processing by loading computer program code.

[0106] In the present disclosure or claims, the expression "at least one of a processor and a circuit" should be interpreted as a disjunction (logical OR), and not as at least one processor and at least one circuit. Therefore, in the present disclosure or claims, "at least one of a processor and a circuit" includes cases where only a circuit performs all functions. Also, in the present disclosure or claims, "at least one of a processor and a circuit" includes cases where only a processor performs all functions. In the present disclosure or claims, "at least one of a processor and a circuit" includes cases where a circuit performs some functions and a processor performs the remaining functions.

Claims

1. A vehicle-side device for use in a vehicle that can be used in a distributed ID system (1, 1a) that uses distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network (50), which is a network of nodes on the distributed ledger system, comprising: a vehicle-side information acquisition unit (111) that acquires vehicle information, which is information about the vehicle, from the vehicle (10); a vehicle-side storage unit (113) that stores the vehicle information acquired by the vehicle-side information acquisition unit; and a tampering verification unit (114) that verifies whether the vehicle information stored in the vehicle-side storage unit has been tampered with. The vehicle-side device includes a data output unit (116, 116a) that adds to the vehicle information a vehicle-side signature, which is a signature using the private key of the vehicle DID, which is the distributed identifier of the vehicle, and a verification result of whether the vehicle information stored in the vehicle-side storage unit has been tampered with by the tampering verification unit, and outputs the vehicle information directly or indirectly to a guarantee agency terminal (30), which is a terminal of a guarantee agency that can verify at least the vehicle-side signature and registers the vehicle information in the distributed ledger network and issues a VC for the vehicle information, if the verification result shows that there has been no tampering.

2. A vehicle-side device as described in claim 1, wherein the data output unit (116) outputs the vehicle information to a user terminal (20) carried by a user that can be used in the distributed ID system, thereby indirectly outputting the vehicle information to the guarantee agency terminal via the user terminal; and by indirectly outputting the vehicle information to the guarantee agency terminal via the user terminal, the user terminal also assigns a user terminal-side signature, which is a signature using the private key of the user terminal DID, which is the distributed identifier of the user terminal, to the vehicle information to which the vehicle information has been directly or indirectly output, and which, if it can verify the vehicle-side signature and the user terminal-side signature and the verification result has not been tampered with, registers the vehicle information in the distributed ledger network and issues a VC for the vehicle information.

3. A user terminal carried by a user that can be used in a distributed ID system (1) that uses distributed ID technology to verify a verifiable credential, VC, linked to a distributed identifier, DID, in a distributed ledger network (50), which is a network of nodes on the distributed ledger system, comprising: an output request unit (211) that issues an output request to a vehicle, requesting that the vehicle information, which is information about the vehicle acquired and stored in the vehicle, be output; and a terminal-side information acquisition unit (212) that acquires the vehicle information, output from the vehicle in response to the output request from the output request unit, to which a vehicle-side signature, which is a signature using a private key of the vehicle DID, which is the distributed identifier of the vehicle, and a verification result, which verifies whether the vehicle information stored in the vehicle has been tampered with, are attached. A user terminal comprising a relay unit (213) that adds a user terminal signature, which is a signature using the private key of the user terminal DID, which is a distributed identifier of the user terminal, to the vehicle information, to which the vehicle side signature and the verification result have been added, acquired by the terminal side information acquisition unit, and transmits the vehicle information to a guarantee agency terminal, which is a terminal of a guarantee agency that registers the vehicle information in the distributed ledger network and issues a VC for the vehicle information.

4. A data assurance method usable in a distributed ID system (1, 1a), which uses distributed ID technology to verify a verifiable credential (VC) linked to a distributed identifier (DID) in a distributed ledger network (50), which is a network of nodes on the distributed ledger system, the data assurance method comprising: a vehicle-side information acquisition step executed by at least one of a processor and a circuit, which acquires vehicle information from a vehicle (10), which is information about the vehicle; a vehicle-side storage step storing the vehicle information acquired in the vehicle-side information acquisition step; and a tampering verification step verifying whether the vehicle information stored in the vehicle-side storage step has been tampered with. a data output process for adding to the vehicle information a vehicle-side signature, which is a signature using the private key of the vehicle DID, which is the distributed identifier of the vehicle, and the verification result of whether the vehicle information stored in the vehicle-side storage process has been tampered with in the tampering verification process, and outputting the vehicle information directly or indirectly to a guarantee agency terminal (30), which is a terminal of a guarantee agency that registers the vehicle information in the distributed ledger network and issues a VC for the vehicle information, if at least the vehicle-side signature can be verified and the verification result shows no tampering.

5. A data assurance method according to claim 4, which is executed by at least one of a plurality of processors and circuits, wherein in the data output step, the vehicle information is assigned with the vehicle-side signature and the verification result, and the vehicle information is indirectly output to the assurance agency terminal via a user terminal (20) carried by a user that can be used in the distributed ID system, and the method includes an output request step in which the user terminal issues an output request to the vehicle requesting output of the vehicle information acquired in the vehicle-side information acquisition step and stored in the vehicle-side storage step; and a terminal-side information acquisition step in which the user terminal acquires the vehicle information, to which the vehicle-side signature and the verification result have been assigned, and which is output from the vehicle in the data output step, in response to the output request in the output request step. The data assurance method further includes a relaying step of: adding a user terminal side signature, which is a signature using the private key of the user terminal DID, which is a distributed identifier of the user terminal, to the vehicle information, which has been acquired in the terminal side information acquisition step and has been assigned the vehicle side signature and the verification result; and, if the vehicle side signature can be verified and the user terminal side signature can be verified and the verification result is not tampered with, registering the vehicle information in the distributed ledger network and transmitting it to the assurance agency terminal, which issues a VC for the vehicle information.

Images