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. 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 particpating 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 incliudes key management primitives for key provisioning and with 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.
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.