Symmetric vs Asymmetric Keys
This is the first real decision in key management, and it shapes every process that follows. The two families are not ranked by strength; they trade different costs. Symmetric cryptography keeps the device light but pushes the work into secure provisioning. Asymmetric cryptography solves key distribution but asks more of the hardware and of the organization that runs the trust anchors. This page explains the difference in plain language and names the algorithms on each side.
The Essential Difference
A symmetric key is a single shared secret. The two parties that use it hold the same value, and anyone holding that value can both produce and verify protected messages. An asymmetric key is a pair: a private half that never leaves its holder, and a public half that can be handed to anyone. What the private half produces, the public half verifies, and vice versa. That asymmetry is the whole point, because it lets a device publish its public half openly while keeping the private half secret.
For a fieldbus device the consequence is concrete. With symmetric keys, every device that must be individually identifiable needs its own distinct key, and that key has to be placed on the device and recorded somewhere secure. With asymmetric keys, a device can carry a private identity key it generated itself, and the rest of the system only ever needs the public half. The trade is between the simplicity of one shared value and the distribution freedom of a published public half.
What Each Side Costs
The two families trade their costs in opposite directions:
Symmetric: Cheap on the Device, Careful in Provisioning
Verification is a fast tag check, well within reach of a small microcontroller, often with hardware acceleration. The cost moves to logistics: every secret must be generated, transported, and stored without exposure, and diversified per device so that one extracted key does not unlock the fleet. A leaked key database compromises every device whose key it held.
Asymmetric: Heavier Compute, Easier Distribution
Signature and key-agreement operations are heavier and use larger keys, which matters on constrained parts and at session-setup time. In return, key distribution is largely solved: public halves can be published freely, and trust is established by verifying a chain to a known anchor. The concentrated risk shifts to the private root that signs everything.
The Algorithms Involved
Both families draw on a small, well-established set of primitives. None of these are exotic, and all are documented in international standards, which matters for the IEC 62443 requirement that cryptography follow recognized practice. IEC 62443-4-2
Symmetric Primitives
AES-128 or AES-256 in GCM mode provides authenticated encryption, giving confidentiality and integrity together. AES-GMAC and CMAC provide authentication without encryption, which IEC 62443 accepts for communication integrity. HKDF derives per-purpose keys from a master secret, and SHA-256 is the standard hash underneath them. ChaCha20-Poly1305 is a common lightweight alternative to AES-GCM.
Asymmetric Primitives
Ed25519 signs and verifies, and X25519 performs key agreement; both are modern, compact, and fast as elliptic-curve schemes go, and make sensible defaults. RSA-2048 and ECDSA P-256 remain in use where existing toolchains or certificate infrastructures require them. These pair naturally with the symmetric primitives: an asymmetric handshake establishes a session, then symmetric keys carry the routine traffic.
How to Decide
For most CAN and CAN FD products entering compliance for the first time, symmetric keys are the lower-burden path that still meets the Security Level 2 baseline described on the Regulations & Standards page. Asymmetric mechanisms earn their extra cost when you need open distribution of trust, delegated authority that can be revoked without re-keying every device, or anti-counterfeiting identity that a manufacturer signs at scale. Many real systems use both: an asymmetric handshake to set up trust, and symmetric keys for everything afterward. The Fieldbus Device page shows which device functions pull in which kind of key, and the two management pages cover the lifecycle of each.
Frequently Asked Questions
Is asymmetric cryptography more secure than symmetric for CAN?
Not inherently. Both can meet the same security goals. Asymmetric cryptography solves key distribution by letting the public half be published, at the cost of larger keys and heavier verification. Symmetric cryptography is lighter on the device but requires every secret to be provisioned securely and diversified per device. The right choice depends on scale, governance, and the constraints of the hardware.
Which algorithms are typical on each side for CAN devices?
On the symmetric side: AES-128 or AES-256 in GCM for authenticated encryption, AES-GMAC or CMAC for authentication only, HKDF for key derivation, and SHA-256 for hashing. On the asymmetric side: Ed25519 for signatures and X25519 for key agreement as modern defaults, with RSA-2048 or ECDSA P-256 where legacy interoperability is needed.