The hardware-backed capabilities on a target device depend on its chipset, not on the Android version it runs. Most current Android devices provide a trusted execution environment, some add a secure element, and the attestation keys and rollback storage vary by chipset and device maker. Otukan confirms which of these each model in your programme really offers, uses them for its keys and evidence where they exist, and labels every signal as hardware-backed or software-level. This page covers Android-based devices. It does not suggest that every model offers the same protection.
Hardware dependencies
Four components decide what a device can prove about itself. Otukan checks each one per model during qualification.
| Component | What it provides | Who supplies and configures it | What Otukan checks |
|---|---|---|---|
| Boot ROM and fused keys | The first link of the boot chain, fixed at manufacture | Chipset vendor, keys fused by the OEM | Whether the device boots only images signed with your keys |
| Trusted execution environment | Isolated processing and key storage beside Android | Chipset vendor, integrated by the OEM | Key generation, use and attestation on the physical unit |
| Secure element (StrongBox) | A separate chip with its own processor and storage | Chipset vendor or module supplier, enabled by the OEM | Presence, and which key types it accepts |
| Rollback storage | Tamper-resistant counters for boot and key state | Chipset and storage supplier | Whether rollback indexes are held in protected storage |
Key boundaries
“Hardware-backed” covers three separate ideas. Otukan treats them separately because each answers a different question.
Isolation
Isolation decides where a key lives and who can use it. A key in the trusted execution environment is used on request but never handed to Android. A key in a secure element sits on a separate chip designed to resist physical attack, outside the main processor. Otukan chooses the placement per key.
Attestation
Attestation lets a remote server check a claim. The device’s key store signs a certificate stating that a key is hardware-backed, together with the boot state and patch level it observed. The chain leads to attestation keys provisioned at the factory or, on newer devices, through Android’s remote key provisioning. Otukan verifies that chain on your server.
Key lifecycle
Every key has a start and an end. Otukan records how each key is generated, what it may be used for, whether it survives a factory reset, and how it is retired when a device leaves service.
| Stage | What Otukan defines per key |
|---|---|
| Generation | Inside which hardware, and with which usage limits |
| Use | Which component may call it, and under what device state |
| Rotation | What triggers a new key and how the server learns of it |
| Retirement | What happens at factory reset, repair and decommissioning |
Portability
Two models that run the same Android version can offer very different hardware. Moving to a new chipset, a new board revision or a new supplier can change what your devices can prove.
- Model differences. One model may have a secure element and another only a trusted execution environment. Otukan’s compatibility entry for each model shows the difference, and your server policy can treat them differently.
- Supplier responsibilities. The chipset vendor supplies the isolated environment and its firmware updates; the OEM provisions keys at the factory; the ODM builds the image that uses them. Otukan records who maintains each piece for the life of the model.
- Changes mid-programme. A chipset revision or second-source supplier triggers the same qualification checks before shipment, so a quiet hardware change does not weaken the evidence.
Questions to put to your supplier
Before you choose a model, ask the device maker for written answers to these questions. Otukan checks the answers on physical units during qualification.
- Which isolated hardware does the model provide, and which key types does each part accept?
- Are attestation keys provisioned at the factory, remotely, or both, and who can revoke them?
- Where are rollback counters stored, and can a repair centre reset them?
- Who ships firmware updates for the isolated environment, and until which date?
Where these components sit in the wider device design is covered on Android device security architecture. How the work is shared with device makers is covered on OEM device security integration. For the product overview, see mobile device security.