Cloud Services Provide a Path to Embedded Security
Internet connectivity provides the means to add huge value to embedded systems, yet that same connectivity can be a threat to the integrity of devices and the IoT applications that are being built using them. By using smart design techniques, it is possible to turn this situation around. With the right foundations, internet-connected embedded and IoT devices can leverage online services to provide long-term security and protect the network, even if individual nodes are, at some point, compromised. Achieving the required level of security is complex but solutions are now appearing that provide a package of measures and facilities that address the different threats: an example is Microsoft’s Azure Sphere and its embedded Pluton security subsystem.
Hardware essentials for IoT Security
A
fundamental requirement of IoT device security is one of system integrity. The device must be protected against unauthorized modification and intrusion. Hackers are resourceful and will exploit any weaknesses they can identify to try to compromise a system. Layered security is a means by which OEMs can reduce their vulnerability to successful attempts to compromise part of a system. For example, the buffer overflow is a commonly exploited mechanism used to penetrate a system and works by taking advantage of the layout of data in memory. Oversized network packets can lead to code provided by the hacker being stored outside the memory allocated to network buffers and then be inadvertently executed by the target system. From the hacker’s perspective this provides a point at which they can upload a new executable image.
Once the device has been rebooted so that it can execute that new image, the hacker then has complete control over the system and access to secrets and other valuable data.
A secure-boot mechanism provides the means to close this and other attacks down by ensuring that only the executables provided by an authorised party are able to run. A basic requirement for implementing a secure-boot mechanism is an area of non-volatile memory that is treated as read-only after manufacture – this contains bootloader code that forces the processor to check the boot image loaded into the system for integrity. If it fails the integrity check, the device will not boot until it is provided with a boot image that is valid.
The simplest mechanism for an integrity check is some form of checksum. However, this does not check the boot image for origin. A counterfeit boot image could still potentially pass the integrity check if the hacker knows how to construct one based on a manufacturer ID or similar shared code thought to be secret. Users can achieve a much more effective integrity check: one that combines manufacturer IDs with the device’s own by ensuring that code loaded into flash for use in the next boot is signed with a hash generated using a unique ID stored locally. To protect against attacks that might be used to find this ID, the device would also need to have a hardware root of trust.
Hardware root of trust
The hardware root of trust is a protected area for running security-sensitive operations which would provide protection against physical tampering and remote attacks. To provide such protection, the root of trust implements a secure processor that has sole access to on-chip code and data memory. Encryption keys and other secure data are stored in these areas and the root of trust is configured to never allow access to these elements from outside. The secure processor is often supported by a cryptographic processor to speed up those operations and a true random number generator (TRNG), which is used to generate software and systems running outside the root of trust to determine whether they should have access to system resources. An example of a hardware root of trust is the Pluton security subsystem implemented as a core part of the Azure Sphere Module that is available through element14.
With a hardware root of trust in place, a device has the potential to not only secure itself and any data it sends, but demonstrate that it is a legitimate device sending credible data to other nodes on the internet, whether they are other IoT devices or servers in the cloud. This, in turn, helps improve security as devices can refuse to engage with any networkconnected that do not have acceptable credentials. This reduces the potential for buffer-overflow and similar attacks to get through in the first place. Pluton also enforces security within the system to control the action of peripheral devices that may themselves be compromised. Firewalls within the processor prevent unauthorized accesses to sensitive functions and attempts to take over a system using, for example, counterfeit peripherals.
Attestation is the mechanism by which software or remote devices can prove their identity or authenticity. Typically, this attestation is handled with the help of protocols based on public-key infrastructure (PKI) mechanisms. Under PKI, messages are encrypted using public keys, which can be distributed freely without compromising the protocol as only the corresponding private key can decrypt the message. Such private keys are those that will be stored in the hardware root of trust’s secure memory and are typically loaded during manufacture.
Security for communication
When the device wants to establish communications or prove its identity, it will use protocols to generate certificates and signatures using one or more of those private keys. The signing and certification protocols combine random values, ideally created with the help of a TRNG, with the private key to create values such as session keys, which are used once for short periods before being discarded to avoid the possibility of hackers intercepting messages and recreating them in socalled replay attacks. Once created, PKI protocols ensure a private key need never be accessed outside the secure area.
In the case of Azure Sphere, two core private keys are generated by the Pluton subsystem on the device itself during manufacture and cannot even be directly read by software afterwards. All messages derived from the private keys are created by the cryptoprocessor within the Pluton subsystem.
This overcomes a key weakness in many systems where the private keys are generated externally and programmed into the device which opens up the possibility of interception.
Any device can generate private keys and store them internally. The next issue is determining whether the keys are valid when the device first appears in the network. Azure Sphere achieves this by generating matching public keys: one for attestation and one for user-defined secure services. These public keys are provided at manufacturing to Microsoft for use by its Azure cloud service. Also stored in the device are digital certificates generated using PKI mechanisms that are used to check messages purporting to come from Azure servers.
When an Azure Sphere device connects to the cloud, it verifies the identity of the server by checking messages against the Azure-created certificate it stores in secure memory. At this point, the device needs to authenticate itself to the server, a task achieved using a remote-attestation protocol. In the Azure Sphere system, it is not just the device that is identified but the code it runs. This is performed by creating a session key based on the cryptographic hashes of the code sequences found during the secure-boot process. These values are signed with a private key for attestation generated by the onboard cryptoprocessor. As the Azure service can generate a corresponding public key based on the device’s public key that it holds in its database, it can verify the devices identity that it has booted using authorised firmware.
The availability of a cloud service to authenticate devices has other benefits: under the Azure Sphere, for example, when a device is found to be authentic and running the correct software it is provided with a certificate that, when used in conjunction with its own stored credentials, can be presented to other online services and devices to prove identity. The certificate is valid for roughly a day, which limits the potential for attacks and the device will be forced to demonstrate its health on a regular basis if it wants to maintain a connection to IoT services. This is a level of protection that standalone cannot experience because, if they are compromised by a physical attack, they cannot be fixed without a manual maintenance check.
If the device does not pass the secure boot process, the client device cannot obtain a certificate that will let it perform as a valid, authenticated system and it will be cut off from the IoT and unable to function in a manner that is useful to the hacker. Furthermore, failure to authenticate provides a means to rectify the situation and the device may be allowed to connect to the Azure services in order to download and install an authentic and up-to-date boot image. This provides an additional level of protection against attacks that exploit weaknesses in older versions of the authentic firmware.
Though support for internet connectivity is now practically a requirement for many embedded systems designers, the threat that poses can be controlled. Through platforms such as Azure Sphere, internet connectivity provides a more robust solution than would be possible with unconnected devices.
