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.
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:
1. Bind to PCR 7
2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated)
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.
4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub.
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!
> 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.
LUKS has multiple "key slots" so IIRC you can use one slot for TPM unlock, and a different one for long password unlock.
Have you considered using that as your recovery mechanism?
> It's just for a personal project,
One of the reasons very few hobbyists touch the open source TPM stuff is there are a number of alternatives that scratch similar itches much more easily.
Need to protect a crucial encryption key by locking it up in hardware? Buy a Yubikey.
Disk encryption password on your laptop is inconvenient? Just use standby when you close the lid instead of powering off fully. Login password is inconvenient? Fingerprint reader, or biometric yubikey.
Unattended kiosk, school computer lab or similar that needs to boot without a password? Just put it in a sturdy metal box and chain it to the wall.
Server in a data centre that needs to boot unattended? Move to a data centre with physical security you can trust. Still worried? Dropbear or Tang so it has to be on the right network before it'll boot.
Home lab hobbyist, working with the TPM for fun? Assess whether you're actually having fun working with the TPM, and you'll probably notice you're not.
Surely Windows keeps the FVEK in RAM regardless of whether the TPM requires a PIN to initially obtain it. Otherwise, wouldn't you need to enter your PIN every time a block from the disk needs decrypting? Not to mention the performance impact of calling the TPM on every disk operation.
This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate it.
The point is that the TPM PIN prevents the attack if the system is powered off when the attacker obtains it.
If the TPM doesn't have a PIN, this attack works even if the attacker obtains the system when it's powered off. They can start the computer, proceed to the Windows logon screen (that they can't get past and that hence prevents them from exfiltrating data from the running system), then just reset the computer and perform this attack to obtain the encryption key. This obviously doesn't work if the PIN prevents Windows from ever even starting.
I know this is besides the point, but still kinda relevant:
Even on Win11 it's still possible to do the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot), from there you can change account passwords at will.
I think Windows repair prompts for an admin login and the bitlocker key before allowing you to proceed. Assuming the windows install is intact enough to read the security sam.
Correct, unless you're using a self-encrypting drive the FVEK sits in RAM once it's been released by the TPM during boot. The TPM is only a root of trust; for fast crypto operations without keeping the key in kernel memory you would need something like Intel SGX or ARM TrustZone.
BitLocker no longer leverages SED by default due to vulnerabilities in drive manufactures firmware as of Sept 2019.
> Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change.
If you can short the reset pins while the computer is running and make it restart without losing power, then yes, I agree. But if you have to shut down to make your modifications, then you won't get past the PIN prompt.
Why? It means you'll only get one shot at the attack, but nothing here is intrinsically prevented by using a TPM PIN (or even a non-TPM password, the attack doesn't depend on TPM-based Bitlocker in any way other than if the target machine is powered off or your first attempt fails)
I wouldn't underestimate that a PIN prevents this attack on machines that are powered off.
You can then go further up the chain with a UEFI settings password and no usb booting. If the password is hard to decrypt, then that's a pretty good approach.
Then there's custom Secure Boot certificates that replaces the ones from MS. It'll work for Linux, not sure about BitLocker. But my Surface tablet doesn't even support custom sb certs.
Would you be better off using split key encryption or encrypted secret key?
If you have to put a password in before boot that needs to be combined with the TPM key to unlock the drive, it would help in scenarios where a TPM key can be found later.
I’m not sure how much anything helps against this attack though. Retrieving data from RAM in this way should work for most scenarios by changing where you look for the key (as it needs to be held somewhere by the OS to maintain read/write access to the drive).
I would assume Apple devices aren’t vulnerable to this type of attack as IIRC the keys never exit the enclave. Maybe TPM 3.0 needs to look a lot more like that.
> If you have to put a password in before boot that needs to be combined with the TPM key to unlock the drive, it would help in scenarios where a TPM key can be found later.
Bitlocker already does this if you use a PIN/password.
You might know better than I do, but I had believed that Bitlocker used TPM PIN when you use a PIN, which is challenge/response (i.e. if PIN matches then TPM releases key) so wouldn't help in this case.
If Bitlocker PIN is split key then yes that would be ideal, but I think you can change the PIN without re-encryption (which implies it's challenge/response).
A power-on password (set in the BIOS) should also work, since without it the system will never get to the point where the TPM unlocks the FVEK, right?
I prefer this setup to a Bitlocker PIN because I can use a fingerprint instead of the power-on password on my Thinkpad, and because it should make the device largely unusable to a thief.
Of course, power-on password and fingerprint auth are only as strong as my TPM, but the same goes for Bitlocker TPM+PIN, right?
Isn't TPM just a honeypot of sorts? It seems strange to me that after successful open source encryption software, there was a shift to TPM, like you'll have a notion of super secure storage provided by big corporations and you should just not worry about it and not question.
Surely there must be a backdoor access for three letter agencies to just download all the pins and passwords and then take a dip in the data, no worries.
It's not a honeypot, and it does have value when used properly.
Their main purpose is to generate and store keys that cannot leave the device, instead performing signing operations as needed internally and only returning the result, and only if attestation passed. This is a lot better than just having private keys on disk.
People just forget that security isn't absolute, and each solution has a threat model it is appropriate for. In case of full disk encryption, neither a TPM nor user input can protect against evil maid on its own for example - the TPM will unlock for anyone, while user input might be collected by a modified and malicious bootloader. Having both, however, works well.
"TPM" is a bit dated as a term as it's all directly built into the processor nowadays, including for smartphones and such. Another modern feature in that catalogue is memory encryption, which rules out the attack described by OP as the rebooted machine would be unable to read old memory content.
I encourage you to read what a TPM is. A TPM isn't an "encryption" software/hardware. It's completely orthogonal to "successful open source encryption software".
"successful open source encryption software" don't solve the main usability problem with encryption: "Where do I store my super secure 4096-bit private key so it's both secure and convenient to use"
I don't see why a TPM couldn't be open? Nobody makes open-source TPMs (because they're put inside CPUs or attached to motherboards with specific pins and protocols) but in theory you could just do it. All you need to do is make sure any secrets stored get wiped permanently whenever you flash new firmware.
It'd be similar to secure boot: usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.
> usable by default, but reconfigurable so that you can bring your own keys and signatures, putting you in complete control of your hardware, to the point where even the manufacturer no longer has a say in what's running and what isn't.
You can control what's your TPM. That's how they work today. Sure their software isn't "open source" but there aren't that many 100% "open source hardware" options around. If you want to be able to flash it, build your own HSM. I don't know if there is a market for a prebuilt microcontroller with something like picokeys preinstalled. I know that the market for "open" hardware is tough.
The TPM emulation offers a full TPM implementation in software, for providing TPM functionality to a virtual machine when the host doesn't have one (or, when the TPM needs to be virtualized for other reasons, e.g. migration).
> I don't see why a TPM couldn't be open? Nobody makes open-source TPMs
The main advantage of the TPM is how it is made physically. It should be designed to make it hard or impossible to read the secrets out of it and those things depends on how the components are manufactured on the silicon wafer.
Maybe the manufacturing process could be published, but I don't think it would help much.
You could probably write your own TPM emulator or modify swtpm a bit and compile it to any microcontroller, but in that case the chip could be easily decapped to make all the secrets readable.
Unlike with cryptography, there is no rigorous notion of physical security. Doors, locks and even security systems can all be overcome with sufficient effort, skill and resources. They work because physical attacks require proximity and are very hard to keep anonymous. I seriously doubt that any TPM implementation would last a week against government funded researchers with state of the art technology, but that doesn't mean the TPM is useless.
No, it's the same. Cryptography is like a lock that you can overcome with mathematical force. It's just in different domain than physical objects.
If you know how the lock is built, you can rule out existence of master key for instance. You don't know if your TPM chip has API where three letter agency can just download the keys from it. You are in the dark.
Same with cryptography, you can choose the method, just like you can choose type of lock. There are locks that have not yet been picked, but you can use a hammer, similar with cryptography - you can use quantum computer etc.
Which locks haven't been picked? Abloy Protec 2 got picked, Bowley got picked, StealthKey got picked… I'm not aware of any designs for an unpickable/unbypassable lock. Whereas several AEADs have not been broken.
These things make it harder to break into the internals of the chip regardless of they being kept secret, so I wouldn't call it security by obscurity. I'm not even sure you can apply that principle to physical security.
No, it's security by intrusion detection, generally. HSMs are designed to be boxes that it's very hard to get a secret out of with physical access. TPMs generally aren't the most paranoid version, but it gets more expensive and less practical as you go further (e.g. a large box which has a battery backup, keeps the secrets in RAM, and will wipe them as soon at it detects any funny business. These are DIYable, but the list of tricks by attackers is long and it's hard to cover all of them at once). A TPM is generally somewhere in between that and a regular micro with no particular effort to prevent readout of internal storage, in that they are small, can persist secrets without power, but are still difficult to attack physically (~maybe at the level of advanced criminal organisations, ~probably at state level if they're willing to spend some money on it, even absent a backdoor).
They’re built from essentially the same secure MCUs as traditional TPMs and both the hardware and the proprietary crypto libraries used on them have been exploited many times over.
But would you not agree that using a yubikey can improve security?
If you chose to label TPMs as security by obscurity, so be it, but it doesn’t make them less useful conceptually. Shitty implementations and complexities of UEFI do that.
You can store it encrypted with a password on a USB memory that you insert when booting the computer, like you would use a key for starting a car.
This is what I actually do. I also store the OS kernel on the USB memory and I boot from there, with the root file system set to mount an internal SSD. The SSDs in the computer are completely encrypted with such long "super secure" keys (distinct for each SSD and selected automatically based on their serial number), and they do not store any information about the keys.
I have used this system for years and I find it very convenient. My computers cannot be booted without inserting the bootable USB memory and also giving the correct password. I have multiple bootable keys stored in different places, for the case when one becomes defective or lost.
I am sorry I wasn't clear. I am aware that TPM is a key storage. Just I am not convinced they keys it stores are secure. It smells of security by obscurity and all big corporations are happy clappy to use it and government is silent about it, which likely means they have a backdoor.
>It smells of security by obscurity and all big corporations are happy clappy to use it and government is silent about it, which likely means they have a backdoor.
The government is also pretty silent about AES. Does it mean that's backdoored as well? More to the point, I'm not sure what the proposed alternative is. Not using TPM, and exposing yourself to bootkits and evil maid attacks?
It is security the same way a lock is. It limits low efforts attempt which is why we put locks in our doors and close our most easily accessible windows in the first place.
This type of /r/ufos|/r/aliens speculation isn't particularly useful. It comes with no evidence of TPMs being backdoor'ed. Have they been compromised [at least pre-2.0]? Yes, in as much as Apple's Secure Enclave has as an example.
Gut feelings aren't always correct and for topics which have a sort of 'correctness' about them, they're not useful.
Maybe it's different for you, but I don't think any three letter agencies have some kind of TPM backdoor (they don't need to with how often TPM chips end up being vulnerable to common software exploits, the firmware being written in unsafe languages and all). If a government was going after me with enough force to use their TPM bypass trick, I'd probably be in jail for years on fake allegations regardless of encryption status.
TPMs work great against things like common thieves and probably corporate espionage, if set up well. When implemented well, they provide no additional friction (except for having to store a recovery key somewhere) but all the security against a laptop being stolen at the airport you could wish for.
Should be good enough for a personal tablet used for mail and browsing. If I drop it and someone curious finds it, I'd like to make it impossible for them to extract anything useful.
I think this is a good analogue. A smart card is a challenge-response system where sure you could extract the inner key, but doing so would take time and require destroying the card, which would alert the user— we all learned years ago about skimming and now the payment terminal comes to our table rather than the card being carried off elsewhere.
TPM is one piece of a larger puzzle and provides a middle ground where among other things you can get full disk encryption without needing to input a memorized key on every boot.
Found the article where I read about PCR 7+11 being the default [1]. The reason I looked it up is because if this is actually true, and the TPM is built into the cpu, what prevents someone from placing the cpu and disk on another motherboard?
Say that you have disabled usb booting and secured UEFI settings with a password. If you extract the cpu (and thereby its tpm) and the disk, then you'd still be able to boot, right? Meaning that without a TPM pin, you'd be able to do OP's attack on a different motherboard even when the original machine was off and UEFI settings secured.
What am I missing? Is it that easy to circumvent UEFI settings protection and maintain the PCR 7 value?
From what I know, the state of the UEFI settings is hashed into some PCR registers. Potentially even hardware serial numbers. Sometimes when I modify non-secureboot BIOS settings, Bitlocker complains and enters into recovery mode.
So I really doubt TPM will release the keys on a different motherboard with different UEFI settings.
Odd that you have to recover from changing UEFI settings with Secure Boot! You should be able to change any setting when that's enabled. BitLocker binds to a lot of other things when SB is off and might be fragile in that state. But it does seem that some changes will affect PCR 7:
> PCR 7 changes when UEFI SecureBoot mode is enabled/disabled, or firmware certificates (PK, KEK, db, dbx, …) are updated. The shim project will measure most of its (non-MOK) certificates and SBAT data into this PCR. — https://uapi-group.org/specifications/specs/linux_tpm_pcr_re...
It makes sense to use the certificates to generate PCR 7. I wonder if you can swap out the motherboard with one of the same model with the same certificates without modifying the PCR 7 digest...
But if Shim actually modifies the digest, I guess that SB would completely mitigate OP's exploit since the TPM policy is going to fail when the PCR 7 values doesn't match.
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.
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.
With LUKS it at least has a password prompt to unlock the drive.
> I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that
It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around.
> With LUKS it at least has a password prompt to unlock the drive.
Configuration dependent. You can set up Linux to do the same thing as Windows here (I have my home video-security server set up this way, as it needs to reboot silently - I know that I'm vulnerable to warm/coldboot attack and software attack surface, but at least if someone yoinks the drive I'm safe), and Windows can also be configured to prompt for a password or use PIN-authenticated TPM sealed keys.
> Fundamentally I don't understand BitLocker's security model.
Minus the parameter encryption / bus-sniffing issue, it moves the boundary from "anyone can read your drive" to "someone needs to either perform a platform-level attack to access the contents of memory, or hack whatever services are running at the login screen to read your drive." It's a decent security improvement, actually, because it protects very well against stuff like "someone stole our financial data off of a random recycled hard drive."
> It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around.
AFAIK it is useless, there is no way the TPM could authenticate the CPU. You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.
"Useless" is grossly incorrect. Bitlocker is not invincible, but it lowers your threat surface by a huge %.
In real terms: if i get your unbitlockered hard drive, i own your shit. It's not a hack you pay crypto for on the dark web, it's a trivial compromise that every person in IT has known for at least a decade. If you google it, you'll find it. Ring 0 access to all nonbitlockered windows installs. Takes like 2 minutes and a usb or cd.
With bitlocker, at least every idiot on the planet can't login to your profile; that's not nothing
Considering security "researchers" absolutely love to make cataclysmic mountains out of vulnerabilities that require local, physical access as the first step?
It's one of those "useless in theory but extremely meaningful in practicality" things, IMO. Getting the correct PCRs is going to be a whole lot harder than putting a sniffer on the LPC. It takes the attack from something that random TikTok security "influencers" sell devices for to something which requires meaningful effort.
Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU and probing the signals in the chip is probably outsider of the budget of TikTok influencers.
At an enormous cost of having to remember and enter a PIN - not practical for corporate IT due to the propensity for forgetting and not practical for offline server use.
> Anyways on many modern system the TPM is often just part of the firmware running on a secure part of the CPU
On AMD this is almost 100% prevalent, yes.
On Intel platforms a physical TPM is still common and PTT (firmware TPM) is usually disabled by default for some reason - a user/manager would usually have to re-select it in the BIOS. On desktop platforms I think PTT runs externally in the PCH, too, which is off-package and connected over DMI (I think on most mobile parts PCH is a separate on-package die). I don't think anyone has done research on how the fTPM part of PCH <-> CPU comms work on modern Intel platforms; this has always seemed like a fun topic for a deep dive and talk to me, but I've never had the time.
I don't think either of these things excuses the lack of encrypted parameter support from BitLocker, though. I'd love to know why Microsoft continue not to use it. The only reason I've ever seen given is "it was deemed too complex / has an attack surface," which is an interesting idea but quite bunk when UEFI is already in the picture IMO.
I haven’t used Windows since the XP days. Does Windows not have a login password? Or does something make it require a separate disk PIN and not just encrypt the drive with the login password? macOS does the latter and it seems like an obvious approach.
In this case, they're talking about the Bitlocker disk encryption PIN, which is in _addition_ to the Windows password, or more common now, PIN. You can set them both to the same thing if you choose.
The disk PIN on boot is uncommon/harder to do for home users, but it's a common setup in the corpo world. Enforced by AD, or Intune.
I'm not aware that Windows uses your login key to encrypt anything on the disk, but maybe Windows 11 does it differently than <=10.
The disk password actually encrypts the disk, so you can't just pull the disk out and read it, or boot Linux from a flash drive and read it.
You can do the above attacks when all that's set is a Windows password. In fact, you could even modify the OS at that point so it logs and exfiltrates passwords in the future.
> So if someone steals you machine with an encrypted hard drive they need to...just turn it on?
That'd bring them to a login screen. Without your password or biometrics, they're not getting past that. They'll have to figure out some kind of workaround (like a RCE exploit, or booting an old, vulnerable Windows bootloader somehow) because they can't do the usual "replace the software keyboard with cmd.exe" workaround as the drive remains locked.
Without Bitlocker, you can plug a Windows drive into your PC and browse all the files. With Bitlocker, you need to faff about with exploits and vulnerable Microsoft software and dumped memory, and even that doesn't always work.
With Bitlocker configured in TPM+PIN mode, you can't even do that, as you don't have the password to unlock the TPM. You could also put Bitlocker in password-only mode, but that's much easier to brute-force. Same goes for LUKS, by the way, which also supports TPM and TPM+PIN in most Linux distros these days.
> 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.
Yes, but the idea is that from the login screen (winlogon) you really can't do much unless you actually have account credentials on the computer - or are bio-metrically enrolled into the computer* - and if you attempt to reboot to safe mode, or reboot to a different OS (or firmware update utility, etc) you do need to enter the Bitlocker recovery key.
* I'm not sure how it works in terms of "hacking" fingerprint sensors or face recognition webcams.
The primary purpose of Bitlocker (when used with a PIN + TPM) is it makes a powered off computer or a drive itself as good as a brick. Assuming the TPM doesn't have any key extraction vulnerabilities.
Keyword is powered off.
With any general purpose drive encryption, the TPM doesn't actually decrypt the bulk of the data as its too slow so the OS eventually ends up with a key that is extractable.
In Pro editions it is also possible to require an interactive step at boot time via group policy (this also works if you have no TPM available), then it will ask for a password on each startup.
While I am aware of bitlocker in general, I don't have a full grasp of it. Just how secure is it from a software of hardware attack?
It was my understanding that veracrypt was considered more tested than bitlocker due to the lack of backdoors or workarounds. Can anoyone point me at some good resources regarding this?
It depends on the mode you're using. If you use the transparent unlock functionality (the default) then it's vulnerable to hardware key extraction. If you use anything else (PIN, password, whatever) then I'm not aware of any weaknesses or workarounds. I'm certainly not aware of any backdoors.
I think with a Microsoft account login on Windows 10/11, BitLocker recovery keys are synced to your Microsoft account and can be viewed from your Microsoft account device settings. They may also be present on Active Directory so there may be some vulnerabilities on any of those avenues which may be easier to circumvent than BitLocker itself.
> With LUKS it at least has a password prompt to unlock the drive.
BitLocker should ideally be used with a PIN/password too. This means the key isn't decrypted until the correct PIN is entered. No SPI sniffing, UEFI exploits, or memory dump would help the attacker in this preboot state. BitLocker with TPM and PIN is a pretty powerful combination.
But by default, without any second factor, BitLocker is two parts convenience and one part security. Probably the price of user adoption.
If someone steals the device and removes the drive the data is encrypted.
If someone steals the device and powers it on, the os that wrote the encrypted data (and is presumably secured) can enforce login authorization which the thieves presumably cannot bypass.
Both of these are big ifs, but the installed os won’t just divulge the contents of the disk so the trick is locking down the disk so that it’s easy for the installed os to access but becomes useless if the disk is removed from the computer.
All of this depends on the TPM implementation not being trash, which integrated instances help with. Ultimately this is a trade off for convenience. I don’t worry about random thieves probing the buses in my computer to get my tax info, so I don’t use luks’ other stuff.
Auto unlock only happens with a TPM. You couple TPM with encrypted RAM, Secure Boot and tamper-detecting erase. So if they remove the bottom cover, TPM is cleared and you need to enter the recovery key. Encrypted RAM prevents extracting secrets from sleep state. All corporate laptops have these features (and also remote erase / destroy with Intel ME / AMT). A correctly setup system will cover almost all of the attacks in physical nature. Of course they can still find exploits in logon screen. It is good enough security combined with convenience. It is more secure than letting normies (and lazy techies) use 12345678 as the pin.
It isn't enabled by default likely because it makes updates more of a manual process and they decided timely updates were a more important attack surface
This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-gr... - 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?
"BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory."
I would extremely not trust most platform implementation of TCG Reset Attack Mitigation, though. I've never seen a UEFI platform that is even close to correctly implemented in any form. It would be interesting to know which platform this researcher was working with, and whether it purports to support the MOR bit or not.
>However, this measure can still be circumvented by removing the memory module from the system and reading it back on another system under the attacker's control that does not support these measures
> "BitLocker uses the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory."
(Edit: No this is a UEFI request to clear memory. Below is incorrect.)
I don't think this is what the commenter was mentioning. I think this essentially makes it only possible to extract the key from the TPM once and then the TPM needs to be powered off and back on to get it again.
The TPM has no control over whats in the system memory, so if they key is in system memory, no TPM mitigations are going to help.
UEFI firmware must support clearing the keys from RAM.
That's a very stupid mitigation as you can mess with RAM during the overwrite. Heck, see how Team Tweezers originally exploited the Wii.
The real mitigation is the memory encryption feature of modern CPUs. Being on-die means tweezers won't reach, and being just a key means the wipe is instant and very difficult to mess with even if it survived a power cycle.
After reading the article again, I think this might be an actual interesting Windows vulnerability - rather than a platform issue with MOR, I think this might be bad Windows code where the key is left over in places that aren't protected by MOR. It's quite unclear the more I think about it what's going on here, and the article lacks detail. It's very suspicious to me that the key has disappeared from the `ksecdd` pool but remains in the `dumpfve` pool, and this has my bug spidey-sense tingling.
I'm surprised given that the article mentions stepping into the boot process and `SymCryptSessionDestroy` that they didn't look more deeply into this; it's not how I really intended to spend my new years but I might have a new debugging project now...
Hello! I'm the author of the article and I actually did look into that. I used windbg and stepped through the process of windows booting up to the point of expecting a password. I also looked at what happens when you trigger bitlocker in a way where it requests a recovery key.
I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets.
Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...
MOR should be wiping everything, especially since after a cold boot the firmware has no idea what the previous memory map was. But I can imagine a universe where it doesn't wipe the boot services heap space (because some of that is obviously in use) and maybe a copy is hanging out there in a predictable way?
It's something that's only triggered in the event of an unclean reboot so under normal circumstances it should be irrelevant and trying to be more elegant potentially increases risk?
The inelegant approach increases risk by relying entirely on the OS being sure that the key is never recoverable from memory on clean shutdown, and on the firmware ensuring that all used RAM is sufficiently wiped in all unclean scenarios.
What if Windows forgot to wipe a spot after having relocated a page? What happens if the firmware's boot flow is interrupted by, say, a hardware fault prompt, a low battery prompt, etc.? There's a lot of places where that approach can go wrong.
The key approach is simpler and comparatively bullet proof: If the machine is rebooted, clean or not, the key will be lost and no memory that was previously used will be readable. All it takes is the OS initializing a single CPU feature on boot, with the only downside being that it requires support for a quite modern CPU feature.
> This still won't prevent yoinking the entire RAM modules and dumping them offline.
Theoretically no, but realistically I doubt even intel agencies can pull this off.
> Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
> In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
This already exists: it's the MOR bit and it's supposed to be in play here.
I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
> I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
True. Given that the CPU is what's resetting and running the UEFI code, you better hope it could recognize and clear a scratchpad reliably.
The issue is that any memory readable by a software directly has some kind of risks, including SRAM. Here is something something you might find interesting: https://forte-research.com/UnTrustZone/ There is no absolute security, but keeping secure memory away from software provides much better solution.
TrustZone is not a great solution here, the decryption needs to be fast, and this really means that the key should be directly accessible to the kernel.
Having it only inside the cache SRAM mitigates all the offline attacks. SRAM immediately loses content on power disruption (its state is encoded in the current path, not in a capacitor charge). And it's trivial to completely and unconditionally erase on boot.
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.
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].
Microsoft is moving more and more to virtualisation based security, including the ability to run “enclaves” for protecting specific pieces of software: https://learn.microsoft.com/en-us/windows/win32/trusted-exec.... I wouldn't be surprised if they'll soon leverage encrypted “VMs” as a means of storing secrets like these. All we need is wide general hardware availability on consumer platforms.
That said, previous side-channel attacks on CPUs have shown it possible to attack encrypted memory (https://www.usenix.org/conference/usenixsecurity21/presentat...), targetting the cache as the CPU decrypts memory for normal operation. While it'll stop memory dumps from being effective, encrypted RAM won't be the end of dumping keys from memory, especially for patient or highly-skilled attackers.
Memory compression has been around for ages, at least since Windows 10 RTM. All major operating systems have implemented this feature -- it has no relation to security, though.
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?
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.
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?
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?
In theory? Sure. In practice? Establishing DDR links involves a lot of negotiation between the memory controller and the RAM and being in a situation where you can maintain the same timings while also dumping data isn't going to be easy. I wouldn't expect this to be an off the shelf solution.
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.
It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%)
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
I was trying to recover data off a laptop in basically the same situation. My solution was to boot into a WinPE live USB and use bcdedit to enable safe mode (as trying to do it the normal way would ask me for the BitLocker key), which let me boot without BSODing. Though this wouldn’t work if the BSOD happens in safe mode as well…
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.
Ages ago I had an external drive that had a controller with built in keys that encrypted the data in and out. Problem was that the controller was poorly made and one time upon connecting to the PC, the controller chip died and so the keys with it. It was impossible to recover the data, but the disk itself was perfectly fine. I bought a damaged drive with working controller and swapped it out and my drive worked again, however I had to format it, because new board had different keys.
Since then I preferred to use software encryption and steered clear of drives that use any sort of hardware encryption. The risk of losing data was not worth it.
All SSD's with OPAL are always encrypting your data. "Enabling" the feature just means that you change from a random on-device key to a key encrypted with your passphrase.
(Whenever you wipe the drive through OPAL, you're just overwriting the key.)
Quite dumb considering this was an issue with pretty much a single, low-cost consumer vendor (Crucial?).
If nothing else, use it in combination - the encryption of OPAL drives is always active anyway, all that changes when the feature is "active" is whether the key is stored as-is on the controller or whether its protected by a passphrase.
The Crucial drive did not have any association between the encryption key and the passphrase, making it possible to bypass encryption.
The Samsung drive had an issue where when setting a passphrase, wear leveling could cause the old unprotected key to still exist on a flash bank (not normally accessible) until that bank got reused.
Only one of them is horrible incompetence - the other is bad but fixable and expires on its own after a bit of use.
And in either case, it doesn't matter in the eyes of Microsoft. Drive manufactures couldn't be trusted -- and honestly, the amount of "awesome" software coming from component manufactures is pretty small.
The drive manufactures software was making Microsoft look bad. The advantage of SED was small when we have AES-NI.
True, Microsoft can't be expected to make software that is good for the sake of being good. Maybe they'll consider now Microsoft looks bad on their own - OPAL2.0 on modern drives is quite a different beast than what they pulled out of.
Note that the advantage is still very large - easily 20% and an associated hit to battery life, depending on the specific cipher mode and access pattern. Without AES-NI it just wouldn't be practical to even consider AES-based FDE.
I like using OPAL on my low powered laptop (8th gen i3), since Bitlocker eats some of that prescious CPU. Testing showed the impact of BL to be about 20% worse for the write speed and somewhere around a few percent read.
Not earth shattering, but for SATA3 era SSDs, it's not nothing either. The old 850 EVOs work well, and they're quality disks IME.
Now, drives with eDrive, as MS calls it, are becoming harder to find. It is no longer advertised (as native 4k sectors aren't either...). Soon it'll be dropped all together.
I blame the mess that was Wave Systems and the shitty meddlingware they built to try to manage it all.
The support experience was one of the absolute worst I’ve ever seen — and I was the guy on the end of the phone that had to say “thank you for calling Wave Systems Gold Support” having been given zero documentation into what the product even did, but being told we had to log tickets into MS Dynamics and pray that a Wave engineer would call a panicked locked out user back “soon”.
This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader.
Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection.
Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout.
This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery.
And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out.
Do this experiment.
Boot into any Linux live CD on a machine with bitlocker enabled.
No, the TPM doesn't retain PCR measurements over reboots, and the log (rather than the composite PCR value) is handled by the firmware and the OS and the TPM has no idea it exists.
It doesn't matter if you change the settings back. I don't know how it works, but something non-user configurable is changed that prompts Windows to require a reset of the TPM keys.
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.
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
> 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.
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?
So this is just another theoretical attack where perfect conditions must be met.
This attack has nothing to do with the memory type; memory is never made cold or allowed to decay. The system is hot-restarted into UEFI. Ideally no memory refreshes are skipped.
I do wish they provided the hardware specs too, though, as this reflects an incorrect UEFI platform implementation of MOR.
You are right, but i still have no idea what is the point of this article.
The guy unlocked the bitlocker, then restarted PC just before login screen appeared. He said that's when he had most success. What sense does it make to restart and start looking for key in memory, when bitlocker has been just unlocked.
I steal your Windows laptop. I want your data. I don't have your credentials, so can't login to Windows. I let your laptop boot to the point where Bitlocker is automatically unlocked, perform a hard reboot, dump the RAM, extract the keys, and can now decrypt your drive and extract your data.
> What sense does it make to restart when bitlocker has been just unlocked.
You steal a laptop. You turn on the laptop. You reboot it into UEFI and steal the keys. This is bad for BitLocker. Ideally this is not possible because the MOR bit should cause the keys to be erased by the platform initialization before boot-from-USB is possible.
Bitlocker is unlocked before you reach the login screen.
If I understand correctly, you need to start the PC, reboot just before the login screen appears, and boot to an USB application, which will copy the memory content.
You seem to think it's common to require a separate BitLocker unlock step. In reality, this is extremely rare: the vast majority of users have no idea about any of this and have BitLocker set to automatically unlock during system power on.
So this is a viable attack on many, many real-world systems. Adding a BitLocker password/PIN is a mitigation that prevents this attack.
Note that BitLocker is still very useful even in this mode: it guarantees that someone who steals your laptop can't just connect the disk to another system and read everything on it, unless they can actually extract the keys from RAM, or bypass Windows authentication - this attack allows them to do the former relatively easily.
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.
Even if you are using Transparent Operation Mode then it still will not work as bitlocker will not decrypt the drive and lock itself into recovery mode if you make changes to the boot order or any other BIOS / UEFI changes.
It uses secure boot and it’s pretty darn decent at detecting any form of tampering.
TPM 2.0 isn’t particularly resilient against physical key extraction attacks but believe it or Microsoft did threat model this…
This happened to me once. Sadly I had wiped the flash drive containing the recovery key months before the lockout without realizing it. Chide me if you must, but I certainly learned my lesson.
I tried a few non-hardware exploits, even CVE-2022-41099 about WinRE but to no avail.
I’m not a security pro, but I assume once it is in recovery mode lockout you’re pretty much out of luck. From what I can tell most other exploits require it to be unlocked in the first place. Even the hardware hacks seem to require a drive being in a non-lockdown state in order to sniff things during boot.
That NVMe drive is just a keepsake now. I plan to frame it and put it on my wall as a memento.
This is why i use the key backup to OneDrive option.
My threat model is a lost or stolen device or RMA/repair.
If someone wants my data so badly that they’ll be able get into my OneDrive account that is protected with a passkey or a 32 char password + MFA and also have physical access to my devices let them have it.
Anyone who is that determined and capable can always resort to rubber hose cryptography and I want none of that in my life.
This sounds like BitLocker wasn't enabled on the drive. All of the laptops I've deployed with BitLocker are very good at detecting tampering and will immediately go into lockdown mode. A Linux USB most likely requires Secure Boot to be turned off to boot, if so, the TPM tamper will trigger and BitLocker will require the recovery key at next boot.
> A Linux USB most likely requires Secure Boot to be turned off to boot
That hasn't been my experience. All the recent laptops I've owned (Dell and HP) had a default secure boot setup that allowed booting to Ubuntu and Fedora without disabling Secure Boot. In fact, nowadays even Ventoy works with Secure Boot [0], and I've managed to use it with the setting enabled on all machines I've tested, however in this case you might need to enroll the keys on the first boot, which I imagine will trigger BitLocker.
Apparently what happened is that Microsoft now signs some third party certs for common Linux distributions, and some setups allow these to boot by default. However, it also looks like Microsoft wants these certs disabled by default [1], which should improve BitLocker integrity on average.
Although I believe what happened in OP's situation was that BitLocker wasn't actually enabled or working, likely due to misconfiguration or lack of any.
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:
1. Bind to PCR 7
2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated)
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.
4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub.
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!