[coreboot] SPI controller and Lock bits

[Nico Huber]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xBD56B4A4138B3CE3.asc
Type: application/pgp-keys
Size: 5227 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181002/428856a0/attachment.skr>