Vehicle-to-Everything security — proving a message came from an authorised participant.
A receiving vehicle has to establish two things before acting on a safety message: that it came from an authorised participant, and that it arrived unaltered. That applies in Vehicle-to-Vehicle communication, between two vehicles, and equally in Vehicle-to-Infrastructure communication, between a vehicle and roadside equipment. Ambimat helps product teams design that trust into the On-Board Unit or Roadside Unit rather than bolting it on afterwards.
This is the security specialism within our V2X development services — the part customers most often arrive with. Choosing the secure element, structuring the applet, provisioning identity on a manufacturing line, handling enrolment and authorisation credentials on the unit, and keeping all of it updatable for the service life of the fleet.
The claim worth being precise about: the architecture lets a receiver authenticate authorised participants and reject messages that fail the trust and integrity checks. It does not make it impossible for anyone to transmit. That distinction is the whole design problem.
A working radio stack is not a secure on-board unit.
Most V2X programmes reach first light on the radio before they reach it on trust. The modem associates, the stack emits a well-formed BSM or CAM at 10 Hz, the integration test passes — and none of that says anything about where the signing key lives, who can extract it, how the device obtained an enrolment credential, what happens when the authorisation certificate batch runs out on a Sunday, or how the fleet gets a new certificate policy without a recall.
Those are hardware and lifecycle questions before they are cryptography questions. IEEE 1609.2 and ETSI TS 103 097 assume a tamper-resistant boundary architecturally; neither tells you which part to buy, how to structure the applet, how to run the provisioning line, or how to size verification throughput for the load your deployment will actually see. That gap is what this engagement covers.
We work on the device side of the trust chain. Not the authority side.
Stating this plainly is more useful to you than a broader claim would be.
In scope
Secure-element selection and integration. Key generation and custody inside the tamper boundary. JavaCard applet structure for V2X credentials. Enrolment and authorisation certificate handling on the device. Pseudonym batch storage and rotation policy in the applet. Device-bound identity anchored in the secure element. Secure boot. Signed firmware update. Verification-throughput sizing. Manufacturing test.
Not in scope
We do not operate a Root CA, an Enrolment Authority or an Authorisation Authority, and we are not a national trust-model operator. We do not supply a certified production V2X protocol stack — where a programme needs a conformance-certified facilities and networking implementation, that comes from your stack vendor. The open ROS 2 development environment we do provide is described on the AmbiV2X Developer Stack page. We are not an accredited test laboratory. Type approval and certification remain with ARAI or the appropriate authorised body.
The second column is the point. A supplier who claims the whole trust chain is either describing a national programme they do not run, or has not thought about who is liable when a pseudonym certificate is misused. Our engineering view on how an Indian V2X PKI should be governed — and who should run the authority tier — is set out on the V2X PKI reference, and Ambimat is not proposed as that operator anywhere in it.
Choosing the part is a throughput and lifecycle decision, not a datasheet comparison.
Three questions decide the part, and only the first is usually asked:
- What assurance level does the deployment require? EVITA Full is the V2X profile, because V2X needs an asymmetric engine and a hardware ECC accelerator rather than symmetric crypto alone. The CAR 2 CAR Communication Consortium formalises the target as the Protection Profile “V2X Hardware Security Module”, version 1.4.1. Dedicated V2X security parts on the market sit at EAL4+ per their vendors' published certificates; AmbiSEC is built to EAL6+ secure-element requirements, stated as Common Criteria EAL6+ compliant rather than certified.
- What verification rate must it sustain, and under what adversarial load? This is the single most routinely missed sizing question in on-board unit design. Signing is cheap and bounded — roughly 10 Hz. Verification is not: it scales with the number of neighbours in range, and an attacker can raise it deliberately. Ask any V2X hardware proposal what its verification throughput is under a 5,500-message-per-second offered load, and what the device does when that load is hostile. The throughput problem, in full →
- Is the security logic upgradable without touching application firmware? A fixed-function secure element freezes the certificate policy at tape-out. A JavaCard part lets a policy change deploy as an applet upgrade, independently of application firmware. In a fleet whose national certificate policy will change during its service life, that is the difference between an update and a recall.
Where the answer is a third-party part, we integrate it. Where the answer is ours, it is AmbiSEC — a 25 × 25 mm solder-down module with ECDSA P-256 and P-384, Ed25519, on-chip key generation, and an automotive operating range available from −40 °C to +105 °C. We are not neutral about that, and we would rather you knew it than discovered it.
Enrolment, authorisation and rotation, as the device experiences them.
The V2X credential architecture is well specified. Implementing it on a device that may be offline for a week, and that must verify a stranger's signature with no server reachable at all, is where the engineering sits.
| Stage | What the device has to do |
|---|---|
| Key generation | Generate the long-term key pair on-chip, inside the tamper boundary. The private key must never exist outside it — not in a build system, not in a test jig, not in a log |
| Identity binding | Anchor that key to a device-bound identity held inside the secure element and non-extractable by hardware design |
| Enrolment | Obtain and store an enrolment credential from the Enrolment Authority, and protect it as a long-lived secret |
| Authorisation | Request, receive and store batches of pseudonymous authorisation certificates, with a storage budget that survives the batch size the national policy actually sets |
| Rotation | Rotate pseudonyms on the schedule the policy requires, without leaking a linkable identifier across the change. Why rotation alone is not unlinkability → |
| Verification | Verify inbound signatures at line rate, with a rejection path that stays bounded when the load is adversarial |
| Policy change | Accept a new certificate policy as an applet upgrade rather than a firmware reflash or a recall |
Because the national trust models differ in exactly these details — batch sizes, rotation rules and above all revocation — the applet has to be structured for the model the deployment will run under. SCMS, CCMS and the two Asian models compared →
The factory is part of the threat model.
A device is only as trustworthy as the line that personalised it. If keys are injected from a workstation, the workstation is now the root of trust for the whole fleet, and nobody audits it.
The architecture we start from gives the part a device-bound identity: a unique 128-bit identity key held inside the secure element and non-extractable by hardware design, so identity-related cryptographic operations are anchored to that individual endpoint rather than to ordinary application storage. The provisioning-line architecture →
What we design with you is the shape of that line for your programme — key ceremony, custody boundaries, per-unit records, what the contract manufacturer can and cannot see, and how a unit that fails personalisation is disposed of rather than shipped.
A credential lifetime is measured in years. So the update path is part of the security architecture.
Secure boot and signed update are not separate from the V2X credential problem; they are what keeps it true after year one. AmbiOTA is the architecture we use for that path, and its first stage is the one that matters: the firmware signing key is held inside an AmbiSEC secure element, so no private key touches a build system or a developer workstation. A signed pipeline whose key sits on a CI server has moved the attack, not removed it.
On the device, the update signature is verified by the secure element, with automatic rollback on a failed update, and every event logged with device identity, timestamp and firmware hash. Delta packaging keeps the transfer within the bandwidth a constrained fleet actually has.
Two points specific to V2X. First, the update path and the certificate-delivery path share the same cellular link, so a vehicle whose network side has failed eventually cannot sign messages either. Second, secure update is not optional in the regimes this hardware will ship under — UNECE R156 requires a certified Software Update Management System for vehicles, TEC 31318 applies on the IoT side, and AIS-230 addresses it for Indian V2X on-board units. The Indian regulatory position, including what is still draft →
Three ways in, depending on where your programme is.
| Engagement | What it is |
|---|---|
| Technical deep-dive | Hardware architecture and block diagrams for the security path, presented to your technical team, within 30 days |
| Secure-element integration | Secure-element selection, applet structure, provisioning-line architecture and enrolment/authorisation integration patterns. Reference designs and evaluation hardware shared under NDA |
| Proof of concept | A working unit for demonstration and testing, within 90 to 180 days |
What is genuinely useful at the first conversation is the binding constraint rather than the requirement list: the verification rate you have to hit, the certificate policy you have to interoperate with, the bill-of-materials ceiling, the fitment deadline, or the contract manufacturer you are already committed to. All four ways to engage →
The reference material this service is built on.
Hardware root of trust
The threat model, the EVITA taxonomy, the C2C-CC Protection Profile and the verification-throughput problem.
V2X PKI
Enrolment, authorisation, pseudonym batches and the governance question India has not yet answered.
SCMS vs CCMS
Four national trust models, and what each of them does about revocation.
Pseudonymity and privacy
Why certificate rotation on its own does not deliver unlinkability.
AmbiSEC
The secure element: the dual-domain architecture it sits in, the JavaCard V2X applet and the provisioning model. Shipping.
AmbiOTA
The secure over-the-air update architecture: signing key held in hardware, verified on-device. Technology reference.
Send us the binding constraint.
The verification rate, the certificate policy, the provisioning architecture, the trust boundary, the update path or the fitment date — whichever one is actually deciding your design. Email goes to an engineer, not a form.
Questions this page answers.
What does V2X secure element integration actually involve?
Selecting a part that meets the assurance profile and the verification throughput the deployment needs; structuring the applet that holds enrolment and authorisation credentials; designing the provisioning line that binds identity at manufacture; and wiring secure boot and signed update so the arrangement survives a policy change years later. The radio stack is a separate problem: a certified production implementation comes from a stack vendor, while the application and development environment around it is the AmbiV2X Developer Stack.
Why does a V2X device need a secure element rather than software key storage?
Because the attacker can hold the device. A signing key in flash exists in several places at once — the flash itself, the build artefact, the update package, backups and any debug interface left enabled. IEEE 1609.2 and ETSI TS 103 097 assume a tamper-resistant boundary architecturally, and the CAR 2 CAR Communication Consortium formalises the target as the Protection Profile “V2X Hardware Security Module”, version 1.4.1.
What verification throughput does a V2X on-board unit need?
It depends on neighbour density, and it is the sizing question most often missed. Signing is bounded at roughly 10 Hz; verification scales with how many equipped vehicles are in range, and an attacker can raise that deliberately. The useful test of any proposal is what it sustains under a 5,500-message-per-second offered load, and what it does when that load is hostile. The throughput problem.
Does Ambimat run the Enrolment or Authorisation Authority?
No. That is the authority side of the trust chain and Ambimat does not operate it. This service covers what the device does: generating and holding keys inside the tamper boundary, obtaining and storing an enrolment credential, requesting and storing pseudonymous authorisation certificate batches, rotating them to policy, and verifying inbound signatures at rate.
Can the certificate policy change after the fleet has shipped?
It will. National certificate policies change during a fleet's service life, which is why the applet architecture matters: on a JavaCard secure element a policy change deploys as an applet upgrade, independently of application firmware. On a fixed-function part the policy is frozen at tape-out, and the alternative to an update is a recall.
Which secure element does Ambimat use?
Where a third-party part is the right answer for the programme, Ambimat integrates it. Where its own part fits, that is AmbiSEC — a 25 × 25 mm solder-down module with ECDSA P-256 and P-384, Ed25519 and on-chip key generation, built to Common Criteria EAL6+ secure-element requirements and stated as EAL6+ compliant rather than certified.
Last updated 2026-09-07 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: neel.shah@ambimat.com