Am 26.09.2018 01:30 schrieb Youness Alaoui:
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads would first lock the flash so it can't be written to. This should add some security to avoid any malware writing to the flash, or someone booting into a USB stick and using that to flash a malicious BIOS, but still gives the user the freedom of updating their flash whenever they want to.
I might be wrong, but since Heads already authenticates to you via TOTP, this wouldn't really add extra security, wouldn't it?
Am 02.10.18 um 13:01 schrieb Martin Kepplinger:
Am 26.09.2018 01:30 schrieb Youness Alaoui:
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads would first lock the flash so it can't be written to. This should add some security to avoid any malware writing to the flash, or someone booting into a USB stick and using that to flash a malicious BIOS, but still gives the user the freedom of updating their flash whenever they want to.
I might be wrong, but since Heads already authenticates to you via TOTP, this wouldn't really add extra security, wouldn't it?
This is the most common misunderstanding about a measured boot. If you don't have separate hardware that starts the measuring (usually you let the firmware measure itself), you need a firmware part that starts the measuring and is read-only for an attacker (referred to as read-only or static `root of trust`). Otherwise you leave the decision what to mea- sure to the attacker (and he can choose to measure the original software before his tampering instead of the running program, and TOTP will still work flawlessly).
So it's the other way around: without this, TOTP doesn't provide any security at all.
Nico
Am 02.10.2018 13:51 schrieb Nico Huber:
Am 02.10.18 um 13:01 schrieb Martin Kepplinger:
Am 26.09.2018 01:30 schrieb Youness Alaoui:
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads would first lock the flash so it can't be written to. This should add some security to avoid any malware writing to the flash, or someone booting into a USB stick and using that to flash a malicious BIOS, but still gives the user the freedom of updating their flash whenever they want to.
I might be wrong, but since Heads already authenticates to you via TOTP, this wouldn't really add extra security, wouldn't it?
This is the most common misunderstanding about a measured boot. If you don't have separate hardware that starts the measuring (usually you let the firmware measure itself), you need a firmware part that starts the measuring and is read-only for an attacker (referred to as read-only or static `root of trust`). Otherwise you leave the decision what to mea- sure to the attacker (and he can choose to measure the original software before his tampering instead of the running program, and TOTP will still work flawlessly).
So it's the other way around: without this, TOTP doesn't provide any security at all.
Nico
thanks! My high-level understanding was that Heads uses the TPM as said "root of trust" and the TOTP shared secret will be lost in any changed firmware.
So a changed firmware would basically need to write PCRs to the TPM in order for the "PCR matching" to succeed and release the valid TOTP secret. Be it by measuring and remembering the original firmware or somehow else.
I don't know why, but I've though that the TPM would prevent a modified firmware to do this -.-
http://osresearch.net/Keys is quite good, but maybe we'd need a wiki with real setups compared, or something. I fear that I'm not the only one who's confused with trusted boot stuff.
As a quick fix, couldn't Heads offer to create an image with the IFD re-locked, in order to force (yourself) to hardware-flashing. Has this been discussed?
thanks
martin
Am 02.10.18 um 14:31 schrieb Martin Kepplinger:
Am 02.10.2018 13:51 schrieb Nico Huber:
Am 02.10.18 um 13:01 schrieb Martin Kepplinger:
Am 26.09.2018 01:30 schrieb Youness Alaoui:
Hi,
I'm trying to add a way to lock the SPI flash to be read-only via software *after* coreboot boots. The scenario is basically with using Heads, you could authenticate to it (with a yubikey/nitrokey/librem key) then be able to flash a new rom (update your BIOS), but once you boot an OS, Heads would first lock the flash so it can't be written to. This should add some security to avoid any malware writing to the flash, or someone booting into a USB stick and using that to flash a malicious BIOS, but still gives the user the freedom of updating their flash whenever they want to.
I might be wrong, but since Heads already authenticates to you via TOTP, this wouldn't really add extra security, wouldn't it?
This is the most common misunderstanding about a measured boot. If you don't have separate hardware that starts the measuring (usually you let the firmware measure itself), you need a firmware part that starts the measuring and is read-only for an attacker (referred to as read-only or static `root of trust`). Otherwise you leave the decision what to mea- sure to the attacker (and he can choose to measure the original software before his tampering instead of the running program, and TOTP will still work flawlessly).
So it's the other way around: without this, TOTP doesn't provide any security at all.
Nico
thanks! My high-level understanding was that Heads uses the TPM as said "root of trust" and the TOTP shared secret will be lost in any changed firmware.
So a changed firmware would basically need to write PCRs to the TPM in order for the "PCR matching" to succeed and release the valid TOTP secret. Be it by measuring and remembering the original firmware or somehow else.
Correct.
I don't know why, but I've though that the TPM would prevent a modified firmware to do this -.-
Alas, they can't (on their own). OTOH, TPMs are already too complex for real security IMO. Adding more features would just weaken it further.
http://osresearch.net/Keys is quite good, but maybe we'd need a wiki with real setups compared, or something. I fear that I'm not the only one who's confused with trusted boot stuff.
As a quick fix, couldn't Heads offer to create an image with the IFD re-locked,
I don't understand why you would unlock the IFD in the first place. But anyway, the usual lock settings only protect the IFD itself and the ME firmware, not the BIOS region for the host firmware (e.g. coreboot). Also, if you'd protect the BIOS region too, coreboot couldn't write to the flash itself anymore which would prevent suspend-to-RAM to work; but maybe you are too security concerned for that anyway ;)
in order to force (yourself) to hardware-flashing. Has this been discussed?
Ofc, it has. And there is even an option in coreboot to lock the flash (after coreboot is done with it). But this is only available for few platforms (Sandy/Ivy Bridge IIRC; config LOCK_SPI_FLASH_RO).
Nico
-
Martin Kepplinger -
Nico Huber