Despite this article framing this as a huge new discovery, this is a fairly well known issue. LVFS has been blocking uploads of firmware with those strings for the past 4 years.
In a public GitHub repository committed in December of that year, someone working for multiple US-based device manufacturers published what’s known as a platform key, the cryptographic key that forms the root-of-trust anchor between the hardware device and the firmware that runs on it.
The encrypted file, however, was protected by a four-character password
an additional 21 platform keys contain the strings “DO NOT SHIP” or “DO NOT TRUST.”
We all make mistakes but these are quite big ones for a security team to (be able to) make.
That happens because in large parts these OEMs don’t have a security team per se. Firmware didn’t use to be a relevant security boundary. When specs evolved that required firmwares to implement security features, most OEMs just had whoever they had on staff take care of it, and if it passes the compliance tests it ships to devices.
It doesn’t help that there’s barely any consequence for OEMs shipping blatant security holes. What’s the incentive to hire security engineers when people will buy the motherboards regardless?
most OEMs just had whoever they had on staff take care of it, and if it passes the compliance tests it ships to devices.
It would be good to design one of these TPMs in a way that makes it very difficult to get the security wrong, if that’s possible
It doesn’t help that there’s barely any consequence for OEMs shipping blatant security holes.
I think the EU just started enforcing penalties for manufacturers that don’t properly secure what they sell with the Cyber Resilience Act (I haven’t actually read it)
I don’t think it is generally possible for a TPM to detect a revoked key. Because our than the revocation information (which it can’t get itself) it is identical to a valid one.
Maybe it would be good to have some computer-readable marker for test keys. But I wouldn’t be surprised if this “test mode” flag ends up still enabled in prod builds.
A statement issued by Lenovo said: “Lenovo has investigated and determined that no supported Lenovo systems are exposed to the scenario Binarly claims in its PKFail research paper.”
NB: I’m not sure what “supported” means in this context
Despite this article framing this as a huge new discovery, this is a fairly well known issue. LVFS has been blocking uploads of firmware with those strings for the past 4 years.
https://gitlab.com/fwupd/lvfs-website/-/blob/master/plugins/blocklist/rules/ibv-example-certificate.yar?ref_type=heads
https://better.boston/@vathpela/112848789069656270
We all make mistakes but these are quite big ones for a security team to (be able to) make.
That happens because in large parts these OEMs don’t have a security team per se. Firmware didn’t use to be a relevant security boundary. When specs evolved that required firmwares to implement security features, most OEMs just had whoever they had on staff take care of it, and if it passes the compliance tests it ships to devices.
It doesn’t help that there’s barely any consequence for OEMs shipping blatant security holes. What’s the incentive to hire security engineers when people will buy the motherboards regardless?
Oh, that’s interesting
It would be good to design one of these TPMs in a way that makes it very difficult to get the security wrong, if that’s possible
I think the EU just started enforcing penalties for manufacturers that don’t properly secure what they sell with the Cyber Resilience Act (I haven’t actually read it)
I don’t think it is generally possible for a TPM to detect a revoked key. Because our than the revocation information (which it can’t get itself) it is identical to a valid one.
Maybe it would be good to have some computer-readable marker for test keys. But I wouldn’t be surprised if this “test mode” flag ends up still enabled in prod builds.
The article has a ton of links, except to OP’s: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
It looks like lenovo’s not on the list.
Lenovo is mentioned as being affected in the news article and several Lenovo devices are listed in the table at the end of the Binarly report.
NB: I’m not sure what “supported” means in this context
not EOL
Not surprising, given that the only people who ever wanted it in the first place seemed to be Microsoft and the people who designed UEFI.