Method and vehicle terminal for v2v-based cooperative data verification

Abstract

A vehicle terminal for V2V-based collaborative data verification and a method performed by the same are provided. The method includes: receiving service data from a service providing server; generating a first hash value for the service data; requesting a hash segment corresponding to the service data from a surrounding vehicle; receiving a hash segment from the surrounding vehicle, where a portion of a second hash value corresponding to the received hash segment is at least partially different; and verifying the integrity of the service data based on the received hash segment and the first hash value. Each hash segment is part of a second hash value generated by the corresponding surrounding vehicle for service data that has been received from the service providing server, and may be combined by the vehicle terminal in order to reconstruct the second hash value.

Description

Technical Field

[0001] The present disclosure relates to verifying the integrity of data received by a vehicle via a communication network. More specifically, the present disclosure relates to verifying the integrity of data received by a vehicle via a communication network in collaboration with surrounding vehicles. Background Art

[0002] In recent years, attempts have been made to provide various services in vehicles through network communication. This connection can be achieved using vehicle-to-everything (V2X) communication technology.

[0003] Advanced vehicle features and the user services that support them are closely tied to the software (SW) developed in conjunction with the vehicle's hardware (HW). To fix bugs or enhance functionality in this software, over-the-air (OTA) software (SW) updates are expanding for convenience and affordability.

[0004] When performing software updates over a communication network, vehicles are exposed to cybersecurity threats such as tampering and spoofing. For example, an attacker could infect an OTA server and transmit software (or firmware) containing malicious code to the vehicle, updating it with software containing malicious code and ultimately executing various cybersecurity attacks through malware. Furthermore, without infecting the OTA server, an attacker could use a man-in-the-middle attack to replace the software update file being transmitted with a malicious file, resulting in the malicious firmware update file being delivered to the vehicle.

[0005] In addition, the vehicle's autonomous driving system or driver assistance system may use high-precision map data of the driving area or planned driving area provided by external servers. Forging or modifying high-precision map data may threaten the safe driving of the vehicle.

[0006] Therefore, it is necessary to perform integrity verification on data received over communication networks (e.g., software updates and high-precision maps). Integrity verification is well known in the field of computers and cryptography. In typical applications, integrity verification ensures that the sent message is received without being corrupted by errors caused by the communication channel or maliciously damaged by hackers. Summary of the Invention

[0007]

Technical Issues

[0008] The present disclosure proposes a method for performing integrity verification on server data received by a vehicle through a communication network in cooperation with surrounding vehicles, and a vehicle terminal used for the method.

[0009] Means used to solve the problem

[0010] According to some embodiments of the present disclosure, a method for collaborative data verification based on vehicle-to-vehicle (V2V) communication, performed by a vehicle terminal, is provided. The method includes: receiving service data from a service provider server; generating a first hash value for the service data; requesting hash segments corresponding to the service data from surrounding vehicles; receiving the hash segments from the surrounding vehicles; and verifying the integrity of the service data based on the received hash segments and the first hash value. Each hash segment can be combined to reconstruct a second hash value generated by the corresponding surrounding vehicle for the service data received from the service provider server.

[0011] In some embodiments, verifying the integrity of the service data may include comparing a first hash value with each received hash segment. In some embodiments, verifying the integrity of the service data may include reconstructing a second hash value by combining the received hash segments, and comparing the first hash value with the reconstructed second hash value. In some embodiments, verifying the integrity of the service data may include determining that integrity verification of the service data has failed when a ratio of the number of surrounding vehicles that successfully received the hash segment to the total number of hash segments (N) is less than a preset threshold.

[0012] In some embodiments, requesting the hash segments may include sending a request message to each surrounding vehicle, the request message including the total number (N) of hash segments to be divided from the second hash value and a sequence number assigned to the corresponding surrounding vehicle.

[0013] In some embodiments, each hash segment received from the surrounding vehicles may be the Mth hash segment corresponding to the serial number (M) assigned to the corresponding surrounding vehicle, among the hash segments obtained by dividing the second hash value according to the total number of hash segments (N).

[0014] In some other embodiments, each hash segment received from a surrounding vehicle may be the Mth hash segment and the M+1th hash segment corresponding to the serial number (M) assigned to the corresponding surrounding vehicle, among the hash segments obtained by dividing the second hash value according to the total number of hash segments (N). The method may further include: determining whether a pair of hash segments corresponding to the same portion of the second hash value received from a pair of surrounding vehicles match each other; and when the pair of hash segments corresponding to the same portion of the second hash value do not match each other, determining that the service data is abnormal data.

[0015] The total number (N) of hash segments may be included in metadata received from the service providing server along with the service data, or may be a preset value in the vehicle terminal. The total number (N) of hash segments may be determined based on the number of surrounding vehicles that can respond.

[0016] The metadata may be received from the service providing server along with the service data. The metadata may include version information of the service data and an identifier of a hash function used to generate the first hash value and the second hash value. The metadata may be used to identify surrounding vehicles that can respond.

[0017] In some other embodiments, a vehicle terminal for V2V-based collaborative data verification is provided. The vehicle terminal includes: a memory; and at least one processor. The processor is configured to perform the following steps: receive service data from a service provider server; generate a first hash value for the service data; request hash segments corresponding to the service data from surrounding vehicles; receive the hash segments from the surrounding vehicles; and verify the integrity of the service data based on the received hash segments and the first hash value.

[0018] Beneficial effects

[0019] According to the present disclosure, a vehicle can perform integrity verification on data received via a communication network in collaboration with surrounding vehicles. For example, a vehicle can verify the integrity of OTA SW updates and precision map data received via network communication.

[0020] Integrity verification is performed by comparing hash values ​​generated for the same data received by vehicles at different times and / or different geographic locations. When the hash values ​​generated for the same data by multiple vehicles match, it can be assumed that the data has not been tampered with by an attacker. On the other hand, when at least one hash value does not match, it can be assumed that the data received by at least one vehicle has been tampered with by an attacker. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a conceptual diagram illustrating a vehicle environment in which the techniques of this disclosure may be used.

[0022] Figure 2 The present invention is a flowchart of a method for a vehicle to perform V2V-based collaborative data verification on service data according to an embodiment of the present disclosure.

[0023] Figure 3 It shows that when the total number of hash segments (N) is equal to 10, two hash segments are to be sent by the surrounding vehicles according to the assigned sequence numbers.

[0024] Figure 4 This is a conceptual diagram of how a hash function in a Merkle-Damgard configuration generates a hash value.

[0025] Figure 5 A simplified functional block diagram of an exemplary vehicle terminal that can be used to implement the method according to the present disclosure is shown. DETAILED DESCRIPTION

[0026] Hereinafter, some exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In the following description, like reference numerals represent like elements, but these elements appear in different drawings. In addition, in the following description of some embodiments, for the sake of clarity and brevity, detailed descriptions of known functions and configurations incorporated therein will be omitted.

[0027] In addition, various terms such as first, second, A, B, (a), (b), etc. are only used to distinguish one component from another, and do not imply or suggest the nature, order, or sequence of the components. Throughout the specification, when a component "includes" or "comprising" a component, the component is intended to further include other components, rather than exclude other components, unless otherwise explicitly stated. Terms such as "unit" and "module" refer to one or more units for processing at least one function or operation, and these units can be implemented by hardware, software, or a combination thereof.

[0028] In exemplary embodiments of the present disclosure, a vehicle may be understood as a concept based on various vehicles having network communication capabilities. In some cases, a vehicle may be understood as a concept based on various land vehicles traveling on roads (e.g., cars, motorcycles, trucks, and buses) and various vehicles (e.g., vertical take-off and landing aircraft (VTOL) for urban air mobility, drones, etc.).

[0029] The technology disclosed herein relates to a method for V2V-based collaborative data verification and a vehicle terminal using the method. A vehicle receives data through network communication with a service provider server and performs integrity verification on the received data (which may be corrupted) in collaboration with surrounding vehicles.

[0030] Figure 1 is a conceptual diagram illustrating a vehicle environment in which the techniques of this disclosure may be used.

[0031] The vehicles 10 and 30 are each equipped with a vehicle terminal 11 and 31 that supports a data communication function. The vehicle terminals 11 and 31 are connected to a communication network and can request service data from the service providing server 20 and receive service data from the service providing server 20 .

[0032] The vehicle terminals 11 and 31 can support V2V communication. For example, the vehicle terminal 11 of the vehicle 10 can perform V2V communication with the vehicle terminal 31 of the surrounding vehicle 30 to verify the integrity of service data received from the communication network (provided from the service providing server 20 but may have been damaged).

[0033] The service providing server 20 is a server that provides service data to the vehicles 10 and 30. For example, the service providing server 20 may be a server that supports over-the-air (OTA) update files for software or firmware used in various electronic control units of the vehicle. As another example, the service providing server 20 may be a server that provides various types of data (e.g., high-precision map data, weather information, and intrusion detection system (IDS) rule sets for the functions of such software or firmware).

[0034] The vehicle terminal 11 of the vehicle 10 can receive service data from the service providing server 20 and generate a first hash value for the received service data. The vehicle terminal 11 can request hash segments corresponding to the service data from the vehicle terminals 31 of the surrounding vehicles 30 and receive the hash segments from the vehicle terminals 31 of the surrounding vehicles 30. Each hash segment is a portion of the second hash value generated for the service data that the corresponding surrounding vehicle 30 has received from the service providing server. The portion of the second hash value corresponding to the hash segment received from the vehicle terminal 31 of the surrounding vehicle 30 can be different. For example, the hash segment received from the first surrounding vehicle and the hash segment received from the second surrounding vehicle can be different parts of the hash value. Therefore, the hash segments received from the surrounding vehicles 30 can be combined to completely or partially reconstruct the second hash value.

[0035] The vehicle terminal 11 of the vehicle 10 can verify the integrity of the service data based on the received hash segments and the first hash value. The vehicle terminal 11 can compare the first hash value with each received hash segment to verify the integrity of the data. The vehicle terminal 11 can combine the received hash segments to reconstruct the second hash value and compare the first hash value with the reconstructed second hash value to verify the integrity of the data.

[0036] This inter-vehicle collaborative data verification is based on the following assumptions: an attacker's cybersecurity attacks are typically performed at a specific time and / or geographic location, and vehicles may probabilistically receive the same service data at different times and / or geographic locations. For example, even if service data received by a vehicle from the communication network has been tampered with by an attacker, service data received by several surrounding vehicles at different times and / or geographic locations may not have been affected by the attacker's attack.

[0037] Therefore, when the hash values ​​of the same service data generated by vehicles within the geographic range where V2V communication is possible match, it can be assumed that the service data has not been tampered with by an attacker. On the other hand, when at least one hash value does not match, it can be assumed that the service data received by at least one vehicle has been tampered with by an attacker.

[0038] Figure 21 is a flowchart illustrating a method for a vehicle (specifically, a vehicle terminal) to perform V2V-based collaborative data verification on service data according to an embodiment of the present disclosure. In the following description, the vehicle terminal may be simply referred to as a "vehicle."

[0039] The vehicle 10 may request service data from the service providing server 20 (S11). The vehicle 10 may request updates of software or firmware operating in conjunction with the hardware (HW) in the vehicle, and various types of data for the functions of such software or firmware, from the service providing server 20. For example, the vehicle 10 may receive a notification from the service providing server 20 that a new version of software (or firmware) for an electronic control module installed in the vehicle 10 has been released, and when the vehicle 10 enters a state suitable for performing a software update (e.g., a parked state or the driver consents to the update), the vehicle 10 may request the software update file from the service providing server 20. As another example, when the vehicle 10 enters a new driving area used in an automatic driving system, the vehicle 10 may request precise map data for the new driving area or the planned driving area from the service providing server 20.

[0040] The service providing server 20 may transmit the service data requested by the vehicle 10 to the vehicle 10 (S12). The service providing server 20 may transmit metadata defining and describing the service data together with the service data to the vehicle 10. For example, the metadata may include identification information of the service data, version information of the service data, an identifier of a hash function to be used to generate a hash value of the service data, etc. Examples of hash functions include MD5, SHA-1, or SHA-2.

[0041] The vehicle 10 may receive data (i.e., service data and metadata) from the service providing server 20. The vehicle 10 may calculate a hash value H for the received service data (S13). The hash function used to generate the hash value may be predefined in the control logic of the vehicle terminal or determined based on an identifier of the hash function defined in the metadata received from the service providing server 20.

[0042] The vehicle 10 may identify surrounding vehicles that are capable of responding to the request for the hash segment (S14). For example, the vehicle 10 may select a surrounding vehicle that has the same service data as the service data to be verified for integrity. To this end, the vehicle 10 may provide metadata related to the service data to the surrounding vehicles in order to inquire whether the surrounding vehicles are capable of responding to the request for the hash segment.

[0043] Based on the received metadata, each surrounding vehicle can determine whether it can respond to the hash segment request and reply with the result to vehicle 10. For example, based on the service data identification information and service data version information, the surrounding vehicle can determine whether it has the same service data and whether the hash function corresponding to the hash function identifier is available. In some embodiments, vehicle 10 can also verify whether the surrounding vehicles are secure in terms of network security.

[0044] The vehicle 10 determines the total number (N) of hash segments based on the number of surrounding vehicles that can respond, and may assign a different sequence number (M) from 1 to N to each surrounding vehicle. For example, when 10 surrounding vehicles are found that can respond to the request for hash segments, a different sequence number (M) from 1 to 10 is assigned to each surrounding vehicle.

[0045] In another embodiment, the total number of hash segments (N) may be included in metadata received from the service providing server along with the service data, or may be preset in the control logic of the vehicle terminal. In this case, the vehicle 10 may repeat the process of S14 until the number of selected surrounding vehicles reaches the preset total number of hash segments (N).

[0046] To verify the integrity of the received service data, the vehicle 10 may request at least one hash segment corresponding to the service data to be verified from each surrounding vehicle (S15). For example, the vehicle 10 may send a request message to each surrounding vehicle including the total number of hash segments (N) and the sequence number (M) assigned to the corresponding surrounding vehicle. The request message may also include metadata about the service data.

[0047] The surrounding vehicle that receives the hash segment request from the vehicle 10 calculates the hash value H' of the service data it has received from the service providing server 20 (S16). The hash function used to calculate the hash value H and the hash value H' is the same. The hash function used to calculate the hash value H' can be pre-defined in the control logic of the vehicle terminal of the surrounding vehicle, or can be determined based on the hash function identifier included in the metadata received from the vehicle 10. Alternatively, the non-volatile memory of the vehicle terminal 31 can store the hash value H' pre-calculated for the service data. In this case, S16 can be omitted.

[0048] After calculating the hash value H' (or reading the hash value H' stored in the non-volatile memory), the vehicle terminal 31 of each surrounding vehicle can divide the hash value H' into N hash segments based on the total number of hash segments (N) (S17). In addition, each surrounding vehicle can send one or more hash segments determined by their assigned serial numbers among the N divided hash segments to the vehicle 10 (S18).

[0049] For example, the surrounding vehicles may divide the hash value H′ according to the total number of hash segments (N), and transmit the Mth hash segment corresponding to the assigned sequence number (M) among the obtained hash segments to the vehicle 10 .

[0050] As another example, Figure 3 As shown, the surrounding vehicles may transmit the Mth hash segment and the M+1th hash segment corresponding to the assigned serial number (M) among the hash segments obtained by dividing the hash value H′ according to the total number of hash segments (N) to the vehicle 10 .

[0051] Figure 3 It shows that when the total number of hash segments (N) is equal to 10, two hash segments are to be sent by the surrounding vehicles according to the assigned sequence numbers.

[0052] The hash value (H') is divided into N (=10) hash segments (h1, h2, ... h10) of the same length. When the hash value (H') is not a multiple of N, the last hash segment may be shorter in length than the other hash segments. In one implementation, the last hash segment may include a predefined padding bit (e.g., "1") to have the same length.

[0053] like Figure 3 As shown in (a), the surrounding vehicles assigned the same sequence number as 3 can send the third hash segment (h3) and the fourth hash segment (h4) to the vehicle 10. Figure 3 As shown in (b), the surrounding vehicles assigned the same serial number as 4 can send the fourth hash segment (h4) and the fifth hash segment (h5) to the vehicle 10. Figure 3 As shown in (c), the surrounding vehicles assigned the same serial number as 5 can send the fifth hash segment (h5) and the sixth hash segment (h6) to the vehicle 10. Figure 3 As shown in (d), the surrounding vehicles assigned the same serial number as 10 can send the tenth hash segment (h10) and the first hash segment (h1) to the vehicle 10.

[0054] In this way, for a given portion of the hash value (H'), two hash segments can be obtained from two surrounding vehicles. For example, one hash segment in a pair of hash segments received from a first surrounding vehicle assigned the same serial number as 4 can be the same as the hash segment received from a second surrounding vehicle assigned the same serial number as 3, while the other hash segment can be the same as the hash segment received from a third surrounding vehicle assigned the same serial number as 5.

[0055] The vehicle 10 can determine whether a pair of hash segments corresponding to the same part of the hash value (H') received from two different surrounding vehicles match each other (S19). For example, the vehicle 10 can compare the k+1th hash segment received from the surrounding vehicle assigned the same serial number as k with the k+1th hash segment received from the surrounding vehicle assigned the same serial number as k+1. This process is repeated N times. When a pair of hash segments does not match once in the N repetitions, the vehicle 10 can determine that the received service data is abnormal data. Alternatively or additionally, when a pair of hash segments does not match once in the N repetitions, the vehicle 10 can perform the process again from S11.

[0056] In some embodiments, S19 can be skipped. Depending on the type of service data, the vehicle 10 may execute or skip S19. For example, for weather information and high-precision map data, where processing speed is relatively important, S19 may be skipped. On the other hand, for software update files where integrity verification is important, S19 may be required.

[0057] In each of the N repetitions, when a pair of hash segments matches, the vehicle 10 reconstructs a hash value (H") by combining the hash segments. The hash segments received from the N vehicles are combined based on the sequence numbers, and duplicate segments are removed. The vehicle 10 compares the reconstructed hash value (H") with the hash value (H) generated by the vehicle 10 (S20).

[0058] When the reconstructed hash value (H”) matches the generated hash value (H), the vehicle 10 can determine that the service data received from the service providing server 20 is secure. Therefore, the vehicle 10 uses the service data according to its original purpose. For example, when the service data is a software update file, the vehicle 10 can use the service data to update the software of the relevant electronic control module, and when the service data is high-precision map data, the service data can be sent to the autonomous driving control system. When the service data is weather information or multimedia, the service data can be sent to the in-vehicle infotainment system. The service data or the generated hash value (H), or both, can be stored in the non-volatile memory of the vehicle terminal 11 so that they can be used for collaborative data verification with other vehicles in the future.

[0059] When the reconstructed hash value (H") does not match the generated hash value (H), the vehicle 10 may determine that the service data received from the service providing server 20 is not secure. In this case, the vehicle 10 may request the service data from the service providing server 20 again. Alternatively, when the comparison result in S19 or S20 does not match, a warning may be sent to the service providing server 20, or an alert may be provided to the user through the user interface.

[0060] Furthermore, some surrounding vehicles may be unable to transmit their hash segments to vehicle 10 due to poor communication conditions. In this case, vehicle 10 may repeat the process from S15. Alternatively, vehicle 10 may compare only the successfully received hash segments with the corresponding portion of the hash value (H). Furthermore, when the ratio of the number of surrounding vehicles that successfully received the hash segments to the total number of hash segments (N) is less than a preset threshold, vehicle 10 may determine that the integrity verification of the service data has failed.

[0061] In one embodiment, the service providing server 20 or the vehicle 10 may set the total number of hash segments (N) or the preset threshold differently depending on the type of service data provided (e.g., software update files, precision maps, multimedia) or the type of vehicle 10 being served (e.g., shuttle buses, freight vehicles, emergency vehicles, etc.). For example, the total number of hash segments or the preset threshold may be larger for software update files than for multimedia.

[0062] In one embodiment, the service providing server 20 or the vehicle 10 may set the total number of hash segments or the preset threshold value differently depending on the communication condition or traffic condition. For example, when the communication condition is poor or the road condition is quiet, the total number of hash segments or the preset threshold value may be smaller than when the above conditions are not met.

[0063] In the above embodiments, a hash segment is described as a portion of a hash value generated for service data. That is, a hash segment is obtained by dividing the hash value generated for the service data. Like most advanced encryption technologies, these hash functions are computationally intensive and therefore slow or require a large amount of computing power. Given the limited computing power of vehicle terminals, or in situations where fast integrity verification is required (for example, for high-precision map data), it may be inefficient for each surrounding vehicle to calculate a complete hash value in order to send a hash segment.

[0064] In this context, in an alternative embodiment, each hash segment may be an intermediate value of each stage of a hash function (or hash algorithm) that generates a hash value for the service data.

[0065] Figure 4 This is a conceptual diagram showing a method for generating hash values ​​using a hash function of a Merkle-Damgard configuration. This scheme has been used in the design of many widely used hash functions, such as MD5, SHA-1, and SHA-2. Figure 4 As shown, the hash function divides the target data (binary data) into blocks (or chunks) of fixed length, processes these blocks one by one at each stage (or round), and uses a compression function to combine the output of the previous stage (i.e., the intermediate result) with the input block of the current stage. Figure 4In the example shown in Figure 2, the algorithm consists of four stages. The compression function (denoted by "F") converts two fixed-length inputs into an output that is the same length as one of the inputs. The first stage of the hash function algorithm begins with an initialization vector (IV), which is an initial value. Although it can vary depending on the algorithm or implementation, the initialization vector is usually a fixed value. The last block can be padded to make it the same size as the other blocks if necessary. The fixed length of the block ( Figure 4 ) and the length of the output of the compression function ( Figure 4 128 bits in the example above) can vary depending on the hash function.

[0066] The output of the last stage may be a hash value of the target data, or alternatively, a finalization function may be used to convert the output of the last stage into a hash value of the target data to enhance the hash value or obtain a shorter bit length.

[0067] Here, the output of each stage can be used as a hash segment to be sent to the vehicle 10 by the surrounding vehicles in response to the hash segment request. For example, when the hash algorithm used to calculate the hash value H' consists of four stages, the vehicle 10 can receive outputs of different stages from four surrounding vehicles. Since the target data is divided into fixed-length blocks processed at each stage, the total number of hash segments (N) required for collaborative data verification can depend on the size of the target data.

[0068] In this alternative embodiment, surrounding vehicles can Figure 2 In S16 to S18, the output of a level or the output of two (continuous or intermittent) levels corresponding to their assigned sequence numbers are sent as hash segments to the vehicle 10. In S19, the vehicle 10 can check whether a pair of hash segments corresponding to the output of the same level matches each other, which are hash segments received from two different surrounding vehicles. In S20, the vehicle 10 can use the hash segment received from the surrounding vehicle as one of the two inputs of the compression function of each level to reconstruct the hash value H' for the service data.

[0069] In this embodiment, each surrounding vehicle does not need to calculate a complete hash value to send a hash segment to the vehicle 10. It only needs to calculate the output of the level corresponding to the serial number assigned to each surrounding vehicle.

[0070] Figure 5 A simplified functional block diagram of an exemplary vehicle terminal that can be used to implement the method according to the present disclosure is shown.

[0071] The vehicle terminal 500 may be installed in Figure 1 The vehicle terminals 11 and 31 on each vehicle 10 and 30 are shown. Figure 5As shown in the example of FIG, the vehicle terminal 500 may include an input device 502, an output device 504, a control circuit 506, a central processing unit (CPU) 508, a memory 510, a program code 512, and a transceiver 514. The control circuit 506 executes the program code 512 in the memory 510 through the CPU 508 and controls the operation of the vehicle terminal 500 accordingly. The control circuit 506 can interact with the user via the input device 502 and the output device 504, or exchange signals with other electronic control units / systems in the vehicle. The transceiver 514 is used to receive and transmit wireless signals, thereby transmitting received signals to the control circuit 506 and wirelessly outputting signals generated by the control circuit 506.

[0072] The operating process of the present disclosure can be implemented as computer-readable code on a computer-readable recording medium. The computer-readable recording medium may include all types of storage devices capable of storing computer-readable data. The computer-readable recording medium may be a non-transient medium, such as a read-only memory (ROM), a random access memory (RAM), a compact disc ROM (CD-ROM), a magnetic tape, a floppy disk, or an optical data storage device. In addition, the computer-readable recording medium may be distributed on computer systems connected via a network, and the computer-readable program code may be stored and executed in a distributed manner.

[0073] In addition, the components of the present disclosure can utilize integrated circuit structures, such as memories, processors, logic circuits, lookup tables, etc. These integrated circuit structures perform the functions described herein under the control of one or more microprocessors or other control devices. In addition, the components of the present disclosure can be specifically implemented by parts of programs or codes, which contain one or more executable instructions for performing specific logical functions and are executed by one or more microprocessors or other control devices. In addition, the components of the present disclosure may include a central processing unit (CPU), a microprocessor, etc. that performs the corresponding functions, or be implemented thereby. In addition, the components of the present disclosure can store instructions executed by one or more processors in one or more memories.

[0074] Although exemplary embodiments of the present disclosure have been described for illustrative purposes, it will be understood by those skilled in the art that various modifications, additions, and substitutions are possible without departing from the concept and scope of the claimed invention. Therefore, for the sake of brevity and clarity, exemplary embodiments of the present disclosure have been described. The scope of the technical concept of the present embodiment is not limited by the description. Therefore, it will be understood by those skilled in the art that the scope of the claimed invention is not limited by the embodiments explicitly described above, but is limited by the claims and their equivalents.

[0075] CROSS-REFERENCE TO RELATED APPLICATIONS

[0076] This application claims priority from Patent Application No. 10-2023-0019671 filed in Korea on February 14, 2023, and Patent Application No. 10-2024-0020291 filed in Korea on February 13, 2024, which are hereby incorporated by reference herein in their entirety.

Claims

1. A method for V2V-based collaborative data verification performed by a vehicle terminal, the method comprising the following steps: receiving service data from a service providing server; generating a first hash value for the service data; requesting hash segments corresponding to the service data from surrounding vehicles, each hash segment being capable of being combined to reconstruct a second hash value generated by the corresponding surrounding vehicle for the service data that has been received from the service providing server; receiving the hash segments from the surrounding vehicles; as well as The integrity of the service data is verified based on the received hash segment and the first hash value.

2. The method according to claim 1, wherein The steps to request a hash segment include: A request message is sent to each surrounding vehicle, the request message including the total number (N) of hash segments to be divided from the second hash value and a serial number assigned to the corresponding surrounding vehicle.

3. The method according to claim 2, wherein: Each hash segment received from the surrounding vehicles is the Mth hash segment corresponding to the serial number (M) assigned to the corresponding surrounding vehicle, among hash segments obtained by dividing the second hash value according to the total number (N) of hash segments.

4. The method according to claim 2, wherein: Each hash segment received from the surrounding vehicles is the Mth hash segment and the M+1th hash segment corresponding to the serial number (M) assigned to the corresponding surrounding vehicle, among the hash segments obtained by dividing the second hash value according to the total number (N) of hash segments.

5. The method according to claim 4, further comprising the steps of: determining whether a pair of hash segments received from a pair of surrounding vehicles and corresponding to a same portion of the second hash value match each other; as well as When a pair of hash segments corresponding to the same portion of the second hash value do not match each other, it is determined that the service data is abnormal data.

6. The method according to claim 2, wherein: The total number (N) of hash segments is included in metadata received from the service providing server together with the service data.

7. The method according to claim 2, wherein: The total number (N) of hash segments is a preset value in the vehicle terminal.

8. The method according to claim 2, wherein: The steps of requesting hash segments also include: Identifying surrounding vehicles that can respond to requests for hash segments; and Based on the number of surrounding vehicles that are able to respond, the total number of hash segments (N) is determined.

9. The method according to claim 8, wherein The metadata received from the service providing server together with the service data includes version information of the service data and an identifier of a hash function commonly used to generate the first hash value and the second hash value, and The metadata is used to identify surrounding vehicles that can respond.

10. The method according to claim 2, wherein: The steps of verifying the integrity of the service data include: When the ratio of the number of surrounding vehicles that successfully receive the hash segment to the total number of hash segments (N) is less than a preset threshold, it is determined that the integrity verification of the service data has failed.

11. The method according to claim 2, wherein: The steps of verifying the integrity of the service data include: The first hash value is compared with each received hash segment.

12. The method according to claim 2, wherein: The steps of verifying the integrity of the service data include: reconstructing the second hash value by combining the received hash segments; and The first hash value is compared to the reconstructed second hash value.

13. A vehicle terminal for V2V-based collaborative data verification, the vehicle terminal comprising: Memory; and At least one processor, wherein the processor is configured to perform the following steps: receiving service data from a service providing server; generating a first hash value for the service data; requesting hash segments corresponding to the service data from surrounding vehicles, each hash segment being capable of being combined to reconstruct a second hash value generated by the corresponding surrounding vehicle for the service data that has been received from the service providing server; receiving hash segments from the surrounding vehicles; and The integrity of the service data is verified based on the received hash segment and the first hash value. The vehicle terminal according to claim 13 , wherein: The processor is configured to perform the following steps: As part of verifying the integrity of the service data, the first hash value is compared to each received hash segment.

15. The vehicle terminal according to claim 13, wherein The processor is configured to perform the following steps: As part of verifying the integrity of the service data, the received hash segments are combined to reconstruct the second hash value, and the first hash value is compared to the reconstructed second hash value.

Images