SDL-STD-025 — Release Signing & Key Management

1. Why signing is a standard and not a build step

The update mechanism is the most powerful interface an embedded product has: it rewrites the device's own trust anchor. Every other control in the SDL is downstream of the assumption that only ACME can produce an image the device will accept. If that assumption fails, secure boot, at-rest encryption and the CVD process are all decorative.

The threat is scored in the product risk assessments — for the S300 it is R-02, "malicious firmware installed via update channel", impact 4. This standard is the design measure that answers it.

2. Key hierarchy

Rules that follow from the hierarchy:

1. Private keys never leave the HSM. Not for backup, not for a hotfix, not for a developer's laptop. Signing is a service call; possession of the key is never transferred.
2. A device trusts the root, not the release key. Rotating a product-line key therefore does not require touching the field.
3. Devices carry two verification slots. The successor key is provisioned alongside the current one before rotation begins, so rotation never depends on every device having taken an update first.
4. Development keys and production keys are distinct trust anchors. A production-fused unit rejects development signatures; this is verified on a sample unit at the release gate (SDL-CHK-030).
5. Algorithms: ECDSA P-256 with SHA-256, or Ed25519. Signature format and the key identifier are carried in the image header so that verification is unambiguous when two slots are populated.

3. Four-eyes release signing

Signing is an authorisation decision, not a build artifact.

1. The release requester (DevOps) submits the image digest, the version, the branch and the release dossier reference to the signing service.
2. The release approver — PSL, or the Managing Director in the PSL's absence — verifies that the digest matches the artifact produced by the release pipeline, that the release gate record (SDL-PROC-001 #3.7) is complete, and that the advisory for any security content is drafted. The approver then authorises the signature.
3. Requester and approver must be different people. The signing service enforces this; it is not a procedural expectation.
4. Each signature produces a signing ceremony record: digest, version, requester, approver, timestamp, key identifier, and the dossier reference. The record is filed in the release dossier (REL-DOS-YYYY-NNN).

Emergency releases do not bypass this. An emergency-class fix under PSM-PROC-002 §3 shortens the queue, not the control: the approver may be reached out of hours per the on-call rule, and the ceremony record is completed at the time of signing, not reconstructed afterwards. A signing path that can be used by one person under time pressure is the path an attacker will aim for, because it is the one that exists on the worst day.

4. Device-side verification

1. Signature verified before installation, against a key in a verification slot chained to the root. An image that fails verification is discarded, not quarantined for retry.
2. Anti-rollback counters prevent downgrade to a version with known vulnerabilities. The counter increments on security releases; the increment is a deliberate release decision, recorded in the dossier, because it is irreversible in the field.
3. Power-fail safety: A/B slots; a failed update leaves the previous, verified image running. A failed update never leaves the device in a less secure state (SDL-STD-022 §3(4)).
4. Offline packages carry the same signature plus a published SHA-256 checksum, so air-gapped sites can verify before transfer as well as on the device.

5. Key ceremonies, backup and rotation

• Ceremony (root key generation, product-line key generation, rotation): two custodians plus a witness; scripted, logged, and recorded with the HSM audit log attached. Ceremony records are retained for the life of the key plus 10 years.
• Backup: HSM backup under M-of-N control (3 of 5 custodian shares), shares held in separate physical locations. Restore is exercised annually — an untested backup is an assumption. The exercise is recorded.
• Scheduled rotation: product-line keys every 5 years. The successor key is provisioned into the second verification slot at least one release cycle before it is first used to sign.
• Custodian change: on any departure or role change, shares are re-split and the HSM authentication credentials are replaced. Departure of a custodian is a rotation trigger for the credentials, not for the key.

6. Compromise response

A suspected compromise of a product-line release key is a severe incident and is handled under PSM-PROC-003, including the Art. 14 assessment — a signing key in an attacker's hands meets the "introduction of malicious code" criterion in Art. 14(5) once it is used.

1. Suspend signing with the affected key immediately; the signing service is disabled by either custodian acting alone. Stopping is not a four-eyes decision.
2. Assess exposure: which images were signed with it, and which are in the field.
3. Sign the successor key with the root; distribute an update signed by the successor, using the second verification slot already provisioned per §2(3).
4. Revoke the compromised key in the update service; devices that have taken the successor image no longer accept it.
5. Publish an advisory and notify users (PSM-PROC-003 P4.2, PT.5). Devices that cannot be reached remotely are handled as a field action with the customer.

Recovery depends entirely on the second slot existing beforehand. A single-slot device whose signing key is compromised cannot be recovered over the air; it is a physical recall. That is the reason §2(3) is a rule and not a recommendation.

7. Records

Signing ceremony records per release, key ceremony records, HSM audit logs, annual backup-restore exercise records, custodian roster and its change history, rotation plans, and compromise-response records. Filed with the release dossiers and retained 10 years after the last unit is placed on the market.

Revision history