7 ms·

Awesome. One question... why STM/ARM? I'm not an expert in the available choices, but I'm generally curious about RiskV devices because they're fully open. A

by jaekwon 10y ago

Awesome. One question... why STM/ARM? I'm not an expert in the available choices, but I'm generally curious about RiskV devices because they're fully open. Are the designs of this chip at least available, and audit-able, or could it contain something like Intel's HM?

lisper 10y ago
> Awesome. Thanks! > why STM/ARM? The STM32F415 is specifically designed for crypto and security-sensitive applications. It has built-in support for AES and other crypto primitives (though I'm not actually using any of those at the moment), a hardware random number generator, and built-in readout protection modes that prevent you from externally accessing the flash or the RAM. And it has plenty of flash and RAM for this sort of application, and it's reasonably priced. If you designed a SoC from scratch for this application you couldn't do much better than this chip. > Are the designs of this chip at least available, and audit-able, or could it contain something like Intel's HM? No, I don't think so. And yes, it's possible there's a back-door in there, but I think it's unlikely. The market for this chip is embedded devices with sensitive code. If it became known that there was a back door that would destroy the market for the chip. But if you want one based on a RiskV I'd be happy to discuss doing a custom development.
- e12e 10y ago
  It looks like a very nice piece of kit - I just might have to get one :-) But speaking of hardware, I was recently reminded of the new BBC:Micro[m] project thanks to an email by the PythonAnywhere[p]-team. I wonder how much of the features could be implemented on that? I'm guessing that while the micro-usb might allow for power and data connection to the host - there'd probably not be a way to prevent compromise when connected (I'm guessing malware could reprogram the device without overwriting the stored keys). Thoughts? [m] https://www.microbit.co.uk/device https://www.microbit.co.uk/device [p] https://www.pythonanywhere.com/ https://www.pythonanywhere.com/ [ed: As for adding (some) tamper-proofing to either device, remember the glitter-nailpolish-picture-trick: https://www.wired.com/2013/12/better-data-security-nail-polish/ https://www.wired.com/2013/12/better-data-security-nail-poli... I wonder if it would be possible to epoxy up the BBC:Micro's micro USB port, and use the connectors/headers for communicating, possibly emulating USB 1.1 or something, with an soldered connector. ]
  - lisper 10y ago
    > I just might have to get one Better hurry. My stock of prototypes is very nearly sold out. > BBC:Micro[m] project I have no idea about that particular device. But very few things end up being secure by accident. But if it's not designed for security like the STM32F415 is, then I'd say odds are good it's not secure.
    - e12e 10y ago
      Sorry (happy :) to hear that you're running out. Might actually be in a situation soon where it will make more sense to hold a workshop and build a good handful of the things. Agreed on the "accidentally secure" part. Then again, if you could drench a full x86 pc in epoxy, it might be possible to make "reasonably secure" blob if all you left open was a serial port. Might.
pjc50 10y ago
Are RISCV devices actually available at all? I'm not too worried about backdoors in microcontrollers, they're too small to hide much. Are the designs of this chip at least available, and audit-able I'm not aware of any processors you can buy from current production that meet this criterion (because it would involve complete exposure of that company's IP). I suppose the fully reverse-engineered 6502 meets it.
- frederikvs 10y ago
  > I'm not too worried about backdoors in microcontrollers, they're too small to hide much. Have you read the article "A2: Analog Malicious Hardware" [1]? You really don't need much space to insert a backdoor in silicon. [1] http://ieee-security.org/TC/SP2016/papers/0824a018.pdf http://ieee-security.org/TC/SP2016/papers/0824a018.pdf
- kabdib 10y ago
  > I'm not too worried about backdoors in microcontrollers, they're too small to hide much. You can hide a LOT on a chip, though for embedded systems the attacks are not likely to be generic, or scale. If I was a spook agency, I'd definitely try to compromise USB handling, at a low level. Most controllers I know of use DMA, so it's likely that sneaking in a few hundred gates would open up a whole SOC. The USB controllers are just libraries that people buy; I don't know how closely they are audited by customers. Hook that up to a compromised PC (read about system management CPUs...) and that's the ball game. Silicon is pretty opaque.

by jaekwon 10y ago

lisper 10y ago

> Awesome. Thanks! > why STM/ARM? The STM32F415 is specifically designed for crypto and security-sensitive applications. It has built-in support for AES and other crypto primitives (though I'm not actually using any of those at the moment), a hardware random number generator, and built-in readout protection modes that prevent you from externally accessing the flash or the RAM. And it has plenty of flash and RAM for this sort of application, and it's reasonably priced. If you designed a SoC from scratch for this application you couldn't do much better than this chip. > Are the designs of this chip at least available, and audit-able, or could it contain something like Intel's HM? No, I don't think so. And yes, it's possible there's a back-door in there, but I think it's unlikely. The market for this chip is embedded devices with sensitive code. If it became known that there was a back door that would destroy the market for the chip. But if you want one based on a RiskV I'd be happy to discuss doing a custom development.

e12e 10y ago
It looks like a very nice piece of kit - I just might have to get one :-) But speaking of hardware, I was recently reminded of the new BBC:Micro[m] project thanks to an email by the PythonAnywhere[p]-team. I wonder how much of the features could be implemented on that? I'm guessing that while the micro-usb might allow for power and data connection to the host - there'd probably not be a way to prevent compromise when connected (I'm guessing malware could reprogram the device without overwriting the stored keys). Thoughts? [m] https://www.microbit.co.uk/device https://www.microbit.co.uk/device [p] https://www.pythonanywhere.com/ https://www.pythonanywhere.com/ [ed: As for adding (some) tamper-proofing to either device, remember the glitter-nailpolish-picture-trick: https://www.wired.com/2013/12/better-data-security-nail-polish/ https://www.wired.com/2013/12/better-data-security-nail-poli... I wonder if it would be possible to epoxy up the BBC:Micro's micro USB port, and use the connectors/headers for communicating, possibly emulating USB 1.1 or something, with an soldered connector. ]
- lisper 10y ago
  > I just might have to get one Better hurry. My stock of prototypes is very nearly sold out. > BBC:Micro[m] project I have no idea about that particular device. But very few things end up being secure by accident. But if it's not designed for security like the STM32F415 is, then I'd say odds are good it's not secure.
  - e12e 10y ago
    Sorry (happy :) to hear that you're running out. Might actually be in a situation soon where it will make more sense to hold a workshop and build a good handful of the things. Agreed on the "accidentally secure" part. Then again, if you could drench a full x86 pc in epoxy, it might be possible to make "reasonably secure" blob if all you left open was a serial port. Might.

pjc50 10y ago

Are RISCV devices actually available at all? I'm not too worried about backdoors in microcontrollers, they're too small to hide much. Are the designs of this chip at least available, and audit-able I'm not aware of any processors you can buy from current production that meet this criterion (because it would involve complete exposure of that company's IP). I suppose the fully reverse-engineered 6502 meets it.

frederikvs 10y ago
> I'm not too worried about backdoors in microcontrollers, they're too small to hide much. Have you read the article "A2: Analog Malicious Hardware" [1]? You really don't need much space to insert a backdoor in silicon. [1] http://ieee-security.org/TC/SP2016/papers/0824a018.pdf http://ieee-security.org/TC/SP2016/papers/0824a018.pdf
kabdib 10y ago
> I'm not too worried about backdoors in microcontrollers, they're too small to hide much. You can hide a LOT on a chip, though for embedded systems the attacks are not likely to be generic, or scale. If I was a spook agency, I'd definitely try to compromise USB handling, at a low level. Most controllers I know of use DMA, so it's likely that sneaking in a few hundred gates would open up a whole SOC. The USB controllers are just libraries that people buy; I don't know how closely they are audited by customers. Hook that up to a compromised PC (read about system management CPUs...) and that's the ball game. Silicon is pretty opaque.