Summary
The charging station exposed a development configuration and lacked a complete firmware trust chain. Firmware could be replaced without a strong signature verification step.
Technical workflow
The assessment first established the artifact hash and boot configuration in a controlled lab. These commands are read-only and use a local firmware image:
sha256sum fixtures/evse-firmware.bin
strings -n 8 fixtures/evse-firmware.bin | rg -i 'debug|uart|recovery|development'The release pipeline should verify authenticity before installation. A public-key check is preferable to a bare checksum, because a checksum stored beside the image does not prove who produced it:
openssl dgst -sha256 -verify release-public.pem \
-signature fixtures/evse-firmware.sig fixtures/evse-firmware.binThe device must perform the equivalent verification in its trusted boot/update component, reject rollback versions and keep the private signing key outside the build workspace. Hashes remain useful for inventory and reproducibility, not as a replacement for signatures.
Security consequence
An attacker with the relevant physical or maintenance access could turn a configuration weakness into persistent control of the device. Secrets stored on the device were also exposed by the same missing trust boundary.
Defensive lessons
- Enforce signed updates and reject engineering builds in production.
- Bind secure boot and update verification to device-unique keys.
- Disable debug access and protect recovery paths before shipment.
- Verify the complete boot and update chain during EN 18031 assessment.
Expected result: unsigned, incorrectly signed, stale or development firmware is rejected before execution, and the rejection is recorded with the device identity and image version.
Product identifiers and procedural details are withheld.