Hello Marcus,
Thank you for your detailed answer, it is very kind and much appreciated!
It's very clear and I think I got it.
My confusion came from the Microsoft litterature, which kind of mixes the two concepts (example: https://docs.microsoft.com/windows/security/information-protection/secure-th...).
Whereas, in the Linux implementation, Trusted boot is apart and has different goals (measurement for a remote server) and as of now, no UEFI support.
One last question: in the Linux/open source world, do you know of a software that can be used on a server for remote attestation?
It does not seem very popular, so far I found a solution from IBM but not much else.
Have a nice day,
JC
18.02.2020, 08:02, "Marcus Meissner"
Hi,
On Sun, Feb 16, 2020 at 10:54:30AM +0100, jc@phocean.net wrote:
Hello here,
I just found this post about a feature that I was not aware of, and seems to result from a patch that is very specific to openSUSE, namely Trusted Boot:
https://lizards.opensuse.org/2016/05/18/highlights-of-yast-development-sprin...
1) About Secure Boot
I have been using SecureBoot for a while, and here is my understanding of Secure Boot in openSUSE:
- the root of trust is the UEFI ;
Yes.
- it does use the TPM for cryptographic measurements ;
No. TPM is related, but not used here I think.
- Shim in the EFI partition is the first component to check the signature of grub, then subsequently the chain continues from the kernel up to the modules.
Correct.
It works pretty well, except that most distributions have an implementation flaw (e.g Ubuntu, Fedora): as long as /boot has not been encrypted, an attacker with physical access to the machine can alter the initrd, do nasty stuff (like hijacking the user encryption password) and then proceed with the boot execution normally. I can confirm this flaw for sure as this is something that we have tested at my work.
This is an issue, yes.
In openSUSE, /boot is encrypted by default and Grub has been patched to prompt for decryption, so this is a good mitigation against these "evil maid attacks".
Well no ... While /boot is not encrypted by default, it can be selected to be the encrypted easily.
Overall, did I get it correctly ?
Largely :)
2) About Trusted boot
The documentation is sparse so I am confused on how it compares with the SecureBoot implementation above.
My understanding is that it's exactly the same, except that it's some kind of legacy support for Grub and legacy BIOS, without UEFI.
It's not clear here what's the root of trust: I guess this can only be Grub itself, storing measurements in the TPM.
Again, thank you for telling me if I am correct or wrong...
Trusted Boot is a bit of weirdly to think about.
Every boot step is measured (depending on method via hashes of code or so), and if sufficient proof can be shown (using a hash) the next TPM register slot is unlocked, and so forth.
This avoids bad parties inserting code itself after the initial chain creation, but it does not stop the system from working. The code would just not unlock the next TPM slots.
The idea for TPM was that DRM media would only be played if you would prove a valid trust chain from booting -> media player, using this method, with all steps "approved" in between to avoid reverse engineering or sniffing.
General idea:
- UEFI secure boot stops your system hard from booting when someone meddled with it. It is largely for "self protection".
- TPM is more like a "proof of identity" chain that can be presented. So basically the system providing "proof of identity and correct procedures" to outside parties, e.g. DRM or other Trusted Computing.
Following your feedback, it might be a good idea that I write some stuff in the wiki or/and my blog to clarify all this.
I hope it is a bit more clear.
Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org