V2V, V2X, Autonomous Vehicles

Beyond the capabilities described in the “Vehicle Life-Cycle Management” page on this site, TrustCentral’s technology offers additional tools and capabilities that are applicable for autonomous vehicles:

PRIVACY; IDENTITY EXPOSURE AND SHARING

  • Support of multiple identities to enhance endpoint privacy control (e.g., only identity information required for each specific purpose is made available)
  • The Security Ecosystem includes a capability to support multiple identities for endpoints and/or groups that can be useful for V2V. For privacy concerns a Rear Sensor Group or Vehicle Group may utilize more than one identity depending on defined circumstances or in response to specified external endpoints, groups or queries.
  • Example: (a) an identity can be as minimal as generic make and model of vehicle; or (b) an second identity providing more detailed information such as, licensing info, VIN, registration info, insurance info, etc.
  • An authenticated police officer would be provided with more info than an ordinary passing vehicle
  • Flexible support for emergency vehicles: when not operating under emergency, maintains non-emergency identity truck; responding in an emergency, identity becomes that of a responding emergency vehicle

TRUSTWORTHINESS, REPUTATION

  • A robust system of scoring endpoint (e.g., AV, infrastructure, etc.) trustworthiness, reputation and other metrics
  • An ability to deliver trusted records providing trusted origin (with auditability) to a blockchain or other databases
  • Reliable trust and reputation scores available for vehicles, infrastructure, devices, groups, etc.
  • Confirmation of a vehicle’s claimed identity (e.g. emergency vehicle) through PKI certificates and a central Attribute Authority (AA)

ENCRYPTION, DIGITAL SIGNING, DIGITAL AUDIT TRAILS

The solution supports public key cryptography capabilities: encryption between endpoints; digital signing; and digital audit trails.


CROSS CERTIFICATION

It is assumed that vehicles will be managed under an OEM’s PKI with an integrated Attribute Authority (AA). Such arrangements will result in multiple, siloes OEM PKI’s. Certification Authorities of the various PKI’s will be authenticated to extend trust one to another. Vehicles managed under one OEM’s PKI may be authenticated for trusted communication with vehicles and/or infrastructure and/or other devices managed by another PKI (e.g., that of another OEM, governmental entity, etc.).

The integration and cross-certification of separate infrastructure sources using PKI’s administered by independent government, states, cities, and possibly private businesses may be implemented.

The diagram below shows how a truck managed under one OEM’s PKI and a vehicle managed under a second OEM’s PKI may trust an authenticated police car managed under a government PKI.


 

 

 


MITIGATING VEHICLE-LEVEL NETWORKING AND COMPUTING CAPACITY REQUIREMENTS

One of the technical challenges to be addressed by the automotive industry is the communication requirements to support V2V and V2X for autonomous vehicles. For example, the AECC (Automotive Edge Computing Consortium, www.aecc.org) describes itself and the challenges it intends to address as: “A consortium for driving the network and computing infrastructure needs of automotive big data. In the future, connected cars will typically not only allow for safer driving but also for smoother traffic flows and optimization of energy consumption giving lower emissions, which altogether will significantly improve the driving experience resulting in an environmental benefit. Those future automotive services will be expected to require a much larger data transfer capacity than used by connected cars today and to accommodate this, the current network architectures and computing infrastructures need to evolve. The consortium focuses on increasing network and computing capacity to accommodate automotive big data smartly between vehicles and the cloud using edge computing and more efficient system design.”

The AECC’s approach appears excellent and well thought out. TrustCentral’s technology may potentially mitigate the presently anticipated demand for network and computing capacity. Mitigating that need may reduce costs as well as the network and computing capacity to support anticipated needs. There are several ways in which the security ecosystem can support these efforts.

The authentication of vehicle and infrastructure identity, the determination of trustworthiness and reputation of vehicles, etc. ideally should typically not have to be completed by each individual vehicle-2-vehicle exchange nor should these activities have to fully depend on the constrained resources at the vehicle level. Rather (to the extend possible and practicable) such determination preferably could be done at the Attribute Authority-PKI level utilizing more powerful computational resources available to an AA as well as the higher speed networking resources in the cloud. Such an approach can provide for more efficient cross certification and authentication between AA’s of separate PKI’s.

For example, when examining the above diagram, one can observe numerous relationships between vehicles and infrastructure. If most vehicles need to communicate individually with many other vehicles to gain identity and other information about them, and particularly to authenticate those vehicles and determine their trustworthiness, the communication requirements and computation requirements at the vehicle-level will be considerable. Shifting a significant portion of those determinations away from vehicle-level resources to AA’s in the cloud (which can provide summarized, trusted data pushed to vehicles) can mitigate such demands.

Attribute Authorities can obtain the information that they need in at least two ways: (a) by a managed vehicle’s direct communications with an unknown vehicle that is managed under another PKI; or (b) by an AA’s cross certification with another PKI then pushed to a vehicle, particularly when GPS and movement information is also included in the cross certified information.

In either event, an Attribute Authority (AA) should generally be able to intelligently predict a new vehicle’s location and be able to authenticate its PKI identity certificate and/or group attribute certificate. Subsequently when that now-known vehicle needs to establish V2V communication with any additional managed vehicle the previously completed authentication/trustworthiness process need not be repeated. The AA should be able to immediately authenticate that vehicle to any of its supported vehicles as needed. As a result, demand on computing and network resources at the vehicle level will be reduced. (A similar process can be applied to infrastructure.)

These procedures can become more efficient as AA’s learn to predict locations of vehicles. Ideally the AA should know the GPS coordinates of its managed vehicles and be able to determine their speed and direction. The AA should be able to determine locations of non-managed vehicles based on those vehicles’ prior interactions with the AA’s managed vehicles. An AA can have an ability to track a larger and broader number of vehicles than any single vehicle is capable of doing. An AA will typically already possess authenticated vehicle information of such a non-managed vehicle prior to a managed vehicle’s awareness of needing such information. The AA could push appropriate information about other vehicles to a managed vehicle prior to the initial contact between those vehicles.

An AA’s authentication (and other endpoint metrics) on a broad and wide basis can help to keep the security ecosystem in a position in which it can maintain current authentication status, identity trust, trustworthiness, reputation scores and/or other scoring of IoT endpoints, IoT devices groups, vehicles, infrastructure, etc.

Referring to the diagram, OEM 2 might have pre-determined that the police vehicle is an authenticated police vehicle. The AA of OEM 2 could inform vehicle 2 of this information without vehicle 2 having to ask. Such a method would likely reduce V2V traffic and computation at the vehicle level that might otherwise be used because vehicle 2 and the police vehicle did not have to query each other, thus avoiding their likely separate queries to PKI 2 and the Government PKI. That could result in a possibly repeated cross-certification query to authenticate, validate trust and/or reputation of the police vehicle and then for the two PKI’s to report back to vehicle 2 and the police vehicle.