> To prevent (in theory) various attack vectors (e.g., physical access to
the disk while offline), you need to have the system in a trusted state.

> Somebody has already thought this through, here is the result:
>
http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#Secure_boot

> Such a fully trusted, BSD-licensed OpenBSD boot chain, where I can put my
own keys into the BIOS, would be nice to have. Good luck writing it ;)

Secure Boot only protects the boot loader, and potentially the kernel and
it's drivers *if* the boot loader implements that. Any other system file on
the disk is totally unprotected, even in a OS like Windows 8+ which has
implemented a "fully" signed boot chain (through the kernel and it's
drivers). This means that even a system using Secure Boot is very easy to
root with offline physical access.

You actually could expand Mr. Nelson's proposal into something more
interesting by starting with a Windows-style fully signed boot chain
(through the kernel) and then also verifying launched binaries in the
manner he suggests. This would ostensibly resist all attempts to tamper
with the kernel or system binaries, even with offline physical access.
However, it wouldn't protect anything else, including configuration files,
which would still leave gaping holes open to the offline physical access
attack. It also could not be configurable and it would need to hard code
the keys, which strikes me as inelegant and inflexible. Seems like an
enormous amount of effort with little return...

FYI... FreeBSD is actually working on implementing Secure Boot right now,
according to their website:

https://wiki.freebsd.org/SecureBoot

Not sure how easy it would be to port to OpenBSD once completed. AFAIK,
OpenBSD doesn't even support UEFI.

I doubt it will ever be possible to really protect a system from an offline
physical access attack. Even if the entire system disk were protected with
an authenticated cipher like AES-GCM, there are plenty of firmware based
attacks that you can prep to launch as soon as the system is turned back on.

Reply via email to