Where to Start with Embedded Processor Security

Multicore embedded SoCs see security demands rising

The world runs on data, and every bit or byte is a potential target for attack. At the same time, both software and hardware systems are becoming much more complex, connected, and interdependent. And with complexity comes vulnerabilities. The billions or trillions of lines of code and interrelated hardware modules, subsystems, and partitions—all crammed on tiny slices of silicon—are a hacker’s delight.


Of course, hackers are not standing still. Reports of vulnerabilities in embedded systems go on and on: satellite communication systems, wireless base stations, laser printers in residences and businesses, the smart electrical grid, medical devices like defibrillators, and many other systems are at risk. The need for security in multicore embedded system-on-chips (SoCs) has only increased. Embedded devices like heart equipment, smartphones, and automotive control units rely on multiple components, including embedded SoCs, to protect the control center. In this article, I’ll examine secure boot, the foundational layer of security for embedded processors. With secure boot, the system is protected from power on. Without secure boot, the system has a vulnerable gap from power on to usage.

Designers may face balancing communication throughput and security, but some embedded processors avoid this dilemma…

Architectural Considerations
Embedded security starts in hardware. Coupling software and hardware security features together enables a more secure layer of protection than either solution working independently. Vendor-provided tools can streamline the development of security subsystems and ensure that the resulting architecture meets developer requirements. For example, hardware-based security accelerators can mitigate the performance cost of a security subsystem.

Of course, the strength of a security architecture will depend on its foundation. Three aspects of the foundational layer are essential: a secure boot process, hardware-based device IDs/keys, and cryptographic acceleration.

The Security Pyramid
The security pyramid (Figure 1) illustrates the various layers and constituent parts of a comprehensive security subsystem for a multicore SoC embedded processor.

Figure 1: Security pyramid

Figure 1: Security pyramid

Secure Boot
A secure boot process establishes a root-of-trust for the embedded system. Even when initiating booting from external flash memory, a secure boot process verifies the integrity of the boot firmware through any number of mechanisms, including embedded cryptographic keys and others. A secure boot layer safeguards the system against takeover by malware, any possible cloning of the in-system intellectual property (IP), inadvertent execution of unwanted applications, and other security risks.

Secure boot also assists in providing an additional layer of protection by encrypting the IP and copying it securely to protect internal memories. Having the ability to encrypt also adds security for the code base, as it prohibits carrying out directed exploration attacks.

Cryptographic Acceleration
Cryptographic processing, which involves the generation, verification, and certification of various public and private keys, can take a toll on the performance and throughput of an embedded system. Some SoCs are equipped with hardware-based accelerators or co-processors that speed up the coding/decoding processes tremendously. Software-based acceleration is also available, but software is not as inherently secure as hardware-based cryptographic acceleration. Examples of common cryptographic functions include Advanced Encryption Standard (AES), Triple Data Encryption Algorithm (3DES), Secure Hash Algorithm (SHA), Rivest Shamir Adleman (RSA) and elliptic curve cryptography (ECC).

Debugging Security

During system development, you need access to embedded multicore processors in order to debug firmware and software and troubleshoot possible hardware problems. In most cases, access is via the Joint Test Action Group (JTAG) port. In an operating environment, the debugging port must either be sealed closed by some sort of fuse, or accessible only through certified cryptographic keys. Otherwise, the debugging port could provide an easy way into the system for hackers (Figure 2).

Figure 2: Texas Instruments MSP430™ microcontroller debugging port.

Figure 2: Texas Instruments MSP430™ microcontroller debugging port.

Trusted Execution Environment
The run-time security layer comprises several distinct capabilities that all play a part in protecting the system following the boot-up process and execution of the operating system (OS). An important aspect of run-time security is monitoring all aspects of the system to determine when an intrusion has either occurred or been attempted. Trusted execution environment (TEE) security (Figure 3) enables a system to host secure and nonsecure applications concurrently and maintain a partition through the system such that there is no leak of data.

A TEE essentially provides a secured partition within a multicore system that enables the execution of certified secure firmware, software, and applications only, and the storage of certified data only. Walling off the TEE from the rest of the multicore/multiprocessing system prevents suspect code, applications, and data that may pass through the system from contaminating mission-critical software, data, and other IP.

Figure 3: A trusted execution environment.

Figure 3: A trusted execution environment.

Secure Storage
Cryptographic keys and security data must be stored in system memory in locations that are impervious to unwanted access. A number of capabilities can provide secure storage, including encrypted Binary Large Object (BLOB) keys, anti-tamper protection that only a master key can unlock, a private key bus between nonvolatile memory and cryptographic engines, and others.

External Memory Protection
When adding another application or subsystem, you usually have to add memory that is external to the main processor and connect to it through a memory bus. You must protect the data stored in external memory against tampering or replacement to ensure that external memory only stores trusted data or application code. A number of methods can safeguard the contents of external memory, including secured execute-in-place directly from external memory (without loading data into the processor’s integrated memory) and decrypt on the fly, which can maintain confidentiality while enabling applications to run on the main processor.

Networking Security
Hackers are quite adept at intercepting wireless and wired network communications. In fact, some communication protocols have known security weaknesses that hackers have exploited. Deploying only highly secure communication protocols often involves a significant number of processing cycles to encrypt and decrypt the communication stream, as well as to verify the authenticity of the sender or receiver. Designers may face balancing communication throughput and security, but some embedded processors avoid this dilemma by integrating hardware-based accelerators for the cryptographic algorithms used in conjunction with standard communication protocols.

Physical Security and Tamper Protection
Sophisticated and not-so-sophisticated hacking organizations have been known to remove chips from a system or a silicon die from a chip package to access embedded assets (Figure 4). Once the device or die has been removed, hackers can bombard the devices with lasers, power them up beyond their specified power limits, or employ other means. Their objective: Observe how the device reacts to stimulus because responses may betray vulnerabilities that hackers can then exploit to access the device. Tamper-protection modules integrated into embedded multicore processors can contain power and temperature monitors, reset functionality, frequency monitors, and programmable tamper-protection capabilities.

 Figure 4: An example of a device under physical attack.

Figure 4: An example of a device under physical attack.

Enclosure Protection
Enclosure protection features are physical measures that safeguard the enclosure encasing a system. These features can range from locking mechanisms to electronic switches, break-away wire-tripping mechanisms, and others (Figure 5).

Figure 5: Enclosure protection.

Figure 5: Enclosure protection.

Where to Start with Embedded Security?
The fundamental basis for the security of an embedded multicore processor begins in hardware. If the hardware is not secure, no amount of security software will assist in making it so. Assuming security features are already built into the hardware, the first place to look to begin building a security subsystem is in the first software that will execute following power up: the boot code. If you cannot authenticate the booting process, then no other software running on the system can either. So, securing the boot process is the fulcrum upon which all of the security in the system depends. A secure boot process establishes the root-of- trust, which is the goal of every security subsystem.

Usually, a secure boot process involves programming a public cryptographic key into nonvolatile, one-time-programmable memory somewhere in the system. This public key must match private/public keys associated with the boot code to authenticate the validity of encrypted boot code before execution begins. Booting firmware can either be loaded into the embedded processor’s random access memory (RAM) or, for added security, secured and executed in place out of memory external to the embedded processor. Some firmware images consist of various components or modules. Requiring authentication before decrypting and executing each module enhances boot security. Examples of embedded processors that offer a secure boot process can be found in the Sitara™ AM43x, AM335x, and AM57x processor families from Texas Instruments.

Embedded processor security is a multifaceted, complex subject. With the ascent of the Internet of Things (IoT) and the ubiquity of embedded systems, hackers—now more than ever—have an abundance of prime targets.

amrit_headshot_2Amrit Mundra is a Security Architect and Systems Engineer in TI’s Processor group. He is responsible for the definition of end-to-end security for TI’s Processor platform that includes single and multicore processors devices with ARM and DSP cores. In the past, Amrit has architected and implemented various cryptographic cores, IPSEC engines, security sub-systems and has lately defined the security for TI’s point-of-sale device that involves securing the device to meet payment security standards.


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.