IoT Security Foundations

In this blog post, we will discuss what makes up the foundations of security in IoT, and begin a series of articles that will provide focused overviews on select topics within this field. We will focus on the client or device side of IoT, rather than the server or service side, since that is where some of the most unique challenges lie.

Security in IoT has been a hot topic ever since the ‘Internet of Things’ became a buzzword. Security – broadly speaking the ability to build, deploy and operate connected computing devices without external interruption or abuse – has been successfully achieved in other ecosystems, namely the mobile, PC and server industries. Beginning in the ‘90s when many systems first became globally connected, great security efforts were undertaken, and continue to be undertaken, by the companies providing these successful ecosystems. These efforts are essential to close off the countless ways through which attackers can take over a system. This need for security is often overlooked or prioritised in many IoT products, resulting in the current situation, which some have called a ‘back to the ‘90s’ – where computing devices are being recklessly connected to the public internet without installing proper security features first. This tendency enables easy break-ins, which combined with the wide scale of IoT has led to the latest wave of attacks creating massive, high-profile botnets such as Mirai.

Some of the reasons why IoT security tends to be poor can be traced to the IoT supply chain. This is often more complex than that of the closely related mobile and ‘traditional’ embedded industries. An IoT product or service is made up of multiple software, hardware, connectivity and cloud elements, all stitched together using components from different vendors. Business interests dictate the priorities of all parties, and currently, security is often left at the bottom of the list when it comes to choosing components. Badly outdated and insecure components proliferate, leaving attackers with a wide attack surface. Given its significance, we will examine the IoT supply chain in an upcoming article.

Security concepts begin with discretionary access. Once you have an asset of value, you must let the right ones in and keep the wrong ones out, and if you fail to do so, you lose your asset. The same is true for physical security (installing a front door) as for digital security (installing a login screen). Digital systems use authentication – users must prove who they are before accessing the device. Despite the obviousness of the concept, and a ubiquity of available solutions, many IoT devices have failed at authentication. Many of the highly publicized attacks of 2016-2017 spread without using any sophisticated exploits, rather by entering devices through the unlocked front door – via a hard-coded administrative password put in by the device maker, which was in many cases to guess (such as ‘abcd1234’).

Authentication is followed by authorization – assigning different users and software components different rights on the device operating system. By necessity, users must be authenticated first. Following this, access rights should be granted to users on a ‘least privilege’ basis, i.e. each user should be able to access the functionality they need, and not more. It is common in the world of IoT to only define one user per device, which effectively gives that user ‘root’ permissions – full access to the device’s abilities. This leads to attackers who manage to take over a minor part of the device functionality (such as a router’s web interface) gaining full control of the device. In most cases, it makes sense to use authorization to separate the critical device functionality, such as the device’s main intended function, from less important service functions such as web interfaces. Sensitive functionality such as device identity and key storage can be isolated as well, if possible using hardware security features. User-installed applications should run under separate accounts and use operating system isolation mechanisms. Authorization should be part of the device’s design from the get-go, as it’s harder to add as an afterthought.

Auditing is an important concept, which combined with authentication and authorization makes up the ‘triple A’ of security. Keeping an audit log of security-relevant events allows after-the-fact detection of attempted or successful attacks, such as repeated authentication attempts with wrong credentials, or violations of authorization policy. Devices can keep an internal log of events, but limited device storage makes that expensive, and attackers with physical access may tamper with logs in storage. It is simpler to report audit events over the network to the device’s management service, but this incurs a communication cost instead, and attackers with control of the network can usually block communications. Hence, auditing is costly and difficult, and because of that it is often overlooked or even left out completely, resulting in devices infected with malware happily chugging along on private and public networks, their owners blissfully unaware.

In the digital world, security is impossible without cryptography.  Cryptography provides the basis for digital authentication methods, and is necessary to protect data in transit (transmitted in network communications) and data at rest (stored on device). Cryptography is widely available to IoT developers and is easy to deploy thanks to open-source libraries, but is often applied without proper understanding. Symmetric cryptography is usually within reach for even the most constrained devices, but asymmetric cryptography is often avoided due to its higher computing and power consumption requirements – often to the detriment of the overall security design. Outdated algorithms continue to proliferate through legacy code, where sound alternatives have been available for years. Finally, without proper key management, cryptography can provide little more than a false sense of security.

Key management is strongly tied to cryptography and device identity. For the device to identify its users, and any servers or services it connects to, it needs to hold credentials. Key management concerns include key generation, establishment and import, storage, renewal and destruction along the different device life cycle stages. Device keys can be initialized during secure manufacturing, or created using a source of randomness. Whenever two parties connect, they can perform key establishment or key transport protocols to obtain shared keys needed to secure the conversation. Once created or established, credentials can be used to authorize peer devices, online services and human users. Credentials may need to refreshed or replaced, including, in many cases, by remote operators. Any system that strives to be secure from more than casual attackers must use some form of secure key storage. Finally, credentials may need to be erased or revoked when necessary. Some of these issues present challenges unique to the IoT setting, which we will discuss below.

Randomness is vital for cryptography; it is used for more than just key generation. Without a good source of randomness, devices cannot establish secure TLS sessions, leaving their encryption keys vulnerable to cracking by network attackers. Randomness requires a source of entropy. While regular computers and mobile phones can harvest some entropy from their environment and user interaction, these sources are usually too limited on an IoT device. Some manufacturers opt to provide a hardware random number generator, while others avoid the overhead. Workarounds exists, such as using an evolving seed injected in secure manufacturing, but that must be done with care to avoid some severe pitfalls.

Protection for data at rest is needed for stored device configurations and audit logs, any sensitive data that is stored on the device, and often for the device’s code as well. Attackers with physical access to the device’s storage should not gain easy access to the user’s sensitive data, including credentials and any application-specific data that may damage the user’s privacy. Encrypting the data raises the bar for data retrieval, however the encryption key would have to reside on the device itself, so the complete solution must include some form of secure key storage.

Code integrity – protecting the device code from modification – is a different concern. If the device code were able to be modified in an unauthorized manner, subverting its function or causing other harm, no one would be able to trust it – neither the user, the vendor or the service operator. Code integrity is usually achieved by a secure boot mechanism – using a smaller, physically protected component such as a bootloader to verify the larger, less secure system components (such as the system kernel, operating system in general, and potentially all the applications installed thereon) before they are brought up.

Code integrity ties in closely with software updates. The necessity for software (or firmware) update mechanisms in IoT comes up often, as most security breaches found in deployed IoT devices can only be resolved by updating the software of the operating system and various application components. In addition, some IoT devices (such as smart meters) are intended to serve for decades at the customer site or in remote locations, during which time communication protocols and security building blocks are expected to change. A remote software update mechanism is required to achieve this in a practical manner.

Many of the security concerns mentioned above need hardware security features to be fully addressed. Software on the device can be exploited remotely and is easier to hack than hardware, and without hardware assistance, software break-ins grant the attacker full control of the device. The features most in need of hardware protection are device identity and secure boot. This can be extended to fuller secure storage functionality, with protection for other credentials and keys, and the added ability to perform cryptographic operations on those keys without software involvement. Other hardware security features include a persistent clock, which helps check other entities’ security certificates, and some form of rollback protection, without which the software update mechanism and other components are left vulnerable.

The device lifecycle should be addressed as it touches on many security concepts. Device security begins with secure manufacturing, where the device receives its initial identity and the public credentials for the services it will work with. Once the device leaves the manufacturing floor, any debug interfaces it has must be securely closed off for access to authorized personnel. Some devices are additionally equipped with return-to-manufacturer functionality, which leaves the device testable but removes any assets installed by its users. Additional important lifecycle features are the ability to change device ownership, remotely manage enrollment in services, etc. IoT devices, more than mobile phones and unconnected embedded devices, are expected to be transferred between owners and service providers.

We will address physical tamper protection briefly. This concept is well-addressed by the industry, which manufactures and standardizes highly tamper-proof products, such as Secure Elements, Trusted Platform Modules and Hardware Security Modules. The use of such modules has not yet caught on, at least on the device side of IoT, due to hardware costs. Some hardware security features are available in a variety of IoT offerings, however in today’s ecosystem we see IoT devices being hacked using much simpler and more primitive approaches. As long as IoT software remains widely insecure, tamper protection features will remain irrelevant as the pragmatic attackers will continue to choose the easier path.

We leave privacy for last. An important concept that is often overlooked or exploited by unscrupulous vendors, privacy should be one of the design goals of any IoT system. It is easy to see how security features such as data encryption at rest and in transit can assist in achieving privacy, but we will also review how it ties in with authentication, auditing and the device lifecycle.

With this series of articles, we hope to start an initial discussion of the basic IoT security challenges, and attempt to cover the foundational issues. This will be used as a basis later when discussing more specific topics.