141–150 of 272 posts
>Currently, shim is signed with a Microsoft key from 2011 that expires on September 11. What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!" Does anyone know the rationale for such expiry?
Just out of curiosity, how good is the secure boot experience these days? I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
Earlier quoted context omitted.
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signator…
Another potential use is to facilitate managed deprecation of obsolete crypto functions / protocols / hash suites / etc.
That fits pretty well with a 10 year rotation period, and is probably more valuable in the long term than minimising DBX size.
Earlier quoted context omitted.
SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
Can you elaborate on that? Isn't it the whole point of secure boot? My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
Earlier quoted context omitted.
mind to elaborate? I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. the promise of secure boot and trusted computing is backdoor-free boot. what is in your eyes evil and garbage about that?
Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…
Which basically are exactly what "infosec fucktards" as you named them warned about.
Earlier quoted context omitted.
Can you elaborate on that? Isn't it the whole point of secure boot? My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.
I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature?
EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right?
[1]: https://learn.microsoft.com/en-us/windows/security/operating...
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
MS uses three separate CA's to sign Windows boot loaders, third party bootloaders (including Linux bootloaders) and UEFI Option ROMs.
In theory, no manufacturer has to install all three as trusted. But it makes no business sense to do so - why have two separate hardware SKUs for the sole purpose of lock-in? Once word got out no one would buy from that manufacturer.
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
If Linux users had "stepped up to the plate" and demanded their own separate PKI, nothing would be different, except that every system that shipped with Windows would be locked to Windows. Dual booting would not be a thing. I mean, your statement is self contradictory. Linux users demanded no signing etc. So, had the industry listened to Linux users, there would be no signing. We do not live in that universe. There a…
Microsoft uses separate CAs (read: separate root certificates) to sign Windows vs Linux bootloaders.
Both CAs have to be trusted. They could also, in theory, be revoked separately.
There is no reason the "third party" CA couldn't be run by Red Hat. It's done by MS out of convenience.
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
> Now had the Linux folks stepped up to the plate early on, instead of childishly acting This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
Linux has 63% of the server marketshare, which is where Secure Boot and the whole chain-of-trust has utmost importance. Of course they have leverage.
Do you think overall Secure Boot is more important in the context of securing your bank's servers, or some porno jack machine throwaway laptop?