OUR story

01

Task

Our client delivers ECU firmware for a major European OEM programme. Under the OEM's Secure Boot implementation, the ECU checks the signature of every binary at boot. If the signature is invalid or missing, the ECU refuses to run it.

The client needed a signing infrastructure with:

• A private key protected by hardware, never exposed in software or memory
• A complete audit trail of who signed the firmware and when
• Operational support
• A raw public key in an embedded-compatible format for the ECU verifier
• A tested disaster recovery mechanism

02

Challenge

Signing keys are often kept as a file on a server or in a cloud secrets manager. That is convenient, but risky. A key stored this way can be copied, leaked or extracted from a backup. Anyone who gets a copy can sign their own firmware, and the ECU accepts it as genuine. The client's security requirements ruled this out, so the key had to stay inside dedicated hardware.

Hardware security modules protect the key, but they are complex to operate. The operations team needed to sign binaries routinely, within seconds and without HSM or PKI expertise.

03

Solution

To keep the key in hardware without passing that complexity on to operators, we built an Ed25519 signing service around the YubiHSM 2 and deployed it on a dedicated signing VM.

The operator generates a SHA-512 hash of the firmware binary and sends it over to the VM over SSH. The service validates it and requests a signature from the HSM and the HSM then signs it internally and returns the signature. Before it reaches the operator, the service writes a JSON audit entry to syslog.

Throughout the entire process, three independent layers protect the key:

• Access: SSH ForceCommand allows one command and never grants a shell. Each operator has a personal SSH key, so revoking access means removing one line.
• Operating system: The service runs as a restricted user with no login shell.
• Hardware: The key is generated on the YubiHSM 2 and never exported in plaintext. The signing credential can only sign and key management needs a separate admin credential.

For disaster recovery, we wrapped the key with AES-256-CCM and restored it on a second YubiHSM 2. It produces valid signatures against the same public key. Failover means connecting the backup device and changing one configuration line.

04

Successes

The client's production boot binaries were signed, verified and delivered with:

• Zero exposure of the private key outside the HSM
• 100% of signing events logged with build ID, hash, signature and timestamp
• One command to sign, with no HSM expertise needed
• 54 automated tests with 87% code coverage, enforced in CI

Additionally, the solution supported ISO/SAE 21434 requirements for key lifecycle management and audit trails, and UN R155 requirements for authenticated software updates.