A device programme can use firmware integrity evidence that shows three things: the device booted firmware you signed, protected partitions have not changed since, and security settings still hold while the device runs. Otukan builds this evidence into your Android firmware using verified boot, partition verification and hardware-backed key attestation on chipsets that support it, and delivers it to a verification server you control. Expected values follow every authorised update. The work is engineered per model and chipset, inside your own build and signing process.
What integrity means
“Firmware integrity” covers three different questions. Otukan answers the first two directly and makes the third easier to act on.
Trusted boot
Each stage of the boot chain checks the next stage’s signature before running it, from the boot ROM through the bootloader to the kernel and system partitions. On Android this is Android Verified Boot, with a signed metadata structure (vbmeta) holding the expected hashes and a rollback index. Otukan configures this chain for your keys and reports the result: a boot state, such as verified, self-signed, unverified or failed, and the bootloader lock state.
Runtime state
After boot, integrity depends on protections staying in force. Read-only partitions are checked block by block with dm-verity as they are read. Mandatory access control (SELinux in enforcing mode) and production build settings matter too. Otukan reports these signals so you see the device as it is now, not only at start-up.
Vulnerability assessment
Whether the firmware contains known flaws is a separate question, answered by patch levels and security testing. Otukan reports the patch level of each device against your approved values, so out-of-date devices are easy to find and prioritise. Firmware integrity versus firmware security testing is covered on firmware integrity vs firmware security testing.
Who produces and verifies each signal
Strong evidence depends on who produces it and who checks it. Otukan sets up each signal so that it is produced by the right layer and verified by a party the device does not control.
| Signal | Produced by | Depends on | Verified by |
|---|---|---|---|
| Boot chain signatures | Boot ROM and bootloader | Chipset vendor boot chain, your signing keys | The device itself at each boot |
| Bootloader lock and boot state | Bootloader | Your lock configuration | Your server, from the key attestation record |
| Partition verification | Kernel (dm-verity) | Hash trees built into the signed image | The device, on every read |
| Patch levels | System image and vendor image | Your build process | Your server, against expected levels per model |
| Key attestation | Hardware-backed key store in the trusted execution environment or a secure element | Chipset support and attestation keys provisioned at manufacture or remotely | Your server, which checks the certificate chain and reported values |
| Runtime security settings | Operating system | Your build configuration | Your server or management tools, alongside the signed evidence |
Two things make the evidence strong, and Otukan delivers both. On chipsets with a hardware-backed key store, the key signals are signed by a key the main operating system cannot reach. And the verification server holds an approved list of expected values for each model: boot keys, patch levels and image versions. Together they show not only what a device reported, but whether it is acceptable.
The device architecture this depends on is covered on Android device security architecture.
Lifecycle and authorised changes
Firmware changes legitimately throughout a device’s life. Otukan keeps integrity evidence in step with those changes, so approved releases stay trusted and unapproved ones stand out.
- Authorised updates. Each update changes image hashes and patch levels. Otukan publishes the new expected values to the verification side before the update is released.
- Rollback protection. Verified boot uses a rollback index so older, vulnerable images are refused. You decide when to raise it, and Otukan builds it into the release plan.
- Key ownership. Whoever holds the boot and update signing keys decides what counts as authorised. Otukan agrees custody and rotation with you before the first device ships.
- Repairs and refurbishment. The programme states which images service centres may flash and how they are signed, so repaired devices return as trusted devices.
- End of support. Otukan agrees what happens to devices when updates stop, so ageing firmware is handled by plan.
| Question | Who answers it |
|---|---|
| Which boot keys and image versions are approved per model? | OEM, with the ODM and Otukan |
| Who publishes expected values when an update ships? | Otukan, with the team that owns the update pipeline |
| What happens when a device reports an unexpected value? | The institution or fleet operator, through the policy it sets |
| When is the rollback index raised? | OEM security owner |
For the wider programme, see mobile device security.