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
Dec 3, 2021
Believe it or not, I ran into John (he told me I could call him that) at a small café just a couple of evenings ago as I pen these words....
Dec 3, 2021
The annual Design Automation Conference (DAC) is coming up December 5th to 9th, next week. It is in-person in San Francisco's Moscone Center West. It will be available virtually from December... [[ Click on the title to access the full blog on the Cadence Community site...
Dec 1, 2021
We discuss semiconductor lithography and the importance of women in engineering with Mariya Braylovska, Director of R&D for Custom Design & Manufacturing. The post Q&A with Mariya Braylovska, R&D Director, on the Joy of Solving Technical Challenges with a...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured video

Achronix VectorPath Accelerator Card Uses PCIe Gen4 x16 to Communicate with AMD Ryzen PC

Sponsored by Achronix

In this demonstration, the Achronix VectorPath™ accelerator card connects to an AMD Ryzen based PC using PCIe Gen4 x16 interface. The host PC issues commands to have the Speedster™7t FPGA on the VectorPath accelerator card write and read to external GDDR6 memory on the board. These data transactions are performed using the Speedster7t FPGA’s 2D network on chip or NoC which eliminates the need to write complex RTL code to design the host PC to GDDR6 memory interface.

Contact Achronix for a Demonstration of Speedster7t FPGA

featured paper

Enhancing PSAP Audio Performance and Power Efficiency in Hearables with Anti-Noise

Sponsored by Analog Devices

Personal sound amplification products (PSAP) enhance user’s listening experiences with hearables in challenging environments. Long delay in the audio system creates distortion known as comb effect in PSAP. This paper investigates the root cause of the comb effect and explains how Maxim’s PSAP based on anti-noise solution yields a superior system performance than conventional PSAP solutions.

Click to read more

featured chalk talk

Traveo II Microcontrollers for Automotive Solutions

Sponsored by Mouser Electronics and Infineon

Today’s automotive designs are more complicated than ever, with a slew of safety requirements, internal memory considerations, and complicated power issues to consider. In this episode of Chalk Talk, Amelia Dalton chats with Marcelo Williams Silva from Infineon about the Traveo™ II Microcontrollers that deal with all of these automotive-related challenges with ease. Amelia and Marcelo take a closer look at how the power efficiency, smart IO signal paths, and over the air firmware updates included with this new MCU family will make all the time-saving difference in your next automotive design.

Click here for more information about Cypress Semiconductor Traveo™ II 32-bit Arm Automotive MCUs