How to boot Windows when Bitlocker enabled with key sealed in TPM

How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

Hi,

It's increasingly common to see Windows 10 systems with full disk
encryption (BitLocker) enabled out of the box, with the encryption key
sealed in the TPM 2.0. [1][2][3]

The system uses Measured Boot to determine if boot related components
have been tampered with, and if not, the BitLocker key is unsealed by
the TPM, and the system boots normally.

The problem is that with dual boot Linux systems, typically this means
shim followed by GRUB are loaded, altering the PCR values used for
sealing the BitLocker key, and the key is not unsealed. That means the
user is left looking at a BitLocker recovery window instead of getting
a successful boot whenever they boot the GRUB menu entry, e.g.:

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/nvme0n1p1)' --class windows
--class os $menuentry_id_option 'osprober-efi-DA43-2963' {
    insmod part_gpt
    insmod fat
    search --no-floppy --fs-uuid --set=root DA43-2963
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

One idea I've heard floated is, having GRUB alter efivars such that
BootNext is changed to do a one time boot of Windows, instead of using
chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
efi variable? This has the benefit of working even on UEFI systems
which aren't BitLocker encrypted.

Can GRUB modify efivars now? If not, what work would be needed to
enable GRUB to modify efivars? Alternatives?


[1] https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures
[2] BitLocker Encryption is enabled, by default, on computers that
support Modern Standby.
https://support.hp.com/us-en/document/c06458046
[3] I have a Lenovo Thinkpad X1 Carbon Gen 7, fairly popular hardware
but also not the newest available, it came with Windows 10
preinstalled. And Bitlocker was enabled out of the box. I wiped the
laptop clean and installed Windows 10 from ISO downloaded from
microsoft.com. Same thing, following the clean install, full disk
encryption is enabled. I did not opt-in. This likely will expand due
to the Windows 11 requirement that supporting hardware have TPM 2.0.

-- 
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

Found this:

[PATCH v1 2/2] core: commands: efi: add commands to get/set EFI vars
https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00027.html

But I haven't seen any discussion on whether to support get/set EFI
vars. Would it be possible to constrain the support to setting just
"BootNext" for this use case? Or else I guess distros need to consider
removing the creation of a Windows menu entry, as there's no point
creating menu entries that don't work.

--
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Lennart Sorensen]

On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> One idea I've heard floated is, having GRUB alter efivars such that
> BootNext is changed to do a one time boot of Windows, instead of using
> chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
> efi variable? This has the benefit of working even on UEFI systems
> which aren't BitLocker encrypted.
> 
> Can GRUB modify efivars now? If not, what work would be needed to
> enable GRUB to modify efivars? Alternatives?

I am pretty sure I have read of cases where systems used such low quality
flash for their UEFI variables that they broke after being written too
many times.  I think Ubuntu had a bug that caused it to rewrite some
UEFI variable ever boot that initially spotted the problem or something
like that.  Cheap flash is often 10000 writes or even less in some cases.

But rewriting the variable each time you boot sounds like a "Don't do
that" thing.

-- 
Len Sorensen

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
>
> On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > One idea I've heard floated is, having GRUB alter efivars such that
> > BootNext is changed to do a one time boot of Windows, instead of using
> > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
> > efi variable? This has the benefit of working even on UEFI systems
> > which aren't BitLocker encrypted.
> >
> > Can GRUB modify efivars now? If not, what work would be needed to
> > enable GRUB to modify efivars? Alternatives?
>
> I am pretty sure I have read of cases where systems used such low quality
> flash for their UEFI variables that they broke after being written too
> many times.  I think Ubuntu had a bug that caused it to rewrite some
> UEFI variable ever boot that initially spotted the problem or something
> like that.  Cheap flash is often 10000 writes or even less in some cases.
>
> But rewriting the variable each time you boot sounds like a "Don't do
> that" thing.

Not every boot. Just when the user picks the Windows entry in the
menu. Anyway, the death of NVRAM is orthogonal to the issue, which is
that the current paradigm isn't working for newer systems. Eventually
it'll be the common case. So is the idea to just leave it broken, or
fix it? At a certain point it makes more sense to stop creating
Windows boot entries if they're not going to work.

Also, systemd-boot is going to support BootNext.
https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe



-- 
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Lennart Sorensen]

On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> <lsorense@csclub.uwaterloo.ca> wrote:
> >
> > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > > One idea I've heard floated is, having GRUB alter efivars such that
> > > BootNext is changed to do a one time boot of Windows, instead of using
> > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
> > > efi variable? This has the benefit of working even on UEFI systems
> > > which aren't BitLocker encrypted.
> > >
> > > Can GRUB modify efivars now? If not, what work would be needed to
> > > enable GRUB to modify efivars? Alternatives?
> >
> > I am pretty sure I have read of cases where systems used such low quality
> > flash for their UEFI variables that they broke after being written too
> > many times.  I think Ubuntu had a bug that caused it to rewrite some
> > UEFI variable ever boot that initially spotted the problem or something
> > like that.  Cheap flash is often 10000 writes or even less in some cases.
> >
> > But rewriting the variable each time you boot sounds like a "Don't do
> > that" thing.
> 
> Not every boot. Just when the user picks the Windows entry in the
> menu. Anyway, the death of NVRAM is orthogonal to the issue, which is
> that the current paradigm isn't working for newer systems. Eventually
> it'll be the common case. So is the idea to just leave it broken, or
> fix it? At a certain point it makes more sense to stop creating
> Windows boot entries if they're not going to work.
> 
> Also, systemd-boot is going to support BootNext.
> https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe

Well every time you boot windows counts as every boot.  Perhaps not
every boot of the system.  Still seems like way too often at least.

Secureboot combined with dual (or more) booting sure does seem like a
huge mess.

-- 
Len Sorensen

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

On Thu, Feb 10, 2022 at 12:29 PM Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
>
> On Thu, Feb 10, 2022 at 11:46:33AM -0700, Chris Murphy wrote:
> > On Thu, Feb 10, 2022 at 10:18 AM Lennart Sorensen
> > <lsorense@csclub.uwaterloo.ca> wrote:
> > >
> > > On Mon, Feb 07, 2022 at 04:48:43PM -0700, Chris Murphy wrote:
> > > > One idea I've heard floated is, having GRUB alter efivars such that
> > > > BootNext is changed to do a one time boot of Windows, instead of using
> > > > chainloader. If BIOS, use chainloader as now. If UEFI, set BootNext
> > > > efi variable? This has the benefit of working even on UEFI systems
> > > > which aren't BitLocker encrypted.
> > > >
> > > > Can GRUB modify efivars now? If not, what work would be needed to
> > > > enable GRUB to modify efivars? Alternatives?
> > >
> > > I am pretty sure I have read of cases where systems used such low quality
> > > flash for their UEFI variables that they broke after being written too
> > > many times.  I think Ubuntu had a bug that caused it to rewrite some
> > > UEFI variable ever boot that initially spotted the problem or something
> > > like that.  Cheap flash is often 10000 writes or even less in some cases.
> > >
> > > But rewriting the variable each time you boot sounds like a "Don't do
> > > that" thing.
> >
> > Not every boot. Just when the user picks the Windows entry in the
> > menu. Anyway, the death of NVRAM is orthogonal to the issue, which is
> > that the current paradigm isn't working for newer systems. Eventually
> > it'll be the common case. So is the idea to just leave it broken, or
> > fix it? At a certain point it makes more sense to stop creating
> > Windows boot entries if they're not going to work.
> >
> > Also, systemd-boot is going to support BootNext.
> > https://github.com/systemd/systemd/pull/22043/commits/661615a0afacee3545cde0a48286c0fef983f8fe
>
> Well every time you boot windows counts as every boot.  Perhaps not
> every boot of the system.  Still seems like way too often at least.

If you boot windows once a day, it's changing what, 1-4 bytes, per
day? The entry for Windows is already in NVRAM, it doesn't need to be
written each time. You're only changing the BootNext value that points
to the Windows entry (and then the firmware removes it).

> Secureboot combined with dual (or more) booting sure does seem like a
> huge mess.

This is not Secure Boot. It's measured boot. They're using the TPM to
measure the bootchain and make sure it hasn't been tampered with
before revealing the encryption key. If the user has written down the
recovery key, they can still boot from the BitLocker recovery window,
but that's an untenable default user experience following the
installation of a Linux distro. It's a 48 digit key.



-- 
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Lennart Sorensen]

On Thu, Feb 10, 2022 at 02:13:43PM -0700, Chris Murphy wrote:
> If you boot windows once a day, it's changing what, 1-4 bytes, per
> day? The entry for Windows is already in NVRAM, it doesn't need to be
> written each time. You're only changing the BootNext value that points
> to the Windows entry (and then the firmware removes it).

Well the fact you are only rewriting nextboot with a few bytes is probably
still a potential problem since from what I have seen, these simple SPI
flash chips that seem to often be used tend not to have wear leveling.
They don't expect a lot of writes.

Ideally the UEFI NVRAM should be battery back ram, but that doesn't seem
to be how a lot of systems actually implement it.  If they expect you
to install windows and run it, they don't need to support rewriting a lot.

> This is not Secure Boot. It's measured boot. They're using the TPM to
> measure the bootchain and make sure it hasn't been tampered with
> before revealing the encryption key. If the user has written down the
> recovery key, they can still boot from the BitLocker recovery window,
> but that's an untenable default user experience following the
> installation of a Linux distro. It's a 48 digit key.

Oh right for bitlocker.  Even more picky than secureboot.

-- 
Len Sorensen

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

For all practical purposes, this is functionally the end to dual boot
in GRUB, if there is no work around, e.g. bootnext. Is that the
direction GRUB maintainers want to go in?

--
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Vladimir 'phcoder' Serbinenko]

On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> For all practical purposes, this is functionally the end to dual boot
> in GRUB, if there is no work around, e.g. bootnext. Is that the
> direction GRUB maintainers want to go in?
Why don't you just update TPM with new values? Then it will get
unsealed when booted through GRUB
>
> --
> Chris Murphy
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



-- 
Regards
Vladimir 'phcoder' Serbinenko

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
> On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy <lists@colorremedies.com> wrote:
> >
> > For all practical purposes, this is functionally the end to dual boot
> > in GRUB, if there is no work around, e.g. bootnext. Is that the
> > direction GRUB maintainers want to go in?
> Why don't you just update TPM with new values? Then it will get
> unsealed when booted through GRUB

How?

The key is sealed in the TPM so first we need to get the key in order
to (re)seal it with new PCR values. Correct? So we somehow need a way
to boot only the Windows bootloader in order for measured boot to
unseal the key, and then we'd need to somehow measure
shim+grub+windows bootloaders together in order to seal the key with
the new values for those three bootloaders used in that sequence. I
have no idea if that's practical at all.

The recovery key is not the one sealed in the TPM, they are separate
keys in separate "keyslots".


-- 
Chris Murphy

Re: How to boot Windows when Bitlocker enabled with key sealed in TPM

[Chris Murphy]

On Fri, Mar 25, 2022 at 5:00 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Fri, Mar 25, 2022 at 2:32 PM Vladimir 'phcoder' Serbinenko
> <phcoder@gmail.com> wrote:
> >
> > On Fri, Mar 25, 2022 at 9:14 PM Chris Murphy <lists@colorremedies.com> wrote:
> > >
> > > For all practical purposes, this is functionally the end to dual boot
> > > in GRUB, if there is no work around, e.g. bootnext. Is that the
> > > direction GRUB maintainers want to go in?
> > Why don't you just update TPM with new values? Then it will get
> > unsealed when booted through GRUB
>
> How?
>
> The key is sealed in the TPM so first we need to get the key in order
> to (re)seal it with new PCR values. Correct? So we somehow need a way
> to boot only the Windows bootloader in order for measured boot to
> unseal the key, and then we'd need to somehow measure
> shim+grub+windows bootloaders together in order to seal the key with
> the new values for those three bootloaders used in that sequence. I
> have no idea if that's practical at all.
>
> The recovery key is not the one sealed in the TPM, they are separate
> keys in separate "keyslots".

The next problem is that when there's a Linux system update the
updates either shim or grub, the shim+grub+windows bootloader
measurements have changed and will again fail to unseal the key. It's
indistinguishable from the system having been compromised. And now you
get to do a clean install of Windows and Linux to get back to
functional.

Further, should the user need to reinstall Linux, or even boot Windows
directly from the firmware's boot manager - they wouldn't be able to.

This all sounds quite a lot more difficult than GRUB having the
ability to set a bootnext efi variable, and just reboot - let the
Windows bootloader handle all of this, and not involve Linux
bootloaders.


-- 
Chris Murphy