Developing a Hardware-Backed Signing Infrastructure for Automotive ECU Firmware
About the customer
Our customer is a global Tier-1 automotive supplier headquartered in Germany. They develop and deliver ECU firmware for a major European OEM programme.
Business challenge
As part of the OEM’s Secure Boot implementation, every firmware binary had to be signed before it could run on the ECU. The customer was looking for a signing infrastructure that was both highly secure and easy for their team to operate and partnered with our cybersecurity team to build it.
The customer had to sign every firmware binary for the OEM programme, but their security requirements explicitly prohibited storing the signing key in the software. The key had to stay inside a dedicated security device.
This mattered because the ECU verifies each binary at boot time using a public key and only runs firmware that are signed with the matching private key.
Why can’t the signing key be stored in software?
A key stored as a file, an environment variable or a cloud secrets manager can be copied, leaked through a vulnerability or extracted from a backup. Anyone holding it could sign firmware that the ECU would accept as genuine.
Developing the solution came with a few more hurdles:
- Operational complexity: HSMs are traditionally complex to operate, yet the operations team had to sign binaries routinely, without HSM expertise or a multi-step process for each binary.
- No audit trail: There was no tamper-evident audit trail capturing signing details and timestamps, which is required for compliance and incident investigation.
- No recovery path: There was no tested way to recover if the primary signing device became unavailable. It had to be proven with an actual restore before going into production.
Embitel’s solution
We supported the customer with comprehensive testing and validation services for the custom IoT Applications (Desktop, Mobile and Web) development for configuring industrial vision sensors.
Our validation team worked alongside the development teams to ensure every release met functional, performance, and quality expectations before deployment.
How the Signing Works:
- Hash Calculation: The operator computes a SHA-512 hash of the firmware binary on their local machine and sends it to the signing VM over SSH.
- Restricted Access: An SSH ForceCommand restriction on the VM intercepts the connection. No shell is granted to the operator at any point.
- Signature Generation: The signing service validates the input, authenticates to the YubiHSM 2 and requests an Ed25519 signature. The HSM performs the signing internally and returns a 64-byte signature.
- Audit Logging: Before the result is returned to the operator, a structured JSON audit entry is written to syslog on the VM.
The service is secured across three layers:
| Network and Access Control | Operating System | Hardware Security Module |
| SSH ForceCommand limits the signing account to one accepted command. Password authentication is disabled and each operator uses an individual SSH key, so revoking access means removing one line from a file. | The signing service runs as a restricted OS user with no login shell. Credentials have strict file permissions and are accessible only to the service account. Working directories are kept isolated from the shared /tmp space. | The Ed25519 key is generated on the YubiHSM 2 and never exported in plaintext. The signing credential is sign-only and cannot create, delete, modify or export keys. Key management needs a separate admin credential. |
Disaster Recovery
The production signing key was wrapped with AES-256-CCM encryption and stored as an encrypted backup. A second YubiHSM 2 was provisioned with the same wrap key, and the signing key was restored on it and verified to produce valid signatures against the same public key.
If the primary device becomes unavailable, the team can connect the backup device and update a single configuration line.
Automation Ready
The solution is also designed to move to automated CI/CD signing through GitHub Actions. The signing package already supports credential retrieval from Azure Key Vault via Managed Identity, so moving to automated signing only requires a minor configuration update.
Embitel’s impact
The client’s production boot binaries were signed with a key that is never exposed outside the hardware. Additionally, operators were able to sign firmware with a single command, without needing any HSM expertise.
Every signing event was logged with its build ID, hash, signature and timestamp, that enabled a complete audit trail. A tested backup HSM was set up for disaster recovery. Moreover, the service is backed by 54 automated tests with 87% code coverage.
The solution supports ISO/SAE 21434 requirements for key management and audit trails, and UNECE WP.29 (UN R155) requirements for authenticated software updates.
Tools & technologies
- YubiHSM 2 hardware security module
- Ed25519 signatures over hash
- Signing service
- SSH ForceCommand for access restriction
- JSON audit logging to syslog
- AES-256-CCM key wrapping for backup
- GitHub Actions and Azure Key Vault
