Securing device identity with an Infineon OPTIGA Trust M
A few weeks ago a small company building consumer devices asked us a question. Their AI runs in the cloud, and the board in the customer’s home has to authenticate to their API.
The classic trap is an API key in a config file, where every board holds the same file. One opened board leaks the fleet, and rotating the key means touching every device.
We built a stronger setup for them using an Infineon OPTIGA Trust M instead. This chip is a secure element: a small chip on the I2C bus that holds keys and signs with them, and it costs under $2.
The design
What our solution does:
- Each device generates a P-256 key pair inside the chip, once - and the private key never leaves the chip.
- The public key is read out once and stored in data object 0xF1D1, so it can be read back at every boot.
- The device id is derived from the public key
- To talk to the API, the application asks a small tool on the device for a token. The tool builds a standard JWT, signed ES256 by the chip, with the API as audience and a five-minute lifetime. The application sends it as a bearer token with its usual HTTP client.
- The server checks the JWT against that device’s public key. A standard JWT library call plus a key lookup.
The chip side is open source: trustm-rs. This repo contains Rust bindings for the Trust M built on Infineon’s C host library (MIT licensed), and we used this as our base to build our tool.
Why we like it:
- One key per device, and it cannot be extracted or duplicated.
- Enrolling a device is adding its public key on the server, and revoking is removing it.
- Tokens expire after five minutes - i.e. a leaked token is worth very little.
- The application does not change, it gets a string and puts it in a header to authenticate.
- No secret on the filesystem.
Enrolment
How each public key gets onto the server depends on how the boards are made, and we offer three options:
- On the production line, generate the keyset, collect the public halves in a manifest, load it on the server before the units ship.
- Trust on first use (TOFU) - the server pins the first key a device presents, protected by a one-time enrolment code handed to the installer.
- Or using the chip itself. Every Trust M ships with a factory key in slot 0xE0F0 and an Infineon-issued certificate for it in data object 0xE0E0, chained to Infineon’s CA. The device signs its new public key with the factory key and sends the certificate along. The server checks the chain, then checks the chip serial against the list of serials you bought. A valid Infineon certificate proves a genuine chip. The serial list of purchased Trust M proves it is one of yours.
Limitations
The chip protects the key. It does not protect the device. Concretely:
- A hacked device can access the API. A Root user on the board asks the chip to sign, exactly like the application does. The chip cannot tell the difference.
- It only gets that one identity. The key cannot be extracted, so it cannot be copied to another device, and it cannot be used without the physical chip.
- Abuse is easy to track and ban. Every request carries the device id. Odd traffic from one id stands out, and banning it is straightforward.
- Keep server-side permissions narrow, per device. A rooted device should only ever reach its own data.
Where we stand at Kernwerk
This solution is simple and straightforward to implement both for hardware manufacturers (the Trust M is a very easy addition to the board’s design), as well as for cloud AI server runtime (simple authentication & ban server feature).
A local confidential AI model running at the edge requires a different set of tools, such as secure boot, an integrity-checked root filesystem, as well as our confidentiality toolset - but this is a different threat model. In the meantime the Trust M and our authentication tooling drastically helps with securing small deployments of devices relying on cloud AI.