Security is a hot topic when it comes to IoT and a vital consideration as you build your connected devices. Strangely enough, it is frequently overlooked at prototyping stage. We have seen products that went through to production stage with poorly designed security mechanism or little security measures at all.
Why it matters
The simple answer, because buyers demand it. Whether you are considering a device for end consumers or businesses, both care about how their data is handled. The fears of your IoT enabled house just being hacked and letting anyone in or collected consumer data being leaked are real and discussed throughout the press relentlessly.
Think about the valuations some well-known organisations received before their platforms made any real money (we are looking at you, Facebook). Why? Data. The potential to segment, target and learn about audiences is extremely valuable. In the same token, think about the court cases, complaints and fears voiced by users consistently about how their data is viewed, shared and sold. Data is a commodity and a highly valuable one at that.
For hardware innovators the result is having to be ready with answers on the security of their IoT software solution right from the start. Investors evaluating your prototype will strongly care about this.
Security for IoT software solutions
How to protect your device from being accessed and used by malicious parties is a fear that you need to tackle right from the beginning of development.
When it comes to IoT there are a wide variety of protocols available. Most of them use TLS/DTLS and some protocols, like Cesanta’s Clubby, allow you to use virtually any existing protocol as transport.
There are main two challenges around secure communication with embedded systems:
- True Random Number Generation. This is the foundation of modern security algorithms. However, usual sources of entropy like disk access timing, mouse & keyboard events, are not available on most embedded systems. Thus, secure embedded systems should provide hardware support for RNG
- Computationally expensive crypto operations. In particular, RSA and Diffie-Hellmann public key algorithms use y = pow(x, e) mod n operation, which on some chips may take seconds or even minutes to complete - depending on the key size. Thus, the challenge: establishing a secure connection is very expensive in terms of CPU time, at the same time keeping the connection alive is expensive, too in terms of battery life. For real applications, a tradeoff should be made.
Our recommendations for secure data transfer
- Use hardware that implements RNG or the whole crypto stack on chip
- Implement anti-tamper features in hardware
- If you can’t implement security on a device for any reason, then use gateways that wrap communication into secure channels
- Follow the standards out there: use TLS/DTLS for encryption and authentication
- Have a recovery plan should things go wrong
- Keep a balance between cost and the provided level of protection
To contact: send us a message or ask on the developer forum.