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.
Per-Device Diversification Is the Core Principle
Every device that must be individually trusted gets its own distinct symmetric key. This is not a refinement, it is the foundation. A unique per-device key gives each unit an identity and contains the blast radius: extracting the key from one device compromises that device, not the fleet. IEC 62443-4-2 makes the same point from the compliance side, treating the authentication requirement as met when the secret is diversified per device. A single shared fleet key fails both tests at once. IEC 62443-4-2
Given that starting point, the real decision is operational: where does each device's key come from, and where, if anywhere, is it kept after provisioning. There are three common answers, and they differ mainly in how much maintenance they impose and how they behave when something leaks.
Three Ways to Manage the Keys
Store Per-Device Keys
Generate a random key for each device and keep it in an integrator database, organized by serial. Simplest to build. The database becomes a crown jewel: a leak exposes every device it lists, and refreshing one device means rewriting its key and updating the record. Acceptable for closed, low-Security-Level systems with tight database control.
Derive From a Master
Hold one master 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. There is no per-device key database, a database leak exposes no secrets, and refreshing a device is a counter bump. The master must be backed up, because its loss means no key can be re-derived.
Add an Asymmetric Governance Layer
Keep the derived-from-master scheme, and place a lightweight asymmetric root above the master to sign records that say which master generation is current. This adds the ability to revoke a master generation and to check currency, the one thing pure symmetric derivation cannot do on its own. It unifies symmetric cheapness with asymmetric governance.
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 master 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
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 master 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
Why does every device need its own symmetric key?
Per-device diversification is what gives each device a unique identity and contains the damage from a single extracted key. If a whole fleet shared one key, recovering it from one device would compromise all of them. IEC 62443-4-2 treats the authentication requirement as satisfied when the secret is diversified per device, so unique per-device keys are both a security measure and a compliance baseline.
Is it better to store per-device keys or derive them from a master?
Deriving from a master 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 master must be backed up, since its loss means the fleet's keys can no longer be derived.