Keys and Key Lifecycle
SPsec works with a small, ordered family of symmetric keys. Each has a defined trust level, a defined writer and a defined moment in the device lifecycle.
The Key Hierarchy
From the network root of trust down to the keys that protect everyday traffic, each key has one job and one writer:
- Commissioning Marker. Not a secret key in itself, but an all-zero placeholder value used only to open an unsecured session for the very first provisioning step.
- Provisioning Key. Device-specific, written once by the manufacturer. It exists only to install the Integrator Key in a trusted environment.
- Integrator Key. The integrator's root of trust for the network. Installed once when the device is taken into service; it may be unique per device or shared across the network. It authorizes installing the Seed Key and writing most registers.
- Seed Key. The shared base from which the working keys are derived. Pre-shared across all participants and updated each maintenance cycle.
- Communication Keys (odd and even). The keys that actually protect data-plane traffic. They are derived automatically from the Seed Key; two are live at once so a frame sent either side of a roll-over stays verifiable.
- Session Key. A short-lived key derived for a single Configurator session and discarded when the session ends.
- Parameter Authentication Key. A one-shot key that authenticates a single value, typically the synchronized timestamp a participant needs at startup.
From Manufacture to Maintenance
The keys appear in a fixed order across the device lifecycle. The manufacturer writes the Provisioning Key; the integrator uses it to install the Integrator Key when the device enters service; the Integrator Key then installs the Seed Key, which is refreshed at every maintenance session. The short-lived Session and Parameter Authentication keys are derived on demand and never stored. Keys are never read back out of a participant: to audit which key is loaded, a Configurator reads an opaque Key ID that points to the secret in a separate key database, so the secret itself never appears on the bus.
Automatic Key Rotation
The data-plane Communication Keys refresh themselves without
any handshake. They are re-derived from the Seed Key whenever
a defined bit of the synchronized timestamp advances, and the
odd and even keys alternate so a receiver can still verify a
frame sent either side of a roll-over. A fresh working key
therefore rolls in during full operation with no slowdown and
no added delay.
The exact trigger bit and interval are fixed by the network
mapping; see SPsec on CAN FD.
Frequently Asked Questions
How many keys does SPsec use?
A small hierarchy, opened by a Commissioning Marker for first provisioning: a device Provisioning key, the Integrator key as the network root of trust, the Seed key, the derived Communication keys that protect data-plane traffic, and the short-lived Session and Parameter Authentication keys.
Can a key be read back from a device?
No. Keys are never read back. To check which key is loaded, a Configurator reads an opaque Key ID that identifies the secret in a separate database, so the secret never appears on the bus.