need for clarifications between Secure Boot and Trusted Boot

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

need for clarifications between Secure Boot and Trusted Boot

Bugzilla from jc@phocean.net
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-sprint-19/


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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: need for clarifications between Secure Boot and Trusted Boot

Marcus Meissner
Hi,

On Sun, Feb 16, 2020 at 10:54:30AM +0100, [hidden email] 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-sprint-19/
>
>
> 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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: need for clarifications between Secure Boot and Trusted Boot

Bugzilla from jc@phocean.net
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-the-windows-10-boot-process).

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" <[hidden email]>:

> Hi,
>
> On Sun, Feb 16, 2020 at 10:54:30AM +0100, [hidden email] 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-sprint-19/
>>
>>  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: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: need for clarifications between Secure Boot and Trusted Boot

wnereiz-2
In reply to this post by Marcus Meissner
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, [hidden email] 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-sprint-19/
> >
> >
> > 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: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]