Otukan sits in the system layer of an Android-based device. Its protection components are built into the firmware image you sign, run with privileges agreed with your engineers, and rely on the boot chain and hardware beneath them. Above them, your apps and management tools consume the device state Otukan reports. Off the device, a verification service in the environment you choose checks that evidence. Otukan owns those components and that service; verified boot, access control and hardware key storage stay Android and chipset functions. The architecture applies to devices whose firmware an OEM or ODM builds.
Trust layers
Each layer trusts the one below it and is checked by it. Otukan’s place is easiest to see layer by layer.
| Layer | What lives there | Who owns it | Otukan’s role |
|---|---|---|---|
| Hardware | Boot ROM, fused keys, trusted execution environment, secure element where present | Chipset vendor | Uses hardware-backed keys and attestation where the chipset provides them |
| Boot chain | Bootloader, vbmeta, kernel image | OEM keys, chipset vendor code | Configures verified boot for your keys and reports its result |
| Operating system | Kernel, dm-verity, SELinux policy | Android platform, customised by the OEM | Checks that these protections stay in force at runtime |
| Privileged components | System services and apps signed with platform keys | OEM, with Otukan for its own components | Runs Otukan’s protection components and enforces model policy |
| Applications | Your apps and your management agent | You | Receive device state through a defined interface |
Why the privileged layer matters
System components run with rights ordinary apps never receive. That makes the layer powerful for protection and attractive to attackers. Otukan’s components sit here so they can watch it, and their own privileges are limited to what each function needs.
Dependencies
Reviewers need to know which behaviour comes from Android, which from the chipset and which from Otukan.
| Function | Provided by | Otukan’s part |
|---|---|---|
| Verified boot and rollback index | Android platform and bootloader | Configured for your keys, result reported |
| Block-level partition checks | Android platform (dm-verity) | Result included in device evidence |
| Mandatory access control | Android platform (SELinux) | Enforcing mode checked at runtime |
| Hardware-backed keys and attestation | Chipset, through Android’s key store (KeyMint) | Used for signing evidence where present |
| Protection components and model policy | Otukan | Built, maintained and updated by Otukan |
| Evidence report and verification | Otukan | Collected on device, verified in your environment |
Where a chipset lacks a function, the record says so for that model, and Otukan’s evidence carries a matching label.
Keeping Otukan’s part current
Otukan’s components change on their own schedule as well as yours. Each new version is built into your next firmware release, tested on the models in scope and signed by you, so an Otukan update never reaches a device outside your release process. The verification service is updated in the environment where it runs, with the expected values for every model it serves. Because the platform functions above are maintained by the Android project, the chipset vendor and the OEM, Otukan checks each Android security patch and chipset update for changes that affect its own components before your release goes out.
Failure behaviour
A security architecture is judged by what happens when something is missing. Otukan defines each state per model and tests it before release.
- No network. The device keeps enforcing its last approved policy. Reports are queued and sent with their original timestamps on reconnection.
- Verification service unreachable. Your services decide, by rule, whether stale evidence still grants access or triggers a fallback.
- Hardware feature absent. Protection and reporting continue, and evidence is labelled software-level so your server can weigh it.
- Failed integrity check. The device moves to the restricted state defined for that model, and the finding is reported when possible.
- Interrupted update. On devices with A/B system partitions, a failed install falls back to the slot that last booted correctly. The device keeps the Otukan components and policy of the image it runs, and reports the reverted version once it is online.
Each of these states is tested on the physical models in scope before release, and the results go into the model’s architecture record alongside the trust-boundary diagram. How to plan those tests for your own models is covered on device security evaluation.
How firmware integrity evidence is produced and verified is covered on Android firmware integrity. Which hardware features a model offers is covered on hardware-backed mobile security. For the product overview, see mobile device security.