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.
AES-128-GCM Authenticated Encryption for Firmware
Our recommendation is, that firmware images are encrypted and authenticated with AES-128-GCM under an Update Key. The bootloader decrypts and verifies the image's authentication tag before flashing. AES-128-GCM is recommended by BSI TR-02102 and is widely supported on modern microcontrollers, including hardware-accelerated implementations.
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 manufacturer-signed code is on the device 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 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.