Symmetric Key Management
Symmetric key management is the lower-burden path for most CAN and CAN FD products, and it is where the day-to-day discipline lives. The cryptography is light; the work is in giving every device its own key, deciding whether to store or derive those keys, and running the rotation and revocation cycles that keep a fleet healthy. This page lays out the approaches at a framework level so you can match one to your deployment.
Before You Diversify, Ask What the Key Is For
Whether every device needs its own symmetric key depends on what the key is for, so start with purpose rather than with a rule. Two questions settle most of it. Is this the only key on the device, carrying identity, firmware protection, and session traffic at once? If not, are firmware protection and device identification handled by separate keys? A key that is the sole means of trust, and whose job is to tell one device from another, has to be unique per device, because a single shared value would let one extracted secret stand in for the whole fleet. A key whose only job is to protect a firmware image for a product family does not carry that requirement, because it is not what distinguishes one unit from the next.
Per-device diversification is therefore core in one specific case, when the key identifies and authenticates the individual device. IEC 62443-4-2 makes the same point from the compliance side, treating the authentication requirement as met when the secret that carries identity is diversified per device. The sections below follow that order: decide what each key is for, diversify the keys that carry identity, and let a firmware or family key stay common where its purpose calls for it. IEC 62443-4-2
One Root, Two Kinds of Key
The decision to diversify does not force a separately stored key for every purpose. One root key can produce both kinds at once, because the derivation input decides what comes out. Feed in a device serial number and the root yields a per-device key that identifies and authenticates that one unit. Feed in a fixed string that names a firmware version or a product family and the same root yields a firmware protection key shared across that family. Both come from the one root, differing only in the input mixed in.
A label bound into each derivation keeps the two purposes cryptographically separate, so the identity key and the firmware key can never stand in for one another even though they share a parent. A single stored secret therefore answers the opening question two ways at once: unique where the key carries identity, common where it protects a shared image. The mechanics of holding that one secret, and deriving the rest on demand, are the subject of the sections that follow.
Three Ways to Manage the Keys
| Approach | How It Works | Trade-Off | Potential Use Cases |
|---|---|---|---|
| Store Per-Device Keys | Generate a random key for each device and keep it in an integrator database, organized by serial. | Simplest to build, but the database becomes a crown jewel: a leak exposes every device it lists, and refreshing one device means rewriting its key. | Closed, low-Security-Level systems with tight database control, and small fleets where the database stays manageable. |
| Derive From a Root | Hold one root key in a small hardware module and derive each device key on demand from public inputs such as the serial and a key-revision counter. | No per-device database, a leak exposes no secrets, and refreshing a device is a counter bump, but the root must be backed up. | Most CAN and CAN FD fleets meeting the SL2 baseline with low maintenance, and larger fleets where a key database would be a liability. |
| Add an Asymmetric Governance Layer | Keep the derived-from-root scheme and place a lightweight asymmetric trust anchor above the root to sign which root generation is current. | Adds the ability to revoke a root generation and to check currency, which pure symmetric derivation cannot do, at the cost of a signing trust anchor to protect. | Deployments that must revoke a root generation or verify currency, and systems that combine symmetric efficiency with governed authority. |
The derivation in the second and third options uses a standard key-derivation function, with HKDF (specified in RFC 5869) the usual choice, fed with values that are not secret. The technique of deriving many keys from one root and tracking generations has long-standing prior art in ANSI X9.24-3, the DUKPT (Derived Unique Key Per Transaction) scheme from the payments world. The lifecycle discipline around all of this, generation, rotation, and destruction, follows NIST SP 800-57. RFC 5869 ANSI X9.24-3 NIST SP 800-57
Producing Many Keys From Bounded Secure Storage
Deriving keys from one root removes most per-key storage, yet two storage questions remain. Where is the root itself held, and what happens when a program needs several base keys, one per product line or one per security domain, rather than a single one? A hardware security module protects what it holds, yet it holds only a handful of slots. Storing every base key in a secure database can seem the appropriate answer at first glance, yet there are better ones that keep secure storage constant no matter how many base keys the program uses.
Derive a Key Ladder
Hold one root in the module and derive every working key beneath it on demand, so only the root occupies secure storage and everything else is recomputed when it is needed. As the section above describes, the derivation input sets the purpose: a serial yields a per-device identity key, a firmware or family label yields a shared firmware key. Extending the same idea, the root can derive base keys as an intermediate tier, one per product line or purpose, and those base keys derive the working keys beneath them, so a whole program of keys reduces to one stored secret. NIST SP 800-108 defines the counter-mode derivation this uses. NIST SP 800-108
Wrap Keys for External Storage
When the individual keys must be independent random values rather than branches of one root, keep a single key-encryption key in the module and store each key encrypted under it in ordinary storage. The module unwraps a key only at the moment it is used, so secure storage holds one key-encryption key however many keys exist. AES key wrap is the standard construction. The trade against a ladder is that the wrapped material is the only copy, so it must be backed up. NIST SP 800-38F
The following animation illustrates how symmetric keys can be managed by the manufacturer using USB-HSMs (Hardware Security Modules):
backups
Root key
Development and Test Base Key
Production Base Key
ID:011001…
ID:011010…
The symmetric key management described here can be used in a similar fashion on the integrator level. The following cryptographic solutions depend on such symmetric keys:
- Frame Security authenticates each frame on the bus.
- Secure Object Fieldbus Access protects object-level reads and writes.
- Secure Bootloader authenticates firmware updates.
Rolling, Rotation, Refresh, and Revocation
A symmetric deployment is not finished when the keys are provisioned; it runs for the life of the fleet. Four mechanisms keep it healthy, and it pays to keep them distinct, because the first two sound alike yet differ in which key they touch and how often:
Rolling
The short-lived session key changes automatically on a fixed time base, with no human action. SPsec, for example, rolls the session key continuously this way, so the key protecting traffic is never the same for long. Rolling limits how much data any single key ever protects, and it is part of normal running rather than maintenance.
Rotation
The longer-lived operational or root key is replaced on a planned schedule, far less often than the session key rolls. Where rolling is continuous and automatic, rotation is deliberate and policy-driven. It is the periodic re-keying of the keys that persist across sessions and that the rolling layer is derived from.
Refresh
An operational key is replaced on demand, for hygiene or after a suspected exposure. With a derived scheme this is a key-revision bump that the device re-derives from; with a stored scheme it is a rewrite plus a database update.
Revoke
Authority is withdrawn after a credential is compromised. Where an asymmetric governance layer is present, a technician or operator grant can be denied without re-keying devices; in a pure stored or derived scheme, revocation means refreshing the affected devices.
One more obligation closes the lifecycle. IEC 62443-4-2 CR 4.2 requires that key material be zeroized, that is, purged so it cannot be recovered, when a device is reset, decommissioned, or has its storage released. Key destruction is as much a part of symmetric key management as key creation, and it is easy to forget until an audit asks for it. CR 4.2
Frequently Asked Questions
Does every device need its own symmetric key?
It depends on what the key is for. A key that identifies and authenticates the individual device has to be unique per device, because it is what tells one unit from another and one extracted secret would otherwise stand in for the whole fleet. A key whose only job is to protect a firmware image for a product family does not need per-device diversification, because it does not distinguish one unit from the next. IEC 62443-4-2 treats the authentication requirement as met when the secret that carries identity is diversified per device, so per-device keys are the baseline for identity even where a shared firmware key is acceptable.
Can one root key both protect firmware and identify devices?
Yes. One root can derive both kinds of key, because the derivation input sets the purpose. A device serial number yields a per-device identity key unique to that unit, and a fixed firmware or family label yields a firmware protection key shared across the family. A label bound into each derivation keeps the two cryptographically separate, so neither can stand in for the other.
Is it better to store per-device keys or derive them from a root?
Deriving from a root held in a small hardware module usually wins for maintenance. There is no per-device key database to protect, a database leak exposes no secrets because the derivation inputs are public, and a single device can be refreshed by bumping its key-revision counter. The trade is that the root must be backed up, since its loss means the fleet's keys can no longer be derived.