Every single time when this concern is being raise, people get called "conspiracy theorist" and get "flagged" or muted, aka censored
Fast forward today, yall are getting fucked deep in the ass
Fuck Microsoft
Linux and Secure Boot certificate expiration
171–180 of 272 posts
Re: Linux and Secure Boot certificate expiration
#172Earlier quoted context omitted.
Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys. Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your l…
> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself? Would the solution be that the GPU…
You don't need to be able to build them. Just sign them or sign the keys that sign the third party blobs/binaries.
Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.
What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.
Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.
With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.
Re: Linux and Secure Boot certificate expiration
#173Earlier quoted context omitted.
Secure Boot is almost never a choice. It's just something a hardware vendor hits you with, whether you like it or not.
It’s a choice I make all the time. I disabled it on one of my computers just last night. I’ll probably turn it back on today. It’s easy to toggle.
Now do that on your smartphone. And then on your smart watch. And then on your gaming console.
Secure Boot being "a choice" on PC is an exception, not the norm. On just about every other device, the vendor is going to take a boot, shove it up your ass, and say "it's there to make your ass more secure" if you complain.
Re: Linux and Secure Boot certificate expiration
#174And this is why I avoid and will always avoid "Secure Boot". I can see many newer Linux people being locked out starting in Sept.
There should be some “Sane Usage” certification that a device doesn’t do secure boot, provides fully open and self-maintainable hardware, is independent of all external entities for ongoing use, provides hardware switches to turn off built-ins like ports, mics, and cameras, for power-savings and security.
Re: Linux and Secure Boot certificate expiration
#175This is yet another why I do not encrypt.
Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.
There's some link between secure boot and encryption.
If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.
Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.
Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
Re: Linux and Secure Boot certificate expiration
#176Re: Linux and Secure Boot certificate expiration
#177Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
Re: Linux and Secure Boot certificate expiration
#178Earlier quoted context omitted.
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementi…
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs. Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS? This stuff seems inches away from a supply chain attack.
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2...
It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
Re: Linux and Secure Boot certificate expiration
#179Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol!
It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
Re: Linux and Secure Boot certificate expiration
#180Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.