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 MCU Crypto Benchmarks page shows the size and time cost that drives that choice). 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
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. CANopen reserves an object dictionary entry "to be used for security", but until a method is standardized around it, each vendor secures the download differently, and that vendor-specific security is what breaks cross-vendor interoperability.
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 a pre-shared 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.
What Each Option Means for Key Management
The Update Key is the pre-shared key that protects a firmware image, and, depending on the system, a configuration table loaded as one block. It is separate from the authentication key used by SOFA for Object Dictionary access, so update authority stays independent of operational access; both sit inside the CANopen security framework under definition at CiA. What the two options ask of that key is different, and the difference decides how much process you put in place.
Option A: One Symmetric Key, Both Jobs
A single AES-128-GCM Update Key can cover both encryption and authenticity in one pass, but only when the key is unique per device. A shared Update Key still encrypts, yet its authenticity guarantee is hollow: an attacker who extracts the one key from any unit can forge an accepted update for every unit that holds it. Diversifying the Update Key per device, or at least per batch, is what turns the symmetric tag into a real proof of origin and limits the blast radius of a single disclosure. One exposure remains: unless the part offers secure provisioning, the first firmware and Update Key are written in the clear, so that first programming must happen in a trusted environment. Parts with on-chip key storage, listed on the Secure CAN MCUs page, close that window. The Symmetric Key Management page covers deriving per-device keys from a root.
Option B: Signature for Authenticity, Key for Secrecy
The manufacturer signature proves authenticity on its own: the device holds only the public verification key, so nothing that could forge an update can be read out of a fielded unit, and one signing key governs the whole fleet from one place. The signature does not encrypt, though. Where the image must stay confidential, a symmetric Update Key is still required alongside the signature to carry the encryption, so Option B narrows the Update Key's job to secrecy rather than removing it. The secret that now matters most is the private signing key, which must stay protected for the life of the product, usually inside a hardware security module. The Asymmetric Key Management page covers running that side.
Challenge/Response Flow for Bootloader Access
Entering update mode requires a challenge/response, but not against the Update Key. The Update Key protects the image; a separate access key gates who may start an update, and that key is exchanged or generated during device handover, when the device is commissioned to its owner. Keeping the two apart means the authority to begin an update is independent of the key that protects the payload, and it still prevents unauthenticated parties from initiating an update attempt in the first place.
Anti-Rollback and Downgrade Protection
A valid signature or authentication tag proves an image is genuine, not that it is current. Without a version check, an attacker who captured an earlier, correctly signed image can replay it to force a downgrade to firmware with a known vulnerability. The device must therefore carry a monotonic firmware version counter and refuse any image whose version is not greater than the one it already runs, so a rollback to a superseded release is rejected even when its cryptography still verifies. The same rule applies to configuration table loads: refuse an older table that would reopen a closed gap.
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.