5 ms·

IoT is all about unsecured devices generally?

marktangotango 10y ago
That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.
- exelius 10y ago
  Maybe if you're talking about an Arduino (which is more of a micro controller than a full-on CPU). Anything resembling a real CPU definitely has the horsepower for SSL.
- leni536 10y ago
  I'm not a cryptographer, in my hobby project I used a port of nacl to AVR to do encryption. Such an IoT device doesn't need to process a large amount of data for encryption, it can be done on a 8bit uC.
- mavhc 10y ago
  Sounds more like the companies aren't bothered enough to pay for someone who knows what they're doing in a reasonable amount of time.
  - jussaskin 10y ago
    Some of these IoT devices are solar powered or rely on ambient electromagnetic energy and don't have enough juice to perform crypto.
- icebraining 10y ago
  I don't think so, but even if they were, you can buy a crypto co-processor for less than $1/unit.
  - JoeAltmaier 10y ago
    That could well be way over budget for hardware. Remember its $1 less margin on every unit. That's enough to kill many embedded projects.
- jenscow 10y ago
  By the way, the chips of smartcards are enough to perform encryption, as well as storing keys. (fast enough for streams in 'real-time' - I don't know)
- jerf 10y ago
  As usual, "it depends". If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done. Lesser-capable devices may have issues. But note that one way or another, the devices must speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not like we're living in the 1980s where we literally wouldn't have been able to afford the silicon in a consumer device. Hardware acceleration of SSL shouldn't be that hard to get a hold of, for instance: https://en.wikipedia.org/wiki/SSL_acceleration#Central_processor_support https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...
  - peterwwillis 10y ago
    But more to the point: there is no purpose to SSL/TLS on an appliance because it will not have a valid certificate, hence it won't protect anything. You might as well just use WPA2-PSK.
    - jerf 10y ago
      If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured. I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't all bad, it prevents that sort of thing.) I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's possible. Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often much much simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't that hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't that hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's still better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard. But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even half correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily bad and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't really know what you're doing with this crypto stuff? I dunno.
- Twirrim 10y ago
  What kind of latency is really an issue here? The payload isn't going to be large for lots of these IoT devices. If it takes a couple of hundred milliseconds longer to carry out the transaction is that really a big deal?
- toomanybeersies 10y ago
  The ESP8266, which is popular for hobbyist IOT projects doesn't have enough memory to do SSL. That's not to say that you can't do encryption though, just that you need to rethink how to do it, where the solution is not just unencrypted JSON APIs.

That's been my understanding as well. The cpu's used typically aren't powerful enough to do anything other than simple encryption in a reasonable amount of time. Ssl is generally out of the question. Someone please educate me if that's incorrect.

exelius 10y ago
Maybe if you're talking about an Arduino (which is more of a micro controller than a full-on CPU). Anything resembling a real CPU definitely has the horsepower for SSL.
leni536 10y ago
I'm not a cryptographer, in my hobby project I used a port of nacl to AVR to do encryption. Such an IoT device doesn't need to process a large amount of data for encryption, it can be done on a 8bit uC.
mavhc 10y ago
Sounds more like the companies aren't bothered enough to pay for someone who knows what they're doing in a reasonable amount of time.
- jussaskin 10y ago
  Some of these IoT devices are solar powered or rely on ambient electromagnetic energy and don't have enough juice to perform crypto.
icebraining 10y ago
I don't think so, but even if they were, you can buy a crypto co-processor for less than $1/unit.
- JoeAltmaier 10y ago
  That could well be way over budget for hardware. Remember its $1 less margin on every unit. That's enough to kill many embedded projects.
jenscow 10y ago
By the way, the chips of smartcards are enough to perform encryption, as well as storing keys. (fast enough for streams in 'real-time' - I don't know)
jerf 10y ago
As usual, "it depends". If this thing is capable of running OpenWRT, it can run some sort of SSL for what it needs. Might be tight and might have to not be OpenSSL, but it can be done. Lesser-capable devices may have issues. But note that one way or another, the devices must speak some decent encryption to get on to WPA2 networks. Of course that's probably done in the Wifi hardware, but it still shows that it's not like we're living in the 1980s where we literally wouldn't have been able to afford the silicon in a consumer device. Hardware acceleration of SSL shouldn't be that hard to get a hold of, for instance: https://en.wikipedia.org/wiki/SSL_acceleration#Central_processor_support https://en.wikipedia.org/wiki/SSL_acceleration#Central_proce...
- peterwwillis 10y ago
  But more to the point: there is no purpose to SSL/TLS on an appliance because it will not have a valid certificate, hence it won't protect anything. You might as well just use WPA2-PSK.
  - jerf 10y ago
    If you're using a custom client-side app to access the device, which many of these things seem to do, you can create a CA for the devices, put the public cert for the CA into the app, and issue each device an individual cert at the factory signed by that CA. Then the app can be reasonably secure and assured. I say only "reasonably" because defending against the "I cracked into the device and stole its cert" is pretty hard, but I'd submit, also not all that realistic a threat in this case. I'm really looking to defend more against "I bashed together some encryption so crappy I can hack this by making you visit a hostile web page" than "I want to use this lightbulb without the NSA knowing". (On that note, an SSL cert only valid to a custom app that your browser won't accept isn't all bad, it prevents that sort of thing.) I mean, this it total pie-in-the-sky in terms of the ask I'm making here for security knowledge and willingness to do something correctly instead of bashing out some terrible, incorrect crypto with direct and incorrect use of the primitives. But it's possible. Actually... I won't call myself an SSL expert per se, but one of the things that I find personally frustrating in dealing with some people is that once you do know what's going on, using SSL is often much much simpler than bashing together your own crap crypto. Any sensible SSL library has places to stick the CA certs. Generating them isn't that hard, more just tedious. Generating a big pile of certs at the factory and siging them isn't that hard. Even if you're very sloppy with your SSL usage, where you don't do a great job of protecting your core cert, where you use the root of the CA instead of an intermediate so the private key of the root is "live" in the factory, you don't set up a good revocation solution and you just set the expiration as far into the future as you can, because you probably haven't got a mechanism for updating them... even if you make all those errors, it's still better than just bashing crap crypto together, because it'll still resist more attacks than your crap crypto and it's not really all that hard. But I have abundant experience that shows people would way rather futz around directly with RSA keys and HMAC and spend days and weeks scraping something together rather than even entertain the suggestion of doing it even half correctly. I don't fully understand it. Do other people find futzing with crypto that fun? I play defense a lot in security, but I honestly find correct crypto a royal pain in the ass and do everything I can to outsource it via SSL (which may not be perfect but isn't necessarily bad and has the advantage of being very defensible when people ask "what do you do to secure things") or NaCL or something. Is it just the psychological difficulty of admitting that you don't really know what you're doing with this crypto stuff? I dunno.
Twirrim 10y ago
What kind of latency is really an issue here? The payload isn't going to be large for lots of these IoT devices. If it takes a couple of hundred milliseconds longer to carry out the transaction is that really a big deal?
toomanybeersies 10y ago
The ESP8266, which is popular for hobbyist IOT projects doesn't have enough memory to do SSL. That's not to say that you can't do encryption though, just that you need to rethink how to do it, where the solution is not just unencrypted JSON APIs.