Gfrktyl

I'm exploring the security of Bitlocker when combined with TPM and secure boot (and no password for Bitlocker or BIOS), and am struggling with something -

Does/How does Windows protect the early boot process?

For example - Lets say a computer with the bitlocker encrypted drive is stolen, but the thief does not know login credentials to get into Windows. What, if any, protections are in place to prevent the thief making changes to the early boot environment to allow the theif to add/change a password/get a shell without requiring a valid login?

Possibly begging the question, but is the early boot process signed/measured in such a way as to prevent this attack vector, and if so, how?

Bonus if anyone can advise of a way to actually bypass the Bitlocker/TPM protection/chain without using the Bitlocker recovery key. (I believe there is/theoretically was a mechanism to abuse the Windows upgrade process to bypass this protection, but I've no idea how this would be implemented or how hard - or if there are simpler ways)

To clarify elements of my post:

At this link, Microsoft says "The TPM-only authentication mode is easiest to deploy, manage, and use. It might also be more appropriate for computers that are unattended or must restart while unattended. However, the TPM-only mode offers the least amount of data protection. If parts of your organization have data that is considered highly sensitive on mobile computers, consider deploying BitLocker with multifactor authentication on those computers." - I am trying to quantify this risk.

When I say "early boot process", I'm talking about when Windows takes over booting, but before the main OS has been loaded (ie the stub/initial bit which loads the Bitlocker driver and other early processes which are found on the non-encrypted partition which bitlocker drives have - and then hands off to the main boot)

How does Windows protect the early boot process?

Windows does not attempt to protect the early boot process (anything that happens before the Windows Bootloader). Secure Boot, a UEFI feature, accomplishes this task. When configuration changes are detected BitLocker will require you to provide the recovery key. This prevents an HDD from being pulled from a machine and placed into another one without the BitLocker Recovery key being provided. A system disk protected by BitLocker, mounted within Windows, cannot be unlocked without the recovery key.

What, if any, protections are in place to prevent the thief making changes to the early boot environment to allow the thief to add/change a password/get a shell without requiring a valid login?

If any changes to the TPM are detected, BitLocker will prompt, for the recovery key. If any changes are made to the UEFI firmware, BitLocker will prompt, for the recovery key. Since BitLocker is a full disk encryption there isn't a way to access the data without the recovery key.

Possibly begging the question, but is the early boot process signed/measured in such a way as to prevent this attack vector, and if so, how?

Secure Boot prevents from booting into unsigned operating systems.

Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.

Source: Secure boot

Can anyone advise of a way to actually bypass the Bitlocker/TPM protection/chain without using the BitLocker recovery key.

If such a vulnerability exists with BitLocker it has not been made public.

I believe there is/theoretically was a mechanism to abuse the Windows upgrade process to bypass this protection, but I've no idea how this would be implemented or how hard - or if there are simpler ways

This theoretical mechanism to bypass BitLocker protection does not exist as you describe it. In order to boot into the Windows installation environment, one would need to change the firmware configuration of the device, which would then result in the recovery key being required to decrypt the data. Additionally, you cannot install Windows over itself, on an encrypted volume from within the installation environment.

However, the TPM-only mode offers the least amount of data protection. If parts of your organization have data that is considered highly sensitive on mobile computers, consider deploying BitLocker with multifactor authentication on those computers.

I don't believe this applies to TPM 1.2. The documentation you link to is from Windows Vista which does NOT support TPM 1.2.

When I say "early boot process", I'm talking about when Windows takes over booting, but before the main OS has been loaded (ie the stub/initial bit which loads the BitLocker driver and other early processes which are found on the non-encrypted partition which BitLocker drives have - and then hands off to the main boot)

So you mean the Windows Bootloader. As I indicated, any configuration change will result in the Recovery Key being required to decrypt the data.