Integrating a secure element with a host MCU: the architecture.
An engineering guide to embedded secure element integration: what the host microcontroller owns, what the secure element owns, how ISO/IEC 7816-4 APDUs cross the bus between them, and where provisioning stops and field operation begins. It describes architecture, not a particular vendor’s command set.
What problem does the integration have to solve?
A secure element on a board is only as useful as the boundary drawn around it. The chip can keep a private key non-exportable, but if the host firmware decides what gets signed, holds the provisioning keys, or treats an unknown status word as success, the device’s security still rests on application code.
Integration therefore has three jobs: split responsibilities so each side does only what it can defend; build a transport that moves APDUs reliably and fails loudly; and keep the factory-time secrets that personalise the chip out of the firmware that ships in the field.
1. System architecture
Two domains share a bus, not a memory map. The host MCU runs everything that talks to the outside world. The secure element holds keys and performs operations on them. The only thing that crosses the trust boundary is a command and its response.
2. Who is responsible for what?
Most integration defects are responsibility defects: a job that belongs on one side of the boundary was quietly done on the other. Write the split down before writing the driver.
| Host MCU owns | Application and protocol logic; the network stack; constructing and validating the data to be signed (typically a digest); policy decisions about whether to ask for a signature; the driver, link layer, timeouts, retries and bus reset; storing public certificates where the applet does not; logging that never records secrets. |
|---|---|
| Secure element owns | Key generation and custody; signing, verification, key agreement and decryption with those keys; monotonic counters; PIN or access conditions where the applet defines them; the applet firewall; its own GlobalPlatform lifecycle state; the endpoint of any secure channel used to manage it. |
| Neither side alone | Trust decisions. A valid signature proves that a key holder produced some bytes; it does not make the content permitted or current. Certificate-chain checks, freshness and replay checks belong to the host application or the verifying back end. |
| Never on the host | Private keys, issuer security-domain keys, and the secure-channel keys used at personalisation. If field firmware can open a management channel to the chip, an attacker who extracts that firmware can too. |
3. How do the host and the secure element talk?
Whatever the physical bus, the logical exchange is the ISO/IEC 7816-4 command–response pair. The host always initiates; the secure element never speaks unprompted.
- Command APDU — a four-byte header (
CLA INS P1 P2), then optionallyLcand command data, then optionallyLe, the number of response bytes expected. The presence or absence of data andLegives the four ISO cases. - Response APDU — optional response data followed by a two-byte status word,
SW1 SW2.90 00is success; everything else is a defined condition, not a hint. - Length — short APDUs carry up to 255 bytes of command data and up to 256 bytes of response. Extended length raises both limits, but only if the chip, the applet and the link layer all support it; otherwise the host uses command chaining (a CLA bit) and, under T=0,
GET RESPONSEafter a61 xx. - Selection — the host selects an applet by its AID with
SELECTbefore sending applet commands. Logical channels, also signalled in CLA, let more than one applet stay selected.
Two driver rules prevent most field failures. First, map every status word the applet documents to a named outcome, and treat any other word as a transport error, never as success. Second, never retry a non-idempotent command blindly: a timeout after a signing or counter-incrementing command means the host does not know whether it executed.
To inspect real traffic, the APDU parser and status-word lookup decode both halves of the exchange, and the ISO/IEC 7816 reference covers the class and instruction bytes.
4. Transport: general industry architecture
This section describes how the industry moves APDUs between a host and a secure element. It is background, not a statement of what any one AmbiSecure part implements; that is covered in the next section.
| ISO/IEC 7816-3 contact | The smart-card interface: the chip answers reset with an ATR, then uses T=0 (character-oriented) or T=1 (block-oriented, with a prologue, information field and checksum). T=1 carries waiting-time-extension requests, so a slow cryptographic operation does not look like a dead chip. |
|---|---|
| I²C and SPI | The usual buses for soldered, embedded secure elements. GlobalPlatform’s APDU Transport over SPI / I2C specification defines a block protocol derived from T=1 (called T=1′) for carrying APDUs over these buses. Some vendors ship their own T=1-over-I²C variants, so the chip vendor’s integration manual is the authority on framing, timing and reset behaviour. |
| Contactless ISO/IEC 14443-4 | Card and token form factors carry the same APDUs over the air; the reader is the host. Relevant when one credential must work both embedded and as a card. |
Whichever bus is chosen, the link layer has to answer the same questions:
- Timing. Clock rate and the chip’s worst-case operation time set end-to-end latency. Measure signing latency on the target bus and clock, not on a bench reader.
- Frame size. The maximum information-field size bounds how much data one block carries; larger APDUs are split across blocks by the link layer.
- Waiting and polling. The host must know how the chip signals “still working” versus “no answer”, and how long to poll before declaring a fault.
- Reset and recovery. Define how the host resynchronises after a corrupted frame, a brown-out or a watchdog reset, and what applet state survives it.
- Bus sharing. On a shared I²C or SPI bus, another peripheral can delay or corrupt frames. Integrity checking in the link layer is what turns that into a retry instead of a wrong answer.
5. What AmbiSecure has published about its own host interface
The AmbiSEC IoT Security Co-Processor is documented with a host driver that exchanges APDUs over I²C, SPI or ISO/IEC 7816, with the host MCU initiating every call. The IoT Security Applets list ISO/IEC 7816 (T=0 / T=1) for contact deployments and I²C for embedded secure-element variants paired with the co-processor.
Which of those buses a specific design uses, the clock rate, and the link-layer framing are confirmed per project in the integration brief. So are applet identifiers, command codes and status words. They are not published here, and an integration should not guess them.
AmbiSEC secure-element architecture aligned to v0.9.3 interface/spec evolution, with validated implementation based on the implemented v0.9.2 subset.
6. Lifecycle: where the chip is in its life
Secure elements that run Java Card and GlobalPlatform carry an explicit lifecycle, and the chip enforces it. The host driver should read and respect it rather than assume it.
| Card lifecycle | OP_READY → INITIALIZED → SECURED, with CARD_LOCKED and TERMINATED as the restrictive end states. A device in the field normally sits in SECURED: content management is still possible, but only through an authenticated security domain. |
|---|---|
| Applications | Load files are LOADED; applet instances move through INSTALLED and SELECTABLE into applet-specific personalised states, and can be LOCKED. |
| Security domains | The issuer security domain (ISD) manages the card; supplementary security domains can hold keys for an application provider. Each domain’s keys open its own secure channel. |
The GP status reference decodes these states as the chip reports them.
7. The provisioning boundary
Provisioning is where a generic chip becomes a specific device’s identity, and it is the step most often blurred into firmware. Keep the line sharp:
- On the personalisation line: the management channel to the security domain is opened under GlobalPlatform secure messaging, with the channel keys held in an HSM. Applets are loaded and installed, device keys are generated on-chip, certificates or attestation material are written, and the card is moved to its field lifecycle state.
- In the field: the host firmware selects the provisioned applet and asks for operations. It does not hold the keys that personalised the chip, and it cannot reopen that channel.
- Later updates: key rotation or applet updates go back through an authenticated management channel, from an off-card entity that holds the right security-domain keys — not through the application driver.
How that management channel works — static keys, session-key derivation, mutual authentication and security levels — is covered in SCP03 provisioning and secure-channel architecture.
8. An application and authentication flow
A typical device-authentication exchange, at concept level. Command names here are descriptive; real applets define their own.
Two design choices in that flow matter more than they look. Giving the chip a digest and a key reference, rather than a whole message, keeps the secure element from becoming an oracle that signs anything well-formed. And checking version and capabilities at start-up lets a host and an applet that disagree fail at boot instead of on the first signature.
9. Integration checklist
- Responsibility split written down and reviewed before driver work starts.
- Bus, clock rate, frame size and reset behaviour confirmed with the chip vendor’s manual.
- Every documented status word mapped; anything else is a transport error.
- Timeout and retry policy defined per command, with non-idempotent commands never retried blindly.
- Applet version and capabilities checked at boot and recorded in diagnostics.
- No security-domain or secure-channel keys in field firmware or logs.
- Latency measured on the target hardware, bus and clock.
Standards referenced
- ISO/IEC 7816-4 — organisation, security and commands for interchange (APDU structure, status words).
- ISO/IEC 7816-3 — electrical interface and transmission protocols T=0 and T=1.
- GlobalPlatform APDU Transport over SPI / I2C — APDU transport for embedded secure elements.
- GlobalPlatform Card Specification 2.3.1 — card, application and security-domain lifecycle.
Frequently asked questions
What does the host MCU do in a secure element integration?
The host MCU runs the application, decides what to ask the secure element for, builds and transports the APDUs, and handles timeouts, retries and bus reset. It never holds the private keys or the keys used to manage the secure element.
How does a host MCU send commands to a secure element?
As ISO/IEC 7816-4 command APDUs: a CLA, INS, P1, P2 header with optional data and expected length. The secure element returns optional data and a two-byte status word. A link-layer protocol carries those APDUs over the physical bus.
Which bus connects a host MCU to an embedded secure element?
Commonly I2C or SPI for soldered parts and ISO/IEC 7816-3 contact for card-style parts. For AmbiSecure parts, the bus, clock rate and framing used by a given design are confirmed per project.
Should the host firmware hold the secure channel keys?
No. The keys that open a management channel to the secure element belong in an HSM on the personalisation line or in a back-end key service. Field firmware that can open that channel hands the same ability to anyone who extracts the firmware.
Putting a secure element on your board?
Chip selection, host driver, applet and field lifecycle are covered by our secure-element integration engagement. Bring your MCU, bus and threat model.