Anatomy of a secured MCU

Secure silicon

Azure Sphere is an end-to-end solution containing three complementary components that provide a secured IoT platform. They include an Azure Sphere microcontroller unit (MCU), an operating system optimized for IoT scenarios that is managed by Microsoft, and a suite of secured, scalable online services. Microsoft provides over a decade of support for the operating system as well as use of the security service for a single per device fee to simplify business planning.

Microsoft built its name in software, but our expertise in silicon runs deep. Over the last 15 years, Microsoft has deeply invested in hardware-based security by designing custom silicon for various Microsoft products. Azure Sphere’s silicon architecture is a culmination of all those years of experience, and our Pluton Security Subsystem is the heart of our security story. In this blog post, I’ll drill down a layer to discuss what puts the “secured” in a secured Azure Sphere MCU. Specifically, I’ll dive into Pluton’s design details, as well as some other general silicon security improvements.

Broadly, any MCU-based device belongs in one of two categories – devices that may connect to the Internet and devices designed to never connect to the Internet. Until recently, virtually all MCU-based devices were disconnected, which led to a security model that considered the value of the device, the physical threat model (Is the device locked in a cage? Does the general public interact with it?), and the risk of the device being attacked (e.g., an automatic paper towel dispenser versus an MRI machine). Therefore, security had a simple model – pay more, get more.

Connecting an MCU-based device to the Internet is a watershed moment because any MCU can become a potential general-purpose digital weapon in the hands of an attacker. The Mirai botnet was composed of only 100,000 connected cameras. If you’ve never thought about a distributed denial of service (DDOS) attack launched by 100 million paper towel dispensers, consider this blog post your moment of clarity.

Internet connectivity means that the table stakes for security must be changed. We authored the white paper on the seven properties of highly secured connected devices to reset the conversation around security. However, Azure Sphere certified MCUs go beyond a typical hardware root of trust used in an MCU.

Pluton Key management

Pluton generates its own key-pairs in silicon during the manufacturing process. Other secured chips often depend on a hardware security module (HSM) on the factory floor to generate keys. Pluton goes further by generating its keys privately in silicon, and then persistently storing those keys into e-fuses. The private keys are never visible to software. Even the most trusted firmware on the device does not have access to the private keys. Pluton generates two different public/private elliptic curve cryptography (ECC) key-pairs. One is used exclusively for remote-attestation (more on that later) and the other is available for general purpose cryptography. The chips’ public keys, but not the private keys, are sent to Microsoft from the silicon manufacturer, which means Microsoft knows about and establishes a trust relationship with every Azure Sphere chip from the point the chip is manufactured.

Pluton’s random number generator

Pluton implements a true random number generator. Pluton’s random number generator collects entropy (i.e., randomness) from the environment to generate random numbers. This random number generator is critical to each MCU generating its own keys during the manufacturing process and is therefore a critical attack surface that must be defended. Pluton’s true random number generator measures the entropy it collects, and if the entropy does not meet a certain standard defined as part of its design, the random number generator refuses to deliver random numbers.

Pluton’s cryptographic helpers

Pluton accelerates common cryptographic tasks. Pluton accelerates cryptographic tasks such as hashing (via SHA2), ECC, and advanced encryption standard (AES) cryptographic operations.

The benefits of secure boot

Pluton minimizes supply chain risk. ECDSA is an algorithm for checking digital signatures with ECC key-pairs. Every piece of software on an Azure Sphere device must be signed by Microsoft. Microsoft uses its own proven signing infrastructure, the same infrastructure that protects the private keys of some of Microsoft’s most valuable products, and therefore ensures that private keys are kept in secure HSMs and that every use of this key follows a strict and documented process.

Leveraging remote attestation

Pluton implements support for measured boot and remote attestation in silicon. When an Azure Sphere device connects to the Azure Sphere Security Service (AS3), it completes server authentication by using a locally-stored certificate. However, AS3 must also authenticate the device itself. It does that via a protocol called remote attestation:

1. AS3 sends the device a nonce, which is combined with the measured boot value that consists of the cryptographic hashes of the software components that have been booted.

2. The device signs these values with Pluton’s private ECC attestation key and sends them back to AS3.

3. AS3 already has the device’s public ECC attestation key and can therefore determine whether the device is authentic, was booted with genuine software, and if the genuine software is trusted.

It is critical that this measured-boot value cannot be forged or changed; therefore, it is kept in an accumulation register that can only be reset if the entire chip is reset. Since signing happens in silicon, even a device with fully compromised software cannot forge an attestation value.

4. If a device is up to date, it is given a client certificate that can be presented to any online service and an AS3 certificate that is used only with AS3 services. If the certificate chain is valid, it represents AS3 vouching for the health of the chip. The certificate is valid for roughly a day, which means the device is forced to attest to its health on a regular basis if it wants to maintain a connection to the Internet.

If the device is not healthy, the client certificate is not issued, effectively allowing the device to connect only to AS3 and perform a software update.

Silicon-based attestation with continual renewal prevents device impersonation and forgeries. A future blog post will provide a more thorough deep dive on this topic, but it all starts with Pluton.

Silicon security beyond Pluton

Security doesn’t stop at the silicon fabric that makes up Pluton. In fact, Azure Sphere MCUs go beyond Pluton by implementing additional security features that improve the platform’s defense in depth strategy. Let’s use the MT3620, a chip composed of five cores, as an example. One core is dedicated to the runtime that invokes operations within Pluton. Next is a core dedicated to Wi-Fi that interacts with the Wi-Fi RF components of the chip. The A7 core is dedicated to running the Azure Sphere operating system, and two M4 cores are available for real time processing. The A7 core leverages Arm’s Trust Zone technology, the Azure Sphere security monitor runs in Secure World, while the Linux kernel and other OS components run in Normal World. 

Between all the cores and peripherals are what we call “firewalls.” These are not firewalls in the network sense, but instead a set of mappings of resources to cores. In fact, internally we call this the core mapping feature. All resources on the device are mapped this way and by default all resources (A7 SRAM, peripherals, and flash) are mapped only to Secure World, denying access to software executing in Normal World. Secure World can selectively grant access to peripherals, and those selections are “sticky.” Sticky is not a term you often see when discussing silicon. In this case we mean that a core mapping is “locked” once set, which means that even if an attacker compromises the code that programs the firewalls, the attacker cannot get access to resources that were not originally assigned to the core in which it’s executing.

Limited peripheral access reduces the surface area that could potentially be subject to attack. Sticky selection further reduces the surface area. After the device is deployed, an attacker cannot exploit the code to communicate with a rogue web service or to control another part of the device. The result is greater security for individual devices as well as through the entire supply chain.

These are just a few of the silicon features that make an Azure Sphere MCU unique, and that make it more difficult for an attacker to take control of an Azure Sphere device. Each additional feature provides one more complication that an attacker must overcome to compromise a device’s functionality, and Pluton provides a rich set of silicon security features that are not often present in a hardware root of trust. Microsoft believes in the benefits of Pluton so strongly that it is licensing Pluton, royalty free, to any silicon manufacturer that wants to make an Azure Sphere chip. Better security is not foolproof, but raising the bar in IoT makes it that much harder to compromise a device.

Source: IoT