Secure Elements in Connected Vehicles

The connected-vehicle threat model is not the laboratory threat model. The device sits in a chassis any owner, mechanic, or attacker can open. The firmware will eventually leak, intentionally or otherwise. The keys cannot live in software. This post walks the hardware root of trust as it actually applies to OBUs and RSUs — what a secure element does, where it sits, and what changes when the silicon is in MFF2 instead of a nano-card.

A V2X PKI is only as strong as the boundary that holds its private keys. The architecture documented in how V2X PKI works assumes that boundary is a discrete tamper-resistant secure element with hardware key isolation and signed boot. This piece is the hardware side of that assumption: what an SE is, how it differs from neighbouring devices, what the form-factor choices imply, and why none of this is optional in field-deployed mobility hardware.

Why hardware identity, not software identity

The argument for hardware-rooted identity in connected vehicles compresses into four observations about the operating environment.

1. Physical access is the default. An OBU lives inside a vehicle owned, serviced, repaired, modified, and occasionally stolen by parties who are not the OEM. An RSU sits on a pole at a roadside, exposed to weather, vandalism, and unauthorised maintenance. There is no operationally meaningful sense in which an attacker is kept away from the device.
2. Time is on the attacker’s side. A laboratory attacker who has obtained one OBU has indefinite time to extract its firmware, dump its flash, probe its debug interfaces, and analyse its key-storage layout. The defence has to assume the attacker will succeed at any attack that scales linearly with patience.
3. Fleet compromise from one device is the failure mode. A successful extraction on one OBU, when identity material is software-stored, yields the cryptographic technique used across the fleet. The marginal cost of compromising the second OBU is near zero. Hardware identity inverts this: every device requires its own attack on its own silicon, with no scaling discount.
4. Verification is local. A vehicle on PC5 sidelink verifies safety messages from neighbours with no network round-trip. There is no real-time policy enforcement to fall back on if a key was extracted yesterday. The protection has to be at the key-storage layer, before it leaks.

This is treated in more detail in why software-only device trust fails; the conclusion is that the threat model the architecture was designed against rules out software-only identity.

What a secure element actually is

A secure element is a small, low-power, tamper-resistant integrated circuit designed to hold cryptographic keys and perform cryptographic operations on them without ever exposing the keys to anything outside its boundary. It is not a coprocessor in the general-purpose sense; it is a key-custody and cryptographic-execution device with a narrowly defined command surface.

// Anatomy of a discrete secure element
                ┌───────────────────────────────────┐
                │     Tamper boundary               │
                │  ┌─────────────────────────────┐  │
                │  │  CPU + secure RAM           │  │
                │  │  (executes JavaCard /       │  │
                │  │   native applet code)       │  │
                │  └─────────────────────────────┘  │
                │  ┌─────────────────────────────┐  │
                │  │  Crypto accelerators        │  │
                │  │  (AES, ECC P-256/P-384,     │  │
                │  │   RSA, SHA, TRNG)           │  │
                │  └─────────────────────────────┘  │
                │  ┌─────────────────────────────┐  │
                │  │  Non-volatile key store     │  │
                │  │  (per-applet, isolated)     │  │
                │  └─────────────────────────────┘  │
                │  ┌─────────────────────────────┐  │
                │  │  Sensors: voltage, clock,   │  │
                │  │  temperature, light,        │  │
                │  │  glitch detection           │  │
                │  └─────────────────────────────┘  │
                │   Mesh, side-channel hardening    │
                └───────────────┬───────────────────┘
                                │  ISO 7816 / I²C / SPI
                                ▼
                        ┌───────────────┐
                        │   Host MCU    │  ← runs application firmware
                        └───────────────┘

Four properties distinguish a secure element from a general-purpose microcontroller, and each of them maps to one of the threats above.

• Tamper resistance. Side-channel-hardened analog design, active mesh, voltage and clock monitors, glitch detectors. Common Criteria EAL5+ at the chip level is the public mark of this body of work — the underlying secure-element silicon in AmbiSEC Module carries that certification.
• Key isolation. Private keys are generated inside the boundary, never leave it, and are referenced by handle (e.g. "key 0x03") rather than by value. The host MCU never holds the key. A compromised host firmware cannot exfiltrate what it never had access to.
• Attestation. The SE can prove its identity to a remote authority before being trusted with a credential. The attestation signature is generated by a manufacturer-injected key inside the boundary. The Enrolment Authority in V2X relies on exactly this to decide whether a fresh device may enrol.
• Signed boot enforcement. The host MCU starts only if the firmware image’s signature verifies against a key the SE exposes. Modified images stop at boot, before they can interact with anything else.

The secure elements technology page covers the silicon class in broader engineering detail.

Form factors: nano-card vs MFF2

Same silicon class, different mechanical packaging. The choice drives factory-line cost, field-replacement options, and integration complexity. Three form factors matter in connected-mobility deployments.

Removable 4FF nano-card

The smallest SIM form factor (12 × 9 mm), inserted into a holder on the host PCB. Used where the identity may need to be replaced in the field without replacing the entire device: roadside units that are serviced, fleet vehicles transferred between operators, lab development hardware. The mechanical holder adds BOM cost; the operational flexibility is the trade-off.

Solderable MFF2 (DFN-8)

A surface-mount package, soldered to the board at SMT line. Tamper-resistant by mechanical integration: physically removing the SE damages the board. The form factor automotive OEMs and industrial integrators choose for unattended deployments where the identity is intended to last the device lifetime. AmbiSecure ships both removable and solderable forms across its IoT Security Co-Processor product line.

Integrated SE (iSIM / iSE)

The secure element implemented as a hardened IP block inside the host MCU or modem SoC. Lower BOM cost, more constrained tamper boundary (the boundary is now whatever the SoC vendor implements). Suitable where supply-chain depth allows the OEM to trust the SoC vendor’s integration. Less commonly the right answer for connected-vehicle deployments today; the discrete SE remains the conservative default.

The choice between these is not a security ranking — all three can satisfy the V2X threat model. It is a procurement and lifecycle decision. The nano-card is the most flexible; the MFF2 is the most automotive-friendly; the iSE is the most integrated. AmbiSecure’s default for V2X integrations is MFF2 because the typical deployment is "soldered to an OBU board for ten years".

Form factor is not service

One persistent confusion worth addressing directly: the 4FF nano-card form factor is not a SIM service. The shape of the card is what people see; the contents of the card are what matters. The same physical 4FF package can carry:

• A FIDO2 / WebAuthn applet (no telecom service involved).
• A PIV applet (government identity, no telecom service).
• A V2X EC/PC management applet (no telecom service).
• An eUICC carrying one or more operator profiles (yes, telecom service — via SGP.22 or SGP.32 RSP).
• Several of the above in parallel, AID-selectable, on a multi-applet GlobalPlatform 2.3.1 card.

The applet stack inside the SE is what determines what the SE does. The form factor is a packaging choice. Embedded secure-element FIDO2 authenticators covers this in detail for the FIDO-on-SIM case; the same architectural point applies to V2X-on-SIM.

Key isolation in practice

Key isolation is what makes hardware identity actually hardware identity. The operational pattern is straightforward and almost identical across applets.

// Host MCU asks the SE to sign a V2X message (illustrative)
host_mcu                                  secure_element
  │                                       │
  │  1. Hash V2X message (SHA-256 host    │
  │     side; cheap, no key involved)     │
  │                                       │
  │  2. APDU: SIGN, keyHandle = 0x03,    │
  │     data = hash                       │
  ├─────────────────────────────────────►│
  │                                       │
  │                                       │ 3. SE retrieves Kpc_priv from
  │                                       │    isolated key store (handle 0x03)
  │                                       │
  │                                       │ 4. SE performs ECDSA-P256 signature
  │                                       │    using on-chip ECC accelerator
  │                                       │
  │  5. APDU response: signature (r, s)  │
  │◄─────────────────────────────────────┤
  │                                       │
  │  6. Host MCU assembles V2X message    │
  │     + signature on the wire. Never    │
  │     touched the private key.          │

The host never possesses the key. A debug interface, a buffer overflow, or a malicious firmware update on the host MCU does not yield key material because the key is not in host memory at any point. The compromised firmware can ask the SE to sign things while it is running, which is a different (and managed) problem — but the keys do not leak.

Secure boot and the SE

A V2X OBU has two firmware-trust problems and the SE participates in both.

Boot-time integrity

The host MCU’s boot ROM hashes the application firmware image and asks the SE to verify the hash against a signature signed by the OEM’s release key. The signature-verification key lives inside the SE’s isolated key store. If the verification fails, the boot ROM refuses to transfer control. A modified firmware image stops at boot.

OTA update integrity

A firmware update arriving over the air (cellular, V2X, or service-bay diagnostic link) is signed by the OEM release key. The host MCU downloads the candidate image, asks the SE to verify the signature, and only commits the update to flash if verification succeeds. Combined with rollback protection (a monotonic version counter inside the SE), this prevents an attacker from downgrading the device to a vulnerable firmware version.

Without the SE in this loop, the verification key would live in flash that firmware could rewrite — the chicken-and-egg problem where the thing that verifies firmware integrity is itself firmware. The SE breaks the cycle by holding the verification key outside the host’s reach.

Anti-cloning by construction

A connected-vehicle deployment fails differently when device identity can be cloned. A cloned OBU presents the same fleet credential as the legitimate one; the PKI cannot distinguish them; safety-message signing power scales with the attacker’s clone count. The deployment moves from "one compromised vehicle" to "an attacker who can amplify a hazard signal across geographies they don’t occupy".

Hardware-bound identity makes cloning a silicon-level attack rather than a software attack. To clone an OBU’s identity, an attacker has to extract material from the SE itself — against active tamper protection, against side-channel-hardened analog circuitry, against per-die randomised key storage. This is not impossible in a well-equipped lab; it is uneconomical at fleet scale because each clone costs as much as the first. The economics, not the impossibility, are the defence.

TPM vs HSM vs secure element

Three nearby device classes, often confused. The differences matter in connected-mobility deployments because picking the wrong class produces a hardware-rooted identity story that does not actually fit the threat model.

The right tool for V2X PKI participation at the device is a discrete secure element. TPMs are excellent for the laptop they are soldered into; HSMs are excellent for the Authorisation Authority running in a datacentre. Neither has the applet ecosystem, the form factor, or the power envelope of a discrete SE for the OBU-side problem. Secure element vs TPM vs HSM goes deeper into the classification.

OTA trust anchors

A connected vehicle’s software composition changes over its lifetime. The secure element is the trust anchor that makes this safe.

• OEM release key. Lives in the SE’s key store. Used to verify firmware-update signatures.
• V2X PKI trust anchors. The Root CA public keys from the current CTL live in the SE. The trust anchor set evolves over time as the CTL is updated; the SE-side applet handles the update under a separate signing key.
• Manufacturer attestation key. Injected at factory, signed by the OEM CA, used by the SE during EA enrolment. Never rotated; the device’s lifetime identity anchor.
• Per-device device key. Generated inside the SE; used to derive operational credentials. Never leaves the boundary.

Together, these keys are what allow a vehicle’s software composition to evolve safely over a decade in the field. The hardware does not change; the trust material does, under cryptographic continuity.

Automotive operating environment

One detail that distinguishes connected-mobility SE selection from enterprise SE selection: the operating range. An OBU in a vehicle sees temperatures from −40°C in cold climates to +105°C inside a parked engine bay. An RSU on an Indian highway sees +85°C ambient. The SE silicon has to sustain the cryptographic-throughput requirement (10 Hz ECDSA-P256 signatures, ECDH for session establishment, periodic PC batch operations) across that range, for the design life of the device.

Not every SE silicon class meets this requirement. The IoT Security Co-Processor product line specifies an automotive-temperature variant precisely because this is where ordinary commercial-grade SE silicon stops working. The hardware constraint translates directly into a silicon-selection constraint that the rest of the architecture relies on.

Architectural implication

The case for hardware-rooted V2X identity is not "use a secure element because it is more secure". The case is sharper than that. The V2X PKI architecture documented in how V2X PKI works — the Enrolment Authority, the Authorisation Authority, the Pseudonymous Certificate lifecycle, the offline-trust property — was designed against a threat model that assumes hardware binding. Take the SE out and the architecture does not gracefully degrade; it fails in specific predictable ways:

• The EA cannot reliably attest a device; any verification can be spoofed by an attacker who extracted the attestation key from firmware.
• PCs can be cloned across the fleet; one extracted batch becomes thousands of valid signers.
• Signed boot is bypassable; modified firmware can be flashed onto stolen devices and joined back to the fleet.
• Revocation only works against well-behaved attackers; a compromised device that does not consult the CRL keeps signing forever.

Hardware identity is not an enhancement to the V2X PKI. It is the assumption the PKI was designed to rely on. The secure element is the architectural component that satisfies the assumption.

What AmbiSecure ships

• IoT Security Co-Processor (AmbiSEC Module) — the secure-element silicon platform for V2X OBU / RSU integrations. Removable nano-card and solderable MFF2 form factors. Automotive operating range. Underlying secure-element silicon CC EAL5+ at the chip level.
• JavaCard applets — the applet platform inside the SE; ships with FIDO2, PIV, OpenPGP applets and supports custom V2X EC/PC management applets.
• JavaCard development — custom applet engineering for the OBU-specific certificate-management logic.
• HSM-backed personalisation lines — the manufacturing-time provisioning infrastructure that makes the per-device attestation key injection defensible.

What AmbiSecure does not do: operate the V2X PKI, ship turnkey OBUs or RSUs, or claim ISO 26262 / ASPICE certification of the integrated AmbiSEC Module product. The boundary is documented on the trust page.

Related reading

• How V2X PKI works — the architecture the SE participates in.
• Why software-only device trust fails — the threat model in detail.
• Device identity at manufacturing scale — the factory provisioning side.
• Secure element vs TPM vs HSM — the device-class comparison.
• Secure elements technology page · IoT Security Co-Processor product · IEEE 1609.2 reference.