Chapter 7
A vehicle that acts on a radio message from a stranger has to answer one question first: should this message be believed? The security architecture of WIA-COMM-003 exists to answer it. It does so without giving up the property that makes V2X useful, which is that unfamiliar vehicles can talk to each other with no prior relationship. The specification states six requirements. Five protect the message and the network, and the sixth protects the person in the car.
| Requirement | What it means in a V2X context |
|---|---|
| Authentication | The receiver can verify who sent a message |
| Integrity | Tampering with a message in transit is detected |
| Non-repudiation | A sender cannot later deny having sent a message |
| Confidentiality | Sensitive data can be encrypted; this is optional for safety messages |
| Availability | The system resists denial-of-service attacks |
| Privacy | User location and identity are protected |
Confidentiality is marked optional for safety traffic, and the reason is practical. A Basic Safety Message exists to be heard by every vehicle nearby, so encrypting it would defeat its purpose. Authenticity is what matters for such a broadcast. Receivers must be able to trust it, and they do not need to be shielded from reading it.
Trust is anchored in a public key infrastructure with two branches below a root authority. The split is deliberate. One branch identifies a vehicle for the long term, and the other lets the vehicle act on the road under identities that change.
Root CA (Certificate Authority)
├── Enrollment CA (Long-term certificates)
│ └── Vehicle Enrollment Certificates
└── Authorization CA (Short-term certificates)
└── Pseudonym Certificates (changed frequently)A vehicle's enrollment certificate says that it is a legitimate participant. The pseudonym certificates issued by the Authorization CA are what it actually attaches to broadcasts. Because the two branches are separate, a message on the air never has to carry the vehicle's long-term identity. This arrangement is what makes the privacy mechanisms in section 7.2 workable.
The certificate format follows IEEE 1609.2. The excerpt below keeps the fields that carry the most meaning for the road environment and omits the rest of the specification's example.
{
"version": 3,
"type": "explicit",
"issuer": "AuthorizationCA-001",
"toBeSigned": {
"id": "CERT-789012",
"cracaId": "ROOT-CA-001",
"crlSeries": 5,
"validityPeriod": { "start": "2025-12-26T00:00:00Z", "duration": "1 week" },
"region": {
"circularRegion": {
"center": {"lat": 37.7749, "lon": -122.4194},
"radius": 50000
}
},
"assuranceLevel": "high",
"appPermissions": [ { "psid": 0x20, "ssp": "all" } ],
"verifyKeyIndicator": {
"verificationKey": { "algorithm": "ecdsaNistp256", "publicKey": "04a1b2c3..." }
}
},
"signature": { "algorithm": "ecdsaNistp256", "r": "12345678...", "s": "87654321..." }
}Several fields do real work in operation:
ecdsaNistp256).Every signed message wraps the application payload (BSM, CAM, or DENM data) in a fixed envelope: header information with protocol version and message type, signer information as either a full certificate or a digest, a generation time, a three-dimensional generation location, and finally the ECDSA P-256 signature. Putting time and location inside the signed envelope means they cannot be altered without invalidating the signature. This makes it possible to check a message's claims against the world.
The reference verification routine runs six checks in sequence and rejects the message at the first failure:
def verify_v2x_message(signed_message):
cert = extract_certificate(signed_message)
if not verify_certificate(cert):
return False, "Invalid certificate"
if is_revoked(cert):
return False, "Certificate revoked"
if not ecdsa_verify(cert.public_key, signed_message.payload,
signed_message.signature):
return False, "Signature verification failed"
timestamp = signed_message.generation_time
if abs(current_time() - timestamp) > 5000: # 5 seconds
return False, "Message too old"
if not is_in_region(signed_message.generation_location, cert.region):
return False, "Location outside certificate region"
return True, "Message authenticated"Each step defends against a different attack. Certificate validity and revocation checks stop impostors and compromised units. The signature check stops tampering. The freshness check, with a five-second tolerance, stops replay, where an attacker records a legitimate "hard braking ahead" and rebroadcasts it later. The region check catches a valid certificate being used where it should not be. Note that the signature alone would pass a perfectly replayed message, which is why the time check is separate.
Authenticity creates a privacy problem. A vehicle that signs every position broadcast with the same certificate can be followed by anyone with a receiver. The specification answers with pseudonym certificates:
Rotation is only part of the defence, because the trajectory itself identifies people. A car that starts every morning from one driveway reveals its home through its first broadcast, whatever certificate it uses. The specification therefore adds privacy zones. No V2X broadcast is made within 500 m of a registered home, or the vehicle uses maximum privacy mode (encrypted). Sensitive locations such as hospitals, government buildings, and religious sites are detected automatically and protected in the same way.
Where a vehicle does broadcast, position precision can be reduced according to a privacy level:
| Privacy level | Behavior | Resulting precision |
|---|---|---|
| MAXIMUM | Position is not broadcast at all | None |
| HIGH | Coordinates rounded to 3 decimal places | About 100 m |
| MEDIUM | Coordinates rounded to 4 decimal places | About 10 m |
| LOW / NONE | Full precision | About 1 cm |
The tradeoff is built into the table. A collision-warning application needs lane-level position, so the ~100 m setting is useful for privacy but largely useless for safety. Reduced precision therefore suits situations where the vehicle is far from other traffic, or where the owner has deliberately chosen privacy over cooperative safety. The standard does not hide this conflict. It exposes the level as an explicit setting so that the choice is made consciously.
Cryptography proves who signed a message. It does not prove the message is true. A vehicle with a valid certificate and a faulty GNSS receiver, or an insider with stolen but unrevoked credentials, will produce authentic nonsense. The specification therefore includes a plausibility layer, a misbehavior detector that compares each incoming message against the sender's recent history and against physical limits.
The reference detector produces a list of anomalies, each with a type and a severity. Its four checks are:
| Anomaly type | Severity | Test in the reference logic |
|---|---|---|
| POSITION_JUMP | HIGH | Distance moved exceeds last speed × elapsed time × 1.5 (a 50% margin) |
| EXCESSIVE_SPEED | MEDIUM | Reported speed above 200 km/h |
| EXCESSIVE_ACCELERATION | MEDIUM | Longitudinal acceleration beyond 10 m/s² |
| MESSAGE_FLOODING | HIGH | More than 50 messages in the last 5 seconds |
max_distance = history.last_speed * time_delta * 1.5 # Allow 50% margin
actual_distance = calculate_distance(history.last_position, message.position)
if actual_distance > max_distance:
anomalies.append({
'type': 'POSITION_JUMP',
'severity': 'HIGH',
'description': f'Position jumped {actual_distance}m in {time_delta}s'
})The severity assignments reflect what each failure suggests. A position jump has few innocent explanations and also undermines every collision calculation built on that vehicle's track, so it is rated high. An implausible speed or acceleration may be a sensor glitch, so it is rated medium. Flooding is rated high because it is also the signature of a denial-of-service attempt, which ties back to the availability requirement in section 7.1. A channel saturated with bogus beacons blinds every honest receiver.
These checks interact with the privacy design. The position-jump test assumes continuity, but a pseudonym change makes a vehicle look briefly like a new station, and a vehicle reducing its position precision will show apparent jumps. A detector that is too strict will punish exactly the privacy behavior the standard requires. The 50% margin in the reference logic is a tolerance of this kind, and implementers should treat the thresholds as starting points to tune against field data. A flagged message is evidence to weigh, not proof of guilt.
A compliant system must contain five components: a V2X radio (DSRC 802.11p or C-V2X), a GNSS receiver (GPS, GLONASS, or Galileo), a message processor for BSM/CAM/DENM generation and parsing, a security module for certificate management and cryptography, and an application layer for collision detection, warnings, and the user interface. The recommended software architecture stacks these in five layers, from the application down to the hardware:
V2X Application Layer (Collision Avoidance, Platooning, UI)
V2X Middleware / SDK (Message Handling, Event Processing)
Security & Privacy Layer (Signing, Verification, Anonymization)
V2X Protocol Stack (IEEE 1609.x, ETSI ITS-G5, SAE J2735)
Hardware Abstraction Layer (Radio Control, GNSS, CAN Bus)The security and privacy layer sits between the applications and the protocol stack, so that no application can put an unsigned or unfiltered message on the air. The hardware abstraction layer hides the radio, GNSS, and CAN bus behind a common interface, which lets the same application code run over either DSRC or C-V2X.
The BSM generator, which runs at 10 Hz, shows how vehicle state becomes wire values. Everything is converted to integer units:
this.msgCount = (this.msgCount + 1) % 128;
...
latitude: Math.round(vehicleState.position.lat * 1e7),
speed: Math.round(vehicleState.speed / 0.02), // 0.02 m/s units
heading: Math.round(vehicleState.heading / 0.0125) // 0.0125° unitsOne caution applies to the timestamp. The reference sketch computes it as Date.now() % 65536 and describes it as milliseconds within a minute. A minute is 60,000 ms, so a production encoder should follow the field definition in SAE J2735 rather than copy the sketch.
The second optimization concern is receive-side load. In dense traffic a vehicle hears far more messages than any application needs. The reference MessageFilter discards a message when the sender is beyond a maximum distance (default 500 m). It also discards the message when the bearing differs from the ego heading by more than 90° and the sender is farther than 50 m, so vehicles behind and to the side are dropped unless they are close. The close-range exception matters for blind-spot and lane-change warnings. The order of operations should also be kept in mind. Cheap geometric filtering reduces work, but a message must still pass authentication before it is trusted by any application, and a filter must never be the only thing standing between an attacker and the safety logic.
Validation is organized around four scenario families:
| Family | Examples from the test plan |
|---|---|
| Basic communication | Transmission and reception, latency measurement, packet delivery ratio |
| Collision avoidance | Forward collision warning, blind spot detection, intersection collision |
| Platooning | Formation and maintenance, lane change maneuvers, emergency dissolution |
| Security | Message authentication, certificate validation, misbehavior detection |
Field testing requires at least 5 vehicles, 100+ hours, and 50+ distinct scenarios. The environments must include urban, highway, and rural roads, in clear weather, rain, and fog, at light, medium, and heavy traffic densities. The breadth is intentional. Radio propagation and packet delivery change sharply between a canyon of buildings and an open highway, and a system tuned only in clear, light-traffic conditions says little about its behavior in the cases that matter most.
The specification anchors all of this in base standards. IEEE 1609.x (resource manager, security services, networking services, and multi-channel operation) and IEEE 802.11p cover the radio and security stack. SAE J2735 defines the message set and SAE J2945 and J2945/1 define on-board system requirements. ETSI EN 302 637 covers CAM and DENM, with ETSI TS 102 894-2 for the basic application set. ISO 21217 describes station architecture, and 3GPP TS 22.185 and TS 23.285 cover service requirements and architecture for cellular V2X. Related WIA standards for intent-based control, API gateways, social coordination, quantum-secure communication, and edge computing are listed for adjacent concerns.
This chapter followed a V2X message from creation to acceptance, and the same path shows where each safeguard sits:
The common thread is that no single mechanism carries the trust burden. A message is accepted because it is signed by a permitted, current, unrevoked certificate, is fresh, comes from where the certificate allows, and behaves like a real vehicle. Each condition covers a gap the others leave open.
The work so far has concentrated on a single station: what it signs, what it accepts, and how it is built and tested. The next chapter moves from that station-level view to the wider operating context around it. A secure, well-filtered vehicle still depends on infrastructure operators to run the certificate authorities, and on the interoperability testing that shows independently built stations can accept each other's messages. That context is where the standard's base specifications and the field-test evidence meet in practice.