17

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.]

Improve this question
18
  • 2
    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
    Commented Jul 28, 2018 at 16:24
  • 1
    @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
    Commented Jul 28, 2018 at 19:01
  • 1
    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
    Commented Jul 28, 2018 at 19:55
  • 1
    (Or it might be there because your company admin doesn't understand what he's doing, thinking it's secure already)
    – deviantfan
    Commented Jul 28, 2018 at 22:47
  • 2
    hardware change and boot sequence change upset the TPM. Thus if you do not boot into the original OS who initialized the TPM, the TPM won't allow you to access its content. Even with owner pwd, you can only change the owner pwd, clear or reset the TPM. You can never trick the TPM to give you any content. Win10 does not even store/keep the owner pwd. It is a random number which is discarded immediately after TPM initialization.
    – Wang
    Commented Jun 25, 2019 at 12:03

3 Answers 3

Reset to default
2

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.

Improve this answer
14
  • 2
    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
    Commented Aug 3, 2018 at 6:59
  • 2
    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
    Commented Aug 3, 2018 at 13:55
  • 1
    @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
    Commented Aug 7, 2018 at 22:41
  • 1
    @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
    Commented Aug 7, 2018 at 22:57
  • 1
    It is a bit funny, that even the one paragraph excuse for a "Technical overview" contains only one sentence that is relevant and this gem: "When the operating system an Encrypted Hard Drive, it activates the security mode." Takeaway: If you want something secure, don't rely on Microsoft.
    – Peter Harmann
    Commented Aug 7, 2018 at 23:04
3

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.

Improve this answer
21
  • 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
    Commented Aug 7, 2018 at 22:35
  • 1
    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
    Commented Aug 8, 2018 at 22:30
  • 1
    Can you provide links to evidence that it's possible to bypass the lock screen of a Bitlocker+TPM machine? I have seen nothing to suggest that this is true. In fact, since creating this question, I've read a lot of material that suggests it is NOT true.
    – Neilski
    Commented Aug 16, 2018 at 9:06
  • 1
    Doh. In that case I'm perhaps still misunderstanding the unsealing process to some degree, which wouldn't greatly surprise me to be honest :-) I learned from the answer by @filipe-rodrigues that Windows sets an owner password on the TPM, which may contradict what you're saying. In any case though, I'm still very unclear about how you expected to be able to load Linux after Windows boots - I can't understand how you would bypass the lock screen. Can you spell it out more clearly?
    – Neilski
    Commented Aug 19, 2018 at 21:49
  • 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
    Commented Sep 2, 2018 at 20:51
0

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.

Improve this answer
4
  • 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
    Commented Aug 7, 2018 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
    Commented Aug 7, 2018 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
    Commented Aug 8, 2018 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
    Commented Jun 25, 2019 at 11:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .