421–430 of 514 posts
Earlier quoted context omitted.
I was confused about this because last time I used LibreOffice it wasn't that bad. Turns out, it's really just a normal UI? I guess the biggest difference is it doesn't conform to Microsoft's design but to call it a time capsule is a bit dramatic.
I think by default after fresh install it suggests the "old" layout akin to Office 2000, but you can just select "tabbed ribbon" and then it really isn't half bad.
I agree with all of the articles points except for the first one: TPM and Secure Boot do not reduce user choice or promote state or corporate surveillance. If you want to be able to prevent root kits you need secure boot, and if you want to store secrets that don't need a user password to unlock and can't be stolen by taking apart the computer, you need a TPM; or you need substantially similar alternatives. I would s…
Thing is, because the whole design is closed as well as firmware, the security of it is near zero, even for sealing firmware device images (e.g. option ROM), much less bootloaders. Multiple security holes have been found. There's no issue booting a boot rootkit with the standard Windows bootloader unless you manually seal the image with command line or group policy, and even then it's possible to bypass by installing…
This. It is secure only for MS, AMD or Intel.
Earlier quoted context omitted.
If evil maid attack, and you see this prompt, you a) re-enable secure boot, if did not work b) throw away the device. In any case data stays secure. Edit: Hmm, you have a point, how do I know secure boot was disabled in the first place? Anyway, still works for servers and unattended reboots.
No, GP is misinterpreting Windows's message. It prompts for a recovery key because the TPM is bound to, among other things, Secure Boot == enabled. When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device. The fact that Windows is compromised does not make it capable of extracting secrets from the TPM, though maybe a naïve…
But the attacker isn't trying to get the key from the TPM right now, they're trying to get the credentials from the user. It's the same thing that happens with full disk encryption and no TPM. They can't read what's on the device without the secret but they can alter it.
So they alter it to boot a compromised Windows install -- not the original one -- and prompt for your credentials, which they then capture and use to unlock the original install.
They don't need secure boot to be turned on in order to do that, the original Windows install is never booted with it turned off and they can turn it back on later after they've captured your password. Or even leave it turned on but have it boot the second, compromised Windows install to capture your credentials with secure boot enabled.
How suspicious are you going to be if you enter your credentials and the next thing that happens is that Windows reboots "for updates" (into the original install instead of the compromised one)?
Earlier quoted context omitted.
> There is also a real potential for abusing TPMs or cryptographic co-processors to enforce remote attestation. People here REALLY need to start understanding this issue. Remote Attestation is the kind of tech that if abused will end free computing over night.
And it's already happening in the form of Google play integrity API. Many apps already require it. It's just a matter of time before they push similar tech to the desktop. And on mobile it hurts more because many banks now require a mobile app for 2FA. Personally I think any form of attestation is evil.
Linux isn't going to be any more secure than Windows was if everyone switches to it.
Another "everyone will migrate in droves to Linux" article that keeps poping up a Windows version ends, since Windows XP days, yet even Valve was forced to translate Win32 APIs to actually have games for the Steam Deck, after how Steam Machines went down. General public won't care until they can buy laptops with GNU/Linux on their favourite shopping mall PC store. As it stands today they are more likely to buy an iPa…
Yeh, and it works great. Your point?
The Steam Deck hardware itself can run the original 32-bit libraries if your distro supports it, Valve wasn't "forced" to do anything. They chose WoW64 because it's the mature and functional solution.
I know this isn't Stackoverflow, but... Does anyone have a good mental model for disentangling the issues of full-disk encryption versus secure-boot? I've been badly procrastinating with my desktop's new SSD because of it. Use-case is: * Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive. * I don't need unattended boot at all, I'd rather enter a passphrase every time. *…
You can turn the secure boot on/off at any time. The only effect from this is the loss of encryption keys that you might have bound to the measured values. So for it to be effective against the evil maid, you really need to bind the LUKS key to it. But you can do that _and_ set a strong PIN for your LUKS key.
1. Your data on the drive/partition is encrypted by $BIGKEY, which basically never changes because that would require redoing everything.
2. The LUKS header stores one-or-more encrypted versions of $BIGKEY, generally encrypted using a more convenient $SMALLKEY that a human could memorize. Optionally, $PIN can also be part of the encryption step.
3. Unlike $BIGKEY, the $SMALLKEY and/or $PIN can be changed over time. This changes the ciphertext of $BIGKEY and rewrites the LUKS header.
4. Optionally, secure boot is capable of storing and retrieving $SMALLKEY into system chips in such a way that most tampering ought to destroy $SMALLKEY.
> So for [Secure Boot] to be effective against the evil maid, you really need to bind the LUKS key to it.
If my $SMALLKEY is not stored inside the secure-boot chips, I can see how that would be inconvenient, but I'm not sure how that is safer.
Is it because the route $SMALLKEY automatically travels bypasses tricks like a hardware keylogger?
Even if I didn't give a shit about the privacy stuff, I would like to just reiterate something I said a few days ago. My mom got an automatic update to Windows 11, and it bricked her computer. It wouldn't boot; it would spin and then say it needed to go into repair mode, and then doing repair mode didn't do anything. My initial thought was that the disk was hosed, but of course my parents had a bunch of priceless doc…
There was a live USB version of windows; Windows to Go. Microsoft stopped supporting it about 6 years ago for some reason.
It's my own opinion that windows enforcement of TPM while retiring Windows 10 is a rough direction, but I also get the executive decision. Support for old software is costly, and Windows 10 is very old at this point. Add that to how many security issues Microsoft has been having, and this seems like the only sensible decision.
Earlier quoted context omitted.
Normally I would agree that security measures are needed in many, but not all cases, but only if they are in complete control of the user and cannot by altered by any one organization. For-profit companies cannot be in control of these mechanisms. We have seen how they can be abused with the latest decision by Google to limit side-loading to people who identify themselves. So your take is really a misdirection from h…
> For-profit companies cannot be in control of these mechanisms. But they are not in control of Secure Boot. Microsoft runs a root CA that is pre-installed on most PCs. It could have been Verisign or someone else, but MS made sense at the time, likely because they had additional code signing expertise. You are free to delete these keys and/or install your own. If there wasn't preexisting infrastructure, Secure Boot w…