Cryptographic Primitives
SPsec is deliberately conservative about cryptography: two primitives, a key derivation function and an AEAD construction, do the work.
Key Derivation
SPsec derives the keys it uses at runtime from longer-lived base keys with an HKDF-compatible key derivation function based on SHA-256. Each derivation takes a base key plus a salt and produces a key of the requested size. Two derivations matter in practice: a fresh Session Key is derived from a pre-shared key and the random values exchanged in a session Hello, and the data-plane Communication Keys are rolled out of the Seed Key with a salt taken from the synchronized timestamp. Because the derivation is deterministic, every participant that holds the Seed Key produces the same Communication Key without ever exchanging it on the bus. The keys themselves and their lifecycle are described under Keys and Key Lifecycle; the hardware that stores and generates them under Hardware Requirements.
Authenticated Encryption (AEAD)
The workhorse of the data plane is an AEAD primitive, which authenticates and optionally encrypts a payload together with its associated header fields in one operation. SPsec admits three constructions, chosen once per network so every device agrees: AES-GCM with a 128-bit or 256-bit key, ChaCha20-Poly1305 with a 256-bit key or ASCON-128 with a 128-bit key. All are configured for a 64-bit authentication tag. The nonce is built from the uniqueness value (the synchronized timestamp on a group, or a counter on a point-to-point link) combined with the CAN ID of the protected frame, padded from the key's pre-shared salt when more bits are needed; that construction guarantees two participants transmitting on the same tick still produce different nonces. When confidentiality is not required, the payload is passed as associated data, so it stays readable on the wire while remaining tamper-evident.
A network selects one AEAD construction at design time, and every device agrees on it. All three carry a 64-bit authentication tag:
AES-GCM
Block-cipher AEAD with hardware acceleration on many controllers.
ChaCha20-Poly1305
Stream-cipher AEAD with high throughput in software where no AES accelerator is present.
ASCON-128
The NIST lightweight selection, sized for the smallest constrained nodes.
Security at a Glance
The table below consolidates the properties a security reviewer or an integrator needs to weigh SPsec against a risk assessment or a regulation such as the EU Cyber Resilience Act or IEC 62443. It states what the sublayer protects and, just as usefully, the boundaries an integrator has to design around. The key material and the hardware behind these rows are covered under Keys and Key Lifecycle and Hardware Requirements.
| Property | CANcrypt V2 on CAN FD | What a reviewer should note |
|---|---|---|
| What the sublayer protects | ||
| Per-frame authentication | AEAD tag on every secured frame | One altered bit rejects that single frame; there is no batched or coarse-grained check. |
| Confidentiality | Optional, one setting per network: authenticate, or authenticate and encrypt | The CAN ID and the frame timing stay visible even when the payload is encrypted, so traffic analysis remains possible. |
| AEAD constructions | AES-GCM (128 or 256-bit), ChaCha20-Poly1305 (256-bit) or ASCON-128 (128-bit) | Fixed per network and not negotiated on the bus, so there is no downgrade path to attack. |
| Authentication tag | 64 bits | Sized to the frame budget; automatic key rotation bounds how much traffic any one key ever protects. |
| Key sizes and derivation | 128-bit or 256-bit keys, HKDF-SHA-256 key derivation | Communication and session keys are derived on both sides and never travel on the bus. |
| Replay protection | 64-bit synchronized 0.1 ms timestamp (groups) or 32-bit random-seeded counter (1:1) | The Sync Role advances the timestamp and is responsible for never repeating it; bound into every frame, that value makes a replayed frame no longer match the current time. |
| Nonce uniqueness | Timestamp combined with the frame CAN ID and the key salt | Two nodes transmitting on the same tick still produce different nonces, so an AEAD nonce is never reused. |
| Boundaries an integrator must design around | ||
| Source authentication | Group-level inside a secure group; true 1:1 in the session mode | A shared group key means any group member can transmit as any other. Use the 1:1 session mode where a device identity must be proven. |
| Forward secrecy | Not provided | Communication keys derive from a fixed Seed Key, so a Seed compromise exposes past and future traffic. Roll the Seed Key at maintenance. |
| Node revocation | No revocation list; a node is removed by rolling the Seed Key | A missing Secure Heartbeat marks a node as gone, and its frames are then ignored. |
| Hardware root of trust | Secure key storage and a true random generator required | Without both, the reachable security level is limited, as the specification itself states. |
| Availability | Not a goal of the sublayer | Cryptography cannot stop bus flooding; pair SPsec with bus-load and anomaly monitoring. |
| Compromised node | Outside the trust boundary | A node running attacker code has already surrendered its keys; the sublayer cannot vouch for traffic that node authors. |
Frequently Asked Questions
Does frame protection prove which node sent a frame?
Within a secure group every member shares one Communication Key, so protection is group-level: a receiver can prove a frame came from the group, not which member produced it. Where a device identity must be proven, SPsec provides a 1:1 session mode keyed to a device-specific key.
Which cryptographic primitives does SPsec use?
Two: an HKDF-compatible key derivation function based on SHA-256, and an AEAD construction. The concrete AEAD is selected per network from AES-GCM, ChaCha20-Poly1305 or ASCON-128, all with a 64-bit authentication tag.
Can a payload be authenticated without being encrypted?
Yes. AEAD supports an authenticated-only mode: the payload is passed as associated data, so it stays readable on the wire but any change to it is detected.