Ambimat GroupAmbimatAmbiSecureeSIM InitiativeEngineering BlogAhmedabad · India · Est. 1981
IoT Secure Element

AmbiSecure IoT Security Chipset

Hardware secure-element integration for connected devices. Provisioning, attestation, signed key rotation, signed update — the foundation of an IoT root of trust.

Secure ElementAttestationPKIProvisioningOTA
AmbiSecure IoT Security Chipset — embedded secure element for connected devices
Why an SE in the device

The device key has to outlive the device firmware.

Hardware root of trust

Device identity key generated and stored inside a tamper-resistant secure element. Never extractable. Never present in firmware.

Set/Get Master Key

Operations include Set/Get Master Key, key pair generation, data signing, and proprietary extensions for specific deployments.

Attestation

Each device proves its identity to the back end with a signed attestation derived from the SE root key.

Field key rotation

Operational keys can be rotated over the air without recalling the device, while the root remains unchanged.

Signed update

Firmware images are verified inside the SE before the host MCU executes them. Boot is gated on signature.

Volume-friendly

Small package, simple host interface (I²C or SPI), straightforward integration cost for high-volume IoT.

Specifications

What ships in silicon.

Form factorQFN / SOIC packages; integration via I²C or SPI; ISO/IEC 7816-3 contact variant available
CryptographyECC P-256 / P-384, RSA 2048 / 3072, AES-128 / 256, SHA-256 / SHA-384, HMAC, ECDSA
OperationsSet/Get Master Key, Key Pair Generation, Sign Data, Verify, Encrypt/Decrypt, secure messaging
ProvisioningPer-device unique key injection at our personalisation line, or in-field over a secure channel
Tamper resistanceActive shield, voltage and clock monitors, fault-injection countermeasures
Operating rangeIndustrial -40°C to +85°C; extended automotive temperatures on request
Certification targetCommon Criteria EAL5+ chip; SE-compliant integration patterns for AVA_VAN.5
Sample SDKReference C driver for Linux / RTOS / bare-metal MCU; Python tooling for provisioning lines
Architecture

How the SE sits in the device.

The host MCU runs firmware. The SE holds the keys. The two talk over a simple bus and a strict command set.

01

Boot

Host MCU asks SE to verify firmware signature.

02

Identity

Device presents SE-signed attestation to backend.

03

Provision

Backend pushes operational keys; SE wraps them under its master key.

04

Operate

Host calls SE for sign / verify / encrypt operations.

05

Rotate

Operational keys rotate. Root never moves. Device stays in field.

Designing a connected device that needs a real root of trust?

We integrate the SE, write the host driver, and provision keys on our line so your factory does not have to.

Request integration brief