Now that you all are so busy implementing Internet of Things pilots everywhere, I mean at home like with this and this, but B2B everywhere as well (…!?) or are you doing it there not too, we may need to consider Security.
Yeah, Hans Teffer did a great piece on that (see here, in Dutch) and I blogged about that before [and many more links/posts…]. And, there’s quite some other issues with IoT. But the point here is – we haven’t thought of security before implementation.
And at the very few implementation’lets of IoT we see so far, security seems absent. Of course, you’d first want to make it work in the first place. But you’re doing it not right at the start, and you know that decisions made now (implicitly) will remain in the architecture for decades to come, in particular when today’s (almost) stand-alone implem’s become linked up into one giant uncontrolled, uncontrollable mesh.
Now, first, an intermission:
[At dawn]
So, ‘we’ all have been complaining about the security risks of IoT here and there and everywhere, in particular re the current risks of all sorts of industrial control being hooked up to the ‘net without anyone knowing or caring about proper sec.
And still then, we haven’t progressed beyond this Boy Crying Wolf position. Instead of moving to provide solutions. To begin with architecture ideas, the kind that we will need in order to branch out of the simpleton pilots.
On a walk, it struck me that one major part of any solution would be with Identification, Authentication (A1), and Authorisation (A2) – in particular at each and every end node in the network, the kinds you would want to reach to transit back to the Real, Physical world of Things and which are supposed to move ever closer to some form of smart dust… Whereas now, we often have the I and A1 usually at the front door, and the A2 somewhere in the/a network usually ‘near’ the end point (which also usually, is a relatively compute-enabled ‘large’ thing like a server with data).
Clearly, with the IoT we’ll need something else. All end points may float around somewhere out there, uncontrolled, un-tied-down in the giant global mesh network architecture. We will be systemically unable to tie any A2 server to an end point or vice versa (smart dust, spread out, remember), and the IA1-part will also be much, much less definable than it is today. But then, we’ll need much finer-grained access control at the end point, and much more flex at the (IA1) entry point or we leave it all free for all and only at the end point, the destination, check IA1 (again). For this IA1A2 at the end point, we need to consider:
- The end point(s) will very probably have very limited computing capacity; even with Moore et al., this will still lag required resource in a big way – because any type of ‘attack(er)’ will have vastly more computing power available. Hence, things will need to be really really simple at this point. We may need to consider global IoT mesh network segmentation or other pervasive and comprehensively secure forms of IA1 at entry points (how to guarantee complete coverage) or throughout the mesh (how to prevent complete coverage without even the slightest possibilities of evasion).
- Identities… ?? Where, how to manage the I’s and maintain the I+A1’s privacy, and transparency to the A2-owners ..?
- How to arrange A2 at all those end points, including the ability to maintain those ..? The dust (or some coarser-grained proxy, whatever) is out there, and can’t easily be uploaded all with the latest A2 tables we’d want – or that is done by some broadcast flash approach which is all too vulnerable for cracked use.
But still, we need something of that kind. And transparency built in to that, too… To ensure No Backdoors and accountability in general, as these cute little hidden holes would be exploitable by all the bad guys (official, and not). By the way, #ditchcyber.
I’m aware there’s more problems than solutions in the above. But you should be aware of the risks of letting them remain unsolved. Your suggestions, please!
And, just so you know:
![20140917_092605[1]](https://maverisk.nl/wp-content/uploads/20140917_0926051.jpg)
![20140917_144502[1]](https://maverisk.nl/wp-content/uploads/20140917_1445021.jpg)
