When we talk about IoT, privacy and security come directly to the minds of the users. Yet for developers, this isn’t always an obvious issue. Most of the time we’re just trying to figure how to get things to work properly, then security comes as a secondary concern.
Embedded devices are the base on which your IoT infrastructure is relaying for the low level sensors and controls. This could go from motion sensors, light sensors, GPS, etc…
Embedded devices and IoT go together like peanut butter and jelly (or like spaghetti and meatballs if you like). Indeed, embedded devices are efficient, low powered and we have had them for so long that we basically understand them perfectly now.
These embedded systems can be placed outdoors, with a battery and some wireless connectivity and you basically forget about them for a couple of years. With this particular use-case come some specific security requirements.
Being an embedded system is like being that distant cousin that inherits all the bad family genes but none of the money. Embedded systems are basically miniaturized computers, thus they inherit all the common security problems from servers, desktops and mobile devices. And even though securing data on embedded systems is inherently similar to securing data on severs, there are some exceptions.
The specificity of embedded systems, is that they’re low power and low cost, leaving us with limited resources to execute our programs on, CPU, RAM and battery are valuable and for each different project they impose different constraints on the designers and developers. Sometimes, security libraries that are used server-side won’t fit or won’t be available for your particular architecture. Other times, it is just too expensive to secure every request using non-optimized code.
If your device needs to communicate, a crypto library is a must. You’ll need a library with a small footprint and preferably designed for embedded systems.
Your boss, or you (if you’re really an idiot with a big ego) might think that you can do the encryption and deception of the data with your own code that could be more optimized than the libraries out there.
YOU DON’T ROLL YOUR OWN CRYPTO
Hardware Hacking … also called debugging
Debugging is a crucial part of the code’s life-cycle. As developers we need debugging interfaces in order to test and understand possible problems within the embedded system. And even though these interfaces shouldn’t be left after the prototyping phase, they’re sometimes too useful or too expensive to remove.
Some just try to cover them with the casing or blow a fuse, but this will only deter a small percentage of attackers, more determined ones will work around this.
Over-the-Air Firmware updates
When a bug is found and you need to update an app running on your sever, all you need to do is to SSH into it, run a couple of scripts and –instantly- all your users will be on the latest version. On mobile it’s a bit different, you push your update to the store and you wait for the users to accept the update, it sure causes some versioning trouble when your back-end has to keep supporting all the old versions of your app.
Now imagine that same mobile devices problem only 1000x times worse, and with no users to download your update, because your device could be in the bottom of an ocean or in millions of homes with no screen or keyboard. Are you going to send a team to fetch each device or are you going to email all your clients and issue a massive recall?
It is better to spend a couple of months implementing a feature that allows you to remotely push updates and authenticate them. Again, public key crypto is your friend.
Secure Firmware Updates over the Air in Intelligent Vehicles is a good read.
This is admittedly an “advanced” attack but a very possible one for outdoor devices. This usually requires the attacker to probe input/output pins fishing for any useful information.
The most basic form of this attack can be countered easily using fake/dummy pins. These pins need to be monitoring any input generated by the attacker plugging something into the embedded device. When a rogue input is detected the device could shut-down or send an alert to HQ reporting and preventing any unauthorized activity.
More advanced I/O scanning attacks could be preventing using techniques like sealing the casing and detecting openings (think portable credit-card readers and RSA SecurID).
Long story short…
Securing embedded systems is not an easy task, it requires deep hardware and software knowledge. Most approaches are common, but some are project-specific and require even more attention de details and weird use-case scenarios.
This is not a comprehensive guide, if you can think of another attack vector for embedded IoT devices, leave a comment below.