Excellent.
... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s
Here you go — now you have. Thank ${DEITY} for exploits!
https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot
https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
For that, any SSDs/HDDs included in the computer should be non-bootable and fully-encrypted.
Then the BIOS will happily run whatever an intruder will attempt to run, but nonetheless the intruder will not have any access, neither for reading nor for writing, to the data hosted by the computer.
The owner can boot from a removable USB memory, used as a computer key, whose content cannot be modified by someone else as long as the owner keeps it.
All Intel/AMD CPUs have backdoors in the form of the System Management Mode and of various hardware management engines, which can be exploited by a malicious BIOS or UEFI firmware to monitor what the operating system that is controlled by the user does, but SecureBoot also offers no protection against such backdoors. ARM CPUs are no better, because many of them have copied Intel, so they have the equivalent of the SMM: EL3.
If you run yourself a hostile application after booting, then SecureBoot also does not offer any protection against that.
Mmm....no.
I use my own keys and removed vendors keys from my secureboot setup. Hard disk is encrypted and automatically pulls keys from the TPM to boot into a guest OS, which is running something akin to prey. If the hard drive is removed, it can't be read or examined, and you can't replace the HDD with a different OS to get it to boot.
How would you recreate that setup with just a BIOS?
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
I see Microsoft's malicious erosion of the meaning of "genuine" is going well.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.
It's not forced. You can disable secure boot and all that in BIOS.
If this really were all only for enterprise users things like https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkh... wouldn't be an issue but that isn't reality.
Of course online multiplayer games are gonna have more stringent device security requirements to try to deter cheaters on the PC platforms. Companies aren't gonna mass produce new HW and SW customized to your own individual desires just because you want something else than the masses of consumers don't care about.
Vote with your wallet if TPM bothers you. Otherwise I don't see what your argument stands on.
I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.
Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using something bruteforceable.
Cryptography should be enough to protect you from brute force, if you care about such things. I don't think it would be controversial to say that it's much more likely your particular secure enclave is broken than your encryption scheme (assuming you choose something appropriate and you're not on the NSA's radar).
People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.
How does secure boot help with that? Those kind of users aren't going to be pulling the CMOS battery to reset the BIOS password.
Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected.
Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.
Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.
You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.
Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.
This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.
Ordinary disk encryption would protect me too here, wouldn't it?
https://security.stackexchange.com/questions/267222/full-dis...
So, there are two scenarios here.
First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.
Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.
As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.
And yes, getting back to the original topic, I believe that against petty criminals, even a full disk encryption is plenty defense. They won't go about installing anything to the EFI partition just to get to the data.
This Coreboot + Heads setup I'd trust to protect against even the more involved.
That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.
Coreboot supports secure boot, so why isn't that sufficient?
Secure boot requires that the bootloader match a hash derived from a TPM-stored key.
Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it.
A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot.
Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card.
For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.
It does nothing to prevent overwriting the kernel image.
Now if you ask, how is secure boot stopping an attacker from overwriting libc or some other important system library? the answer is nothing is stopping it on Linux, but on ChromeOS, MacOS, Windows and the two mobile OSes, the secure-boot machinery has been guarding against that for years.
This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader somehow ...
LOLOL lemme stop ya right there chief. I'm screwed anyway? This is ridiculous.
UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.
https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...
db48x•1d ago
Sheer incompetence, in other words.
candiddevmike•1d ago
ahepp•1d ago
It seems like the immediate problem here is that most people will never enroll their own keys, and if every vendor's crappy EFI binary gets signed by Microsoft, there will be a huge library of garbage vendor code which is all an attack surface.
AnthonyMouse•1d ago
Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on.
That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised.
The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
gruez•1d ago
What if you need to update the bootloader?
>The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.
AnthonyMouse•1d ago
Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash.
> TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader.
If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.
mjg59•1d ago
All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.
AnthonyMouse•16h ago
However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's own update servers. Maybe it just boots an OS that allows the operator to apply any update they want from a USB stick, but only after authenticating with the OS.
None of that is the firmware's problem, all it has to do is disallow modifications to itself unless the owner has entered the firmware password or the system is booted from the owner-designated trusted bootloader.
> All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.
The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.
mjg59•10h ago
> The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.
TPMs have private keys, and are not involved in enforcing secure boot. The firmware validating the signatures only has public keys.
AnthonyMouse•1m ago
Isn't that kind of pointless?
Suppose the attacker gets root on your OS, i.e. what they would need to supply the firmware with a new hash. That OS install is now compromised, because they can now change whatever else they want in the filesystem. If you boot the same OS again, even using the trusted bootloader, it's still compromised.
If you don't realize that it's compromised, you're now using a compromised system regardless of the bootloader. If you do realize it's compromised then you do a clean reinstall of the OS and designate your bootloader as the trusted one again instead of whatever the compromised OS installed.
What does the bootloader really get them that root didn't already?
> The firmware validating the signatures only has public keys.
Having the keys installed from the factory still seems like the thing causing the problem:
If it only trusts e.g. Microsoft's public key, they now get to decide if they want to sign something you might want to use. If they don't, secure boot prevents it from working, which causes problems for you if you want it to work.
Which then puts them under pressure to sign all kinds of things because people want their firmware updaters etc. to work, and then you get compromised by some code they signed which wasn't even relevant to you.
Whereas what you want is some way of designating what can run on your machine, regardless of what someone else would like to run on theirs. But then that's a machine-specific determination rather than something somebody should be deciding globally for everyone.
mschuster91•1d ago
For your own personal machine, sure. But say you're a sysadmin in a company that has thousands of units. Suddenly, a CA infrastructure is much more appealing than having to deal with component hashes.
AnthonyMouse•1d ago
Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys also wouldn't be trusting random third party code either.
mschuster91•1d ago
With your private CA you can skip the "update the hash" part, removing a crucial step that one might forget in a hurry or that simply might go wrong because of whatever sort of bug or power outage... and brick thousands of machines as a result.
AnthonyMouse•16h ago
mjg59•1d ago
AnthonyMouse•16h ago
OjotCewIo•1d ago
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
gmueckl•1d ago
EPWN3D•1d ago
db48x•1d ago
Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
bradfa•1d ago
Most small customers have no choice but to buy a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
wmf•1d ago
bradfa•23h ago
Now, Intel platforms you maybe have a shot at using EDK2 on, especially those with FSP. But Intel is unlikely to give you any support when something goes wrong and there’s probably no way to pay Intel to change that unless you’re a very big customer.
bcantrill•15h ago
[0] https://github.com/openSIL/openSIL
[1] https://github.com/oxidecomputer/illumos-gate
[2] https://rfd.shared.oxide.computer/rfd/0552
neilv•1d ago
I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is...
Speculation:
* Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer who knows enough hardware.
* Hardware companies know hardware, and might have hardware engineers as execs and managers, so they probably know how to hire hardware engineers, but maybe not software engineers.
* Hardware companies respect hardware engineers, and not so much software people. You don't need all those hard math and engineering classes to be a "coder". Even their 12yo can make an app, but you usually need a team with a ton of hardware education and experience to produce a viable board or IC. ("Coding" even sounds like a tedious but straightforward clerical task.)
Other speculation, or does anyone know?
db48x•1d ago
privatelypublic•1d ago
Same person thinks I'm literally paranoid for splitting home, IoT, and Security cameras into separate networks... despite the cameras and dvr being the banned/recalled costco ones.
nikanj•1d ago
worthless-trash•1d ago
privatelypublic•17h ago
worthless-trash•4m ago
https://nvd.nist.gov/vuln/detail/cve-2018-6242
and
https://github.com/erdzan12/switch-fusee
miki123211•23h ago
Better software doesn't sell more hardware. From those companies' point of view, what matters is hardware features to make consumers want the product, and manufacturing efficiency to make margins high. The quality of what's in the ROM is no more important than the quality of the fans, servos, DACs or what have you. As long as the parts don't break too often and are within specifications, they're good enough, no point in wasting money to make them better.
This, of course, is true until it isn't. At some point, somebody comes along who disrupts the space completely by making the software great and well integrated (or just by making it do what people have previously had to do in hardware), and traditional companies don't know how to cope.
neilv•14h ago
scraptor•1d ago
coderatlarge•1d ago
i would argue every apple macbook purchase implicitly includes this.
db48x•1d ago
FirmwareBurner•1d ago
The former decision is made by engineers, the latter by bean counters.
eviks•1d ago
quotemstr•22h ago
Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf
Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.
getcrunk•1d ago