Time and again, we hear about connected devices being hacked: security cameras, connected cars, connected toys… One of the largest DDOS attacks in history was made thanks to security camera hacking. Security is of course linked to and influenced by a much broader set of problems surrounding IoT such as interoperability, liability in case of security breaches, and threats to privacy and data protection.
Security experts advocate for better firmware, frequent updates, thorough security testing, open source software submitted to a community of security experts. All of these suggestions are useful and it is clear that software security needs to be enhanced. Open source in that respect can play a major role since many smaller companies manufacturing connected devices don’t have the resources to invest in internally designed software and have to resort to third-party software, which does not necessarily come cheap either, and might cut corners on the security side. A widely used and maintained open-source software solution might thus help keep connected devices safe. It is not by coincidence that a majority of Internet servers run Linux!
In the future, we may see software based security enhanced greatly thanks to blockchain technology, but this depends greatly on uptake by the IoT device vendors. Blockchain technology is decentralized, meaning that IoT vendors would need to give up centralized control over their devices, something that is unlikely due in part to the over-reliance on a business model centered around massive data collection which requires 24/7 connectivity. Nevertheless, blockchain technology shows great promise. In the future, IoT devices would be able to mutually check the integrity of their software/firmware which would require hackers to compromise over 50% of devices, ensure secure histories, databases and logs of IoT devices, guarantee that IoT devices carry out certain automated actions in a secure way through smart contracts (for instance, a washing machine purchasing washing powder when it has run out).
But back to the topic. Let’s look at often overlooked solution to security for Internet of Things which are rooted in the balance of connectivity and inclusion of analog features.
Balance in terms of connectivity refers to four connectivity “states” and how connected devices are configured: the offline state, local area network state, mesh state and online state. Obviously, if a connected device is offline, the chances of it being hacked goes down to zero, but that defies the purpose of the device being “connected”, right? Not necessarily.
Take a connected toy. With today’s technology, it is not difficult to host text-to-speech, voice recognition and some basic form of AI directly inside the toy with no need to be connected to the Internet. Of course, no locally hosted AI could match an AI hosted on the cloud, but still, it could provide minimum functionality, especially as the field of AI advances. Google Translate, for instance, can now work entirely offline.
Continuing with the analogy of connected toys, many of them include a functionality to record a child’s play session, but this feature only works with Internet connectivity and the recordings are directly hosted on the connected toy manufacturer’s website/servers. This is also complete overkill and a security liability. With today’s technology, it is relatively easy to set up a local area network recording (the connected toy can connect via the local home router to a hard drive and record the play sessions directly on the drive without needing to send any information on the Internet).
Moving on to connected cars, connectivity can also be more strategically defined. For instance, drivers could choose between several security options which would adjust the car’s connectivity settings. For instance, the connected car could only connect to the Internet when calculating an itinerary and once calculated, only use GPS positioning (something easy to do with Google Maps when you’re out of data: once Google Maps starts the navigation, you can disable your data and the GPS will do the rest). Of course, you won’t have real time traffic data, but in terms of security, this means that the only time a hacker can control your connected car is when you’re encoding your itinerary. In terms of other features like real-time accident monitoring, mesh connectivity can be a solution. Instead of having all connected cars talking to each other via a central Internet-based server, connected cars could send each other signals directly via so called mesh-networking. Basically, imagine that each car is equipped with WiFi or 5G that can connect directly to another car’s WiFi or 5G. So if you have a car driving in front of you, you can connect to that car, which connects to the car in front of it and so forth, creating a “mesh” and capable of sending information like speed to other surrounding vehicules. Again, this would protect connected cars from online hacking, save for a hacker driving next to your car…
Balance in connectivity thus enables to limit or strategically choose when devices are connected in order to enhance security, as opposed to simply assuming they should be connected 24/7. This strategy cannot work for all connected devices of course. Remote security cameras that need to be accessed from a distance have to be connected to the Internet. Still, thinking about balancing connectivity is essential. You could for instance have access to the video feed of a security camera without accessing the camera itself via a third-party device that locally collects the video feed but does not have remote access to the cameras.
Now about the second solution: analog features. More and more connected devices are shipped with no hardware or analog buttions, only software enabled features, which means you can only access them digitally via plugging them inside a computer, or connecting them to the local area network or via the Internet. To make things worse, some connected devices like connected cars do not even offer the digital possibility to disconnect them from the Internet, let alone provide an analog feature to terminate the connection! Needless to say that this is by far the most suicidal choice anyone could make in terms of security. Allowing the user to disable connectivity manually, via an unhackable analog button, is the safest way to ensure your device is safe if you do not need to be connected at the time of use, and is one of the best ways to interrupt a hacker’s control over a hacked device.
On top of an analog button disabling connectivity, a second analog button should enable a user to manually switch to the stock firmware/software on a non-editable medium. What does this mean? Imagine your device was hacked and the software/firmware of your connected device was tampered with (installation of a Trojan or corruption/encryption/deletion of the data enabling your device to function). You could press a button which manually switches to another non-editable storage which includes the “original”/initial version of the software/firmware running your connected device. Sure, some “new” features would not be available (since you wouldn’t have the latest updates) and there may be some “bugs” corrected with newer version, but at least, your connected device would be operational like on the first day you have bought it. Of course, before doing this manipulation, you should disable connectivity as a hacker would easily be able to hack into an older version of your software/firmware. But this could be very useful for connected cars for instance: interrupting a hacker’s remote take-over of your car and reverting back to the “default” firmware/software if the hacker managed to corrupt the data and your car would no longer function. To top it off, for sensitive devices like connected cars, the non-editable medium could be replaced from time to time when your car undergoes service at your official car dealer to take care of critical updates.
So what prevents companies from doing all that? Cost? Design problems? Sure. Any analog feature or buttons might cause costly changes to the design and build of devices. A nice connected barbie doll might not look as good with two extra buttons on it’s back, with cables running through the body… It might even have to increase in size from anorexic barbie to normal size barbie… But that’s not the only problem, especially since more and more gruesome stories of hacking and cybersecurity breach appear time and again, and users are starting to pay attention to security on top of nice design…
The deeper problem is first and foremost that companies selling you connected devices want to collect as much data as possible as it can be sold for big money! Personal data has tremendous (economic) potential for companies, and can be exploited in unforeseen ways, so companies are collecting it like crazy, hoping that someday it might turn into digital gold. To give just one of the latest examples, the Roomba creator hinted that it might sell data collected from his connected robot vacuum cleaners only to deny it a few days later… One can never know just how valuable a huge database of user data can be. And so companies have a vested interest in keeping your devices connected, 24/7, regardless of whether this creates a security hazard. Once again, the business model relying on data collection is standing in the way, not just of privacy, but also of more security.
Comments