←back to thread

658 points transpute | 7 comments | | HN request time: 1.508s | source | bottom
Show context
dathinab ◴[] No.35844589[source]
I don't understand how such keys can leak?

Hasn't intel heard about locking keys in hardware, e.g. like with hardware security key modules similar but faster/flexibler then a TPM. Surly one of the main developers of TPM does understand that concept.... right? /s

replies(4): >>35844629 #>>35844632 #>>35844776 #>>35844793 #
1. CircleSpokes ◴[] No.35844793[source]
The keys are OEM specific. Intel gives them to MSI so they can sign their firmware/BIOS updates. Clearly MSI didn't handle them well.
replies(1): >>35845874 #
2. emmelaich ◴[] No.35845874[source]
So this is really an MSI key? Not Intel - even if Intel created it.
replies(1): >>35846105 #
3. CircleSpokes ◴[] No.35846105[source]
Intel gave it to MSI, but I may have been incorrect before. Apparently the keys was shared across multiple OEMs (at least that is how I read this below)

>The leaked private keys affect Intel’s 11th, 12th, and 13th generation processors and were distributed to various OEMs, including Intel itself, Lenovo, and Supermicro.

replies(1): >>35846459 #
4. Joker_vD ◴[] No.35846459{3}[source]
...isn't such signing usually done the other way around? Intel would hold the signing keys, MSI (or any other OEM manufacturer) then sends (over a secure channel) their firmware to Intel, Intel signs it and sends the signature back.
replies(1): >>35846500 #
5. CircleSpokes ◴[] No.35846500{4}[source]
I think that would make sense yes. It isn't clear to me why they would distribute the private keys to the OEMs (laziness?).
replies(1): >>35847613 #
6. Arnavion ◴[] No.35847613{5}[source]
The processor has to verify the signature, which means the public key needs to be embedded in the processor. It makes sense that the processor manufacturer creates the keys and distributes them. If it was the other way around, then a) fifty motherboard manufacturers would make their own keys and the processor would need space to embed fifty of them, and b) a new fifty-first motherboard manufacturer coming into the market would be unable to support any existing CPUs. It would also explain why the same key was used for signing multiple motherboard manufacturers' firmware.

Why distribute the keys themselves instead of having some way for the motherboard manufacturers to upload an unsigned firmware and then download a signed one? That is probably laziness.

replies(1): >>35848126 #
7. csdvrx ◴[] No.35848126{6}[source]
If this is the Intel key that's burned on the CPU (or PCH, I forgot) e-fuses, and that manufacturers use to sign their own BIOS and UEFI payloads, do you think this will enable us editing the manufacturer bioses to tweak variables, resign some of their EFI payloads or just remove some of these payloads? (like the ones involved in checking the PCI or USB ids is on an approved whitelist of WWAN and WLAN cards cards)

Like what https://erfur.github.io/2019/03/28/down_the_rabbit_hole_pt3.... could do before BootGuard?

I ask because this would enable a lot more security: I could mod my bios, and add a extras EFI module signed with my key that wouldn't trigger bootguard: then later during the boot, an encrypted grub or whatever could check them, say with a TPM enrolled key having their hashes: this could make the computer refuse to boot further if say the MAC address of the network card (or the CPU serial, or the NVME serial) doesn't match what I added.

Yes, an evil maid attack could do the same to me (by removing these checks I've added and replacing them say by nops), but that would alter their hash.

And if the secure boot payloads signed with my own key first check the existence of these modules, and then verifies that their signature (kept inside my signed payloads matches) my versions (and not the evil maid or the manufacturer original) I'd still get the benefits of secureboot - just with my own keys all the way down.

The it'd be super interesting to have!!