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

Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

streaming.media.ccc.de

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#11

Post by JayHLee77 »

michaelt wrote: post #2

Seems a bit of a strange feature to even want on a product targeting the education market. In a classroom setting you don't really want students to be able to set fuse bits so the device can't be re-programmed. Presumably this is a sign RPi are deliberately aiming to straddle the hobby and light commercial markets?

Security is an essential feature for everyone, not just Enterprise. Can you trust the code your device is running? Can your device keep a secret? These capabilities are needed universally.

As to students being able to set the efuse so the device can't be reprogrammed, sure but they're $5 each so it's not like they're destroying a $500 Chromebook (which they do, look on YouTube). That risk is the cost of attempting to educate though (and it's worth it).

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#12

Post by Retr0id »

michaelt wrote: post #2

Seems a bit of a strange feature to even want on a product targeting the education market. In a classroom setting you don't really want students to be able to set fuse bits so the device can't be re-programmed. Presumably this is a sign RPi are deliberately aiming to straddle the hobby and light commercial markets?

Seems like a small risk compared to students creating a trivial short-circuit and letting out the magic smoke, and at $1/part it's not a big deal even if they do.

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#13

Post by michaelt »

lll-o-lll wrote: post #9

What an interesting talk, and an interesting concept also. Open source hardware security; get the security researchers interested and fix the security defects. The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? I suppose the hsm model of “destructive tamper detection” is one way.

> The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder?

Get your chip made with the latest TSMC process and get features so small nobody else, even superpowers and trillion-dollar tech companies working together, can manipulate them :)

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#15

Post by compsciphd »

londons_explore wrote: post #7

Real security processors never give big bounties because when bugs are discovered all the buyers immediately cancel their orders of the 'faulty' secure chips. They'd prefer to live in ignorance.

really big bounties would then be appropriate, as they would come with NDAs. Small bounties would just encourage others to make them public / sell them to more malicious actors.

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#17

Post by shash »

michaelt wrote: post #13
lll-o-lll wrote: post #9

What an interesting talk, and an interesting concept also. Open source hardware security; get the security researchers interested and fix the security defects. The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? I suppose the hsm model of “destructive tamper detection” is one way.

> The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? Get your chip made with the latest TSMC process and get features so small nobody else, even superpowers and trillion-dollar tech companies working together, can manipulate them :)

A good scanning electron microscope costs at most a few million? And is pretty common in a decently funded lab pretty much anywhere? Resolutions of 5nm is not uncommon. A scanning tunnelling microscope can go much lower (single atom types) and isn’t all that much more expensive either (comparatively I mean).

I think it’s common knowledge by now that the smallest feature in a 5nm chip isn’t really 5nm. So that’s not (yet?) a viable strategy.

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#18

Post by jnwatson »

lll-o-lll wrote: post #9

What an interesting talk, and an interesting concept also. Open source hardware security; get the security researchers interested and fix the security defects. The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? I suppose the hsm model of “destructive tamper detection” is one way.

The current solution is obfuscation. They make the mapping from physical state to actual key complicated enough that you have to reverse engineer a lot of the logic.

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#19

Post by klysm »

regularfry wrote: post #10
lll-o-lll wrote: post #9

What an interesting talk, and an interesting concept also. Open source hardware security; get the security researchers interested and fix the security defects. The “read the data out with a super expensive microscope” remained. Is there any way to defeat that attack I wonder? I suppose the hsm model of “destructive tamper detection” is one way.

I patented something that had a countermeasure for this, which was a bit impractical but fun to think about. Basically you put the sensitive data in an eeprom layered with a chemical that emits UV when exposed to air or, optionally, visible light - chemically more entertaining, hard to manufacture. But it's a just an arms race at that point.

Cool idea, but seems pretty straightforward to bypass and definitely an arms race

Re: Of Boot Vectors and Double Glitches: Bypassing RP2350's Secure Boot

#20

Post by lysace »

I've had a bit of a difficulty of understanding the actual benefits of proper secure boot vs zero protection.

I've arrived at this understanding: secure boot sometimes allows you to recover a compromised fleet without recalls. Instruct the customer to disconnect the device, reboot it and then somehow reflash it before getting infected again? Seems fraught with errors though.

When I worked with IoT HW companies in Taiwan their understanding tended to be along the lines of: "it makes the device secure" or "it prevents the firmware from being used by clone devices".

(It's been a while since I worked in this area.)

Post reply on HN