Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Boot is broken on 200 models from 5 big device makers

arstechnica.com

Post reply on HN
Print view View original

41–50 of 147 posts

Re: Secure Boot is broken on 200 models from 5 big device makers

#41

Post by Hizonner »

Gormo wrote: post #35
Hizonner wrote: post #31

Earlier quoted context omitted.

I strongly suspect that most or all of the modern "hardware" write-protect switches are actually just suggestions to the drive firmware. Which may very well itself be modifiable.

I can't imagine how it would be possible to do it any other way for a flash storage device. A mechanical hard drive could at least theoretically have a physical lock attached to the drive head which prevents it from approaching the platters if it is engaged.

Erm. The read head and the write head in a magnetic drive are the same head. You can't keep the head away from the surface if you want to read the disk. But you can disable power to the driver that puts write current into the head.

... and you could absolutely build similar functionality into a flash chip. But most likely you can't actually buy such chips, at least not with any real capacity.

Re: Secure Boot is broken on 200 models from 5 big device makers

#42

Post by manofmanysmiles »

Unless I'm missing something, Secure Boot as designed is fundamentally broken.

Its root of trust is the BIOS/Firmware, which can be updated from a running OS. There is no hardware root of trust.

How Secure Boot Works

Secure Boot ensures that a device boots using only software trusted by the Original Equipment Manufacturer (OEM). Here's a high-level overview:

1. Power On and Initialization: The CPU initializes and runs the BIOS/UEFI firmware, which prepares the system for booting.

2. Platform Key (PK) Verification: The firmware verifies the Platform Key (PK), which is used to validate Key Exchange Keys (KEKs).

3. Key Exchange Keys (KEK) Verification: The KEKs validate the allowed (whitelist) and disallowed (blacklist) signature databases.

4. Signature Database Verification: The firmware checks the allowed (db) and disallowed (dbx) signature databases for trusted software signatures.

5. Bootloader Verification: The firmware verifies the bootloader’s signature against the db. If trusted, the process continues.

6. Kernel and Driver Verification: The bootloader verifies the OS kernel and critical drivers’ signatures.

7. Operating System Boot: Once all components are verified, the OS loads.

Apple Secure Boot Process

Apple adds hardware-based security with the Secure Enclave:

1. Secure Enclave Initialization: Separate initialization handles cryptographic operations securely.

2. Root of Trust Establishment: Starts with Apple's immutable hardware Root CA.

3. Immutable Boot ROM Verification: The boot ROM verifies the Low-Level Bootloader (LLB).

4. LLB Verification: The LLB verifies iBoot, Apple's bootloader.

5. iBoot Verification: iBoot verifies the kernel and its extensions. The Secure Enclave ensures cryptographic operations remain protected even if the main processor is compromised.

For more details, check out:

- https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8...>

- https://www.apple.com/business/docs/site/Security_Overview.p...>

I would really love to have a hardware root of trust on a Linux or other open system, with a hardware security module of sorts that is programmable, so I decide what the root keys are, and is able to measure the firmware boot process, establishing a proper audit trail or chain of trust.

I can't remember the HN formatting rules, so expect an edit shortly to make this look better.

Edit: I did a little more poking. It's not quite as bad as I thought, because at least in theory, the BIOS will verify a digital signature of a BIOS update before flashing it.

Re: Secure Boot is broken on 200 models from 5 big device makers

#43

Post by out-of-ideas »

acdha wrote: post #22
drhagen wrote: post #6

> 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. Am I correct that Secure Boot purely exists to prevent this attack vector: malware gets root on the OS, hardware allows updating f…

Also things around physical access: if you steal my laptop, FDE prevents you from getting my data immediately but if you install malware which takes over the boot process, you get that data as soon as I type in my password. If the process changes so the hardware only loads signed firmware, which only loads a signed boot loader, which only loads a signed kernel, etc. that avenue of attack is closed. It also makes it p…

do folks in the business really simply steal a laptop and try to pull all data? or do they steal the laptop and wipe it and flip it... if they wanted your data wouldnt they steal you, the human, too ?

the signing method only offers buying more time before the innevitable data is "breached" by a theat actor - its the same buying-time for any and all encryption. the system can get too complex, and the underlying problems of humans will always exist (and amplified by more points of failure).. (accidents, data breaches, exploits, ect). the system needs to be immutable, but also mutable at the same time (for updates, ect) - and thats not exactly something easy to accomplish.

and with apple.. they try yes, but it is forever a walled garden. we've already seen their secure enclave bloatloader shinanigans get exploited on phones- and it was not fun for those people where their phones were compromised. apple suffer from us humans, too (we will never be perfect, nor will our software)

Re: Secure Boot is broken on 200 models from 5 big device makers

#44

Post by _trampeltier »

A bit oftopic but when last week came out, Cellebrite could open the Trump shooters phone, there was a PDF, they can brute force all android phones since from Android 7 or newer. What changed there? Why can they brute force all newer versions?

https://www.documentcloud.org/documents/24833831-cellebrite-...

Re: Secure Boot is broken on 200 models from 5 big device makers

#45

Post by snailmailman »

I’ve had so many issues with secure boot on my machines causing issues that if I ever saw a secure boot error message I would never think “oh I must have a rootkit”

Instead I would assume, in order

- my config broke it

- OS update broke it

- the bios doesn’t properly handle any case that isn’t “preinstalled OEM windows”

I had a laptop that as far as I could tell, could only boot into windows’ default bootmgr.efi. I could turn off secure boot, and tamper with that efi to boot Linux, but it refused to acknowledge other boot loaders from within the bios. It wouldn’t surprise me in the slightest if secure boot isn’t properly handled. I’ve had too many issues with cheap computers having janky bioses.

Re: Secure Boot is broken on 200 models from 5 big device makers

#46

Post by schmidtleonard »

Gormo wrote: post #35
Hizonner wrote: post #31

Earlier quoted context omitted.

I strongly suspect that most or all of the modern "hardware" write-protect switches are actually just suggestions to the drive firmware. Which may very well itself be modifiable.

I can't imagine how it would be possible to do it any other way for a flash storage device. A mechanical hard drive could at least theoretically have a physical lock attached to the drive head which prevents it from approaching the platters if it is engaged.

Writing flash takes (relatively) high voltage and the voltage boosting circuitry could be routed through a switch. It generally isn't, and the voltage converter is often an on-chip charge pump so this wouldn't be an easy retrofit, but the current state of affairs is due entirely to lack of interest rather than lack of possibility.

Re: Secure Boot is broken on 200 models from 5 big device makers

#47

Post by Hizonner »

_trampeltier wrote: post #44

A bit oftopic but when last week came out, Cellebrite could open the Trump shooters phone, there was a PDF, they can brute force all android phones since from Android 7 or newer. What changed there? Why can they brute force all newer versions? https://www.documentcloud.org/documents/24833831-cellebrite-...

Android 7 is when Google switched from dead simple full-"disk" encryption to per-file hackery with complicated key management. Basically the whole data encryption scheme changed.

Re: Secure Boot is broken on 200 models from 5 big device makers

#48

Post by upwardbound »

schmidtleonard wrote: post #46
Gormo wrote: post #35

Earlier quoted context omitted.

I can't imagine how it would be possible to do it any other way for a flash storage device. A mechanical hard drive could at least theoretically have a physical lock attached to the drive head which prevents it from approaching the platters if it is engaged.

Writing flash takes (relatively) high voltage and the voltage boosting circuitry could be routed through a switch. It generally isn't, and the voltage converter is often an on-chip charge pump so this wouldn't be an easy retrofit, but the current state of affairs is due entirely to lack of interest rather than lack of possibility.

Do those charge pumps use external capacitors? If so, you could disconnect/float those capacitors, or if that would damage or glitch the chip, you could replace the real capacitors with some circuit like a voltage regulator + diode that would be designed to provide the charge pump output rail with a voltage that's high enough not to glitch the chip but low enough to be unsuccessful in writing to the flash. Would one of those ideas work, and allow the retrofit you envision to be designed with existing flash memory silicon + a few additional components?

Re: Secure Boot is broken on 200 models from 5 big device makers

#50

Post by Scoundreller »

Gormo wrote: post #35
Hizonner wrote: post #31

Earlier quoted context omitted.

I strongly suspect that most or all of the modern "hardware" write-protect switches are actually just suggestions to the drive firmware. Which may very well itself be modifiable.

I can't imagine how it would be possible to do it any other way for a flash storage device. A mechanical hard drive could at least theoretically have a physical lock attached to the drive head which prevents it from approaching the platters if it is engaged.

Flash storage requires high voltage to do an erase (which needs to precede a write operation).

Back in the EPROM days, that was easy, just don’t supply 25V or whatever.

Modern flash still needs those high voltages but generates it on-chip via charge pumps. If your read-only switch physically disconnected the charge pumps, you would have read-only flash.

Post reply on HN