feature article
Subscribe Now

Das Boot und Kryptographie

Microsemi Inserts Man-in-the-Middle to Encrypt Boot-up

Security wonks talk about the “root of trust” for computer systems, and for good reason. If you can’t start from a known-good position, everything that happens afterwards is potentially suspect. Building castles on sand, and all that.

Since every computer and embedded system has to bootstrap itself from cold metal, the boot-up process is necessarily the root of all subsequent trust. If the boot ROM is compromised… well, there’s no telling what mischief may follow.

That’s the concept behind Microsemi’s new “secure boot reference design.” Lock down the bootstrapping process first, and you can then start building a secure system on top of it. A lot of companies have made token efforts to secure their respective processors’ firmware. Encryption, anti-hacking measures, obfuscation, and so forth. But Microsemi is different in three ways. First, it’s much more complete (and paranoid) than any other approach I’ve seen. Second, it secures other vendors’ processors, not its own. And finally, it’s not even a new chip – it’s programming for existing devices.

The details of Microsemi’s scheme are necessarily intricate and arcane, but the overall concept is simple enough: prevent the contents of the boot ROM from being corrupted, and make sure that only good code reaches the processor. Once the CPU is on its feet, turn over control to somebody else’s code, at which point further security becomes someone else’s problem. Microsemi can’t guarantee that your Linux drivers haven’t been hacked, but by golly, the system will be pure and uncontaminated when they’re loaded.

So how’s it work? Basically, by inserting a chip between your processor and its boot ROM. Specifically, it relies on one of Microsemi’s SmartFusion2 FPGA/CPU combo chips. You remember SmartFusion2. Back when the company was still called Actel, it announced a new family of chips that combined an ARM Cortex-M3 processor, programmable logic, and flexible analog components all into one programmable system-on-a-chip. In some cases, a single SmartFusion2 might be all the hardware you need. In this case, it’s an intermediary – a man in the middle – between your processor and your boot code.

Assuming your CPU talks to its boot ROM over SPI (a requirement of the current reference design), you simply snip the connection, plant the SmartFusion2 device in its place, and reconnect the boot ROM on the other side. Voila! You’ve turned a simple four-wire interface into a smart, security-managed, intelligent, programmable, bootloader watchdog.

That’s the easy part. The hard parts are figuring out whether the boot image is genuine; transferring that code to the processor without allowing it to be intercepted or corrupted; and making the processor execute boot code that’s been encrypted.

The magic wand you want to wave over this whole process is generically known as white-box cryptography (WBC). Here, “white box” refers to the easily accessible nature of the hardware, as opposed to a closed “black box.” To ensure the maximum level of security, we have to assume the worst: that attackers will have total physical access to the embedded system and that they are able to trace, measure, probe, disassemble, cut, or solder anything they want. The trick then becomes engineering security measures for a system that’s wide open to reverse engineering.

The first step is to never transmit a cryptographic key in the clear. Fine, but how do you do that when all your software is transported over SPI? It’s pretty easy for the bad guys to monitor an SPI bus and disassemble all the code, or to inject malicious code over the same SPI bus.

Part of the solution is to bury the crypto keys in amongst the bit stream of the software itself, and this is where Microsemi’s SmartFusion2 device comes into play. It uses uninitialized SRAM cells to harvest a few thousand random bits of random data, seed a key with it, and use that to encrypt and obfuscate the “real” key as it makes its way to the host processor. Because the SRAM noise is different every time the system powers up, this initial one-time key, or nonce, changes every time.

It would have been easy enough for Microsemi to just encrypt all the boot code and send that to the processor, but most processors can’t execute encrypted code. So it does the next best thing by sending the boot code in plaintext, along with the obfuscated AES key and the SRAM-seeded nonce. That allows the host processor to authenticate the boot loader without having to decrypt the whole thing or to share a hard-coded or permanent key with SmartFusion2. 

20140212_fig1.png

The processor and SmartFusion2 then both generate and share another set of keys, which are used to protect the transport of the larger application code. Sound complicated? You betcha. But Microsemi has done all the work. All you have to do is buy it.

The company says its secure-boot design will work with even the smallest and cheapest SmartFusion2 device, so you’re looking at about $7 in additional hardware cost. If you’re already a SmartFusion2 customer, you might get lucky and be able squeeze the new logic into an unused corner of the device, making the security features essentially free.

The encryption key is going to cost you, however. Microsemi sells single WBC keys for $11,500 a pop, or a program to generate unlimited keys for $95,000. That may sound like a lot of money, but if you’re making high-reliability equipment, it’s probably a drop in the development-project bucket.

As we saw recently, embedded systems are increasingly coming under attack, partly because there’s more of them, and partly because they’re becoming more interesting to attackers. Sooner or later, we’ll all have to secure our designs, starting with the boot process. Internal boot ROMs can help a lot, but, for systems that load code from external storage, Microsemi’s elaborate man-in-the-middle approach looks likely to keep the bad guys at bay. 

Leave a Reply

featured blogs
Jul 6, 2020
If you were in the possession of one of these bodacious beauties, what sorts of games and effects would you create using the little scamp?...
Jul 3, 2020
[From the last episode: We looked at CNNs for vision as well as other neural networks for other applications.] We'€™re going to take a quick detour into math today. For those of you that have done advanced math, this may be a review, or it might even seem to be talking down...
Jul 2, 2020
In June, we continued to upgrade several key pieces of content across the website, including more interactive product explorers on several pages and a homepage refresh. We also made a significant update to our product pages which allows logged-in users to see customer-specifi...

Featured Video

Product Update: DesignWare® TCAM IP -- Synopsys

Sponsored by Synopsys

Join Rahul Thukral in this discussion on TCAMs, including performance and power considerations. Synopsys TCAMs are used in networking and automotive applications as they are low-risk, production-proven, and meet automotive requirements.

Click here for more information about DesignWare Foundation IP: Embedded Memories, Logic Libraries & GPIO

Featured Paper

Cryptography: A Closer Look at the Algorithms

Sponsored by Maxim Integrated

Get more details about how cryptographic algorithms are implemented and how an asymmetric key algorithm can be used to exchange a shared private key.

Click here to download the whitepaper

Featured Chalk Talk

Demystifying Wireless! Key Considerations for Adding Wireless to Your IoT Solution

Sponsored by Mouser Electronics and Digi

Adding wireless connectivity to your IoT design can be a major challenge in an already-crowded schedule. And, doing it as an afterthought can cause all kinds of trouble. In this episode of Chalk Talk, Amelia Dalton chats with Andrew Reiter from Digi International about a holistic approach to designing wireless connected designs.

Click here for more information about Digi International XBee® XBIB-C Development Boards