Can a physical attacker compromise a Windows machine with UEFI, secure boot and bitlocker?
After conducting extensive research on the Bitlocker platform, I believe I can answer my own question.
Key reference: Bitlocker Drive Encryption Technical Overview
In our default setup (at least on MS Surface Pro 3), Bitlocker, UEFI and Secure Boot are on. There is TPM 2.0 enabled. The UEFI is not password protected, and the boot order allows USB before SSD.
Attackers have the interest in booting into an alternative OS because popular password cracking tools like Ophcrack run from Linux (actually it wouldn’t work on the Surface Pro 3 because it is a class 3 UEFI device that does not support Legacy BIOS mode). In addition, if the hard disk is not encrypted, the alternate OS has the liberty to read the files from the hard disk, and even “reset” the Windows password by messing around with the Windows SAM and registry.
In our scenario, since Bitlocker encryption is on, the hard disk partition is encrypted so an alternate booted OS will not be able to see our files.Also, the TPM will conduct an integrity check on the pre-boot components and will realize we are booting into another system, and thus will not release the keys needed to decrypt the hard disk partition. Furthermore, one cannot simply boot a Live Linux USB, or install Linux on the hard disk, since Secure Boot would not allow that. Can we just turn off Secure Boot, since there is no password protection on the UEFI settings?
Yes, an attacker has the ability to turn off Secure Boot and boot into an alternate OS. However, that is not a concern because the default Bitlocker policy will use Secure Boot for integrity validation as well, and turning off Secure Boot will trigger the Bitlocker recovery key lockout. The attacker should not have the recovery key in his possession and brute forcing it is infeasible. Since the attacker cannot go past the recovery key screen, the hard disk will not be decrypted and the data remains protected. An intelligent user should also sense that something is up if he is prompted for the recovery key for no legitimate reason like a system update (in case we are afraid of Evil Maid attacks).
In the UEFI settings, the attacker could also turn off the TPM protection. This will definitely trigger the Bitlocker recovery key lockout because Bitlocker relies on TPM for its usual decryption keys. Therefore, it is pointless to do so.
Therefore, while it is possible to make the system “more secure” by password protecting the UEFI, it does not seem necessary to do so.
In addition, Surface Pro 3 is certified as a ‘Connected Standby’ device. In other words, we don’t have to go to the extremes of always shutting down the device or putting it to hibernate for added security in some configurations. We don’t really need to have pre-boot authentication also (i.e. just have TPM-only authentication). It does not have any DMA ports, so DMA attack is not possible. It is not susceptible to Cold Boot attacks, since system memory cannot be easily removed. See this reference article.
In his talk on ‘Building a Bulletproof Bitlocker’, Sami Laiho mentions that TPM-only authentication is good enough for 90% of people. If you’re interested, he talks about Bitlocker and added configurations that you could set up (for general devices, not just the Surface Pro).
Note that encryption does not prevent the attacker from writing over the hard disk with random bits.
Additional reading: Comments on Bitlocker
Note: there may be backdoors and implementation errors which are unknown. The answer here is based on available information from Microsoft and general knowledge about FDE systems. It also assumes that the TPM can be trusted and that brute forcing the encryption itself is "infeasible" without a very fast supercomputer (i.e. will take "too many" lifetimes to break at present time). That said, feel free to point out additional vulnerabilities so that we can be more aware of the potential threats and under which circumstances we should be concerned about them (i.e. assumptions about the attacker). I would just like to comment that a vulnerability in a part of the system does not immediately imply that an attacker can engineer a successful attack to extract information from it, although it indeed does increase the chance of success.
There is an entire literature in the Blackhat and Defcon communities showing how to exploit the software that manages TPMs, retrieve secret keys from the TPM by interposing on the communication between the TPM and the CPU, and other attacks. The answer above by Kevinze and his followup comments are simply not accurate (he/she argues that such exploits are only theoretical). Section 5 in this paper gives a brief summary of some known ways to exploit TPMs: https://www.blackhat.com/docs/us-14/materials/us-14-Weis-Protecting-Data-In-Use-From-Firmware-And-Physical-Attacks-WP.pdf