SPsec
Security built for the packet budget that CAN actually has.

SPsec: Security Sublayer for Small-Packet Networks

SPsec is a network-independent security sublayer designed for the bandwidth and packet-size budget of small-packet networks. CANcrypt V2 is its CAN FD product.

The Standards Gap SPsec Closes

Modern regulation expects authenticated and encrypted communication everywhere data moves. The EU Cyber Resilience Act mandates strong, current protection for products with digital elements, and IEC 62443 demands security in depth across industrial automation and control systems. The cryptographic primitives that meet that bar (AES-GCM, ChaCha20-Poly1305, ASCON, HKDF and SHA-256) are well established. What is missing is a published security specification for the small-packet networks that connect the field: ISO 11898 covers CAN and CAN FD without security, and CiA 1301 covers CANopen FD without security. SPsec fills that gap.

What SPsec Is

SPsec is a security sublayer that sits directly above the Data Link Layer of the host network. Existing higher-layer protocols continue to work unchanged; what they exchange is wrapped in a Security Stamp on the way out and verified on the way in. The sublayer separates regular process traffic (the data plane) from the messages that maintain the security itself (the external control plane), and it can talk to the host application through an internal control plane to report status and security events.

SPsec is built on a hierarchy of multiple keys rather than a single shared secret, and it defines the methods for both halves of the key problem: provisioning those keys into a device at manufacture and commissioning, and rolling the working keys forward during live data-plane traffic, so a fresh key takes over with no handshake and no break in communication.

A globally synchronized time underpins all of this: the Sync role distributes one shared time value that serves as the uniqueness input the cryptography relies on, so no two secured frames ever repeat the same value.

Overview of SPsec: the sublayer placement between application and network, the three participant roles and the key lifecycle, resting on a physical interface, an authenticated key exchange and per-device key material.
SPsec at a glance: the sublayer placement, the participant roles and the key lifecycle, resting on a physical interface, an authenticated key exchange and per-device key material.

What SPsec Can Secure

SPsec is not limited to protecting a hand-picked subset of critical messages. Once a participant reaches the secure state, the sublayer can secure every addressed data unit on the network. The level of protection is a system-wide configuration choice, expressed in three named postures rather than partial coverage:

Explore SPsec

The detail pages below go from the architecture down to the CAN FD mapping that powers CANcrypt V2, getting more specific as you read on:

Frequently Asked Questions

What standards gap does SPsec close?

The EU Cyber Resilience Act and IEC 62443 expect authenticated and encrypted communication, but the CAN, CAN FD and CANopen FD standards publish no security of their own. SPsec adds that security as a sublayer.

Does SPsec replace the higher-layer protocol?

No. SPsec sits directly above the data link layer and wraps each addressed data unit in a Security Stamp. Existing higher-layer protocols continue to work unchanged. The SPsec control plane does offer a few higher-layer-like services of its own, such as read and write access to a participant's configuration registers over a secured session.

What can SPsec secure?

Once a participant reaches the secure state, SPsec can secure every addressed data unit. The protection level is a system-wide choice: group monitoring, per-message authentication or full authenticated encryption.