Securing connected devices and stopping AI going bad?
From the archive: written before or outside the Architect Tomorrow newsletter, so it may be out of date.
As the explosion in connectivity, smart devices and AI continues to accelerate in pace - security as ever is a massive concern. Also it is potentially a blocker for adoption of the Internet of Things (IoT) and future applications of Artificial Intelligence and robotics. Just look at the news around connected cars being hacked (the Jeep entertainment system in the states) and worries that Skynet from the Terminator is in our medium term future!
So how could we easily secure IoT that we own in a seamless, robust and plug and play manner? Personal wearables and other IoT devices need to be secure by default and maybe (I stress maybe!) tied together with an evolution of OAuth (a standard used by websites to manage user identities) and NFC (Contactless type technology). I don’t claim to have this fully nailed yet but it is something I am thinking about (and I am sure many others are too). Imagine your Smartphone as the hub of your identity (its generally signed in to at least one cloud identity like Google, Microsoft (or Apple - hmm perhaps not with the iCloud security issues) and using NFC you can tap your watch, trainers, umbrella, whatever else you want to use your credentials. Want to logout out? Maybe thats a double tap or something with vibration feedback to tell you its logged out. Perhaps you also need to use a biometric - like the fingerprint sensor on the phone in addition to the NFC tap?
As for the connected car security issues - I think this is a classic case of the trusted “castle and moat” type approach that several organisations used to take on security. By this I mean that IT systems within the organisation boundary (protected by firewalls aka the castle walls / moat) was viewed to be trusted and secure. Car makers have probably cut corners and done the same thing. They’ve assumed the internal networks within the car are trusted and that no one would try and interfere with them. This arrogance is probably similar to the recent VW dieselgate scandal; “protected” by security by obscurity or proprietary code that can’t be independently reviewed. Surely the immobiliser connected to the key concept could be re-used (i.e. to prevent the car being hacked when the owner is not around - i.e. it being unlocked). As for protecting it in motion that is probably mainly beefing up development to use more secure coding practises and not assume the car is in a trusted environment?
Another consideration is that some IoT applications could be argued to be community owned. For example Smart Lamp Posts, Connected street furniture, ibeacons - who will really own these? The council? Or the residents of the street to which it lives? How will we secure and manage these devices adequately? Imagine if we can enhance local community social networking (e.g. facebook) groups with validation of actual community membership - could we then use these to manage community hardware devices? Slightly out there I know - and not exactly a problem we are facing right now but I think a few years down the line we will be.
An even more off the wall idea on this is can we create a safety net to avoid doomsday Artificial Intelligence and robot type scenarios - i.e. the AI gone bad stuff that has been a hot topic recently. This one is really interesting. Can we use community monitoring (more on this topic soon!), event processing and machine learning to detect anomalies and then use human feedback when exceptions are detected to determine whether something should be allowed or not? I guess this one falls down when its something that needs a real time sub millisecond response. ”For example, a self-driving car may, in an emergency, have to decide between a small risk of a major accident and a large probability of a small accident” is an example of this. But could it prevent an Amazon delivery drone doing something bad? Or stop someone using their drone to stalk or spy on someone? Hard baking Asimovs laws into the code (or perhaps even better the hardware) might be part of the solution as well?
I’ll stop with my random brain dumping for now, more to come when time allows…!
Originally published on LinkedIn. Comments and discussion live there.