This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
A rollback attack is a common type of security attack in which an attacker tricks the target into running an older, less secure version of its software. Once the insecure software is running, the attacker can take advantage of its vulnerabilities. With thousands of field-deployed devices, Azure Sphere represents a likely target for such an attack. Azure Sphere uses two main strategies to prevent such attacks: one-time programmable (OTP) fuses and attestation.
One-time programmable fuses
OTP fuses can serve as circuit breakers that are built into the hardware. On Azure Sphere, the Pluton security subsystem contains several such fuses, which use the e-fuse technology. To stop trusting (and running) all previous versions of the OS, Azure Sphere “blows” an e-fuse upon update to a particular release. During OS installation, the bootloader compares the number of blown e-fuses on the device to the number expected for the OS being installed. If more e-fuses are blown than the software expects, the software must be too old, so installation fails, and the last known good version of the OS is run instead. The number of e-fuses available in Pluton is limited. Therefore, we blow them only when necessary.
Attestation requires that every Azure Sphere device prove every 24 hours that it is running valid, trusted software and is an authentic Azure Sphere device. When a device connects to the Azure Sphere Security Service, it provides an attestation value that combines a hash value from each loaded binary and additional data from the device with a nonce from the Security Service. The attestation value is signed using a device-specific private ECC attestation key that was generated when the chip was manufactured. The key is stored in Pluton, is used exclusively for attestation, and is inaccessible to any software. The Security Service has the corresponding public key, so it can verify that the device is authentic. The Security Service uses the binary hashes and additional data to verify that the software is trusted.
If attestation succeeds and the software is trusted, the device receives the certificates required to connect to the Azure Sphere update service and to authenticate as a client to other services. If the attestation value is invalid or has an incorrect signature, the device fails attestation outright and does not receive any certificates. It can neither connect to the update service nor authenticate to another web service.
In some cases, however, the Security Service may determine that the binaries are valid but are not trusted. This check guards against rollback attacks because it prevents an attacker from loading an older OS that posts a security risk. For example, if a binary contains a zero-day exploit, Microsoft might decide not to trust it as part of the attestation process. In this situation, the device is not granted a client certificate, so it cannot connect to web services. Instead, it receives only an update certificate so that it can update to a trusted version of the software. Once the update is complete, the device restarts the attestation process. If the binaries are now both valid and trusted, the device receives both the update and client certificates and can operate as usual.
After 24 hours, the certificates expire, and the device must repeat the attestation process.
Strong, flexible combination
The combination of e-fuses and attestation constitutes a strong yet flexible range of protection against rollback attacks. Attestation using secure ECC keys and binary hashes provides a way to remove trust for a single binary image in an OS release, a single OS release, or a range of releases in such a way that the device cannot run untrusted software and can easily update to a newer, trusted version. Blowing an e-fuse provides the ability to remove support for all releases earlier than a particular version at the hardware level, ensuring that the device cannot run older software.
For more information about security features in Azure Sphere, see Best practices for implementing seven properties in Azure Sphere.