WO2022137945A1 - データ保存装置、データ保存方法、およびデータ保存プログラム - Google Patents

データ保存装置、データ保存方法、およびデータ保存プログラム Download PDF

Info

Publication number
WO2022137945A1
WO2022137945A1 PCT/JP2021/042863 JP2021042863W WO2022137945A1 WO 2022137945 A1 WO2022137945 A1 WO 2022137945A1 JP 2021042863 W JP2021042863 W JP 2021042863W WO 2022137945 A1 WO2022137945 A1 WO 2022137945A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
hash value
data
storage
blockchain
Prior art date
Application number
PCT/JP2021/042863
Other languages
English (en)
French (fr)
Inventor
▲シン▼ 徐
Original Assignee
株式会社デンソー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社デンソー filed Critical 株式会社デンソー
Priority to CN202180086419.1A priority Critical patent/CN116710917A/zh
Publication of WO2022137945A1 publication Critical patent/WO2022137945A1/ja
Priority to US18/339,113 priority patent/US20230336356A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the disclosure in this specification relates to a technique for storing data acquired by a mobile body.
  • Non-Patent Document 1 discloses a technique of assigning an encryption key to an in-vehicle ECU and authenticating a legitimate ECU based on the encryption key.
  • Non-Patent Document 1 does not disclose any measures against such a situation.
  • the purpose of disclosure is to provide a data storage device, a data storage method, and a data storage program that can make it difficult to falsify data.
  • One of the disclosed data storage devices defines a secure world that is mounted on a mobile body and has restricted access from the normal world and the normal world, and the acquired data acquired by the mobile body is collected using a blockchain. It is a data storage device that stores data.
  • a block generator that generates a new block to be connected to the blockchain based on the block hash value generated from at least the immediately preceding block, By saving the last block hash value based on the last block concatenated at the end of the blockchain at each specific update timing in the storage area of the secure world, the last block hash value saved at the previous update timing is updated.
  • Processing unit and A data hash generator that generates a data hash value, which is a hash value based on the acquired data and the final block hash value, at least for each update timing. To prepare for.
  • One of the disclosed data storage methods defines a secure world that is mounted on a mobile body and restricts access from the normal world and the normal world, and the acquired data acquired by the mobile body is obtained using a blockchain.
  • a data storage method performed by the processor to store, A block generation process that generates a new block to be linked to the blockchain based on the block hash value generated from at least the immediately preceding block.
  • the final block hash value saved at the previous update timing is updated.
  • the storage process and A data hash generation process that generates a data hash value, which is a hash value based on the acquired data and the final block hash value, at least at each update timing. including.
  • One of the disclosed data storage programs defines a secure world that is mounted on a mobile body and restricts access from the normal world and the normal world, and the acquired data acquired by the mobile body is collected using a blockchain.
  • a data storage program that contains instructions to be executed by the processor for storage.
  • the order is A block generation process that generates a new block to be linked to the blockchain based on the block hash value generated from at least the immediately preceding block.
  • the final block hash value saved at the previous update timing is updated.
  • the storage process and A data hash generation process that generates a data hash value, which is a hash value based on the acquired data and the final block hash value, at least at each update timing. including.
  • the final block hash value stored in the storage area is updated at each specific update timing. If the data is tampered with due to the installation of a fake data storage device, etc., the final block hash value and the new data hash value will be different from the original ones. It may be possible to verify the presence or absence. Furthermore, since these values change at each update timing, falsification can be detected even if these values are leaked at the update timing before the previous time. As described above, a data storage device, a data storage method, and a data storage program that can make it difficult to falsify data can be provided.
  • the data storage device of the first embodiment will be described with reference to FIGS. 1 to 6.
  • the data storage device of the first embodiment is provided by an in-vehicle ECU 100 which is an electronic control device mounted on a vehicle A which is an example of a moving body.
  • the in-vehicle ECU 100 stores the acquired data acquired by the vehicle A, particularly the operation history data HD of the vehicle A.
  • the in-vehicle ECU 100 is an information processing device mounted on the vehicle A in a plurality of units, for example, four or more units.
  • the plurality of in-vehicle ECUs 100 can communicate with each other via an in-vehicle network according to a communication standard such as Ethernet (registered trademark).
  • Each of the in-vehicle ECUs 100 can execute processing functions other than storage and verification of acquired data, which will be described later.
  • the in-vehicle ECU 100 may be capable of executing an automatic driving function, an advanced driving support function, a peripheral monitoring function, and the like.
  • one of the in-vehicle ECU 100 may be provided by the vehicle control ECU 20 (described later).
  • the in-vehicle ECU 100 is connected to the in-vehicle sensor 10 and the vehicle control ECU 20 via an in-vehicle network.
  • the in-vehicle sensor 10 has various detection configurations mounted on the vehicle A.
  • the in-vehicle sensor 10 includes a sensor capable of detecting the operation of the vehicle A by the driver.
  • the vehicle-mounted sensor 10 includes an accelerator pedal sensor that detects the amount of depression of the accelerator pedal, a brake pedal sensor that detects the amount of depression of the brake pedal, a steering sensor that detects the amount of operation of the steering handle, and the like.
  • Each vehicle-mounted sensor 10 can provide the detected data to at least one vehicle-mounted ECU 100.
  • the in-vehicle sensor 10 may indirectly provide the detection data to the in-vehicle ECU 100 via another ECU that collects the detection data.
  • the in-vehicle ECU 100 is a plurality of electronic control devices mounted on the vehicle A. At least one of the in-vehicle ECU 100 is a data storage device that stores the data acquired from the above-mentioned in-vehicle sensor 10 and the blockchain BC. The other in-vehicle ECU 100 stores the blockchain BC and verifies the credibility of the blockchain BC.
  • the former in-vehicle ECU 100 may be referred to as “verification target ECU”
  • the latter in-vehicle ECU 100 may be referred to as “verification charge ECU”.
  • the in-vehicle ECU 100 mainly includes a computer including a memory 101, a processor 102, an input / output interface, and a bus connecting them.
  • the processor 102 is hardware for arithmetic processing.
  • the processor 102 includes, for example, at least one of a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), a RISC (Reduced Instruction Set Computer) -CPU, and the like as a core.
  • a CPU Central Processing Unit
  • GPU Graphics Processing Unit
  • RISC Reduced Instruction Set Computer
  • the in-vehicle ECU 100 defines at least two different processing areas in the system, a normal world NW and a secure world SW.
  • the normal world NW and the secure world SW may be physically separated on the hardware, or may be virtually separated by the cooperation of the hardware and the software.
  • the in-vehicle ECU 100 uses a function such as a context switch to temporally separate resources necessary for executing an application into a normal world NW and a secure world SW.
  • Normal World NW is a normal area for executing operating systems and applications.
  • the normal world NW is provided with a normal storage US as a storage area (Untrusted Storage) for storing data.
  • a normal storage US as a storage area (Untrusted Storage) for storing data.
  • Secure World SW is an area isolated from Normal World NW.
  • a secure operating system and application for processing requiring security are executed. Access from the normal world NW to the secure world SW is restricted by the function of the processor 102. Therefore, the existence of the secure world SW cannot be recognized from the normal world NW, and the security of the processing executed by the secure world SW and the information stored in the secure world SW is ensured.
  • the secure world SW is provided with a secure storage TS as a storage area (Trusted Storage) for storing data.
  • the capacity of the secure storage TS may be smaller than the capacity of the normal storage US. Alternatively, the capacity of the secure storage TS may be equal to or greater than the capacity of the normal storage US.
  • the memory 101 non-transiently stores or stores a computer-readable program, data, or the like, for example, at least one type of non-transitional substantive storage medium (non-transitional memory, magnetic medium, optical medium, or the like, etc.). transitory tangible storage medium).
  • the memory 101 stores various programs executed by the processor 102, such as a data storage program described later.
  • the processor 102 executes a plurality of instructions included in the data storage program stored in the memory 101.
  • the in-vehicle ECU 100 constructs a plurality of functional units for data storage.
  • a plurality of functional units are constructed by causing the processor 102 to execute a plurality of instructions by the data storage program stored in the memory 101.
  • the in-vehicle ECU 100 includes a data block creation unit 110, a data hash generation unit 120, a block hash generation unit 130, a block generation unit 140, a hash storage processing unit 150, and a transmission processing unit 160. Will be built.
  • the in-vehicle ECU 100 is constructed with a block hash storage processing unit 170, a verification execution unit 180, a block storage processing unit 190, and the like.
  • the data block creation unit 110, the data hash generation unit 120, the block hash generation unit 130, the block generation unit 140, the hash storage processing unit 150, and the transmission processing unit 160 are constructed by the ECU to be verified. It is a functional unit. Further, the block hash storage processing unit 170, the verification execution unit 180, and the block storage processing unit 190 are functional units constructed by the ECU in charge of verification. In FIG. 1, each is described as a function of a different in-vehicle ECU 100, but each in-vehicle ECU 100 can also serve as a verification target and a person in charge of verification.
  • the data block creation unit 110 acquires the detection data detected by the in-vehicle sensor 10 as the operation history data HD of the driver, and creates a data block.
  • the data block may be referred to as a transaction.
  • a transaction is a unit for collectively storing operation history data HD having a specified size.
  • the data block creation unit 110 periodically creates a transaction while the drive source of the vehicle A is activated.
  • the data block creation unit 110 stores the created transaction in the normal storage US in a state of being associated with the block BL connected to the blockchain BC described later.
  • the data block creation unit 110 provides the created transaction to the data hash generation unit 120 and the block generation unit 140.
  • the data block creation unit 110 determines that the drive source of the vehicle A has stopped.
  • the data block creation unit 110 cancels the transaction creation.
  • the data block creation unit 110 determines that the drive source of the vehicle A has been activated, the data block creation unit 110 resumes the creation of the transaction.
  • a newly generated transaction may be referred to as a "new transaction" in particular.
  • immediately after the drive source is activated is a timing after the drive source is activated and before the credibility of the in-vehicle ECU 100 is ensured. It can also be said that immediately after the drive source is activated is the timing at which the data block is generated for the first time after the drive source is activated. This timing is an example of the "second timing".
  • the data hash generation unit 120 generates a hash value based on the created transaction as a data hash value.
  • the data hash generation unit 120 converts a composite of the block hash value BH (BH_1) stored in the secure storage TS and the transaction into a data hash value.
  • This process can be understood as a process of digitally signing a transaction.
  • the newly generated data hash value may be particularly referred to as “new data hash value”.
  • the data hash generation unit 120 provides the data hash value to the block generation unit 140.
  • the block hash generation unit 130 generates a hash value based on the final block, which is the last block BL connected to the blockchain BC, as the block hash value BH.
  • This block hash value BH is an example of the "final block hash value". In the example shown in FIG. 2, the final block is "BLOCK3" and the block hash value BH is "BH_3".
  • the block hash generation unit 130 may simply convert the block into a block hash value BH by a hash function.
  • the block hash generation unit 130 provides the block hash value BH to the block generation unit 140 and the transmission processing unit 160.
  • the above data hash generation unit 120 and block hash generation unit 130 use a cryptographic hash function in generating a hash value.
  • the cryptographic hash function has a characteristic that the same hash value is not output from different inputs and it is practically impossible to infer the input from the output hash values.
  • SHA-256 which is one of SHA-2
  • SHA-3 SHA-1 and SHA-256 may be appropriately used according to the required output length (number of bits).
  • the block generation unit 140 generates a block BL by combining the data hash value acquired from the data hash generation unit 120 and the block hash value BH acquired from the block hash generation unit 130. Further, the block generation unit 140 concatenates and stores the generated blocks at the end of the blockchain BC.
  • the block generation unit 140 performs the above processing only when an agreement is formed to concatenate the new block BL. More specifically, the block generation unit 140 first acquires the verification result transmitted from the ECU in charge of verification. For example, the block generation unit 140 acquires the verification results performed by three or more other in-vehicle ECUs 100. The verification result includes at least judgment information for determining whether or not to approve the credibility of the in-vehicle ECU 100.
  • the block generation unit 140 generates a new block BL and concatenates the block BL when the credibility of the data is approved by the majority of the verification ECUs based on the acquired verification result.
  • BLOCK4 which is a combination of DH_D (data hash value) and BH_3 (block hash value)
  • BLOCK3 block hash value
  • the hash storage processing unit 150 stores the block hash value BH in the secure storage TS at a specific timing.
  • the hash storage processing unit 150 uses, for example, the stop timing of the drive source of the vehicle A as the storage timing.
  • the hash storage processing unit 150 updates the block hash value BH stored at the previous stop timing with a new block hash value BH.
  • BH_2 which is a block hash value generated from BLOCK2, which is the final block at the previous stop timing
  • BLOCK4 is a block hash value generated from BLOCK4 which is the final block at the current stop timing. Updated to BH_4.
  • the hash storage processing unit 150 acquires a signal (stop signal) capable of determining the stop of the drive source from the vehicle control ECU 20, it determines that it is the stop timing.
  • the stop signal may be a stop state signal indicating a state in which the drive source has stopped, or may be a stop instruction signal instructing the stop of the drive source.
  • the stop timing is an example of "update timing".
  • the transmission processing unit 160 executes information transmission processing that needs to be provided to another vehicle-mounted ECU 100 in the generation of the blockchain BC or the verification of the vehicle-mounted ECU 100. Specifically, the transmission processing unit 160 transmits the transaction and the block hash value BH generated from the final block of the blockchain BC at that time to another in-vehicle ECU 100. In the following, the block hash value BH generated by the verification target ECU may be referred to as a target block hash value.
  • the transmission processing unit 160 is an example of a “transmission unit”.
  • the block hash storage processing unit 170 stores the block hash value BH in the secure storage TS at the stop timing of the drive source in the ECU in charge of verification.
  • the block hash storage processing unit 170 may generate the block hash value BH from the final block of the blockchain BC stored in its own normal storage US, or may acquire the block hash value BH from the ECU to be verified. good.
  • the "blockchain BC stored in the own normal storage US" here means the blockchain BC distributed from the ECU to be verified.
  • the verification execution unit 180 verifies the credibility of the ECU to be verified and generates judgment information as to whether or not to approve it.
  • the verification execution unit 180 acquires a new transaction and a target block hash value transmitted from the verification target, and executes verification based on these information and the information stored by itself.
  • the verification execution unit 180 generates a data hash value (charged data hash value) based on the responsible block hash value which is the block hash value BH stored in its own secure storage TS and the new transaction acquired from the verification target.
  • the verification execution unit 180 determines whether or not the block hash value (in charge block hash value) generated from the final block of the blockchain BC stored by itself matches the target block hash value. If it is determined that they match, the verification execution unit 180 generates determination information to the effect that the credibility of the verification target is approved. On the other hand, if it is determined that they do not match, the verification execution unit 180 generates determination information indicating that the credibility of the verification target is not approved. The verification execution unit 180 transmits the generated determination information to the verification target and the ECU in charge of verification.
  • the block storage processing unit 190 acquires the verification result transmitted from another ECU in charge of verification.
  • the block storage processing unit 190 uses the transaction acquired from the verification target ECU and the block hash value BH stored in its own secure storage TS. Generate a data hash value.
  • the block storage processing unit 190 generates a block with the data hash value and the block hash value BH generated from the final block in its own blockchain BC, and stores the block in connection with the blockchain BC of the normal storage US. As a result, the block storage processing unit 190 can hold the blockchain BC distributed from the ECU to be verified.
  • the block storage processing unit 190 may acquire the new block BL from the ECU to be verified. If the credibility of the data is not approved by the majority of the verification ECUs, the block storage processing unit 190 suspends the connection of the block BL.
  • S means a plurality of steps of the flow executed by a plurality of instructions included in the program.
  • the data block creation unit 110 generates a transaction based on the acquired data.
  • the data hash generation unit 120 generates a data hash value based on the transaction.
  • the block hash generation unit 130 generates the block hash value BH based on the final block. Further, in S140, the transmission processing unit 160 transmits the block hash value BH of the final block and the new transaction to the ECU in charge of verification. Then, in S150, the block generation unit 140 determines whether or not a majority consensus has been formed regarding the concatenation of the new block BL. If it is determined that an agreement has been formed, this flow shifts to S160. In S160, the block generation unit 140 generates a new block BL and connects it to the blockchain BC. After the processing of S160, this flow returns to S110.
  • the block hash generation unit 130 determines whether or not the drive source of the vehicle A has stopped. If it is determined that it has not stopped, it waits until it is determined that it has stopped. On the other hand, if it is determined that the block has stopped, the block hash generation unit 130 generates the block hash value BH from the final block in S220.
  • the hash storage processing unit 150 saves the generated block hash value BH in the secure storage TS, and updates the previously saved block hash value BH.
  • the data hash generation unit 120 determines whether or not the drive source of the vehicle A has been activated. If it is determined that it has not started, it waits until it is determined that it has started. On the other hand, if it is determined that the transaction has been started, the data block creation unit 110 creates a new transaction in S250. In the following S255, the data hash generation unit 120 generates a new data hash value based on the block hash value BH stored in the secure storage TS and the new transaction. Further, in S260, the transmission processing unit 160 transmits the generated new transaction and the block hash value BH of the final block to the ECU in charge of verification.
  • the block generation unit 140 determines whether or not a majority vote agreement has been formed based on the judgment information from each in-vehicle ECU. When it is determined that a majority agreement has been formed, in S280, the block generation unit 140 generates a new block BL and adds it to the blockchain BC. After executing the process of S280, the blockchain generation process shown in FIG. 4 may be started. On the other hand, if it is determined in S270 that the majority agreement has not been formed, in S290, the block generation unit 140 stops the generation of the new block BL.
  • the block storage processing unit 190 determines whether or not the drive source of the vehicle A has stopped. If it is determined that it has not stopped, it waits until it is determined that it has stopped. On the other hand, if it is determined that the block has stopped, the block hash storage processing unit 170 generates the block hash value BH from the final block of the blockchain BC distributed from the ECU to be verified in S320. Next, in S330, the block hash storage processing unit 170 saves the generated block hash value BH in the secure storage TS, and updates the previously saved block hash value.
  • the verification execution unit 180 determines whether or not the drive source of the vehicle A has been activated. If it is determined that it has not started, it waits until it is determined that it has started. On the other hand, if it is determined that the operation has been started, the verification execution unit 180 acquires a new transaction and a data hash value from the verification target ECU in S350.
  • the verification execution unit 180 determines whether or not to approve the ECU to be verified. If it is determined to approve, in S361, the verification execution unit 180 transmits the determination information to approve the addition of the new block BL to the other in-vehicle ECU 100.
  • the verification execution unit 180 transmits the determination information that the addition of the new block BL is not approved to the other in-vehicle ECU 100.
  • Subsequent processing of S370, S380, and S390 is equivalent to processing of S270, S280, and S290 in FIG.
  • the processing of S370, S380, and S390 is executed by the block storage processing unit 190.
  • S140 and S150 are examples of the "block generation process”
  • S210, S220 and S230 are examples of the “storage processing process”
  • S120 and S255 are examples of the “data hash generation process”
  • S160 and S260 are examples of the "transmission process”.
  • the final block hash value stored in the storage area is updated at each specific update timing. If the data is tampered with due to the installation of a fake in-vehicle ECU, the final block hash value and the new data hash value will be different from the original ones. Can be verified. Furthermore, since these values change at each update timing, falsification can be detected even if these values are leaked at the update timing before the previous time. From the above, it may be possible to make it difficult to falsify the data.
  • new data and new data hash values are transmitted as verification information to three or more other in-vehicle ECUs 100. Then, when it is determined that a majority vote has been reached by the three or more other in-vehicle ECUs 100, a new block BL based on the new data hash value and the block hash value BH is generated and connected to the blockchain BC. According to this, since the credibility is judged by a majority vote agreement in three or more other in-vehicle ECUs 100, the credibility is ensured as compared with the case where the credibility is judged by two or less other in-vehicle ECUs 100. Greater certainty.
  • the final block hash value stored in the secure storage TS is updated at the stop timing of the drive source of the vehicle A. Therefore, the final block hash value can be updated at the timing when the stop period of the vehicle A, which is relatively likely to be equipped with a fake in-vehicle ECU, is entered. Therefore, tampering with a fake in-vehicle ECU 100 can be more reliably difficult.
  • the data hash generation unit 120 of the second embodiment uses preset key information in addition to the block hash value BH to generate a new data hash value.
  • the key information is, for example, the MAC address MA, which is identification information uniquely assigned to each in-vehicle ECU 100.
  • the MAC address MA is stored in the normal storage US.
  • the key information may be an arbitrary key value set in advance at the time of manufacturing the in-vehicle ECU 100.
  • the data hash generation unit 120 obtains a new data hash value by synthesizing a new transaction, a block hash value BH, and a MAC address MA and inputting them into a hash function.
  • the data hash generation unit 120 executes the above processing after the activation of the drive source is determined and a new transaction is generated (S256).
  • the preset key information is further used to generate a new data hash value. Therefore, it may be more difficult for a fake in-vehicle ECU to generate a fake new data hash value. Therefore, it is possible to more reliably determine the falsification by the fake in-vehicle ECU.
  • Disclosures include exemplary embodiments and modifications by those skilled in the art based on them.
  • the disclosure is not limited to the parts and / or combinations of elements shown in the embodiments. Disclosure can be carried out in various combinations.
  • the disclosure can have additional parts that can be added to the embodiment. Disclosures include those in which the parts and / or elements of the embodiment are omitted. Disclosures include the replacement or combination of parts and / or elements between one embodiment and another.
  • the technical scope disclosed is not limited to the description of the embodiments. Some technical scopes disclosed are indicated by the claims description and should be understood to include all modifications within the meaning and scope equivalent to the claims description.
  • the in-vehicle ECU 100 saves the operation history data HD of the driver as acquisition data, but data other than the operation history data HD may be saved.
  • the vehicle-mounted ECU 100 may store the mileage, travel route, travel behavior, and the like of the vehicle A.
  • the hash storage processing unit 150 determines that it is the stop timing when the stop signal capable of determining the stop of the drive source is acquired. Instead of this, the hash storage processing unit 150 may determine that the stop timing is reached when a predetermined time has elapsed from the acquisition of the stop signal. Alternatively, the hash storage processing unit 150 may determine that it is the stop timing when the stop signal is acquired and the power switch (ignition switch or the like) of the vehicle A is off.
  • the vehicle-mounted ECU 100 updates the block hash value BH of the secure storage TS at the stop timing of the drive source of the vehicle A.
  • the vehicle-mounted ECU 100 may update the block hash value BH at regular time intervals.
  • the in-vehicle ECU 100 may update the block hash value BH each time a new block is generated.
  • the in-vehicle ECU 100 may update the block hash value BH at the timing when the shift position of the vehicle A is set in the parking range, and updates the block hash value BH at the timing when the instruction signal is received from the server. May be good.
  • the verification target ECU transmits a new transaction and a new data hash value to three or more verification charge ECUs.
  • the verification target ECU may send a new transaction and a new data hash value to two or less verification ECUs.
  • the approval of the ECU to be verified may be performed by a method other than the majority vote agreement.
  • the in-vehicle ECU 100 executes the data storage process.
  • a data storage device mounted on a moving body other than the vehicle A may execute the data storage process.
  • Moving objects include ships, airplanes, railroad vehicles, and the like.
  • the block generation unit 140 is assumed to generate a block BL by combining a data hash value and a block hash value. Instead of this, the block generation unit 140 may generate a block BL by a combination of a transaction and a block hash value. Alternatively, the block generation unit 140 may generate a block BL by combining a transaction, a data hash value, and a block hash value.
  • the data hash generation unit 120 determines that each time a transaction is generated, the block hash value and the transaction are combined and converted into a data hash value. Instead, the data hash generation unit 120 simply converts the transaction into a data hash value except immediately after the drive source is started, and immediately after the drive source is started, the data hash value is a combination of the block hash value and the transaction. It may be configured to convert to.
  • the transmission processing unit 160 transmits the transaction and the block hash value to the ECU in charge of verification. Instead, the transmission processing unit 160 may transmit the transaction and the data hash value generated from the transaction.
  • the in-vehicle ECU 100 may be a dedicated computer configured to include at least one of a digital circuit and an analog circuit as a processor.
  • digital circuits include, for example, ASIC (Application Specific Integrated Circuit), FPGA (Field Programmable Gate Array), SOC (System on a Chip), PGA (Programmable Gate Array), CPLD (Complex Programmable Logic Device), and the like. Of these, at least one. Further, such a digital circuit may include a memory for storing a program.
  • the in-vehicle ECU 100 may be provided by one computer or a set of computer resources linked by a data communication device.
  • a part of the functions provided by the in-vehicle ECU 100 in the above-described embodiment may be realized by another ECU.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

車載ＥＣＵ（１００）は、ブロックチェーン（ＢＣ）に連結する新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成するブロック生成部（１４０）を備える。車載ＥＣＵ（１００）は、保存処理部（１５０）を備える。保存処理部（１５０）は、特定の更新タイミングごとにブロックチェーン（ＢＣ）の最終ブロックに基づく最終ブロックハッシュ値をセキュアワールドのストレージ領域（ＴＳ）に保存することで、前回の更新タイミングにて保存した最終ブロックハッシュ値を更新する。車載ＥＣＵ（１００）は、少なくとも更新タイミングごとに、取得データと最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成するデータハッシュ生成部（１２０）を備える。

Description

データ保存装置、データ保存方法、およびデータ保存プログラム 関連出願の相互参照
　この出願は、２０２０年１２月２５日に日本に出願された特許出願第２０２０－２１６３９９号を基礎としており、基礎の出願の内容を、全体的に、参照により援用している。
　この明細書における開示は、移動体にて取得されるデータを保存する技術に関する。
　非特許文献１には、車載ＥＣＵに対して暗号鍵を付与し、当該暗号鍵に基づいて正規ＥＣＵの認証を行う技術が開示されている。
国際交通安全学会誌　Ｖｏｌ．４２，Ｎｏ．２，２０１７年１０月、３９頁～４７頁
　しかし、車載ＥＣＵに暗号鍵を付与したとしても、当該暗号鍵が漏洩した場合、偽の車載ＥＣＵの取り付け等によるデータの改ざんが容易となる虞がある。非特許文献１には、こうした状況への対策について何ら開示されていない。
　開示される目的は、データの改ざんを困難にすることが可能なデータ保存装置、データ保存方法、およびデータ保存プログラムを提供することである。
　この明細書に開示された複数の態様は、それぞれの目的を達成するために、互いに異なる技術的手段を採用する。また、請求の範囲およびこの項に記載した括弧内の符号は、ひとつの態様として後述する実施形態に記載の具体的手段との対応関係を示す一例であって、技術的範囲を限定するものではない。
　開示されたデータ保存装置のひとつは、移動体に搭載され、ノーマルワールドおよびノーマルワールドからのアクセスが制限されるセキュアワールドを規定し、移動体にて取得される取得データを、ブロックチェーンを用いて保存するデータ保存装置であって、
　ブロックチェーンに連結する新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成するブロック生成部と、
　特定の更新タイミングごとにブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値をセキュアワールドのストレージ領域に保存することで、前回の更新タイミングにて保存した最終ブロックハッシュ値を更新する保存処理部と、
　少なくとも更新タイミングごとに、取得データと最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成するデータハッシュ生成部と、
　を備える。
　開示されたデータ保存方法のひとつは、移動体に搭載され、ノーマルワールドおよびノーマルワールドからのアクセスが制限されるセキュアワールドを規定し、移動体にて取得される取得データを、ブロックチェーンを用いて保存するために、プロセッサにより実行されるデータ保存方法であって、
　ブロックチェーンに連結する新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成するブロック生成プロセスと、
　特定の更新タイミングごとに、ブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値をセキュアワールドのストレージ領域に保存することで、前回の更新タイミングにて保存した最終ブロックハッシュ値を更新する保存処理プロセスと、
　少なくとも更新タイミングごとに、取得データと最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成するデータハッシュ生成プロセスと、
　を含む。
　開示されたデータ保存プログラムのひとつは、移動体に搭載され、ノーマルワールドおよびノーマルワールドからのアクセスが制限されるセキュアワールドを規定し、移動体にて取得される取得データを、ブロックチェーンを用いて保存するために、プロセッサに実行させる命令を含むデータ保存プログラムであって、
　命令は、
　ブロックチェーンに連結させる新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成させるブロック生成プロセスと、
　特定の更新タイミングごとに、ブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値をセキュアワールドのストレージ領域に保存することで、前回の更新タイミングにて保存した最終ブロックハッシュ値を更新させる保存処理プロセスと、
　少なくとも更新タイミングごとに、取得データと最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成させるデータハッシュ生成プロセスと、
　を含む。
　これらの開示によれば、特定の更新タイミングごとに、ストレージ領域に保存された最終ブロックハッシュ値が更新される。偽のデータ保存装置の取り付け等によりデータが改ざんされた場合には、最終ブロックハッシュ値および新規データハッシュ値が本来のものと異なったものとなるため、これらの値の少なくとも一方に基づいて改ざんの有無を検証することが可能となり得る。さらに、これらの値は更新タイミングごとに変化するため、前回以前の更新タイミングにおけるこれらの値が漏洩したとしても、改ざんが検知され得る。以上により、データの改ざんを困難にすることが可能なデータ保存装置、データ保存方法、およびデータ保存プログラムが提供され得る。
車載ＥＣＵが有する機能の一例を示すブロック図である。 データ保存方法の一例を示す概念図である。 ブロックハッシュ値の更新方法の一例を示す概念図である。 データ保存方法のうち、ブロックチェーンの生成処理の一例を示すフローチャートである。 データ保存方法のうち、検証対象のＥＣＵにて実行される処理の一例を示すフローチャートである。 データ保存方法のうち、検証担当のＥＣＵにて実行される処理の一例を示すフローチャートである。 第２実施形態の車載ＥＣＵが有する機能の一例を示すブロック図である。 第２実施形態のデータ保存方法のうち、検証対象のＥＣＵにて実行される処理の一例を示すフローチャートである。
　（第１実施形態）
　第１実施形態のデータ保存装置について、図１～図６を参照しながら説明する。第１実施形態のデータ保存装置は、移動体の一例である車両Ａに搭載された電子制御装置である車載ＥＣＵ１００によって提供される。車載ＥＣＵ１００は、車両Ａにて取得される取得データ、特に車両Ａの操作履歴データＨＤを保存する。
　車載ＥＣＵ１００は、車両Ａに複数台、例えば４台以上搭載されている情報処理装置である。複数の車載ＥＣＵ１００は、Ｅｔｈｅｒｎｅｔ（登録商標）等の通信規格に従う車載ネットワークを介して互いに通信可能である。車載ＥＣＵ１００は、それぞれ、後述する取得データの保存および検証以外の処理機能を実行可能である。例えば、車載ＥＣＵ１００は、自動運転機能、高度運転支援機能、周辺監視機能等を実行可能であってよい。また、車載ＥＣＵ１００の１つは、車両制御ＥＣＵ２０（後述）によって提供されてもよい。車載ＥＣＵ１００は、車載センサ１０および車両制御ＥＣＵ２０と車載ネットワークを介して接続されている。
　車載センサ１０は、車両Ａに搭載される種々の検出構成である。車載センサ１０には、ドライバによる車両Ａの操作を検出可能なセンサが含まれる。例えば、車載センサ１０には、アクセルペダルの踏み込み量を検出するアクセルペダルセンサ、ブレーキペダルの踏み込み量を検出するブレーキペダルセンサ、ステアリングハンドルの操作量を検出するステアセンサ等が含まれる。各車載センサ１０は、検出したデータを少なくとも１つの車載ＥＣＵ１００に提供可能である。なお、車載センサ１０は、検出データを収集する他のＥＣＵを介して、間接的に車載ＥＣＵ１００に検出データを提供してもよい。
　車載ＥＣＵ１００は、車両Ａに搭載された複数の電子制御装置である。車載ＥＣＵ１００のうち少なくとも１つは、上述の車載センサ１０からの取得データおよびブロックチェーンＢＣを保存するデータ保存装置である。他の車載ＥＣＵ１００は、ブロックチェーンＢＣを保存し、当該ブロックチェーンＢＣの信憑性を検証する。以下において、前者の車載ＥＣＵ１００を、「検証対象のＥＣＵ」、後者の車載ＥＣＵ１００を「検証担当のＥＣＵ」と表記する場合がある。
　車載ＥＣＵ１００は、メモリ１０１、プロセッサ１０２、入出力インターフェース、およびこれらを接続するバス等を備えたコンピュータを主体として含む構成である。プロセッサ１０２は、演算処理のためのハードウェアである。プロセッサ１０２は、例えばＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）およびＲＩＳＣ（Reduced Instruction Set Computer）－ＣＰＵ等のうち、少なくとも一種類をコアとして含む。
　車載ＥＣＵ１００は、ノーマルワールドＮＷおよびセキュアワールドＳＷという少なくとも二つの異なる処理領域をシステム内に規定する。ノーマルワールドＮＷおよびセキュアワールドＳＷは、ハードウェア上で物理的に分離されていてもよく、またはハードウェアおよびソフトウェアの連携によって仮想的に分離されていてもよい。車載ＥＣＵ１００は、コンテキストスイッチ等の機能を利用し、アプリケーションの実行に必要なリソースを、ノーマルワールドＮＷおよびセキュアワールドＳＷに時間的に分離させている。
　ノーマルワールドＮＷは、オペレーションシステムおよびアプリケーションを実行させる通常の領域である。ノーマルワールドＮＷには、データ保存のためのストレージ領域（Untrusted Storage）として、ノーマルストレージＵＳが設けられている。
　セキュアワールドＳＷは、ノーマルワールドＮＷから隔離された領域である。セキュアワールドＳＷでは、セキュリティを要求される処理のためのセキュアなオペレーションシステムおよびアプリケーションが実行される。ノーマルワールドＮＷからセキュアワールドＳＷへのアクセスは、プロセッサ１０２の機能によって制限されている。そのため、ノーマルワールドＮＷからは、セキュアワールドＳＷの存在が認識不可能となり、セキュアワールドＳＷにて実行される処理およびセキュアワールドＳＷに保存された情報等の安全性が確保される。セキュアワールドＳＷには、データ保存のためのストレージ領域（Trusted Storage）として、セキュアストレージＴＳが設けられている。セキュアストレージＴＳの容量は、ノーマルストレージＵＳの容量よりも少なくされてよい。または、セキュアストレージＴＳの容量は、ノーマルストレージＵＳの容量と同等以上であってもよい。
　メモリ１０１は、コンピュータにより読み取り可能なプログラムおよびデータ等を非一時的に格納または記憶する、例えば半導体メモリ、磁気媒体および光学媒体等のうち、少なくとも一種類の非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。メモリ１０１は、後述のデータ保存プログラム等、プロセッサ１０２によって実行される種々のプログラムを格納している。
　プロセッサ１０２は、メモリ１０１に格納されたデータ保存プログラムに含まれる複数の命令を、実行する。これにより車載ＥＣＵ１００は、データ保存のための機能部を、複数構築する。このように車載ＥＣＵ１００では、メモリ１０１に格納されたデータ保存プログラムが複数の命令をプロセッサ１０２に実行させることで、複数の機能部が構築される。具体的に、車載ＥＣＵ１００には、図１に示すように、データブロック作成部１１０、データハッシュ生成部１２０、ブロックハッシュ生成部１３０、ブロック生成部１４０、ハッシュ保存処理部１５０および送信処理部１６０が構築される。加えて、車載ＥＣＵ１００には、図１に示すようにブロックハッシュ保存処理部１７０、検証実行部１８０およびブロック保存処理部１９０等が構築される。
　以上の機能部のうち、データブロック作成部１１０、データハッシュ生成部１２０、ブロックハッシュ生成部１３０、ブロック生成部１４０、ハッシュ保存処理部１５０および送信処理部１６０は、検証対象のＥＣＵにて構築される機能部である。また、ブロックハッシュ保存処理部１７０、検証実行部１８０およびブロック保存処理部１９０は、検証担当のＥＣＵにて構築される機能部である。図１においては、それぞれを異なる車載ＥＣＵ１００の機能として記載しているが、各車載ＥＣＵ１００は、検証対象および検証担当を兼任することも可能である。
　データブロック作成部１１０は、車載センサ１０にて検出された検出データを、ドライバの操作履歴データＨＤとして取得し、データブロックを作成する。なお、以下においてデータブロックをトランザクションと表記する場合がある。トランザクションは、規定サイズの操作履歴データＨＤをひとまとめに格納する単位である。データブロック作成部１１０は、車両Ａの駆動源の起動中に定期的にトランザクションを作成する。データブロック作成部１１０は、作成したトランザクションを、後述のブロックチェーンＢＣに連結されるブロックＢＬと紐づけた状態でノーマルストレージＵＳに保存する。データブロック作成部１１０は、作成したトランザクションをデータハッシュ生成部１２０およびブロック生成部１４０に提供する。
　データブロック作成部１１０は、車両Ａの駆動源が停止したと判断すると、トランザクションの作成を中止する。データブロック作成部１１０は、車両Ａの駆動源が起動したと判断すると、トランザクションの作成を再開する。以下において、新たに生成されるトランザクションを、特に「新規トランザクション」と表記する場合がある。なお、ここで駆動源起動直後とは、駆動源が起動した後で車載ＥＣＵ１００の信憑性が確保される前のタイミングである。また、駆動源起動直後とは、駆動源が起動した後で初めてデータブロックを生成するタイミングであるということもできる。このタイミングは、「第２タイミング」の一例である。
　データハッシュ生成部１２０は、作成されたトランザクションに基づくハッシュ値を、データハッシュ値として生成する。
　具体的には、データハッシュ生成部１２０は、図２に示すように、セキュアストレージＴＳに保存されたブロックハッシュ値ＢＨ（ＢＨ＿１）と、トランザクションとを合成したものを、データハッシュ値に変換する。この処理は、トランザクションに対して電子署名を施す処理と解することができる。以下において、新たに生成されたデータハッシュ値を、特に「新規データハッシュ値」と表記する場合がある。データハッシュ生成部１２０は、データハッシュ値をブロック生成部１４０へと提供する。
　ブロックハッシュ生成部１３０は、ブロックチェーンＢＣに連結された最後のブロックＢＬである最終ブロックに基づくハッシュ値を、ブロックハッシュ値ＢＨとして生成する。このブロックハッシュ値ＢＨが「最終ブロックハッシュ値」の一例である。図２に示す例では、最終ブロックは「ＢＬＯＣＫ３」、ブロックハッシュ値ＢＨは「ＢＨ＿３」である。ブロックハッシュ生成部１３０は、単にブロックをハッシュ関数にてブロックハッシュ値ＢＨに変換すればよい。ブロックハッシュ生成部１３０は、ブロックハッシュ値ＢＨをブロック生成部１４０および送信処理部１６０に提供する。
　以上のデータハッシュ生成部１２０およびブロックハッシュ生成部１３０は、ハッシュ値の生成において、暗号学的ハッシュ関数を利用する。暗号学的ハッシュ関数は、違う入力から同一のハッシュ値を出力することがなく、且つ、出力されたハッシュ値から入力を推測することが実質不可能という特性を有している。例えば、ＳＨＡ－２のひとつであるＳＨＡ－２５６が、暗号学的ハッシュ関数として使用される。または、ＳＨＡ－１、ＳＨＡ－２５６以外のＳＨＡ－２およびＳＨＡ－３等の暗号学的ハッシュ関数が、必要とされる出力長（ビット数）に合わせて適宜使用されてよい。
　ブロック生成部１４０は、データハッシュ生成部１２０から取得したデータハッシュ値と、ブロックハッシュ生成部１３０から取得したブロックハッシュ値ＢＨとの組み合わせによるブロックＢＬを生成する。また、ブロック生成部１４０は、生成されたブロックをブロックチェーンＢＣの最後に連結して保存する。
　ここで、ブロック生成部１４０は、新規のブロックＢＬを連結する合意が形成された場合にのみ、以上の処理を実施する。詳記すると、ブロック生成部１４０は、まず検証担当のＥＣＵから送信された検証結果を取得する。例えば、ブロック生成部１４０は、３つ以上の他の車載ＥＣＵ１００にて実施された検証結果を取得する。検証結果には、車載ＥＣＵ１００の信憑性を承認するか否かを判断した判断情報が少なくとも含まれる。
　そして、ブロック生成部１４０は、取得された検証結果に基づいて、過半数の検証担当のＥＣＵにてデータの信憑性が承認された場合に、新規ブロックＢＬを生成し、当該ブロックＢＬを連結する。図２に示す例では、ＤＨ＿Ｄ（データハッシュ値）と、ＢＨ＿３（ブロックハッシュ値）との組み合わせによるＢＬＯＣＫ４が、新規ブロックとしてＢＬＯＣＫ３の後に連結される。ブロック生成部１４０は、過半数の検証担当のＥＣＵにてデータの信憑性が承認されなかった場合には、ブロックＢＬの連結を中断する。
　ハッシュ保存処理部１５０は、ブロックハッシュ値ＢＨを特定のタイミングでセキュアストレージＴＳに保存する。ハッシュ保存処理部１５０は、例えば、車両Ａの駆動源の停止タイミングを保存のタイミングとする。このとき、ハッシュ保存処理部１５０は、前回の停止タイミングにて保存されていたブロックハッシュ値ＢＨを、新たなブロックハッシュ値ＢＨで更新することになる。図３に示す例では、前回の停止タイミングでの最終ブロックであるＢＬＯＣＫ２から生成されたブロックハッシュ値であるＢＨ＿２が、今回の停止タイミングでの最終ブロックであるＢＬＯＣＫ４から生成されたブロックハッシュ値であるＢＨ＿４に更新される。ハッシュ保存処理部１５０は、例えば、車両制御ＥＣＵ２０から駆動源の停止を判断可能な信号（停止信号）を取得した場合に、停止タイミングであると判断する。停止信号は、駆動源が停止した状態を示す停止状態信号であってもよいし、駆動源の停止を指示する停止指示信号であってもよい。停止タイミングは、「更新タイミング」の一例である。
　送信処理部１６０は、ブロックチェーンＢＣの生成または車載ＥＣＵ１００の検証において、他の車載ＥＣＵ１００への提供が必要な情報の送信処理を実行する。具体的には、送信処理部１６０は、トランザクションと、その時点でのブロックチェーンＢＣの最終ブロックから生成されたブロックハッシュ値ＢＨとを他の車載ＥＣＵ１００へと送信する。なお、以下において、この検証対象のＥＣＵにて生成されたブロックハッシュ値ＢＨを、対象ブロックハッシュ値と表記する場合がある。送信処理部１６０は、「送信部」の一例である。
　ブロックハッシュ保存処理部１７０は、検証担当のＥＣＵにおいて、ブロックハッシュ値ＢＨを駆動源の停止タイミングでセキュアストレージＴＳに保存する。ブロックハッシュ保存処理部１７０は、自身のノーマルストレージＵＳに保存されたブロックチェーンＢＣの最終ブロックからブロックハッシュ値ＢＨを生成してもよいし、検証対象のＥＣＵからブロックハッシュ値ＢＨを取得してもよい。なお、ここでの「自身のノーマルストレージＵＳに保存されたブロックチェーンＢＣ」とは、検証対象のＥＣＵから分散されたブロックチェーンＢＣを意味する。
　検証実行部１８０は、検証対象のＥＣＵの信憑性を検証し、承認するか否かの判断情報を生成する。検証実行部１８０は、検証対象から送信された新規トランザクションおよび対象ブロックハッシュ値を取得し、これらの情報と、自身が保存する情報とに基づいて検証を実行する。検証実行部１８０は、自身のセキュアストレージＴＳに保存されたブロックハッシュ値ＢＨである担当ブロックハッシュ値と、検証対象から取得した新規トランザクションとに基づくデータハッシュ値（担当データハッシュ値）を生成する。
　一例として、検証実行部１８０は、自身の保存するブロックチェーンＢＣの最終ブロックから生成したブロックハッシュ値（担当ブロックハッシュ値）と、対象ブロックハッシュ値とが一致するか否かを判定する。一致すると判定すると、検証実行部１８０は、検証対象の信憑性を承認する旨の判断情報を生成する。一方で、一致しないと判定すると、検証実行部１８０は、検証対象の信憑性を承認しない旨の判断情報を生成する。検証実行部１８０は、生成した判断情報を、検証対象および検証担当のＥＣＵへと送信する。
　ブロック保存処理部１９０は、他の検証担当のＥＣＵから送信された検証結果を取得する。ブロック保存処理部１９０は、過半数の検証担当のＥＣＵにてデータの信憑性が承認された場合に、検証対象のＥＣＵから取得したトランザクションと自身のセキュアストレージＴＳに保存されたブロックハッシュ値ＢＨとからデータハッシュ値を生成する。ブロック保存処理部１９０は、当該データハッシュ値と、自身のブロックチェーンＢＣにおける最終ブロックから生成されたブロックハッシュ値ＢＨとでブロックを生成し、ノーマルストレージＵＳのブロックチェーンＢＣに連結して保存する。これにより、ブロック保存処理部１９０は、検証対象のＥＣＵから分散されたブロックチェーンＢＣを保持可能である。
　なお、ブロック保存処理部１９０は、当該新規ブロックＢＬを、検証対象のＥＣＵから取得してもよい。ブロック保存処理部１９０は、過半数の検証担当のＥＣＵにてデータの信憑性が承認されなかった場合には、ブロックＢＬの連結を中断する。
　次に、機能ブロックの共同により、車載ＥＣＵ１００が実行するデータ保存方法のフローを、図４～５に従って以下に説明する。なお、後述するフローにおいて「Ｓ」とは、プログラムに含まれた複数命令によって実行される、フローの複数ステップを意味する。
　まず、データ保存処理のうち、検証対象のＥＣＵが取得したデータに基づいてブロックチェーンＢＣを生成する処理について図４を参照して説明する。まず、Ｓ１１０にて、データブロック作成部１１０が、取得したデータに基づくトランザクションを生成する。次に、Ｓ１２０では、データハッシュ生成部１２０が、トランザクションに基づいてデータハッシュ値を生成する。
　続くＳ１３０では、ブロックハッシュ生成部１３０が、最終ブロックに基づいてブロックハッシュ値ＢＨを生成する。さらに、Ｓ１４０では、送信処理部１６０が、最終ブロックのブロックハッシュ値ＢＨと新規トランザクションとを検証担当のＥＣＵに送信する。そして、Ｓ１５０では、ブロック生成部１４０が、新規ブロックＢＬの連結について多数決合意が形成されたか否かを判定する。合意が形成されたと判定すると、本フローがＳ１６０へと移行する。Ｓ１６０では、ブロック生成部１４０が、新規ブロックＢＬを生成してブロックチェーンＢＣに連結する。Ｓ１６０の処理の後、本フローはＳ１１０へと戻る。
　一方で、Ｓ１５０にて合意が形成されなかったと判定されると、本フローがＳ１７０へと移行する。Ｓ１７０では、ブロック生成部１４０が、新規ブロックＢＬの生成を中止し、本フローが終了する。
　次に、データ保存処理のうち、データの信憑性を検証する処理について図５に従って説明する。まず、Ｓ２１０では、ブロックハッシュ生成部１３０が、車両Ａの駆動源が停止したか否かを判定する。停止していないと判定した場合、停止したと判定するまで待機する。一方で停止したと判定した場合には、Ｓ２２０にて、ブロックハッシュ生成部１３０が、最終ブロックからブロックハッシュ値ＢＨを生成する。次に、Ｓ２３０にて、ハッシュ保存処理部１５０が、生成したブロックハッシュ値ＢＨをセキュアストレージＴＳに保存し、前回保存されたブロックハッシュ値ＢＨを更新する。
　続くＳ２４０では、データハッシュ生成部１２０が、車両Ａの駆動源が起動したか否かを判定する。起動していないと判定した場合、起動したと判定するまで待機する。一方で起動したと判定した場合には、Ｓ２５０にて、データブロック作成部１１０が新規トランザクションを作成する。続くＳ２５５にて、データハッシュ生成部１２０が、セキュアストレージＴＳに保存されたブロックハッシュ値ＢＨと新規トランザクションとに基づく新規データハッシュ値を生成する。さらに、Ｓ２６０では、送信処理部１６０が、生成した新規トランザクションおよび最終ブロックのブロックハッシュ値ＢＨを、検証担当のＥＣＵへと送信する。
　そして、Ｓ２７０では、ブロック生成部１４０が、各車載ＥＣＵからの判断情報に基づき多数決合意が形成されたか否かを判定する。多数決合意が形成されたと判定した場合、Ｓ２８０にて、ブロック生成部１４０が、新規ブロックＢＬを生成してブロックチェーンＢＣに追加する。なお、Ｓ２８０の処理を実行した後は、図４に示すブロックチェーン生成処理を開始すればよい。一方で、Ｓ２７０にて多数決合意が形成されなかったと判定した場合、Ｓ２９０にて、ブロック生成部１４０は、新規ブロックＢＬの生成を中止する。
　次に、データ保存処理のうち、検証担当のＥＣＵにて実行される処理について図６に従って説明する。図６に示す処理は、車載ＥＣＵ１００の起動中に実行される。
　まず、Ｓ３１０では、ブロック保存処理部１９０が、車両Ａの駆動源が停止したか否かを判定する。停止していないと判定した場合、停止したと判定するまで待機する。一方で停止したと判定した場合には、Ｓ３２０にて、ブロックハッシュ保存処理部１７０が、検証対象のＥＣＵから分散されたブロックチェーンＢＣの最終ブロックからブロックハッシュ値ＢＨを生成する。次に、Ｓ３３０にて、ブロックハッシュ保存処理部１７０が、生成したブロックハッシュ値ＢＨをセキュアストレージＴＳに保存し、前回保存されたブロックハッシュ値を更新する。
　続くＳ３４０では、検証実行部１８０が、車両Ａの駆動源が起動したか否かを判定する。起動していないと判定した場合、起動したと判定するまで待機する。一方で起動したと判定した場合には、Ｓ３５０にて、検証実行部１８０が、検証対象のＥＣＵから新規トランザクションおよびデータハッシュ値を取得する。
　そして、Ｓ３６０では、検証実行部１８０が、検証対象のＥＣＵを承認するか否かを判定する。承認すると判定すると、Ｓ３６１にて、検証実行部１８０が、新たなブロックＢＬの追加を承認する旨の判断情報を他の車載ＥＣＵ１００へと送信する。
　一方で、Ｓ３６０にてデータハッシュ値が一致しないと判定すると、Ｓ３６２にて、検証実行部１８０が、新たなブロックＢＬの追加を非承認する旨の判断情報を他の車載ＥＣＵ１００へと送信する。続くＳ３７０、Ｓ３８０、Ｓ３９０の処理は、図５におけるＳ２７０、Ｓ２８０、Ｓ２９０の処理と同等である。Ｓ３７０、Ｓ３８０、Ｓ３９０の処理は、ブロック保存処理部１９０により実行される。
　なお、上述のＳ１４０，Ｓ１５０が「ブロック生成プロセス」、Ｓ２１０，Ｓ２２０，Ｓ２３０が「保存処理プロセス」、Ｓ１２０，Ｓ２５５が「データハッシュ生成プロセス」、Ｓ１６０，Ｓ２６０が「送信プロセス」の一例である。
　以上の第１実施形態によれば、特定の更新タイミングごとに、ストレージ領域に保存された最終ブロックハッシュ値が更新される。偽の車載ＥＣＵの取り付け等によりデータが改ざんされた場合には、最終ブロックハッシュ値および新規データハッシュ値が本来のものと異なったものとなるため、これらの値の少なくとも一方に基づいて改ざんの有無を検証することが可能となり得る。さらに、これらの値は更新タイミングごとに変化するため、前回以前の更新タイミングにおけるこれらの値が漏洩したとしても、改ざんが検知され得る。以上により、データの改ざんを困難にすることが可能となり得る。
　また、第１実施形態によれば、３つ以上の他の車載ＥＣＵ１００に対して新規データおよび新規データハッシュ値が検証情報として送信される。そして、３つ以上の他の車載ＥＣＵ１００にて多数決合意が取れたと判断された場合に、新規データハッシュ値およびブロックハッシュ値ＢＨに基づく新規ブロックＢＬが生成され、ブロックチェーンＢＣに連結される。これによれば、３つ以上の他の車載ＥＣＵ１００における多数決合意にて信憑性が判断されるので、２つ以下の他の車載ＥＣＵ１００にて信憑性を判断する場合に比べて、信憑性確保の確実性が大きくなる。
　加えて、第１実施形態によれば、車両Ａの駆動源の停止タイミングにて、セキュアストレージＴＳに保存されている最終ブロックハッシュ値が更新される。故に、偽の車載ＥＣＵを取り付けられる可能性が比較的高い車両Ａの停止期間に入るタイミングにて最終ブロックハッシュ値が更新され得る。したがって、偽の車載ＥＣＵ１００による改ざんがより確実に困難になり得る。
　（第２実施形態）
　第２実施形態では、第１実施形態における車載ＥＣＵ１００の変形例について説明する。図７および図８において第１実施形態の図面中と同一符号を付した構成要素は、同様の構成要素であり、同様の作用効果を奏するものである。
　第２実施形態のデータハッシュ生成部１２０は、新規データハッシュ値の生成に、ブロックハッシュ値ＢＨに加えて予め設定された鍵情報を利用する。鍵情報は、例えば、車載ＥＣＵ１００ごとに固有に付与された識別情報であるＭＡＣアドレスＭＡとされる。ＭＡＣアドレスＭＡは、ノーマルストレージＵＳに保存されている。または、鍵情報は、車載ＥＣＵ１００の製造時に予め設定された任意の鍵値であってもよい。データハッシュ生成部１２０は、新規トランザクション、ブロックハッシュ値ＢＨおよびＭＡＣアドレスＭＡを合成してハッシュ関数に入力することで、新規データハッシュ値を得る。データハッシュ生成部１２０は、駆動源の起動が判定されて新規トランザクションを生成した後に、以上の処理を実行する（Ｓ２５６）。
　第２実施形態の車載ＥＣＵ１００によれば、予め設定された鍵情報が、さらに新規データハッシュ値の生成に利用される。故に、偽の車載ＥＣＵによる偽の新規データハッシュ値の生成がより困難になり得る。したがって、偽の車載ＥＣＵによる改ざんを一層確実に判別し得る。
　（他の実施形態）
　この明細書における開示は、例示された実施形態に制限されない。開示は、例示された実施形態と、それらに基づく当業者による変形態様を包含する。例えば、開示は、実施形態において示された部品および／または要素の組み合わせに限定されない。開示は、多様な組み合わせによって実施可能である。開示は、実施形態に追加可能な追加的な部分をもつことができる。開示は、実施形態の部品および／または要素が省略されたものを包含する。開示は、ひとつの実施形態と他の実施形態との間における部品および／または要素の置き換え、または組み合わせを包含する。開示される技術的範囲は、実施形態の記載に限定されない。開示されるいくつかの技術的範囲は、請求の範囲の記載によって示され、さらに請求の範囲の記載と均等の意味および範囲内での全ての変更を含むものと解されるべきである。
　上述の実施形態において、車載ＥＣＵ１００は、ドライバの操作履歴データＨＤを取得データとして保存するとしたが、操作履歴データＨＤ以外のデータを保存してもよい。例えば、車載ＥＣＵ１００は、車両Ａの走行距離、走行経路および走行挙動等を保存してもよい。
　上述の実施形態において、ハッシュ保存処理部１５０は、駆動源の停止を判断できる停止信号を取得した場合に、停止タイミングであると判断するとした。これに代えて、ハッシュ保存処理部１５０は、停止信号の取得から所定の時間経過した場合に停止タイミングであると判断してもよい。または、ハッシュ保存処理部１５０は、停止信号を取得し且つ車両Ａの電源スイッチ（イグニッションスイッチ等）がオフである場合に、停止タイミングであると判断してもよい。
　上述の実施形態において、車載ＥＣＵ１００は、車両Ａの駆動源の停止タイミングにてセキュアストレージＴＳのブロックハッシュ値ＢＨを更新するとした。これに代えて、車載ＥＣＵ１００は、一定時間ごとにブロックハッシュ値ＢＨの更新を実行してもよい。または、車載ＥＣＵ１００は、新規ブロックを生成するたびにブロックハッシュ値ＢＨを更新してもよい。また、車載ＥＣＵ１００は、車両Ａのシフト位置がパーキングレンジにセットされたタイミングにてブロックハッシュ値ＢＨを更新してもよく、サーバから指示信号を受けたタイミングにてブロックハッシュ値ＢＨを更新してもよい。
　上述の実施形態において、検証対象のＥＣＵは、３つ以上の検証担当のＥＣＵに対して新規トランザクションおよび新規データハッシュ値を送信するとした。これに代えて、検証対象のＥＣＵは、２つ以下の検証担当のＥＣＵに新規トランザクションおよび新規データハッシュ値を送信してもよい。この場合、検証対象のＥＣＵの承認は、多数決合意以外の手法で行われればよい。
　上述の実施形態において、車載ＥＣＵ１００がデータ保存処理を実行するとした。これに代えて、車両Ａ以外の移動体に搭載されたデータ保存装置がデータ保存処理を実行してもよい。移動体には、船舶、飛行機、鉄道車両等が含まれる。
　上述の実施形態において、ブロック生成部１４０は、データハッシュ値とブロックハッシュ値との組み合わせによるブロックＢＬを生成するとした。これに代えて、ブロック生成部１４０は、トランザクションとブロックハッシュ値の組み合わせによるブロックＢＬを生成してもよい。または、ブロック生成部１４０はトランザクション、データハッシュ値およびブロックハッシュ値の組み合わせによるブロックＢＬを生成してもよい。
　上述の実施形態において、データハッシュ生成部１２０は、トランザクションが生成されるたびに、ブロックハッシュ値とトランザクションとを合成したものを、データハッシュ値に変換するとした。これに代えて、データハッシュ生成部１２０は、駆動源起動直後以外は、単にトランザクションをデータハッシュ値に変換し、駆動源起動直後には、ブロックハッシュ値とトランザクションとを合成したものをデータハッシュ値に変換する構成であってもよい。
　上述の実施形態において、送信処理部１６０は、トランザクションとブロックハッシュ値を検証担当のＥＣＵに送信するとした。これに代えて、送信処理部１６０は、トランザクションと当該トランザクションから生成されたデータハッシュ値とを送信してもよい。
　車載ＥＣＵ１００は、デジタル回路およびアナログ回路のうち少なくとも一方をプロセッサとして含んで構成される、専用のコンピュータであってもよい。ここで特にデジタル回路とは、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＳＯＣ（System on a Chip）、ＰＧＡ（Programmable Gate Array）、およびＣＰＬＤ（Complex Programmable Logic Device）等のうち、少なくとも一種類である。またこうしたデジタル回路は、プログラムを格納したメモリを、備えていてもよい。
　車載ＥＣＵ１００は、１つのコンピュータ、またはデータ通信装置によってリンクされた一組のコンピュータ資源によって提供され得る。例えば、上述の実施形態における車載ＥＣＵ１００の提供する機能の一部は、他のＥＣＵによって実現されてもよい。

Claims (9)

  1. 　移動体（Ａ）に搭載され、ノーマルワールド（ＮＷ）および前記ノーマルワールドからのアクセスが制限されるセキュアワールド（ＳＷ）を規定し、前記移動体にて取得される取得データを、ブロックチェーン（ＢＣ）を用いて保存するデータ保存装置であって、
    　前記ブロックチェーンに連結する新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成するブロック生成部（１４０）と、
    　特定の更新タイミングごとに前記ブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値を前記セキュアワールドのストレージ領域（ＴＳ）に保存することで、前回の前記更新タイミングにて保存した前記最終ブロックハッシュ値を更新する保存処理部（１５０）と、
    　少なくとも前記更新タイミングごとに、前記取得データと前記最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成するデータハッシュ生成部（１２０）と、
    　を備えるデータ保存装置。
  2. 　前記移動体に搭載された３つ以上の他の情報処理装置に対して、前記ブロックチェーンに前記新規ブロックを連結してよいか否かを検証させるための検証情報を送信する送信部（１６０）をさらに備え、
    　前記ブロック生成部は、３つ以上の前記情報処理装置にて前記新規ブロックの連結について多数決合意が取れたと判断した場合に、前記新規ブロックを前記ブロックチェーンへ連結する請求項１に記載のデータ保存装置。
  3. 　前記保存処理部は、前記移動体における駆動源の停止タイミングにて、前記最終ブロックハッシュ値の更新を実行する請求項１または請求項２に記載のデータ保存装置。
  4. 　前記データハッシュ生成部は、予め設定された鍵情報を、さらに前記データハッシュ値の生成に利用する請求項１から請求項３のいずれか１項に記載のデータ保存装置。
  5. 　移動体（Ａ）に搭載され、ノーマルワールド（ＮＷ）および前記ノーマルワールドからのアクセスが制限されるセキュアワールド（ＳＷ）を規定し、前記移動体にて取得される取得データを、ブロックチェーン（ＢＣ）を用いて保存するために、プロセッサ（１０２）により実行されるデータ保存方法であって、
    　前記ブロックチェーンに連結する新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成するブロック生成プロセス（Ｓ１４０，Ｓ１５０）と、
    　特定の更新タイミングごとに、前記ブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値を前記セキュアワールドのストレージ領域（ＴＳ）に保存することで、前回の前記更新タイミングにて保存した前記最終ブロックハッシュ値を更新する保存処理プロセス（Ｓ２１０，Ｓ２２０，Ｓ２３０）と、
    　少なくとも前記更新タイミングごとに、前記取得データと前記最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成するデータハッシュ生成プロセス（Ｓ１２０，Ｓ２５５）と、
    　を含むデータ保存方法。
  6. 　前記移動体に搭載された３つ以上の他の情報処理装置に対して、前記ブロックチェーンに前記新規ブロックを連結してよいか否かを検証させるための検証情報を送信する送信プロセス（Ｓ１６０，Ｓ２６０）をさらに含み、
    　前記ブロック生成プロセスでは、３つ以上の前記情報処理装置にて前記新規ブロックの連結について多数決合意が取れたと判断した場合に、前記新規ブロックを前記ブロックチェーンへ連結する請求項５に記載のデータ保存方法。
  7. 　前記保存処理プロセスでは、前記移動体における駆動源の停止タイミングにて、前記最終ブロックハッシュ値の更新を実行する請求項５または請求項６に記載のデータ保存方法。
  8. 　前記データハッシュ生成プロセスでは、予め設定された鍵情報を、さらに前記データハッシュ値の生成に利用する請求項５から請求項７のいずれか１項に記載のデータ保存方法。
  9. 　移動体（Ａ）に搭載され、ノーマルワールド（ＮＷ）および前記ノーマルワールドからのアクセスが制限されるセキュアワールド（ＳＷ）を規定し、前記移動体にて取得される取得データを、ブロックチェーン（ＢＣ）を用いて保存するために、プロセッサ（１０２）に実行させる命令を含むデータ保存プログラムであって、
    　前記命令は、
    　前記ブロックチェーンに連結させる新規ブロックを、少なくとも直前のブロックから生成されたブロックハッシュ値に基づいて生成させるブロック生成プロセス（Ｓ１４０，Ｓ１５０）と、
    　特定の更新タイミングごとに、前記ブロックチェーンの最後に連結された最終ブロックに基づく最終ブロックハッシュ値を前記セキュアワールドのストレージ領域（ＴＳ）に保存することで、前回の前記更新タイミングにて保存した前記最終ブロックハッシュ値を更新させる保存処理プロセス（Ｓ２１０，Ｓ２２０，Ｓ２３０）と、
    　少なくとも前記更新タイミングごとに、前記取得データと前記最終ブロックハッシュ値とに基づくハッシュ値であるデータハッシュ値を生成させるデータハッシュ生成プロセス（Ｓ１２０，Ｓ２５５）と、
    　を含むデータ保存プログラム。
PCT/JP2021/042863 2020-12-25 2021-11-23 データ保存装置、データ保存方法、およびデータ保存プログラム WO2022137945A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180086419.1A CN116710917A (zh) 2020-12-25 2021-11-23 数据保存装置、数据保存方法、以及数据保存程序
US18/339,113 US20230336356A1 (en) 2020-12-25 2023-06-21 Data storage device, data storage method, and non-transitory computer readable storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020216399A JP7472781B2 (ja) 2020-12-25 2020-12-25 データ保存装置、データ保存方法、およびデータ保存プログラム
JP2020-216399 2020-12-25

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/339,113 Continuation US20230336356A1 (en) 2020-12-25 2023-06-21 Data storage device, data storage method, and non-transitory computer readable storage medium

Publications (1)

Publication Number Publication Date
WO2022137945A1 true WO2022137945A1 (ja) 2022-06-30

Family

ID=82159075

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/042863 WO2022137945A1 (ja) 2020-12-25 2021-11-23 データ保存装置、データ保存方法、およびデータ保存プログラム

Country Status (4)

Country Link
US (1) US20230336356A1 (ja)
JP (1) JP7472781B2 (ja)
CN (1) CN116710917A (ja)
WO (1) WO2022137945A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023019048A (ja) * 2021-07-28 2023-02-09 トヨタ自動車株式会社 センタ、方法、及びプログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018133744A (ja) * 2017-02-16 2018-08-23 パナソニックＩｐマネジメント株式会社 通信システム、車両、および監視方法
JP2020525877A (ja) * 2019-04-03 2020-08-27 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ 信頼できる実行環境下でのブロックチェーンデータの処理および保存
JP2021013122A (ja) * 2019-07-08 2021-02-04 株式会社デンソー データ保存装置、及びデータ保存プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018133744A (ja) * 2017-02-16 2018-08-23 パナソニックＩｐマネジメント株式会社 通信システム、車両、および監視方法
JP2020525877A (ja) * 2019-04-03 2020-08-27 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ 信頼できる実行環境下でのブロックチェーンデータの処理および保存
JP2021013122A (ja) * 2019-07-08 2021-02-04 株式会社デンソー データ保存装置、及びデータ保存プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OKABE, TATSUYA; MITANI, AKIRA; XU, XIN; SAKAMOTO, HAYATO; MIZUMA, SATOSHI; NAMIKI, HARUHIKO; HUANG, HAOLUN; TAMURA, YUKA: "Development of Blockchain Technology to Protect Mobility Data and Traceability Data", DENSO TECHNICAL REVIEW, vol. 24, 1 January 2019 (2019-01-01), Japan, pages 42 - 52, XP009537762, ISSN: 1342-4114 *

Also Published As

Publication number Publication date
JP2022101967A (ja) 2022-07-07
CN116710917A (zh) 2023-09-05
US20230336356A1 (en) 2023-10-19
JP7472781B2 (ja) 2024-04-23

Similar Documents

Publication Publication Date Title
JP6782446B2 (ja) 監視装置、通信システム、車両、監視方法、およびコンピュータプログラム
CN104773120B (zh) 用于高效重新编程的车内设备及其控制方法
Guette et al. Using tpms to secure vehicular ad-hoc networks (vanets)
US9577997B2 (en) Authentication system and authentication method
US20190056925A1 (en) Update control apparatus, software update system, and update control method
US10887111B2 (en) Verification method, verification apparatus, and storage medium including program stored therein
US10049232B2 (en) Rewrite detection system, rewrite detection device and information processing device
CN106529301B (zh) 车机系统的控制方法、装置以及车机系统
JP2013060047A (ja) 車両用ネットワークシステム及び車両用情報処理方法
JP5772692B2 (ja) 車載制御装置の認証システム及び車載制御装置の認証方法
CN110920560A (zh) 云授权车辆控制
JP2018081349A (ja) 改竄検知システム、検証ｅｃｕ、被検証ｅｃｕ、プログラム
WO2022137945A1 (ja) データ保存装置、データ保存方法、およびデータ保存プログラム
US20230083716A1 (en) Devices, methods, and computer program for releasing transportation vehicle components, and vehicle-to-vehicle communication module
CN108737988B (zh) 使用机械振动进行车辆上带外通信的系统和方法
US20230246849A1 (en) Verification method, verification apparatus, and storage medium including program stored therein
US8776205B2 (en) Secure connection systems and methods for vehicles
US11935341B2 (en) Data storage device and non-transitory tangible computer readable storage medium
JP6783578B2 (ja) 車両制御システム
WO2021207986A1 (zh) 数据验证方法及装置
US10997799B2 (en) Method and apparatus for leveraging wireless connectivity for pre-service preparation in service lanes
US20230306101A1 (en) System, vehicle, and method
WO2023232045A1 (zh) 车辆校验方法、相关装置及系统
US20230205887A1 (en) Secure automotive system
WO2023074072A1 (ja) データ保存システム、移動体、及びデータ保存プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21910098

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180086419.1

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21910098

Country of ref document: EP

Kind code of ref document: A1