6 IoT security fundamentals still to be solved
6 fundamental problems to solve in Internet of Things (IoT) security
IoT,Internet of Things,security,development
post-template-default,single,single-post,postid-22062,single-format-standard,stockholm-core-2.4,qodef-qi--no-touch,qi-addons-for-elementor-1.6.2,select-child-theme-ver-1.0.0,select-theme-ver-9.5,ajax_fade,page_not_loaded,,qode_menu_,wpb-js-composer js-comp-ver-6.10.0,vc_responsive,elementor-default,elementor-kit-23565

6 IoT security fundamentals still to be solved

The nice thing about standards is that you have so many to choose from;
furthermore, if you do not like any of them, you can just wait for next year's model.
- Andrew S. Tanenbaum

Internet of Things is still very immature. There is not even a consensus in what it means. It covers many different technologies like the new entrants wearables and connected household supplies, but also the very mature technologies in m2m. Vendors large and small hurry to launch products and take their stakes in this emerging markets. ITU-T standards and industry consortiums popping up everywhere that try to make some order in this chaos, but as the quote says, there are no common agreed uniform standards just yet.

So, if you start your IoT development projects today, there might not be one simple way of doing secure IoT. Different products and implementations require different solutions and strategies. A wearable will be something completely different from a connected medical device, or a Smart Home, or Smart City. However, there are some common characteristics that need to be handled as product design criterias from the start:

Product Life Cycles

How do you cope with security patches? Remote update? When the Tesla was hacked they pushed a security patch to all cars. After the Jeep Cherokee hack, Fiat quickly issued a safety recall for 1.4 million U.S. cars and trucks to install the security patch. Two very different approaches, two very different costs and inconveniences for the users.


And then there is Product End of Life. What happens when your products aren’t maintained anymore? Companies change, suppliers go out of business or get bought, product lines are closed, old standards are abandoned. But the product that should have been retired is still online doing what it was installed to do. When the connected things no longer are updated, they become more vulnerable to attacks. An immortal IoT product will eventually be taken over by hackers.


Just think about the struggles Microsoft have had trying to end support for Windows XP.


Most solutions of today are a complete product; device – cloud – app from the same supplier. Very little system integration thinking, especially when you want to mix and match solutions from different vendors. Many big players in the IoT create their own ecosystem by designing solutions for their own smart things to be able to interact.


Say you buy a home alarm system from a supplier that connect to the Internet and can be controlled with an app. Down in the basement you have a heat pump from another supplier who is also online and can be controlled via another app. Eventually, the user would end up with an app for every smart gadget, and too many apps would mean that none would be used. Take the hilarious situations with the remotes on your living room table, one for the TV, one for the sound system, one for the cable modem, one for the lighting and multiply that with all potential gadgets at home, in your garden, your car, at your office…

By agreeing on how interoperability can be solved, existing suppliers and inventive entrepreneurs can develop new solutions and apps that automate and control the myriad of sensors and gadgets, providing radically new solutions and abilities cross-vendor technologies. But this openness also opens for malicious attacks, hacking, and other criminal and destructive behavior. With all data easily exposed it would be a simple thing to know when the house is empty for burglars to enter, to stalk people and to steal their identity.


Your solution must take into consideration the whole communication chain, from the device to possible aggregation hubs and cloud storage, to the actual user that might have a mobile app. The whole chain must be protected and secure, even if the app and the devices are from several different manufacturers.

Remote control

IoT is not only about gathering “harmless” data from sensors, like temperature or an opening door. IoT will also give applications access to control real physical devices that can cause some real world damage.


What if it’s your oven that gets hacked? If you remove the safety features and turn the heat up way over max, then your kitchen, or even the whole house, burns. It might be by mistake by a hacker searching for information to steal but can just as easily be used for extortion schemes. Or even worse. As in the example of the Jeep Cherokee hack, turning off your breaks remotely is the perfect remote assassination method.

A non-secure Internet of Things will open a completely new door for terrorism and destruction.

Distributed communication over public networks

Most IoT devices will be placed outside the traditional fixed networks protected by firewalls. They will use wireless connections provided by carriers or public WiFi connections. This will put a lot of requirements on the device and the accessing applications to communicate securely over non-secure networks.


Most security technology of today is derived from the fixed network world with centralized servers talking to clients over a wire, using sessions and encrypted synchronous tunnel communication. This architecture maps poorly to the Internet of Things world.

Things will often communicate directly with other things. Take for instance a thermostat that adapts its behavior based on heat sensors in different rooms. Things will also sleep to save batteries. A device might wake up and gather some data and go back to sleep again after having evaluated that data. Radio signaling requires a lot of energy so the device will only connect and sent data when it is necessary, to save battery. This means that the communication will be bursty in its nature.


If the “listener” is also running on batteries, it should also be asleep when not in use. Neither the sending or receiving device should be required to stay awake and wait for the other one to wake up before signaling since that would reduce battery life. Ideally the communication should be asynchronous, like e-mail or messaging, instead of synchronous, like a phone call where both are online at the same time.


A secure connection will require strong encryption since the communication is outside the protection of traditional firewalls, and that is heavy on processors. Unnecessary signaling of raw data draws battery both for the encryption process and the radio connection, so if you want the device to have long battery life you need to design the device with some intelligence that makes simple decisions, like “tell the heater that this window has been opened if the temperature is below 15 degrees”.

Communication over varying connections

Another complicating factor of the wireless connection is that, depending on the device and application, the radio connection might be unstable. If your application is a sensor in a home you could probably rely on bringing your own IoT radio standard like Zigbee or Bluetooth into the application. But if you require longer distances or moving objects like a connected car your connection will be unstable and unreliable, jumping between networks. 4G, 3G, GPRS, public WiFi, etc. You will lose connection in radio shadow, and how do you manage roaming between these different network technologies, without losing data or increased security risks?

This problem is also addressed with asynchronous security and communication like discussed above, but in this case, it’s not about saving battery. It’s about having a reliable communication where information is sent and received without both end-points having to be online at the same time. The information must get through as soon as technically possible without any lost data packages.


How many routers and firewalls out there are still using the default password “password”? The vast number of common users will need to have automatic configuration and security. Remember the blinking 00:00 on the VCR? Have you set the time on your microwave? The suppliers of apps, systems and devices have to figure out how to protect the user without putting any requirement or blame on them.

You also have to provide simple but secure authentication mechanisms for all the people/systems/products accessing the device.  Without complicated setups etc.

The only security worth anything is the one that gets used. So your solution must be easy to use for the users, for the administrators and for the developers and integrators.

Many commentators described 2015 as “the year of IoT,” but so far, it has been a year of bad press. As an example, security firm Kaspersky recently ran a damning critique of IoT security challenges, “Internet of Crappy Things”.


Learn from the mistakes by others. You can do better! The challenges are tough, but there are solutions available! For advice on how to solve them, please contact us here.