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.
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.
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.
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.
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"
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.
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.
> 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?
> 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.
> 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.
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.
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.
Readit News
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!
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.
This attack reads the key from RAM, so I don't see how a TPM PIN would mitigate 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.
Deleted Comment
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.
Bitlocker already does this if you use a PIN/password.
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?
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.
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.
"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"
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.
Avoid GRUB, difficult to secure with it.
Kernel updates will also be painful…
GRUB and all other boot loaders are unecessary with UEFI. See my comment history for more.
Kernel updates + Secure Boot is easy with a Debian hook.
The hard part is making it work with TPM when you want to add encryption...
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.
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."
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.
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.
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.
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.
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?
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.
Deleted Comment
https://techdirectarchive.com/2023/10/08/how-to-enable-a-pre...
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
"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.
https://en.wikipedia.org/wiki/Cold_boot_attack
(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.
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.
Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
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.
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
Both Intel and AMD are working on embedding this into their CPUs.
However, the target use appears to be servers with multiple VMs, not laptops.
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.
https://techcommunity.microsoft.com/blog/windowsosplatform/m...
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.