You're completely right someone could put some other firmware on the image but have it return the correct one - we solve this by:
- padding the image to the size of the ROM (256k, the runtime image is ~10k)with random data making it incompressible
- signing the image (including the random bit) so that the image can't be altered
On a linux system the udev install script kicks off a process that starts with verification of the firmware image and finishes with putting it into service if verification passes.
This is open hardware - you can program it yourself, we'll be releasing both the hardware design and all the software in a little while - along with programmer for doing it - you just wont be able to create an image signed by us - but you can sign images and share them with your friends.
Note: what you can't do is program the device over the USB
As far as lifting the lid and verifying what's underneath is concerned we don't expect every user to open it and look at the board and understand how it works (we hope some people will and will verify our work) - but what you can do is look under there and verify that the board looks the same as images that we publish.
padding the image to the size of the ROM (256k, the runtime
image is ~10k)with random data making it incompressible -
signing the image (including the random bit) so that the
image can't be altered
You could pad it with data that looks random, but is secretly compressible. For example, the output of a prng with a known seed.
Why not pad it with something that's already compressed, but which has information content, like a nice jpeg or something?
well you have to consider me (the designer, the guy putting the original code in the device that you want to verify and make sure that it's not someone else's code) as trustworthy. After all I'm the one who's trying to protect the integrity of my product, I'm not going to give you a compressible bitstream if I can possible help it - and I'm going to publish the bitstream I am using so you can check
I think the parents point is that you generated the random-bitstream somehow, starting from a specific seed. If you know the seed, you could regenerates the random bitstream with a lot less bytes (=secretly compressible).
So now you have some extra room left on the ROM to embed your malicious firmware and still be able to dump the original full 256k.
If you start with a known image/photo (not yours, some public domain), that after encryption/compression is exactly the amount of padding you need (or cut-off), you have your padding-bitstream that is a lot harder to regenerate from a seed.
You're completely right someone could put some other firmware on the image but have it return the correct one - we solve this by:
- padding the image to the size of the ROM (256k, the runtime image is ~10k)with random data making it incompressible - signing the image (including the random bit) so that the image can't be altered
On a linux system the udev install script kicks off a process that starts with verification of the firmware image and finishes with putting it into service if verification passes.
This is open hardware - you can program it yourself, we'll be releasing both the hardware design and all the software in a little while - along with programmer for doing it - you just wont be able to create an image signed by us - but you can sign images and share them with your friends.
Note: what you can't do is program the device over the USB
As far as lifting the lid and verifying what's underneath is concerned we don't expect every user to open it and look at the board and understand how it works (we hope some people will and will verify our work) - but what you can do is look under there and verify that the board looks the same as images that we publish.