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
Oct 20, 2020
In 2020, mobile traffic has skyrocketed everywhere as our planet battles a pandemic. Samtec.com saw nearly double the mobile traffic in the first two quarters than it normally sees. While these levels have dropped off from their peaks in the spring, they have not returned to ...
Oct 20, 2020
Voltus TM IC Power Integrity Solution is a power integrity and analysis signoff solution that is integrated with the full suite of design implementation and signoff tools of Cadence to deliver the... [[ Click on the title to access the full blog on the Cadence Community site...
Oct 19, 2020
Have you ever wondered if there may another world hidden behind the facade of the one we know and love? If so, would you like to go there for a visit?...
Oct 16, 2020
[From the last episode: We put together many of the ideas we'€™ve been describing to show the basics of how in-memory compute works.] I'€™m going to take a sec for some commentary before we continue with the last few steps of in-memory compute. The whole point of this web...

Featured Paper

Four Ways to Improve Verification Performance and Throughput

Sponsored by Cadence Design Systems

Learn how to address your growing verification needs. Hear how Cadence Xcelium™ Logic Simulation improves your design’s performance and throughput: improving single-core engine performance, leveraging multi-core simulation, new features, and machine learning-optimized regression technology for up to 5X faster regressions.

Click here for more information about Xcelium Logic Simulation

featured paper

Fundamentals of Precision ADC Noise Analysis

Sponsored by Texas Instruments

Build your knowledge of noise performance with high-resolution delta-sigma ADCs. This e-book covers types of ADC noise, how other components contribute noise to the system, and how these noise sources interact with each other.

Click here to download the whitepaper

Featured Chalk Talk

Electrification of the Vehicle

Sponsored by Mouser Electronics and KEMET

The automotive technology revolution has arrived, and with it - new demands on components for automotive applications. Electric vehicles, ADAS, connected cars, and autonomous driving put fresh demands on our electrical and electronic parts. In this episode of Chalk Talk, Amelia Dalton chats with Nick Stephen of KEMET about components for the next generation of automobiles.

More information about KEMET Electronics ALA7D & ALA8D Snap-In Capacitors