This blog has been reproduced by kind permission of ARM – founder members of IoTSF. Whether you know it or not, you are benefiting from ARM technology every hour of the day. ARM is the worlds leading semiconductor intellectual property provider and are at the very heart of our digital world – from phones to storage to automotive and so much more.
This blog post, originally posted here on the ARM Connected Community by Jim Wallace, covers a number technical factors to consider in IoT security.
Simply put, security for Embedded IoT devices is about protecting assets from malicious attack. Typically this protection is thought about in terms of keeping some assets, such as crypto keys, secret and controlling how software and data is modified. In order for the Internet of Things (IoT) to be successful it is important that devices and services are appropriately protected.
As IoT products become successful they will become increasingly attractive for attackers and so appropriate security must be baked into every system and at every level. This will require a scalable “building block” approach where designers can use established security approaches that can scale from low cost microcontrollers through to high performance application processor based systems.
However, understanding how to protect devices, data and services can be an overwhelming task for developers who are new to security and who must focus on other challenges such as battery life, form factor and user interfaces, just to name a few.
The Internet of Things is vulnerable to attack from many angles
The above diagram shows the breath of the attack surface along with some of the vulnerabilities that can be exploited within connected systems. These can be categorized as:
- The network attack surface
- Every point of network interaction from the end device nodes to the server is a potential part of the network attack surface.
- The software attack surface
- All running code has the possibility of having exploitable vulnerabilities – from the end device, through the network and all the way to the server.
- The physical attack surface
- If not protected, an attacker can gain the highest level of access to a device through physical attacks. This can be in the form of debug probing or more invasive hardware attacks.
Attackers have the privilege of selecting where to attack so we need to think carefully about countermeasures across the entire system.
Security is a balance between economic cost and benefit
Given enough time, money and expertise any system can be hacked, so it is important to design a system to deter an attacker by making it uneconomic (i.e. the cost or effort of an attack far outweighs any benefit to an attacker).
Types of attacks can be classified in terms of investment, the type of attacker and equipment used. These range from:
- Expensive invasive attacks (such as reverse engineering, or sophisticated micro probing a chip)
- To lower cost:
- passive software attacks (exploiting unintentional security vulnerabilities in the code)
- communication attacks (e.g. exploiting weaknesses in the internet protocols, crypto or key handling
Hacks can be categorised by the cost and effort involved
Security is always a balance between economic cost and benefit, dependent upon the value of assets on the one hand and the cost of security features on the other. The success of the Internet of Things will depend on data and services being protected, and when the security balance is right, it can open up new opportunities and markets.
So how can we relate to the needs of a secure application or service?
Secure digital payment
One way is to consider an example so many of us perform; a digital payment transaction. If you are paying by credit card, smart phone or over the web, you are a participant in a secure application. As a card holder or in the case of mobile phone payment with NFC, you are the holder of a unique identification linking what you have in your possession to your ability to pay. During the payment process there is a confirmation of the parties involved in the transaction. Payment networks are built to provide assured service, for example, supporting transactions without a network connection. The networks involved are protected by strong firewalls and the communication between all stages of the transaction are protected by strong cryptography. Secure content is also managed as records of the transaction are protected. In addition, to protect the most critical data in the payment application, there is tamper resistance built into the devices.
Requirements for secure digital payment
A great deal can be learned by considering payment applications, the associated standards and the ARM® powered ARM Processors that are essential to supporting these solutions. Unfortunately, as we can see from numerous reports on data breaches, we also learn that this high value transaction is subject to attacks. With a direct link to a financial benefit, attackers seek out every opportunity.
IoT devices are hugely diverse
IoT covers many applications and includes everything from wearable fitness bands and smart home appliances to factory control devices, medical devices and even automobiles. These market segments have many different types of IoT devices from ultra-low cost battery powered devices with tiny sensors that can last years to hub and base station devices that can act as an aggregation point, providing connectivity to the cloud and are normally connected to the mains power.
IoT devices are different from one another in almost everything: their hardware, their operating system, their type of software, their level of assurance, and their ability to support different security protocols.
Devices can be highly varied across architecture, software and security capabilities
The type and level of security applied in a device will vary according to the functionality of the device and the impact that an exploited device can pose. In the ultra-low cost segment, some devices may not require the capability to have their software upgraded, may not enable any third party software to be downloaded and may not store sensitive data; hence, the security applied may just involve locking down debug ports and encrypting the data on the radio link between the client and the host. Many more devices within the segment will have link encryption, hardware backed trusted execution environments, secure data storage, root-of-trust, and device security lifecycle management.
Even though a device may appear to be simple, and therefore require minimal security, the level of security applied and the impact on the system of a device being hacked must be considered. A good example of this is a simple connected light bulb. At first consideration the value of exploiting this would appear low, however looking deeper, if an attacker were able to take command of thousands of light bulbs, the impact of turning these on or off at the same time could potentially bring down the power grid. Equally, if an attacker were able to access crypto keys from a simple device the attacker may be able to use these to attack other parts of a system.
ARM and the ARM partners are building layers of security (hardware & software) into IoT devices, balancing cost and security across these segments.
Three key areas that need to be considered are device, communications link and product lifecycle.
Device security
Trust starts with devices that have hardware based trust anchors (known as roots of trust), a trusted boot process to get those systems into a known good state and layers of hardware and software based security that can be used to protect assets of differing value.
These secure devices need to
- Protect themselves and recover from untrusted software attacks through isolation, ensuring untrusted code cannot access these secure domains.
- Prevent attackers from accessing or copying data, with on chip memories to protect firmware from theft and cryptography to encrypt and decrypt the data.
- Provide anti-tampering techniques. The level of technique applied will depend on the value of the asset. Typical techniques aim to detect if an attack is occurring and then react to correct that attack. An example of this is to block external access to a non-trusted debug request and/or wipe secure memory spaces once an attack is detected.
Communication security
We also need to ensure the link is secure and trusted devices can connect to the cloud via encrypted links using standard internet protocols (such as TLS – Transport Layer Security, which is the security protocol used for https transport). Consumers will be familiar with this widely deployed technology from the padlock symbol used to secure their online banking. This prevents eavesdroppers (man in the middle) listening by providing the encrypted link between the trusted end point and the cloud.
Using key management the identity of endpoint device can also be authenticated on the server before it is allowed access to the services.
Software lifecycle security
During a product’s lifecycle the device will go through a number of updates: from its early days in the factory, where the silicon manufacturer and OEM will inject root of trust keys in ROM or eFuse technologies, to its initial boot up with the consumer, to the many over-the-air (OTA) updates ensuring the firmware is kept up-to-date and secure.
To ensure the device is protected from malicious software attack all software images need to be authenticated before they are used in the system.
Software provisioning, such as OTA updates, require a trusted process of authentication
Software is protected and authenticated through a process of code signing which digitally signs a software image to guarantee that the code has not been altered or corrupted. To do this, an OEM or service provider first generates an RSA public key and private key pair.
The private key is used to sign the original image and is never shared with the device. The public key is programmed into a secure eFuse or ROM block within the device. This forms a core root of trust.
Once the device receives the signed image, it then compares the decrypted original public key to the signature and, if the values match, the code is considered authentic and the new code is used in the boot process.
These steps within the trusted boot process are also used to ensure any firmware updates are validated throughout the life of the product. For firmware updates the new public key is verified with the original public key before the signature is compared and the result authenticated.
Security across all of the IoT
For IoT to succeed, we need to consider security as a system problem: how the high value keys are provisioned and protected? How is critical software authenticated and isolated? How is the device managed over its life-cycle? Which security communications protocol is being used to protect data in-flight? We also need to think about what is an appropriate level of protection given the value of the assets and the use of the device.
Given that many IoT devices will be designed by non-security experts we also need to ensure the solutions to these problems are easy to implement and scalable across different use cases. Fortunately, ARM and its partners are creating easy to use hardware and software building blocks that can provide the security foundations for the next wave of connected devices.
When security is implemented across the cloud, it opens up new business models
About the Author
Jim has 29 years of managing consumer marketing and business development, engineering and business units across a number of hi-tech semiconductor companies, including GEC Plessey Semiconductors, Mitel, Philips, Zarlink and CSR. Jim joined ARM in 2006 and is currently VP Strategy for the Media Processing Group.
Special thanks to Donnie Garcia from Freescale Semiconductor for his contribution to this blog.
Donnie has held various roles in his semiconductor career related to embedded processors including applications support, systems engineering and product marketing. He currently works as a solutions architect for payment and access applications.
Here at IoTSF our mission is to unite the efforts of diverse IoT stakeholder groups to raise the bar on security. That’s a truly noble and worthwhile cause – and it’s also a mighty tall challenge too. It’s such a huge task, that we can only meet our vision of safety of connection by working with many, and prioritising our efforts.
Click here to see what our Working Groups are focused on to help make it safe to connect.
Disclaimer:
The views and opinions expressed in this article are those of the authors and do not necessarily reflect the official policy or position of the IoT Security Foundation.
