What is the problem with IoT security?

It used to be just computers – desktops, servers and laptops – that were connected to the Internet but now almost everything has the potential to be online. From cars to door sensors, with everything in between, there are now an untold number of devices with Internet capabilities.

According to some research there will be over six billion connected devices in use worldwide by the end of 2016 and by 2020 that number will reach 20 billion. The reason all these devices are being put online is so that they can send information into the cloud where it can be processed and then used in some useful manner. You want to control your thermostat from your phone? Easy! You want to have security cameras which you can check while you are away? OK, as you wish.

However there is one problem with all of this connectivity, the link flows in two directions. If a device can send data up into the cloud, then also it can be contacted from the cloud. And this is where the issue of security arises. If a hacker can control IoT devices then chaos ensues.

"Securing a system has traditionally been a battle of wits: the penetrator tries to find holes, and the designer tries to close them" - Morrie Gasser, Building a Secure Computer System.

And that is what we saw recently when cyber-criminals launched a Distributed Denial of Service (DDoS) attack on Dyn, a DNS provider for Twitter, SoundCloud, Spotify, Reddit and others. A DDoS attack aims to disrupt Internet services (like websites) so that users can access them. This brings frustration for the users and potential financial loss for the website. The reasons these attacks are 'distributed' is because they use multiple (like thousands or tens of thousands) of computers across the world in a coordinated attack. Traditionally these computers have been Windows desktop PCs which have been infected with malware. At the right time the malware is activated and PC joins a 'botnet', a network of remote machines (bots) which stage the attack.

DDoS attacks aren’t new, however there was something very special about the attack on Dyn, this one was launched not via PCs, but via connected devices like DVR security cameras or network-attached storage devices. According to security expert Brian Krebs a new piece of malware was recently developed which scans the Internet for IoT devices and tries to connect to those devices. If a device allows some kind of simple access using factory default username and passwords then the malware connects and inserts a malicious payload.

And here we get to the crux of the matter. Way too many connected devices grant access over the Internet using default usernames and passwords like admin/admin or root/root. Now the reason for that is simple, inept software. One of the characteristics of the IoT market is that the devices need to be cheap, at the consumer end at least. Adding Internet connectivity is a selling point, maybe a gimmick, but certainly a unique proposition. However adding that connectivity isn’t just about running Linux (or an RTOS) on a processor and then adding some web services. Done correctly the devices need to be secure. Now adding security isn’t hard, but it is an extra cost. The foolishness of a short term view is that skipping the security makes the product cheaper, however in many cases it can make it more expensive.

Take the example of the Jeep Cherokee. Charlie Miller and Chris Valasek famously hacked the Jeep Cherokee using a remotely exploitable vulnerability. They told Jeep about the problems but Jeep ignored them. What Jeep actually thought of Miller and Valasek’s research is unknown, however not much was actually done about it. However once the details of the hack were made public then Jeep was forced to recall over a million vehicles to fix the software, which apparently cost the company billions of dollars. It would have been much cheaper to do the software right in the first place.

In the case of the IoT devices used to launch the Dyn attack, the cost of the security failures isn’t being borne by the manufacturers, but by companies like Dyn and Twitter.

IoT security checklist
In light of these attacks and the current poor state of security on the first generation of IoT devices, it is essential that IoT developers heed the following checklist:

• Authentication – Never create a product with a default password which is the same across all devices. Each device should a have a complex random password assigned to it during manufacturing.
• Debug – Never leave any kind of debugging access on a production device. Even if you are tempted to leave access on a non-standard port using a hard-coded random password, in the end it will be discovered. Don’t do it.
• Encryption – All communications between an IoT device and the cloud need to be encrypted. Use SSL/TLS where appropriate.
• Privacy – Ensure that no personal data (including things like WiFi passwords) is readily accessible should a hacker gain access to the device. Use encryption for storing data along with salts.
• Web interface – Any web interface should be protected against the standard hacker techniques like SQL injections and cross-site scripting.
• Firmware updates – Bugs are a fact of life, often they are just a nuisance. However security bugs are bad, even dangerous. Therefore all IoT devices should support Over-The-Air (OTA) updates. However those updates need to be verified before being applied.

You might think that the list above is only for IoT developers, however consumers also have a role to play here by not purchasing products which don’t offer high levels of security awareness.

"The mantra of any good security engineer is: Security is not a product, but a process. It's more than designing strong cryptography into a system; it's designing the entire system such that all security measures, including cryptography, work together." – Bruce Schneier

There are solutions
The initial reaction of some IoT developers (and probably their managers) is that all this security stuff is going to be costly. In one sense yes, you are going to need to devote man hours to the security aspect of your product, however it isn’t all up hill.

There are three ways to build an IoT product based on a popular microcontroller or microprocessor like the ARM Cortex-M range or the ARM Cortex-A range. You could code it all in assembly code. Nothing stopping you doing that! However it might be more efficient to use a higher level language like C. So the second way is to use C on bare metal, meaning you control everything from the moment the processor boots. You need to handle all the interrupts, the I/O, all the networking etc. It is possible, however it is going to be painful!

The third way is to use an established Real Time Operating System (RTOS) and its supporting ecosystem. There are several to choose from including FreeRTOS and mbed OS. The former is a popular third party OS which supports a wide range of processors and boards, while the latter is ARM’s architected platform which offers more than just an OS and includes solutions for many of the different aspects of IoT. Both are open source.

The advantage of ARM’s solution is that the ecosystems covers not only developing software for the IoT board, but also solutions for device deployment, firmware upgrades, encrypted communications, and even server software for the cloud. There are also technologies like uVisor, a self-contained software hypervisor that creates independent secure domains on ARM Cortex-M3 and M4 micro-controllers. uVisor increases resilience against malware and protects secrets from leaking even among different parts of the same application.

Wrap-up
The key to IoT security is to change the mind-set of the developers and to inform consumers of the dangers of buying insecure devices. The technology is there and there is really no barrier to getting hold of that technology. For example, during 2015 ARM bought the company which made the popular PolarSSL library just so it could make it free in mbed OS. Now secure communications is included in mbed OS for any developer to use free-of-charge. What more can you ask for?

I don’t know if some form of legislation is required in the EU or in North America to force IoT OEMs to improve security in their products, I hope not, but in a world where billions of devices are going to be connected to the Internet and in turn somehow connect with us, we need to ensure that the IoT products of the future are secure.