OptiStick and RK3576 keys
Wilber Zheng · 2026-11-08 · Names only. No private key material.
Summary
- RK needs four production signing keys for mass production. AVB and OTA already exist and are shared with OptiStick. Secure boot and TA still need to be created.
- RK should have its own secure boot key rather than use an OptiStick one. Once its hash is burned into a chip, it can never be changed.
- The RK TA is signed today with Rockchip's public sample key. This must be replaced before mass production.
All keys on the two products
1. Firmware signing keys (these prove a firmware really came from us)
| Key | In plain words | OptiStick | RK3576 | Can it be changed after shipping? |
|---|---|---|---|---|
| Secure boot | The chip's first check at power-on: it only starts a bootloader signed with this key | Exists. 8 keys: 4 roots (efuse-prod-root-0..3) and 2 chains of level keys (efuse-prod-c0/c1-lvl1/lvl2). One root and one chain are in use, the rest are spares.Test: the same set in the sandbox, efuse-dev-* |
Production key not created. One key signs both the loader and U-Boot. Test: rk-boot-dev-k1, borrowed from the OptiStick sandbox key efuse-dev-c1-lvl2 |
OptiStick: level keys can be replaced by re-signing. A root cannot. RK: no |
| TA | Decides which Trusted App may run in the chip's secure area and ask for the disk key | None. Not needed today | Production key not created. Uses Rockchip's public sample key today | No. Its public key is inside U-Boot, which OTA does not update |
| AVB | The second check at boot: U-Boot only starts a kernel and system signed with this key. The runtime system integrity check (dm-verity) relies on it and has no key of its own | Shared. Production: avb-prod-k1. Test: avb-dev-k1 |
No. Its public key is inside U-Boot | |
| OTA | The device only installs update packages signed with this key | Shared. Production: firmware-prod-k2 (KMS name ota-prod). Test: firmware-dev-k1. The old firmware-prod-k1 is retired. Each package names its board, so an OptiStick package cannot install on RK |
Yes. The trusted key list can be updated by OTA | |
| App signing | Will prove an app is ours when apps are updated on their own | Test only: app-dev-r1. Production is not done yet, and production firmware does not trust this key |
- | |
2. Other keys (not used to sign firmware)
| Key | In plain words | OptiStick | RK3576 |
|---|---|---|---|
| Disk encryption | Encrypts user data. The key is not stored anywhere; it is worked out at every boot | Worked out from the chip's group key DGPK1 plus each unit's chip ID. Chips in the same group share that group key | Worked out through the TA from the HUK, which is unique to each chip |
| SSH access | Lets support and developers log in to a device remotely | Shared: support key (production), team key (test), and the optisigns-device-agent certificate CA | |
| SecureLink | The key for the remote connection tunnel | One per device, generated at activation, not in the firmware | |
| Telemetry enrol key | Used when a device registers with the telemetry service | Both products have one. It is added to the image at build time | |
Production signing for both products goes through the same service account, optisigns-os-release-prd.
What the TA key is for
A Trusted App (TA) is a small program that runs in the chip's secure area. On RK, one TA asks the chip for a secret that only that chip can produce, and the disk encryption key is built from it. The secure area runs a TA only if its signature is valid, so the signing key decides who can reach that secret.
Rockchip's sample key is public, so anyone can sign a TA that our devices will accept. Our own key closes this. It has to be in place before mass production, because units already shipped cannot receive a new one over OTA.
OptiStick does not use a TA today. If it does later, it should get its own TA key.
Why RK should not use an OptiStick secure boot key
OptiStick has a chain of keys, so a lower-level key can be replaced by re-signing. RK has no chain: one key signs every build and its hash stays in the chip for life. To share, RK would have to pick one of the OptiStick keys, and each choice has a cost:
| If RK uses | How OptiStick uses it today | What happens |
|---|---|---|
| A root key | Used once, when the keys were created | A key that should almost never be used would sign every RK release |
| The active level-2 key | Signs every OptiStick release | Even if OptiStick replaces it, it stays valid on RK forever and can never be retired |
| The spare level-2 key | A spare, with no day-to-day use | OptiStick has no clean spare left on the day it needs to replace a key |
- A problem in one product becomes a problem in both. If a shared key is leaked or misused, boot security is lost on both products together.
- The two products get tied together. The key cannot be deleted while any RK unit is in use, whatever OptiStick needs.
- A separate key costs almost nothing. It is one more HSM key, and the RK build already reads its key from a config file.
Worth noting
- The concern is not OptiStick firmware running on RK; the image formats are different. The concern is the damage if a key is leaked or misused, and that it cannot be replaced.
- Both products sign through the same service account. Once there are separate keys, that account's access also has to be split per key before the products are really separated.
- AVB is shared too, and it also cannot be changed after shipping. OTA can be changed, so it is less of a concern.
- Not yet confirmed: whether the RK3576 has a hardware way to revoke a key. Our current burn flow writes a single hash.
What needs to be done
- RECOMMENDEDCreate two RK production keys in HSM. Secure boot:
RSA_SIGN_PSS_4096_SHA256. TA:RSA_SIGN_PSS_2048_SHA256(the secure area has a fixed 2048-bit slot for the public key). - Limit signing access on these two RK keys to the RK release flow.
- Before mass production, decide whether RK should also get its own AVB key. It cannot be split after that. Splitting needs a tooling change and a reflash of RK test units.