Ensuring end-to-end security for embedded systems

When embedded devices started connecting to the internet routinely, the weakness of these approaches quickly became apparent. If a hacker could find the code for one device, they could use it on all devices of the same type. Hackers have demonstrated the extent of this kind of vulnerability by replacing firmware in the victim devices and recruiting them into botnets.

Although there are a huge number of vendors providing embedded security solutions, they tend to focus on a particular aspect of the system and true security can only be achieved if a solution covers the system end-to-end.  End-to-end security therefore becomes the responsibility of the designer who must think holistically to ensure all elements are considered. 

A core requirement for all embedded devices is to ensure any access to maintenance functions, at the very least, is protected by a code that is unique to each specific device. However, this is the absolute minimum. In practice, design for security needs to be far more granular and layered to prevent different kinds of attack that might be launched by hackers

Tamper-proofing and device security

Embedded system designers need to consider the many points of attack that could occur. From that analysis, they must then consider the best trade-off between protection, cost and energy consumption. Attacks may be focused on obtaining data for later use, or on compromising the functionality of a system to extort the operator, or to inflict damage directly. Each type of attack will focus on different elements of the overall system, or system of systems.

Increasingly, hackers are deploying hybrid strategies. For example, hackers will make the most of physical access to one or two devices to obtain intelligence on the operation of a system before launching a remote attack on cloud servers that will provide them with their ultimate prize. Protection against these increasingly sophisticated threats will often involve several different components from separate vendors.

All protections come at a cost – take data encryption as an example. Ideally, the data that a device handles will be protected by encryption in its three phases: when it is at rest in flash memory or cloud storage; when it is moving through a network or even across an internal system bus; and when it is in use by a processor. Each encryption and decryption cycle adds power and cost. For data at rest, it may be tempting to use very long keys to secure the contents as the time to break a key by brute force rises exponentially with key length. However, the value of the data itself may well decline over time.

Transitory temperature measurement data from an industrial sensor has limited use to an attacker unless they have access to the entire history from which they can reverse-engineer a production process. Efficient protection would put far greater emphasis on protecting data at rest in a destination such as the cloud or in a gateway used to collect data from a number of local devices as opposed to protecting data on a single device.

On the device and for delivery over the internet, lightweight encryption technology may be more appropriate and will enable the device to use a more cost-effective processor with a smaller power envelope.

With its larger power budget and greater value to an attacker, a gateway such as Schneider Electric’s FactoryCast can encrypt data to a higher level before transferring data to other servers as well as providing firewall protection to block hacking attempts from a remote location.

Higher stakes for high value data 

Other data on the device with a higher value, such as personal information about a user or anything commercially or financially sensitive must, on the other hand, be protected more extensively. One way to deliver granular data protection is by using a hardware root of trust. Software on its own is not enough to guarantee security on an embedded device because, without some form of hardware protection, it is too easy for a hacker to load their own software in place of the original code and give themselves greater control.

A root of trust provides the foundation for all protections within the device by ensuring only authorised users can make any critical changes, whether to firmware or data. In addition, it should contain the core keys used for encrypting any data the device stores or transmits that the risk assessment deems sensitive.

no circumstances should the root of trust expose private keys stored in its memory. The usage model should be one in which temporary session keys are generated and provided to other subsystems as needed on the basis that, should they be hacked, the data they protect is no longer valid or useful to a third party.

On-chip encryption

Some systems can rely on a fixed-function root of trust, which is an element that performs a specific set of functions. An example is the secure engine implemented in a number of the ST32 family of microcontrollers by STMicroelectronics. This provides services such as secure boot and secure firmware updates as well as runtime security checks and key storage.

Secure boot is rapidly becoming a vital component of embedded-system security. It helps control cost by allowing the use of standard flash memory for program storage rather than demanding all code be held in a large, expensive secure memory.

Using hashes, a secure bootloader checks the validity of code held in memory against private keys in the security component. Only if the hash of the code is valid is it allowed to run. Upon a failure, the device reverts to a known good copy held in ROM or fails to boot until a valid firmware image is restored to the flash memory. Once booted, the operating system can call on the same functions to authenticate each application before being allowed to run.

Many Arm-based devices, including those in the ST32 family, provide a programmable security engine in the form of Trustzone which allows a range of protection mechanisms to be incorporated, such as encryption and decryption of data passed over the internal system bus or over a network connection.

Security in the cloud

A further requirement for devices that are installed in the field is an ability to resist aggressive physical attacks that might compromise the root of trust. In principle, it is possible to get a root of trust to allow access to illegitimate software or release private keys by forcing it into unexpected error conditions.

Attacks may involve disruption of power and clock signals to force these errors. Root of trust implementations can employ a range of countermeasures to prevent these attacks from succeeding in releasing sensitive data or compromising functionality.

Even a well-protected root of trust on each device does not guarantee security in the context of an IoT system. A hacker could, in principle, obtain devices that mimic the operation of authentic systems, introduce them to the network and have them subvert the operation of the overall IoT application. For this reason, security of the total IoT supply chain is vital.

This calls for a manufacturing and installation flow that only allows valid devices to join and participate in a system if they have the right credentials.

It can be complex to set up supply chains that provide the ability to issue certificates to devices, and have their complementary credentials transferred into the cloud so they can be checked, when a device is commissioned.

Microchip’s Trust Platform and Microsoft Azure’s IoT Hub support mechanisms to allow such supply chains to be set up and controlled easily.

Although the threats to embedded systems continue to rise, design engineers have access to the tools with which to defend them. However, in order to provide the level of defence required, they must choose wisely from the wide selection of techniques, protocols and products on offer rather than relying on a single component.