How it is created — SDL-STD-025 Release Signing & Key Management

1. Why this artifact exists

The update mechanism rewrites the device's own trust anchor. Everything else in the lifecycle assumes that only you can produce an image the device will accept — secure boot, storage encryption, the whole vulnerability process. If that assumption fails, none of them mean anything, because the attacker ships the next version.

This is also the control with the shortest window to get right. Most of an SDL can be improved later: you can tighten a coding standard, add fuzzing, rewrite a policy. A key hierarchy is provisioned into devices at manufacture. The decision you make before the first production run is the one you live with for the whole support period, and the specific decision that matters — whether devices carry a second verification slot — determines whether a compromised key is an over-the-air recovery or a physical recall.

2. Inputs

• The silicon's capabilities: secure boot support, anti-rollback counters, how many verification slots the bootloader can hold. This constrains the design, so establish it during hardware selection, not after.
• Your update mechanism design: A/B slots, offline packages, what the companion tools verify.
• The product risk assessment entry for malicious firmware via the update channel — this standard is the design measure that answers it.
• Your release process, because signing has to attach to a gate that already exists rather than becoming a parallel one.
• Who can be a key custodian, and how many of them you actually have. A three-of-five scheme needs five people who will still be reachable in five years.

3. Steps

1. Separate the root from the signing keys. The root signs keys, never images, and lives offline. Devices trust the root, so rotating a product-line key never requires touching the field.
2. Provision a second verification slot from the first production unit. This is the decision that cannot be retrofitted, and it is the entire difference between recovering from a key compromise remotely and recalling hardware. Write it as a rule, not a recommendation.
3. State that private keys never leave the HSM — not for backup, not for a hotfix, not for a developer's machine. Signing becomes a service call; possession is never transferred. This one sentence removes most of the ways keys actually leak.
4. Make development and production distinct trust anchors, and verify on a production-fused unit at the release gate that a development signature is rejected. Otherwise this is an assumption, and it is the assumption that fails quietly.
5. Write signing as an authorisation with two named roles. The requester submits the digest; a different person verifies that the digest matches the pipeline artifact and that the release gate is complete, then authorises. Enforce the separation in the signing service — a rule that depends on people remembering it does not survive a bad week.
6. Close the emergency path explicitly. Emergency releases shorten the queue, not the control. A one-person signing path that exists "for urgent cases" is the path an attacker will aim for, precisely because it is available on your worst day.
7. Produce a ceremony record per signature: digest, version, requester, approver, timestamp, key ID, dossier reference. Written at signing time. A record reconstructed afterwards proves the paperwork, not the control.
8. Exercise the backup restore annually. An M-of-N backup nobody has ever restored is an assumption with custodians. Put the exercise on the calendar and record the result.
9. Write the compromise response as steps, and let either custodian stop signing alone. Stopping must never be a four-eyes decision — the whole point is speed. Resuming is.
10. Treat a suspected key compromise as a severe incident under your vulnerability process, including the regulatory reporting assessment. A signing key in an attacker's hands meets the malicious-code criterion once it is used, and the clock will not wait for you to finish deciding whether it counts.

4. Done when

• The key hierarchy is documented, and the root's only job is signing other keys.
• Devices carry two verification slots, and rotation does not depend on the field taking an update first.
• Private keys are non-exportable, and no procedure in the document contemplates moving one.
• Signing requires two different people, enforced by the service, with no exempt path.
• Every release has a ceremony record filed in its dossier.
• The backup restore has actually been performed and recorded within the last year.
• The compromise response names who can stop signing, and stopping takes one person.

5. Common mistakes

Shipping devices with a single verification slot, which converts a key compromise into a recall. Keeping a copy of the signing key "for emergencies" — that copy is the compromise. Letting the release engineer sign their own build because the approver is on holiday. Ceremony records written the following week. Backups that have never been restored. And treating a suspected key compromise as an IT incident rather than a product-security one, which is how the reporting clock gets missed while everyone is busy rotating credentials.

6. In TRA Studio

Update integrity is one of the essential requirements that is easiest to mark as covered and hardest to evidence, because the evidence is operational rather than architectural — ceremony records, a tested backup, a rejected development signature on a production unit. When you assign the update-mechanism requirements to activities in your lifecycle, assign them to the release activities that actually produce those records. A requirement mapped to "we sign our firmware" is mapped to a design intention; mapped to the signing step, it inherits an owner and a per-release artifact.