I have a Windows system and I protected the drive with BitLocker encryption.

Can BitLocker encryption be bypassed by live-booting with Linux or any other OS?

  • Ok. Do you understand how BitLocker works?
    – schroeder
    Commented Apr 25, 2016 at 17:01
  • @schroeder yeah with the TPM right ? Commented Apr 25, 2016 at 17:04

1 Answer 1


First off, you should go type "how bitlocker works" into google and read a few articles. You will probably learn the answer to your question (and a bunch more interesting things besides!).

If you want a quick answer, I found an article by Microsoft that says:

During the startup process, the TPM releases the key that unlocks the encrypted partition only after comparing a hash of important operating system configuration values with a snapshot taken earlier. This verifies the integrity of the Windows startup process. The key is not released if the TPM detects that your Windows installation has been tampered with.

There are two important points here:

  1. The keys to decrypt your hard drive are stored in the TPM chip on your motherboard, so you would need to live-boot on the same motherboard, and your live-boot OS would need to convince the TPM to release the keys.

  2. It's not 100% clear from the above but it seems like the TPM checks RAM during startup to make sure that the OS being booting is the same one that registered the encryption keys in the first place.

So it would probably be hard to "fool" the TPM into releasing the keys to your live-boot Linux.

That said, Wikipedia has details on a successful attack: https://en.wikipedia.org/wiki/BitLocker#Security_Concerns

In February 2008, a group of security researchers published details of a so-called "cold boot attack" that allows full disk encryption systems such as BitLocker to be compromised by booting the machine off removable media, such as a USB drive, into another operating system, then dumping the contents of pre-boot memory.[34]

So it seems that it's not as simple as just booting into Linux and reading the drive, but if an expert hacker has access to your computer while its running and logged into the decrypted drive, then it's possible to reboot into linux quickly enough that RAM still has the old data on it pluck the decryption key directly out of memory, this bypassing the TPM entirely. For more info on this attack, see: wikipedia/Cold_boot_attack.

As @AndréBorie points out in comments, if you're willing to do some electrical engineering and sniff the connection between the TPM and the rest of the motherboard, then you can boot the system normally and read the decryption key off the wire.

I guess the old adage proves right once again; Ten Immutable Laws Of Security:

Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

  • 1
    To be more specific, the BIOS hashes its configuration and puts the results in the TPM's PCRs, and the TPM can be "sealed" to only reveal a key if the PCRs match the values at the time it was sealed. Though an easy way to break this is to leave the software intact (so the TPM is happy and releases the key) and connect a logic analyser to the serial lines connecting the TPM chip to the rest of the system. The key will be right there in plain text. Commented Apr 25, 2016 at 18:02
  • The only way to mitigate this TPM attack is to have the TPM (and preferably RAM) built into the CPU, so that there is no way (or at least, very difficult) to access it without destroying everything. Kinda like what Apple does on their newer iPhones. Commented Apr 26, 2016 at 1:35
  • Your link seems to be broken, see wciapool.org/pdf/Tab_5_10_Immutable_LawsofSecurity.pdf Commented Sep 24, 2018 at 12:00
  • @JensTimmerman Thank you. Feel free to edit the post directly next time :) Commented Sep 24, 2018 at 12:07
  • You said that they are potentially vulnerable to a cold boot attack "if an expert hacker has access to your computer while its running and logged into the decrypted drive". However, once the computer is running and logged into the decrypted drive, doesn't this mean that they already have access to the decrypted drive contents anyway? Or are you referring to use cases when the computer is on and drive decrypted, but locked so the attacker does not have access to the user's session? Commented Sep 24, 2018 at 12:14

You must log in to answer this question.

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