Beyond the capabilities described in the “Vehicle Life-Cycle Management” page on this site, TrustCentral’s technology offers additional tools and capabilities that may be applicable for V2X, V2V and autonomous vehicles:
PRIVACY, IDENTITY EXPOSURE, PRIVILEGES AND SHARING
- When vehicles exchange communication with other vehicles or with infrastructure, the grouping capabilities of the Security Ecosystem may be advantageously used. For example, the Attribute Authority of a trusted OEM1 could issue attribute certificates to each authenticated vehicle that it supports. Using certificates, OEM1 could associate portions of its vehicles into one or more groups. An OEM2 could also create groups of vehicles, as could various governmental entities do with infrastructure.
- The System includes a capability to support multiple identities for endpoints and/or groups that can be useful for V2V
- Example of a vehicle identity: (a) an identity exposure can be minimal (e.g., generic make and model of vehicle); or (b) under defined conditions, an identity exposure may be extended to provide more detailed information such as licensing info, VIN, registration info, insurance info, etc.
- An authenticated police officer could be provided more detailed vehicle info than more typical queries might be entitled to
- Flexible identities could be supported for emergency vehicles: when not operating under emergency, a vehicle maintains a non-emergency identity; when responding in an emergency, its identity becomes that of a responding emergency vehicle
- USE CASE EXAMPLE: vehicle A of OEM1 may be able to distinguish that it is receiving a command or query from vehicle B of OEM2 that it should ignore as opposed to a command from an infrastructure component of City-X. Vehicle A will be able to ascertain the legitimacy of the command or query as coming from an authorized traffic light that is also an authenticated member of an infrastructure group with traffic control privileges of City-X as opposed to coming from a street light component (or bad actor) that lacks privileges to direct traffic. This process provides appropriate authorization and/or confidential isolation that otherwise may be difficult to expeditiously be achieved within a cacophony of less precisely authenticated and/or privileged vehicles and/or infrastructure.
- The system supports a robust system of scoring endpoint trustworthiness, reputation and other metrics (e.g., of vehicles, AV’s, infrastructure, groups, etc.)
- The system supports an ability to deliver trusted device records providing trusted origin (with auditability) to a blockchain or other database
- Confirmation of a vehicle’s claimed identity (e.g. emergency vehicle) through 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; digital audit trails; etc.
It is assumed that vehicles will be managed under its OEM’s PKI with an integrated Attribute Authority (AA). Such arrangements will result in multiple, siloed OEM PKI’s. This will likely also be the case with the infrastructure of multiple governmental entities. 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 achieve trust for an authenticated police vehicle 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 requirement 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 integrated with secure communication lines, the authorization of devices including control of their privileges through the use attribute certificates, the determination of trustworthiness and reputation of vehicles, infrastructure, 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 may 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 could be considerable (the system’s use of trusted attribute certificates will, by itself, reduce computational requirements). 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) may 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. Such from a cross certification could then be pushed to a vehicle (this could save additional bandwidth when GPS and vehicle movement information is also included in the cross certified information.
In either event, as a non-managed vehicle presents itself, an Attribute Authority (AA) should be able to intelligently determine that vehicle’s location and be able to authenticate its identity certificate and/or group attribute certificate. Subsequently when that non-managed vehicle needs to establish V2V communication with any of the AA’s managed vehicles, 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 comparable 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, having far greater computing resources, will have a far greater 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, thus again reducing the need for larger network capacity for AV’s.
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, authorization provileges, 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 required 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 queries 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.