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
Sep 26, 2022
Most engineers are of the view that all mesh generators use an underlying geometry that is discrete in nature, but in fact, Fidelity Pointwise can import and mesh both analytic and discrete geometry. Analytic geometry defines curves and surfaces with mathematical functions. T...
Sep 22, 2022
On Monday 26 September 2022, Earth and Jupiter will be only 365 million miles apart, which is around half of their worst-case separation....
Sep 22, 2022
Learn how to design safe and stylish interior and exterior automotive lighting systems with a look at important lighting categories and lighting design tools. The post How to Design Safe, Appealing, Functional Automotive Lighting Systems appeared first on From Silicon To Sof...

featured video

PCIe Gen5 x16 Running on the Achronix VectorPath Accelerator Card

Sponsored by Achronix

In this demo, Achronix engineers show the VectorPath Accelerator Card successfully linking up to a PCIe Gen5 x16 host and write data to and read data from GDDR6 memory. The VectorPath accelerator card featuring the Speedster7t FPGA is one of the first FPGAs that can natively support this interface within its PCIe subsystem. Speedster7t FPGAs offer a revolutionary new architecture that Achronix developed to address the highest performance data acceleration challenges.

Click here for more information about the VectorPath Accelerator Card

featured paper

Algorithm Verification with FPGAs and ASICs

Sponsored by MathWorks

Developing new FPGA and ASIC designs involves implementing new algorithms, which presents challenges for verification for algorithm developers, hardware designers, and verification engineers. This eBook explores different aspects of hardware design verification and how you can use MATLAB and Simulink to reduce development effort and improve the quality of end products.

Click here to read more

featured chalk talk

HARTING's HAN® 1A Connector Series

Sponsored by Mouser Electronics and HARTING

There is a big push in the electronics industry today to make our designs smaller and more modular. One way we can help solve these design challenges is with the choice of connector we select for our designs. In this episode of Chalk Talk, Goda Inokaityte from HARTING and Amelia Dalton examine the role that miniaturized connectivity plays in the future of electronic design. They also how HARTING's Han 1A connectors can help reduce errors in installation, improve serviceability and increase modularity in your next design.

Click here for more information about HARTING Han® 1A Heavy Duty Power Connectors