Autonomous Vehicles & V2X

By using the technology of its Building Blocks, the TrustCentral API will offer unique and valuable services for the autonomous automotive industry in two broad areas:

  • The security, privacy, control and management of IoT devices in vehicles and the infrastructure with which vehicles will communicate; and
  • The mitigation of enhanced vehicle-level network architectures and computing infrastructures otherwise required to support larger data transfer capacity to support autonomous vehicles

SECURITY

  • A solution built on a foundation of PKI (Public Key Infrastructure) that incorporates device root-of-trust, best practices, etc.,
  • Providing PKI-Enforced Whitelisting of IoT devices whereby devices only talk to previously authenticated devices and no others
  • IoT Device Groups; PKI-based secured groups of devices (e.g., a vehicle) and subgroups (e.g., front sensors) providing unique stratifications for security and management

ENCRYPTION

  • An Inviter-Invitee Protocol to establish persistent, secure relationships between authenticated endpoints
  • Providing a trusted exchange of authenticated pubic keys of between endpoints
  • Data encryption; digital signing; and digital audit trails

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)

TRUST AND REPUTATION

  • A system of scoring endpoint trustworthiness, reputation and other metrics
  • An ability to deliver trusted records providing trusted origin (with auditability) to a blockchain or other database

CROSS-CERTIFICATION

  • An innovative system of cross-certification between PKI’s that may be managed by different OEM’s, governmental entities, etc., in order to extend authenticated and trusted relationships of known vehicles and infrastructure managed within one PKI to be shared with other PKI’s and with their managed vehicles and infrastructure

MITIGATING VEHICLE-LEVEL NETWORKING AND COMPUTING CAPACITY REQUIREMENTS

  • Mitigating otherwise anticipated increased vehicle-level networking and computing capacity requirements for autonomous vehicles by leveraging TrustCentral platform computing resources

 

VEHICLE-2-X (“X” = “anything”)

Vehicle-to-X (V2X, i.e., anything) is a superset of V2V and other terms, such as Vehicle-to-Infrastructure (V2I) and Vehicle-to-Grid (V2G). Vehicle-to-X (V2X) refers to an intelligent transport system where all vehicles and infrastructure systems are interconnected with each other, thus providing more precise knowledge of the traffic situation across the entire road network.

SECURITY, MANAGEMENT AND IOT DEVICE GROUPS

The Security Ecosystem’s using IoT Device Secure Groups, Secure Communication Lines together with their rules and business logic technology is useful for supporting controlled access to devices and/or data.

For example, sensors in a vehicle required for V2V activities could be grouped in a “Rear Sensor Group”. Outside devices allowed to communicate with this group would typically not have credentials to gain access into vehicle devices beyond the group of sensors and possibly a sensor management ECU. Using Security Ecosystem technology, outside sensors could have carefully defined and credentialized access to specific vehicle devices.

In a security ecosystem-managed PKI, Group, Secure Communication Line and rules/business logic/smart contract technology may be useful for controlling, managing or for other purposes, access to devices and/or data. PKI-Enforced Whitelisting could be introduced to such a group so that the sensors are instructed to communicate only to endpoints with which they have a pre-existing secure communication line and no to other endpoints. This will mitigate random queries (e.g., Shodan), spoofing attacks, scanning and/or other communication attempts from an endpoint, external server or other unknown entity.

Groups can be useful in allowing device access, for example for authenticated members of a “Maintenance Group” would be allowed device access for maintenance and/or replacement purposes.


ENCRYPTION, DIGITAL SIGNING, DIGITAL AUDIT TRAILS

The Security Ecosystem’s Attribute Authority (AA) acts as a Trusted Third Party mediating service provider for users/devices in running the Inviter-Invitee Protocol used to authenticate communication lines between paired endpoints by: (a) establishing and authenticating unique identities of IoT devices (or computing devices); (b) uniquely associating cryptographic keys to their identities and those of their invitees; (c) providing a trusted exchange of authenticated pubic keys of between the endpoints (d) uniquely associating a PKI certificate with each communication line. This infrastructure supports: endpoint encryption and decryption of data; endpoint digital signing capabilities; ability to track, monitor and audit the exchange of encrypted digital content (but not the content itself).


ENDPOINT IDENTITIES

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. For 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. Variable identity profiles may be modified automatically or manually. The system’s flexibility supports an emergency vehicle (such as a fire truck) when not operating under an emergency to broadcast an identity of a large vehicle or of a non-emergency fire truck. However, when that emergency vehicle changes its operation to a mode of responding to an emergency call, then its broadcast identity will become that of a responding emergency vehicle. Through reliance on the trust granted to PKI certificates, confirmation of an emergency vehicle’s claimed identity can be validated by (or provided to) the vehicles around it with the support of the TrustCentral’s PKI Attribute Authority (AA). Through the trusted Security Ecosystem technology behind the API, an autonomous vehicle (or the driver of a non-autonomous vehicle) will be able to determine that a specific emergency vehicle (or other vehicle) is trustworthy.


CROSS CERTIFICATION

It is predicted that Devices and Device Groups (e.g., vehicles) will be managed within a PKI of their OEM with a proprietary 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. Devices and Devices Groups managed under one OEM’s PKI may be authenticated for trusted communication with Devices and Device Groups that are managed by another PKI (e.g., that of another OEM, governmental entity, etc.) through the application of cross-certification.

The integration and cross-certification of separate infrastructure sources administered by independent government, states, cities, and possibly private businesses must be done with care. For example, to authenticate and certify: entities; PKI’s; AA’s; infrastructure components; devices; vehicle groups; etc. The security ecosystem technology will provide for trusted integration in order to provide security, trusted devices and groups, as well as and trusted data and transactions.

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.


TRUSTWORTHINESS, REPUTATION

Trust and reputation scores of devices and groups will be established and by the Attribute Authority integrated with each PKI as an extended component of cross-certification. TrustCentral’s proprietary technology of endpoint trust and reputation scoring will be highly useful for V2V and V2X scenarios. “Trusted records require trusted provenance [origin]” – Dr. David Kravitz


 

 

 


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 is excellent and well thought out. TrustCentral’s technology is expected to 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 are generally considered to be high. Shifting a significant portion of those determinations away from vehicle-level resources to AA’s in the cloud (which can provide summarized, trusted data to vehicles) can mitigate these demands.

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

In either event, an Attribute Authority (AA) should be able to predict a new vehicle’s location and will 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 another of its supported vehicles. 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. As the 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 significant V2V traffic and computation at the vehicle level that might otherwise be used because vehicle 2 and the police vehicle did not have 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.