Idea: Secure IoT Development Kit

[technix]

The whole point of this kit is provide makers something that can use proper TLS efficiently without having to resort to Raspberry Pi or BBB.

For functionally simple gadgets an entire Linux kernel can be unnecessary and expose an unnecessarily broad surface of attack, as exposed by the Mirai botnet. This kit provides hardware support for some cryptographic primitives, allowing for efficient implementation of the TLS protocol stack.

Specs (SushiBits Two Connected):
* Arduino Sub-Mega form factor
* MCU: STM32F217VGT6 (Cortex-M3 @120MHz, 100 pins hopefully all broken out)
* Ethernet: DP83848 over RMII, maybe PoE support
* Wi-Fi: ESP8266 on ESP-12 module
* External memory: microSD card, maybe 1MB additional SRAM
* Maybe onboard debug probe using STM32F042F4

[Kalvin]

Have a look at Contiki OS (or any other OS for the IoT devices) which has support for DTLS.

[X]

SSL/TLS is a huge bloated protocol, and most vulnerabilities aren't in the ciphers themselves. These vulnerabilities are often in other parts of the implementation.

I'm at a loss as to what I think about this idea. I first read it thinking "not another single board computer, we have loads of them already." If it used RISC-V it may be worthwhile, but otherwise I hear the licensing for ARM isn't the most accessible to the budding startup.

A better idea would be to provide building blocks (ethernet/wifi/Bluetooth/USB/etc) as separate modules, this way an application that doesn't need WiFi or Bluetooth don't have to have it, they save power and money, and have fewer security issues.

[Matir]

The Mirai botnet didn't use kernel bugs, but used software running on the devices with default credentials.  No matter how you secure the platform, if the application layer is terrible, you're still insecure. 

[technix]

The Mirai botnet didn't use kernel bugs, but used software running on the devices with default credentials.  No matter how you secure the platform, if the application layer is terrible, you're still insecure. 

My point of an excessively large surface of attack still stands. The kernel may be rock solid but a lone kernel don't do much. When you get a userland on there the surface of attack would be increasing rapidly. The overall security is no more than the weakest link in the system.

[PointyOintment]

If it used RISC-V it may be worthwhile, but otherwise I hear the licensing for ARM isn't the most accessible to the budding startup.

You have to license ARM IP even if you're just building and selling a product with a COTS ARM chip in it? I thought only the chip makers had to license the ARM IP.

The Mirai botnet didn't use kernel bugs, but used software running on the devices with default credentials.  No matter how you secure the platform, if the application layer is terrible, you're still insecure. 

This device seems targeted at applications where you wouldn't have an operating system (i.e. microcontroller-based stuff) and so no malware can run alongside the maker's soft-/firmware.

Anyway, the Hologram (formerly Konekt (which apparently means something NSFW in Malaysia (but I can't find out what))) Dash Pro (which seems discontinued…?) supports TLS (that being its main advantage over the regular Dash (which is still available)), and it uses the same MCU as the Teensy 3.0, IIRC. Also, I am 95% sure I've heard that TLS on the ESP8266 is not hard to do. So I'm not sure what the purpose of this product is, when its declared purpose is already achievable with current commodity dev kits.

[Kjelt]

The problem is simple
If you have internet facing open listen ports you better have top notch every week auto updated gear behind it with firewalls and the lot because after ten minutes a zillion bots are visiting you reporting to their controllers. Now if you have a limited device such as a 217 that might not have a large attack surface it might be uninteresting to attack.
However the weak part is still the open port and network configuration, you need a dmz thus a very good or a second router.
Best defense is not to open a port. If you need communication with your home use an out of band communication way which is polled by the device. Such as gsm or email or phone.
Let the device contact you instead of the other way round and half the planet visiting you and trying to get in, probably resulting in hacking your router which is the weakest link, all because you draw attention to yourself with opening a port.

[jbb]

I think it's important that people make some actual effort for IOT Security.  Many products get pushed out the door with laughable security.

Unfortunately SSL/TLS is no guarantee of security.  There are a lot of aspects to consider.

Here are some things to think about just for TLS:

• Which crypto schemes will you support?  There are a lot and some of them are dreadful.
• How will you make sure the device can confirm the identity of the host? (i.e. How do you manage the host authentication.)
• How will you make sure the server can confirm the identity of the server? (i.e. How do you manage the device authentication.)
• How are the asymmetric keys generated?
• What happens when someone steals some devices and sucks the keys out?  Does that get them into other devices?
• How can you make key management easy enough that CutCorners Inc. will do it properly?
• That external SRAM sounds like it costs money.  If CutCorners Inc. chops out TLS, will it fit into on-chip RAM and "still work?"

So if you can do a minimal-footprint configuration and all the key-management (think about loading 10000 products) architecture that could be very useful.

You should also think about software licensing. Most companies won't use GPL because it is 'contagious;' code that is linked in the same binary (as lots of cheap IoT devices which don't run Linux do) also becomes GPL.