Comparison of CAN Link-Layer Security Options
Three approaches to securing small-packet fieldbus communication, side by side: the original CANcrypt, CANcrypt V2 on the SPsec sublayer and the CiA work item CANsec.
Where Security Sits on a Fieldbus
Fieldbus systems rarely afford the luxury of stacking
security at every network layer. In practice, two placements
dominate. The first is at the highest layers, where
established higher-layer protocols such as TLS variants can be
tunneled through the fieldbus, inheriting their security
guarantees end-to-end. The second is at the link layer, where
security is introduced as a sublayer directly above the data
link layer, protecting every addressed data unit on the bus.
This page compares the link-layer answers available on the
small-packet networks CANcrypt and CANsec address. For the
role link-layer frame security plays within a complete
defensive architecture, see the CAN Security Reference at
Frame Security.
Reading the CANsec Column
CiA 613-2 (CANsec) is in active development at the time of
writing this information. The design philosophy behind it is
to reuse IEEE 802.1AE / MACsec primitives as much as possible,
which fits cleanly when the underlying network is CAN XL with
its 2048-byte frames. On CAN FD, the same approach forces MKA
control-plane messages and other Ethernet-sized constructs to
be fragmented across many 64-byte frames, which limits
practicability. Cells in the CANsec column marked tbd.
(control plane) refer to behavior the forthcoming CiA
613-2 control-plane document might define.
Side by Side
| Property | CANcrypt V1 | CANcrypt V2 / SPsec | CANsec (CiA 613-2) |
|---|---|---|---|
| Status | Established (book + product since 2016) | Specification family published 2025; product available | Under review / definition |
| Standardization | EmSA proprietary (open documentation in book) | Published SPsec spec family, open source | CiA specification, in development |
| Primary network | Classical CAN, secondary CAN FD | CAN FD (Classical CAN with limitations) | CAN XL, CAN FD under consideration |
| Position in stack | Security sublayer directly above the Data Link Layer | Security sublayer directly above the Data Link Layer | Data Link-layer security |
| Crypto | |||
| Authentication | AES-based MAC or custom | AEAD tag, 64-bit (48-bit on classical CAN) | Yes (under definition) |
| Confidentiality | Optional, AES | Enable/disable through AEAD | Optional (under definition) |
| AEAD construction | n/a (separate authentication and encryption) | AES-GCM-128, AES-GCM-256, ChaCha20-Poly1305-256 or ASCON-128 | MACsec primitives (AES-GCM for AEAD, AES-GMAC for auth-only) |
| Symmetric key size | Custom | 128-bit (ASCON or AES-GCM) or 256-bit (AES-GCM or ChaCha) | AES-128 or AES-256 (via MACsec) |
| Key derivation function | Pre-shared + RNG exchange to derive session key | HKDF-SHA256 | tbd. (control plane) |
| Key management lifecycle | |||
| Initial provisioning | Integrator loads pre-shared pairing/group keys | Factory-installed Provisioning Key, then Integrator Key installed at commissioning over a Provisioning-Key-protected channel | tbd. (control plane) |
| Operational key install in the field | Re-pairing | SPsec Session (TLS-PSK-style, stripped down) writes parameter registers, including the Seed Key; one-shot Parameter Authentication authenticates single values | tbd. (control plane) |
| Rotation during operation | Per pairing / per session | Automatic: odd/even Communication Keys re-derive from Seed Key on timestamp-bit toggle, no handshake required | Planned: Per Secure Association, MKA-driven, limited practicability on CAN FD |
| Key hierarchy / priority tiers | Single tier of pre-shared keys, plus session keys derived from them | Four explicit tiers, each with a different role and lifetime: Provisioning Key, Integrator Key, Seed Key, Session & Communication Key | Inherited from MACsec: CAK (Connectivity Association Key) to SAK (Secure Association Key) per SA |
| Security contexts | |||
| Contexts required per network | One per pair (pairing) or one per group (grouping) | One context per secure group, single shared Communication Key plus shared uniqueness covers entire group (Multi-Participant Grouping) | One per Secure transmission Channel |
| Group / multicast model | Pairing or grouping | Secure Session & Multi-Participant Grouping | MACsec Connectivity Association, members share a CAK, each transmitter runs one or more Secure Channels |
| Liveness detection | Secure Heartbeat | Secure Heartbeat | Not planned |
| Practical limits at scale | |||
| Coverage of bus traffic (HW economy) | Maximum of 16 Participants in a group | Every frame exchanged can be protected | Hardware supports a finite number of secure channels |
| Receiver-side state per source | Per-pair / per-group state on each side | One shared Communication Key plus one global synchronized timestamp covers all secure communication | Receiver maintains per-channel state: keys, freshness window, replay window (limited scaling) |
| Replay protection at system scale | Secure heartbeat uses input from all participants, strong replay protection | 64-bit synchronized timestamp is the freshness for the whole group, authenticated upon init, strong replay protection | Per-channel 32-bit Packet Number (PN) counter. Counter initialization, persistence across power cycles and recovery after counter loss are tbd. in control plane spec, which is where system-scale replay hardness actually lives |
| Footprint | |||
| Per-frame overhead | Separate authentication frames | 10-byte Security Stamp in the data field and 18 bit in CAN ID (extended from 11 bit to 29 bit) | Part of the frame definition, does not require portions of CAN ID or data field |
| Max user payload after security | 8 bytes on Classical CAN but additional security frame required | 56 of 64 bytes on CAN FD (or 48 if next-smaller DLC is preferred) | 2000+ on CAN XL, 64 bytes on CAN FD (planned) |
| Coexists with existing higher layers | CANopen CC | CANopen FD | CAN XL upper-layer protocols, MACsec-aware applications |
| Safety integration | |||
| Combination with functional safety | Application-level, the application owns both safety wrapping and security overlay | Extension of Security Stamp to 16-byte would allow adding counter and 32-bit CRC | Unknown |
| Standards / regulatory | |||
| EU CRA / IEC 62443 framing | Pre-CRA design | Explicitly framed as the CRA / IEC 62443 answer for small-packet networks | Unknown |
Frequently Asked Questions
How does SPsec differ from CANsec (CiA 613-2)?
CANsec reuses IEEE 802.1AE / MACsec primitives, which fit CAN XL but force Ethernet-sized constructs to be fragmented across many 64-byte frames on CAN FD. SPsec is designed for the small-packet budget from the start.
Where does link-layer security sit on a fieldbus?
As a sublayer directly above the data link layer, protecting every addressed data unit. The alternative placement is tunneling a higher-layer protocol such as TLS end-to-end.