V2X security — the part that cannot be retrofitted.
A V2X message says something like collision imminent, or emergency vehicle approaching, or this signal turns red in 1.8 seconds. Unsigned, every one of those is forgeable by anyone with a software-defined radio. Signed but with an extractable key, every one of them is forgeable by anyone with a soldering iron and a stolen vehicle — and the PKI cannot help, because the forgeries are validly signed.
Everything on this page follows from two constraints that web PKI does not have. The receiver has to decide offline, with no network to consult. And it has to decide in milliseconds, thousands of times a second, while driving.
From the certificate format to the authority that revokes it.
V2X PKI
Enrolment Authority, Authorisation Authority, the certificate flow, IEEE 1609.2 structure.
Pseudonymity and privacy
Pseudonymous certificates, butterfly key expansion, linkage values, rotation cadence.
Hardware root of trust
Why software keys fail, secure elements, verification throughput, AmbiSEC.
Threats and attacks
GNSS spoofing, Sybil, ghost vehicles, RSU compromise — with documented demonstrations.
Misbehaviour detection
ETSI TS 103 759, detector classes, the Misbehaviour Authority, revocation.
SCMS vs CCMS
The US, EU, Chinese and proposed Indian trust models, side by side.
V2X endpoints are not in air-conditioned data centres.
Vehicles get stolen, crashed, parked in salvage yards and sold on; roadside units are bolted to poles where contractors and passersby have physical access. A key in flash is also in RAM during signing, on the JTAG or SWD debug interface, and in the boot ROM — extract it once and you can manufacture a clone that transmits validly signed forged messages indefinitely.
A deployment that permits extractable signing keys is a hazard-amplification system, one stolen vehicle away from producing an unlimited supply of trusted liars. Why software key storage does not survive this →
Where Ambimat sits in this picture, and where it does not.
Ambimat supplies the device-side layer: the secure element, the JavaCard credential-lifecycle applet, and the HSM-backed provisioning line that puts an identity into it. Ambimat is not a V2X Root CA operator and does not run Enrolment or Authorisation Authorities — those are trust-anchor functions for designated authorities and their appointed operators.
The security business unit's own treatment of secure elements, attestation and PKI primitives sits on a sister property: AmbiSecure V2X security architecture and device identity at scale. This site covers the wider V2X picture — technology, regulation, deployment and hardware — and links across rather than duplicating.
Adjacent material.
India regulation
The PKI framework question India still has to answer, and why it is the least recoverable decision.
Chipsets and hardware
The dedicated V2X security parts, with their published certifications.
AmbiSEC
The secure element module and its JavaCard V2X applet.
AmbiSecure V2X security architecture
The security business unit's end-to-end treatment of OBU/RSU PKI and provisioning.
Device identity at scale
V2X EA/AA in the same architectural frame as eSIM SM-DP+ and FIDO attestation.
PKI test environments
Where a development team can actually enrol a device and get a real certificate.