Post B6Tiw3hjT4NH3cjze4 by kuketzblog@social.tchncs.de
 (DIR) More posts by kuketzblog@social.tchncs.de
 (DIR) Post #B6Tiw3LkmmnFxSSRO4 by syt@social.heise.de
       0 likes, 0 repeats
       
       Can someone explain #yellowkey to me? I must be missing something. AFAIK it requires physical access to the target system, which must use the TPM-only variant of Bitlocker¹. So how is it a Bitlocker bypass? I understand it bypasses Windows’ log-in screen and maybe the TPM (which probably shouldn’t pony up the key in such a setting?) but how is Bitlocker failing?¹I know the vague hint by the developer, that the issue also affects Bitlocker with a PIN, but there’re no details yet, are there?
       
 (DIR) Post #B6Tiw3hjT4NH3cjze4 by kuketzblog@social.tchncs.de
       0 likes, 0 repeats
       
       @syt YellowKey doesn’t seem to break BitLocker’s crypto. It breaks the protection promise of TPM-only BitLocker: physical access to a BitLocker-protected device should not expose plaintext data without a recovery key, BitLocker PIN or Windows credentials. In TPM-only mode the machine itself is effectively the credential. YellowKey abuses WinRE after auto-unlock and gives a shell with access to the unlocked volume. That’s why calling it a BitLocker bypass is fair, but it’s a design/recovery-path bypass, not »AES is broken«. For TPM+PIN there’s only the author’s claim so far; no public details/PoC./kuk
       
 (DIR) Post #B6TknjW0qWTc2APu6K by syt@social.heise.de
       0 likes, 0 repeats
       
       @kuketzblog Thanks for the explanation! But that’s an extraordinary promise, isn’t it? I mean, one can just boot the device and it has to unlock the Bitlocker volume. I wouldn’t trust the Login-Screen to be an insurmountable barrier at all, even more so with physical access to the device. (And technically, just showing the account names is already exposing BitLocker-protected plaintext data, no?)
       
 (DIR) Post #B6TlOrtKfOwEj7222y by kuketzblog@social.tchncs.de
       0 likes, 0 repeats
       
       @syt If I understand this correctly, I don’t think that promise is extraordinary. It’s basically the point of full-disk encryption on a lost/stolen device.TPM-only weakens that by letting the machine unlock itself if the boot path looks trusted. Fine, that’s the trade-off.But then the trusted recovery path must not hand an attacker a shell on the already-unlocked volume. That’s the failure./kuk
       
 (DIR) Post #B6Tr6fslB4T3zdTJdQ by syt@social.heise.de
       0 likes, 0 repeats
       
       @kuketzblog Hm, I’d say TPM-only cancels the lost/stolen device scenario. It’s still useful, e.g. when you want to replace and sell/discard the disks. But IMHO FDE is a barrier until it’s unlocked; after unlock, bets are off. (There’s a reason for the move to file-based encryption.) If you use an auto-unlock feature, FDE is not a barrier, while that feature is available (i.e. the disk is with the TPM). I still don’t get the hubbub. But thanks again for the explanation ❤️