Give away medical masks when you place an order. learn more

Protect Your MCU Design from Copying and Reverse Engineering



MCUs are used as the main control element in just about every application imaginable. Their power and flexibility make them the go-to component at the heart of most designs. Since it is important to make sure that your design cannot be easily copied, reverse engineered or tampered with, modern MCUs now provide a few different options for protecting your design; a good understanding of the capabilities and trade-offs are important in order to determine which approach is best for a given design.

This article will review some of the common approaches to design protection, such as making your MCU unreadable from the outside world, using on-chip capabilities to validate that the code to be executed is unmodified, and using external components to provide more advanced security capabilities. On-board techniques for tamper detection and possible “penalties” that can be applied also will be described.

Protecting your design

You may not have given much thought to how easy it is to copy your design, but engineers who have experienced design theft will tell you that once it has happened, you never want it to happen again! For example, if the on-chip code for your MCU design can be read out by a competitor, or even by an unscrupulous contract manufacturer, your entire design can be easily copied and resold — either under a different brand or perhaps even using your brand on the black market. Popular designs that outstrip product capacity are ripe for this type of treatment, and if sellers cannot get product from you they may dip into the black market to satisfy their customer demand.

Just as vulnerable is the actual design or algorithm hidden in the heart of your MCU code. Perhaps you have an innovative approach to analyzing sensor data that dramatically reduces the power or processing time required. Do you want a competitor to be able to just copy your code and reverse engineer your algorithm? There are even software tools that can take binary and regenerate reasonable “C” code so that the algorithmic details are even easier to decipher. Even something as mundane as an on-board test routine may have taken many months to get just right — do you want a competitor to get short-cut access to your infrastructure related code, dramatically reducing their development cost so they can unfairly cut their market price to win your business?

Another aspect of protection is related to hardware authentication. Often a design will allow for peripherals or add-on cards so a base design can be upgraded or enhanced. If the design does not include some capabilities to detect that the add-on module hardware is authorized, it’s possible for other vendors to create lower-cost modules to compete for the add-on business. Printer cartridges are perhaps the most familiar application for hardware authentication, to ensure that you buy a manufacturer’s branded cartridge. Often the printer is sold at a discount and the cartridge price is inflated to cover the discount over the lifetime of the printer. A competitor could sell a cartridge at a lower price, since it need not recoup the printer discount, and still make a healthy profit.

So, it should now be clear that in many cases it is important to be able to protect your hardware from copying, reverse engineering, and from counterfeiting. Furthermore, without secure hardware as a starting point, it would be impossible to create the variety of secure devices needed in applications like the connected home (Figure 1).


Figure 1: Common examples of secure devices in the connected home. (Courtesy of Texas Instruments) 

Several techniques have evolved over time, many of them using standardized security algorithms to protect and authenticate code stored inside an MCU or in memories peripheral to the MCU. Let’s look at some of the most common protection techniques and security standards and what they are used for. We will then be able to look at a variety of MCUs and peripherals that support these standards and can be used to protect your design.

Protection techniques and common security standards

Perhaps the most common technique for protecting hardware from copying is to program an MCU in a One-Time-Programmable (OTP) mode where the programmed data cannot be accessed from outside the device. JTAG and debug facilities must be turned off so that data cannot be accessed using a debug “backdoor.” Modern designs find the OTP approach very limiting, however, since debugging is a useful feature during failure analysis and in-field testing. Another important capability the OTP approach eliminates is remote updates to on-chip MCU code for upgrades, bug fixes, and other similar changes needed to improve operating integrity or quality of service. Ideally we would want to protect our code from reverse engineering and copying, but still be able to easily make updates and changes.

Some MCUs provide a secure method for accessing on-chip memory. Texas Instruments, with its MSP430FR MCU family, provides a method to either secure the JTAG port via a password, or to disable it completely by programming an on-chip disable-fuse signature. When JTAG is disabled, access to the device is only allowed via the boot loader using a password. Providing an incorrect password can result in the entire code memory area being mass erased.

TI also provides a method to create both secure and non-secure zones within the MSP430FR memory space. Secure code can be encapsulated (via IP Encapsulation, or IPE), by storing the secure code in a special memory area that is mapped into the boot code area after the first power-up cycle. The IPE area cannot be accessed by JTAG, BSL or even in-system reads, so it stays secure for the lifetime of the device. Code within the secure area can access data within the secure area however, so both security algorithms and keys can coexist within the security zone.

The most common security algorithms needed to protect your IP are used either to encrypt and/or decrypt secure data or to authenticate data to prove it is from a known and trusted source. MCUs can provide dedicated hardware to implement common industry standards and the Microchip PIC32MZ MCU family is just one such example. PIC32MZ devices include a hardware crypto engine that implements common bulk encryption decryption “ciphers” such as AES, DES, and Triple DES. These functions are used to protect secure data by encryption, using a secret key, so that only a process that “knows” the secret key can decrypt the data. Authentication is provided by SHA-1, SHA-256, MD-5, AES-GCM, and HMAC — all implemented in hardware. The crypto-engine hardware architecture and resulting performance (in Mbps/MHz of the input clock and in Mbps for a 100 MHz clock) are shown in Figure 2. The performance values are far superior to software implementations and show that if large amounts of data need to be processed frequently (perhaps during high-speed data transmission) or during time-critical events (such as during a boot process) the use of a hardware crypto engine can be critical for meeting system requirements.


Figure 2: Microchip PIC32MZ MCU crypto engine and performance metrics. (Courtesy of Microchip) 

Dual-core MCUs

Another approach to implementing security in more complex systems is to use a dual-core MCU. One of the MCU cores can be dedicated to implementing the security functions while the other core can be used for more standard operations. The NXP Semiconductors LPC4370 Dual-Core MCU (Figure 3) has two CPU cores, one is an ARM Cortex-M4 and the other is an ARM Cortex-M0. The Cortex-M4 core can be used for the “heavy lifting” portions of the application while the Cortex-M0 core can be used to implement the security-related functions and common-peripheral functions — perhaps managing the Ethernet and USB ports, configuring the various ports, and managing any off-chip resources.


Figure 3: The NXP LPC43xx Dual-Core MCU can be used to secure your design. (Courtesy of NXP) 

For even more advanced security designs, the optional AES encryption and decryption engine, offered on the LPC43Sxx devices, can be used to accelerate standard cryptographic functions such as AES, CMAC, and random-number generation. AES keys can be securely stored in on-chip one-time programmable (OTP) memory and optionally encrypted for additional protection. The AES hardware can even be used to implement a secure-boot capability (ensuring that the boot code has not been tampered with — a common target used by hackers to attack the security of an embedded system) from an encrypted image to further protect the design IP.

Security peripherals

If you want to augment an existing MCU with some additional security features you may be able to add a security peripheral to get the security capabilities you need. For example, the Atmel ATSHA204A device provides tamper-protected secure-key storage and authentication. The on-chip 4.5 Kb of EEPROM secure memory can be used to store multiple keys, perform reads and writes to manage passwords or secret data. Memory can be organized, configured, and then locked to prevent changes. Each device has a unique 72-bit serial number and supports common cryptographic algorithms (SHA-256 with Message Authentication Code and Hash-Based Message Authentication Code options) and a high-quality random-number generator. An I²C interface makes it easy to connect the device to a standard MCU. The ATSHA204A is typically used with a challenge and response transaction with the host MCU, as illustrated in Figure 4 below.


Figure 4: Using the Atmel ATSHA204 to authenticate and protect a design’s IP. (Courtesy of Atmel) 

The MCU challenge is processed by the ATSHA204 using the stored secret and the Message Authentication Code (MAC) command to create the response sent back to the host. The host can verify the response is correct by performing the same MAC command. An observer of the transaction never sees the secret key, so it is virtually impossible to determine the secret key needed to copy the design or determine any secret information stored in the ATSHA204. The ATSHA204 can be used to prevent copying of the design, protect firmware or media by validating it prior to execution (secure boot for example), store and manage session keys used by the host MCU for secure communications, store secret configuration, calibration or consumption data, or for validating user passwords. Atmel also offers engineers a crypto-authentication Product Training Module for the ATSHA204.

In summary, protecting your design from reverse engineering and hacking is now possible when using advanced security capabilities available to modern MCUs and a variety of supporting devices. Protecting networked-embedded systems is particularly critical as the occurrences of networked-based attacks against embedded systems continue to grow.

For more information on the parts discussed in this article, use the links provided to access product information pages on the Hotenda website.

Supplier