As Security Breaches Rise, Hardware-Based MCU Solutions Take Center Stage

Virtually all MCU-based embedded systems – automobiles, drones, USB sticks, garage door openers, digital cameras, and even consumables such as printer cartridges – are vulnerable to security attacks.

The growing number of documented security breaches that used Internet of Things (IoT) as an entry point has raised security consciousness in the design community for IoT-connected devices. Typically, the stories involve breaches that affected consumers and end-users. However, other types of security threats are at least as important to design engineers – and most involve the theft, tampering with, or destroying of intellectual property.

The Internet may have become the most popular entry point into an MCU-based system, but it is far from the only one. Unsecured or inadequately secured diagnostic ports have always been potentially vulnerable – as the automotive industry discovered largely through the activities of the “tuner” community. Any wireless (or wired) communications link also can be used as an entry point.

Even the unattached MCU device (or its associated ROM) are subject to tampering and IP theft. Among other techniques, reverse-engineering specialists have developed techniques in which the chip’s mask layers are carefully ground down until the ROM layer is exposed. By closely analyzing which switches have been blown, the firmware code contained in them can be deduced.

MCU vendors have responded with multiple approaches to enhancing security for the firmware that runs their devices. Although these measures make firmware more secure, implementing them requires that the system design team understand how they work – and implement them correctly. This involves the extra effort, time, and cost for the system’s bill of materials (BOM). Computer-intensive security measures such as data encryption can require a more powerful MCU.

Security strategies

Software solutions are often seen as an attractive option because they are relatively easy to implement and virtually free. Sometimes they are sufficient, but as is usually the case of “quick, cheap, easy” solutions, they carry more risk.

Critical components of the security algorithm, such as encryption keys, are stored in the MCU’s existing memory resources such as EEPROM or Flash. However, if the memory devices themselves are unsecured, the key information is still at risk. There is also the possibility that the algorithm itself may have implementation errors that make it vulnerable to attack.

A popular variant of the software-based solution is to add hardware-based security to the client side of the system and use software security on the host side. This hardware – which can exist on the client-side MCU or in an additional chip – is used to store the encryption key and to execute some or all of the security algorithm. Critical data is protected by a combination of logic and physical mechanisms, which are typically kept secret by the manufacturer. This approach is an effective defense against man-in-the-middle attacks. Since the host-side keys are stored in an unsecured resource, they can still be subject to alteration or theft. MCU security that is implemented entirely in hardware puts tamper-resistant key storage at every critical point of the system, includes encryption, and executes the security algorithm in hardware as well.

A popular way to implement hardware-based MCU security is for the MCU vendor to offer specially-designed processors and peripherals. Implementations vary but typically secure-processing chip sets deliver lower performance and increase BOM cost.

Hardware encryption

Microchip Technology offers hardware security into some of its popular PIC devices by integrating an encryption engines on the MCU. The engine also executes authentication to protect against man-in-the middle attacks. Two examples are the 16-bit PIC24F “GB2” and the 32-bit PIC32MZ.

In addition to adding security, integrating the engine offloads the MCU from the task of executing encryption algorithms in software. Microchip’s hardware engines can perform encryption and authentication in sequence or in parallel. An internal descriptor-based DMA is employed for efficient programming of the security association data and packet pointers. An intelligent state machine schedules the crypto engines based on the protocol selection and packet boundaries.

Key features include: Bulk ciphers and hash engines, integrated DMA to off-load processing, secure association for each buffer descriptor, and the ability to execute some functions in parallel.

Figure 1 shows the algorithms and performance metrics for the PIC32MZ. The performance metrics give an indication of the speed of encryption and how much CPU offloading is gained compared to executing of the algorithm in software.

Engine/Algorithm	Performance Factor (Mbps/MHz)	Maximum Mbps (PBCLK5 = 100 MHz)
DEC	14.4	1440
TDES	6.6	660
AES-128	9.0	900
AES-192	7.9	790
AES-256	7.2	720
MD5	15.6	1560
SHA-1	13.2	1320
SHA-256	9.3	930

Figure 1: Microchip Technology’s integrated encryption engines support eight security algorithms. (Courtesy of Microchip Technology)

Microchip offers the DM320006-C starter kit for its 32-bit crypto-engine devices and the DM240314 demonstration kit for its 16-bit devices.

Expanding memory options

Texas Instruments recently introduced a new approach to embedded MCU memory with a new family of its MSP430 FRAM MCUs that use Ferroelectric Random Access Memory (FRAM) in place of Flash. FRAM combines the attributes of Flash and SRAM. Like Flash, it is non-volatile but like SRAM it delivers fast, low-power writes. Its rewrite endurance is greater than 1015 cycles.

Data stored in FRAM is less vulnerable to reverse engineering attacks than Flash/EEPROM due to its resistance to radiation and electromagnetic fields. In addition, its power and access speeds are superior to Flash.

FRM write speed for 13 KB is 10 ms compared to 1 s for Flash and its average active power measured (measured for a 16-bit word access) is 100 µA/MHz compared to Flash’s 230 µA/MHz.

Its resistance to radiation and electromagnetic fields make FRAM particularly valuable in protecting against the physical attacks using microscopy and voltage manipulation.

In these types of attacks, hackers attempt to alter the application code itself instead of trying to modify the data while it is being transferred. To achieve this, they first obtain an image of the application code, reverse-engineer it, and finally overlay a modified version successfully within the system.

FRAM resists microscopy attacks because the bit write and read lines are physically located on either side of the polarized molecule, which means that de-layering the chip is likely to destroy the contents of the memory.

Protection against voltage manipulation is obtained largely due to the speed of FRAM write cycles. In these attacks, the input voltage to the device is manipulated outside the standard range to program bit cells by brute force. It is difficult to provide brown-out and overvoltage protection circuitry that can operate longer than the time required to program EEPROM bit cells. However, because FRAM writes much faster, this protective circuitry can be configured to create safe write-back circuitry to allow the FRAM to complete the write process correctly.

Securing programming ports

MSP430 FRAM MCUs also have an effective means to secure the ports that are used to program the device, which are attractive entry points for hackers. Typically, these are the JTAG interface and boot strap loader (BSL), which is mostly used for firmware upgrades.

By programming a fuse signature in FRAM, TI’s FRAM MCU can either secure JTAG using a password or disable it completely. When the JTAG port is disabled, access to the device is possible only using BSL, which requires a password to read out or receive data.

The password is the content of the interrupt vector table. On MSP430 FRAM devices, providing an incorrect password will result in the entire FRAM code area being mass erased. An additional way to increase the strength of the password is by filling any unused address spaces in the interrupt vector table with valid address values or by creating a double-jump table making it harder to perform a brute-force attack.

TI offers the MSP-EXP430FR5739 development kit for its MSP430 FRAM devices. The board is compatible with many TI low-power RF-wireless-evaluation modules.

Secure key managers

Another alternative – this one offered by Atmel Corp. – implements encryption security with an inexpensive chip that stores keys, passwords, and other data in EEPROM. The secure key manager uses a variety of physical and logical mechanisms, such as a random-number generator, that make the device tamper-proof and also capable of implementing authentication as well as encryption.

Since they are autonomous devices, they remove 100 percent of the computing burden from the MCU. Overall system design time is also cut significantly because most of the crypto- and protection-scheme work is done in advance by the chip vendor.

Atmel’s CryptoAuthentication ATSHA204 family of devices offers this option to design teams. The chips use the SHA-256 hash algorithm augmented by Message Authentication Code (MAC) and Hash-Based Message Authentication Code (HMAC) options. Other capabilities include:

• 256-bit key length
• Storage for up to 16 encryption keys
• Guaranteed unique 72-bit serial number
• Internal, high-quality random-number generator (RNG)
• 4.5 Kb EEPROM for keys and data
• 512-bit OTP (One-Time Programmable) Bits for fixed information
• Multiple I/O options

The unique 72-bit serial number is critical to implementing much of the ATSHA204’s functionality. Using cryptographic protocols supported by the device, a host system or remote server can prove that the serial number is both authentic and not a copy.

The ATSHA204’s ability to generate high-quality random numbers is used by the device’s cryptography protocols as well as for other security strategies. A flexible command set eases the task of implementing anti-counterfeiting and anti-cloning protection, firmware IP protection and validation, secure data storage, user password checking, and session key exchange.

Authentication

An effective strategy for combating copycat products is to implement an authentication process for accessories that work with the real product. When common accessories such as cables, plug-ins, power supplies, and batteries render the copycat product useless, they expose its counterfeit nature.

Similarly, copycat accessories cannot work with the original product. Copycat accessories invariably result in lost revenue, but an unauthorized accessory such as a battery or medical device that does not fully meet specifications can also result in serious harm. Adding a secure key manager to the system on the client side is the first step toward achieving a high level of security.

Additional security can be obtained by including the ATSHA204 in the host system as shown in Figure 2. The host generates a Random Challenge for the client (accessory) and evaluates its response.

An additional security benefit is derived from that fact that because the host’s challenge is generated using its ATSHA204, even the host processor is unaware of its response. Isolating the processor from the security function enables the use of an inexpensive non-security-hardened processor without providing a weak point through which an attacker can extract the system’s secrets.


Figure 2: Including secure key storage on both the accessory and host improves system-level security. (Courtesy of Atmel Corp.)

Firmware validation

While many security threats can cost a company revenue or damage its brand, the one that design engineers worry about the most is attempts to copy or corrupt the MCU’s firmware, which is typically stored in Flash. An effective defense is a secure boot process that ensures that only authentic firmware can run on the system.

Secure boots are implemented using a validating code or signature that is stored in Flash memory along with the boot code. The signature is created at the time of manufacture or code update and is the output of a cryptographic hash function – an irreversible algorithm which “condenses” the boot code into a compact, but unique datagram, typically 32-128 bytes in length. Figure 3 illustrates how the calculation and key storage is offloaded into a hardware-key-management device (ATSHA204).


Figure 3: Secure boot is an excellent way of protecting an MCU’s firmware. (Courtesy of Atmel Corp.)

At system startup, part of the boot sequence requires the security device to verify the signature accompanying the boot code. Only if the verification succeeds will the operating program be executed, and allow the system to operate in the normal way. Even modifying the operating program by a single bit will require a new validating signature. Both code images and downloaded media files can be stored using an encrypt key which can be usable only on a single authenticated system.

Conclusion

In response to a surge in security breaches and copycat products, MCU vendors are providing hardware-based security solutions in their chips. Although more costly than software-based solutions, they are more difficult – if not impossible – for even the most persistent intruder to defeat. Solutions range from embedded cryptography engines to memory technologies, such as FRAM to autonomous security chips that isolate the MCU from malicious interference. There is, however, no one-size-fits-all solution. Design teams must create the most appropriate security strategy for their application.

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