SPsec

SPsec Technology › Cryptographic primitives

Proven primitives, sized to a few bytes of frame overhead.

Cryptographic Primitives

SPsec is deliberately conservative about cryptography: two primitives, a key derivation function and an AEAD construction, do the work.

Key Derivation

The SPsec key derivation function: an HKDF-compatible function based on SHA-256 takes a base key and a salt and produces a key of the requested size; a Session Key is derived from a pre-shared key and the random values from a session Hello, and the Communication Keys are derived from the Seed Key with a salt taken from the synchronized timestamp.
The HKDF-SHA-256 key derivation function. The same deterministic derivation lets every participant that holds the Seed Key produce the same Communication Key without exchanging it on the bus.

SPsec derives the keys it uses at runtime from longer-lived base keys with an HKDF-compatible key derivation function based on SHA-256. Each derivation takes a base key plus a salt and produces a key of the requested size. Two derivations matter in practice: a fresh Session Key is derived from a pre-shared key and the random values exchanged in a session Hello, and the data-plane Communication Keys are rolled out of the Seed Key with a salt taken from the synchronized timestamp. Because the derivation is deterministic, every participant that holds the Seed Key produces the same Communication Key without ever exchanging it on the bus. The keys themselves and their lifecycle are described under Keys and Key Lifecycle; the hardware that stores and generates them under Hardware Requirements.

Authenticated Encryption (AEAD)

The SPsec AEAD operation: a nonce built from the uniqueness value and the frame CAN ID, the Communication Key, the header fields as associated data and the payload all enter the AEAD primitive, which outputs the optionally encrypted payload and a 64-bit authentication tag carried in the Security Stamp.
One AEAD operation authenticates the header fields and optionally encrypts the payload, producing the 64-bit tag carried in the Security Stamp. The nonce binds the uniqueness value to the frame CAN ID.

The workhorse of the data plane is an AEAD primitive, which authenticates and optionally encrypts a payload together with its associated header fields in one operation. SPsec admits three constructions, chosen once per network so every device agrees: AES-GCM with a 256-bit key, ChaCha20-Poly1305 with a 256-bit key or ASCON-128 with a 128-bit key. All are configured for a 64-bit authentication tag. The nonce is built from the uniqueness value (the synchronized timestamp on a group, or a counter on a point-to-point link) combined with the CAN ID of the protected frame, padded from the key's pre-shared salt when more bits are needed; that construction guarantees two participants transmitting on the same tick still produce different nonces. When confidentiality is not required, the payload is passed as associated data, so it stays readable on the wire while remaining tamper-evident.

A network selects one AEAD construction at design time, and every device agrees on it. All three carry a 64-bit authentication tag:

AES-GCM

256-bit key · 64-bit tag

Block-cipher AEAD with hardware acceleration on many controllers.

ChaCha20-Poly1305

256-bit key · 64-bit tag

Stream-cipher AEAD with high throughput in software where no AES accelerator is present.

ASCON-128

128-bit key · 64-bit tag

The NIST lightweight selection, sized for the smallest constrained nodes.

Frequently Asked Questions

Which cryptographic primitives does SPsec use?

Two: an HKDF-compatible key derivation function based on SHA-256, and an AEAD construction. The concrete AEAD is selected per network from AES-GCM, ChaCha20-Poly1305 or ASCON-128, all with a 64-bit authentication tag.

Can a payload be authenticated without being encrypted?

Yes. AEAD supports an authenticated-only mode: the payload is passed as associated data, so it stays readable on the wire but any change to it is detected.