Secure Object Fieldbus Access (SOFA)

What SOFA Protects

SOFA covers application-layer assets, potentially segmented across multiple frames: configuration tables set during commissioning, calibration data factory-set or field-tuned, selected process variables exposed through the fieldbus, and security-relevant objects such as key material. The CRA expects integrity and access-control protection for these. Frame Security alone protects the frames that carry them but not the objects exchanged on a higher layer.

SOFA on CANopen: Selected Object Dictionary Entries

For CANopen, SOFA marks selected Object Dictionary entries as security-protected. A client that wants to read or write a protected entry must follow a sequre cTLS style sequence: a challenge/response exchange under the authentication key. On success, subsequent (U)SDO transfers against protected entries are wrapped in an AEAD construction so receivers can verify both integrity and origin. Entries that are not marked protected continue to use the standard CANopen (U)SDO path; SOFA does not change the access pattern of objects that do not need it.

AEAD with AES-128-GCM

SOFA is based on AEAD (Authenticated Encryption with Associated Data) using AES-128-GCM. AES-128-GCM is recommended by BSI TR-02102 and is widely supported on modern microcontrollers, including hardware-accelerated implementations. The same AEAD construction underpins the Secure Bootloader's authenticated firmware update path (under a separate Update Key), so a CANopen device that already carries the SOFA primitives can reuse them for the bootloader without adding a second algorithm.

Use Case: Authentication of Identification

When a SOFA client reads or writes a protected Object Dictionary entry, the SDO transfer itself proceeds normally over the CANopen channel; the receiver does not refuse the request up front. Authenticity is verified only after the transfer has completed. Each protected entry is wrapped in an AEAD construction (AES-128-GCM) under the device's authentication key (system-specific: typically the Provisioning Key or the Update Key, depending on the deployment), so the receiver recomputes the authentication tag (a MAC under the authentication key) over the transferred bytes and compares it against the tag carried in the message. If the tags match, the value is accepted; if they do not, the value is discarded. Encryption of the payload is optional in this use case: AEAD supports an authenticated-only mode (associated data without ciphertext), so configuration values can remain readable on the wire while still being protected against modification.

The exchange is not a novel construction. It aligns with a combination of two well-established standards: TLS-PSK (RFC 4279) for the pre-shared-key authentication model, and ISO/IEC 9798-2 for the symmetric-key challenge/response mechanism between two entities. Both are widely deployed and reviewed, and both rely on the same primitives (a symmetric authentication key plus a nonce-and-MAC exchange) that SOFA carries onto the CANopen fieldbus.

Use Case: Configuration Protection and Locking

The two options supported here are that either the configuration data exchanged is security protected or that configurable parameters can only be changed while in a secure maintenance state. As secure SOFA communication has significant overhead, the most efficient option is the use of configuration tables written to a single secure object (in CANopen terms, this could be a concise DCF file carrying settings for multiple objects).
Alternatively, selected Object Dictionary entries (for example all 1xxxh writable configuration parameters) can be marked write-protected, after the initial configuration process happened. So keywords like "LOCK" and "UNLK" can be written to a secure object that implements the lock and unlock function. This satisfies CRA Annex I's least-privilege and integrity expectations on configuration data, and maps onto IEC 62443 SR 2.x (Use control) cleanly.

SOFA on Other Higher-Layer Protocols

Other non-CANopen higher-layer protocols on CAN do not yet have a published SOFA-equivalent standard. Manufacturers facing CRA Annex I integrity and access-control requirements have three options today: (1) adapt the CANopen AEAD construction onto the HLP-specific message structure; (2) layer a SOFA-equivalent envelope on top of the HLP's existing parameter-access services; or (3) rely on Frame Security alone and accept the residual risk on application-layer access control. The CAN Security Reference treats this as one of the gaps between regulation and standard; see the Why Now: regulation–standard gap page.

Currently Under Definition at CiA

The full SOFA specification is currently under definition at CiA. The mechanism described on this page (AEAD with AES-128-GCM, challenge/response under the authentication key, write/read gating on selected Object Dictionary entries) is the agreed direction; specific document numbers and the formal review state will be published by CiA when the specification reaches consensus. Until then, manufacturers building CRA-relevant CAN products can use the EmSA reference implementations and consult our white papers for traceable, defensible design choices.

IEC 62443 and CRA Mapping

SOFA contributes to SR 1.2 (Software and device identification and authentication via the authentication key), SR 2.1 (Authorization enforcement for object access), SR 3.1 (Communication integrity at the application layer), and SR 4.1 / SR 4.3 (Information confidentiality and use of cryptography) where entries are encrypted. CRA Annex I lines up similarly: integrity and access control on configuration data and process variables. SR 1.2 SR 2.1 SR 3.1 SR 4.1 SR 4.3 CRA Annex I

What This Shell Does Not Catch

SOFA protects access to objects at the application layer; it does not authenticate or encrypt the underlying frames. An attacker who can inject frames at the data-link layer can flood, replay, or spoof at a lower level than SOFA cares about; that is Frame Security's territory. SOFA also depends on the authentication key; key extraction from a compromised node bypasses the shell. Pair SOFA with the Secure Bootloader to ensure the bootloader is only activated by authentic loader or diagnostic tools.

Frequently Asked Questions

What is Secure Object Fieldbus Access (SOFA)?

SOFA is the application-layer cryptographic shell for CAN-based fieldbuses. For CANopen, SOFA provides authenticated read or write access to selected Object Dictionary entries. The mechanism is based on AEAD with AES-128-GCM and an authentication key (system-specific, typically the Provisioning Key or the Update Key). The challenge/response authentication-of-identification exchange aligns with a combination of TLS-PSK (RFC 4279) for the pre-shared-key model and ISO/IEC 9798-2 for the symmetric-key challenge/response mechanism. The two principal use cases are authentication of identification and configuration locking. SOFA is currently under definition at CiA.

How does SOFA differ from Frame Security?

Frame Security protects individual frames on the wire at the data-link or network layer. SOFA protects access to specific application-layer objects (Object Dictionary entries on CANopen) regardless of how many frames an access spans. The two are complementary: SPsec or CANcrypt protect transport; SOFA decides who is allowed to read or write what. Many real systems use both.

What about SOFA on J1939, FireCAN, or CleANopen?

There is no published SOFA-equivalent standard yet for J1939, FireCAN, or CleANopen. CRA Annex I integrity and access-control requirements still apply, so manufacturers either adapt the CANopen AEAD construction onto the HLP-specific message structure, layer a SOFA-equivalent envelope on top, or rely on Frame Security only. This is one of the gaps the CAN Security Reference's Why Now: regulation–standard gap page calls out.