[bri3d]

I'm glad we were able to move past "We don't know how that mechanism works, it could just be a totally separate gate that IS bypassable" and into the actual way the mechanism works!

> 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.

[ranger_danger]

> the TPM has PolicyAuthValue(PIN)

Where are you seeing that? I can't find it in the article.

It wouldn't make sense to me for that to be the case if the article details how the driver does it own unwrapping/decryption after the KP is extracted. Plus it would probably mean they're lying about TPM+PIN being defeatable.

> The blog post documents dumping the PIN-entangled key material by MITM-ing the TPM communication while a user enters the PIN

I really don't think so... the screenshot with the PIN entry I think was only for hooking his debugger up in order to reverse the driver's decryption process. I don't see where they mention how/when the KP is actually extracted. It looks to me like it's transmitted during boot _before_ the PIN entry, so that the software driver can decrypt it after the user enters the PIN.

They list the steps as:

1. Extract TPM data. The TPM data is encrypted Key Protector (aka KP).

2. Generate the decryption key of KP

3. Decrypt KP

4. Extracting encrypted VMK

5. Decrypt VMK using KP

I didn't see anything about needing to enter a PIN in order to get the TPM data.

If the TPM required a PIN to extract anything, I think there would be no need to manually decrypt anything in software as they show with the python code.

Of course I could be wrong... please feel free to provide more info.

[bri3d]

> If the TPM required a PIN to extract anything, I think there would be no need to manually decrypt anything in software as they show with the python code.

Like I specifically pointed out, it's belt and suspenders.

> Of course I could be wrong... please feel free to provide more info.

From https://blog.scrt.ch/2024/10/28/privilege-escalation-through... :

> Indeed, by analysing the decryption process, it appears that the user’s PIN is sent to the TPM which releases the intermediate key only if the provided secret is correct, thus effectively preventing offline bruteforce attacks.

> Secondly, no data is returned when the PIN is incorrect, which indicates that the PIN or a derivative is sent to the TPM for verification.

[ranger_danger]

Interesting... I wonder why that wasn't mentioned in the previous article, and why an intermediate key is even necessary in the first place. Not sure what you mean by belt and suspenders by the way.

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

[bri3d]

> I wonder why that wasn't mentioned in the previous article, and why an intermediate key is even necessary in the first place. Not sure what you mean by belt and suspenders by the way.

Belt and suspenders = the industry standard term for "you have one protection you rely on, you add a second that should help." Stuff like ASLR, for example. Or in this case, the stretched key material. The belt is the TPM PIN anti-hammering, the suspenders are the key stretch / entanglement.

> 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

Trusting the word of exploit developers, especially random anime avatars on GitHub, is always a bad idea no matter the recent track record. Self promotion is very powerful in the security industry and every claim deserves independent research; that's at least half of the original point I was trying to make about conspiracy theories.

Personally, I suspect the exploit author had a disk with multiple enrollments in addition to the TPM + PIN one, and broke a parallel strategy.

[lupire]

It's not clear why I'd trust a company with decades of track record of being exploitable and a trillion dollar reputation to prop up over an anime avatar with a track record of finding exploits.