8

I've googled the heck out of this, and have read multiple related questions on this site, but I'm still missing a crucial piece of the puzzle.

I have a (work) laptop with Win10 Pro which is encrypted with Bitlocker. For quite a while I didn't even realise it was encrypted because it doesn't ask for a password on a cold boot. (We used to use TrueCrypt on all of our laptops, so I was accustomed to using a password.) I then decided to check the system and booted it with a Linux live CD. I was able to see the partitions on the disk but was unable to mount the main one - a quick bit of hex dumping showed me that the main NTFS partition was indeed encrypted.

Now, the OS will happily cold-boot all the way to the Windows login screen with NO input from the user (i.e. no PIN/password), which from my googling I have learned happens by dint of the OS automagically extracting the encryption key from the TPM.

What's bothering me is this: what's to stop another bit of code (e.g. Linux) from asking the TPM for the HDD encryption key? Even assuming a secret MS key is required, this key surely must be present in the boot partition somewhere, and my simplistic idea of how this might be achieved would be for a VM (on a USB key?) to execute the boot loader until the boot sequence interacts with the TPM and bingo the encryption key is no longer secret... This isn't rocket science though, and clearly it can't be this easy or Bitlocker+TPM would be an utter waste of time. So - I can't have a correct picture of what's going on, but I've tried and failed to find out how it really works...

Can anyone provide the insight I'm missing? Thanks in advance!

[Edit: for clarity, I'm mainly thinking about the case where the laptop gets stolen. Like many people, my laptop spends a lot of its time in my bag in sleep mode, so let's assume it's sleeping when stolen - this has implications for how much a move to TPM+PIN would help, but I don't think it directly changes the fundamentals of the actual question.]

  • I don't think anything stops it other than Linux not knowing how to do so (not coded with bitlocker). The point of the TPM is not to prevent decryption by other OS but to prevent decryption of the HDD on different physical machine, eg. a thief just pulling the HDD from the computer or a spy cloning it. If I am not mistaken, a TPM can take a password and enforce rate-limiting if you are concerned about other OS/person on the physical machine. – Peter Harmann Jul 28 '18 at 16:24
  • @PeterHarmann - thanks for the suggestion but I'm struggling to understand how that could be the case. It would imply (I think) that a Bitlocker-ed machine wasn't truly secure unless all alternative boot methods had been locked down, or unless the user was prepared to trust in security-by-obscurity. Could that really be true? – Neilski Jul 28 '18 at 19:01
  • You may be misunderstanding the reason why the encryption is happening in the first place. I doubt it is meant to keep the HDD safe when all the attacker would have to do is boot the original (non password protected) windows and copy the files anyway. The point is that if you choose to add password, it can just send it to the TPM without encrypting everything and having to delete stuff (which is impossible on SSDs). Without password, there is no real protection anyway. PS: If you are relying on windows permissions, then a specialty software to break bitlocker is the least of your problems. – Peter Harmann Jul 28 '18 at 19:55
  • And also, it would not be secure even if you did lock down all other boot methods. – Peter Harmann Jul 28 '18 at 20:00
  • 1
    (Or it might be there because your company admin doesn't understand what he's doing, thinking it's secure already) – deviantfan Jul 28 '18 at 22:47
1

I think a lot of the comments miss a key point. If you are using Windows 10 with secure boot and password protected firmware, then you cannot simply boot into Linux and see the disk. The TPM will not release the decryption keys to a changed O/S. I'd suggest having a read through this post:

Can a physical attacker compromise a Windows machine with UEFI, secure boot and bitlocker? as there is some good information there.

  • I believe this is incorrect. The TPM can still release the decryption keys if the OS changes, as long as the attestation stage is passed. All the TPM will do is check the integrity of firmware, bootloader, and kernel. It can easily be made to do that without booting into said kernel when SRTM is being used (which I think Bitlocker does?) – forest Aug 3 '18 at 6:59
  • I believe this is incorrect. You can just disable secure boot and if BIOS is password protected, you can reset BIOS on pretty much any motherboard to get rid of the password. As for the "lockout" mentioned in the link, that does not help if they reverse-engineer bitlocker instead of using the original, which is what I assume they would have to do anyway. PS: Of course this apply to TPM-only. With PIN it would be a different story. – Peter Harmann Aug 3 '18 at 13:55
  • Actually I think this answer looks mostly correct to me. The linked answer also helped me quite a lot (including the links contained within the various answers and comments in it). @peter - I believe that if you disable secure boot you will automatically change the hash computed by the TPM and prevent unlocking the key (even before you attempt to boot to a different OS). – Neilski Aug 7 '18 at 22:40
  • @forest - how can the attestation stage be passed if the OS changes? The boot-time environment hash codes will be different and therefore (surely?) the attestation must fail. – Neilski Aug 7 '18 at 22:41
  • @Neilski It is hard for me to say anything for certain as official Microsoft docs just spew a lot of vague claims without giving any technical details. I would however very much doubt the encryption uses full attestation of the OS. Between windows updates, firmware and driver updates, data recovery from failed systems etc, it would just not work well that way IMO. docs.microsoft.com/en-us/windows/security/… – Peter Harmann Aug 7 '18 at 22:57
2

Nothing is stopping this. What the TPM is doing is checking the integrity of various boot-time components and only unsealing an internal password if these components have not been tampered with. It can be additionally configured to require a PIN code, but that is not strictly necessary. The reason the drive does not automatically decrypt on a Linux system is simply because Windows is communicating with the TPM, asking it to attest the state of the system.

The key is kept sealed inside the TPM itself. The purpose is not to prevent you from decrypting the disk if you have both the computer and the drive, but to make it impossible to decrypt the disk if you have only the storage drive but not the computer itself. If you have physical access to the entire device, including both the drive and the TPM, you will be able to decrypt the drive.

  • Thanks. However, this seems to be at odds with what I'm reading elsewhere. Can you provide any links to back up your assertion that with the entire device (i.e. drive and the TPM) you will be able to decrypt the drive? My current (but still evolving!) understanding of how the TPM does its job implies that (much as you mention in the first part of your answer) the boot-time environment checks performed by the TPM will yield up a different set of hash codes if you boot (e.g.) to Linux and therefore you simply can't unlock the disk encryption key unless the TPM itself is defeated somehow. – Neilski Aug 7 '18 at 22:35
  • @Neilski Bitlocker uses the TPM with SRTM, which means that it only checks things such as the bootloader and BIOS. When the OS is actually running, it has no say over what happens. This means that you could easily start up Linux as long as the Windows bootloader at least executes. – forest Aug 8 '18 at 0:17
  • I had some trouble parsing that answer :-D Having googled SRTM and learned more, I'm still not seeing how your comment addresses the question in my comment. (This was very helpful btw.) Specifically, how could one start Linux after the Windows bootloader executes? Remember we're talking about a stolen laptop (TPM-only) which will boot to the login screen, but you can't get further without user credentials. And even if you can log in, you still can't start up Linux... – Neilski Aug 8 '18 at 22:30
  • If you can log in, you can start Linux. As long as the system is powered on, you can do various magic to launch another operating system (this is how kexec on Linux works, for example). There's no need to truly power cycle and reset the TPM just to load another operating system. – forest Aug 13 '18 at 23:14
  • 1
    @Neilski Yes, you can physically plug it in, usually to a slot called the ITP-XDP header. Sometimes the header is gone and you have to solder it. Regarding a stolen system, realistically, the thief won't even know what a cold boot attack is, much less what JTAG is. But if your adversary is skilled and the system is powered on, they will be able to bypass the lock screen. – forest Sep 2 '18 at 20:51
1

When a TPM is initialized, the OS takes ownership of it and uses a TPM owner password to protect its access. On Linux, this password is manually entered (see tpm_takeownership). On Windows, it is generated automatically and stored internally, although there are some methods to recover it. This answer (https://stackoverflow.com/questions/48762602/tpm-owner-password-and-lockout-password-with-windows-10-linux) has some details on how to do it.

  • Thanks, but I don't see anything here which really addresses my question about how a Linux system wouldn't be able to pretend to be the authorised boot loader and get the key from the TPM. – Neilski Aug 7 '18 at 22:36
  • The key itself is never acessible. It is "sealed" inside the TPM so only authorized applications can use it. So if linux somehow has access to the tpm owner password, it can act as an owner and use the keys (by "use" I mean encrypt/decrypt, not export, but since this is what is needed for Bitlocker) – Filipe Rodrigues Aug 7 '18 at 22:56
  • Are you saying that the owner password allows an "unseal" to take place even when the PCR measurements don't match the requirements? Also, I would assume that the owner password will not be accessible to a thief in most cases ;-) – Neilski Aug 8 '18 at 22:32
  • There is no way to share owner password when you are using win10. The win10 use random number as owner password during setup and then discard it. There is no way to recover or record this password. And TPM will refuse to give keys when the measurement detects it is not boot into original windows. Even if you have the owner password you can only change the password or clear the keys. It does not allow you to decrypt stuff. – Wang Jun 25 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.