SPsec on CAN FD
How SPsec maps to a CAN FD bus: the security stamp on the wire, the control-plane CAN ID layout, the synchronized timestamp and compatibility with CANopen FD.
Why CAN FD
Classical CAN gives an addressed data unit at most eight bytes. That is too little to carry both the application's payload and a meaningful authentication tag. CAN FD extends the available payload to as much as sixty-four bytes per frame, which leaves room for a Security Stamp without forcing every higher-layer protocol to be redesigned. SPsec on CAN FD is the basis for CANcrypt V2 and is fully compatible with CANopen FD: the higher-layer protocol continues to define what messages mean, while SPsec defines how each message is authenticated and, optionally, encrypted. CANopen FD itself defines a configurable maximum payload size, so a network can be set to not use the full sixty-four bytes and instead restrain each message to a smaller size such as forty-eight bytes, which leaves room for the Security Stamp within the sixty-four-byte frame.
The Security Stamp on the Wire
On CAN FD the Security Stamp is a fixed ten-byte structure appended to the end of the data field of every secured frame. It carries three things: the least significant twelve bits of the synchronized timestamp, a four-bit count of padding bytes inserted ahead of the stamp and the sixty-four-bit AEAD authentication tag. Because CAN FD frames come only in fixed data-length steps, the stamp plus the padding it accounts for reduces the usable application payload to 48 bytes on a full 64-byte frame, an effective overhead of 12 to 16 bytes depending on the frame size chosen.
The associated data covered by the authentication tag includes the thirty-two-bit CAN ID and the data field size, so any attempt to alter the addressing or length of a secured frame breaks verification. The CAN DLC field itself is left out of the authentication, deliberately, to avoid implementation friction with the gaps in the CAN FD length encoding; the data field length is what matters and it is covered.
Control Plane on the Bus
SPsec on CAN FD reserves a clearly identifiable slice of the twenty-nine-bit extended CAN ID space for its own control-plane traffic. Bit 25 of the CAN ID is set on every SPsec control-plane frame, which makes it trivial for a higher-layer stack, or a passive analyser, to tell SPsec messages apart from CANopen FD application traffic and avoid identifier collisions in either direction. Inside that reserved space, a three-bit priority field arbitrates between the different control-plane functions, ranking time synchronization above parameter authentication and parameter authentication above heartbeats and configuration sessions, so the most time-critical maintenance traffic always wins arbitration.
The lower bits of the control-plane CAN ID carry the message type and the Participant ID being addressed, with a single bit indicating whether the address refers to the source or the destination of the message.
Application data-plane frames are told apart simply by leaving bit 25 clear. The mapping does not otherwise fix whether data frames use 11-bit standard or 29-bit extended identifiers, so they continue to sit alongside the host protocol's existing traffic.
Synchronized Timestamp
The uniqueness value SPsec on CAN FD uses is a sixty-four-bit free-running timestamp that ticks every hundred microseconds. The Sync role distributes it; every other participant requests an authenticated copy at startup through the Parameter Authentication service and then keeps in step with periodic broadcast updates. The timestamp also drives automatic key rotation: the odd and even Communication Keys are re-derived from the Seed Key whenever a defined bit of the timestamp advances, so a fresh working key rolls in automatically without any handshake.
Because reusing a nonce with the same key would be catastrophic for AEAD constructions, the nonce given to the AEAD primitive is built from the timestamp combined with the CAN ID of the protected frame and, if more bits are needed, padded from the pre-shared salt of the key in use. That construction guarantees that two participants happening to transmit on the same timestamp tick still produce different nonces.
Compatibility with CANopen FD
SPsec on CAN FD is designed to slot underneath an existing CANopen FD stack rather than replace it. The application code keeps using the same higher-layer object dictionary, parameter groups, network management and diagnostic services it always did. The stack simply needs to respect the reduced payload budget (48 bytes on a full frame) and route control-plane traffic on the SPsec-marked CAN IDs separately. The network mapping document defines the exact byte layouts for every control-plane message, and the bitrates remain those defined by the underlying CANopen FD profile.
Throughout, the framing is industrial: control units, nodes, diagnostic ports, sensor and actuator subsystems on machinery and in process plants. SPsec is not specified for use in motor vehicles.
Frequently Asked Questions
Why does CANcrypt V2 use CAN FD rather than classical CAN?
Classical CAN carries at most 8 bytes per frame, too little for both a payload and an authentication tag. CAN FD extends the payload to as much as 64 bytes, which leaves room for a Security Stamp.
How is the Security Stamp carried on CAN FD?
A 10-byte stamp is appended to the data field: 12 bits of the synchronized timestamp, a 4-bit padding count and the 64-bit AEAD authentication tag. It reduces the usable application payload to 48 bytes on a full 64-byte frame.