Frame Security
The preventive shell at the heart of defense in depth: cryptographic frame protection is the only mitigation that can outright prevent frame injection and spoofing attacks rather than just detect them. On CAN, the primary security goal is authentication: receivers need a way to verify that a frame really came from the node that claims to have sent it. Some deployments may additionally require confidentiality, for example when payloads carry sensitive operating data, calibration values, commercial recipes or other intellectual property. The same AEAD primitives that authenticate frames provide that confidentiality from a single key and nonce: AES-128-GCM and the SPsec construction both produce an authenticated and, where configured, encrypted frame in one step. This page covers the principal building blocks to protect selected or all frames. For application-layer cryptographic protection of selected Object Dictionary entries (as opposed to per-frame protection), see Secure Object Fieldbus Access (SOFA). SR 3.1 SR 4.1 SR 4.3
Why Cryptography Is Challenging on CAN
Three constraints shape every design. Payload size: 8 bytes on classical CAN leaves almost no room for an authentication tag. Real-time: cryptographic processing must fit within the per-frame budget without breaking control loops. Resources: many CAN nodes are highly constrained microcontrollers with no hardware AES. Where you control the silicon choice, a part with an on-chip AES accelerator and a hardware random number generator removes the resource constraint and greatly speeds up the per-frame calculations. The Secure CAN MCUs page lists CAN FD families that pair the interface with these hardware security features, and the MCU Crypto Benchmarks page reports what each primitive costs in flash, stack, and time on them. The schemes covered below address these constraints differently.
CANcrypt 1.0: Scalable Frame Authentication for CAN/CANopen
CANcrypt 1.0 is a scalable authentication and encryption layer for classical CAN. It supports configurable trade-offs between bandwidth, latency, and cryptographic strength, and integrates with CANopen and other higher-layer protocols. It supports a total of up to 16 nodes participating in secure communication and uses an extra security frame for each secured data frame. The CANcrypt book and reference implementation document the protocol in full.
SPsec: Security Sublayer for CAN FD (CANcrypt 2.0)
SPsec is a security sublayer specification designed for "small packet networks". It uses the upper 12 bytes of the 64-byte payload to carry the security overhead. This provides authenticated, encrypted data with AES-128-GCM for ALL frames exchanged. It supports N:N messaging, and is designed for integration with CANopen FD. It includes key management primitives for key provisioning and automatic key re-fresh during regular operation. SPsec was developed jointly with University Offenburg.
CANsec: Potential Future Option for CAN XL and CAN FD
CANsec is a cryptographic security extension defined for the CAN XL data-link layer. It adds frame-level authentication and optional confidentiality to CAN XL, in a role analogous to MACsec for Ethernet. The construction is AES-GCM based and operates on the CAN XL frame, not on application-layer objects. The specification is currently under definition; once published, CANsec will be a potential future option for per-frame protection on CAN XL and CAN FD networks
Node Authentication with Frame Security
When all frames are protected, this also includes frames with device identification information. While this ensures authenticity on a group level, it does not provide true end to end assurance. Where that is essential, device identification needs to be verified using a device specific key, not a group shared key. Both CANcrypt V2.0 / SPsec and SOFA provide 1:1 security communication modes.
Replay Protection and Nonce Management
Authentication proves a frame is genuine; it does not by itself prove the frame is fresh. Without a freshness input, a valid frame captured off the bus can be re-injected later and will still verify. The schemes here close that gap in two different ways, matched to how each one communicates. CANcrypt 2.0 / SPsec binds every protected frame to a synchronized 64-bit timer that all participating nodes advance in step, so a frame is accepted only against the current time value and a captured frame no longer matches once the timer has moved on; at 64 bits that value does not wrap within any practical device lifetime. SOFA, which secures individual application-layer accesses rather than a continuous frame stream, derives its freshness from a combination of a random input established in the challenge/response and a counter, so each protected access is bound to a value the receiver has not accepted before. In either case the receiver rejects a frame or access whose freshness value it has already seen or that falls outside its accepted window.
The same freshness state serves a second, mandatory purpose. AES-128-GCM requires a unique nonce for every message encrypted under a given key; reusing a nonce under one key breaks both the confidentiality and the authentication of GCM. The synchronized timer in SPsec and the random-plus-counter input in SOFA supply that uniqueness, together with a per-node identifier, and periodic key refresh bounds how long any single key is used. A deployment that fixes a key must still guarantee the nonce never repeats under it, which is the practical reason these schemes advance a shared timer or refresh keys rather than run one static key indefinitely.
Choosing Between CANcrypt 1.0, SPsec, and SOFA
Per-frame protection on classical CAN with limited payload:
CANcrypt 1.0. Per-frame protection on CAN FD with full
security at the network layer: CANcrypt 2.0 / SPsec. Future
per-frame protection on CAN XL once the specification is
published: CANsec. Application-layer protection for selected
Object Dictionary entries on any of these: SOFA.
What This Shell Does Not Catch
Cryptographic frame authentication only holds while the keys hold. An attacker who extracts PSK material from a compromised node, a debug interface, or a poorly protected firmware image bypasses the entire shell. Frame authentication also does not help against bus flooding; the attacker does not need valid frames to occupy the medium. Pair this shell with Bus Load Monitoring for flood detection and with Anomaly Event Monitoring for cross-bus correlation.
Frequently Asked Questions
What is the difference between CANcrypt and SPsec?
CANcrypt is the original scalable authentication and encryption layer designed for classical CAN/CANopen with limited payload. SPsec (CANcrypt 2.0) is its CAN FD-focused successor, a security sublayer specification co-developed with University Offenburg and CiA's HLP Security SIG.
Can classical CAN frames be encrypted?
Authenticated encryption inside a single classical CAN frame is impractical because of the 8-byte payload. CANcrypt provides scalable authentication (and a form of confidentiality across multiple frames). True per-frame authenticated encryption is much more practical on CAN FD via SPsec.
What cryptographic algorithm is recommended for CAN frame authentication?
AES-128-GCM is the AEAD primitive used by SPsec for CAN FD frame authentication and by Secure Object Fieldbus Access (SOFA) at the application layer. It is recommended by BSI TR-02102, provides authenticated encryption, and is widely supported on modern microcontrollers.
How does node authentication work on a CAN network?
Node authentication uses an authentication key (system-specific: typically the Provisioning Key or the Update Key, depending on the deployment) and a challenge/response exchange: the verifier sends a nonce, the device responds with a MAC over the nonce computed with the authentication key. This proves possession of the key without transmitting it.