I didn’t find it too difficult to set up TPM backed encryption on Arch using systemd-cryptenroll for my home server, although for anything I use interactively I just use a passphrase instead.

- The feds show up

- A bugular breaks in and grabs your computer

- You're selling your house and host an open house

- You have curious children and want to keep them from live booting and reading your tax returns

That is not what happens. There is nothing wrong with decrypting the drive. If you just powered on the computer normally, it will "trigger the decryption." There just isn't way to read a file from the lock screen. This exploit is getting you to a state where the drive is unlocked but the user has access to a command prompt. A command prompt, unlike a basic login screen gives the user the ability to actually see the contents of arbitrary files.

>specific file name

It's a specific file name because Windows stores transaction logs under that name. If it was a random name it wouldn't be able to exercise this vulnerable code.

>also removing said files after this is achieved

It doesn't seem farfetched for a transaction log to be deleted after it is successfully replayed.

Does this exploit have external media having anything to do with the encryption process? If yes, how do we know that? Remember that the OS normally unlocks the drive on boot, when no exploits are happening.

> Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.

It's files in System Volume Information describing a transaction or something. It makes sense for it to resolve that transaction when mounting the external drive, and to then delete the files. And that's if it's even windows itself triggering the deletion.

Also, I'd argue the stolen bag scenario usually features dilletante attackers.

But Windows for personal private use? No.

(I'm aware that there's going to be a significant gap between the theory and what happens in practice though)

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.

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.

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.

> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.

If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.

That's the thing, we don't actually know how involved the PIN is in relation to the key... it might be completely separate (and hence bypassable).

Similarly I also wonder if password-based pre-boot auth is affected.

Do you know how hard discovering even one of those is? And how many months of work it takes?

A USB stick containing a masterkey to decrypt a bitlocker volume is literally the definition of a backdoor.

Go on, try it out. It works.

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

> The article shows that the PIN-entangled key material can still be downloaded directly from the TPM.

Not exactly, the TPM has PolicyAuthValue(PIN), so the PIN also needs to be provided to the TPM to unseal the material, and the hardware anti-hammering should prevent brute forcing it this way. The blog post documents dumping the PIN-entangled key material by MITM-ing the TPM communication while a user enters the PIN; the entanglement is a belt-and-suspenders approach.

No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM.

> I don't think Bitlocker does that

It does, which is why cryptsetup was much more affected by the faulTPM exploit: https://arxiv.org/abs/2304.14717

> Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too.

Not only do they do the same thing, they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.

https://post-cyberlabs.github.io/Offensive-security-publicat...

Yes, the PIN is entangled with the key material. The admin PIN recovery techniques all involve enrolling additional unlocking methods.

Besides this, I completely agree with this post, especially:

> I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.

I've always found it silly that Microsoft's default BitLocker implementation doesn't make it easy to do the obvious thing that FileVault does and use the user's password as an additional wrapper to encrypt the KEK. Yes, then there's trouble when the user forgets their password and password-change rotation is a little annoying, but if you're in an enterprise scenario you need backup keys anyway, and your users are still as likely to get BitLocker'd by PCRs changing (ie due to EFI updates) than forgetting a password anyway.

Agreed that the default Bitlocker config is much less secure than having a PIN at boot time due to the amount of code that gets run.

I think they're attacks on Windows' measured boot approach.

Now I have to wonder if the exploit author's definition of "it works with a PIN" is simply "it works if you enter the correct PIN" and just somehow left out that important detail... I don't know. Perhaps everyone is just guessing that they meant it's possible to exploit without knowing the PIN at all.

I suppose they could be lying too, but I would hope they would be smarter than that given their apparently successful track record /shrug