Engineering Internet Of Things Secure network for our upcoming IoT service.
- End to End Security
- Secure Firmware Upgrades
- DoS Attacks
- DDoS Attacks
- DNS spoofing /don’t even think of DynDNS/
- man in the middle
- Using a VPN -> takes the problem away and requires extra settup. Not user friendly. The only pro is that it can use an existing infrastructure if present. A Big NO
- SSL -> expired certificates , heavy overhead, often exploited. Closed source library, may already be hacked. NO
- AES all the Way. A big YES
- DoS/DDoS prevention – redundant MQTT brokers, with dns/firmware fallback
So Why AES?
- Can provide end to end encryption
- Is openly developed standard – no hidden treasures
- Suitable for encrypting messages – MQTT messages
- Fast on modern processors and fast enough on the esp8266
- AES can run on smaller chips too.
- One big con is that the mqtt user name and password can be sniffed and used to connect to the cloud. But that’s easy solvable, if they don’t speak right, disconnect them and force password change.
Secure Firmware upgrades
Only local and only user initiated, user must see and check the result of the upgrade – Any other option introduces big risk for the system and the user.
Data – What to protect and what not?
It’s well know that all encryption is value versus time. So do you really want to hide what was the temperature at your house 5 minutes ago? – May be, if you are paranoid, but you definitely want to lock the access to your internet enabled door locks.
So all the actuators must be crypto protected – they do things. While sensors can be divided into two types – sensitive and non-sensitive. For example – house alarm state is sensitive, just like house human presence . But the outdoor temperature is not sensitive, you can get it N+1 ways.