There was a post here yesterday (https://news.ycombinator.com/item?id=23149771) about the (in)security of Linux, but the primary purpose of an OS is utility, not merely security. The leadership of the Linux project made very smart analyses of what priorities come first. Despite there being billions of insecure old devices scattered about, running old kernels, I think the kernel authors made the right call.
The problem rests with the manufacturers who abandoned support for those devices and left no escape route for users to update the kernels themselves. Most disgusting are these phone and car manufacturers, and apps, which have enabled wholesale spying on users for many years now. These devices are literal bugs, reporting realtime locations, conversations, and who knows what else to Big Brother.
Its a pleasure to see that some people still care enough to make the world a better place, in a way I can understand.
There must have been some groundswell movement amongst users all demanding that the boot process be made more "secure". There must have been well-publicised cases where "bad guys" were hijacking the boot process.
Perhaps different people have different definitions of "secure". If some third party, including the seller, has control over access to the computer or what I can run or disable on it after I purchase it, then I do not consider that computer to be more "secure". I just consider it to be less useful and less trustworthy to use with any personal data.
There wasn't. Users want security in general but most people would not even realize it if a boot process was insecure nor would they understand the implications.
> There must have been well-publicised cases where "bad guys" were hijacking the boot process.
Yes. The "bad" guys are the people running "unauthorized" software on computer hardware. Governments and corporations would very much like to restrict what users can and can't do. Widespread cryptography is viewed as an existential threat to law enforcement and intelligence gathering. Companies enjoy owning their users and being in a monopoly position with regards to the software market for their devices. So we get systems which control the user instead of systems controlled by the user.
It's less binary than that for me. Yes, the same technologies that keep my data secure also act as a buttress against jailbreaking. But people who want to jailbreak can simply choose less-secure devices, while I would personally not trade that security for greater hackability. There are other, lower-risk devices than phones and cars that I can use for that.
I think we know the answer, and that is; the attitude towards things like mobile phones being different to that of a laptop; we don't really "own" or phones in the same sense and if shouldn't be that way.
The point of the OP is that users can and deserve to have the reliability that cryptographically-secure boot systems provide, without the Big Brother backdoor.
I currently have a custom platform key, packet everything I need for booting into a single image (signed with the custom platform key) and everything else is in a fully encrypted partition (lvm2 on dmcrypt). "Decryption key" is inserted via keyboard on boot, which is not to everyone's liking but is what I want.
It's not really hard to setup (on arch Linux) and works like a charm. ;-)
Through the drawback is that the initRamFs is only protected by the signature/secure boot but not encrypted and combining it with some other boot related setup can be less straight forward then under a "boring" setup.
I.e. some of the thinks this project promises are already possible now, just not streamlined. Which is why it's nice to have such a project.
Regarding /boot being in the clear -- the initramfs and kernel shouldn't contain any secrets, so having them unencrypted isn't a big drawback. Signed is much more important so that an adversary with write access to the disk can't swap out the kernel.
One advantage to using the TPM for unsealing the disk encryption key is that it helps protect against attacks that re-write the firmware. If an adversary can reflash the platform key (via either a local SPI flash programmer or some code execution that gives them write access to the NVRAM region of the flash), then you can't tell that the PK has been changed and that the kernel to which you are inputting the password is no longer trustworthy. Since the secret is sealed with (among other things) the hash of the UEFI SecureBoot configuration, the TPM will not unseal it if the PK, KEK or db are changed.
If you want to take it to another level, TPM TOTP can be used to validate that the password dialog is even valid before you type in the password. I think we can integrate that fairly easily into the initramfs for the next version of safeboot.
I'm wondering about this assumption. Hasn't the ME previously been shown to be fairly straightforward to exploit?
- Copy GRUB, bootlines for your system, your kernel and initrd to a WORM media like a bootable CD-ROM.
- Boot using CD-ROM.
- When boot completes, remove the CD-ROM.
Now you can't attack my boot kernel or boot process because I've just physically separated it from the system and taken it with me. Even if it was there, the media is read only so you can't modify it.
If I need to upgrade, I need to burn a new CD. CDs are cheap.
Using actual CDs would be impractical for many users, but a parallel could be implemented on a system with micro-SD card readers supporting removeable media and a physical read/write or connection switch. Which, if we're talking about physical switches for camera and mic, why not boot files?
This implies that you have set your boot order to CD-ROM first, so anyone can - say - boot their own system on your machine from CD and either access your data or make a dd-copy of your disk and look at it later.
You need also to password protect your BIOS so that first device in boot order is hard disk and settings cannot be changed (without BIOS password).
Depending on the BIOS this change in booting order could be possible at boot time (providing the password) or a reboot would be needed.
You also have to make sure your BIOS can't be reset by removing the battery, doesn't have some administrative bypass or even a reset jumper. I've even seen a BIOS that reset to default boot settings when you remove all disks - and then gleefully boots from any attached USB disk.
Even a “read only” CD-ROM if not verified on boot for tampering — might contain an attack, including: to just disable the disk from booting, among other things.
Still leaves you vulnerable to bios compromise (e.g. get some malware running in SMM before your kernel), but that can be addressed by soldering the bios WP pin low and dropping some epoxy over the laptop case screws.
Edit: There are some SPI chips that have a write protect fuse that you can blow, leaving your bios in a known-good state. [1] pdf page 7.
https://docs.microsoft.com/en-us/windows-hardware/design/dev...
Secure Boot as it is configured by Windows only prevents malware from inserting itself into the boot process, since all Windows installations use the same signature. Bitlocker only prevents attackers from accessing the data on the disk, not from using the workstation in general.
[1] https://www.reddit.com/r/thinkpad/comments/epadb5/psa_dont_i...
https://duo.com/labs/research/secure-boot-in-the-era-of-the-...
ME vs PSP isn't much of a choice. Of course POWER might be an option eventually, but isn't for most of us currently.
I mean I'm not a fan of DRM but then undermining it might cause browsers on Ryzen to no longer be able to run Netflix and similar.
While I guess many people on this site wouldn't care too much it's not profitable for AMD.
But then there should be a way to have both. The case which don't need/want DRM and can have a complete libre system and the case which needs DRM for whatever reason and sadly can't go libre.
