Introduction

We live in exciting times from a technology perspective. The dreams of a “connected life” are becoming realized, and many ordinary products are being provisioned with internet connectivity to enable this new world of convenience. However, the internet can be a dangerous place, and securing these newly-connected products against threats is essential. Otherwise this unrivaled convenience could turn into a nightmare. As system designers, we have a responsibility to be a part of the solution to delight our end-users and be good stewards of their data and peace of mind.

One of the challenges with Internet of Things (IoT) product development is that security is difficult. A secure product must defend against every possible attack, but attackers only need to find one weak link to exploit a system. They also have the advantage of time: attacks always get better, not worse, and computational capacity, tools and the knowledge of how to use them are becoming cheaper and more widespread. In addition, the standard pressures of cost, time to market, size and customer convenience cause many designers to implement quick, expedient, or simply incorrect or incomplete security provisions.

This article focuses particularly on small wireless connected systems that are often battery powered and running a lightweight, low-bandwidth RF protocol such as Bluetooth Low Energy (LE), Bluetooth mesh, Zigbee, Thread, Z-Wave, LoRa or proprietary ISM-band protocols. Most of the challenges and solutions presented here are common to larger systems (smartphones, laptops, etc.) as well. (See Figure 1.)

Design for Resilience

Before getting into the details of what can go wrong, it’s helpful to plan that something will go wrong: vulnerabilities and bugs will be discovered and will need to be addressed. Provision the system with a secure firmware update mechanism, ideally with signed, encrypted, and versioned upgrade packages and an update manager with rollback protection. Also provision secure boot with hardware root of trust to ensure that only authorized code can run on your product.

Don’t Make Your Own Security Protocol

When faced with a security need, combined with potentially limited device resources (code space, battery life, lack of crypto accelerators) and limited time, many embedded designers opt to design their own security protocol, rather than adopting a suitable industry-proven solution to satisfy the security requirements. Unfortunately, it is easy to propose a system that appears unbreakable, and far more challenging to identify the flaws in such a design.

Creating a secure connection requires verifying the authenticity of the remote end of the link, encrypting the messages, and verifying the integrity and authenticity of the messages delivered over the link.

A Transport Layer Security (TLS) session used by a web browser to secure an “https:” connection between a user and his/her bank addresses all these security requirements. Bank website authenticity is addressed by using certificate-based public-key cryptography; confidentiality is implemented using symmetric cryptography; and integrity is addressed by message authentication codes.

Establishing a TLS connection on a small embedded processor may seem overkill. Fortunately, there are other lighter-weight established standards, such as DTLS (used in Thread), that can be adopted instead.

One of the most flexible tools to manage device authenticity is the X.509 certificate coupled with a public key infrastructure (PKI). This allows devices to be authenticated using the same cryptographic tools and methods as the banking website example above. The certificate contains some device-specific information such as a unique ID, a validity period, cryptographic algorithm information, as well as company name and other data. The certificate is signed by a company’s private key (which is strongly protected) but can be verified by a public key that anyone can access. Furthermore, if a device or private key becomes compromised, the certificate or a family of certificates can be revoked, limiting the scope of damage.

Injecting unique device certificates into products or devices may seem burdensome or expensive, but many MCU and SoC suppliers, distributors and third parties offer these capabilities as part of their device customization and pre-programming services at modest cost due to the high demand and prevalence of need in IoT.

Most standards-based RF protocols such as Bluetooth, Zigbee, Thread and Z-Wave already have prescribed, or at least recommended, ways of establishing a secure authenticated link. All these protocols provide a means to establish a confidential transport channel, and designers should absolutely take advantage of the security features offered by the protocol. Some designers may want to add additional security on top of the transport layer to provide authentication support or application-level encryption.

Common Vulnerabilities

In 2014, researchers from MIT surveyed the most common vulnerabilities logged in the Common Vulnerabilities and Exposures (CVE) database between 2011 and 2014. They categorized the sources of the vulnerabilities between the crypto library and the application. It is interesting to note that only 17 percent of the cryptography vulnerabilities were found in the crypto library, and the bulk of the vulnerabilities (83 percent) were in applications that used the library incorrectly. One way to minimize vulnerability exposure is to choose the right crypto library. No library is completely free of vulnerabilities or bugs; however, a library that is open source, actively maintained, and whose maintainers follow best practices of vulnerability disclosure is probably a good start. The mbed TLS library is one such example that is also optimized for use in resource-constrained IoT systems.

The MIT students separated the vulnerabilities into four different classifications: Plaintext disclosure, Man-in-the-middle attacks, Brute-force attacks and Side-channel attacks. We will review the common cases that apply to IoT products.