Today’s lightning-fast, increasingly interconnected world provides us with the opportunity to dramatically add value to the embedded systems we use every day. However, that same connectivity can also become a threat to the integrity of the IoT applications and devices that are part of the foundation of embedded systems. The solution? Smarter, more secure design. Once a solid foundation is in place, internet-connected embedded and IoT devices can ensure long-term security and protect the network, even if individual nodes are compromised. In order to achieve the required level of security, multiple threats must be anticipated and addressed: a great tool for achieving this is Microsoft’s Azure Sphere and its embedded Pluton security subsystem. 

IoT Security Essentials

An essential requirement of IoT device security is ensuring that the system is integrated properly. Since hackers are notoriously resourceful and will be happy to exploit any and all weaknesses, the device must be protected against unauthorized modification and intrusion. Smart OEMs can reduce their vulnerability to compromised systems through layered security. For example, one commonly exploited mechanism hackers use to penetrate a system is buffer overflow. It allows hackers to take advantage of data stored outside the memory and allocated to network buffers, which can sometimes cause the code to be inadvertently executed by the target system. From the hacker’s perspective, this is great news. Not only does it provide a point at which they can upload a new executable image, but once the device has been rebooted so that it can execute that new image, he or she has complete control over the system and access to valuable data.

A secure-boot mechanism is a great way to avoid this problem. It provides the means to close potential attacks by ensuring that only the executables provided by an authorized 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. An effective integrity check 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

Security is increasingly becoming an important issue for all members of the design community. For example, in a recent road test review, element14 community member David Long notes the Pluton security subsystem’s root of trust implemented as a core part of the Azure Sphere Module, available through Newark, as one of the key features.

The hardware root of trust is a protected area for running security-sensitive operations. It provides protection against physical tampering and remote attacks by implementing 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.

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 IoT devices or servers in the cloud. This, in turn, helps improve security as devices can refuse to engage with any network-connected devices that do not have acceptable credentials. This also reduces the potential for buffer-overflow and similar attacks to get through in the first place. The Pluton security subsystem helps to control the action of peripheral devices that may themselves be compromised. And Firewalls within the processor prevent unauthorized accesses to sensitive functions and attempts from would-be hackers to take over a system using counterfeit peripherals.

Software or remote devices can prove their identity or authenticity through attestation. Typically, this 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 so-called replay attacks. Once created, PKI protocols ensure a private key never needs to 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 during manufacture and cannot even be directly read by software afterwards. All messages derived from the private keys are created by the crypto processor within the Pluton subsystem. This compensates for a key weakness in many systems where the private keys are generated externally and programmed into the device, creating the possibility of interception.

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 crypto processor. As the Azure service can generate a corresponding public key based on the device’s public key in its database, it can verify the devices identity that it has booted using authorized firmware. 

The availability of a cloud service to authenticate devices has other benefits: under 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 the device’s identity. The certificate is valid for roughly one day, which limits the potential for attacks and forces the device to demonstrate its health on a regular basis in order to maintain a connection to IoT services.

If the device does not pass the secure boot process, then it cannot obtain a certificate that will let it perform as a valid, authenticated system and will be cut off from the IoT. 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. 

element14 community member Rodrigo Sim describes the Microsoft Pluton security subsystem as the base of the Azure Sphere ecosystem, noting that Pluton has a dedicated core used to accelerate cryptographic tasks like hashing with SHA2, Elliptic-curve cryptography (ECC) and AES encryption. All this allows Pluton to provide secure boot and remote attestation for base OS and user applications. The dedicated core can also control access of peripheral in other cores.

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.