AmbiSEC — the security development setup, and the boundary the keys never cross.
AmbiSEC is a 25 mm × 25 mm solder-down module built on an NXP Secure Element. It communicates with a host device and manages the security of that device's communication. The host keeps its radio stack, its application logic and its operating system. AmbiSEC owns key generation, key custody, signing, verification and credential lifecycle inside a tamper-resistant boundary.
AmbiSEC is the security development setup in Ambimat's V2X programme — the third alongside the On-Board Unit and Roadside Unit development kits. It exists because a V2X development environment has to address identity, credentials and message trust, not only radio connectivity: a receiving node needs a way to establish that a message came from an authorised participant and was not altered on the way. Why that has to be hardware → · How the credentials work → · The integration service →
It is in production. AmbiSecure has been shipping identity systems since 2017, into city-scale IoT and infrastructure programmes outside India.
What is in the module.
| Layer | Specification |
|---|---|
| Silicon | An NXP Secure Element — the security domain of a dual-domain architecture, across a trust boundary from the host's application domain. The specific part is not published. Whose assurance is whose → |
| Form factor | 25 × 25 mm solder-down PCB module |
| Asymmetric cryptography | ECDSA P-256 / P-384 signing and verification; Ed25519; on-chip key generation |
| Symmetric and hashing | AES; HMAC; SHA-family; monotonic anti-replay counters |
| Key custody | Private keys never leave the tamper boundary — the host receives signatures only |
| Applets | JavaCard V2X applet: enrolment credential storage, pseudonymous certificate batch lifecycle, policy enforcement |
| 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 the individual endpoint rather than to ordinary application storage |
| Lifecycle | Secure boot, OTA verification, and applet upgrade independently of full firmware |
| Environment | Automotive temperature grades are available for the underlying secure element, to −40 °C to +105 °C. That is the component supplier's figure for the silicon, not a rating of AmbiSEC as built, and it is not an operating range for AmbiOBU or AmbiRSU, which publish none |
The same secure-element family is offered on the security business unit's own property as the AmbiSecure product page, framed for IoT rather than V2X.
Two domains, and long-term secrets never cross between them.
Host MCU domain — application firmware, sensor acquisition, edge logic, and the communications subsystem the product design selects. Which radio technology a product uses is a system-design decision; AmbiSEC is not the radio and does not implement one.
Cryptographic security domain (AmbiSEC) — key storage and credential isolation; sign, verify, encrypt and decrypt; anti-replay counters and monotonic state; secure firmware-update authorisation. Long-term secrets are never exposed to application firmware.
Three properties a fixed-function secure element cannot give you.
The custom JavaCard applet stack was engineered by the AmbiSecure team over a decade. JavaCard applet development →
- Isolation — security logic fully separated from application firmware.
- Controlled upgrades — applets updated independently of full firmware, so a certificate-policy change deploys as an applet upgrade. No device recall. In a V2X deployment where the national certificate policy will change during the fleet's service life, this is not a convenience; it is the difference between a policy update and a recall of every vehicle sold.
- Structured domains — multiple security applications coexisting in isolated partitions: a V2X identity applet alongside FIDO, PIV, IoT and SIM functions on the same silicon.
That last point has a direct bill-of-materials consequence for an on-board unit. A C-V2X unit needs two credentials that look unrelated but are not: a V2X identity for signing safety messages over PC5, and a cellular identity for the Uu path that delivers certificate batches and firmware. Both are long-lived, both are provisioned at manufacture, both must be non-extractable, and both can live as separate isolated applets on one JavaCard secure element. One part instead of two, one provisioning step instead of two, one boundary to secure — and one supplier who has to understand both domains. Multi-applet secure elements → · C-V2X and the Uu subscription →
Requirement by requirement.
| V2X requirement | How AmbiSEC meets it |
|---|---|
| Key generated inside the tamper boundary, never extractable | On-chip key generation; the private key has no exit path in any lifecycle state |
| Signing hardware-isolated from application firmware | Host sends a hash, receives a signature |
| EC storage and PC batch lifecycle | The JavaCard V2X applet provides storage and rotation-policy enforcement at the module level. Enrolment and pseudonymous-certificate lifecycle at the platform level is being developed, and provisioning against a particular authority is programme work |
| Attestation for EA enrolment | Hardware-signed attestation lets an Enrolment Authority verify the key resides in a hardware security boundary rather than a soft simulator. Enrolment against a live authority is programme work, and no operational enrolment is claimed |
| Certificate policy changes without recall | Applet upgrade, independent of full firmware |
| Automotive environment | −40 °C to +105 °C grade available for the secure-element silicon — the component supplier's figure, not a rating of AmbiSEC as built and not a range for either V2X kit |
What the security claim does and does not say.
- AmbiSEC is based on NXP Secure Elements. Ambimat is a customer of NXP's. This site claims no partnership with NXP, no endorsement by NXP, and no evaluation, approval or certification of AmbiSEC, AmbiOBU or AmbiRSU by NXP. The specific part number is not published.
- Component assurance is not AmbiSEC's assurance. NXP's published Common Criteria evaluations cover that silicon, and the EAL6+ level referred to on this site is the component's. It is not a certificate for AmbiSEC as implemented, for the 25 × 25 mm module, for the JavaCard applet, or for AmbiOBU or AmbiRSU — none of which is evaluated or certified, and none of which inherits the component's evaluation. The certificate identifies the part, so it is held with the part number rather than published here.
- AmbiSEC is the hardware-protected security foundation, and it is not the whole V2X security system. The module-level capabilities below — device-bound identity, protected key storage and protected cryptographic operations — are implemented. The V2X message-security implementation that uses them, meaning IEEE 1609.2 and ETSI TS 103 097 signing and verification and the certificate and credential lifecycle around it, is being developed at the platform level. Which layer is implemented, and which is still being developed →
- Hardware-protected keys, certificate lifecycle, PKI trust infrastructure, message signing and national trust-anchor operation are five separate things. Supplying the security subsystem does not make a supplier a Root CA, and nothing here asserts participation in, approval by, or listing under any national PKI, SCMS, CCMS or RCAI. How those layers separate in a deployed system — enrolment and authorisation authorities, pseudonymous certificates, hardware-isolated keys — is set out in AmbiSecure's V2X security architecture.
- ISO 26262 and Automotive SPICE conformity are targets, not claims.
- Every standard named on this page is a design and compliance reference.
- AmbiSEC is a component. It does not by itself make a device compliant with anything.
- Where a third-party part's certification is cited elsewhere on this site, it is attributed to the vendor that published it.
Where this fits.
Hardware root of trust
The threat model, the EVITA taxonomy and the throughput problem.
V2X PKI
The credential lifecycle the applet implements.
AmbiSecure IoT Security Co-Processor
The same co-processor, framed for IoT deployments.
JavaCard applet development
The applet engineering capability behind the differentiator above.
AmbiSecure secure elements
The silicon class, and what tamper resistance actually means.
Secure element integration
The integration service around the part.
Evaluating a secure element for a V2X or IoT programme?
Bring your BOM constraints, your SMT cadence and the PKI you have to interoperate with. Reference designs and evaluation hardware under NDA. The integration work around the part is the V2X security integration engagement.
Questions this page answers.
What is AmbiSEC?
A 25 × 25 mm solder-down secure-element module, and the security development setup in Ambimat's Vehicle-to-Everything (V2X) programme — the third alongside the On-Board Unit and Roadside Unit development kits. It holds keys and credentials inside a tamper-resistant boundary and signs and verifies messages on behalf of its host.
Why does a V2X development setup need a secure element at all?
Because radio connectivity is not trust. In Vehicle-to-Vehicle communication a receiving vehicle must establish that a safety message came from an authorised participant and arrived unaltered; the same applies in Vehicle-to-Infrastructure communication between a vehicle and roadside equipment. That decision rests on a private key an attacker must not be able to extract from a device they can physically hold. Why it has to be hardware.
What does AmbiSEC actually do in the unit?
It generates the key pair on-chip, keeps the private key inside the tamper boundary, stores the enrolment credential and the batches of pseudonymous authorisation certificates, signs outgoing messages and verifies incoming ones. The host keeps its radio stack, application logic and operating system. How the credentials work.
What security level does AmbiSEC claim, and whose evaluation is it?
AmbiSEC is based on NXP Secure Elements. Where this site names a Common Criteria level it is the component supplier's, for the silicon — never “certified” for an Ambimat part, never with a certificate number and never with a FIPS reference. AmbiSEC as implemented is not evaluated, the module is not evaluated, the applet is not evaluated, and neither V2X kit is evaluated or certified; a component evaluation is not inherited by the module or the platform. The specific part number is not published. This site claims no partnership with NXP, no endorsement by NXP, and no evaluation or certification of AmbiSEC or either kit by NXP. Type approval of any finished product remains with the appropriate authorised body.
Can I use it with a third-party on-board unit?
Yes. AmbiSEC communicates with a host device over a defined interface, so it can sit in a unit Ambimat did not design. Where a different secure element is the better answer for a programme, we integrate that instead — the selection is a throughput and lifecycle decision, not a preference. The integration service.
Last updated 2026-10-01 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com