9 ms·

This seems sound. However, I'm in doubt about some of their points: > You can ask it to dump the current firmware to you It can dump the firmware but it can s

This seems sound. However, I'm in doubt about some of their points: > You can ask it to dump the current firmware to you It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it? > You can see all the components on the board The fact that I can see these tiny thingies doesn't do much good either? Can I, seeing them, tell what they do? No. Building one of these yourself seems to solve both problems. Not trying to undermine it or anything, just curious what others think of it.

tribaal 12y ago
The point is - you can verify it yourself. Without trusting anybody else. Dumping the firmware means you can ensure it's not been modified (presumably from when you uploaded it to the device yourself). Being able to inspect components means you can ensure it's still exactly as you built it. And if you haven't, you can visually check that it does what it says it does. If you're not technically competent to make this verification, you can ask somebody you trust and who is to do it for you.
- gcommer 12y ago
  None of the images show the other side of the board, but unless every trace is visible, it will be difficult to non-destructively inspect. If its only a 2 layer board then this just means scratching off the white silkscreen, which wouldn't be too bad. If its more than 2 layers, you would have to have access to an X-ray machine.
  - Taniwha 12y ago
    it's a two layer board - no buried wires or vias - by design there are very few wires on the bottom layer, none under the noise source (we want to contain the noise) - you can see all the wires without removing the solder mask just by holding it in the right light we'll be publishing the layout files of course
- joezydeco 12y ago
  How do we verify the internal microcode and switch fabric of the TI CC2531? IMO it seems like simply trusting the large block diagram that says "USB PHY" is a very weak point in the design.
  - WaywardGeek 12y ago
    Still, a USB phy is required. How would you solve this problem? Would a FTDI USB chip be more palatable?
    - joezydeco 12y ago
      Who knows. Perhaps a Verilog implementation on an FPGA? Discrete gates and GPIOs galore? Sarcasm and FTDI chips aside, I'm hoping the point was clear. Guess it wasn't. Using USB as the physical transport from dongle to CPU just introduces more black boxes in a system where everyone was bragging about no black boxes. But since we're past the age of parallel ports and discrete GPIOs on these machines, there doesn't seem to be an easy answer.
ChrisAntaki 12y ago
> Building one of these yourself seems to solve both problems. I'd love to see a 3D printer that specifically built verifiably secure hardware.
- icebraining 12y ago
  Ah, but can you trust the c̶o̶m̶p̶i̶l̶e̶r̶ 3D printer?
unwind 12y ago
> It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it? Well, of course, in theory. In practice the total amount of firmware space is limited. It's rather large, as these things go, at 256 or 512 KB depending on the exact model. If it dumps a firmware close to that size, which passes scrutiny by several people, I would say that the risk that the chip still manages to contain a firmware which creates bad random data and a fake firmware is rather slim. Of course it's not impossible, and if you made it a contest (which, perhaps it is to some people) I'm sure it could be done. It's hard to trust digital systems of this complexity; what if you decide you don't trust TI (the makers of the microcontroller) in the first place, for instance? Building your own processor at this performance and size level isn't trivial.
- Taniwha 12y ago
  the actual firmware is far smaller than that (see my explanation about how we pad it out above) - essentially the way you verify it is by compiling the (open) source and getting the same binary image (and then of course one verifies the source by inspection)
Taniwha 12y ago
Note: I'm Paul the designer 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.
- michaelt 12y ago
  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?
  - Taniwha 12y ago
    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
    - 12y ago

tribaal 12y ago

The point is - you can verify it yourself. Without trusting anybody else. Dumping the firmware means you can ensure it's not been modified (presumably from when you uploaded it to the device yourself). Being able to inspect components means you can ensure it's still exactly as you built it. And if you haven't, you can visually check that it does what it says it does. If you're not technically competent to make this verification, you can ask somebody you trust and who is to do it for you.

gcommer 12y ago
None of the images show the other side of the board, but unless every trace is visible, it will be difficult to non-destructively inspect. If its only a 2 layer board then this just means scratching off the white silkscreen, which wouldn't be too bad. If its more than 2 layers, you would have to have access to an X-ray machine.
- Taniwha 12y ago
  it's a two layer board - no buried wires or vias - by design there are very few wires on the bottom layer, none under the noise source (we want to contain the noise) - you can see all the wires without removing the solder mask just by holding it in the right light we'll be publishing the layout files of course
joezydeco 12y ago
How do we verify the internal microcode and switch fabric of the TI CC2531? IMO it seems like simply trusting the large block diagram that says "USB PHY" is a very weak point in the design.
- WaywardGeek 12y ago
  Still, a USB phy is required. How would you solve this problem? Would a FTDI USB chip be more palatable?
  - joezydeco 12y ago
    Who knows. Perhaps a Verilog implementation on an FPGA? Discrete gates and GPIOs galore? Sarcasm and FTDI chips aside, I'm hoping the point was clear. Guess it wasn't. Using USB as the physical transport from dongle to CPU just introduces more black boxes in a system where everyone was bragging about no black boxes. But since we're past the age of parallel ports and discrete GPIOs on these machines, there doesn't seem to be an easy answer.

ChrisAntaki 12y ago

> Building one of these yourself seems to solve both problems. I'd love to see a 3D printer that specifically built verifiably secure hardware.

icebraining 12y ago
Ah, but can you trust the c̶o̶m̶p̶i̶l̶e̶r̶ 3D printer?

unwind 12y ago

> It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it? Well, of course, in theory. In practice the total amount of firmware space is limited. It's rather large, as these things go, at 256 or 512 KB depending on the exact model. If it dumps a firmware close to that size, which passes scrutiny by several people, I would say that the risk that the chip still manages to contain a firmware which creates bad random data and a fake firmware is rather slim. Of course it's not impossible, and if you made it a contest (which, perhaps it is to some people) I'm sure it could be done. It's hard to trust digital systems of this complexity; what if you decide you don't trust TI (the makers of the microcontroller) in the first place, for instance? Building your own processor at this performance and size level isn't trivial.

Taniwha 12y ago
the actual firmware is far smaller than that (see my explanation about how we pad it out above) - essentially the way you verify it is by compiling the (open) source and getting the same binary image (and then of course one verifies the source by inspection)

Taniwha 12y ago

Note: I'm Paul the designer 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.

michaelt 12y ago
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?
- Taniwha 12y ago
  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
  - 12y ago