1

I want to set up a Windows 10 Pro + Debian dual-boot configuration on my TPM-enabled laptop. The thing is that I want both Windows and Linux partitions to be fully encrypted by Bitlocker. I found a tutorial allowing me to boot to Linux from Windows bootloader, so that the Secure Boot chain doesn't break. I haven't tried it yet, but it sounds promising and I wonder if I could use this hack to make Bitlocker unlock my drive before booting to GRUB.

Will it work? Or can it be done even simpler?

edit: there are many many threads all over the internet that, i believe, answer the question of installing unprotected linux next to bitlocker-encrypted win10. that's not what i refer to here

ruplet
  • 23

2 Answers2

1

No.

First off, the hack you find bypasses GRUB. Secondly, you don't unlock Bitlocker and hand off to the OS. All reads/writes of a bitlocker encrypted device run through Bitlocker. The TPM only secures the boot process and derives the key.

I'm not sure its possible to do what you are attempting, but if it is, it will require a Linux distro/nechanism that uses TPM and secureboot and then using dislocker once Linux has booted to decrypt/mount the Windows partition. [Assuming yoy continue down this path, rather then go the VM root].

You can't fully protect the boot process if you use regular GRUB to boot, as GRUB is not TPM aware and is part of the boot process. (There are things like securegrub which might help). Really though, a Linux VM or WSL may be a simpler, more secure solution.

davidgo
  • 73,366
1

I wonder if I could use this hack to make Bitlocker unlock my drive before booting to GRUB.

Most of the time, BitLocker is used in "software encryption" mode. In this mode, such tricks won't be of much use at all because there is no such thing as "unlocking the drive" – the drive itself is not "locked", it merely stores data that was encrypted, and the bootloader and the OS themselves do all encryption/decryption manually (and independently from each other). In other words, neither the drive nor the system firmware are even aware of any encryption happening.

So even if the Windows Boot Manager unlocks the BitLocker encryption layer for its own purposes, this will remain entirely within the boot manager's memory and will not automatically be passed on to GRUB nor to Linux. Similarly, when GRUB unlocks a LUKS partition, this remains invisible to Linux or whatever else is booted from it.

The other mode – OPAL "hardware encryption" – is the complete opposite: it does lock the whole thing, and the drive does in fact remain unlocked after a bootloader unlocks it. Maybe that's what you're looking for? However, it is only supported by a few SSD models (not by HDDs), it hasn't gained much trust security-wise, and it does not seem dual-boot friendly at all.

I found a tutorial allowing me to boot to Linux from Windows bootloader, so that the Secure Boot chain doesn't break.

Actually, that's precisely how you would break the Secure Boot chain. You have a signed bootloader (the Windows Boot Manager) and you're telling it to run completely arbitrary boot code with no signature on it – exactly the sort of thing that BitLocker's Secure Boot integration is supposed to prevent.

Besides that, Secure Boot means UEFI. But the linked tutorial talks about MBR bootcode, which does not apply here – the EFI boot process is completely different. (Even though most EFIs have a compatibility BIOS emulation mode, it's mutually exclusive with Secure Boot.)

Also, in UEFI, the Windows Boot Manager refuses to start third-party EFI applications even if you did add one. Even if you do have Secure Boot-compatible Linux EFI files and adapt the 'bcdedit' commands to EFI (e.g. grubx64.efi instead of mbr.bin), they'll still boot you into an error screen instead.

You can still dual-boot – but you will need to use the firmware's own boot menu (usually the one that shows up when you press Esc or F8) whenever you decide to boot Linux.

A side note: BitLocker's TPM support does not actually require Secure Boot; it only requires the TPM Event Log to work. It is true that BitLocker prefers having Secure Boot available (so it can seal the disk keys against the signature chain found in the Event Log), but if that's unavailable, it'll use a different part of the Event Log which records the exact hashes of bootloaders that were used and such.

If you run manage-bde c: -protectors -get the non-SB sealing mode will be indicated by "PCRs: 0, 1, 4, 7" or something like that.

The downside of this mode is that it's more sensitive to e.g. EFI boot menu changes or partition table changes, and especially Windows kernel/bootloader updates (as all of those are hashed and accounted in PCRs 0/1/4/7), so you should always have the numeric recovery password handy. (For comparison, the SB-aware mode only seals the key against the boot order and the Secure Boot signing certificates, so it's less fragile but perhaps also less secure against downgrade attacks.)

BitLocker will also do this if Secure Boot is available but the chain is not entirely trusted. For example, even if you have a signed and Secure Boot aware GRUB, you still cannot chain GRUB→Windows – it'll boot the OS, yes, but BitLocker will still insist on using basic PCR-based sealing and will refuse to use Secure Boot-based sealing.

So in the end, if you want to dual-boot on encrypted disks, you will need to let Windows and Linux do their own things: you can keep using BitLocker for the Windows partitions, but Linux will need to handle its own decryption for its own root partition (LUKS is the preferred choice).

However, there are relatively easy ways to achieve automatic TPM-based unlocking for Linux, and they can even be used on dual-boot systems without disrupting Windows.

(Shared data partitions can continue to use BitLocker – their keys are always file-based or password-based, never TPM-sealed, so Linux can unlock them using regular tools such as Dislocker or cryptsetup.)

grawity
  • 501,077