AmbiSEC — the boundary the keys never cross.
AmbiSEC is a 25 mm × 25 mm solder-down module with a Common Criteria EAL6+ compliant secure element at its centre. 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.
This is the shipping product on this site. 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 | Common Criteria EAL6+ compliant secure element, dual-domain co-processor |
| 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 |
| Provisioning | Unique 128-bit identity key burned at manufacturing, non-extractable by hardware design; SCP03-wrapped personalisation under HSM custody |
| Lifecycle | Secure boot, OTA verification, applet upgrade under GlobalPlatform SCP03 |
| Environment | Automotive operating range available, −40 °C to +105 °C |
The same silicon 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.
Microcontroller domain — application firmware, connectivity stacks (BLE, Thread, Wi-Fi, LoRa, sub-GHz), sensor acquisition, edge logic.
Cryptographic security domain — 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 under SCP03. 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 | JavaCard V2X applet manages both, with rotation policy enforced in the applet |
| Attestation for EA enrolment | Hardware-signed attestation lets the Enrolment Authority verify the key resides in certified silicon rather than a soft simulator |
| Certificate policy changes without recall | Applet upgrade under SCP03 |
| Automotive environment | −40 °C to +105 °C operating range available |
What the security claim does and does not say.
- The security claim is stated as Common Criteria EAL6+ compliant — what the secure element is built to. It is not an assertion of a formal certificate for AmbiSEC, for the module, for the applet, or for any product built around it.
- 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.