[opensuse-security] need for clarifications between Secure Boot and Trusted Boot
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 ; - it does use the TPM for cryptographic measurements ; - 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. 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. 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". Overall, did I get it correctly ? 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... 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. Thank you ! Best regards, Jean-Christophe -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
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
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
Hi, Secure boot provide very few security IMHO, but yes, better than nothing. One major problem with secure boot is on many hardwares you do not have choice to enroll your own key, that is why we have shim afaik. Although MOK can be used for development purpose, but in that case shim itself is still need to be signed by KEK or a Microsoft-issued certificate, so you do not have fully control of your booting progress, and still vulnerable if there are problems (eg. key leakage) with KEK or even PK. Another issue with secure boot is the inherence form propriatery implementation of firmwares, which makes it impossible for 3rd party to audit on this critical layer. You also have to depend on hardware manufacturer release fireware updates to fix vulnerabilities (in most cases they don't or do it very late). Fireware updates is not so easy comparing to software, many users tend to refuse or ignore. On Tue, Feb 18, 2020 at 08:02:01AM +0100, Marcus Meissner wrote:
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
-- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (3)
-
jc＠phocean.net -
Marcus Meissner -
wnereiz