How to provide updates to IoT devices – yes, I’m aware this might be a overly broad generalization for many different devices – has been the topic of many discussions in the last years (for those interested the papers from the “Internet of Things Software Update Workshop (IoTSU)” might be a good starting point).
Given Matthias and I will moderate the respective session at tomorrow’s IoT Insight Summit I started writing down some points that we consider relevant in this context.
Those can serve as a starting point for a discussion – the event’s format foresees “break out sessions” similar to the traditional Troopers Round Tables. So we will mainly come up with questions, instead of final answers or solutions (still, of course, we’ll provide some feedback wrt what we see in different environments…).
When it comes to (security) updates to IoT devices I like to differentiate between five different dimensions:
- the technical dimension
- the time dimension
- the dimension of physical interaction
- the socio-economic dimension
- the ethical dimension
Let’s have a quick look at potential considerations in each of these areas.
The Technical Dimension
This one encompasses all technical aspects of (securely) providing updates like the needed backend infrastructure (e.g. own servers, CDN, cloud), used protocols and cryptographic mechanisms employed. Here, namely the specific properties of smart devices (like constraints as for CPU/RAM, storage, bandwidth or their, in some cases, somewhat unpredictable lifespan/-cycle) have to be kept in mind. On the other hand there’s already quite some experience with this stuff from the traditional IT world, in a good or a bad sense (think of the challenges of patching in the Android ecosystem for the latter).
The Time Dimension
In this dimension we find aspects like
- “ownership” (which might change over time. => what are the implications once people move from one [IoT equipped] house to another? for certain devices: who’s “the owner” anyway?)
- “vulnerability lifecycle” (e.g. how is the handling of phases like “general purpose patch available but not yet adapted to $PLATFORM” supposed to look like?)
- “end of device’s lifecycle” (is it a viable option to remotely disable devices from the vendor’s side either after some predefined time of use or at least once patches are no longer provided?).
The Dimension of Physical Interaction
From our experience this is an often overlooked one. It’s about the interaction of the update process and its implications (like a reboot) with the physical environment the device controls. Simple example: lightbulb reboots, lights go out, someone falls from a ladder. Questions in this context include:
- Which consequences for the physical environment can arise from a reboot?
- Which consequences for the physical environment can arise from a crash (due to something going wrong during update)?
- How does the vendor notice such events? What to do once device does not come up again after reboot?
In case an update requires user intervention/confirmation
- How to design this (process-/interface-wise)?
- How to handle cases where the confirmation does not happen within $TIMEFRAME?
- How/when to announce availability of a patch (e.g. while driving)?
Usually a thorough risk analysis is needed in this space, in an early stage of (product) development.
The Socio-economic Dimension
In this one, the questions to think through (and where to come up with decisions, at some point) include
- The role of users. Are they supposed/allowed to patch on their own?
- For a vendor providing updates mean efforts (costs!) How long do you want to do this for $PRODUCT? How do you announce this decision/information? What consequences result from that? Relationship with warranty? Relationship with liability?
- What about a vendor-side kill-switch? Tell customers about this or not? Will they appreciate the capability?
- How will the above be affected by an M&A?
The Ethical Dimension
Finally there’s the ethical dimension. Again, some aspects have to be reflected on, like
- Is there a moral obligation to protect users or “the Internet”? If so (any of those), how long (as for a product’s lifecycle)?
- Let‘s assume there‘s a (crypto) master key for the updates. Which parties to share that one with?
- Same question for a potential kill-switch.
The above is just meant to give an idea of things to consider in the course of designing an update process for IoT devices. We might discuss some of those in more detail in a later post.
With regard to the IoT summit we look forward to lively discussions ;-).
Everybody have a great day
Enno