4 ms·

When I read this, I expected there to be some discussion about the chain of custody, verification of the signature of microcode updates, or possible injection a

When I read this, I expected there to be some discussion about the chain of custody, verification of the signature of microcode updates, or possible injection attacks, but none of that is mentioned here. I think those are the real reasons that people are afraid of microcode...even in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified.

deleted 4y ago
[deleted]
muricula 4y ago
They're signed and I believe encrypted by Intel. The CPU will fail to apply a microcode update whose signature fails validation. Here's the best public discussion about the format of microcode updates I know of offhand: http://www.inertiawar.com/microcode/ http://www.inertiawar.com/microcode/
- 1letterunixname 4y ago
  They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files. Intel microcode update secret key revealed https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/ https://arstechnica.com/gadgets/2020/10/in-a-first-researche... https://ieeeaccess.ieee.org/featured-articles/reverseengineering_intel_microcode/ https://ieeeaccess.ieee.org/featured-articles/reverseenginee... https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tree/main/intel-ucode https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... https://github.com/platomav/CPUMicrocodes https://github.com/platomav/CPUMicrocodes It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.
  - monocasa 4y ago
    For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked. Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode https://github.com/RUB-SysSec/Microcode
bastawhiz 4y ago
You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them. > in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified How is this different than any other piece of software?
- worthless-trash 4y ago
  Reproducible builds.

deleted 4y ago

[deleted]

muricula 4y ago

They're signed and I believe encrypted by Intel. The CPU will fail to apply a microcode update whose signature fails validation. Here's the best public discussion about the format of microcode updates I know of offhand: http://www.inertiawar.com/microcode/ http://www.inertiawar.com/microcode/

1letterunixname 4y ago
They have been partially reversed and ==maybe== definitely cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files. Intel microcode update secret key revealed https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/ https://arstechnica.com/gadgets/2020/10/in-a-first-researche... https://ieeeaccess.ieee.org/featured-articles/reverseengineering_intel_microcode/ https://ieeeaccess.ieee.org/featured-articles/reverseenginee... https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tree/main/intel-ucode https://github.com/intel/Intel-Linux-Processor-Microcode-Dat... https://github.com/platomav/CPUMicrocodes https://github.com/platomav/CPUMicrocodes It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.
- monocasa 4y ago
  For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked. Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode https://github.com/RUB-SysSec/Microcode

bastawhiz 4y ago

You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them. > in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified How is this different than any other piece of software?

worthless-trash 4y ago
Reproducible builds.