Patent Application
20090271877
1. Technical Field
The present teaching relates generally to methods and systems for security against tampering. More specifically, the present teaching relates to methods and systems for securing an embedded system against tampering.
2. Background of the Disclosure
An embedded system may be a single semiconductor device, an FPGA or ASIC that contains processors and corresponding software instruction, or a printed circuit board assembly containing multiple FPGAs and/or ASICs, discrete or embedded processors as well as additional hardware circuitry. With the advances made in computing, more and more complex systems are being constructed within smaller and smaller physical devices. Such physical changes have enormous impact on security as private or proprietary information is entered, stored, received, and transmitted by such small computing devices. Therefore, designers and manufactures of such embedded systems must take measures to secure the system itself to prevent intellectual property or proprietary data contained therein or transferred through the embedded system from being compromised.
There are different methods for securing such systems, including but not limited to encryption and obfuscation of both the hardware and software components and information transfers in-between. However, the incremental cost for securing such systems often limits the extent to which such measures can be implemented. Reasons for such limitations include that embedded systems are often utilized within applications such as cellular phones, personal digital assistants (PDA), and portable media players where low cost is of primary concern.
The cost for implementing security measures in an embedded system often makes it financially infeasible to deliver embedded systems solutions that are desired in the market place. Moreover the economics of hardware security methods are further complicated by the fact that once a hardware system is compromised, it is usually cost prohibitive to patch or upgrade the hardware. Without effective counteracting measures, the underlying embedded systems remain vulnerable.
The inventions claimed and/or described herein are further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:
a) illustrates an exemplary implementation of a logic which can be programmed to elect one or more particular security functions based on a program code, according to an embodiment of the present teaching;
b) illustrates an exemplary security function that is capable of reacting to a detected hazard condition by controlling an output signal, according to an embodiment of the present teaching;
The present teaching relates to security measures to improve hardware and software assurance against tampering in an embedded system. The present teaching discloses systems comprising custom hardware devices such as FPGAs and ASICs, processors and software that runs on one or more processors and interacts with other circuitry within an embedded system. The security systems and methods disclosed herein bind hardware and software systems with obfuscation to make it harder for the embedded system to be compromised. In addition, the disclosed systems and methods are capable of reacting to a detected security breach to prevent harm potentially imposed on the embedded system. Because the disclosed security systems and methods are highly configurable, programmable, and can be dynamically re-programmed in a manner specific to each and every individual device, they provide a higher level of protection than any prior art systems.
The software subsystem contains a mission application 110-a, security function 110-b, and program codes 110-c. The mission code is a set of software instructions being executed on the hardware subsystem 120 defining the overall functions for the embedded system 100. The security function 110-b is a set of software instructions being executed on the hardware subsystem 120 to secure the embedded system 100. The program codes 110-c define or program the functions to be performed by the programmable logic subsystem 130.
The programmable logic subsystem 130 binds the hardware subsystem 120 and the software subsystem 110 and operates to provide security protection for the software and hardware subsystems against tampering. The programmable logic subsystem 130 can not only detect tampering but also react to such detected security hazards to prevent harm from being done to the embedded system 100. In some embodiments, the programmable logic subsystem 130 is capable of, as shown at 140, observing, analyzing, or even controlling (modifying) information exchanged between the hardware subsystem 110 and software subsystem 120. In addition, the programmable logic subsystem 130 may be capable of observing, analyzing, or controlling (modifying) information exchanged between different hardware components, such as DMA transfers, state machine transitions, etc. This is shown at 150 in
The programmable logic subsystem 130 is a system that can be configured flexibly to connect or tap into any parts of the hardware subsystem. For instance, the programmable logic subsystem can be configured to tap into an arbitrarily distributed set of components in the hardware subsystem 120. Based on specific application needs, the programmable logic subsystem 130 can be configured differently to monitor different parts of the hardware subsystem 120. For example, the programmable logic subsystem 130 can be configured to observe various types of information in and out of different hardware components such as information 260 flowing through the information exchange interface (240) and information 250 among different peripherals of the embedded system 100.
The programmable logic subsystem can also be configured to monitor different hardware components including memory 210, processor 220, as well as the peripheral (230). Such configured connectivity allows the programmable logic subsystem 130 to track and analyze signals observed at configured locations in the embedded system for the purposes of identifying correct and incorrect embedded system behavior.
In some embodiments, the programmable logic subsystem 130 is capable of being configured to perform concurrent tasks, e.g., making multiple observations, performing a plurality of analysis, and carrying out different control functions, all at the same time, with respect to, e.g., the same or different system components. For example, the programmable logic subsystem 130 can be configured to operate on multiple information exchange interfaces concurrently while performing different functions on one or more of such interfaces.
The process to configure the programmable logic subsystem is to determine, at least in part, the locations in the hardware with respect to which security functions are to be performed. As discussed above, the flexibility in the configuration of the programmable logic subsystem 130 to monitor anywhere in the hardware system makes the security measure practically ubiquitous and capable of being application dependent. Another characteristic of the disclosed security method is that, in addition to being configurable, the functions that the programmable logic subsystem 130 perform in operation to counter the tampering activities can also be programmed or re-programmed, making the security measure dynamic and harder to compromise.
The programmed functions, which potentially can be dynamic, are to be executed by the programmable logic subsystem 130 in order to monitor various locations configured to be monitored. Since the specific functions programmed to be executed to detect tampering may change over time, this characteristic makes the embedded system 100 more secure, thus, making the security protection of the embedded system 100 more obfuscated and difficult to tamper.
According to the present teaching, the programmable logic subsystem 130 can be programmed via program codes. In some embodiments, as shown in
Whenever the program codes (either 270 or 280) are input to the programmable logic subsystem, the programmable logic subsystem is re-programmed. The re-programming can occur at any point in time, so that the security function performed by the programmable logic subsystem can be changed dynamically (“on-the-fly”). The programmable logic subsystem comprises programmable logic structures that do not, in and of themselves, indicate the functions that they can perform. Their functionality is obfuscated due to the programmable nature/structure. Such structure and programmable characteristics can be found in U.S. Pat. No. 7,058,918, entitled “Reconfigurable Fabric For SOCs Using Functional I/O Leads”, assigned to DAFCA, Inc. According to the disclosure therein, a programmable logic system can include a core and a wrapper, where the wrapper may reconfigure the core based on some event occurred.
Therefore, the programmable logic subsystem 130 is a highly customized collection or fabric of discrete programmable components, which can be assembled in a unique fashion for each embedded system design. Such a programmable logic can be implemented as a core or a wrapper, as detailed in the above referenced patent. The unique and customized nature of the programmable logic subsystem can be defined by the embedded system designer.
In addition, the programmable logic subsystem can be programmed in part or wholly, depending on the program codes that are input to the programmable logic subsystem. The program codes may be chosen based on different requirements of specific security functions desired. Furthermore, in some embodiments, the programmable logic subsystem 130 can be programmed to perform a unique function on each individual embedded system manufactured. For instance, each embedded system may optionally contain a unique ID (a key) that, together with the program codes, may define a specific set of programmable logic subsystem functions that is unique for that particular embedded system manufactured.
This provides protection against a multitude of devices being compromised subsequent to a single device being compromised. For example, a hacker may identify a means to compromise a single device by substituting a portion of software code within the mission application. Such intrusion will not affect another devices because this second system will be protected by a different set of security measures (monitors for example), which likely will detect the intrusion and take countermeasures.
a) illustrates an exemplary implementation of a logic which can be programmed to select a particular security function based on a program code, according to an embodiment of the present teaching. Program codes are supplied to a look-up table 410 and the output of the look-up table 410 controls the selection of either a sequential circuit 420 or a combinatory circuit 430 being selected to output signals to a routing block 440.
In some embodiments, the programmable logic system 130 can control certain hardware component or various signals (logic) connected to or within the hardware or peripheral components. Such control functions allow the programmable logic subsystem 130 to react to incorrect system behavior detected in the embedded system 100 and to counteract security breaches. For example, the programmable logic subsystem 130 may react to a detected security breach by electing to, e.g., shutdown a component or system, obfuscate a signal or transaction, or initiate a software exception, etc.
b) illustrates an exemplary security function that is capable of reacting to a detected hazard condition by controlling the output signal, according to an embodiment of the present teaching. There are a plurality of signals 450-a, 450-b, 450-c, and 450-d connecting to the input terminals of the corresponding hardware gates 460-a, 460-b, 460-c, and 460-d. There is a programmable logic subsystem that performs a PLS function 470. The PLS function 470 taps the four input signals 450-a, . . . , 450-d and whenever a certain condition is detected, e.g., when all inputs correspond to zero, the PLS function 470 reacts to the detected condition by sending a control signal to the hardware components 460-a, . . . , 460-d to, e.g., force these components to produce a certain output. The PLS function 470 may be designed to detect an abnormal condition and then react to control the behavior of the hardware components to prevent potential harm caused by the abnormality.
As seen herein, the overall security measures provided to the embedded system 100 comprise the security function(s) 110-b performed by the software subsystem 110 as well as the security functions programmed in the programmable logic subsystem 130. Since the security functions performed by the programmable logic subsystem 130 can be programmed via program codes, the overall security or hardware/software assurance provided to the embedded system 100 is therefore also programmable. As the program code can be dynamically downloaded by the software subsystem or externally input to the programmable logic subsystem, this provides additional protection to the embedded system against tampering.
As illustrated in
As described, the overall system security functions can be customized and made unique. In addition, the designer of the embedded system is not the only one who can define the security functions; the subsequent users may also dynamically determine the security measure for the system. Below, different embodiments for implementing the disclosed security methods and systems are described. It is understood that such described embodiments are for illustration only and they are not limitations to the present teaching.
The embedded system 100 with the disclosed security system and method incorporated therein can be realized in different ways.
As can be seen, the software subsystem code (530) is produced via a process where the original mission application (510) is subjected to the software security code insertion (at 520) which is to interact with the programmable logic program code generation function (540) to determine how to program the security function(s) to be performed by the programmable logic subsystem. The hardware subsystem and programmable logic subsystem are created via a process in which the original hardware source code (550), e.g., verilog or RTL code, is subjected to a programmable logic insertion function (560). The programmable program code generation function (540) is informed by the programmable logic insertion function (560) regarding the nature of the customized and unique structures inserted into the system. The PLS program code generation function (540) used can be, e.g., the Clearblue Silicon Validation Studio (CSVS), available from DAFCA, Inc., Natick Mass., U.S.A. The functions that can be performed by the programmable logic subsystem 130 can be user defined via 540. The security functions carried out by the software subsystem 110 can be defined by a user at step 520.
In some embodiments, the security function carried out by the software subsystem 110 can be implemented so that the programmable logic subsystem monitors the mission application instruction address space to ensure some predetermined address locations between the pre-defined start and end address. In some embodiments, when a watchdog timer tick interrupt is generated by a hardware peripheral with the hardware subsystem, the programmable logic subsystem initiates a checksum calculation on an instruction code located in a pre-defined address space. The expected checksum may be stored within the program code. Multiple instruction codes may be designed to sniff different address locations and the sniffed information may be analyzed over a period of time (multiple timer ticks).
Other exemplary implementations are also possible. For example, within a critical application thread in a known instruction address space, a specified set of address locations are read or written at specified intervals. The read and write values, sequences and latencies relating to the address space in use may be monitored by the programmable logic subsystem 130 to ensure that certain patterns are maintained. As another exemplary embodiment, a pseudo-random value may be written within a body of mission application code, into a register of the programmable logic subsystem. The programmable logic subsystem may then calculate a return value based on the input value and return an expected value to the software. The return value may be designed as a function of the program code loaded into the programmable logic subsystem, which can be changed dynamically. For example, different program codes can be loaded on odd and even days to introduce some dynamically changing security measures. Such dynamic programmable logic program code may call for a calculated return value to be a function of the present date—meaning its value will change dynamically based on a variable unknown to the ordinary user. When an incorrect return value is encountered, the software subsystem may then react to the situation, e.g., throw an exception or halt the operation.
The disclosed security system and method enable important and useful characteristics. For example, the disclosed approach provides multiple layers of obfuscation and obstruction against tampering. A customized programmable logic subsystem can not only detect abnormality but can also react to the abnormality to protect the embedded system. The security measure put in place to protect the embedded system in terms of hardware/software assurance can be updated or upgraded at any time based on needs to proactively or reactively address new security threats. The programmable logic subsystem is not a static IP block but a fabric overlaying the hardware subsystem. The fact that the RTL form or gate-level netlist form of the programmable logic subsystem function is not defined or represents an un-programmed resource makes it much harder to be compromised. Furthermore, since the programmable logic subsystem is used in conjunction with the software security function, which prevents the software image from being lifted from the embedded system, there are multiple layers of protection against a security breach.
The reason that those characteristics make an embedded system more difficult to compromise is that an intruder has to discover and reverse engineer a multitude of complex hardware and software systems and interactions thereof. For example, the software security scheme provides a benefit to an embedded system because it protects the embedded system by periodically loading a program code that can be used to re-program the programmable logic subsystem and, hence, dynamically alter the security measure used for the security check. For example, the areas to be checked may be changed. The method used to check such targeted areas may also be dynamically changed. In order for an intruder attempting to compromise the mission application code through additions, subtractions, or replacements, one will likely need to overcome whatever dynamic software protection mechanisms that are put in place, which would make it very difficult. For example, in order to break into the embedded system without being detected, an intruder has to discover and comprehend the code of the security function that is responsible for loading the program code(s), discover and comprehend the meaning and function of the loaded program codes with respect to the programmable hardware subsystem, which further requires the intruder to discover and comprehend the hardware structures of the programmable hardware subsystem. To the extent that an intruder attempts to compromise such a system through trial and error, they must overcome the apparent pseudo-randomness of detection and actual intrusion detection. The intruder will also have to overcome the countermeasures, which can include dynamic alternating security measures, various countermeasures that are already operational such as complete or partial shutdown, additional obfuscation methods and increasingly aggressive security functions through the activation of addition program codes, either internally or externally.
Variations and exemplary implementations of the disclosed security system and method include also the means to activate the programmable logic subsystem while the embedded system is in operation. In some embodiments, the programmable logic subsystem 130 can be configured to be automatically activated when the embedded system 100 is in operation. In some embodiments, the programmable logic subsystem 130 may be triggered, via some kind of mechanism, in order to be operational. Different exemplary embodiments to activate the programmable logic subsystem are described below. They are merely exemplary and not limiting.
In some embodiments, the programmable logic subsystem 130 can be triggered by the software subsystem 120 when the security function 110-b of the software subsystem 110 is executed.
The security function 110-b can be made operative in different ways. For example, when the mission application 110-a is executed, since the security function 110-b may be a part of the software code (inserted into the mission application code), the security function can be executed during the process. In some embodiments, the security function may be made operative independently. For example, the security function may be activated upon being uploaded and being executed prior to the execution of the mission application.
In some embodiments, the security function 810 may be inserted into the mission application code in a distributed manner, as illustrated in
In some embodiments, the security function inserted in the mission application may also contain instructions that, when executed, serve to deactivate some specific functions that have been previously programmed to operate in the programmable logic subsystem. For instance, a piece of security function shown as 850 in
The trigger 810 may also be activated via other means. In some embodiments, the trigger 810 may be activated by an externally entered program code. In some embodiments, the trigger 810 can be self-activating in an automated mode. For example, whenever the embedded system is powered on, the trigger 810 may activate itself and then retrieve program codes from a pre-determined storage, e.g., memory or removable memory, and program the programmable logic subsystem. Under such a hardware activation scheme, the hardware subsystem may optionally incorporate a special purpose component as the trigger. This is shown in
While the inventions have been described with reference to the certain illustrated embodiments, the words that have been used herein are words of description, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Although the inventions have been described herein with reference to particular structures, acts, and materials, the invention is not to be limited to the particulars disclosed, but rather can be embodied in a wide variety of forms, some of which may be quite different from those of the disclosed embodiments, and extends to all equivalent structures, acts, and, materials, such as are within the scope of the appended claims.
| Number | Date | Country | |
|---|---|---|---|
| 61048306 | Apr 2008 | US |
