Claims:
1. A method for establishing secure communications between connected systems in a blockchain network (102) comprising a plurality of nodes (104), the method comprising:
receiving a transaction request by the plurality of nodes (104) in the blockchain network (102) from a requester system (10), wherein the transaction request comprises a unique code representing a specific data type requested by the requester system (10) from a requestee system (12), wherein the requester system (10) and the requestee system (12) are the connected systems in the blockchain network (102);
validating the transaction request, and subsequently generating and communicating cryptographic keys having a designated duration of validity to the requester system (10) and the requestee system (12) to establish direct communication between the requester system (10) and the requestee system (12) for the designated duration;
receiving one or more of a first feedback regarding the requester system (10) from the requestee system (12) and a second feedback regarding the requestee system (12) from the requester system (10) at the plurality of nodes (104), wherein each of the first feedback and the second feedback comprises a corresponding unique code representing a specific type of feedback;
updating a trust score associated with the requester system (10) based on the unique code included in the first feedback and a trust score associated with the requestee system (12) based on the unique code included in the second feedback; and
enabling at least one of the requester system (10) and the requestee system (12) to communicate with one or more of the other connected systems in the blockchain network (102) only when a corresponding updated trust score is above a designated threshold value.

2. The method as claimed in claim 1, wherein the requester system (10) corresponds to a requester vehicle (10), the requestee system (12) corresponds to a requestee vehicle (12), and the connected systems further comprise one or more of other vehicles and connected vehicle systems registered with the blockchain network (102), the method further comprising:
calculating the trust score associated with each of vehicles and the connected vehicle systems based on one or more of a number of transaction requests generated by a vehicle, a number of transaction requests processed by the vehicle, a number of transaction requests from the vehicle denied by the blockchain network (102) due to incorrect information, a number of data denial or false information feedback received against the vehicle, a number of explanations received from the vehicle for data denial, and a number of malicious attacks feedback received against the vehicle,
storing the trust score associated with each of the vehicles and the connected vehicle systems in the plurality of nodes (104), wherein each node (104) of the blockchain network (102) comprises a distributed ledger (106);
updating the trust score associated with the requester vehicle (10) in the plurality of nodes (104) based on the transaction request generated by the requester vehicle (10) to obtain a modified requester score;
updating the trust score associated with the requestee vehicle (12) after the requestee vehicle (12) receives the specific data type request from the requester vehicle (10) to obtain a modified requestee score;
updating the modified requester score and the modified requestee score further in the plurality of nodes (104) based on the first feedback and the second feedback, respectively to obtain the corresponding updated trust score; and
preventing at least one of the requester vehicle (10) and the requestee vehicle (12) from communicating with the other vehicles when the corresponding updated trust score is below the designated threshold value.

3. The method as claimed in claim 2, further comprising:
implementing a proof-of-work scheme comprising solving a selected cryptographic puzzle, by the plurality of nodes (104) in the blockchain network (102), to process the transaction request to generate a new block and to store the transaction request in the newly generated block; and
appending the newly generated block in the distributed ledger (106).

4. The method as claimed in claim 3, further comprising:
processing the transaction request by each of the plurality of nodes (104) at substantially the same instant of time to solve the cryptographic puzzle; and
selecting a particular node (104) from the plurality of nodes (104) to generate the new block for appending the newly generated block in the distributed ledger (106), wherein the selected node (104) is either the first node (104) to solve the cryptographic puzzle or is a randomly selected node (104) from a set of nodes (104) which are the first to simultaneously solve the cryptographic puzzle.

5. The method as claimed in claim 4, further comprising generating and transmitting one or more cryptographic keys with limited duration of validity by the selected node (104), post validation of the transaction request, to each of the requester vehicle (10) and the requestee vehicle (12).

6. The method as claimed in claim 1, wherein each of the respective unique code included in the transaction request, the first feedback, and the second feedback comprises a 32-bit data field value.

7. The method as claimed in claim 1, further comprising:
temporarily disabling the requester vehicle (10) from establishing communication with one or more of the other vehicles and the connected vehicle systems registered with the blockchain network (102) upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requester vehicle (10), and
temporarily disabling the requestee vehicle (12) from establishing communication with one or more of the other vehicles and the connected vehicle systems registered with the blockchain network (102) upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requestee vehicle (12).

8. The method as claimed in claim 7, further comprising permanently disabling one or more of the requester vehicle (10) and the requestee vehicle (12) from establishing communications with one or more of the other vehicles and connected vehicle systems registered with the blockchain network (102) when the corresponding vehicle has been temporarily blocked more than a designated number of times.

9. The method as claimed in claim 1, wherein the first transaction request received from a requestor vehicle (10) for a requestee vehicle (12) registered with the blockchain network (102) comprises a transaction identifier, public keys of the requester vehicle (10) and the requestee vehicle (12), digital signature of the requester vehicle (10), and the unique code, and wherein a subsequent transaction request from the requestor vehicle (10) comprises a transaction identifier, public keys of the requester vehicle (10) and the requestee vehicle (12), digital signature of the requester vehicle (10), hash of a previous block comprising the most recent transaction requested by the requester vehicle (10), timestamp of the previous block, and a unique code.

10. The method as claimed in claim 1, further comprising automatically generating a transaction request comprising a specific unique code representative of a specific emergency situation by a vehicle registered with the blockchain network (102) upon detecting the specific emergency situation, the emergency situation comprising one or more of a vehicle theft, vehicle collision, vehicle breakdown, and a medical emergency.

11. The method as claimed in claim 1, further comprising automatically generating feedback by the requester vehicle (10) regarding the requestee vehicle (12) in case of one or more of data denial, denial due to poor network, denial due to emergency, false information received, and cyberattack by the requestee vehicle (12).

12. The method as claimed in claim 1, wherein the specific data type requested by the requester vehicle (10) comprises one of traffic data, navigation data, sensor data, infotainment data, vehicle data, and network data.

13. The method as claimed in claim 1, wherein the specific type of feedback received from the requester vehicle (10) for the requestee vehicle (12) comprises a unique code representative of one or more of a data denial, false information received, and cyberattack information, the cyberattack comprising malware attack, phishing attack, man-in-the-middle attack, denial of service attack, teardrop attack, eavesdropping attack, drive-by attack and password attack.

14. A system (100) for establishing secure communication between connected systems, the system (100) comprising:
a blockchain network (102) comprising a plurality of nodes (104), the plurality of nodes (104) configured to:
receive a transaction request from a requester system (10), wherein the transaction request comprises a unique code representing a specific data type requested by the requester system (10) from a requestee system(12);
validate the transaction request, and generate and communicate one or more cryptographic keys having a designated duration of validity to the requester system (10) and the requestee system (12) to establish direct communication between the requester system (10) and the requestee system (12) only for the designated duration;
receive one or more of a first feedback regarding the requester system (10) from the requestee system (12) and a second feedback regarding the requestee system (12) from the requester system (10) at the plurality of nodes (104), wherein each of the first feedback and the second feedback comprises a corresponding unique code representing a specific type of feedback;
store one or more of a trust score of the requester system (10) computed by an access control mechanism (110) based on the unique code included in the first feedback and a trust score of the requestee system (12) computed by the access control mechanism (110) based on the unique code included in the second feedback; and
enable at least one of the requester system (10) and the requestee system (12) to communicate with one or more of other connected systems registered with the blockchain network (102) only when a corresponding updated trust score is above a designated threshold value.

15. The system (100) as claimed in claim 14, wherein each node (104) of the blockchain network (102) comprises a distributed ledger (106), and wherein each node (104) is configured to implement a proof-of-work scheme to process the transaction request to generate a new block with the transaction request and associated information stored therein, and append the newly generated block in the distributed ledger (106).

16. The system (100) as claimed in claim 15, wherein the plurality of nodes (104) process the transaction request at substantially the same instant of time to generate a new block, wherein the blockchain network (102) selects a particular node (104) from the plurality of nodes (104) to generate the new block for appending the newly generated block in the distributed ledger (106), wherein the selected node (104) is either the first node (104) to solve the cryptographic puzzle or is a randomly selected node (104) from a set of nodes (104) which are the first to simultaneously solve the cryptographic puzzle.

17. The system (100) as claimed in claim 14, wherein the access control mechanism (110) is configured to temporarily disable the requester system (10) from establishing communication with one or more of other systems registered with the blockchain network (102) upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requester system (10), and temporarily disable the requestee system (12) from establishing communication with one or more of other the systems registered with the blockchain network (102) upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requestee system (10).

18. The system (100) as claimed in claim 14, wherein one or more of the requestor system (10) and the requestee system (12) comprise one or more of a vehicle, a roadside unit, an over-the-air server, an electronic control unit associated with the vehicle, and a software update providing sever.

, Description:

FIELD OF THE PRESENT DISCLOSURE

[0001] The present disclosure generally relates to establishing secure communications between connected systems, and more particularly, relates to a system and a method for establishing secure communication between connected vehicles using a feedback-based blockchain network.

BACKGROUND

[0002] Connected vehicles, in the context of Advanced Driver Assistance Systems (ADAS) or Autonomous Vehicles (AVs), are changing the way people drive cars. Vehicle-to-Everything (V2X) communication technology enables cars to communicate wirelessly and even maintain temporary networks between vehicles and surrounding infrastructure to share information related to mapping and localization, road hazards, entertainment, and other driving intelligence. V2X communication generally employs VANET (Vehicular Ad Hoc Networks), which is a peer-to-peer network of vehicles communicating among themselves in order to achieve safety on roads. Such peer-to-peer networks can provide real-time traffic information to vehicles and the surrounding infrastructure to facilitate, for example, autonomous navigation, accident prevention, emergency vehicle prioritization, and overall traffic management.
[0003] In recent times, vehicles have been equipped with various electronic communications systems such as radio receivers and transmitters to impart them with V2X communications capability. Such systems typically co-exist with other automotive control and safety systems, such as camera vision and radar systems, to enable the transit and exchange of data relating to the operation of the vehicle, while also ensuring safety and security of the vehicle, passengers, pedestrians, and surrounding infrastructure. However, the extensive use of connected components, networks, and software systems in connected vehicles renders them vulnerable to malicious attacks, cybersecurity-related threats such as malwares and Trojans, cyber-attacks such as spreading disinformation among networks, and the like.
[0004] In a V2X communications environment, such cybersecurity threats and malicious attacks may be implemented in a variety of ways. Attackers may modify and transmit communications content received from a vehicle’s software or hardware modules to surrounding vehicles or infrastructure. For example, attackers may modify the communication content to transmit inaccurate traffic conditions, false warnings related to forward collisions, blind spot situations, lane changes, unsafe passing, and inaccurate driving conditions or patterns, such as false statements about speeds, braking, directions, positions, and intersection movement. Additionally, attackers may modify transmission timing intervals of messages, delay transmission or delivery of messages, or send an excessive number of messages. Furthermore, attackers may attempt to impersonate vehicles or other network entities (e.g., servers), or act as intruders and attempt to use data stored on vehicles or other network entities to cause harm to vehicular network operations.
[0005] As connected vehicles become ubiquitous on the roads, detecting malicious communications activities and mitigating their impact on connected vehicles and infrastructure will become a significant concern. Therefore, cybersecurity systems also need to evolve for preventing suspected malicious entities from communicating with other connected vehicles and devices in the V2X network. Alternatively, the cybersecurity systems may be configured to instruct associated connected vehicle systems to ignore the messages sent from the suspected malicious entities.
[0006] A classic architectural solution to address the cybersecurity problem involves the use of encrypted keys to secure connected vehicles’ communication system. Another solution proposes a certificate-less authentication and message distribution protocol for VANET transmission security. However, such solutions implement the security structure using centralized systems. Centralized authentication or key generation systems may themselves be vulnerable to massive cyber-security threats that may compromise a centralized system to impact the entire network, thus creating massive losses.
[0007] Yet another way of ensuring security of connected vehicles communication systems is by profiling the vehicles operating on the roads. Vehicle profiling can be used to fill the gap left by the cybersecurity protocols and software. However, presently known techniques for vehicle profiling are complex and resource intensive to be useful in real-time environments where vehicle and passenger safety may depend upon split-second decisions.
[0008] Therefore, there is a need for a security system for a V2X network, which intelligently identifies and blocks connected vehicle systems suspected of malicious activities for safeguarding the connected vehicles systems and infrastructure.

SUMMARY

[0009] According to an exemplary aspect of the present disclosure, a method for establishing secure communication between connected systems in a blockchain network comprising a plurality of nodes is disclosed. The method includes receiving a transaction request by the plurality of nodes in the blockchain network from a requester system, wherein the transaction request comprises a unique code representing a specific data type requested by the requester system from a requestee system. The method also includes validating the transaction request, and subsequently generating and communicating cryptographic keys having a designated duration of validity to the requester system and the requestee system to establish direct communication between the requester system and the requestee system for the designated duration. The method further includes receiving one or more of a first feedback regarding the requester system from the requestee system and a second feedback regarding the requestee system from the requester system at the plurality of nodes, wherein each of the first feedback and the second feedback comprises a corresponding unique code representing a specific type of feedback. The method further includes updating one or more of a trust score associated with the requester system based on the unique code included in the first feedback and a trust score of the requestee system based on the unique code included in the second feedback. Furthermore, the method includes enabling at least one of the requester system and the requestee system to communicate with one or more of other connected entities in the blockchain network only when a corresponding updated trust score is above a designated threshold value.
[0010] The requester system corresponds to a requester vehicle, the requestee system corresponds to a requestee vehicle, the connected systems comprise one or more of other vehicles and connected vehicle systems registered with the blockchain network. In an embodiment, the method further comprises calculating the trust score associated with each of the vehicles and the connected vehicle systems registered with the blockchain network based on one or more of a number of transaction requests generated by a vehicle, a number of transaction requests processed by the vehicle, a number of transaction requests from the vehicle denied by the blockchain network due to incorrect information, a number of data denial or false information feedback against the vehicle, a number of explanations given by the vehicle for data denial, and a number of malicious attacks feedback against the vehicle. The method includes storing the trust score associated with each of the vehicles in the plurality of nodes, wherein each node of the blockchain network comprises a distributed ledger. The method also includes updating the trust score associated with the requester vehicle in the plurality of nodes based on the transaction request generated by the requester vehicle to obtain a modified requester score, and updating the trust score associated with the requestee vehicle after the requestee vehicle receives the specific data type request from the requester vehicle to obtain a modified requestee score. The method also includes updating the modified requester score and the modified requestee score further in the plurality of nodes based on the first feedback and the second feedback, respectively to obtain the corresponding updated trust score. Additionally, the method includes preventing at least one of the requester vehicle and the requestee vehicle from communicating with the other vehicles when the corresponding updated trust score is below the designated threshold value.
[0011] In an embodiment, the method comprises implementing a proof-of-work scheme comprising solving a selected cryptographic puzzle, by the plurality of nodes in the blockchain network, to process the transaction request to generate a new block and to store the transactions in the newly generated block. Additionally, the method includes appending the newly generated block in the distributed ledger.
[0012] In an embodiment, the method comprises processing the transaction request by each of the plurality of nodes at substantially the same instant of time to to solve the cryptographic puzzle.Further, the method comprises selecting a particular node from the plurality of nodes to generate the new block for appending the newly generated block in the distributed ledger, wherein the selected node is either the first node to solve the cryptographic puzzle or is a randomly selected node from a set of nodes which are the first to simultaneously solve the cryptographic puzzle.
[0013] In an embodiment, the method further comprises generating and transmitting one or more cryptographic keys with limited duration of validity by the selected node, post validation of the transaction request, to each of the requester vehicle and the requestee vehicle.
[0014] In an embodiment, each of the respective unique codes included in the transaction request, the first feedback, and the second feedback comprises a 32-bit data field value.
[0015] In an embodiment, the method further comprises temporarily disabling the requester vehicle from establishing communication with one or more of the other vehicles and the connected vehicle systems registered with the blockchain network upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requester vehicle. Additionally, the method includes temporarily disabling the requestee vehicle from establishing communication with one or more of the other vehicles and the connected vehicle systems registered with the blockchain network upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requestee vehicle.
[0016] In an embodiment, the method further comprises permanently disabling one or more of the requester vehicle and the requestee vehicle from establishing communication with one or more of the other vehicles and connected vehicle systems registered with the blockchain network when the corresponding vehicle has been temporarily blocked more than a designated number of times.
[0017] In an embodiment, the first transaction request received from a requestor vehicle (10) for a requestee vehicle (12) registered with the blockchain network (102) comprises a transaction identifier, public keys of the requester vehicle (10) and the requestee vehicle (12), digital signature of the requester vehicle (10), and the unique code. Furthermore, a subsequent transaction request from the requestor vehicle (10) comprises a transaction identifier, public keys of the requester vehicle (10) and the requestee vehicle (12), digital signature of the requester vehicle (10), hash of a previous block comprising the most recent transaction requested by the requester vehicle (10), timestamp of the previous block, and a unique code.
[0018] In an embodiment, the method further comprises automatically generating a transaction request comprising a specific unique code representative of a specific emergency situation by a vehicle registered with the blockchain network upon detecting the specific emergency situation, the emergency situation comprising one or more of a vehicle theft, vehicle collision, vehicle breakdown, and a medical emergency.
[0019] In an embodiment, the method further comprises automatically generating feedback by the requester vehicle regarding the requestee vehicle in case of one or more of data denial, denial due to poor network, denial due to emergency, false information received and cyberattack by the requester vehicle or the requestee vehicle.
[0020] In an embodiment, the specific data type requested by the requester vehicle comprises one of traffic data, navigation data, sensor data, infotainment data, vehicle data, and network data.
[0021] In an embodiment, the specific type of feedback received from the requester vehicle for the requestee vehicle comprises a unique code representative of one or more of data denial, false information received, and cyberattack information including malware attack, phishing attack, man-in-the-middle attack, denial of service attack, teardrop attack, eavesdropping attack, drive-by attack and password attack.
[0022] According to another exemplary aspect of the present disclosure, a system for establishing secure communication between connected systems is disclosed. The system comprises a blockchain network comprising a plurality of nodes. The plurality of nodes is configured to receive a transaction request from a requester system, wherein the transaction request comprises a unique code representing a specific data type requested by the requester system from a requestee system. The plurality of nodes are further configured to validate the transaction request, and generate and communicate one or more cryptographic keys having a designated duration of validity to the requester system and the requestee system to establish direct communication between the requester system and the requestee system only for the designated duration. The plurality of nodes are further configured to receive one or more of a first feedback regarding the requester system from the requestee system and a second feedback regarding the requestee system from the requester system at the plurality of nodes, wherein each of the first feedback and the second feedback comprises a corresponding unique code representing a specific type of feedback. The plurality of nodes are further configured to store one or more of a trust score of the requester system computed by an access control mechanism based on the unique code included in the first feedback and a trust score of the requestee system computed by an access control mechanism based on the unique code included in the second feedback. The plurality of nodes are further configured to enable at least one of the requester system and the requestee system to communicate with one or more of other connected systems registered with the blockchain network only when a corresponding updated trust score is above a designated threshold value.
[0023] In an embodiment, each node of the blockchain network comprises a distributed ledger, and wherein each node is configured to implement a proof-of-work scheme to process the transaction request to generate a new block with the transaction request stored therein and append the newly generated block in the distributed ledger.
[0024] The plurality of nodes process the transaction request at substantially the same instant of time to generate a new block. The blockchain network selects a particular node from the plurality of nodes to generate the new block for appending the newly generated block in the distributed ledger, wherein the selected node is either the first node to solve the cryptographic puzzle or is a randomly selected node from a set of nodes which are the first to simultaneously solve the cryptographic puzzle.
[0025] The access control mechanism is configured to temporarily disable the requester system from establishing communication with one or more of other systems registered with the blockchain network upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requester system. The access control mechanism is also configured to temporarily disable the requestee system from establishing communication with one or more of other the systems registered with the blockchain network upon receiving at least three consecutive feedbacks indicating non-trustworthiness of the requestee system.
[0026] Furthermore, according to certain aspects of the present disclosure, one or more of the requestor system and the requestee system comprise one or more of a vehicle, a roadside unit, an over-the-air server, an ECU associated with the vehicle, and a software update providing sever.
[0027] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described earlier, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

BRIEF DESCRIPTION OF THE FIGURES

[0028] The accompanying drawings, which are incorporated herein and constitute a part of this disclosure, illustrate exemplary embodiments, and together with the description, serve to explain the disclosed principles. The same numbers are used throughout the figures to reference like features and components, wherein:
[0029] FIG. 1 depicts a block diagram of a system for establishing secure communication between vehicles, in accordance with one or more exemplary embodiments of the present disclosure;
[0030] FIG. 2 depicts a schematic diagram of the system of FIG. 1 for establishing secure communication between two vehicles, in accordance with one or more exemplary embodiments of the present disclosure;
[0031] FIGS. 3A-3C depict exemplary transaction requests generated by vehicles, in accordance with one or more exemplary embodiments of the present disclosure;
[0032] FIGS. 4A-4F depict different tables with exemplary data field values for different types of communications scenarios, in accordance with one or more exemplary embodiments of the present disclosure;
[0033] FIG. 5 depicts an exemplary trust table that stored trust scores associated with each vehicle in a V2X blockchain network, in accordance with one or more exemplary embodiments of the present disclosure;
[0034] FIG. 6 depicts a table listing exemplary reward points provided to a connected vehicle system for maintaining a good code of conduct, in accordance with one or more exemplary embodiments of the present disclosure; and
[0035] FIG. 7 illustrates a flowchart depicting exemplary steps involved in a method for establishing secure communications between connected vehicle systems, in accordance with one or more exemplary embodiments of the present disclosure.

DETAILED DESCRIPTION

[0036] In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that these specific details are only exemplary and not intended to be limiting. Additionally, it may be noted that the systems and/or methods are shown in block diagram form only in order to avoid obscuring the present disclosure. It is to be understood that various omissions and substitutions of equivalents may be made as circumstances may suggest or render expedient to cover various applications or implementations without departing from the spirit or the scope of the present disclosure. Further, it is to be understood that the phraseology and terminology employed herein are for the purpose of clarity of the description and should not be regarded as limiting.
[0037] Furthermore, in the present description, references to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in one embodiment” in various places in the specification is not necessarily referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Further, the terms “a” and “an” used herein do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described, which may be requirements for some embodiments but not for other embodiments.
[0038] The following description presents an exemplary system and method for establishing secure communication between connected vehicle systems, for example, between two vehicles, or a vehicle and a roadside unit. Specifically, the embodiments presented herein describe a blockchain-based system that implements a feedback-based mechanism to identify and block originators of malicious communications to secure connected vehicles and the associated V2X infrastructure.
[0039] It is to be noted that the modern vehicles and driving behaviors are rapidly transforming with the introduction of connected and autonomous vehicles. Connected vehicles can interact with other vehicles in the vicinity to share information, including mapping and localization information, road traffic data, entertainment requests, collision information, and driving behavior to allow for safer driving experiences. To that end, connected vehicles are equipped with components such as a camera unit, an infotainment unit, a storage unit, a radar-sensing unit, and a Wi-Fi module. Each of these components generates data that could be shared with other connected vehicles or V2X systems for enhanced driving experiences.
[0040] For example, the camera unit can capture images of the road in the event of an accident, whereas the infotainment unit may provide navigation routes that can further be supplemented with information like traffic data. Further, the storage unit could provide entertainment data such as music or movies, the radar-sensing unit can provide information about potential obstacles ahead on the road, and the Wi-Fi module could provide ad-hoc network for internet connectivity and/or broadcast information about vehicular operation. The vehicles may also include a crash-indication unit, which can share information in case of an accident of the vehicle, and an anti-theft unit, which may incorporate hardware and software components signaling or alerting a user when a theft of the vehicle is detected.
[0041] However, in a vehicle communication network, certain vehicle communications units such as a compromised vehicle or a roadside unit may be used by attackers to send false information, which may jeopardize the safety of other vehicles and/or associated V2X infrastructure. For example, a malicious vehicle may broadcast false emergency brake light messages to cause neighboring vehicles to erroneously determine that a particular vehicle ahead is braking hard, thereby causing the other vehicles to employ emergency braking, which may cause accidents. The system and method of the present disclosure aims to mitigate such concerns by providing a framework to prevent malicious vehicles or other connected vehicle systems from communicating with other connected vehicles and associated systems.
[0042] Embodiments of the present system include a blockchain-based security system to secure V2X communications sessions, for example, including vehicle-to-vehicle, vehicle-to-infrastructure, and vehicle-to-cloud communication sessions. The blockchain network described in the present disclosure uses a unique code-based feedback mechanism to evaluate the exact nature of each communications request received from connected systems in a V2X network to prevent malicious vehicles or systems from compromising other vehicles and/or the V2X infrastructure.
[0043] Although, the present system may be used in various application areas. For example, the present system may be used to identify malicious roadside units based on unique codes transmitted by participating vehicles. In another example, the present system identifies an over-the-air (OTA) server transmitting malicious software updates to participating vehicles based on unique codes received as feedback from the participating vehicles to prevent the OTA server from transmitting malicious software updates to further connected systems in the V2X network. However, for clarity, the present system will be described herein with reference to securing communications between two connected vehicles operating in the V2X network. An embodiment of an exemplary system for establishing secure communication between connected vehicles is depicted and described in greater detail with reference to FIG. 1.
[0044] Referring to FIG. 1, a system (designated by the numeral 100) for establishing secure communication between vehicles is illustrated, in accordance with one or more embodiments of the present disclosure. As previously noted, although the system 100 is described herein with reference to securing communication between vehicles in a communications network 101, the system 100 may be similarly used to secure communications between other connected systems such as roadside units, traffic signals, user devices, and the like. To that end, the system 100 employs a blockchain network 102. As used herein, the term 'blockchain' includes all forms of electronic, computer-based, and distributed ledgers. Additionally, reference to the term ‘blockchain’ may also include consensus-based blockchain and transaction-chain technologies, permissioned and un-permissioned ledgers, shared ledgers, and variations thereof.
[0045] Further, FIG. 2 illustrates another exemplary block diagram of the system 100 of FIG. 1 depicting certain aspects of implementing the blockchain network 102 for establishing secure communication between the vehicles. In one embodiment, the blockchain network 102 is a peer-to-peer, electronic ledger which is implemented as a computer-based decentralized, distributed system made up of blocks, whereas each of the blocks stores a set of successful transactions and a set of unsuccessful transactions that have occurred within a designated period of time. Additionally, each block in the blockchain contains a hash of the previous block. All of the blocks in the blockchain are chained together to create a permanent, unalterable record of all transactions which have been written to the blockchain since its inception. Particularly, the present system 100 uses the blockchain network 102 to allow construction and use of a secure communication channel between the vehicles, and to enable incorporation of a securely published contract without the need for control, management, intervention or participation by central or additional parties.
[0046] To that end, as illustrated in FIGS. 1-2, the blockchain network 102 includes a plurality of nodes 104. In one embodiment, each node 104 of the blockchain network 102 includes and maintains the same copy of a distributed ledger 106. The distributed ledger 106 stores information related to transactions requests received from the connected vehicles in the blockchain network 102. Certain examples of the information stored by the distributed ledger 106 are depicted in FIGS. 3A-3C. The nodes 104 of the blockchain network 102 validate each of the received transaction requests either to allow or to prevent establishment of a communications session between two connected vehicles.
[0047] In certain embodiments, the system 100 adds a transaction request generated by a vehicle to the blockchain network 102 only post validation of the transaction request. The nodes 104 perform the validation of the transaction request using at least one of a hash and a timestamp of a block in the distributed ledger 106 that stores the most recent transaction request generated by the requester vehicle 10. All the nodes 104 of the blockchain network 102 solve a cryptographic puzzle upon validating the transaction request. A designated node 104, selected from the nodes 104, is a node that is the first to solve the cryptographic puzzle would generate a new block that includes the transaction request. The designated node 104 then shares the newly generated block with all other nodes 104 in the blockchain network 102 to achieve consensus. After achieving consensus, the new block is added to chain of blocks maintained by each of the nodes 104.
[0048] In certain embodiments, the system 100 mandates that the vehicle explicitly specifies the type of information it is requesting from another vehicle in all transaction requests to the blockchain network 102. The information may be related to traffic data, sensor data, entertainment data, and the like. By mandating the vehicle to explicitly specify the type of communication request, the present system 100 ensures that any potential threats targeting an internal architecture of the vehicle gets restricted to a certain component or a device in the vehicle. This mandate for specifying the type of request allows building of a concrete database in order to evaluate the credibility of the participating connected vehicles.
[0049] Additionally, the system 100 allows the vehicles to complain about other vehicles by sending a feedback to the blockchain network 102. It shall be appreciated that the vehicles may be equipped with cybersecurity software that has the capability of recognizing incoming attacks such as infected files, malwares and Trojans and report occurrence of such incoming attacks to the blockchain network 102 using predetermined unique codes.
[0050] The system 100 further provides an access control mechanism (ACM) (designated by the numeral 110 in FIG. 1) in the blockchain network 102. In one embodiment, the ACM 110 is a processing subsystem that is communicatively coupled to the nodes 104 in the blockchain network 102. The ACM 110 includes a database (not shown in FIGS) that stores a trust table having corresponding trust scores for each of the vehicles that have been part of the blockchain network 102. An example of a stored trust table is depicted in FIG. 5. According to aspects of the present disclosure, the system 100 uses the ACM 110 to block communications requests received from those vehicles in the blockchain network 102 whose associated trust scores are below a designated threshold value. In certain embodiments, the ACM 110 generates a blocking request to block a selected vehicle that is reported to be malicious consecutively for a predetermined number of times, for example, three times. The ACM 110 communicates the blocking request to the nodes 104 prior to blocking the selected vehicle. The nodes 110 receive the blocking request and determine if the selected vehicle is reported as malicious, at least three consecutive times based on transaction data stored in the distributed ledger 106. The ACM 110 blocks the selected vehicle only when all the nodes 104 confirm that the selected vehicle was reported as malicious consequently at least three times.
[0051] Generally, a vehicle needs to preregister with the blockchain network 102 to communicate with other vehicles in the block network 102. In one embodiment, the vehicle includes a blockchain application to establish a first time connection between the vehicle and the blockchain network 102. Using the blockchain application, a user of the vehicle inputs requisite information, for example a VIN (Vehicle identification number), or a number plate of the vehicle. The VIN serves as the vehicle’s fingerprint, as no two vehicles in operation have the same VIN. The VIN usually comprises 17 characters (combination of digits and letters) that act as a unique identifier for the vehicle. 1HGBH41JXMN109186 is an example of a VIN of the vehicle. Additionally, the user of the vehicle may have to authenticate himself or herself by inputting government-certified credentials such as a driving license of the user. The user may also have to input a vehicle fitness certificate issues by a government agency to register with the blockchain network 102.
[0052] After verifying input data provided by the user of the vehicle, the blockchain network 102 generates a unique username or an identity for the vehicle. In one embodiment, the user of the vehicle selects a password for a first time registration with the blockchain network 102. In another embodiment, the vehicle generates a key pair including a private key and a public key using which the first time registration may be completed. The vehicle stores the private key as secret information in an encrypted form. The private key generated by the vehicle is used to generate a signature that is verifiable using the public key but cannot be forged by anyone who does not have the private key.
[0053] For registering the vehicle with the blockchain network 102, the vehicle sends the generated public key to the blockchain network 102. The blockchain network 102 receives the public key and requests the vehicle to transmit the signature generated using the private key. In response, the vehicle transmits the signature to the blockchain network 102 that verifies the received signature using the public key to complete the first time registration of the vehicle. The generated public key may act as a password for subsequently logging into the blockchain application. The vehicle also broadcasts the public key to other vehicles in the vicinity to announce its presence in the blockchain network 102. Once registered, the system 100 enables the vehicle to receive and transmit communications messages to other connected vehicle systems in the blockchain network 102.
[0054] Specifically, the plurality of nodes 104 of the system 100 are configured to receive a transaction request from a vehicle acting as a requester vehicle (e.g., the vehicle 10 in FIGS. 1-2). In one embodiment, the transaction request includes a unique code representing a specific data type requested by the requester vehicle from another vehicle acting as a requestee vehicle (e.g., the vehicle 12 in FIGS. 1-2). Examples of the specific data type requested by the requester vehicle 10 from the requestee vehicle 12 include one of traffic data, navigation data, sensor data, infotainment data, vehicle data, and network data.
[0055] In the disclosed framework of the present system 100, the transaction request generated by the requestor vehicle 10 or the requestee vehicle includes a defined structure for the purpose of sending a request for a specific type of information or sending a specific feedback to the blockchain network 102. In an exemplary embodiment, the transaction request may generally have multiple fields including one or more of a transaction identifier (ID), requestee public key, requester public key, requester signature, hash of a previous block, time stamp of the previous block, and data field.
[0056] As used herein, the term ‘transaction ID’ refers to a transaction request identifier that is unique to a transaction request generated by the requestor vehicle 10. Requestee public key and requester public key refers to a public key generated by the requestee vehicle 12 and a public key generated by the requester vehicle 10, respectively. In one embodiment, the transaction request includes the public keys of both the requester vehicle 10 and the requestee vehicle 12.
[0057] Additionally, the transaction request includes the requester signature, which corresponds to a signature generated with a private key of the requester vehicle 10. Furthermore, the transaction request may also include a hash of the previous block that corresponds to a hash of a block in the distributed ledger 106 that stores a most recent transaction request generated by the requester vehicle 10. Similarly, a time stamp included in the transaction request refers to a time stamp of a block in the distributed ledger 106 that stores a most recent transaction request generated by the requester vehicle 10. The fields such as ‘hash of previous block’ and ’time stamp of previous block’ in the transaction field are used for validating the transaction request.
[0058] In certain embodiments, the transaction request includes a data field, which may be an alpha-numeric string using which the vehicles 10 and 12 request a specific type of information, or provide a feedback to the blockchain network 102 about malicious activities of another vehicle in the blockchain network 102. Additionally, the nodes 104 of the blockchain network 102 include a transaction request processing unit 112 for decoding the transaction requests received from the vehicles 10 and 12. The transaction request-processing unit 112 identifies the alphanumeric string mentioned in data field of the transaction request to determine a type of transaction request to allow the plurality of nodes 104 in the blockchain network 102 to process the request appropriately.
[0059] Unlike transaction requests generated by vehicles that have transmitted one or more transaction requests in the past, the transaction request generated by a vehicle that is newly registered with the blockchain network 102 may only include a transaction ID, an associated public key, an associated digital signature, and a data field.
[0060] In one embodiment, a user of the requestor vehicle 10 selects a specific type of information he or she needs from a list displayed at a display interface of an infotainment system (not shown) associated with the requestor vehicle 10. The requester vehicle 10 generates a transaction request by including a unique code specific to the type of information selected by the user and other fields such as a transaction ID, an associated public key, a public key of the requestee vehicle 12, an associated signature, an associated hash and time stamp of the previous block.
[0061] In another embodiment, the requestor vehicle 10 itself identifies the specific type of information it needs in an automated mode based on associated sensor measurements and automatically generates the transaction request without need for user inputs. For example, the requestor vehicle 10 identifies events such as vehicle theft and emergency using an anti-theft unit deployed in the vehicle 10 in the automated mode. The requestor vehicle 10 then automatically generates a transaction request having a unique code that represents a vehicle theft event and communicates the transaction request to the blockchain network. Similarly, the requester vehicle 10 automatically identifies other events related to vehicle collision, vehicle breakdown, etc. using on-board sensors, generates specific transaction requests, and communicates the transaction requests to the blockchain network 102 for validation.
[0062] FIGS. 3A-3C depict exemplary transactions requests generated by the requester vehicle 10. As noted previously, the transaction requests generated by the requester vehicle 10 include corresponding data fields. In one embodiment, the data field provides a unique code which is a 32-bit value containing a hexadecimal number of length 8. For instance, FIGS. 3A-B depict structures of the transaction requests generated by the requester vehicle 10 having corresponding data fields including “xxxx00xx”, “xxxx10xx” and “xxxx11xx”, respectively. The blockchain network 102 identifies whether a particular transaction request is generated by the requester vehicle 10 or the requestee vehicle 12, whether the transaction request is related to a request for information or a feedback communication, etc. based on data field in the transaction request.
[0063] For example, the blockchain network 102 identifies whether the transaction request is generated by the requester vehicle 10 based on first four digits of the data field “xxxxxxxx”. The blockchain network 102 identifies that the transaction request is generated by a first requester vehicle 10 when first four digits of the transaction request are “0000.” Similarly, the blockchain network 102 identifies that the transaction request is generated by a second requester vehicle 12 when first four digits of the transaction request are “1111.” In other words, the first four digits of the data field allow the nodes 104 in the blockchain network 102 to identify the origin of the transaction request. Further, the fifth digit and the sixth digit of the data field represent whether the transaction request is an information request or a feedback about a past communication. The data field “111100xx” indicates that a request for information is received from the second requester vehicle 12 to the blockchain network 102. Such communication request is sent by the requester vehicle 10 to the blockchain network 102 in order to seek network permission to communicate with another vehicle, i.e. the requestee vehicle 12.
[0064] In certain embodiments, the system 100 also allows for a special scenario where the requestee vehicle 12 can send a transaction request to the blockchain network 102 to block the requester vehicle 10 if the requestee vehicle 12 identifies the requester vehicle 10 to be malicious. The data field “xxxx10xx” or “xxxx11xx” represents feedback about anomalous data exchange. The feedback can be sent by both the requester vehicle 10 and the requestee vehicle 12 in order to inform the blockchain network 102 about any malicious activities or communications denials, which have taken place in the communication exchange. The communications denial feedback is typically sent by the requester vehicle 10 in order to inform the blockchain network 102 that the requestee vehicle 12 has denied data exchange with the requester vehicle 10. In one embodiment, the proposed system 100 also allows the requestee vehicle 12 to send the transaction request to the blockchain network 102, where the transaction request includes a data field that provides explanation for the denial of data requested by the requester vehicle 10. It shall be understood that both the requester vehicle 10 and the requestee vehicle 12 can send the feedback about malicious activities against another vehicle.
[0065] Furthermore, the last two digits, i.e. the seventh digit and eighth digit of the data field represent a specific type of information request (shown in FIG. 4A). Alternatively, the last two digits may represent a specific type of malicious activity reported by the requester vehicle 10 or by the requestee vehicle 12 against another (shown in FIG. 4D). In yet another embodiment, the last two digits may represent a specific type of data denial (shown in FIG. 4E) reported by the requester vehicle 10, or a specific type of denial explanation (shown in FIG. 4F) provided by the requestee vehicle 12.
[0066] As noted previously, FIGS. 4A-4F provide different tables storing exemplary data field values. In particular, FIG. 4A provides ‘Table 1’ which lists exemplary data field values corresponding to different types of transaction requests from the requester vehicle 10. FIG. 4B provides ‘Table 2’ which lists exemplary data field values corresponding to different types of automatic transaction requests from the requester vehicle 10. FIG. 4C provides ‘Table 3’ which lists exemplary data field value for type of transaction request from the requestee vehicle 12. FIG. 4D provides ‘Table 4’ which lists exemplary data field values for different types of transaction requests related to feedback from the requester vehicle 10 or the requestee vehicle 12. FIGS. 4E and 4F provide respective ‘Table 5’ and ‘Table 6’ which lists exemplary data field values for different types of transaction requests related to complaint about denial of information from the requester vehicle 10 and explanation for denial of information from the requestee vehicle 12, respectively.
[0067] Referring back to FIGS. 1-2, in a particular scenario, the requester vehicle 10 may seek a specific type of information from the requestee vehicle 12 via the blockchain network 102. To that end, the requester vehicle 10 generates a transaction request including a public key of the requestee vehicle 12 and a unique code representing the specific type of requested information, and transmits the transaction request to the blockchain network 102. The blockchain network 102 receives and validates the transaction request before establishing secure communications between the vehicles 10 and 12 for achieving exchange of data.
[0068] Particularly, the nodes 104 in the blockchain network 102 process the transaction request and identify if a hash and timestamp mentioned in the transaction request match a hash and timestamp, respectively, associated with a block in the distributed leger 106 that stores the most recent transaction request placed by the requester vehicle 10. The blockchain network 102 validates the transaction request once a match between the hashes and timestamps is verified. . Further, the nodes 104 collate transaction requests received within a designated period of time including the transaction request generated by the requestor vehicle 10 to generate a block. Further, each of the nodes 104 generates a new block including the transaction requests received over the same period of time. In one embodiment, the blockchain network 102 presets a block creation time to a designated duration (e.g., 1 second) by selecting a difficulty level of a cryptographic puzzle to be solved by the nodes 104. Greater the difficulty level of the cryptographic puzzle, greater is the time taken by the nodes 104 to create a single block. In one embodiment, the blockchain network 102 selects the difficulty level of the cryptographic puzzle depending upon a number of leading zeros of a hash of the new block such that when having only one leading zero, a time taken by the nodes to generate the new block is 1 second. However, it is to be understood that, the blockchain network 102 may be configured to set a block creation time to any designated duration based on the difficulty level of a cryptographic puzzle.
[0069] Furthermore, each node 104 of the blockchain network 102 is configured to implement a proof-of-work scheme to solve the cryptographic puzzle by determining a nonce value such that the hash of the new block is less than or equal to a designated target set by the blockchain network 102. A particular node that first solves the cryptographic puzzle by determining the nonce value transmits an associated version of blockchain including the new block to all other nodes 104 in the blockchain network. The nodes 104 then verify content associated with the transmitted version of blockchain and update a corresponding version of blockchain to mimic the transmitted version of blockchain after validating the content and achieving consensus amongst the nodes 104. In one embodiment, the blockchain network 102 selects a designated node randomly if multiple nodes 104 solve the cryptographic puzzle at substantially the same instant of time for transmitting an associated version of blockchain to all other nodes 104. It may be noted that using such a modified proof-of-work scheme that allows for random selection of the designated node helps in preventing a blockchain split. Consequently, such a modified proof-of-work scheme overcomes problems faced by typical proof-of-work algorithms such as scalability and fork blocks.
[0070] In certain embodiments, the particular node, which either solved the cryptographic puzzle first or was randomly chosen by the blockchain network 102, generates and transmits cryptographic keys (as represented by dashed arrows in FIG. 2) to the requester vehicle 10 and the requestee vehicle 12. The generated cryptographic keys facilitate establishment of a secure communication channel between the vehicles 10 and 12. In one embodiment, the generated cryptographic keys have only a designated duration of validity following which they expire. Thus, the blockchain network 102 allows communication between the vehicles 10 and 12 only for the designated duration to ensure that communication between the vehicles 10 and 12 is generally pertaining to a specific type of transaction per original request., The established communication channel is closed upon expiry of the designated duration to prevent exchange of any other type of data (e.g., malicious content) by any of the vehicles 10 and 12 to another vehicle.
[0071] In the present disclosure, the vehicles 10 and 12 are enabled to provide feedback regarding a past data exchange to the blockchain network 102. In particular, the plurality of nodes 104 are configured to receive one or more of a first feedback associated with the requester vehicle 10 from the requestee vehicle 12, and a second feedback associated with the requestee vehicle 12 from the requester vehicle 10. Each of the first feedback and the second feedback includes a corresponding unique code representing a specific type of feedback. For example, as depicted in FIG. 2, the requestee vehicle 12 may provide a feedback to the blockchain network 102 (as represented by solid arrows in FIG. 2) that includes a unique code “11111008” representing an attempt of password attack by the requester vehicle 10. It may be appreciated that the requester vehicle 10 may also provide feedback to the blockchain network 102 about the data exchange there between. The specific type of feedback received from the requester vehicle 10 (i.e. the first feedback) includes notice of one or more of a data denial, false information received, and cyberattack information. The cyberattack information may include details regarding a malware attack, phishing attack, man-in-the-middle attack, denial of service attack, teardrop attack, eavesdropping attack, drive-by attack, and/or password attack. Similarly, the specific type of feedback received from the requestee vehicle (i.e. the second feedback) includes cyberattack information including a malware attack, phishing attack, man-in-the-middle attack, denial of service attack, teardrop attack, eavesdropping attack, drive-by attack, and/or password attack.
[0072] In one embodiment, the vehicles 10 and 12 automatically generate feedback upon detecting one or more of a data denial attack, denial due to poor network, denial due to emergency, false information received, and cyberattack. Upon detecting a malicious attack, a security software, for example, a virus detector installed in the vehicle 12 is interfaced with the blockchain application to send a transaction request including a specific unique code representative of the attack to the blockchain network 102 automatically.
[0073] In one embodiment, the system 100 uses the ACM 110 to calculate a trust score associated with each of the vehicles registered with the blockchain network 102 based on information related to past transaction requests and associated feedback. Particularly, the ACM 110 calculates the trust score based on one or more of a number of transaction requests generated by a vehicle, transaction requests processed by the vehicle, and/or transaction requests from the vehicle that were denied by the blockchain network 102 due to incorrect information. Additionally, the ACM 110 calculates the trust score based on one or more of a number of data denial or false information feedback against the vehicle, explanations given by the vehicle for data denial, and a number of feedbacks identifying the vehicle as the perpetrator of malicious attacks. The calculated trust score associated with each of the vehicles is stored in a trust table in a database associated with the ACM 110. In case of a transaction request (e.g., for data exchange between the requester vehicle 10 and the requestee vehicle 12) being validated and a feedback generated therefor, the plurality of nodes 104 are further configured to update one or more of a trust score of the requester vehicle 10 based on the unique code included in the first feedback and a trust score of the requestee vehicle 12 based on the unique code included in the second feedback. In particular, the trust score associated with the requester vehicle 10 may be updated every time a transaction request is generated by the requester vehicle 10. Similarly, the trust score associated with the requestee vehicle 12 is updated every time the requestee vehicle 12 receives the specific data type request from the requester vehicle 10. The modified requester score and the modified requestee score are further updated in the trust table maintained by the ACM 110 based on the first feedback and the second feedback, respectively, to obtain the corresponding updated trust scores.
[0074] In one embodiment, the ACM 110 dynamically calculates a trust score associated with each of the vehicles registered with the blockchain network 102 based one or more trust fields. For example, in an exemplary implementation, the ACM 110 dynamically calculates a trust score associated with each of the vehicles based on six trust fields. A first exemplary trust field (T1) represents a number of transaction requests generated by the vehicle, and a second exemplary trust field (T2) represents number of transaction requests processed by the vehicle. Further, a third exemplary trust field (T3) represents number of transaction requests that failed due to incorrect information provided by the vehicle, and a fourth exemplary trust field (T4) represents number of data denial or false information cases against the vehicle as a requestee vehicle. Moreover, a fifth exemplary trust field (T5) represents number of explanations given by the vehicle for data denial, and a sixth exemplary trust field (T6) represents number of malicious attacks cases against the vehicle as a requestee vehicle and a requester vehicle.
[0075] For certain types of malicious attacks, the ACM 110 assigns different counts to different malicious attacks based on their corresponding severity. For example, for transaction requests with data field values such as “xxxx1004” and “xxxx1007” representing “denial of service attack” and “drive by attack,” respectively, the ACM 110 counts a number of times such attacks have occurred as two rather than one. In another example, for a data field value “xxxx1008” representing “password attack”, the ACM 110 counts a number of times the password attack has occurred as three instead of one for the purpose of calculating a trust score of a vehicle. Furthermore, in certain embodiments, the trust table (exemplarily depicted as ‘Table 7’ in FIG. 5) that is generated and maintained by the ACM 110 forms a part of the distributed ledger 106 stored in each node 104. Thus, each of the nodes 104 in the blockchain network 102 has access to an access control list having the trust table, which in turn, is used to calculate trust scores of vehicles as discussed in subsequent paragraphs.
[0076] In one embodiment, the ACM 100 calculates a trust score associated with a vehicle by calculating a percentage (P1) of transaction requests that were initiated by the vehicle as a requestor vehicle and were successfully validated by the blockchain network 102. Further, the ACM 110 calculates a percentage (P2) of transaction requests for which the vehicle has provided the requested information. In addition, the ACM 110 calculates a percentage (P3) of non-malicious communications by the vehicle with other vehicles both as a requester vehicle and a requestee vehicle. Particularly, ‘P1’ is calculated, for example, using equation (1):

P1= (T1-T3)/T1 × 100 (1)

[0077] ‘P2’ is calculated, for example, using equation (2):

P2= (T2-(T4-T5))/T2 × 100 (2)

[0078] Further, ‘P3’ is calculated, for example, using equation (3):

P3= ((T1+T2) - T6) / (T1+T2) × 100 (3)

[0079] The ACM 110 also takes weightages of the percentage factors ‘P1’, ‘P2’, and ‘P3’ into account for calculating the trust score (T). For example, the first factor (P1), the second factor (P2) and the third factor (P3) may have an associated weightage of 20%, 10%, and 70%, respectively. The ACM 110 may calculate the trust score T, for example, using equation (4):

T = (20 × P1 + 10 × P2 + 70 × P3)/100 + R (4)

wherein ‘R’ corresponds to reward points.

[0080] In one embodiment, the ACM 110 is configured to provide reward points to the vehicle for maintaining good code of conduct. The reward points help improve the trust score of the vehicle. The ACM 100 grants the reward points based on good reputation indicated by a number of consecutive transactions where a request generated by the vehicle has been successfully validated (designated as ‘P1_cons’), the vehicle has provided the requested information (designated as ‘P2_cons’), and the vehicle has not been reported for malicious activities either as a requestee or as a requester (designated as ‘P3_cons’). FIG. 6 provides a table (‘Table 8’), which lists the reward points provided by the ACM 110 for various factors such as ‘P1_cons’, ‘P2_cons’, and ‘P3_cons’.The terms ‘P1_rw’, ‘P2_rw’ and ‘P3_rw’ depicted in FIG. 6 denote the reward points given for the three aforementioned factors. Thus, the ACM may calculate the trust score (T) of the vehicle, for example, using equation (5):

T = (20 × (P1+P1_rw) + 10 × (P2+P2_rw) + 70 × (P3+P3_rw)) /100 (5)

[0081] According to aspects of the present disclosure, the plurality of nodes 104 enable the requester vehicle 10 or the requestee vehicle 12 to communicate with other vehicles registered with the blockchain network 102 only when a corresponding updated trust score is above a designated threshold value. Furthermore, the ACM 110 prevents at least one of the requester vehicle 10 and the requestee vehicle 12 from communicating with the other vehicles when the corresponding updated trust score is below the designated threshold value. It may be appreciated that the designated threshold value may be a predefined value. For instance, in an exemplary implementation, the designated threshold value may be ‘70’. Additionally, the nodes 104 generate and allocate cryptographic keys with a limited duration of validity to each of the requester vehicle 10 and the requestee vehicle 12 only if the trust scores of both the vehicles are above the designated threshold value to secure corresponding communications.
[0082] Furthermore, in certain embodiments, the ACM 110 blocks or expels vehicles from the blockchain network 102 based on their behavior as indicated by feedback received from other vehicles. Specifically, the ACM 110 processes feedback received from other vehicles to investigate if the feedback is reliable. The ACM 110 stores data associated with each of the vehicles in a table to facilitate fast and easy retrieval of a history of a selected vehicle and other vehicles complaining about the selected vehicle. The ACM 110 determines if feedback received from vehicles complaining about the selected vehicle are reliable based on a history of the complaining vehicles. The ACM 110 subsequently blocks or expels the selected vehicle permanently from the blockchain network 102 upon verifying that the received feedback is reliable. It may be appreciated that blocking malicious vehicles infected with malware, Trojan, or viruses protects other vehicles participating in the blockchain network 102 from irreparable harm.
[0083] Accordingly, in one embodiment, the ACM 110 is configured to temporarily disable the requester vehicle 10 and/or the requestee vehicle 12 from establishing communication with one or more of the other vehicles registered with the blockchain network 102 upon receiving feedback from other vehicles that indicates untrustworthiness of the vehicle 10 or 12 post three or more number of consecutive transaction requests from the corresponding vehicle. However, in certain embodiments, the ACM 110 seeks for a consensus among the nodes 104 regarding the conduct of the vehicle prior to blocking a vehicle from the blockchain network 102.The ACM 110 blocks the vehicle for a fixed duration of time if the consensus of the nodes 104 is against the vehicle. Further, the ACM 110 is configured to permanently disable one or more of the requester vehicle 10 and the requestee vehicle 12 from establishing communication with one or more of the other vehicles registered with the blockchain network 102 when the corresponding vehicle has been temporarily blocked for more than a designated number of times. For example, if a vehicle has been blocked three times, the ACM 110 seeks a consensus among the nodes 104 in order to permanently expel the vehicle from the blockchain network 102. If a consensus is achieved, the vehicle is expelled from the blockchain network 102.
[0084] If a vehicle misuses feedback transactions such as falsely reporting other vehicles as perpetrators of data denial or malicious activities, the ACM 110 determines if the vehicle has to be blocked or expelled based on one or more parameters. Examples of such parameters include a reputation score of a complaining vehicle, reputation scores of reported vehicles, and history of all associated vehicles including the complaining vehicle and the reported vehicles. The ACM 110 may then block the complaining vehicle for a fixed duration of time if an associated reputation score is below a threshold value, the complaining vehicle was involved in malicious activities in the recent past, and based on a consensus among the nodes 104.
[0085] FIG. 7 illustrates a flowchart 700 depicting steps involved in an exemplary method for establishing secure communication between vehicles using a blockchain network (such as, the blockchain network 102) comprising a plurality of nodes (such as, the nodes 104). At step 702, the vehicles associated with the blockchain network 102 broadcast their corresponding public keys. At step 704, a transaction request is received by the plurality of nodes 104 in the blockchain network 102 from a vehicle acting as a requester vehicle 10. Herein, the transaction request includes a unique code representing a specific data type requested by the requester vehicle 10 from another vehicle acting as a requestee vehicle 12. The transaction request also includes the public key of the requestee vehicle 12 . At step 706, the nodes 104 of the blockchain network 102 validate the transaction request. Further, as noted previously, a particular node that solved the cryptographic puzzle first or was randomly chosen by the blockchain network 102 generates and communicates cryptographic keys having a designated duration of validity to the requester vehicle 10 and the requestee vehicle 12 to establish direct communication there between only for the designated duration. At step 708, the requester vehicle 10 and the requestee vehicle 12 exchange data using the cryptographic keys.
[0086] At step 710, one or more of a first feedback associated with the requester vehicle 10 from the requestee vehicle 12 and a second feedback associated with the requestee vehicle 12 from the requester vehicle 10 is received at the plurality of nodes 104. Herein, each of the first feedback and the second feedback includes a corresponding unique code representing a specific type of feedback. At step 712, one or more of a trust score of the requester vehicle 10 is updated based on the unique code included in the first feedback and a trust score of the requestee vehicle 12 is updated based on the unique code included in the second feedback. At step 714, at least one of the requester vehicle 10 and the requestee vehicle 12 is allowed to communicate with one or more of other vehicles registered with the blockchain network 104 only when a corresponding updated trust score is above a designated threshold value. Alternatively, at least one of the requester vehicle 10 and the requestee vehicle 12 is prevented from communicating with the other vehicles in the blockchain network 102 when the corresponding updated trust score is below the designated threshold value.
[0087] Embodiments of the system 100 that includes the blockchain network 102 for implementing the feedback mechanism and the Access Control Mechanism 110 prevent malicious vehicles from compromising the connected vehicle systems in the V2X network. The blockchain network 102 adds a new block to the distributed ledger 106 after achieving a consensus among the nodes 104. Central to the blockchain network 102 is the principle of hashing and Proof-of Work (PoW) consensus algorithm. These principles enforced along with the ACM 110 verify if the security of a vehicle and/or the blockchain network 102 is compromised. Additionally, the system 100 allows the vehicle to seek only the requested information from another vehicle by mandating inclusion of a unique code identifying the request type in the original request Furthermore, the system 100 configures vehicles to use 32-bit data field in transaction requests to enable the blockchain network 102 to identify if the transaction requests are requests for information or feedback related to other vehicles.
[0088] Embodiments of the present system 100 also prevent a blockchain split, for example experienced by blockchain scalability and fork blocks, by allowing random selection of a node 104 if a block is created by multiple nodes at substantially the same time. The system 100 allows vehicles to complain about other vehicles using transaction requests. The blockchain network 102 further maintains an access control list that is dynamically updated in the nodes 104 based on the feedback to profile vehicles registered with the blockchain network 102. To that end, the ACM 110 includes a trust table that stores an associated trust score for all the vehicles registered with the blockchain network 102. Vehicles that are infested with malicious content or trying to initiate cyber-attacks against other vehicles are blocked or expelled from the blockchain network 102 based on a consensus among the nodes 104.
[0089] It may be noted that the present system 100 and method can be implemented for securing data communication, road monitoring, traffic-flow information sharing, vehicle profiling, automotive software update, and information broadcasting applications. Mandating use of a unique code such as a 32-bit data field with transaction requests makes a size of the transaction request small and less complex, thus allowing a single block to store a larger number of transaction requests. Due to this simplicity, the blockchain network 102 scales more easily compared to conventional approaches.
[0090] Thus, embodiments of the present system 100 and method enable vehicle profiling to supplement the cyber-security protocols and software used in a V2X network. The vehicle profiling is achieved by creating the distributed ledger 106 that is not only immutable and indestructible but also is shared and replicated among nodes 104 in the highly decentralized blockchain network 102. The claimed implementation of the blockchain network 102 possess various advantages over centralized or decentralized networks such as data security, data immutability, and resistance to cyber-attacks. The blockchain network 102 implemented by the present system 100, thus facilitates secure communication between any two communication entities, for example, between vehicles, roadside units, over-the-air servers, Electronic Control Units associated with a vehicle, and/or associated sever systems. Further, the blockchain network 102 obviates the need to store content transferred between the vehicles, which helps to reduce storage space and cost.
[0091] It may be appreciated that although the present disclosure has been described in terms of implementing the disclosed system and method for vehicular applications, the underlying framework can be implemented for any applications involving exchange of information in a peer-to-peer network. For instance, the proposed system can be implemented in applications such as providing software updates to vehicles such as automotive software updates, Over-The-Air updates, home automation software update, etc. The system and method of the present disclosure allow connected systems to send feedback to the blockchain network 102 to report or complain about other software products to protect the communications network and corresponding communicating entities from malicious activities.
[0092] The foregoing descriptions of specific embodiments of the present disclosure have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The exemplary embodiment was chosen and described in order to best explain the principles of the present disclosure and its practical application, to thereby enable others skilled in the art to best utilize the present disclosure and various embodiments with various modifications as are suited to the particular use contemplated.