Connected mobility solutions are evolving at a rapid pace. Key areas within this space are safety and intelligent technologies, which are enabled by V2X communication – when vehicles and infrastructure communicate with one another. Sharing sensor data occurring in V2X communication allows for smarter decisions to be made, helping to predict and avoid unsafe situations.
However, while V2X provides connected vehicles with a vast amount of information for making decisions, whether automated or not, the effectiveness of the system relies on accurate and trustworthy information. Traditionally, this trust is achieved by binding information to a verifiable identity. But using this approach in V2X messaging allows each message to be tied to a specific user, creating an easy way to track and monitor participants in the network.
To avoid this and provide individual privacy, a public key infrastructure (PKI) has been proposed – the Security Credential Management System (SCMS). The system issues credentials that allow communicating devices to trust only authorized sources. Unfortunately, while SCMS is used in many pilot demonstrations and is poised to support future national deployments, a critical aspect of the system remains relatively undeveloped – misbehavior detection. Misbehavior occurs when invalid messages (e.g., location, speed, pretending to be multiple vehicles to manipulate a traffic light, incorrect information about another honest device) are sent to cause havoc or gain an advantage on the road. If a vehicle misbehaves by transmitting incorrect data, whether intentionally or due to misconfiguration or malfunction, then it must be actively removed from the network until the cause of the misbehavior is identified and addressed.
A Look at Misbehavior Detection
The SCMS is designed to facilitate message authentication and authorization without revealing the user’s identity or allowing a single user’s activity to be tracked. It is built on two fundamental assumptions:
- Devices will continue to function even if they can’t communicate with the SCMS for an extended period of time (up to 3 years).
- No component should be able to compromise individual privacy in any way.
Now, let’s take a look at these from a misbehavior management perspective:
- If a misbehaving device is not actively revoked from the system, it can continue to misbehave for up to 3 years.
- No component has enough information to add a device to a revocation list on its own.
Note the first assumption can be contradictory as it assumes vehicles are offline for long periods of time, but misbehavior detection, reporting and response require vehicles be online to forward reports and receive updates. Misbehavior detection and response consists of a sequence of steps: Detection; Reporting; Analysis; and Decision.
Detection at the device level (vehicles or infrastructure)
Unfortunately, there is not a complete list of behaviors to monitor or report as misbehavior. However, there are some clues that can be a first step in detecting a potential offending device:
- Using expired or incorrect credentials (e.g., bad permission, geo-fence)
- Sending messages with incorrect signatures, invalid or valid fake location or data (e.g., time)
- Sending messages with bogus and unauthorized information (e.g., to get unauthorized pre-emption)
These are situations in which a device is consistently using or sending information that does not pass standard validation or is not in-line with the sensor readings of the receiver. Because these situations can be detected and reported by a single observer, they are not difficult to implement. Similarly, reports from multiple observers can be combined to provide assurance that the reports are accurate. This combination of data from multiple sources is essential, as end entities (e.g., vehicles, pedestrians, cycles, motorcycles and infrastructure units) have multiple, concurrently valid pseudonyms – to protect the user’s privacy – they could use to falsely sign misbehavior reports.
Reporting to a central entity
Once sufficient evidence of misbehavior has been collected by a device (e.g., vehicle or infrastructure unit), it is formatted into a misbehavior report (MBR) and forwarded to the SCMS’s Misbehavior Authority (MA) via the Registration Authority (RA) for analysis. According to the Crash Avoidance Metrics Partnership (CAMP) protocols supporting vehicle pilot test sites in the U.S., misbehavior reports include:
- Version number
- Timestamp
- Current policy file used by the device
- Core misbehavior data – type of misbehavior and supporting evidence
Detection and reporting can be considered as local misbehavior (i.e. at the device level) activities.
Analysis and correlation of reports
Currently there is no standard way or process for the MA to determine whether a set of reports constitutes misbehavior – this is an active area of research. However, the MA has a few tools at its disposal. It can correlate reports from multiple senders in similar geographic regions to determine if reports are likely to belong to the same vehicle. It also can search for distinctive features in reported messages to potentially correlate them. It is simply looking for anomalies to trace back to the common source.
Decision making
Once the MA has compiled misbehavior reports into groups likely to belong to the same vehicle, it can reach out to the Authorization Certificate Authority (ACA) and Linkage Authority (LA) within the SCMS to determine if a set of values belong to the same vehicle. With this information, the MA can refine its queries in response, or decide if the reported messages constitute misbehavior.
If the MA determines a misbehavior has occurred, the blacklisting and revocation processes are implemented. Blacklisting is the invalidation of a device’s enrollment certificate, the credential used to authenticate with the RA when requesting and downloading pseudonyms. Using the linkage information from the LA, the MA provides the RA with the necessary information to determine which enrollment certificate was associated with the request for the misbehaving pseudonyms and instructs the RA to blacklist the certificate. Once blacklisted, the RA will no longer offer services to the blacklisted device, preventing the download of any previously requested pseudonyms, or requests for new pseudonyms. In short, the blacklisted vehicle is effectively unable to communicate with SCMS components
Blacklisting cannot prevent a vehicle from using pseudonyms it has already downloaded. To inform other network participants that a set of pseudonyms have been revoked, the Certificate Revocation List (CRL) must be updated with the linkage information associated with the revoked vehicle.
New applications and use cases will emerge for which current misbehavior definitions may not apply. A well-designed system should facilitate the safe deployment and integration of new technologies, not constrain it. Things will go wrong, new threats will be identified and new attacks will emerge. The V2X ecosystem must be designed and deployed with this in mind. This is especially true as sensors are used for multiple applications.
Furthermore, many V2X applications go beyond the simple sharing of data and will allow road users to proactively request changes in behavior from other road users and infrastructure (e.g., emergency vehicle signal pre-emption). This makes the understanding and implementation of misbehavior detection solutions even more important because it establishes trust in the system over time, which ensures all benefits, safety and others, remain for all stakeholders.
by Omar Alshabibi, Lead Product Manager – V2X Cybersecurity ESCRYPT
infobox Misbehavior Authority (MA): Collects and analyzes misbehavior reports from multiple sources to determine if there is reason to do more privacy-sensitive analysis of the information. Registration Authority (RA): Receives certificate requests from the end entity and, after expanding individual requests into thousands of requests to prevent identification, forwards to the Authorization Certificate Authority. Linkage Authorities (LA): Generates and sends encrypted linkage values for the pseudonym certificate to the Authorization Certificate Authority. Authorization Certificate Authority (ACA): Collects information for certificates, then signs and encrypts them, without being able to trace to a particular end entity. Certificate Revocation List (CRL): The list of digital certificates that have been revoked by a certificate authority.
