Case Study: IoT and Security – Who Needs Either?
John Moor, IoTSF Managing Director
Recently, I had the pleasure of speaking to Damon Hart-Davis, CEO of OpenTRV. Damon is on a quest to reduce heating waste and in so doing “cutting carbon for everyone”. That is noble in itself, however, that was not the main purpose of the conversation. Damon is making use of communications technology to deliver his mission – and that brings his product into the realm of IoT.
I was naturally interested to hear his views on security and heartened by what he told me. His method is consistent with the founding values of IoTSF and what we consider to be best practice at the highest level, namely; a security-first approach, right-sized for the application and resilient over its life-cycle. It’s a case study that we wanted to share with the world as it helps to balance the perception that manufacturers are behaving badly – so we invited Damon to say a few words in this blog posting.
In short summary: OpenTRV exhibits the responsible behaviours we encourage in manufacturers – over to you Damon:
Damon Hart-Davis, CEO, OpenTRV
OpenTRV is on a mission to cut carbon and help neuter climate change, for Joe Everyone, at scale, cheaply and with minimal pain.
Increased energy efficiency, which carbon cutting implies, almost of necessity involves increased complexity, which we must not let fall on Joe, or it won’t happen. Joe has better things to do with life.
So that in turn suggests that our tech – in the first instance smart radiator valves – needs to have many IoT features, including radio comms, for best effect.
But we strongly believe that we must not compromise Joe’s security or privacy in achieving our carbon (and bill-saving) goals; we don’t want to contribute to making Joe’s heating DoS-able or leaking to burglars at large when Joe is likely to be away.
Our vision is to have hundreds of millions of our smart ‘Radbot’ devices installed in homes, etc, so if we get this wrong then we could become a big part of the problem.
I won’t run apps or banking on my Android smartphone because it doesn’t get frequent security patches (it’s had one update, ever); I wouldn’t bank from home if my machine there was not offered security updates monthly or thereabouts, given the rapidly evolving nature of Internet-borne threats. I spent more than 20 years building finance/banking systems and believe that to be a minimum sane approach, not paranoia.
Yet IoT has a problem because such devices are going to be rarely – if ever – updated, at least for small, cheap, low-power, fit-and-forget infrastructure, especially battery powered or even energy harvesting.
Even OTA (Over The Air) updates for small devices have their own issues such as the capacity of a device big enough to accept them – and indeed simply to run a decent IP stack – may be far higher than needed to perform the device’s main job, possibly making the device too expensive.
Our approach is generally to keep the Things away from the Internet, preferably avoiding the need to slurp data across the public network in the first place, else interposing a gateway/concentrator that is also a security firewall and that can be rapidly patched:
Then we ensure that all comms from the Things to the gateway, and from the gateway across the Internet, are sensibly secured with well understood and scrutinised schemes. Currently we use AES-GCM from our Things, which is OK for the moment to secure at least outbound comms direct across the Internet. The gateway, which is likely a much more capable device, eg a small embedded Linux box, can use much more sophisticated security wrapping for comms across the Internet, and for authenticating/screening incoming commands from the Internet.
Note that the Things’ communications still have to be locally secure (eg including robust authentication of any commands received) even if the Things never talk to the Internet. There are many well-known domestic IoT-style systems right now that I can mess up horribly if I can get to within (say) 100 metres of your home.
OpenTRV has created a permissively-licensed version suitable for 8-bit microcontrollers, currently Arduino AVR:
https://github.com/opentrv/OTAESGCM
We’d welcome further scrutiny and feedback and help with porting to other small IoT microcontrollers.
My mental check-list of how to do IoT comms right is:
- Have Things work autonomously if possible, or locally, or at least fall back gracefully to autonomy when necessary.
- Don’t have the Things talk directly to the Internet.
- Have Things’ comms properly secured; at least authenticated but usually in part encrypted for sensitive payload elements.
- If Things do need to talk to the Internet, then use a capable gateway/concentrator/firewall that can receive security patches automatically and frequently so that manual patching is not necessary.
- Be careful of what security- or privacy- compromising data Things may send, locally or over the public network. Traffic analysis may reveal more than intended (eg if valves were to send more often when calling for heat) even if the content itself has been encrypted.
- Accept that if a really monstrous new threat to some deployed Things arises, it may be cheaper to dispose of them and redeploy.
I have said before that IoT will really work when most of it is boring beige boxes that people can just forget about, but the security should not fail before the device otherwise does, which is a hard to get right in the absence of a crystal ball.
Damon Hart-Davis, CEO, OpenTRV
opentrv.uk
For more information on radbot go to: https://myradbot.com/
(c) Damon Hart-Davis 2017; all rights reserved.
