Introduction
Internet of Things security can mean any number of things for your product and its users. This will depend largely on the context of the product and its deployment, and can include specific requirements, such as integrity, confidentiality, availability, safety, privacy, consent, authenticity, and more. Understanding how security fits into the product’s threat modelling goals will help dictate what foundational security properties need to be implemented or supported by the microcontroller that is at the product’s center.
Security is, of course, not free. It takes considerable development resources to implement security features on a product using a microcontroller. In fact, security can add up to 14% to the cost of a product that has been designed and built from the beginning with security in mind. If not planned for, this might cause the product launch schedule to be delayed. And so, while we recognize security is a significant cost, we also know that poor security could have many worse implications for both you and your users:
- If it is proven that the manufacturer did not take security seriously and customers were affected, the company may be sued by the product users. In the US, the FTC may be involved, which can have enormous financial penalties.
- Identical copies could be sold as a cheaper alternative and so the OEM’s revenue may be impacted. Additionally, if profit from hardware sales is used as a means to support a free service, counterfeiting can hurt revenue even more: service is provided, but there is no payment for it. (Note that all IoT devices that do not require a monthly subscription but do require a backend infrastructure to function, for which the OEM vendor pays, fall under this category.)
- There are also privacy implications to be considered, for both the manufacturing company and their users. For instance, a compromised camera may leak information that can be used for blackmail or can reveal to an intruder when the owners are not home. An insecure medical device might allow an intruder to attack the manufacturer’s backend and obtain confidential information about other users. In the EU and elsewhere, GDPR1, COPPA2 and similar privacy regulations may have impacts.
- Poorly secured IoT devices might cause damage to property. For example, smart sump pumps and irrigation systems might be hacked to turn them on or off, or prevent notifications to the owner which may cause flood damage.
- Insecure devices can also cause safety concerns. Animal feeders could stop dispensing food when required, injuring pets or affecting livestock. Medical devices like insulin pumps and pacemakers could be tampered with, leading to severe health consequences for users. A vehicle can cause havoc on highways and people can be injured. In the future, the safety of autonomous vehicles and smart cities will be of great concern.
- If a product can be compromised, the OEM reputation can be affected as users lose trust in the brand. Consumers may avoid products from an OEM who has had known security issues in the past in an effort to protect themselves and their data.
- If the manufacturer did not implement measures to prevent cloning, then consumers may also be affected when they unknowingly buy an inferior clone.
- A poor product experience that a clone delivers will make users less inclined to buy genuine future products from the OEM as they associate the brand with low quality and unreliability. It could also be that a clone is performing better than the original, and then again, the OEM reputation can be affected.
- The compromise of a device might aid an attacker in gaining access to other networks or resources. The intruder may bypass a perimeter firewall and other defense mechanisms with lower effort by compromising, for example, a building’s internet-enabled lobby fish tank controller. In some cases, a device compromise might lead to a compromise of other devices of the same type through the backend systems on which it depends.
- A compromised device could have its CPU resources commandeered, and become part of a botnet. Botnets are a network of hijacked devices that can be used for various nefarious purposes. The Mirai botnet performed a distributed denial of service that caused a massive Internet outage on the East coast. A variant of Mirai called LiquorBot was used for cryptocurrency mining. Other botnets, such as Kraken, are used to collect emails, send spam emails, and distribute malware.
The examples above are just a few of the higher impact eventualities. In order to truly understand your product’s security needs, a proper threat modelling exercise is needed to enumerate the critical assets that the system must protect, the attack surfaces that the product will expose, and the threats it must defend against. Translating this threat model into a set of product security requirements is one of the earliest tasks in the product development cycle, and from this you will distill those requirements that are to be implemented by, or supported by the MCU.
Threat Modelling
When designing a product, it is critical to understand the security requirements of your product in order to avoid the many problems IoT devices are facing. These security objectives need to be clearly defined. It is important to enumerate where the attack surfaces reside, as it will help understand where attacks could originate and quantify the level of risk. There are many ways to do this, but a typical approach groups attacks into categories, based on where the attackers are located, and the level of access required for the attack to succeed.
Remote Attacks
Remote attacks using wireless or LAN connections to access the device are the most dangerous.
A remote vulnerability scales well and it could be replicated to attack millions of other devices at little or no cost to the adversary (especially for devices connected to the public Internet, or accessible on a local network without any firewall rules restricting access to prevent attacks on interfaces lacking CSRF3 or equivalent protection). Using weak credentials or shared credentials across all devices or the use of unpatched software are common types of issues easily exploited remotely.
Commonly, product designers focus solely on the development of their application. Choosing a microcontroller and Board Support Package (BSP) from a reputable vendor on which to run the application is critical. Only consider vendors that follow good security practices and support your security requirements. For instance, the vendor should support secure boot and should not leave debug ports open or have secret backdoors. If third-party code is used in the BSP, only projects that are actively maintained should be included. A security conscientious vendor periodically patches the BSP and provides these updates to their customers by issuing bulletins or advisories.
Local Attacks
Local attacks where the attacker has the ability to run lower-privileged code on the device are the next most dangerous.
Some examples in this category are mobile devices, smart TVs, and automotive head-units, all of which support third-party applications downloaded from a variety of app stores (or even side loaded). Consider multi-user devices (TVs, vehicles, meeting room appliances, etc.) where users share common hardware resources, possibly allowing an attacker to execute unprivileged code on the victim’s device.
Here privilege escalation is of concern. The user of a mobile device or browser running on a Smart Display may escape the sandbox4 and take control over the platform by exploiting device vulnerabilities to obtain elevated privileges on the device. This type of attack is more difficult to protect against, as the attacker, by design, already has significant access to the system’s resources. However, using a platform that supports strong sandboxing and privilege separation together with periodic software update releases makes this type of attack costlier for the attacker and therefore less likely to succeed. The recent emergence of various micro-architectural side channel and transient execution attacks undermines the protections that are possible against local attackers on modern hardware, but the industry is working hard on mitigations.
The developers will have to define the security objectives of the product in accordance with the various stakeholders. Consider a smart TV that might be intended to run arbitrary third party Android applications and may be open to attack from a broad set of malware developers. On the other hand, a device such as a Point-of-Sale (PoS) device might only have a tightly curated set of applications. The specific threat model will dictate the security requirements. The PoS device is accessible to tens, if not hundreds of employees, in an industry with a high turnover rate. Attackers escaping the kiosk mode on the PoS could take control of the underlying OS and could launch further attacks on the company servers.
Physical Attacks
Physical attacks where intruders have access to the hardware should not be ignored despite being more difficult to exploit at scale.
Attackers could obtain targeted access to a device through various means such as evil maid5 attacks, lost and stolen devices from high-profile users, short term rentals (vehicles, AirBnB, etc.), purchasing products with the intent to modify and return to the store, and so on. Protecting against physical hardware attacks is the most difficult. However, there is a relationship between the cost the product manufacturer is willing to pay to improve the product security and the cost the attacker needs to pay to successfully carry out the attack. Simply using a microcontroller that requires vendor-signed firmware might be only a slight increase to the cost of the product, but it represents a significant cost for an attacker that now needs to defeat the cryptographic signature verification mechanism. Similarly, a system that encrypts the external storage might cost a bit more, but now attackers need to first defeat the encryption before they can extract secrets. Of course, an indoor thermometer and a self-driving car will have different security objectives and risks. The former might not justify the extra cost, but the latter could benefit from strict objectives that clearly state to what level the product should be hardened against physical attacks.
Sample Threat Modelling Exercise
Here, a generic threat model of a typical product is presented. The readers are encouraged to adapt it to their own product specifics as this model is not by any means complete. For instance, some devices use microcontrollers that may support external memory or external flash. On other devices, no external components may be required as the microcontroller includes everything needed. In this situation the attack surface may be reduced as some physical attacks may be more difficult to achieve. Additionally, some systems may lack privilege separation and run the firmware in privileged mode on the bare metal. A vulnerability in the user application may allow the compromise of the entire device firmware. Despite differences such as these, the threat model presented here should be a good starting point.
In the diagram that follows, the red boxes represent critical assets that need to be protected from attackers. The dotted lines represent trust boundaries where the level of trust changes. The three types of attacks listed above are represented by arrows, showing how an attack can evolve. This will be further discussed in this section.
Following the data flow, let us go through the typical paths of attack developers should defend against. The threat model shows a remote attacker taking control of a user process. This could be due to vulnerable software listening on an externally accessible network port. Alternatively, if the attacker is in a privileged network position and the normal traffic is not encrypted/authenticated the attacker could intercept and modify the data transmitted and gain code execution in the user process. In both situations, a successful attacker would be limited to the resources available to the user process. Sometimes the hardware resources are the asset that the attacker is interested in, as the device can be leveraged as part of a botnet. As such, attackers may stop after they take control of a process remotely.
Alternatively, attackers controlling a process or a lower-privileged user account could perform a local attack, escape the sandbox and compromise the OS. With full access to the OS platform the intruder may attempt to pivot towards the secure enclave, TEE6, external TPM7, or any other isolated environment in order to extract secrets. If the attacker has physical access to the device, the attack surface widens considerably. For instance, keys or sensitive data stored in memory may be extracted through a variety of invasive means. For example, a device may follow all the best practices that make a local or remote attack difficult, but leave the flash unencrypted. Attackers could remove the flash and read it offline to obtain user credentials, software intellectual property, and counterfeit-enabling device identities. Interposers could also be used to send malformed data over I2C, SPI, or any of the internal communication channels in order to compromise the kernel drivers or the device firmware. To ensure such hardware attacks are not possible, external components must be integrated carefully and external communication channels should be encrypted and authenticated.
Conclusion
We’ve shown that internet-of-things products designed with no security considerations have real world implications. People can be injured or killed, privacy can be affected, and businesses can lose money and damage their reputation. More and more, security-conscientious OEM vendors use certification programs such as ioXt8 and AVS9 to show their consumers that they are committed to creating secure products and to providing support through software updates.
Don’t Forget To Be Awesome!
I’d like to thank my colleagues Nick Galloway, Jeremy Boone and Rob Wood for their insightful suggestions and feedback provided when writing this blog.
Abbreviations
