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!
michaelt 18 days ago [-]
> 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.
tchebb 19 days ago [-]
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.
indigo945 19 days ago [-]
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.
0xDEADFED5 18 days ago [-]
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.
bmicraft 18 days ago [-]
You can't change something on an encrypted volume without knowing the encryption key
Neil44 18 days ago [-]
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.
18 days ago [-]
ruthmarx 13 days ago [-]
> the old utilman (or other suitable module) replacement hack from Windows repair (trigger by interrupting boot),
Can you elaborate on this?
18 days ago [-]
derekerdmann 19 days ago [-]
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.
p_ing 19 days ago [-]
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.
mjg59 19 days ago [-]
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)
jansommer 19 days ago [-]
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.
prmoustache 18 days ago [-]
It might make it super hard to do an a laptop where you can't usually force reset easily from the power button.
Having said that a number of laptops can still be opened without being powered-off if you do it carefully.
18 days ago [-]
highwaylights 18 days ago [-]
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.
dist-epoch 18 days ago [-]
> 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.
highwaylights 16 days ago [-]
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).
currysausage 18 days ago [-]
> use TPM (PCR 7+11) with a PIN
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?
varispeed 19 days ago [-]
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.
arghwhat 19 days ago [-]
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.
eddythompson80 19 days ago [-]
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"
jeroenhd 19 days ago [-]
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).
raron 19 days ago [-]
> 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.
varispeed 19 days ago [-]
That's a definition of security by obscurity.
PhilipRoman 19 days ago [-]
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.
varispeed 18 days ago [-]
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.
SAI_Peregrinus 18 days ago [-]
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.
raron 19 days ago [-]
Some of these features makes it harder to (physically) probe the internal parts of the chip and read out secret values:
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.
rcxdude 18 days ago [-]
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).
okanat 19 days ago [-]
Printing out your 2FA recovery keys and storing them in a safe also is.
eptcyka 19 days ago [-]
Is a yubikey then employing security by obscurity?
formerly_proven 19 days ago [-]
100%
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.
eptcyka 18 days ago [-]
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.
varispeed 19 days ago [-]
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.
gruez 19 days ago [-]
>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?
prmoustache 18 days ago [-]
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.
p_ing 19 days ago [-]
Lest one forget NSAKey! /s
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.
Otherwise we're debating to prove a negative.
jeroenhd 19 days ago [-]
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.
jansommer 19 days ago [-]
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.
cheschire 19 days ago [-]
I prefer to think of TPM as equivalent to the chip in a smart card.
mikepurvis 18 days ago [-]
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.
BobbyTables2 19 days ago [-]
Might need most of PCRs 0-7. Isn’t PCR 4 used to measure the EFI executable booted by UEFI?
Avoid GRUB, difficult to secure with it.
Kernel updates will also be painful…
jansommer 19 days ago [-]
7+11 is default for BitLocker as far as I know. Binding to other values will bite you later if you update UEFI firmware or change some settings.
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...
jansommer 18 days ago [-]
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.
jandrese 19 days ago [-]
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.
bri3d 19 days ago [-]
> 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."
raron 19 days ago [-]
> 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.
kryogen1c 18 days ago [-]
> AFAIK it is useless
"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
tremon 19 days ago [-]
That's the same kind of useless as "I don't have a front door. You could always drive through it with your car and get inside that way", right?
Dalewyn 18 days ago [-]
Considering security "researchers" absolutely love to make cataclysmic mountains out of vulnerabilities that require local, physical access as the first step?
Yes, it's the same kind of useless.
bri3d 19 days ago [-]
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.
raron 19 days ago [-]
Using Bitlocker with a PIN solves that.
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.
bri3d 19 days ago [-]
> Using Bitlocker with a PIN solves that.
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.
p_ing 19 days ago [-]
The Intel PCH is on-package exposed via [DMI] PCIe lane while AMD's fTPM is on-die.
It would be unusual for any current device to have a discrete TPM, at least in the consumer space given current x86 processors have an fTPM.
wat10000 18 days ago [-]
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.
briHass 18 days ago [-]
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.
wat10000 18 days ago [-]
A disk PIN shouldn’t add much extra security, though, unless the login password isn’t actually used to key the encryption.
BenjiWiebe 18 days ago [-]
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.
p_ing 19 days ago [-]
TPM is now in firmware and has been for quite a few years on Intel and AMD processors; Intel's on the PCH which is on-package and AMD's on-die.
This isn't true for all implementations of TPM, but for AMD/Intel/Qualcomm where BitLocker is relevant, fTPM is used.
> You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.
In modern CPUs, the TPM is built directly into the CPU, so you can't do this.
mikepurvis 18 days ago [-]
All modern CPUs now have it on-die, so doing a replay attack against desoldered TPMs is no longer a thing.
jeroenhd 19 days ago [-]
> 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.
sebazzz 19 days ago [-]
> 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.
rzzzt 19 days ago [-]
You also can't look at the encrypted drive's contents if you connect it to a different machine.
sebazzz 17 days ago [-]
No, I expect the encryption key is probably stored in an efivar.
bangaladore 19 days ago [-]
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.
tonetegeatinst 19 days ago [-]
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?
mjg59 19 days ago [-]
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.
aspenmayer 19 days ago [-]
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.
vel0city 19 days ago [-]
Syncing keys to OneDrive is optional, at least on the Pro versions of Windows.
buran77 19 days ago [-]
> 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.
arzig 19 days ago [-]
The threat model is getting the decrypted data.
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.
18 days ago [-]
okanat 19 days ago [-]
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.
anaisbetts 18 days ago [-]
fwiw, you can enable this on Windows too with a simple command:
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
Hilift 18 days ago [-]
BitLocker may also be configured for a password. This attack is very narrow.
mjg59 19 days ago [-]
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.
gruez 19 days ago [-]
>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.
mjg59 19 days ago [-]
This is exactly what I was mentioning. Despite being a TCG spec, it's implemented in firmware and has no hard requirement on a TPM at all.
bangaladore 19 days ago [-]
Okay, thanks for the correction.
The naming there is definitely confusing. Particularly as it sounds like a key attribute bit.
arghwhat 19 days ago [-]
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.
mjg59 19 days ago [-]
It would entirely prevent the described attack. Related attacks may still be possible, but are also significantly harder than simply booting off USB.
bri3d 19 days ago [-]
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...
NoInitRD 18 days ago [-]
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...
bri3d 18 days ago [-]
Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.
mjg59 18 days ago [-]
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?
NoInitRD 18 days ago [-]
This is my understanding of whats going on.
arghwhat 18 days ago [-]
Fair enough, but I'll still hold that wiping all system RAM is a comparatively dumb and slow solution even in this specific scenario. :)
mjg59 18 days ago [-]
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?
arghwhat 18 days ago [-]
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.
cyberax 19 days ago [-]
This still won't prevent yoinking the entire RAM modules and dumping them offline.
Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
bangaladore 19 days ago [-]
> 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.
bri3d 19 days ago [-]
> Theoretically no, but realistically I doubt even intel agencies can pull this off.
> 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.
bangaladore 19 days ago [-]
> 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.
zebra_bong3 19 days ago [-]
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.
cyberax 19 days ago [-]
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.
mjg59 19 days ago [-]
Just have the CPU microcode clear SRAM whenever the CPU is booted
zebra_bong3 16 days ago [-]
That is what that paper says. No cpu does that.
NoInitRD 19 days ago [-]
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.
1970-01-01 19 days ago [-]
This is an excellent write-up. It's short and to the point, with links right where I would want them.
NoInitRD 19 days ago [-]
Thank you so much for your compliment, and for reading it. I tried to make it as thorough and informative as possible.
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].
Windows has a proposed memory encryption option along with memory compression.
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.
jeroenhd 19 days ago [-]
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.
p_ing 19 days ago [-]
Intel has this via their Total Memory Encryption feature today. Yes, geared towards VMs in the Windows ecosystem.
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?
mjg59 18 days ago [-]
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.
dist-epoch 18 days ago [-]
New AMD/Intel CPUs support transparent full memory encryption, your interposer will just see encrypted RAM data.
dist-epoch 18 days ago [-]
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%)
But it would completely prevent this attack.
sedatk 18 days ago [-]
As I understand, the features are called SME (Secure Memory Encryption) on AMD, and TME-MK (Total Memory Encryption-Multi Key) on Intel.
ibbtown 18 days ago [-]
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
aprilnya 18 days ago [-]
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…
shortsunblack 18 days ago [-]
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.
Game over, any laptop with data worth stealing will have this disabled in bios
totalizator 17 days ago [-]
Valid point but what about the reality? Imagine typical Evil Maid attack but within a workplace, as a cleaning staff. Game over.
jpalomaki 18 days ago [-]
You can make things a bit harder by locking the boot order in bios and password protecting the bios settings.
Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
slicktux 19 days ago [-]
Why are more people not using self encrypting drives?
varispeed 19 days ago [-]
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.
arghwhat 19 days ago [-]
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.)
Microsoft patched out support for self encrypting drives.
arghwhat 19 days ago [-]
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.
p_ing 19 days ago [-]
Both Crucial and Samsung, which produce a significant number of OEM drives for the likes of Dell, HP, etc.
arghwhat 18 days ago [-]
It was two entirely seperate vulnerabilities.
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.
p_ing 18 days ago [-]
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.
arghwhat 18 days ago [-]
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.
briHass 18 days ago [-]
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.
OptionOfT 19 days ago [-]
It's actually still in there.
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.
vel0city 19 days ago [-]
Seems like most of the big drive makers had pretty poor quality on the whole self encrypting part of it, at least last I saw a few years ago.
kotaKat 19 days ago [-]
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”.
slicktux 19 days ago [-]
There are standards and a lot of the stigma comes for AT Password enclosures…
3eb7988a1663 19 days ago [-]
What was the hardware on which this was running? I thought DDR5 would be more resistant to this type of RAM attack.
Arnavion 19 days ago [-]
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.
Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
dogma1138 19 days ago [-]
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.
mjg59 19 days ago [-]
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?
dogma1138 19 days ago [-]
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.
Reboot and see what happens.
vel0city 19 days ago [-]
I did that last night. It didn't have any issues booting back into Windows after booting to a live USB.
I didn't change any parameters of the Windows boot option or the rest of the system.
aspenmayer 19 days ago [-]
It seems that this is a property of TPM 1.2.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
Changing it will trigger recovery, changing it back to the original won't
vel0city 19 days ago [-]
Yeah I seem to recall every time I've done that it seems to auto boot fine when I change it back to what it was before.
And as mentioned it's never had issues if I did a one off choice from the boot menu.
mjg59 19 days ago [-]
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.
aspenmayer 19 days ago [-]
It seems that this is a property of TPM 1.2.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
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.
wh_123 18 days ago [-]
Reminds me the cold boot attack....
EVa5I7bHFq9mnYK 18 days ago [-]
Why bitlocker specifically? Will GPG encryption survive if an attacker can dump the RAM at any moment while it encrypts a file?
devops99 18 days ago [-]
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.
DEEP-MELTDOWN 19 days ago [-]
[dead]
maxo133 19 days ago [-]
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.
bri3d 19 days ago [-]
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.
maxo133 19 days ago [-]
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.
mjg59 19 days ago [-]
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.
bri3d 19 days ago [-]
> 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.
watermelon0 19 days ago [-]
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.
tsimionescu 19 days ago [-]
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.
NoInitRD 19 days ago [-]
Hey I'm the author. I did this on DDR4 RAM. Specifically, it was F4-3600C18D-32GVK in two slots and MD16GK2D4320016AXR in the other two.
tnetenbaa 19 days ago [-]
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.
dogma1138 19 days ago [-]
You should’ve enabled bitlocker first then…
The only thing that would be unencrypted is the system restore partition.
Dislocker does require you to have the keys tho it’s not a bypass.
Grazester 19 days ago [-]
Then the drive wasn't encrypted!
connicpu 19 days ago [-]
Presumably they chose the weakest option where it can boot without a pin/password just using a key stored in the TPM.
dogma1138 19 days ago [-]
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…
BuyMyBitcoins 19 days ago [-]
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.
dogma1138 19 days ago [-]
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.
davemtl 19 days ago [-]
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.
doodlesdev 18 days ago [-]
> 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!
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.
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.
Can you elaborate on this?
> 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.
https://support.microsoft.com/en-us/topic/september-24-2019-...
https://nvd.nist.gov/vuln/detail/CVE-2018-12037
https://threadreaderapp.com/thread/1059435094421712896.html
This is amazing.
> The encrypted SSD has a master password that’s set to “”
HN discussion here: https://news.ycombinator.com/item?id=18382975
Original paper here: https://cs.ru.nl/~cmeijer/publications/Self_Encrypting_Decep...
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.
Having said that a number of laptops can still be opened without being powered-off if you do it carefully.
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.
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?
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"
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).
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.
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.
https://en.wikipedia.org/wiki/Secure_cryptoprocessor#Feature...
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.
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.
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.
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?
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.
Otherwise we're debating to prove a negative.
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.
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.
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...
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?
[1] https://blog.scrt.ch/2023/09/15/a-deep-dive-into-tpm-based-b...
So I really doubt TPM will release the keys on a different motherboard with different UEFI settings.
User changed motherboard and TPM complains: https://old.reddit.com/r/pcmasterrace/comments/vdvni1/swappe...
> 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.
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.
"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
Yes, it's the same kind of useless.
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.
It would be unusual for any current device to have a discrete TPM, at least in the consumer space given current x86 processors have an fTPM.
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.
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.
This isn't true for all implementations of TPM, but for AMD/Intel/Qualcomm where BitLocker is relevant, fTPM is used.
Where it states: Module dTPM 2.0 (Discrete Trusted Platform Module)
Same for HP EliteBook and ProBooks: https://h20195.www2.hp.com/v2/GetPDF.aspx/c08049273.pdf
In modern CPUs, the TPM is built directly into the CPU, so you can't do this.
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.
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 naming there is definitely confusing. Particularly as it sounds like a key attribute bit.
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.
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...
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...
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.
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.
For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though.
> 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.
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.
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.
[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.
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?
It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%)
But it would completely prevent this attack.
https://youtu.be/WK7NERQXh4I
Game over, any laptop with data worth stealing will have this disabled in bios
Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
(Whenever you wipe the drive through OPAL, you're just overwriting the key.)
Microsoft patched out support for self encrypting drives.
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.
The drive manufactures software was making Microsoft look bad. The advantage of SED was small when we have AES-NI.
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.
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.
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”.
See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards.
Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
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.
Do this experiment.
Boot into any Linux live CD on a machine with bitlocker enabled.
Reboot and see what happens.
I didn't change any parameters of the Windows boot option or the rest of the system.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
https://learn.microsoft.com/en-us/windows/security/operating...
And as mentioned it's never had issues if I did a one off choice from the boot menu.
> On devices with TPM 1.2, changing the BIOS or firmware boot device order
https://learn.microsoft.com/en-us/windows/security/operating...
It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.
> 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.
I do wish they provided the hardware specs too, though, as this reflects an incorrect UEFI platform implementation of MOR.
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.
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.
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.
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.
The only thing that would be unencrypted is the system restore partition.
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…
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.
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.
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.
[0]: https://www.ventoy.net/en/doc_secure.html
[1]: https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-...