Figure 2: Using trust factors to improve V2V message factors
Accidental or malicious issue of false messages to connected vehicles could result in dire consequences, so secure systems of authentication and certification are likely to be necessary, write Paul Avery and Sandra Dykes.
Connectivity among vehicles in urban traffic systems will provide opportunity for beneficial impacts such as congestion reduction and greater safety. However, it also creates security risks with the potential for targeted disruption. Security algorithms, protocols and procedures must take into account the unique aspects of vehicle and highway systems. Security for a connected vehicle (CV) environment must go beyond message authentication to consider the broader issue of message trust. This is particularly important if the message could trigger a safety-critical response, potentially creating a risk to drivers and passengers.Security threat scenarios
There are numerous scenarios in which false information inserted into a connected vehicle system may cause widespread disruption. The level of disruption is determined by several factors: the degree of connectivity in the system; traffic density; and individual vehicle response. The last of these depends in part on the type of control, ranging from fully human-controlled to computer-controlled (automated). Consider these two examples where false messages are inserted into a connected vehicle system:A driver in heavy traffic is suddenly barraged with urgent but false warnings from the vehicle’s active safety system and the vehicle begins to take evasive action using automatic braking and steering features. Other vehicles react accordingly and the traffic comes to a standstill.
Or, highway drivers at a given location receive an incorrect message that an accident has occurred ahead and closed the highway. An alternate route is proposed, which takes them off the highway onto arterial roadways. Congestion develops on these roads and eventually backs up onto the exit ramp, causing additional congestion on the highway.
These scenarios are plausible, but the point is that systemic disruption is possible if CV messages are falsely generated and then trusted as accurate.
PKI approach to security
TheThe most difficult problem with the PKI approach is the distribution, management and revocation of certificates. In theory, a certificate will be revoked if it is used to “spoof” another’s identity or to send incorrect data caused either by equipment malfunction or a deliberate act. Periodically the CA will issue a certificate revocation list (CRL) that enables vehicles to detect when a message comes from a malfunctioning or uncertified source. Even with this brief description, it is clear that there are substantial technical problems in designing a PKI system for 250 million privately owned and operated vehicles with no central registration, licensing, or administrative authority. Further complicating the system, vehicles may be registered in one locale while connecting to Intelligent Transportation Systems infrastructure in a different region, state, or country. Yet more complexity is added by privacy concerns that require message anonymity to deter tracking and monitoring.
With these issues in mind, let us consider the proposed PKI and certificate management system. This could take the form of any of five different types:
- On-Board Equipment (OBE) – Dedicated Short Range Communication radio or other vehicle component that stores the certificates and signs the messages.
- Certificate Authority (CA) – generates certificates and CRLs.• Registration Authority (RA) – validates OBE requests for keys and certificates, obtains them from the CA, and distributes them to the OBEs.
- Linkage Authority (LA) – maintains a linkage between groups of certificates issued to a single OBE.
- Misbehavior Detection & Management – collects and analyses misbehaviour reports to detect OBEs whose certificates should be revoked.
To prevent tracking, vehicles change certificates (and identifiers) every five minutes. It is clearly not feasible to issue certificates at this rate, so the RA instead sends the OBE a full year’s worth of five-minute certificates.
This amounts to over 100,000 certificates per year for each vehicle.
Certificates are encrypted by month, so the OBE must request a new key from the RA each month to unlock the next group of certificates.
The OBE is also issued a long-term certificate but its use is limited to fail-safe conditions when short-term certificates are unavailable.
Multiple methods have been proposed for detecting defective or rogue source of data, ranging from on-board hardware checks to global sampling of reports from multiple vehicles.
For example, the OBE can compare ECU component identification to detect when it is installed in a different vehicle. At a local level, the OBE can assess the consistency of its own sensor data with incoming messages to check for plausibility. At a global level, infrastructure can randomly collect messages from vehicles to determine if multiple messages contain certificates issued to the same OBE. Misuse detection is critical to the success of connected vehicles and although there are numerous ideas, work in this area is just beginning.
Problems in managing certificates
An important practical question is how the vehicle OBE will initially register with the RA. It has been suggested that this should occur when the vehicle arrives at the dealership. However, this puts the dealer in the position of safeguarding access to certificates, as its computer system could be vulnerable to external hackers and malicious insiders attempting to steal certificates.The end of a vehicle’s life raises another practical concern. When a vehicle is junked, the OBE could easily be recovered. Once an attacker has physical possession, there are methods for extracting the OBE’s memory and recovering its certificates. With these recovered credentials, the attacker could obtain new certification and keys from the CA. Assuming that vehicle certificates could be stolen from the junkyard, the dealership computer, or the supply chain, it is conceivable that a black market would spring up, similar to the internet spammer black market for renting botnets. CRLs are insufficient to protect against this scenario; there must also be a method for tracking vehicles’ end-of-life and destroying the OBE memory.
A third practical concern is the trustworthiness of sensor input to the OBE, as data sent over an internal vehicle bus such as CAN or FlexRay is rarely authenticated. Doing so would be impractical due to size, power and cost constraints. The security approach must consider such issues throughout the vehicle supply chain.
Improving confidence in V2V
The proposed PKI approach is a good starting point for connected vehicle security; however, there remain gaps to complete trust in V2V messages because there are multiple scenarios in which legitimate messages could lack authentication or be signed by an expired certificate. This problem is of less concern for messages from roadside equipment, where tight control over equipment and certificates is possible.For V2V messages, it is useful to differentiate between authentication and trust. A signed message carries a high level of trust, however other indicators can be used to raise or lower this trust level. A trust level can be established over time, not for a single message, but for an event, by adding contextual information. For example, messages relating to an event will be more highly trusted if they are received from several sources. On-board sensors can also be used to check the consistency of a message. If a vehicle receives a warning message regarding icy road conditions, but the external temperature sensor reads 74°F, the message can be very likely be considered untrustworthy.
Messages from roadside equipment, or other “trusted sources,” such as police, fire, and emergency vehicles could be assigned special certificates with a higher degree of trust. The age of a certificate and the reputation of the agency that issued it may also be used to rate trustworthiness as some states may exert tighter security controls than others.
Figure 2 illustrates a high-level architecture in which the vehicle uses this multi-factor approach for determining the trust value of a message. CV security, from the individual vehicle to entire traffic systems, will benefit from using message authentication, reputation, context clues, and on-board sensors to determine the reality of a situation, prior to taking action.
Building strong security into the connected vehicle system will come at a cost, but not doing so could incur much greater cost. There is an overlap in methods for assessing trust and in methods for identifying bad or rogue sources of information. Connected vehicle communication requires both. Investment in research to develop and tune these methods offers a viable and efficient path to strengthening the proposed certificate-based security system.
Paul Avery is group leader of research and development within the Cooperative Systems Group at the
