I think you get the biggest advantage from BitLocker when you use TPM (PCR 7+11) with a PIN. That should mitigate the exploit because the FVEK should never be read without the PIN, and if BitLocker does it right (which I think it does) too many wrong PIN's results in the TPM going into dictionary attack lockout mode.<p>Now I've been trying for months to do the same for Linux. There's systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm trying to encrypt a few sensitive directories on a super slow internal eMMC with fscrypt (keys for secure boot and /home). The TPM is _EXTREMELY_ hard to code for when things go beyond the basics:<p>1. Bind to PCR 7<p>2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated)<p>3. Use a PIN - but not the AuthValue, because I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually.<p>4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub.<p>Maybe this isn't the right place to ask, but there's almost nothing but basic TPM guides out there, so if you're an expert I could really use your help. It's just for a personal project, but I'll write about it once I'm done - if I ever figure it out!
Fundamentally I don't understand BitLocker's security model. In most installs it seems like you power on the machine by pressing the power button and it boots into Windows.<p>So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless.<p>With LUKS it at least has a password prompt to unlock the drive.
This is entirely defeated by <a href="https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/" rel="nofollow">https://trustedcomputinggroup.org/resource/pc-client-work-gr...</a> - if enabled, if the OS isn't cleanly shut down (giving it an opportunity to wipe encryption keys) the firmware will pause to wipe RAM before booting anything else on next boot. Does Windows not make use of this, or did the tested system not implement it?
Hello everybody, I'm the author of the article. If you have any questions, please feel free to message me on this account. I had a lot of fun working on this and I really appreciate all of the engagement.
Related 38C3 talk about Windows 11 BitLocker bypass: <a href="https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver" rel="nofollow">https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...</a>
It’s fairly well known that BitLocker only really protects a computer that is turned off, and also only if you configure BitLocker to require a boot password [0].<p>[0] <a href="https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_enough" rel="nofollow">https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...</a>
Windows has a proposed memory encryption option along with memory compression.<p>Both Intel and AMD are working on embedding this into their CPUs.<p>However, the target use appears to be servers with multiple VMs, not laptops.
Related: Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop
<a href="https://news.ycombinator.com/item?id=37249623">https://news.ycombinator.com/item?id=37249623</a>
For any exploit which relies on reading a dump of the target machine's memory, if you have physical access to said machine: How feasible is an "interposer" device that copies off or modifies data as it goes in and out of RAM?<p>I'm thinking of something like the old "Action Replay" devices for Gameboys, which modified memory from the game cartridge as it went into the system to be loaded (or executed in the case of code) in order to cheat in games. You slotted the cartridge into the Action Replay, then slotted the Action Replay into the Gameboy.<p>Could you do something similar between the RAM and the motherboard? Slot your ram into the device, slot the device into the motherboard, and capture the state of memory at any moment by simply watching how memory is read/written? That way, you'd save yourself the hassle of manually powering off the machine and hoping the data you need is available?<p>I'm not an electrical engineer so maybe what I am proposing is completely infeasible - physical space and bandwidth limitations certainly seem likely. But is it possible?
Few know this, but Intel/AMD CPUs released in the last few years support transparent full memory encryption, where the RAM content is encrypted with a random key kept in the CPU memory controller and generated at reset.<p>It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%)<p>But it would completely prevent this attack.
Having a surface 5 pro laying around here, with a bitlocker encrypted disk, which turns quickly into a BSOD during boot.
Do you think it could work in auch situation? I'm still waiting for an exploit to the tom to extract some pictures from the disk
See the talk "Recent TPM Security Enhancements to the Linux Kernel" by a Microsoft engineer (I find this ironic) for recent Linux TPM security enhancements. New features add some transport security.<p><a href="https://youtu.be/WK7NERQXh4I" rel="nofollow">https://youtu.be/WK7NERQXh4I</a>
You can make things a bit harder by locking the boot order in bios and password protecting the bios settings.<p>Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
This is exactly why there are some more "enterprise" machines out there that an arbitrary adversary with physical access can not "abruptly restart" from the outside.<p>It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.
Too bad the author did not provide hardware specs. Such attack is even harder on DDR4 and DDR5 memory and most publications refer to legacy ram such as DDR3<p>> In my experience I have had the most success restarting the system while Windows is loading but before the login screen has appeared, at least in the case of finding FVEK keys.<p>So what is this? It was supposed to be memory attack and he's dumping the keys after someone unlocked it and it's booting?<p>So this is just another theoretical attack where perfect conditions must be met.
BitLocker is crazy easy to bypass if you have physical access to the device. I work IT, and had to demonstrate to our head of security, that if you just pop in a Linux USB and boot from it, the drive is completely open.