To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.
You dare question a monopoly corporation and the spymasters of this country??
Oh anyone who doesn’t trust Microsoft with their life is a complete idiot. And the NSA only illegally spied on everyone until Bush the II made it legal! So of course we should unquestioningly follow their configuration guides. I mean - haha - we don’t wanna get disappeared! Haha ha. Not. Not that that’s ever happened. That we know of. For sure. Probably.
The first is to break into any computer or communications stream that they feel the need to for “national security needs”. A lot of leeway for bad behavior there, and yes, they’ve done, and almost certainly continue to do, bad things. Note that in theory that is only allowed for foreign targets, but they always seem to find ways around that.
The second, and less well known, job is to ensure that nobody but them can do that to US computers and communications streams. So if they say something will make your computer more secure, it’s probably true, with the important addition of “except from them”.
I won’t pretend I like any of this, but most people are much more likely to be targeted by scammers, bitcoin miners, and ransomware than they are by the NSA itself, so in that sense, following the NSA’s recommendation here is probably better than not.
Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.
The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.
And it’s not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.
To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.
The kernel modules usually are signed with a different key. That key is created at build time and its private key is discarded after the build (and after the modules have been signed) and the kernel uses the public key to validate the modules IIRC. That is how Archlinux enables can somewhat support Secure Boot without the user needing to sign every kernel module or firmware file (it is also the reason why all the kernel packages aren’t reproducible).
And technically you can whitelist other certificates, too, but I have no idea how you might do that.
When you enter the UEFI somewhere there will be a Secure Boot section, there there is usually a way to either disable Secure Boot or to change it into “Setup Mode”. This “Setup Mode” allows enrolling new keys, I don’t know of any programs on Windows that can do it, but sbctl can do it and the systemd-boot bootloader both can enroll your own custom keys.
Secure Boot is a broken concept by design.
You dare question a monopoly corporation and the spymasters of this country??
(/s)
Yes, surely randoms on Lemmy know better than Microsoft and the NSA in regards to security.
Oh anyone who doesn’t trust Microsoft with their life is a complete idiot. And the NSA only illegally spied on everyone until Bush the II made it legal! So of course we should unquestioningly follow their configuration guides. I mean - haha - we don’t wanna get disappeared! Haha ha. Not. Not that that’s ever happened. That we know of. For sure. Probably.
in regards to security
in regards to security
in regards to security
Just wanted to make sure you saw it this time because you went off on a tangent there.
It doesn’t matter if they know about security (which they do). A burglar could know about locks and home security systems, would you take his advice?
Their positions on security of others is dismissed on grounds of trust not of competence.
Literally, yes. There was even a TV show about it.
The NSA has two jobs.
The first is to break into any computer or communications stream that they feel the need to for “national security needs”. A lot of leeway for bad behavior there, and yes, they’ve done, and almost certainly continue to do, bad things. Note that in theory that is only allowed for foreign targets, but they always seem to find ways around that.
The second, and less well known, job is to ensure that nobody but them can do that to US computers and communications streams. So if they say something will make your computer more secure, it’s probably true, with the important addition of “except from them”.
I won’t pretend I like any of this, but most people are much more likely to be targeted by scammers, bitcoin miners, and ransomware than they are by the NSA itself, so in that sense, following the NSA’s recommendation here is probably better than not.
Hey what is that, some kinda tangent
Can you explain more (don’t doubt you)
Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.
The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.
And it’s not necessarily proven that it can do what it claims to do, either. In fact, it might be a quixotic and ultimately impossible task to try and prevent boot attacks from UEFI.
But OP might have other reasons in mind, I dunno.
To use secure boot correctly, you need disable or delete the keys that come preinstalled and add your own keys. Then you have to sign the kernel and any drivers yourself. It is possible to automate the signing the kernel and kernel modules though. Just make sure the private key is kept secure. If someone else gets a hold of it, they can create code that your computer will trust.
The kernel modules usually are signed with a different key. That key is created at build time and its private key is discarded after the build (and after the modules have been signed) and the kernel uses the public key to validate the modules IIRC. That is how Archlinux enables can somewhat support Secure Boot without the user needing to sign every kernel module or firmware file (it is also the reason why all the kernel packages aren’t reproducible).
When you enter the UEFI somewhere there will be a Secure Boot section, there there is usually a way to either disable Secure Boot or to change it into “Setup Mode”. This “Setup Mode” allows enrolling new keys, I don’t know of any programs on Windows that can do it, but
sbctlcan do it and thesystemd-bootbootloader both can enroll your own custom keys.