What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?
It also strikes me that these are several very high value (all but one complete) exploits.
Surely the value of these on the market would be astronomical and best suited to law enforcement agencies using unlock as a service businesses.
So I have to say I applaud the open disclosure
They also seem suitable for using a secret sharing scheme.
I have Microsoft authenticator requests all day every day. Using aliases has helped but somehow they continue. It's only a matter of time before somehow accidentally I approve.
Which has simply led to me not putting anything of high value in my Microsoft account and not using it for my email.
I had someone demo me preserving PCR values by patching SMM module in firmware without triggering any bitlocker lockout, this also means that you can externally write bios with the smm module as long as you have ~2 minutes to disassemble the laptop or desktop and flash firmware.
This hurts the most when you don't have PIN authentication which means you just need to steal the laptop to exfiltrate data, if you do then you have to have the user boot which then drops a payload exfiltrating data over network or just stealing the laptop again as you can write back decryption keys into non encrypted partition or corrupt some sectors at the end of the disk and write them there.
* modifying smm allows you to patch the boot process loading a malicious payload into hypervisor/kernel.
I know my bike lock can be cut within seconds by someone who is sufficiently skilled and determined. I'm still going to lock my bike.
Also, I'd argue the stolen bag scenario usually features dilletante attackers.
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
Oversimplified and not accurate. Some manufacturers had flawed implementations, others did not. Also, that was a long time ago. There are advantages to hardware encryption. It preserves performance and mitigates other vectors like cold-boot attacks without having to encrypt RAM, which also comes with a performance penalty. By the way, both software and hardware-based encryption can be combined. Cryptsetup on Linux actually offers this, and before you ask, the keys are split. If one is compromised, the other remains secure.
Less emotionally but mostly equivalently, the expense and non-cryptographic skill requirements of breaking mass-storage crypto are quite high while the rewards are comparable to those from breaking much softer targets, so the absence of results since that one paper only changes my mind very slightly. Besides, we know plenty of examples of what these kinds of opaque, serious-business, pay-to-play environments produce: cellular crypto is an uninterrupted series of disasters, so is Wi-Fi, and the things that we do know about storage devices don’t point to an outstanding culture of cryptographic competence there either. Once you’ve done enough to slap an “OPAL” label on it (which says nothing about the internals), there’s just no competitive pressure to improve.
There is a right way to do all this, and it’s essentially what NICs do: allow the host to offload symmetric crypto to the device, but keep the results of said crypto accessible at any moment. And it’s not like there are even that many modes used in full-disk encryption, let alone ciphers.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
> (Note: The YellowKey author disagrees that PIN is a protection
God I hate this stupid design of burying the decryption key in the TPM and hoping the software does not get fooled to reveal it.
Microsoft always sucks. Why don’t you ask for the password at boot time and derive the key from it. So much simpler and makes this kind of attacks impossible. Nobody is going to bypass LUKS or FileVault like this.
Does anyone really trust these shitty Windows laptop/desktop manufacturers to get these things right? These guys couldn't even get basic hardware features like trackpad drivers right.
Since there's a ton of misunderstanding in this thread, I'm going to go into how disk encryption works conceptually.
First, there's a symmetric key to encrypt blocks on the disk. Since you want to be able to change your unlocking password/mechanism without re-encrypting everything on the disk, this has nothing to do with unlocking the disk. This is what you want to get BY unlocking the disk. Let's call this the "data encryption key".
Then, there's something you use to encrypt the data encryption key. Let's call this the "key encryption key" (abbreviated KEK from here on in).
When you use a TPM, the KEK is stored inside the TPM. When you use a TPM PIN, the TPM refuses to release the KEK for use by the OS unless that PIN is provided.
You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?". One could do that! But that's not how Bitlocker works. There is a reason it doesn't work that way: the TPM is supposed to let company admins in charge of the device access it even if the original PIN is forgotten, by using other policies letting them get at the KEK. I personally set my own devices up such that the passphrase IS part of the KEK itself.
Interestingly, LUKS does not have a composite key mode natively that lets you combine a password with TPM material, but there are some good reasons not to use JUST a password:
1. The strength of your disk encryption reduces to the strength of the password, where a TPM can have a 256-bit truly random key
2. If someone keylogs the password, or tricks you into disclosing it, they can later decrypt your drive from anywhere, where a TPM binds the attack to those with posession of the TPM
3. There is no protection against brute force attacks (rate limiting), where a TPM does - or tries to - impose a rate limit
Now, let's go on to what YellowKey attacks.
A TPM can have inside itself "registers", called PCRs. These PCRs can be updated but not reset - think of it like you can add numbers to them but not subtract, and they only go back to zero when you reboot.
Using a passwordless encrypted boot, the TPM is configured to only release the key when the PCRs are in the exact correct state. As the OS boots it adds numbers to those PCRs. If you boot "the wrong" software, the numbers in those registers won't match the expectations, and you cannot unlock the disk.
Speculation on my part: the reason there's an exploit here is that the Windows Recovery Environment apparently can match the PCR values for the booted OS, causing the TPM to release the key, but WinRE doesn't require you to get your password right before it gives you access to the data. So far as I know, protecting the TPM key with a PIN would mitigate this issue, but it's still bad.
Or maybe the exploit actually does something inside the TPM itself, causing it to unconditionally release the key even when protected by a PIN: that would be even worse, but **NOT*** a problem with Windows. That would be a problem with the TPM.
author could become famous by being the first to proove an actual backdoor in an OS disk encryption
I do not know bitlocker/TPMs a lot, do they also prevent this sort of thing ?
Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? It's open source and independently audited, so it really shouldn't be backdoored.
I've seen every variant of:
1) "this is an authentication/privilege escalation bug, not a bitlocker exploit" (? what are you even trying to say)
2) "even though the attacker explicitly warns that this is capable of bypassing TPM+PIN, that isn't actually true or what he meant"
3) "we shouldn't jump to conclusions that this is a backdoor"
4) "we already knew BitLocker with just TPM isn't secure" (? except many organizations depend on it to be)
2) Is it unreasonable to say "show it"?
3) Correct, we shouldn't jump to conclusions.
4) It's not known-insecure but it is known-enormous-attack-surface.
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
Just sign an alternate version of the recovery environment that doesn't bother displaying a login screen. Done - you can access any TPM-only Bitlocker setup freely. This is actually LESS risky than keeping the exploit in the publicly-available version of WinRE, because you don't have the risk of pesky security researchers finding your backdoor.
Hanlon's Razor and Occam's Razor both say this is probably a bug that lets you use some kind of early-boot filesystem-corruption-fixing code on the recovery image to break the login screen and leave the disk unlocked by accident. It deletes itself because it's, well, intended to be a filesystem fix log, and the log gets deleted when it's done being replayed so it doesn't happen a second time!
It's not semantics. A true bitlocker backdoor would let you in even if it's passworded.
And is it really downplaying? The ability to shove in a USB stick and get control over the drive is mostly equivalent to a bitlocker exploit when it comes to laptop theft. But for quick access to a desktop without bitlocker, and without the ability to open it and pull the drive, it's actually more damaging than a bitlocker exploit.
2) I am not personally being dismissive of the claim. I'm saying it's fine to hold off, and even if we assume the PIN version is real we shouldn't assume we know exactly what it looks like.
3) Saying it's not a backdoor distracts from the point? Can't agree with you there at all. The comments saying it's definitely a backdoor are the ones I point to as distracted.
4) Maybe it's downplaying but it's true. Replying on TPM-based bitlocker is a lot more dangerous than having a secure password. It's chosen because it's easier to enforce.
You just have to skip reading them because it seems there's no stopping those 100% genuine replies
For what it's worth, any OS using only hardware identity to unseal disk encryption is vulnerable to the same class of attack; there are all sorts of ways to misconfigure or exploit Linux FDE setups to enter a recovery shell as well. It's still a huge step above "no disk protection" (especially since it protects against every scenario where the disk is separated from the hardware), but the postboot surface area is enormous and nobody should be considering this class of protection as much more than a speed bump for a serious attacker.
Ideally you'd want that key to be further protected with a password or some other mechanism because it's not impossible to extract TPM keys.
You either need to enter a 128-bit entropy password on every boot (good luck with that) or you need to hold it on some external device, with some variant of USB / smartcard / NFC / Bluetooth to transmit it. NB. this is one of the cases where the usual "key for signing only, never leaves device, ephemeral DH and ZK protocols" like for SSH will not work on its own; you need the high-entropy key physically separate from the device.
The NSA realised this a while ago: https://en.wikipedia.org/wiki/KSD-64
Linux/LUKS etc. doesn't change any of this, by the way.
P.S. If Eclipse really has beef with Microsoft, he could always make an exploit that lets you set up a PC without making a Microsoft account.
That said, I think this is a thing with BitLocker? I remember coming across YubiKeys being able to do this via something called PIV (Personal Identity Verification). Found this guide now after giving it a quick search: https://gist.github.com/daemonhorn/03301a66da7d1f4de6cdc8c8b...
Not sure how sound of a design it is though, didn't dig into it much at all.
Yes, it's generally sound, and is the primary means of authentication and encryption used by the US military for classified systems.
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.
[1]: https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
