Authenticated Boot and Disk Encryption on Linux
0pointer.net
Authenticated Boot and Disk Encryption on Linux
1–10 of 214 posts
Re: Authenticated Boot and Disk Encryption on Linux
#2Only had time to skim it, but even without all the details it is an excellent overview of the state of the art regarding secure boot chain. You can learn many of the points by looking into the Android boot sequence but this is a more generic and 'everything in a single place' write-up. Especially the mechanisms behind dm-verity seem to be not widely known and - in my view- underappreciated.
> *This is all so desktop/laptop focused, what about servers?
I know that some of the more powerful and Linux based automotive embedded systems use a similar design. While important for desktop/laptop and servers the mentioned points are crucial for systems where physical security of the hardware is limited.
Oh, and BTW, if 0pointer.net i doesn't ring a bell: The author is Lennart Poettering.
Re: Authenticated Boot and Disk Encryption on Linux
#3Re: Authenticated Boot and Disk Encryption on Linux
#4https://github.com/xmikos/cryptboot/blob/master/README.md
I don't think a 5 year old project linked without context is appropriate when talking about modern boot chain security.
It doesn't even support stubs so it fails at the first threat scenario described in this post.
Re: Authenticated Boot and Disk Encryption on Linux
#5This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process.
> The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops.
Re: Authenticated Boot and Disk Encryption on Linux
#6This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, th…
Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
Re: Authenticated Boot and Disk Encryption on Linux
#7>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft
This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?
Re: Authenticated Boot and Disk Encryption on Linux
#8After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader.
I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.
Re: Authenticated Boot and Disk Encryption on Linux
#9This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, th…
Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware.
All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't work.
Re: Authenticated Boot and Disk Encryption on Linux
#10>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?
> Why can't there be an external body that signs these
Just wait a few years, and it will be the government that decides which OSes can run on your hardware. Hint: It will be OSes that only allow "approved" apps to run.