Securing the embedded IoT world

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 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)

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.

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.

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

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 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.

Source: Arm Community