Protecting today's military electronics systems with real-time hardware/software protection countermeasures

Story

October 27, 2009

Today's military electronic systems have undergone a rapid evolution, and as a result, these systems and the data stored and transferred within are increasingly vulnerable to harmful manipulation caused by both unintentional and malicious actions. While systems designers are becoming more security-conscious and security requirements are increasingly being included in the design and development process, there are many challenges to address when attempting to secure electronics systems.

The optimal approach is to incorporate both hardware-based and software-based security measures to protect against piracy, reverse engineering, and unauthorized use.

Through many advances, including semiconductor integration and the use of third-party software and hardware IP, electronic systems have undergone a rapid evolution in both complexity and construction. Systems that were once composed of a few million transistors and a few hundred thousand lines of code are being replaced with systems constructed with hundreds of millions of transistors and millions of lines of code.

As a result, modern military electronic systems and the data stored and transferred within are increasingly vulnerable to harmful manipulation, caused by both unintentional and malicious actions. In terms of unintentional vulnerabilities, the majority are introduced during the system design phase, when security concerns are inadequately defined or insufficiently considered, and simple design flaws occur. Unfortunately, these unintentional vulnerabilities are increasingly being exploited by ever-more-sophisticated and malicious threats.

Recent news attests to these vulnerabilities. Over the past year, a number of high-profile cyber assaults were launched against defense, government, utility, and financial sector infrastructures, including the infiltration of the Pentagon’s highly secret fighter jet project and a breach of the Air Force’s air traffic control system – both of which represent shocking blows to the nation’s defense capabilities. Evidence increasingly indicates that cyber attacks that were once perpetrated by a few poorly funded individuals are now being executed by a larger number of well-funded and well-organized institutions with scientific resources, aided by an incredibly efficient mass communication system – the Internet.

While systems designers are becoming more security-conscious and security requirements are increasingly being included in the design and development process, there are many challenges to address when attempting to secure electronics systems. The optimal approach is to incorporate both hardware-based and software-based security measures to protect against piracy, reverse engineering, and unauthorized use. These software and hardware systems must be bound tightly together and operate in concert to ensure maximum protection. Our discussion will demonstrate the feasibility of a hardware-assisted technology for adaptive software protection. It will address the elements of a software/hardware approach, and explore how a programmable design can provide real-time security monitoring to detect unexpected or illegal behavior.

The programmable hardware-assisted technology

A programmable hardware-assisted technology provides many benefits over an exclusively software-based alternative, including the ability to monitor low-level hardware functions in real time and the ability to monitor multiple points in a design simultaneously without impacting CPU performance. The most notable benefit, however, is that the hardware-assisted technology is programmable, allowing a variety of monitoring and countermeasure functions to be executed during runtime and providing a means for new security monitors and countermeasures to be created on-the-fly, or uploaded post-deployment to address any unexpected threats or latent design flaws.

This “defense logic” consists of distributed programmable instruments that can be configured repeatedly to dynamically implement different security checks that constantly monitor the system operation to detect unexpected or illegal behavior. Programmability also allows a large number of checks to be implemented by time-sharing the same hardware.

Technology that couples an existing software protection product, such as the ARM TrustZone (TZ) or Green Hills Software’s INTEGRITY RTOS, with security analysis software functions and a new programmable hardware mechanism will defend against a broad spectrum of attacks including Class I (outsiders or hackers), Class II (insiders), and Class III (well-funded organizations or nation-states). Reported attacks can be quickly analyzed and classified so that an appropriate-level response is issued based on the severity of the detected attack.

System architecture

The programmable defense logic is distributed through much of the hardware subsystem to provide ubiquitous coverage, with the specific location determined at design time. The location can be constructed differently for each system, providing a unique security scheme for each hardware design. Even systems composed of the same hardware design can have unique security schemes via the configurable programmable defense logic methodology, and this logic can be controlled through a secure JTAG port and/or by an embedded processor via a secure internal interface.

The security monitor is a programmable transaction engine configured to implement finite state machines to check user-specified behavior properties such as memory access privileges, bus performance levels, boot sequences, and operation signatures, all using the signals brought to its inputs to be analyzed. Signal probe networks are then configured to select a subset of the monitored signals and transport them to the security monitors. To implement different security checks, supervisor security software (or a specialized hardware controller) configures the signal probe networks to select the groups of signals to be checked by security monitors and configures them to perform the required checks. All security instrument configuration programs are encrypted and stored in one or more locations, including hardware-controlled secure flash, secure OTP memory, or software-controlled flash memory.

A dynamic wrapper is used in conjunction with the security monitor to provide a variety of real-time countermeasures. Any wrapped signal or set of signals can be controlled in real time in the event a security monitor (or the supervisor security software) detects misbehavior. Dynamic wrappers can be used to isolate logic, protect memory, reset peripherals, create decoy transactions, and erase keys or other sensitive data within memory.

Figure 1 provides an illustration of the main components of the programmable defense logic mechanism inserted in an SoC with a processor running a secure RTOS. (The SoC may be contained in an ASIC, FPGA, or a collection of off-the-shelf electronics mounted on a printed circuit board assembly.) Additionally, Figure 2 illustrates the hardware and software architecture where the programmable defense logic is configured and controlled by supervisor security software that runs in a protected software area and performs a variety of functions, such as managing the time-sharing security monitoring functions, activating countermeasures, and more.

 

Figure 1: Illustration of the main components of the programmable defense logic mechanism (shown in blue) inserted in an SoC with a processor running a secure RTOS.

(Click graphic to zoom by 1.5x)

 

 

Figure 2: Illustration of the software and hardware architecture.

(Click graphic to zoom by 1.3x)

 

System security checks

System security checks are application-dependent and circuit-dependent. The programmable defense logic element checks both the operation of the hardware and the integrity of the software. The checks target the entire SoC without distinguishing between the secure and non-secure environments. A first category of checks is looking for a set of user-specified security violations such as:

• An attempt to access a restricted address space
• Denial of service
• A change in static characteristics (for example, checksum) of loaded software
• An unexpected output change on a disabled core (for example, an internal logic block)
• An illegal mode of operation on a core
• A change in a dynamic characteristic (for example, signature) of code execution
• Excessive resource utilization – beyond some defined limit
• An attempt to tamper with the boot or BIOS code
• Clock glitching and clock modification attacks
• Tampering attacks that change environmental conditions such as temperature or voltage – requires analog sensors with A-to-D converters coupled with a security monitor

The second category of checks examines general correctness properties (that is, assertions) of system behavior. The rationale for assertion checking is that tampering attacks often cause the system to operate in an incorrect way. Some checks will be based on assertions used in predeployment simulation to verify the correct implementation of the standard communication protocols used within the SoC (AMBA, PCI, and so on) or the behavior of a specific block.

All checks are prepared and verified predeployment in a secure environment, and their corresponding configurations are preloaded into one or more secure SoC memory locations. Not only are these configurations encrypted, but they are unique to each design – and difficult to understand without access to the functional design database. Moreover, in a powered-off state, the programmable defense logic is “blank” (unprogrammed); thus, its function is concealed from unauthorized persons and attackers trying to reverse engineer the system. The programmable defense logic is invisible to both the mission logic and the application software running in the non-secure environment. As such, these security functions can be hidden from “untrusted” system and chip manufacturers and/or others with access to the system in the supply chain.

Implementing countermeasures

When the defense logic detects an attack, it reports it to the supervisor security software via a high-priority or privileged “security” interrupt, along with information detailing the nature and location of the attack. The supervisor security software analyzes the received information, determines the severity of the attack, and deploys the appropriate countermeasures.

The defense logic implements countermeasures by controlling specified signals. For example, if a core exhibits illegal behavior, various countermeasures may isolate that core by disabling its clock, powering it off, holding it in a reset state, or forcing safe values on its outputs. In the software domain, a corrupted routine may be reloaded from the memory or disk. Urgent countermeasures that need to be deployed in real time can be implemented directly by security monitors without requiring supervisor security software.

The programmable defense logic can also be deployed within fail-safe and recovery security applications. System-level countermeasures and recovery may combine techniques such as provision of fail-safe states, spare logic to replace misbehaving logic, and check pointing to return the system to a known-good state.

Taking action

Securing our military electronic systems is critical to the nation’s future. The first step in achieving this is to begin incorporating hardware- and software-based security measures early in the design stage to ensure the most comprehensive protection against the serious threats posed by piracy, reverse engineering, and unauthorized use.

Paul Bradley is chief technical officer of DAFCA, Inc. He has more than 20 years’ experience in electronics and systems design, and specializes in product development and engineering leadership in emerging technology markets. He has held numerous engineering and technical leadership positions at Motorola, Nortel, CrossComm, Sonoma Systems, and Internet Photonics prior to joining DAFCA. He can be reached at [email protected].

DAFCA, Inc. 774-204-0220 www.dafca.com