The future is weird: we used to protect our privacy by shying away from microphones and webcams. Nowadays, we install them everywhere and call them Siri or Alexa.
As the Internet of Things (IoT) continues to proliferate, infusing itself into everyday objects, it’s up to developers to build devices that don’t sacrifice consumer security nor privacy.
Update – Build a Secure Update Mechanism
If NASA can remotely update the Mars Expedition Rover from over 30 million miles away without bricking it, your IoT device should also be capable of being updated across the Internet in a secure manner without turning the device into an expensive paperweight.
A secure update mechanism ensures that only authenticated and authorized updates are allowed to be installed on the device. These requirements are typically implemented via a code signing mechanism.
Prior to applying the update, the device will compute the cryptographic hash of the update to ensure it hasn’t been corrupted in-transit. The update package could be updated in-transit due to transmission errors or a man-in-the-middle (MitM) attack, where an attacker intercepts the connection and sends his own malicious update package, with the intent to install malware or otherwise steal sensitive data.
While you may not think this is a big deal, remember how much of your personal information is stored on these IoT devices to make them function the way you like (to make them so “user-friendly” and “helpful,” that is).
In order to prevent these types of malicious attacks, an update’s signature must be verified against the computed hash and the certificate examined to ensure only updates signed by the specific manufacturer is allowed.
An in-depth signature verification will also validate the certificate authority which signed code signing certificate is on a trusted white list. Certificate authorities have failed in the past and issued fraudulent certificates to malicious actors. Narrowing down the list of trusted certificate authorities mitigates the threat posed by rogue certificate authorities.
Passwords – Don’t Embed Passwords and Credentials
Passwords suck and there’s no way around that, but until devices can auto-magically identify valid users, we’re stuck with them. Anything embedded in your device should not be considered secret.
Don’t make the problem worse by embedding passwords or credentials in your device. You’re just guaranteeing your device to a life of enslavement to a botnet.
Require the administrators to set a password during the device setup and choose a sane password policy such as the one outlined by NIST SP800-63B.
Anything embedded in the device should not be considered secret: don’t burn in any credentials such as passwords, encryption keys, API keys, and secrets for attackers to find. Just don’t do it.
Disable – Deactivate Services and Debug Headers
Linux provides an attractive option for rapidly prototyping and building an IoT device. There’s nothing wrong with using Linux as a starting point. However, care must be taken to disable any unnecessary services such as telnet, FTP, and SSH. Starting out with Linux will require you to include it in your update plans as your IoT device will now inherit bugs from the underlying operating system.
On the hardware side, disable the JTAG, UART, or other debugging ports to prevent attackers from accessing these interfaces to debug and reverse engineer your firmware or extract secrets. The key is to reduce the attack surface to the bare minimum.
Attack – Perform a Penetration Test
A penetration test against the product will provide validation of the effectiveness of the security engineering. Additionally, a pair of fresh eyes from an offensive background will help uncover blind spots in the device’s security.
Consider engaging with a red team at the start of the project instead of the end. After all, fixing code while it’s still in development is easier, cheaper, and faster than attempting to fix code after it’s been shipped.
Send your developers off to a hardware exploitation class such as Software Exploitation via Hardware Exploitation to expose them the offensive side of security to give them an idea how IoT devices are ripped apart by reverse engineers. As a developer, it helps to begin to think like an attacker in order to protect consumers using your IoT device.
Transparency – Be Transparent in Vulnerability Handling and Disclosure
There’s a lot of goodwill to be earned from the information security industry based on how you manage the vulnerability disclosure process.
Much of the research is conducted as a hobby to satiate our ever-inquisitive minds and you’ll likely receive vulnerability reports from independent security researchers across the globe. Responding to a vulnerability report with a legal order is definitely the wrong thing to do.
Bug bounty platforms such as HackerOne and Bugcrowd provide an excellent portal for interacting with independent security researchers.
Publish the vulnerability disclosures to empower consumers to take the appropriate steps to protect themselves so they’re not fighting against attackers while hindered by asymmetrical information.
Encryption – Encrypt Data In-Transit and At Rest
It’s 2017, there’s no excuse for not encrypting data in-transit and at rest. Consumers are starting to understand the value of their data and privacy. IoT devices are at significant risk due to the sensitive nature of the data that can be recorded such as health metrics, geolocation, voice conversations, and even video.
The typical argument against encryption is the performance penalty overhead incurred. While that may have been true decades ago, chip performance has improved exponentially and new lightweight encryption algorithms have been developed to address the constrained processing power of IoT devices. There really is no more room for excuses against encryption.
Man-in-the-Middle attacks are no longer the exclusive capability of nation state intelligence agencies. Wireless interception devices like the WiFi Pineapple have made WiFi MitM attacks easier than ever.
The proliferation of free WiFi has trained consumers to blindly connect to any open access point, ensuring your IoT devices will more than likely end up on an unprotected connection making transport encryption even more important.
Likewise, there’s no excuse for not using SSL/TLS. The Let’s Encrypt project provides free SSL/TLS certificates for everyone in order to create a secure Internet. Don’t forget to perform signature verification on the devices and implement certificate pinning to thwart attackers from using arbitrary certificates to MitM the device’s connections.
If developers begin to take charge of building security into their IoT devices from the start, rather than as an afterthought, we’ll all win: security practitioners, manufacturers, and consumers.
