“Attack surface reduction” is a security principle that you can use to guide your choices when designing an IoT product or service. The attack surface of a hardware or software environment is all of the different points where an unauthorized user can try to insert or extract data. Keeping the attack surface as small as possible is a basic but necessary security measure. 

With IoT, there’s two surfaces you’ll have to contend with. The thing itself, say an internet-connected temperature sensor, and the communicating service - whether that’s Adafruit.IO, Google Cloud, or Microsoft Azure.

Let’s start with device security, starting from the easiest first, here are ten-plus guidelines for device security. Again, this isn't everything, but it’s an excellent start.

#1 Require a login and password - this is number one because it's the bare minimum. Don’t have an open, network-accessible interface to your IoT device. You may think “oh nobody is going to guess the URL, or the port number” but that’s the first thing hackers will find out! Even if its on an intranet, require some authentication!

#2  Don’t have default logins and passwords - we mentioned this before but it bears repeating because it’s so common! Make sure your device has a unique, unguessable password by default.

#3 Two-factor authentication - In addition to a username and password, maybe have an SMS or time-based second factor. This will protect you even when if the password is sniffed or stolen. 2FA is free and pretty easy to implement these days - you no longer have to distribute a physical token, since everyone has a mobile phone.

#4 Require TLS/SSL - Whenever your users or devices connect to the internet, whether over WiFi or cellular, use the latest available version of TLS, sometimes called SSL or HTTPS. TLS will encrypt all data transmitting between the device and the service, protecting both. This will greatly reduce your risk of sniffing. A few years ago, microcontrollers were older and smaller and couldn’t effectively run a TLS stack. Nowadays, there’s no excuse to skip it.

#4.5 Authenticate Host Certificates - TLS is not just data encryption, it's also server authentication. So, if you’re using TLS, make sure your device is checking the fingerprint or certificate chain of the servers it's connecting to. We’ve seen some TLS implementations where it's possible to skip this, which makes man-in-the-middle attacks possible.

#5 Turn off any unused services - If you have an embedded Linux or RTOS for your device, make sure there are no services left on. File sharing, remote login, mail servers, etc. These days, most of these are not enabled by default, but check anyways. Sometimes these are left on during development, and are forgotten when the firmware makes it to release.

#5.5 Don’t accept any inbound connections - If you can, don’t allow any way for outside parties to connect into the device. If you have a debugging port left open that’s just another surface that can be attacked.

#6 Require physical access for important configurations - We’ve seen some WiFi cameras that can be controlled over the internet, but if you want to change the access point password, you need to plug it into a computer and change the setting over USB. This reduces the surface that can be attacked by automated scripts.

#7 Individualized/Revocable Authentication Keys - In order for your device to connect to the service, chances are it has some sort of authentication key or password. As you remember from earlier, make sure that you have a unique key or password for each device - even if the user never sees these, you shouldn’t reuse them. You’ll also need to have a way to revoke/re-instantiate keys if they’re lost, corrupted or stolen.

#8 Data Paranoia - Even though you may be only shuffling data from your IoT device to your IoT service, don’t trust that the data is well formatted. This is often forgotten in the rush to complete and ship firmware, but you should assume that attackers will try to send corrupted or malformed chunks of data to both sides of the connection to corrupt memory. Clean up and vet data fully, this will also keep your device running smoothly if the network connection is flakey.

#9 Updatable Firmware - Bootloaders are the best, and it's a good idea to have one on your device. There are many that are write-only so that the deployed firmware can’t be read back out. Being able to update firmware will help customers recover the device if it gets bricked, hacked, or if there’s an important security update. We like USB bootloaders the best, or ones where you insert an SD card with a file. Having updatable firmware increases your attack surface a bit, because it gives another access point into your device, but we think that if someone has physical access, they could connect a JTAG programmer to erase and reprogram it anyways. 

#10 Secure storage for authentication keys - Embedded Linux devices have a regular filesystem, and microcontrollers often store their code in flash memory, so even if you hard-code authentication keys in flash or EEPROM, it can be read out. Yes, even if you have a chip that has firmware-readback turned off, it’s possible to glitch chips into revealing their secrets. Your microcontroller memory should not be considered a secure storage! Instead, you may want to consider using a secure element chip. These chips are designed to withstand common decapping and glitching attacks and can be programmed with the private key at your factory. Then, it never leaves the secure chip. Instead of having the key sit in microcontroller memory where it could be read out, data that needs to be authenticated or encrypted is sent back and forth through I2C. It’s a little extra BoM cost but is a nice way to keep the secrets in a lock-box.

#11 Over the air updates - This one is a little tricky. Not having OTA is risky because then there’s no way to send important security updates. On the other hand, having OTA is risky because, if hacked, it allows the attacker to completely take over the device. We think OTA is a good idea, but you definitely need to combine it with the prior rules - firmware must be transmitted over an authenticated, encrypted connection. Having firmware be signed with public key cryptography (so the private key is not stored on the device) is a common idea, but be aware that private keys can leak out.

We’ve seen more than one company accidentally ‘brick’ their devices with a mistaken OTA update, some even required a physical recall - so if you do have OTA updates, make sure you always have a way for physical-access-rollback. And do lots of slow-rollout deployments, so you don’t end up with a mistake that affects everyone.

#12 Have a Security Contact - This is last but it’s actually super-easy. Make sure that your website has a way for folks to contact you if they think there’s a security problem. There are lots of amateur and expert security researchers who are also your customers, or potential customers. Many eyes can make flaws obvious, and many will let you know if they find one. Don’t let those emails go unread - have someone who is an assigned security contact, who will read and respond to any bug reports. Small gifts and rewards can encourage responsible disclosure and will motivate smart folks to help you out.