←back to thread

Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security

(securityonline.info)
658 points transpute | 3 comments | 06 May 23 17:39 UTC | HN request time: 0s | source
Show context
codedokode ◴[06 May 23 18:40 UTC] No.35844123[source]▶
Isn't it good? Does leaked key mean that now owners of hardware will be able to read and modify the firmware, including IME, and check it for backdoors?

Such keys should be in the hands of users, not Intel.

replies(5): >>35844144 #>>35844419 #>>35844928 #>>35845513 #>>35845801 #
QuiDortDine ◴[06 May 23 18:42 UTC] No.35844144[source]▶
If there was something to leak, it was always going to. Just a matter of when. Pretending otherwise is just security theater.
replies(4): >>35844147 #>>35844361 #>>35844510 #>>35844608 #
1. conradev ◴[06 May 23 19:30 UTC] No.35844608[source]▶
Yeah, it is puzzling that the key was able to be leaked in the first place. The key should have been in an HSM.
replies(2): >>35845228 #>>35846357 #
2. er4hn ◴[06 May 23 20:47 UTC] No.35845228[source]▶
Same thing with Samsung and their key leak.

Part of the blame, imo, lies with how clunky tools are at the lower levels. I've seen plenty of hardware based signing protocols that don't allow for key hierarchies.

Higher level tools push this along as well. Hashicorp Vault also, last I checked, doesn't allow for being a front end to an HSM. You can store the master unlock key for a Vault in an HSM, but all of the keys Vault works with will still be in Vault, in memory.

3. foobiekr ◴[06 May 23 23:32 UTC] No.35846357[source]▶
HSMs are not secure to sustained competent hardware attacks. This should have been on an HSM in multiple secure a signing service facilities with authenticated access and never handed to an OEM of any kind in any form.