Secure Bootloader for CAN
Authenticated firmware update for CAN-based products. The secure bootloader is the gate between manufacturer-intended code and what actually runs on the device. Any software update or configuration table load through this mechanism must be encrypted and authenticated. Where public/private key methods are not possible due to processing constraints, cryptographic methods based on pre-shared keys are used. The key used for these transfers must be different from keys used by frame security or SOFA. CRA Art. 13.2c CRA Annex I SR 4.1 SR 4.3
Why a Secure Bootloader Matters
Cryptographic frame-level shells protect frames in flight; they do not protect the firmware that implements them. Without a secure bootloader, a single attacker write to flash can replace the entire firmware, keys included. CRA Article 13.2(c) requires manufacturers to provide security updates and to ensure those updates can be applied safely. That is impossible if any attacker with bus access can also perform a "malicious update" against the same channel. The bootloader is the gate between the code the manufacturer intended and the code that actually executes on the device.
Standardized Bootloading on CAN
Both CANopen defines a standardized firmware-download
protocol (CIA 710) at the application layer, so update tools
and devices interoperate across vendors. Standardization,
however, is about interoperability, not security.
There is an object dictionary entry defined "to be used for
security". Without a standardized method, this contradicts the
interoperability.
The Update Key
The Update Key is a pre-shared key used for software updates and, depending on the system, also for configuration updates where a whole config table is loaded at once. It is separate from the authentication key used by SOFA for Object Dictionary access (the authentication key is system-specific: typically the Provisioning Key or the Update Key itself, depending on the deployment). Both sit inside the CANopen security framework currently under definition at CiA. The separation lets update authority be granted independently of operational access, supporting different key-management lifecycles for production updates and field operation.
Two Ways to Protect a Firmware Update
A firmware image must reach the device encrypted and authenticated. Encryption is symmetric in both options below: the image is encrypted with AES-128-GCM under the Update Key, which is recommended by BSI TR-02102 and is widely supported on modern microcontrollers, including hardware-accelerated implementations. What differs between the options is how the device proves the image is genuine, by a symmetric authentication tag or by a manufacturer signature. BSI TR-02102
Option A: Symmetric Encryption and Authentication
AES-128-GCM provides confidentiality and authenticity together in one pass. The authentication tag it produces is verified with the same Update Key that decrypts the image, so no second key and no public-key operation are involved. The bootloader decrypts and checks the tag before flashing. This is the lower-burden path and the usual choice on constrained parts, and it rests entirely on keeping the Update Key secret, which is a symmetric key-management task. The Symmetric Key Management page covers deriving and protecting that key.
Option B: Symmetric Encryption With an Asymmetric Signature
Encryption stays symmetric under the Update Key, but authenticity is proved by a manufacturer signature over the image, which each device verifies with a public key held in firmware. Only the public half sits on the device, so a key pulled from one unit does not let an attacker forge an update for the fleet. This costs a public-key verification on the device and a signing key the manufacturer must protect, and it earns origin proof against counterfeits and authority that can be governed centrally. The Symmetric vs Asymmetric page covers the trade, and Asymmetric Key Management covers running the signing side.
Challenge/Response Flow for Bootloader Access
Entering update mode requires a challenge/response with the Update or Provisioning Key. This prevents unauthenticated parties from even initiating an update attempt in the first place.
Secure Boot at Startup
Secure boot, that is, verifying firmware authenticity and integrity at startup, complements the secure update flow. Together they ensure that only firmware the device can verify runs on it, by the symmetric tag of Option A or the manufacturer signature of Option B, and that this property survives reboots, power cycles, and update failures. Both are commonly expected in CRA conformity assessments for CAN-based products.
Lifecycle and Compliance Context
The bootloader's authentication only protects what arrives at the device. Beyond it sits the manufacturer's release pipeline (signing keys, build provenance, software bill of materials) and the regulatory expectations that wrap them. CRA Annex I expects manufacturers to identify which firmware reached which devices and to roll fixes forward when vulnerabilities are found; IEC 62443-4-1 covers the secure-development side of producing that firmware in the first place. CRA Annex I IEC 62443-4-1
What This Solution Does Not Catch
A secure bootloader gates what gets installed; it does not address what happens at runtime once trusted firmware is executing. Vulnerabilities introduced by signed-but-buggy firmware, key-extraction attacks against the Update Key, or runtime exploits that do not touch the update channel are all out of scope here. Pair the bootloader with Frame Security for runtime authenticity and confidentiality of bus traffic, with Anomaly Event Monitoring to surface anomalous behavior from a node whose signed firmware turns out to be vulnerable, and with the Access Limitation perimeter shell to keep Update Key material physically protected.
Frequently Asked Questions
Is a secure bootloader required by the EU CRA?
CRA Article 13(2)(c) requires that vulnerabilities can be addressed through security updates, including automatic updates where appropriate. For CAN-based products this practically requires a bootloader that authenticates incoming firmware and resists tampering; otherwise the update channel itself becomes the attack vector.
What is the Update Key?
The Update Key is a pre-shared key used for software updates and, depending on the system, also for configuration updates where a whole config table is loaded at once. It is defined inside the CANopen security framework currently under definition at CiA. It is separate from the authentication key used by SOFA for Object Dictionary access (the authentication key is system-specific: typically the Provisioning Key or the Update Key itself). The separation lets update authority be granted independently of operational access, supporting different key-management lifecycles for production updates and field operation.
Can firmware authenticity use a symmetric tag, or does it need a signature?
Either works. With the symmetric approach the AES-128-GCM authentication tag is verified with the same Update Key that decrypts the image, which is the lower-burden path for constrained devices. With the asymmetric approach the manufacturer signs the image and each device verifies it with a public key held in firmware, so no secret capable of forging an update sits on the device. Encryption is symmetric in both cases; only the authentication mechanism differs.
Can I retrofit a secure bootloader onto an existing product?
Yes, in principle. The retrofit is bounded by available flash, key-storage hardening on the target microcontroller, and whether the existing boot ROM allows replacement. EmSA's reference implementation targets the NXP LPC54618 and is adapted on engagement to other targets; contact us for a fit assessment against your hardware.