91–100 of 280 posts
Earlier quoted context omitted.
That's called LUKS2 and it's the default on Linux. You just type passphrase on boot. It's not tied to the motherboard.
What if you forget the passphrase after not using it for many years and you suddenly need a file on the drive?
I just digged into the exploit a little bit more and what it does it targets BitLocker in TPM only mode. That means that there is no preboot authentication or anything. What happens is secure boot validates the boot chain and the TPM gives out the encryption keys by itself. When you have physical access, it doesn't really make a difference. If there is a stick you can boot from and drop into an emergency shell or if…
>If there is a stick you can boot from and drop into an emergency shell This won't work because the TPM will only give you the keys if you're booting an "approved" OS, specifically the PCR states that the encryption keys are bound to. >or if you have to buy a $5 microcontroller and solder it to certain pins on the main board to sniff the TPM keys. That only works with dTPMs. fTPMs aren't vulnerable to this, and are f…
From: https://infosec.exchange/@wdormann/116565129854382214 >In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it >However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But t…
The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.
> Security professionals generally recommend avoiding reliance on any single encryption system and instead evaluating well-reviewed full-disk encryption alternatives such as VeraCrypt. What does this even mean? Nobody is using multiple encryption schemes on top of each other, are they?
If you want to encrypt some data that gets stored persistently somewhere on your machine, rather than invent an application-specific encryption scheme for that data alone, instead use a mainstream full-partition encryption mechanism, then store the data as plaintext within said partition.
Earlier quoted context omitted.
Presumably, not paying out for these bugs which often take weeks of research to find.
Who in their right mind bets on bug bounties to cover their basic needs? They should be highly employable with these kind of skills.
Earlier quoted context omitted.
Ubuntu also released TPM based FDE a few versions ago. I had these thoughts then and decided against using it. Typing my passphrase on boot is muscle memory and gives me simple security I can trust. Also can recover data without my mainboard. Maybe a hybrid (secureboot-TPM+phrase) slot for day to day to also prevent against evil maid attacks, and another slot with a backup passphrase would be acceptable.
>Typing my passphrase on boot is muscle memory and gives me simple security I can trust. It's not an either-or. You can combine TPM with passwords which makes it far more secure than password alone. A TPM can enforce password guessing limits, otherwise a password needs to be absurdly long to be secure against GPU bruteforcing attacks. It also prevents someone from swapping out the bootloader with a backdoored version…
This doesn't surprise me at all. Microsoft is a Chinese company and Chinese companies have to work with the government on such matters. Oh sorry, I meant an US company, whatever..
Earlier quoted context omitted.
I'm not aware of the connection between truecrypt and bitlocker, want to enlighten us?
Long time ago TrueCrypt suddenly and abruptly shut down with a vague goodbye message saying "everyone please move on and use bitlocker instead" Prevailing theory is they were pressured to put in a backdoor and couldn't disclose it, so they had to make a seemingly ridiculous statement (because who in their right mind would trust bitlocker) to call attention that "something is very wrong"
Alternately, they don't want people to rely on abandonware for security.
Also, despite the conspiracy theories of backdoors I'm not aware of any bitlocker exploits that work on TPM + pin, which is the intended "secure" configuration[1]. All exploits rely on TPM-only (ie. ez-mode), which is basically the security equivalent of running https/ssh without certificates and blindly accepting whatever keys shows up.
[1] https://learn.microsoft.com/en-us/windows/security/operating...