How to Design Your Homebrew IoT Solution With Security in Mind
If your garage project has a chance of hitting shelves, you’ll want to keep your users safe from the start.
You are a tinkerer. You want to build things, which you do at home in your garage. You dream of your device, the little BLE-enabled-chip-that-could, becoming a wild success on Kickstarter — plastered all over TechCrunch and on The Verge. All is well — until your customers flock to social media en masse with that dreaded phrase on their fingertips: “I got hacked.”
As of right now, there is no such thing as being unhackable. Security is a best effort attempt at getting an attacker to sit back and say, “This is too hard. I’m going to give up.” Unfortunately, the ease with malicious information can be found via the internet makes being on the offense all too easy.
It feels like the current state of security in IoT exists because of a widespread lack of awareness around potential vulnerabilities — possibly due to the hobbyist nature of the space. There is an evident lack of engineering refinement in the bulk of wearables and home automation products currently on the market. A 2017 IBM sponsored survey indicated that a whopping 80% of IoT apps were not tested for security flaws.
So, why is IoT lagging so much? Enforcing security in web and on mobile applications is a well-trodden path. Solutions are widely known, and they can often be integrated by simply dropping a library into a given service or software project. Interestingly, the traps are very much the same for embedded systems. The difference is that there is less shared knowledge around preventing common methods of attack, primarily in the non-enterprise space.
With that all said, let’s jump into some solutions.
A quick primer: understand the value of the info you’re storing, and how it can be compromised.
Skip this section if you know the basics of cybersecurity.
There are a few questions you may want to ask yourself before you get started with your prototype: What is your system about? What sensitive data will your user be sharing with it? What happens if this information gets leaked or corrupted? Even if the answer to the latter is “nothing”, you still may want to think about how to protect any data on your device.
Attacks boil down to four main categories.
- Disclosure of data — the leakage of sensitive data to an attacker
- Spoofing of data — the faking of sensitive data to yield a particular result. This could be done to impersonate an authorized entity, and sensitive data may or may not be leaked in the process
- Corruption of data — the obfuscation of sensitive data by an attacker such that it can no longer be used
- Denial of service — the overloading of a system’s input devices or mechanisms such that it is not able to service all requests, to the point that it is rendered unresponsive
In order to determine the right solutions and bake them into your product from the start, you’ll want to think about the following principles.
- Confidentiality — keeping sensitive data secret. Solutions here involve encrypting sensitive data.
- Integrity — ensuring that sensitive data is not modified in flight. Solutions here involve hashing sensitive data.
- Authenticity — verifying that the sender is who he/she claims to be. Solutions here involve generating unique encryption keys in order to maintain the confidentiality of each user or entity in a given system.
So, how can these areas of vulnerability be addressed on an IoT device? It helps to think about your system as a graph of links and nodes, and assess vulnerability to attack per unit. Can sensitive data be retrieved from your device’s memory? Can sensitive data be intercepted via the Bluetooth or Zigbee requests that are being made? What about when data is on the bus between the device’s CPU and another component?
I realize this advice sounds suspiciously like “learn about security in general”. Which it is. You will not be able to protect your device, and ultimately your users, in any manner if you do not have a basic understanding of how an attacker might compromise your product.
The good news is, should you be interested, that there are hundreds of academic and applied security courses available online, such as this one on hardware security offered by the University of Maryland.
Start with your hardware.
Basic single-CPU IoT devices do not often have the resources to protect themselves adequately. Unlike larger devices, such as phones, laptops, or consoles, they’re often built with smaller and weaker chassis, and do not always have the computing power necessary to generate complex keys or encrypt data performantly. Luckily, there are some workarounds that are accessible to the amateur IoT enthusiast.
Protect your device from physical vulnerability
Sometimes, just having physical access to device is enough to attack it. Cold boot attacks, for example, rely on the data remanence property of DRAM and SRAM to retrieve memory contents that remain readable in the seconds to minutes after power has been removed. This means an attacker can read sensitive data or encryption keys from your device’s memory by cycling the device’s power on and off.
There are a variety of other side-channel attacks that an attacker can choose to execute on, such as DMA attacks (if a given component has direct memory access), bus sniffing, and so on.
A solution here is potentially to make your chassis uncrackable, which… is possible but extremely difficult. You could also require in your instructions to install the device in a high place, or somewhere out of sight, but this is highly dependent on the type of product you’re intending to build.
In the very likely chance you are unable to make an impregnable device, you could consider integrating a hardware cryptography component into your design.
Integrate hardware crypto solutions from the start
Why are hardware cryptography solutions so great? They’re what I would call the hardware version of “that security lib I dropped into my Android project and now everything just works great”. The benefits here are measurable:
- Offloaded computation — On many offerings, you can perform key generation, encryption (AES, RSA, ECC), hashing (SHA), signing, string compares for password checks, and so on, on this secondary device. This alleviates resource usage on the main CPU and means that no keys, plain-text, or even temporary variables, are stored in main memory.
- Secure key storage — If keys need to be reused, they need to be stored somewhere safe. A number of offerings come with their own secure storage just for keys, meaning that the keys themselves are encrypted on the storage device. Yes that’s right. Your encryption keys will be stored encrypted.
There a variety of offerings from companies like Intel and Atmel, such as the Atmel ATECC608A, and they usually come with the benefit of their own dedicated secure EEPROM arrays for key storage. This also means you can ensure that anything stored in main memory or travelling over a bus is not plain-text!
These solutions often utilize SPI or I²C to communicate with whatever micro-controller it is hooked up to, so if you are unfamiliar with these bus types, you may want to double-check which type supported by your board.
Even if all of this sounds intimidating, there’s no need to worry! Many hardware cryptography solutions can easily be hooked-up to Arduino, Raspberry PI, and other enthusiast boards. And the the benefits of doing so certainly outweigh the costs.
Realize entropy and power are not on your side
I recognize that not everyone is able to include a hardware encryption solution from the start, be it due to cost, lack of confidence, or lack of expertise. But, if for some reason you cannot integrate any type of cryptography chip, you should still keep in mind that small embedded systems can have real issues with gathering entropy.
Why is entropy important? Encryption relies heavily on randomness to generate strong keys. Unfortunately, we are yet to generate true randomness with computers, and so we have to look to a variety of sources to provide a random seed or to fake randomness for us. Small embedded systems are especially bad at this, as they are often very simple devices with short boot times, and keys are often one of the first things a system may generate.
This is why hardware cryptography solutions are so useful; they are usually equipped with inputs to provide enough entropy to generate sufficiently strong keys.
Pick encryption algorithms that fit with your specs.
Whether you pursue a hardware or software security solution for your device, it helps to know what algorithms you actually need, so you can properly assess if your system can support it.
If you know a little bit about security, you’ve probably heard of symmetric and asymmetric cryptography. The way they work that is implied by their names: symmetric cryptography requires all parties to utilize the same encryption key, but asymmetric cryptography relies on different parties using different keys that mathematically complement each other.
While it’s natural to think, by these definitions, that symmetric key cryptography is easier to crack, they are somewhat difficult to compare, as symmetric and asymmetric cryptography were developed for different purposes. Symmetric encryption is used to protect information and keep it private. Asymmetric encryption was developed to authenticate a user or computer, verify a message is authentic, and/or distribute symmetric keys.
A common symmetric key library used in small IoT devices is AES-256. However, you might want to consider using lesser known encryption algorithms like ChaCha20, which is twice as fast as AES, constant-time, and much more CPU-friendly. If code size is an issue for your application (for example on very low end Arduino variants), then Speck on AVR is less than half the code size of ChaCha, at the cost of more data memory for the state and longer key setup times.
If you need to use public key (asymmetric) encryption, consider using Elliptic Curve Cryptography. ECC is very popular right now, for good reason. It uses smaller key lengths than those used by older schemes (RSA, DSA) to achieve the same given security level. This is great for small devices, because it provides the increased complexity of asymmetric without as much “effort” on the part of the device.
Don’t let your prototype become what you ship.
In a sense, the Arduino-ification of the electronics enthusiast space has not helped, though I am personally happy that its popularity has made electronics more accessible to the average person. And I am no different here. My first board was an Arduino Duemilanove. The first PCB I designed myself used an ATmega328 with Arduino Optiboot that I got on sale from Sparkfun.
The problem is that many small indie wearables or device makers ship with Arduino (or similar boards), and often use the Arduino language or other tools that come with the ecosystem. Unfortunately, everything about that ecosystem is known. The schematics are known. How information is stored in memory is known. The reality is, you never know how an attacker will take advantage of this knowledge.
Security often sounds difficult to implement on low resource IoT devices, given the limitations of flash memory and processing power, but once you have developed a good sense for the types of information that need protecting and how your device would handle them, the path to safety becomes a little more intuitive.
