feature article
Subscribe Now

How to Stop an Embedded Virus

Microchip CEC1712 Helps Stop Malware Before it Starts

“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.

Leave a Reply

featured blogs
Jul 25, 2021
https://youtu.be/cwT7KL4iShY Made on "a tropical beach" Monday: Aerospace and Defense Systems Day...and DAU Tuesday: 75 Years of the Microprocessor Wednesday: CadenceLIVE Cloud Panel... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Jul 24, 2021
Many modern humans have 2% Neanderthal DNA in our genomes. The combination of these DNA snippets is like having the ghost of a Neanderthal in our midst....
Jul 23, 2021
Synopsys co-CEO Aart de Geus explains how AI has become an important chip design tool as semiconductor companies continue to innovate in the SysMoore Era. The post Entering the SysMoore Era: Synopsys Co-CEO Aart de Geus on the Need for AI-Designed Chips appeared first on Fro...
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

Electromagnetic Analysis for High-Speed Communication

Sponsored by Cadence Design Systems

When your team is driving the future of breakthrough technologies like autonomous driving, industrial automation, and healthcare, you need software that helps meet approaching deadlines and increasingly high-performance demands. Learn how a system analysis solution can provide accurate 3D modeling, electromagnetic simulation, and electrothermal simulation at the chip, package, PCB, and system level.

Click to learn more

featured paper

Configure the charge and discharge current separately in a reversible buck/boost regulator

Sponsored by Maxim Integrated

The design of a front-end converter can be made less complicated when minimal extra current overhead is required for charging the supercapacitor. This application note explains how to configure the reversible buck/boost converter to achieve a lighter impact on the system during the charging phase. Setting the charge current requirement to the minimum amount keeps the discharge current availability intact.

Click to read more

featured chalk talk

AC Protection & Motor Control in HVAC Systems

Sponsored by Mouser Electronics and Littelfuse

The design of HVAC systems poses unique challenges for things like motor control and circuit protection. System performance and reliability are critical, and those come in part from choosing the right components for the job. In this episode of Chalk Talk, Amelia Dalton chats with Ryan Sheahen of Littelfuse about choosing the right components for your next HVAC design.

Click here for more information about Littelfuse AC Protection & Motor Control in HVAC Solutions