“I eat at the unlimited buffet of danger.” – R.J. Haywire

Security is de rigueur these days, and, like machine learning and cloud connectivity, it’s moving down into cheaper and cheaper devices. Now even low-end microcontrollers have embedded security features – and it’s still not enough. 

Mention “security” to most engineers, though, and they’ll roll their eyes. It’s something the boss says they need to have, but nobody really wants to do the work. (Honestly, few developers even know what’s required.) Like art, it’s hard to define but they’ll know it when they see it. 

So, we have a fundamental conflict: We don’t have the time or inclination to implement good security, but good security has to be designed-in from the start; it can’t be tacked on. 

Except when it can. Let me introduce you to Microchip’s melodiously named CEC1712. It’s a new security chip that you can practically glue on at the last minute to enjoy the benefits of its malware-fighting abilities. It’s solid security without all the effort. 

There are many ways to hack a system, and the CEC1712 doesn’t conquer them all, but it is adept at defeating one class of attacks: malicious boot code. It scours your boot ROM before you boot to make sure a rootkit or bootkit hasn’t infiltrated your system. It protects against malicious code even before any code starts running. 

The concept couldn’t be simpler. The CEC1712 camps on the SPI interface between your boot ROM and your main processor. (This assumes that you boot from a SPI flash device, of course.) It also intercepts your processor’s hardware reset line. During power-up, the chip reads from your boot ROM and authenticates the boot code using the public key stored inside the CEC1712.   The boot code is signed with a private key that never leaves the factory, so it stays safe from evildoers.  If  the boot code checks out, the chip releases the reset line and allows your processor to boot as normal. But if the  boot code does not pass authentication, then something’s gone wrong and your main processor stays frozen. 

Them’s the basics. The devil, as always, lives in the details. The CEC1712 itself is a processor (the ubiquitous ARM Cortex-M4) with 256KB of SRAM, some ROM, and some one-time programmable memory for key storage, all of which means that it needs to boot itself and start running before anything else happens. It starts by booting from its internal factory-programmed ROM before fetching more boot code from the same SPI flash that holds your system’s boot code. That code is signed with a private key that corresponds to the public key inside the CEC1712’s OTP key store. If that code checks out okay (authenticates), the chip then authenticates the main processor’s boot code, checks the code using the same or additional keys, and allows the processor to boot if the code is okay. If not, the processor stays in reset. 

There are fail-safes. The SPI flash actually holds two identical (you hope) copies of the CEC1712’s boot code. If the boot code fails the initial key check, the chip automatically tries again using the second copy. If that copy checks out, it erases the first copy and replaces it with the second copy before booting as normal. That prevents one-time glitches, loose solder connections, flaky busses, and other random mishaps from being misdiagnosed as firmware attacks. If the second copy also fails the key check, however, you’re hosed and the system stays frozen. 

Assuming the CEC1712 boots safely but the main processor’s boot code fails its authentication check, that processor won’t be allowed to boot. The CEC1712 will be secure and running, however, and it’s a decent MCU in its own right. You could use it to signal the outside world that something is amiss, light up LEDs, send a text message, or whatever fallback action makes sense. 

Once the CEC1712 has booted successfully, it’s now a “root of trust” for other devices in the system. And, assuming the host processor also boots up successfully, that chain of trust extends to it as well. 

You can optionally encrypt your boot code, in which case the CEC1712 will decrypt it on the fly using its internal crypto acceleration hardware while it loads from SPI flash. Post-boot, that same hardware can be used as an off-chip crypto accelerator.  

In fact, Microchip clearly designed the CEC1712 to be useful beyond the first few milliseconds of your system’s life. The chip comes in a big 84-pin package and has up to 68 undedicated I/O pins, even though it needs only a few to communicate over SPI. It could just as easily have fit in a tiny 8-pin package, but Microchip clearly wanted the device to justify its existence post-boot. It behaves like a general-purpose microcontroller with some unique security features, not the other way around. 

Cryptographic signatures are great for authenticating your boot code, but what happens if you want to update your firmware? The CEC1712 doesn’t intervene in firmware updates, but it will authenticate the new code the same way it validated the previous version. That is, it won’t prevent the update from happening, but it can prevent it from running. 

There are other scenarios where you might want to change or revoke keys, such as if a key is leaked or if you’re selling equipment. The CEC1712 has room for more than one public key in its OTP key store, so it’s wise to load more than one at build time. That way, keys can be revoked one by one as the need arises. You can’t add keys after the fact, since that would defeat the purpose. 

The CEC1712 goes about its business invisibly and automatically and has no discernable effect on a system’s behavior. The chip takes just a few tens of milliseconds to authenticate the firmware and allow the host processor to boot. That’s overhead time that nobody will see. Because of the size of its internal SRAM, it works quicker when the boot image is smaller than about 250KB, but Microchip says it works just fine with code of any size. And, once your system has booted, you’ve got a Cortex-M4 with a lot of crypto hardware and a lot of I/O pins to play with. At about $4 in volume, the CEC1712 earns its spot on the board even if it never catches an evildoer.