> presumably
replyThat'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.
That is known pretty well: The TPM won't release the the volume key unless the correct PIN is presented to the TPM.
replyThe only evidence I have seen was this article that another user in the thread shared:
replyhttps://blog.scrt.ch/2024/10/28/privilege-escalation-through...
Not saying you're wrong, I'm just not sure how well known it really is.
Either way... if the TPM is the one gating the key behind a PIN, I really don't see how an OS-level exploit can work without knowing the PIN in advance.
If someone drops 5 confirmed ring 0 exploits/bypasses within 3 months and claims that they got a 6th one... why on earth would you doubt that the 6th one suddenly is fake?
replyDo you know how hard discovering even one of those is? And how many months of work it takes?
this claim is in another galaxy, not your average 0-day
replyOne possibility is that in their test, TPM+Pin was added as an additional Key Protector, rather than replacing the TPM Key Protector
replyWe're talking about a company with a security culture where opening a text file in notepad.exe can lead to an RCE.
replyAssuming reasonable implementation standards at this point is the irrational assumption, not the rational one.
deleted
reply