OEM signing and update responsibilities describe who owns each key that a device trusts, in which order software is protected, signed, verified and distributed, and what happens when a key rotates, expires or an update fails. A mobile security team should evaluate them as a written matrix, one row per signed artefact, with a single owner per private key. This article covers Android-based devices built by an OEM or ODM and the apps that run on them. It treats iOS only for app signing, because Apple signs the iOS system itself. Protection, from Otukan or anyone else, must fit that matrix, never replace it.
Signing authority and secrets: who owns what
A modern Android device carries several independent chains of trust. The boot chain decides what software may start. The platform keys decide which system apps get privileged access. Update packages carry their own signature. Every installed app is signed by its developer or by the store on the developer’s behalf. Confusing these chains is how a device ends up trusting more than it should.
| Signed artefact | Private key owner | Verified by | What goes wrong if the key leaks |
|---|---|---|---|
| Bootloader and vbmeta (verified boot) | Device maker | Boot ROM and bootloader | Anyone can build firmware the device boots as genuine |
| Platform keys (platform, shared, media) | Device maker | Package manager | Any app signed with them gains system privileges |
| Over-the-air update package | Device maker | Recovery or update engine | Malicious updates install as trusted |
| Preinstalled partner app | App publisher | Package manager | Tampered copies replace the genuine app on update |
| Store-distributed Android app | Developer (upload key); store or developer (app signing key) | Package manager and store | Repackaged versions can be pushed as updates |
| iOS app | Developer certificate and provisioning profile, re-signed by Apple for the App Store | iOS code signing | In-house apps can be signed and distributed outside your control |
Counting the rows makes the weight of the job visible.
Derived from the six rows of the matrix on this page. Where a store holds the app signing key, the developer still owns the upload key, so both are counted.
The device maker owns the chains that decide what the whole device trusts. That is why its keys belong in a hardware security module, with named signers and an audit log, and why no supplier should need a copy. The wider checks for evaluating a device manufacturer, from build layers to model qualification, are covered separately.
Artifact order: protection, signing, verification and distribution
A signature covers the exact bytes it was made over. Anything that changes those bytes afterwards, including a protection step, invalidates it. The order is therefore fixed.
Build
Compile from a tagged source revision in a controlled build environment.
Protect
Apply obfuscation, integrity and runtime protection as part of the build, before any release signature.
Sign
Sign with the release key inside your key management system; keys never leave it.
Verify before release
Check signatures, certificate fingerprints and rollback index on the exact file you will ship.
Distribute
Publish to the store or update server; the device verifies again before installing.
The verification step is cheap and catches a wrong key, a missing scheme or an unsigned file before users do. For Android apps, the platform’s own tooling prints the signing certificates and the scheme versions present.
# Verify an APK and print its signer certificates and signature schemes
apksigner verify --verbose --print-certs app-release.apk
# Rotate an app signing key with a proof-of-rotation lineage (scheme v3)
apksigner rotate --out lineage.bin \
--old-signer --ks old-release.jks \
--new-signer --ks new-release.jks
Signature schemes have changed over time, and the scheme a device understands depends on its Android version.
- 2016
APK Signature Scheme v2 (Android 7.0)
Whole-file signing makes any change to the package detectable and speeds up verification.
- 2016
A/B system updates (Android 7.0)
Updates install to an inactive slot, so a failed update can fall back to the working one.
- 2018
APK Signature Scheme v3 (Android 9)
Adds key rotation: a signed lineage proves a new key descends from the old one.
- 2020
APK Signature Scheme v4 (Android 11)
Adds a separate signature file that supports incremental installation.
Otukan fits into this order without changing who signs. Otukan application protection is applied before the final signature, inside your existing build and release pipeline, and Otukan device protection fits the device maker’s own build and signing process. In both cases the keys stay with you. Otukan never asks for signing keys, certificates or provisioning profiles. For the firmware side of the same process, see Android secure firmware updates.
Recovery: rotation, expiry, rollback and failed installation
Signing plans are judged on the bad day. Write down what happens in each of these cases before the first device ships.
Planned events
- Scheduled rotation of an app signing key with a lineage
- Renewal of an iOS enterprise certificate and provisioning profile before expiry
- Raising the rollback index after a security fix
- Retiring an old signature scheme once devices no longer need it
Unplanned events
- A leaked platform or update key
- A revoked iOS certificate that stops in-house apps launching
- An update that fails verification on part of the fleet
- A bad update that must be withdrawn after installation
- Rotation. Android app keys rotate with a scheme v3 lineage or, for Play-distributed apps using Play App Signing, through the store’s key upgrade. Platform and verified boot keys are much harder to rotate on devices already in the field, so protect them first.
- Expiry. iOS certificates and provisioning profiles expire. App Store apps keep working; in-house apps stop launching when their profile lapses.
- Rollback. Verified boot 2.0 stores a rollback index in tamper-evident storage, so a device refuses older images once the index has advanced. Raise it only when you are sure the new image is good.
- Failed installation. On A/B devices a failed update falls back to the previous slot. On non-A/B devices recovery must succeed or the device needs service, so test the failure path, not only the success path.
Signing is not a step at the end of the build. It is a promise about who decides what your devices trust, for as long as they are in the field.
Release signing checklist
- Every private key has one named owner, and none is held by a supplier.
- No test key from the open-source tree remains in the release build.
- Protection runs before signing, and verification runs on the exact artefact you ship.
- Certificate and profile expiry dates are in a shared calendar with owners.
- A key compromise runbook exists for platform, update and app keys.
- A forced rollback and a failed installation have been tested on a reference device.