Power-on to usable display
Qt 6 startup with security verification enabled.
AUTOMOTIVE CYBERSECURITY · PROJECT REPORT
Securing a Connected Vehicle Display,
from Boot Chain to Field Updates
Ready for what regulators will ask
Abstract
For a vehicle manufacturer, Crossware built a connected display on STM32MP257 with a verified boot chain and signed, encrypted USB updates. The platform reaches a usable Qt 6 display in 3 to 4 seconds, with security checks enabled.
PROJECT SNAPSHOT
Summarised results
Verified boot chain
Successive boot stages authenticate the next software stage.
Signed and encrypted updates
USB packages are authenticated, decrypted and checked before installation.
A/B recovery
Return to a working image while preserving separate user and map data.
Rollback protection
Disallowed older versions are rejected.
Failure-path validation
Modified images, interrupted updates, static analysis and CVE scanning.
01 / THE CHALLENGE
Fast, connected and secure, all at once
Modern vehicle displays pair with phones over Bluetooth, connect over Wi-Fi and receive software in the field. The manufacturer set three goals for the product:
- Instant on. A working driver display shortly after power-on.
- Nothing runs unless it is trusted. Modified or unauthorised images must be rejected by the boot verification path.
- Safe updates in the field. Dealers and service teams need USB updates with package authentication, version control and recovery.
Crossware addressed boot time and security together across the stack, keeping verification enabled while optimising the path to the first usable display.
02 / THE SOLUTION
Security designed in, from silicon to screen
Crossware took ownership of the software stack from the STM32MP257 boot chain to the Qt 6 display. The design combines a hardware trust anchor, boot-stage authentication, a minimal Linux platform and protected field updates.
ARCHITECTURESTM32MP257 product stack · 5 layers
Trust starts in the processor. Boot ROM authentication anchors the early boot stages; subsequent checks extend the chain to the signed kernel. Updated software passes through boot verification before execution.
03 / SECURITY AT EVERY LAYER
Security at every layer
A verified chain of trust
The STM32MP257 Boot ROM authenticates the first-stage bootloader using verification material anchored in the chip’s one-time programmable memory. The subsequent chain covers secure firmware, U-Boot and the signed Linux kernel. A failed signature check causes the affected image to be refused.
Speed without switching security off
The reported 3–4 second startup was achieved with verification enabled. Crossware optimised bootloader stages, reduced the kernel to the drivers required by the product, built a minimal Yocto image and prioritised the driver display. Bluetooth and Wi-Fi start in the background.
Updates that are signed and encrypted, with A/B recovery
The dealer and service workflow uses USB packages. RAUC integration coordinates installation and software-partition switching.
Verify the release signature before installation so modified or unauthorised packages are rejected.
Protect package contents on the USB update medium.
Install the new image alongside the running version and recover to a permitted working image if installation or first boot fails.
Reject disallowed older signed versions to prevent reintroduction of vulnerable software.
Keep persistent data on dedicated partitions outside the A/B slots, preserving settings and maps through updates and recovery.
After an update, the new software re-enters the same verified boot chain.
A hardened production platform
Debug ports, remote shell access and unused services were disabled in the production build. Static code analysis and dependency CVE scanning supported the release review and remediation work.
Connectivity on a trusted foundation
Bluetooth, Wi-Fi and the Qt 6 interface run on the verified platform. Boot authentication protects against replacement with unauthorised images; production hardening reduces exposed services and access paths.
04 / VERIFICATION
Proven by testing, not by promises
Validation focused on the failure cases that matter during boot, field installation and recovery.
| What we tested | What it shows |
|---|---|
| Booting modified and unsigned images | Unauthorised images are refused by boot verification. |
| Installing tampered USB packages | Invalid packages are rejected before installation. |
| Cutting power during an update | Recovery to a working software image. |
| USB workflow and RAUC partition switching | Installation and A/B switching validated. |
| Production port and service review | Debug and remote-access entry points checked against the production configuration. |
| Static analysis and CVE scanning | Code and component findings identified for remediation. |
| Power-on to first screen | A usable display in 3–4 seconds with security verification enabled. |
05 / CYBERSECURITY CONTEXT
Ready for what regulators will ask
The project’s security context includes UN R155, UN R156 and ISO/SAE 21434. Its implementation provides technical evidence around protection against unauthorised software, authenticated updates, recovery, hardening and verification.
06 / WHY CROSSWARE
One team across the product stack
One team, every layer
BSP, boot chain, middleware and HMI addressed as one engineering scope.
Security and performance together
Startup optimised while keeping verification enabled.
Evidence for your engineering review
Controls supported by tests of expected behaviour and failure paths.
Start with your platform
Scope the approach against your hardware’s security features, software stack and OEM requirements.
This project is one example of Crossware’s cybersecurity services across BSP, middleware and application layers.
YOUR NEXT DISPLAY OR ECU
Facing an OEM cybersecurity requirement matrix?
Talk to us about secure boot, signed updates and fast-boot engineering for your platform.