3 ms·
Security should be embedded in the IoT frameworks and should be easy for it to become the standard practice. But most IoT stuff are hacked on, rarely using any
by sametmax 10y ago
Security should be embedded in the IoT frameworks and should be easy for it to become the standard practice.
But most IoT stuff are hacked on, rarely using anything standard, and even when there is a framework involved, it seldom has security as a main feature.
Even when it does, it's still a lot of work. Take crossbar.io, which is my go to tool to communicate within a IoT context (or anything soft real time really). To secure it you need to:
- setup the TLS certificate. Default communication transport is over unencrypted websocket.
- configure the provided authentication service (and write a backend for your system).
- declare several realms to isolate the clients, and configure the permissions accordingly (default permissions are YOLO, to ease the "hello world", which I understand). Make sure you don't expose important RPC to the wrong clients or allow anybody to declare callbacks.
- manually code the procedure to use their hot reload system to swap code updates. It's made for local updates, not remote ones.
- be very careful when updating your clients. Crossbar routed RPC is transparent and it's tempting to replace a call from JS to Python to a call from JS to Postgres to remove a layer of indirection. But do you make proper permissions checks in your SQL ? Are you sure you don't expose too much ?
So basically, you can make it secure. But only if you know what you're doing and don't have a deadline tomorrow.
- bsder 10y ago> Security should be embedded in the IoT frameworks and should be easy for it to become the standard practice. To be fair, almost all of the security libraries suck. The only thing which is SMALL and solid is DJB's TweetNaCl (http://tweetnacl.cr.yp.to/ http://tweetnacl.cr.yp.to/) If I'm running on a Nordic nRF51 series, for example, things like SSL/TLS are a HUGE chunk of my RAM, ROM, battery, and time budgets. This exploit is a good example. Even if you wanted to use something like a public/private key system, it's not clear that the the Atmel SoC could handle it. In addition, there are still gaps in security libraries that we need. We don't have a good PAKE (password authenticated key exchange) library, for example. HomeKit standardized on SRP with a 3072-bit key, and then discovered that it was too heavyweight and slow for devices working with a lithium coin cell battery. Even Microsoft with AllJoyn had to deprecate SRP and switch to a non-standardized elliptic curve key exchange to better match tiny hardware. The crypto folks are falling down on the job here. These things aren't standardized, and they don't seem to have been beaten on very hard. And they certainly haven't been tested on small hardware very much. Everybody can bitch about security, but until someone figures out the tools required for these small systems, it's going to remain the wild west.
- sametmax 10y agoWell you said it. There is a reason IoT is not secured. It's hard to make thousands of connected devices with little system resource but connected on foreign networks in heterogeneous context secure.
- catdog 10y agoThen simply do not connect thousands of such devices if you can't handle it…
- sametmax 10y agoYeah. And to avoid theft, simply don't acquire things that are not yours.
- pythonaut_16 10y agoA better comparison would be: to avoid theft, don't build your house out of toothpicks that can't support a deadbolt door.
- bsder 10y agoAnd yet we built houses out of such materials for thousands of years. Security has 2 problems--technical and social. The technical problem will eventually get solved as transistors are almost free. We are integrating hardware accelerators into almost everything since transistors are so cheap. The social problem isn't so easy. Companies don't give a crap about security. Only when companies start losing 25% of their stock price after a breach will they care.
- deleted 10y ago[deleted]