Microsoft Experiment Looks Into the 7 Properties of Highly Secured Devices for IoT

Microsoft Research's NExT Operating Systems Group released a list of properties that IoT devices should possess in order to be secure. Here's a look at the list and the hardware the group designed to show it in action.

A team from the Microsoft Research New Experiences and Technologies (NExT) Operating Systems Group has been working on methods to introduce high-level security in IoT microcontrollers, coming up with a list of seven properties they believe are essential for protecting devices and could be easily implemented by any manufacturer.

To test the soundness of the properties they defined, the team experimented implementing the security features on an already existing MCU, and published the results in an article titled “The Seven Properties of Highly Secured Devices”.

IoT security is increasingly in the spotlight as more recognition is given to the fact that many devices, especially low-cost ones, don’t take security into consideration at all in their design. Since IoT devices are networked, often connected to sensors such as cameras, they present a particular vulnerability. Invasion of privacy, stolen information, or being used in DDoS attacks, are all very real and pressing concerns.

In the publication, Microsoft highlights it’s implementation of improved security in Windows 95 when they introduced automate remote updates, and automated security reporting and analysis of attacks. Using this idea and history of dealing with network security, they defined the following properties that could be applied to any level of IoT microcontroller:

The Seven Properties of Highly Secured IoT Devices

1. Hardware-Based Root of Trust

The team advises that the hardware that IoT devices run on need to be inherently secure, creating the “hardware-based root of trust”. The suggestion here is two-fold: use single-purpose hardware so that it is more difficult for an attacker to reuse, and have built-in features to detect when hardware attacks are occurring and can mitigate them. An example the team uses is pulse testing the reset pin as mitigation against glitch attacks.

2. Small Trusted Computing Base

The suggestion here is to minimize the hardware and software being used in the trusted computing base—with more pieces involved in maintaining a secure environment, more failure points are introduced.

3. Defense in Depth

Here, redundant and comprehensive security measures are recommended, so that if one layer of security is compromised, then other measures are still in place to prevent further intrusion.

4. Compartmentalization

Compartmentalization is suggested, in which hardware and software are separated when possible so that a breach in one doesn’t automatically give access to all other parts of the device or software. The paper mentions virtual machines as software compartmentalizing.

5. Certificate-Based Authentication

Moving from password-based authentication to certificate-based authentication is recommended since certificates can’t be forged or stolen. This means that the identity of devices and authentication are much more secure.

6. Renewable Security

Similar to remote security update common in most OSs, renewable security in IoT MCUs would mean that regular security updates would occur to continuously address newly identified threats or vulnerabilities, with no possible roll back.

7. Failure Reporting

Finally, built-in and automated failure reporting would send information about attempted attacks or glitches that could be analyzed and used to continuously improve security.

Sopris Hardware Implementation

Wanting to put their theory into practice, the team developed the Sopris microcontroller, based on an already existing MediaTek MCU, the MT7687.
MT7687 Specs:

• 192 MHz CPU
• 352kb RAM
• 28 pin GPIO
• 12-bit ADC
• 802.11 b/g/n Wi-Fi and Bluetooth

Sopris development board. Image courtesy of Microsoft NExT.

Sopris, the modified version of the MT7687, features Pluton, a security subsystem, and a merry management unit (MMU) in the primary processor. These hardware features create the “hardware-based root of trust” defined earlier.

Pluton features a security processor CPU, a hardware random number generator, cryptographic engine/operation engine using AES symmetric encryption/decryption, an SHA hashing engine for certificate authentication, and a public key engine for both RSA and ECC public-key cryptography.

Image courtesy of Microsoft NExT.

The random number generator is used for cryptography functions (such as key generation) and to randomize the timing of the boot firmware to make side-channel attacks more difficult. The cryptographic operation engine allows for operations that require multiple cryptographic engines at once, such as certificate authentication and attestation.

The MMU, along with some added SRAM, replaces a more traditional memory protection unit and allows for the operating system to define multiple independent memory address spaces. This enables compartmentalization of processes.

With these two added hardware features, the team describes that all seven of their recommendations can be met, starting with the hardware security, and going down to implementing software that can handle automatic updates and reporting.

---

The team’s next step is to further develop an MCU prototype along with software that can be tested by other security experts in academia and in industry, and using that feedback to improve the seven properties they’ve identified.


Do you think the list is comprehensive enough? How would you go about implementing it in your designs? Tell us your thoughts in the comments below.