How does this defend against a the type of hardware-based attack discussed in the article?

The best guess I've heard is that this attack pulls down the BMC's SPI flash lines in order to corrupt its code as it's loaded.

A proper chain of trust that starts on the BMC chip could absolutely protect against that. At that point any modification to the boot image would leave the BMC refusing to boot rather giving attacker control.

The same way secure-boot provides protection against hardware modification / evil maid type attacks in CPUs today: by verifying the integrity of the code that's about to be booted before the CPU boots it.

It would significantly raise the cost and difficulty of this sort of attack.

> It would significantly raise the cost and difficulty of this sort of attack.

In my opinion, modifying the board layout with the additional chip and modifying the production process for the server boards stealthily already has a pretty high cost and difficulty.

> already has a pretty high cost and difficulty

That's true, but properly implemented secure boot could serve to increase it by an order of magnitude.

Hardware attacks cannot be prevented by secure boot...

The most plausible hypothesis of how this attack works is by corrupting firmware loaded at power-on time over SPI. Secure boot would absolutely protect from that by rejecting the signature of the modified code. By hey, I get that Newsy groupthink means secure boot bad.

>is by corrupting firmware loaded at power-on time over SPI. >Secure boot would absolutely protect from that by rejecting the signature of the modified code. Why couldn't you also change out the keys so the signature does match?

Doing so means compromising the TPM on the BMC module which is much harder to do. It's not something that can be done downstream in the supply chain, as this attack is purported to have been.

Secure boot is in no way bad :-) Ofcourse, it must in fact be the first point on any sane security checklist.

And one of the most common attacks aka. malicious firmware is prevented by using secure boot.

Many other classes of attacks like forcing the microcontroller to delete all its data, opening up the debug JTAG port of the microcontroller, preventing the log of certain security events etc. can be achieved with the right settings.

Though these are just remote possibilities with high levels of complexity, so is changing a production design of a board.

> Hardware attacks cannot be prevented by secure boot...

But by Trusted Computing (at least in some implementations).