3 ms·

I’m not completely sure about the attack scenario here. It seems that a bitlocker key is stored unencrypted (no master password) on the TPM device. This seems

I’m not completely sure about the attack scenario here. It seems that a bitlocker key is stored unencrypted (no master password) on the TPM device. This seems to imply that I could boot the laptop without entering a password anyway, and get access to the disk. What would the point of such external device be? Is bitlocker designed to only prevent stealing the hd separately from the laptop? Or is anything in the protocol that makes it so that the boot code, after reading the master key, forces the user to enter a password nevertheless to access the hard drive contents? But it still looks like that if I can hijack this boot process (external usb boot?) I could get access to the drive contents. Disclosure: unfamiliar with bitlocker but I have used and understand FDE on Linux and FileVault.

shawnz 3y ago
The TPM collects some measurements to verify that you actually booted to the correct operating system before releasing the key. From there, the system is protected by the operating system's login screen.
plugin-baby 3y ago
I’m also confused. If a laptop is stolen while off, can this attack still be applied?
- qingcharles 3y ago
  Yes.
  - plugin-baby 3y ago
    That’s not good.
gizmo686 3y ago
The core concept that makes TPMs work (in this usecase) is the Platform Control Registers (PCR). The idea behind the PCRs is to allow the TPM to know that the overall system is in a known state. In particular, there are 2 operations that can be performed on a PCR: read and extend. Read does what it sounds like, and gives you the current value of the PCR. Extend concats the current value of the PCR with a provided value, and hashes the result back into the PCR: PCR[i] <- Hash ( PCR[i] || data ). The TPM also has a small amount of general purpose non-volatile storage (NVRAM). It lets you "seal" entries in NVRAM such that it will only give you them if particular PCRs have particular values. UEFI along with most modern bootloaders and operating systems incorporate this into the boot process such that a component will measure all critical configuration parameters and executables before operating on them. To take your USB boot example, before the UEFI boots into your USB it will measure (at least) the bootloader on your USB drive. As soon as that happens, there is no way to get the PCRs into the required state without breaking the hashing algorithm. Even if your USB drive uses the window's bootloader, the UEFI likely measured other things, such as the device it was booting off of, and possibly your entry into the one-time boot menu [1]. Even if you get through all of that, the Window's bootloader probably measures the code it runs. By the time you get to code you can actually change without invalidating the PCRs, you are running inside of Window's userspace subject to normal software security measures; and Window's might have already modified one of the appropriate PCRs (or simply locked the NVRAM for further reads until system reset). There are several potential problems with this: 1) It assumes that all of the components in the chain are secure and do the right thing. If you can convince one to run your code without changing what it measures, then you can attack the system. 2) It assumes the entire system is an atomic unit. If you can talk to the TPM directly, you can simply measure in the same values that get measured during a normal boot, weather you are actually booting, or have the TPM on a breakout board. The measurement inputs to the TPM are not secret. They are just hashes of firmware, kernels, etc. 2.5) What this paper talks about, none of the communication to/from the TPM is encrypted. TPM backed FDE exists on Linux as well and is vulnerable to the same class of attacks. Some systems have the TPM integrated into the CPU itself, which makes such an attack practically impossible. [0] Or, at least the initial bootloader, which is then responsible for measuring the kernel, which is then responsible for measuring the core OS components, etc). [1] Although, these things are done in a seperate PCR, and BitLocker probably doesn't use all of the PCRs. You don't want to brick a system by simply changing a random setting in the bios.
- alanfranz 3y ago
  Great answer! Thank you so much!

shawnz 3y ago

The TPM collects some measurements to verify that you actually booted to the correct operating system before releasing the key. From there, the system is protected by the operating system's login screen.

plugin-baby 3y ago

I’m also confused. If a laptop is stolen while off, can this attack still be applied?

qingcharles 3y ago
Yes.
- plugin-baby 3y ago
  That’s not good.

gizmo686 3y ago

The core concept that makes TPMs work (in this usecase) is the Platform Control Registers (PCR). The idea behind the PCRs is to allow the TPM to know that the overall system is in a known state. In particular, there are 2 operations that can be performed on a PCR: read and extend. Read does what it sounds like, and gives you the current value of the PCR. Extend concats the current value of the PCR with a provided value, and hashes the result back into the PCR: PCR[i] <- Hash ( PCR[i] || data ). The TPM also has a small amount of general purpose non-volatile storage (NVRAM). It lets you "seal" entries in NVRAM such that it will only give you them if particular PCRs have particular values. UEFI along with most modern bootloaders and operating systems incorporate this into the boot process such that a component will measure all critical configuration parameters and executables before operating on them. To take your USB boot example, before the UEFI boots into your USB it will measure (at least) the bootloader on your USB drive. As soon as that happens, there is no way to get the PCRs into the required state without breaking the hashing algorithm. Even if your USB drive uses the window's bootloader, the UEFI likely measured other things, such as the device it was booting off of, and possibly your entry into the one-time boot menu [1]. Even if you get through all of that, the Window's bootloader probably measures the code it runs. By the time you get to code you can actually change without invalidating the PCRs, you are running inside of Window's userspace subject to normal software security measures; and Window's might have already modified one of the appropriate PCRs (or simply locked the NVRAM for further reads until system reset). There are several potential problems with this: 1) It assumes that all of the components in the chain are secure and do the right thing. If you can convince one to run your code without changing what it measures, then you can attack the system. 2) It assumes the entire system is an atomic unit. If you can talk to the TPM directly, you can simply measure in the same values that get measured during a normal boot, weather you are actually booting, or have the TPM on a breakout board. The measurement inputs to the TPM are not secret. They are just hashes of firmware, kernels, etc. 2.5) What this paper talks about, none of the communication to/from the TPM is encrypted. TPM backed FDE exists on Linux as well and is vulnerable to the same class of attacks. Some systems have the TPM integrated into the CPU itself, which makes such an attack practically impossible. [0] Or, at least the initial bootloader, which is then responsible for measuring the kernel, which is then responsible for measuring the core OS components, etc). [1] Although, these things are done in a seperate PCR, and BitLocker probably doesn't use all of the PCRs. You don't want to brick a system by simply changing a random setting in the bios.

alanfranz 3y ago
Great answer! Thank you so much!