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

Neilski
  • 171
  • 1
  • 8
  • 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 Jul 28 '18 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 Jul 28 '18 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 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
  • @PeterHarmann - I may be confused about what you're saying, but just to be clear about what I mean: the laptop has the main partition encrypted and there is no "original (non password protected) windows" present whatsoever. I believe the main reason for the encryption is so that if the laptop is stolen, the thief will be unable to see the contents of my disk. Is this not what you would expect? (I entirely agree that Windows permissions are useless in this context.) If Bitlocker were no good at protecting against data compromise for a stolen machine, I can't think what it would be good for... – Neilski Jul 28 '18 at 22:01
  • @Neilski As you suspect, and as Peter Harmann says too, right now the encryption is useless against the thief. It might be there just for the reason that you can add a password requirement later (making it useful in the thief scenario) without having to wipe and rewrite the whole disk. – deviantfan Jul 28 '18 at 22:45
  • 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
  • Oh wow... That's rather disturbing. If you guys (@deviantfan and @peterharmann) are right then I suspect the root cause is a misunderstanding by the IT admins. However, I can't entirely blame them because the MS docs I have found so far have been extremely confusing. Do either of you have primary sources that I can show our admins to help them understand the situation? (Perhaps I should say: to help me convince them...) Thanks! – Neilski Jul 29 '18 at 09:24
  • I can't find a nice quote for this exact issue but here are some articles about TPM and what it does (and by extension does not do): https://blueteamer.blogspot.com/2017/01/is-bitlocker-tpm-only-secure-enought-for.html https://blueteamer.blogspot.com/2017/01/is-bitlocker-tpm-only-secure-enought-for.html – Peter Harmann Jul 30 '18 at 13:14
  • Thanks @PeterHarmann. Some interesting info there. (By the way, did you mean to post two separate links? You seem to have posted the same one twice.) I've done some more searching since my last comment and am now wondering if our admins deliberately left the system in "TPM-only" mode. This is because a cold-boot attack works equally well on a TPM+PIN machine, provided it's stolen while suspended (mine almost always is). They have NOT however set the BIOS to prevent booting from (e.g.) a CD though, which seems to be a Bad Thing. But usability (and support effort) is a compromise... Bah. – Neilski Jul 30 '18 at 19:24
  • Continuing that train of thought: even if they HAD locked down the BIOS, my particular laptop has removable RAM modules... So they would have to glue them in to truly prevent a cold-boot attack. Sooooo, like I say, I'm now starting to suspect that our admins have chosen to walk a line between "fully" secure (but with less usability and high support costs) and "fairly" secure... – Neilski Jul 30 '18 at 19:31
  • Bottom line though, and coming back to my original question: the rather tricky and not-guaranteed-to-work cold-boot attack is entirely unnecessary if you know how to ask the TPM for the Bitlocker disk encrytion key. However, in the absence of any posts on the net which describe how to do it, I'm suspecting that this is at least non-trivial and maybe very hard indeed. If it was semi-trivial, then TPM-only would not be worth considering - right? – Neilski Jul 30 '18 at 19:34
  • @Neilski I would not consider attack on TPM-only encryption trivial, but it is not impractically hard either. At the end of the day, the question is whether the contents of the computer are valuable enough to attempt this sort of attack. As for cold boot, while that is a scary attack in theory, in practice, the attack would have to be done in the building, so preventing it would probably be simpler by just having a night-guard. Having to conduct a prolonged and complicated attack in the building they are not supposed to be in is usually way too risky to attempt. – Peter Harmann Aug 01 '18 at 00:15
  • You would usually worry more about thieves snatching the PC/HDD and then breaking it later in safety of their hideout. That is where TPM+Passphrase would protect you while TPM-only could be broken, if deemed profitable by the thieves. But using TPM-only still requires the thieves to snatch the whole PC (or at least the motherboard as well), while without it, they could just pull the drives and carry a lot more/faster. Also cloning the drives and concealing the theft is impractically hard. So you would at least know what was stolen. – Peter Harmann Aug 01 '18 at 00:18
  • @PeterHarmann I wouldn't say it's hard. Getting the TPM to unseal if you have physical access to the machine and the TPM is using the "well known secret" (i.e. not requiring an additional password before unsealing) is easy, much easier than a cold boot attack at least. – forest Aug 03 '18 at 07:09
  • @forest That is what I was kind of trying to say (not sure personally if cold boot would be harder, but I trust you on that). Even if cold boot was not that hard on its own, getting the equipment into the office and pulling the attack there (as they can't unplug the PC) would be. My point was that a TPM with passphrase/PIN would provide considerably more protection than TPM-only, as cold boot is not very practical compared to extracting the key from TPM in TPM-only mode, but that TPM-only is still better than nothing. – Peter Harmann Aug 03 '18 at 13:50
  • Thanks for the feedback, people. Sorry for slow replies (am away from home and doing this via phone tethering is painful :)). Some remarks: - firstly, a cold-boot attack does not require the PC to remain plugged in if it's a TPM-only setup (because you can just power it up again after stealing it). If pre-boot authentication is used, *then* you must steal it while it's "on" (which includes sleep mode for laptops). - secondly, can I ask @forest - what do you mean by "well known secret"? I have found nothing at all which suggests that it's easy to get the TPM to yield the encryption key. – Neilski Aug 07 '18 at 22:19
  • 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 Jun 25 '19 at 12:03

3 Answers3

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.

forest
  • 64,616
  • 20
  • 206
  • 257
  • 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 07 '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 08 '18 at 00:17
  • 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](https://security.stackexchange.com/questions/39329/how-does-the-tpm-perform-integrity-measurements-on-a-system) 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 08 '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
  • Am very puzzled by your reply... Firstly, one would normally assume that a thief can't log in, by dint of not having credentials. If they could log in as a normal user, they still couldn't start Linux and get access to the TPM because that would require elevated privs. And If the thief had elevated privs, there would be *no need* to fire up Linux, because the system would be fully open to them to do whatever they pleased already. Am I missing something? PS: am still wondering what you mean by "well known secret" (re. your comment on the question itself). – Neilski Aug 15 '18 at 20:19
  • Well-known secret is a term for the default password for a TPM. – forest Aug 15 '18 at 20:59
  • @Neilski And remember, with physical access, you will always be able to bypass the lock screen after you boot up the system. Once you bypass the lock screen or otherwise get privileged local access, you will be able to obtain the drive encryption key from the TPM. – forest Aug 15 '18 at 21:08
  • 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 Aug 16 '18 at 09:06
  • @Neilski It's not that you bypass the TPM, because the TPM has already unsealed at this point. You only bypass the lockscreen. You could use a DMA attack for example. If that fails (which it might if the system is using an IOMMU), then plug in a JTAG probe, which will always work. – forest Aug 16 '18 at 10:49
  • Yes I understand that the TPM is unsealed; indeed I said "bypass the lock screen", not "bypass the TPM". Why do you mention a DMA attack in the context of bypassing the lockscreen? A DMA attack would surely be used to retrieve the Bitlocker disk encryption key from memory, no? Can you provide links to info on use of DMA attacks for bypassing a lock screen? And I'm not familiar with a JTAG attack - what does this do for you? (Links welcome here too!) – Neilski Aug 18 '18 at 09:18
  • Oh, I forgot to comment on the "well known secret" thing: I now understand what you mean by that, thanks. However, I'm fairly certain that the Windows Bitlocker setup does NOT use the default password for the TPM - do you have reason to think it does? – Neilski Aug 18 '18 at 09:27
  • @Neilski Well it has to unless you are using a PIN. – forest Aug 18 '18 at 13:37
  • 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 Aug 19 '18 at 21:49
  • @Neilski One simple way to bypass the lock screen is, as mentioned before, JTAG. It's just a debugging port that you plug into the computer which gives you complete, unrestricted access to the CPU and motherboard. On newer computers, you may even be able to do this over USB. On older computers, you have to plug it directly into the motherboard. When you do that, you can kill the lock screen. – forest Aug 29 '18 at 01:08
  • Thanks forest. Can you provide links which describe the JTAG attack? And I must say that my understanding had been that no such attack is possible via USB. (PS: I'm familiar with what JTAG is; I've just never heard of it being used to attack a PC.) – Neilski Aug 29 '18 at 22:43
  • @Neilski Knowing how JTAG works should be sufficient to understanding how a JTAG attack works. After all, you can halt and control all the processor state (registers, memory, etc) at will. Here's a [course](https://www.xipiter.com/software-exploitation-via-hardware-exploitation.html) for learning how to do it, and here's a recent [paper](https://www.ptsecurity.com/upload/corporate/ww-en/analytics/Where-theres-a-JTAG-theres-a-way.pdf) on using it over USB (since DCI is basically JTAG over USB, although not all DCI-capable computers have it enabled). It's usually a last-resort attack. – forest Aug 31 '18 at 21:30
  • Lots of useful reading material there, thanks. I'm still curious about your comment above: "...plug in a JTAG probe, which will always work". Clearly the USB-debugging approach *won't* always work, so where would you be intending to physically plug in the JTAG connector on laptops (or even desktops) for which the USB approach isn't possible? – Neilski Sep 01 '18 at 12:14
  • @Neilski When the USB approach isn't possible, you have to open the chassis. Assuming the attacker has physical access to the system, this isn't a problem for them. – forest Sep 01 '18 at 19:20
  • Yup, but once the chassis is open, where do you **physically** plug in the JTAG cable? Are JTAG connectors present on all motherboards, including laptops? Or are you thinking about soldering onto pins on chips? Am not simply being pedantic here - am seriously trying to assess the ease of attack for a typical stolen laptop (or even desktop). – Neilski Sep 02 '18 at 14:12
  • 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 02 '18 at 20:51
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.

user_al
  • 72
  • 2
  • 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 Aug 03 '18 at 06: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 Aug 03 '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 07 '18 at 22:40
  • 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 Aug 07 '18 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. https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/how-windows-uses-the-tpm – Peter Harmann Aug 07 '18 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 Aug 07 '18 at 23:04
  • @PeterHarmann That's correct, it doesn't attest the entire OS. It ensures that everything _unencrypted_ is verified, so yes the NT kernel must execute, but nothing is preventing it from being used to chainload Linux (similar to the native Linux kexec feature, I guess? Not sure exactly how it would be done on Windows). – forest Aug 08 '18 at 00:19
  • I found the talk [‘Building a Bulletproof Bitlocker’](http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B314#fbid=) very educational. It states that in most cases, TPM-only setups are good enough. Perhaps though (given that it's 4 years old) the state of the art has moved on since then, and it's no longer safe? Right now, my belief is that TPM-only is very nearly as good as TPM+PIN *for a laptop which is stolen while in sleep mode* given that both are susceptible to a cold-boot attack until the 1st power cycle, at which point TPM+PIN becomes invulnerable to cold-boot attacks). – Neilski Aug 08 '18 at 22:37
  • @peter - I don't see why full attestation of the OS is required. Just the bootloader required to get you from the non-encrypted partition to the encrypted one is good enough. And the updates (Windows, drivers etc.) are in almost all cases going to reside on the encrypted partition, so there would be no need to update the attestation data on a frequent basis. – Neilski Aug 08 '18 at 22:41
  • 1
    @forest - given that the unencrypted stuff is verified, how on earth would you be able to chainload Linux? That would surely require you to have been able to compromise the unencrypted stuff? (You certainly can't have compromised the *encrypted* stuff.) Confused about what you mean here. – Neilski Aug 08 '18 at 22:43
  • @Neilski The threat model assumes physical access, right? – forest Aug 17 '18 at 08:34
  • @forest Yes, my main scenario under consideration is the very foreseeable situation where a laptop is simply stolen. I'll update the question to make this clearer. – Neilski Aug 18 '18 at 09:19
  • 1
    OK, I've decided to mark this answer as accepted. I still can't claim to perfectly understand the whole Bitlocker+TPM process. I also don't really understand the impact of having (or not) a password-protected firmware or secure boot, given that the TPM would still be sealed if you managed to boot from a USB drive. However, despite these issues, this answer was the most helpful and based on my current understanding it's also the most accurate. – Neilski Aug 24 '18 at 21:41
  • @Neilski you are correct. There is no need to attest the full OS. Since the OS is in encrypted partitions, thus the attacker cannot modify or review anything in that OS. And TPM won't accept any OS/application not boot to the original partition. So even with physic access thief cannot access your data without your win10 user pwd. Of course, if win10 has bugs in auth step you are still screwed. – Wang Jun 25 '19 at 12:24
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.

Filipe Rodrigues
  • 398
  • 3
  • 13
  • 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 07 '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 07 '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 08 '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 '19 at 11:57