Design A Microcontroller With Security In Mind

Mount Sopris

There are many parts to building a secure networked device, and the entire industry is still learning how to do it right. Resources are especially constrained for low-cost microcontroller devices. Would it be easier to build more secure devices if microcontrollers had security hardware built-in? That is the investigation of Project Sopris by Microsoft Research.

The researchers customized the MediaTek MT7687, a chip roughly comparable to the hacker darling ESP32. The most significant addition was a security subsystem. It performs tasks notoriously difficult to do correctly in software, such as random number generation and security key storage. It forms the core of what they called the “hardware-based secure root of trust.”

Doing these tasks in a security-specific module solves many problems. If a key is not stored in memory, a memory dump can’t compromise what isn’t there. Performing encryption/decryption in task-specific hardware makes it more difficult to execute successful side-channel attacks against them. Keeping things small keeps the cost down and also eases verifying correctness of the code.

But the security module can also be viewed from a less-favorable perspective. Its description resembles a scaled-down version of the Trusted Platform Module. As a self-contained module running its own code, it resembles the Intel Management Engine, which is currently under close scrutiny.

Will we welcome Project Sopris as a time-saving toolkit for building secure networked devices? Or will we become suspicious of hidden vulnerabilities? The researchers could open-source their work to ease these concerns, but value of their work will ultimately depend on the fast-moving field of networked device security.

Do you know of other efforts to add hardware-assisted security to microcontrollers? Comment below or let us know via the tip line!

[via Wired]

Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)

 

22 thoughts on “Design A Microcontroller With Security In Mind

  1. Crypto subprocessor and WiFi subsystem on same die that is a black-box to end user? I don’t think so. It would be better idea to have crypto chip that can be interfaced to microcontroller of your choice using SPI, I2C or any other serial/parallel protocol, so you can see exactly what is going on and control which data goes where.

    1. Evil maids with logic probes might probe the data off of the chip, but the openness of a crypto chip would create more hardware diversity and thus produce more flexibility and security by preventing any one attack to be sucessful on the majority of devices.

  2. Security. An active and growing career opportunity that has served mankind admirably despite no possible way of succeeding well enough to put yourself out of a job.

    “For every better mousetrap…”
    “The more they overthink the plumbing…”

    It’s the one subject actively pursued ever since we discovered comfy caves have one flaw of an entrance needing to be secured.
    Totally a fool’s quest as there is no endpoint, but one that needs be staffed in perpetuity.

  3. Remember, kids… the ‘S” in IoT stands for Security!

    IoT security as a hardware commodity would probably be useful to industry, and would remove a lot of potential attack surface. The main thing is to keep perspective; most IoT uses are relatively benign, so your fridge doesn’t need e-comm-grade crypto. Heavier security should of course be available for medical devices, industrial control, and any other critical application where unauthorized access could bring harm.

    1. I agree with what you say but it should be noted that any IoT device can be used to access the rest of the network, so maybe it would be prudent to give anything connected it the net the best possible security level. Maybe the easiest security measure is to stop attaching fridges (and everything else) to the internet. ;)

    2. “most IoT uses are relatively benign” Really? Most IoT devices are already participating in DDOS botnets.

      I’m sure that neither of these perspectives is strictly true, but “most IoT devices” include enough processing power to be turned into something bad if their firmware were re-written. And because of the need to pass updates to fix deployment-time bugs, most IoT devices have a mechanism for updating their firmware.

      IoT is putting a bunch of computers inside your network firewall. How secure they are is important to the consumer and society in general.

      1. Your observation suggests that perhaps we are using sledgehammers to swat flies.

        Where is it written that the IoT processor in your fridge should ever be capable of participating in a DDOS botnet? Having a drawerful of ESP8266s and other devices, I appreciate how convenient it is to have such powerful and flexible devices to experiment with, but they are arguably too capable and vulnerable to be used as commercialy deployed devices.

        So, maybe we should first establish that IoT devices are restricted to a defined set of ports and/or protocols, and the commercially deployed devices be made with fuses that can be blown at programming time to disable all but those ports and protocols. We could also create standards around the routing of IoT communication within the home or business, so that routers also share the burden of restricting IoT communications.

        Having everyone’s fridge, thermostat, etc talking directly to “the cloud” using standard protocols is also a recipe for disaster.

  4. I found it interesting that the latest batch of Arduino-branded boards, the MKR1000, includes an ECC crypto chip (or the functionality of one) built into the wireless module.

    It seems to be the same chip, or an updated version of one, featured on the CryptoCape and CryptoShield, both now discontinued at Sparkfun. The chips themselves are still available, but you’ll have to DIY some SOIC breakouts to play with ’em.

  5. Here we go again. Intel management engine for micros! This is bad because if it takes off, that means eventually every little embedded cpu will be jacked up so that some big corporation can do anything it wants at any time to “your” device, while YOU are unable to truly get at your own hardware. (Because M$/RIAA etc don’t *trust* you)

    Secure and trusted is “nobody puts code in my box unless they are physically present”. And that’s not M$, nor any other corporate interest. If I paid for it, that’s ME.

Leave a Reply to Richard CollinsCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.