BitLocker asking for protection code after Ubuntu installation
I have just installed Ubuntu side-by-side to a Windows 10 partition shipped on a new laptop.
Meaning, the laptop shipped with Windows 10, and I installed Ubuntu alongside the Windows partition using an Ubuntu Desktop installation ISO through a flash drive.
Now every time I boot into the Windows boot manager, BitLocker wants me to enter the long BitLocker recovery key. A few questions ―
- Why actually is BitLocker affected by the new boot loader set up by Ubuntu? a naive thought would be that the BitLocker decryption key is stored on the motherboard TPM, and isn't affected by a new boot loader installation, and that is probably true as otherwise Windows would no longer be able to read its own files. So why is BitLocker even requiring the recovery key now?
- The Ubuntu side-by-side install said something about fiddling boot protection, but it remains elusive whether that's related to the TPM or a separate security mechanism.
- The Ubuntu installer even asked for a pass-phrase that should help re-establish secure boot, but I was not prompted to use it anywhere after booting with neither the Ubuntu nor the Windows boot loaders, after the install.
- How do I make BitLocker trustful again? in Windows 10, I only see an option to disable disk encryption altogether, but am not sure why can't it just keep going.
- Turning encryption off and then on (in Windows) seems like an overkill and I've no idea, whether it will scramble my Ubuntu partition while at it.
In Windows, after supplying the recovery key, I can see that device encryption is on. So my understanding is that my Windows partition is still decrypting its own files, whereas my Ubuntu partition isn't asking the TPM to encrypt its files when writing them nor decrypt them when reading them.
This issue is that Windows does not consider GRUB as a secure component. Thus, whenever you boot to Windows coming from GRUB, Windows considers the boot sequence might have been compromised, and forces a key re-entry.
The only way I know to fix this is to not use GRUB altogether. You can either
- choose the boot sequence directly through your BIOS menu (the solution I use, I just have to enter F12 during boot, and BIOS gives the choice between the boot scenarios)
- or use Windows bootloader and add the linux options to it (See here how to achieve that).
I solved this by going to "Bitlocker" --> "Suspend Encryption" --> Restart Windows 10 --> Select Windows bootloader in GRUB --> Windows 10 encryption was enabled again but it's not asking anymore for the Encryption long KEY.
I have 1 single SSD with: - Windows 10 (UEFI / GPT) Bitlocker - Ubuntu: (3 partitions: boot, root and home).
I had this problem as well, and I found this workaround by accident:
With my setup, I get GRUB screen, where I can select between these options:
- Ubuntu
- Advanced options for Ubuntu
- Windows Boot Manager (on /dev/sda2)
- System Setup
When I select the Windows Boot Manager option, I get stopped at the BitLocker recovery screen.
However, if I simply hit ESC, I am taken to a GRUB terminal. When I enter exit into the terminal, the terminal disappears, and Windows starts up. With this flow, I don't hit the BitLocker recovery screen.
With a lot of help from the kind people in the comments, I was able to elegantly get past the problem. This was the elegant solution, taken from here:
To make BitLocker regain trust, I simply disabled and then re-enabled BitLocker:
C:\Windows\system32\manage-bde.exe" -protectors -enable c:
C:\Windows\system32\manage-bde.exe" -protectors -disable c:
I assume that now Windows uses BitLocker and disk encryption through the TPM just as before, and Ubuntu simply does not.
It is possible to install some Ubuntu stuff that makes it work like BitLocker (thusly presumably also enabling sharing partitions between Windows and Ubuntu), but I think that for now Ubuntu does not use the TPM hardware, so it would store the entire encryption key on disk, defeating the purpose of the encryption, so not worth it I guess.
So BitLocker was aware of the boot manipulation, justifiably causing it to await a trust regaining event even though the TPM integration remained intact. Entering the protection key and then Using the above couple of commands in Windows, made it re-enter the state of trust, regaining normal operation.