Cryptographic Key Management

Purpose

Define generation, storage, rotation, revocation, and provisioning of cryptographic keys for medical devices, supporting secure boot, OTA, and comms.

When to Apply

• •Any feature using crypto keys (identity, TLS, signing, storage encryption).
• •Manufacturing provisioning and field updates.

Requirements (testable)

1. •Key Generation: Use secure RNG; generate offline for signing roots; on-device keys generated with TRNG and protected storage. Rationale: entropy and control.
2. •Storage: Protect private keys in secure element/TPM or sealed storage; separate code/data privileges; no plaintext keys. Rationale: prevent extraction.
3. •Rotation: Support key rotation for device credentials and signing keys; define processes and grace periods. Rationale: limit exposure window.
4. •Revocation: Support revocation lists or status checks (OCSP/CRL/pinned rotation) for server and device certs. Rationale: remove compromised keys.
5. •Injection/Provisioning: Secure manufacturing key injection with audit trails; no reuse of device keys across units. Rationale: uniqueness and traceability.
6. •Backup/Escrow: Avoid escrow of signing keys; if operational keys need backup, encrypt and control access with least privilege. Rationale: minimize insider risk.
7. •Separation of Duties: Keep signing keys offline; use intermediate for production signing; limit personnel access. Rationale: reduce key misuse.

Recommended Practices

• •Use short-lived device certificates; renew automatically before expiry.
• •Pinning with rotation: maintain old+new pins during transition.
• •Wipe keys on device decommission or secure reset.
• •Document key lifecycle in a key management policy.

Patterns

Key derivation for per-session keys:

// REQ-KEY-KDF-01; TEST-KEY-04
hkdf_sha256(master_key, salt, info, session_key, 32);

Provisioning record (YAML):

# REQ-KEY-PROV-02
device_id: DEV12345
keys:
  identity_cert: sha256:abcd...
  bootstrap_ca: sha256:1234...
date: 2026-01-04
operator: line-3

Revocation check (pseudo):

// REQ-KEY-REV-03; TEST-KEY-07
if (cert_is_revoked(peer_cert) || expired(peer_cert)) {
    reject_connection();
}

Anti-Patterns (risks)

• •Shared device keys across fleet -> risk: systemic compromise.
• •Plaintext private keys in flash -> risk: easy extraction.
• •No rotation path -> risk: long-lived compromise.
• •Root signing key online -> risk: theft/unauthorized signing.

Verification Checklist

• • Keys generated with secure RNG; roots offline; device keys unique.
• • Private keys stored in secure hardware or sealed storage; not plaintext.
• • Rotation supported and tested; transition periods defined.
• • Revocation supported (CRL/OCSP/pins); rejection on revoked/expired.
• • Manufacturing provisioning secure; audit trail kept; no shared keys.
• • Key lifecycle documented; separation of duties enforced for signing keys.

Traceability

• •Requirements REQ-KEY-### to tests TEST-KEY-###; link to secure boot/OTA/auth requirements.
• •Provisioning and rotation events logged with IDs and timestamps.

References

• •NIST SP 800-57 (key management).
• •NIST SP 800-132 (password-based KDF); 800-56 for key agreement.
• •FIPS 140-2/3 for module considerations when required.

Changelog

• •1.0.0 (2026-01-04): Initial key management skill covering generation, storage, rotation, and revocation.

Audit History

• •2026-01-04: Audit performed. Verified:
  • •NIST SP 800-57 (key management) correctly referenced
  • •NIST SP 800-132 (password-based KDF) and 800-56 (key agreement) appropriate
  • •FIPS 140-2/3 considerations correctly noted for applicable environments