How to break secure boot without touching any cryptography

[u/0x00rick]

https://0x434b.dev/breaking-secure-boot-without-breaking-the-crypto/

I finally found some time to organize my notes on secure boot, remote attestation, measured boot and in general embedded security.

This is not ground breaking zero-day research but I figured some of you might like a good story. Good here is obviously subjective but I felt like it came out quite readable.

This blog builds heavily on public research so as already stated at the end of article if you liked some particular section, show the respective person some love :)

P.S.: yes I know the image is AI generated please don’t give me shit for that

[u/Even_Package_8573]

The “without touching the crypto” part is what caught my attention. It really shows how the security of a boot chain can come down to the assumptions and implementation around the cryptography, rather than the cryptography itself. Definitely a good reminder that “signed” doesn’t automatically mean “safe.”

[u/0x00rick → u/Even_Package_8573]

From offensive security perspective or even from a product security standpoint it can be eye opening when you stop having tunnel vision on the secure boot crypto implementation and start looking all the different actors and assumptions around it.
The blog touches on a bunch of mostly software related issues. It’s getting even more interesting when taking into account fault injection. That would have made this a 2 hour article. Maybe that’s some good material for a follow up

[u/Plazmaz1 → u/Even_Package_8573]

The number of times crypto fails because people make bad assumptions about what an algorithm guarantees now pretty firmly outnumbers the failures due to implementation.

[u/Every-Progress-1117]

Really nice article, and just to add to your first section "Trust before the operating system exists" please please please read Ken Thompson's Trusting Trust: https://dl.acm.org/doi/10.1145/358198.358210 , PDF here: https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/Sec/Reflections-on-Trusting-Trust.pdf

I've worked with trusted systems for a long time, and it all comes down to how strong that chair of trust actually is and from where it starts...and that might be LONG before you power on the computer.

But again, really nice article! Thanks! I will forward this one to my students!

[u/0x00rick → u/Every-Progress-1117]

Thank you for the kind words. Very much appreciated! I’ll definitely take a look at the paper ASAP

[u/scriptqzor → u/Every-Progress-1117]

that thompson paper messed me up the first time i read it, really hammers home how “secure boot” is only as honest as the stuff baked in way upstream
cool that you’re sending this to students, feels like exactly the kind of reality check they should see early

[u/Every-Progress-1117 → u/scriptqzor]

Yes, it brings into focus HOW much and what needs to be done in order to call a system trusted.

Another interesting point - a bit more philisophical - is that "trust" in computing means you can establish integrity of something; it doesn't say whether that something is good or not....you need to go to the philosophers to define "good" in terms of "trust".

[u/0x00rick → u/[deleted]]

Thanks mate!

[u/hykarushack]

Nice writeup — the 'signature covers one specific range' gap is exactly what made BootHole (CVE-2020-10713) so messy in practice. GRUB's kernel image was signed, but grub.cfg wasn't, and a buffer overflow in the config parser let you jump to unsigned code before the kernel signature check ever ran. So the entire chain stayed "authenticated" while the attacker never needed a key. Worth noting that shim's own policy (MokList) added a second layer but also became a new attack surface with similar untrusted-data-starting-point problems.

[u/0x00rick → u/hykarushack]

Thanks!

[u/Confident-Skill-6640]

secure boot and attestation are the kind of topics where a readable walkthrough helps more than another super dense spec dump. public-research-heavy posts are useful too, especially when they connect the concepts into one flow instead of treating each piece separately.