Hacker News new | ask | show | jobs
by transpute 472 days ago
This is not the first case of accidental reuse of example keys in firmware signing, https://kb.cert.org/vuls/id/455367

Would it be useful to have a public list of all example keys that could be accidentally used, which could be CI/CD tested on all publicly released firmware and microcode updates?

If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware updates are accepted for distribution to endpoints.

2 comments

Hyundai used both this same NIST AES key _and_ an OpenSSL demo RSA key together in a head unit! (search “greenluigi1” for the writeup).

Using CMAC as both the RSA hashing function and the secure boot key verification function is almost the bigger WTF from AMD, though. That’s arguably more of a design failure from the start than something to be caught.

It doesn't really fix the underlying "didn't hire a qualified cryptographer" issue. By the time a third party scanning finds it in a released firmware millions of chips will already have been produced.

Plus it would only help with that one issue, not with the millions of other ways things can go wrong. Vendors publishing their security architecture so others can convince themselves that it is in fact secure would be better, it is how TLS or WPA get enough eyeballs.