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?
Real security processors never give big bounties because when bugs are discovered all the buyers immediately cancel their orders of the 'faulty' secure chips.
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.
You can also bury the fuse array inside the chip. So in addition to the microscope, you will also have to non-destructively etch or mill the chip to expose the fuses. This also renders the chip non-functional, so if the secret is unique per chip, then the leaked secret can't be used to bootstrap to other secrets on the die.
There's a lot of people that believe that hardware remote attestation will be the end of computational freedom. I'm glad to see that bypasses are still quite possible.
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 also prevents "contempt of business model". Makes a SW or HW bypass for ink cartridge pairing or game piracy or monthly widget subscription difficult or impossible. May also make any vulnerability patchable.
If you depend on your firmware remaining secret, however, you have to contend with the black hat version of the presenters. They are expert at extracting firmware and cloning. Some applications choose FPGAs in part because the equivalent of their firmware (the bitstream) is itself nearly impossible to reverse engineer. That means that a one-for-one clone is possible, but you can't alter the design, and have to use the exact same part.
8 comments
[ 4.5 ms ] story [ 27.0 ms ] threadPresumably this is a sign RPi are deliberately aiming to straddle the hobby and light commercial markets?
They'd prefer to live in ignorance.
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'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.)
If you depend on your firmware remaining secret, however, you have to contend with the black hat version of the presenters. They are expert at extracting firmware and cloning. Some applications choose FPGAs in part because the equivalent of their firmware (the bitstream) is itself nearly impossible to reverse engineer. That means that a one-for-one clone is possible, but you can't alter the design, and have to use the exact same part.