--- title: "CANcrypt V2 — Frame Security for CAN FD on SPsec Sublayer" canonical_url: "https://cancrypt.net/versions/v2/" description: "CANcrypt V2 brings authenticated encryption to every CAN and CAN FD frame, built on the SPsec security sublayer to close the EU Cyber Resilience Act gap." last_updated: "2026-07-13" --- # More Than Frame Security for CAN FD CANcrypt V2 is the next generation of authentication and encryption for CAN and CAN FD networks. It is built on SPsec, the security sublayer for small-packet networks. ## The Standards Gap CANcrypt V2 Fills The EU Cyber Resilience Act and standards such as IEC 62443 require that data in motion is authenticated and encrypted with strong, current cryptography. The CAN FD and CANopen FD standards have no published security specification of their own. CANcrypt V2 closes that gap. It applies the SPsec security sublayer to CAN FD, so machine builders can meet modern regulatory expectations without inventing security at the application layer. ## A Complete Security Infrastructure CANcrypt V2 does protect all frames: once a node enters the secure state, every CAN FD frame (in SPsec addressed data unit) it sends is authenticated and, when configured for full confidentiality, encrypted. The same mechanism covers process data, configuration access and the heartbeat that proves a node is still on the bus. CANcrypt V2 is also the security infrastructure around those frames, not frame protection alone. It defines a hierarchy of keys, from a manufacturer provisioning key down to the working keys that protect traffic, each with a defined trust level and a defined way to install it, so an integrator can take a device into service and assign its keys over a secured session. The cryptography itself is a choice: each network selects one AEAD construction, AES-GCM, ChaCha20-Poly1305 or ASCON-128, to match its devices. Working keys then refresh themselves. They are re-derived from the seed key on a fixed timer while the network keeps running, so a fresh key rolls in during full operation with no handshake, no slowdown and no added delay. [See how SPsec works →](https://cancrypt.net/spsec/) [Security at a glance: key sizes, replay protection and the boundaries to design around →](https://cancrypt.net/spsec/crypto/#security-at-a-glance) ## What Is Inside SPsec SPsec brings together a mixture of building blocks rather than a single technique: - **AEAD**: Authenticated Encryption with Associated Data: a single primitive that encrypts and authenticates the payload, plus any associated header fields, in one operation. - **Cryptographic method configurable**: Each network selects one AEAD construction at deployment (AES-GCM, ChaCha20-Poly1305 or ASCON-128). The spec does not lock you into a single cipher. - **Replay protection**: Captured frames cannot be re-injected later. Every secured frame carries a freshness value that receivers track to reject duplicates. - **Per-frame integrity**: Every secured frame is independently verifiable. One bit flipped means one frame rejected, with no batched or coarse-grained authentication. - **Configurable tag size**: The AEAD authentication tag length can be tuned to the underlying network: 64-bit on CAN FD, smaller on Classical CAN. - **Authenticated configuration**: Configuration writes such as key install or parameter changes are themselves authenticated, so an attacker cannot reconfigure a node by injecting messages. - **Authenticated time sync**: Time synchronization messages are authenticated, so an attacker cannot rewind or fast-forward a participant's clock to break replay protection. - **Open-source specification**: The full SPsec document family is published openly. Anyone can read it, review it and implement against it without licensing barriers. - **Network-independent sublayer**: SPsec is defined once at a generic level, then mapped to specific networks (CAN FD today, others later) without rewriting the core. - **Multi-Participant Grouping**: A secure group shares one Communication Key and one uniqueness value, so every participant can both send and receive secured traffic without per-pair state. - **Per-message authentication**: One of the supported postures: every selected message carries an authentication tag, so a receiver discards a manipulated frame before acting on its content. - **Secure Heartbeat**: Each participant in the secure state publishes an authenticated heartbeat at a fixed cycle. A missing heartbeat is itself a security event. - **SPsec Session (TLS-PSK style)**: A short, authenticated client-server exchange between a configurator and a participant, modeled on TLS-PSK but stripped down for small-packet networks. - **Parameter Authentication**: A one-shot authenticated exchange used to install or read a single value, such as the synchronized timestamp a participant needs at startup. - **Automatic key rotation, no handshake**: Working keys are rederived from the long-lived Seed Key on a defined timer. Both sides roll forward in lockstep without exchanging any messages. - **Key hierarchy**: Provisioning and integrator keys protect the network's seed key, which derives the working keys. Compromising one tier does not expose the others. - **EU CRA aligned**: SPsec is explicitly framed as the link-layer answer for products that need to meet the EU Cyber Resilience Act's authenticated-and-encrypted expectation. - **Synced time as uniqueness**: Replay protection uses a globally synchronized 100 µs timestamp rather than per-source counters, so receivers do not accumulate per-source replay state. - **Key provisioning methods included**: The spec defines the full lifecycle for installing keys at the factory and during commissioning, not just the cryptographic primitives. ## The Origins of SPsec SPsec began as a two-year research project announced in December 2023 by Embedded Systems Academy together with the Institute of Reliable Embedded Systems and Communication Electronics (ivESK) at Offenburg University, supported by a grant from the German Federal Ministry for Economic Affairs and Climate Action. The work carried the title *Inter-Layer Multi-Participant Security for Small-Packet Networks*, and its goal was a single security framework for resource-constrained networks such as CAN, CANopen, I2C and RS-485, where the frame is too short to carry the security overhead that internet protocols take for granted. The approach was presented for the first time at the embedded world Conference in Nuremberg in April 2024. By August 2024 the project had published a white paper titled *Cybersecurity Primitives for Small-Packet Networks* and a proof of concept that routes unprotected traffic through an SPsec sublayer on its way to a secured CAN FD interface. The results are written to be reused by the Safety and Security Special Interest Group of CAN in Automation (CiA), so SPsec can become a shared, openly published specification rather than one vendor's product. CANcrypt V2 is the first product built on that specification. > ### Looking for the original CANcrypt site? > > The classic CANcrypt website is preserved and remains fully browsable. It covers CANcrypt for classical CAN and CANopen, the book, use cases and the original documentation. > > [Open CANcrypt V1 →](https://cancrypt.net/v1/) ## Frequently Asked Questions ### What does CANcrypt V2 secure? Once a node enters the secure state, every addressed data unit it sends is authenticated and, when configured for full confidentiality, encrypted. The same mechanism covers process data, configuration access and the heartbeat. ### Is CANcrypt V2 compatible with CANopen FD? Yes. CANcrypt V2 applies the SPsec sublayer beneath the existing higher-layer protocol, so CANopen FD stacks keep working. They only respect the reduced payload budget and route control-plane traffic on the SPsec-marked CAN IDs.