Timeline for How does Bitlocker + TPM prevent me seeing the HDD contents with another OS?
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 25, 2019 at 12:24 | comment | added | Wang | @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. | |
| Aug 24, 2018 at 21:41 | vote | accept | Neilski | ||
| Aug 24, 2018 at 21:41 | comment | added | Neilski | 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. | |
| Aug 18, 2018 at 9:19 | comment | added | Neilski | @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. | |
| Aug 17, 2018 at 8:34 | comment | added | forest | @Neilski The threat model assumes physical access, right? | |
| Aug 8, 2018 at 22:43 | comment | added | Neilski | @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. | |
| Aug 8, 2018 at 22:41 | comment | added | Neilski | @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. | |
| Aug 8, 2018 at 22:37 | comment | added | Neilski | I found the talk ‘Building a Bulletproof Bitlocker’ 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). | |
| Aug 8, 2018 at 0:19 | comment | added | forest | @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). | |
| Aug 7, 2018 at 23:04 | comment | added | Peter Harmann | 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. | |
| Aug 7, 2018 at 22:57 | comment | added | Peter Harmann | @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/… | |
| Aug 7, 2018 at 22:41 | comment | added | Neilski | @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. | |
| Aug 7, 2018 at 22:40 | comment | added | Neilski | 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). | |
| Aug 3, 2018 at 13:55 | comment | added | Peter Harmann | 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. | |
| Aug 3, 2018 at 6:59 | comment | added | forest | 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?) | |
| Aug 2, 2018 at 20:27 | history | answered | user_al | CC BY-SA 4.0 |