CMP EMBEDDED.COM

Login | Register     Welcome Guest  
HOME DESIGN PRODUCTS COLUMNS E-LEARNING CONFERENCES CODE FORUMS/BLOGS NEWSLETTERS CONTACT FEATURES RSS RSS

Locking Down Intellectual Property in Embedded Systems



Embedded.com
Embedded systems developers want to protect their intellectual property (IP) for financial, competitive, and legal reasons. Aside from protecting their own IP, developers may be obligated to secure libraries or rights managed content obtained from an outside vendor. Failing to protect the IP of outside vendors may expose developers to legal and financial risks.

This article focuses on methods of securing IP in embedded systems. We will examine past and current approaches and look ahead to new embedded processing solutions that offer new options for developers wanting to protect their IP.

Techniques for protecting IP in embedded systems vary greatly. These techniques rely on software, hardware, or a combination of both to prevent reverse engineering and IP theft.

Software-based IP Protection
Software methods for protecting IP in embedded processors are similar to those employed in the broader software industry: anti-disassembly, anti-debug, and tamper resistance.

Anti-disassembly. Anti-disassembly techniques attempt to make the static view of an executable reveal as little information as possible about the software IP in the executable. When employed correctly, anti-disassembly techniques make it more challenging for an adversary to understand, and thus to reverse-engineer, the software.

An example of an anti-disassembly technique is self-modifying code in which a software program modifies itself at run time. An adversary viewing the software statically will have difficulty figuring out the code that actually executes at run time. Self-modifying code is interesting, but implementing it without complicating the development process is a challenge.

Anti-debug. Anti-debug refers to techniques that prevent successful debug of software. A good anti-debug mechanism is one that doesn't alert the attacker to its existence. If attackers can't detect the presence of anti-debug mechanisms in the software they are trying to reverse-engineer, they will be less likely to succeed in identifying and disabling these mechanisms.

Anti-debug consists of techniques for debug detection and for response to debug attempts. Debug detection techniques include monitoring changes in the values of debug registers, self-scanning for breakpoints or emulation interrupts, and/or measuring time delay between various points in the code execution.

Once a process detects that it is being debugged, it may respond in a manner that prevents IP theft by, for example, avoiding its proprietary algorithm and instead executing a more conventional algorithm.

Tamper resistance. Tamper resistance mechanisms are introduced into a software program in order to prevent adversaries from modifying the program. Adversaries modify software programs in order to make it behave in a manner different from that intended.

For example, to prevent software cloning " making unauthorized copies of software " a program may read and verify the unique device ID as a pre-requisite for execution. If the ID read does not match that stored in the program, the program halts itself because there is a high probability that it has been cloned and placed into a different device that has a different unique ID.

An adversary cloning the software program may attempt to patch it in a manner that makes it bypass the unique device ID check. Anti-tampering techniques hamper malicious code modifications by making the code more difficult to understand and/or by making the code likely to fail in case of tampering.

Making the code more difficult to understand may be achieved through the use of a code obfuscator. Code obfuscators are essentially compilers that perform transformations on an input program in order to produce a functionally equivalent but more difficult to reverse-engineer output program.

Making the code likely to fail in case of tampering may be achieved by calculating a hash of the software program at different points during execution. If the program was tampered with, the calculated hash value will not equal the expected value, and the program may take steps to evade the attacker.

In the absence of implementing a system with IP protection features integral to its design, strategies that intelligently combine anti-disassembly, anti-debug, and tamper resistance can provide at least some level of protection in inherently open systems.

Hardware-based IP Protection
Hardware methods for protecting IP in embedded processors attempt to drive up the cost of probing and reverse-engineering the system. These methods can be implemented at the system level, board level or chip level.

System-level protection. One example of system-level protection is a mutual watchdog scheme. A small microcontroller and processor provide mutual watchdog timer services. If either processor is halted or stops responding to the periodic interprocessor communication (i.e. halted via JTAG, removed from board, etc), the other processor performs a countermeasure such as erasure of on-board FLASH contents, removal of power to the other processor or in the most extreme case, physical destruction of the processors and memory devices themselves.

Board-level protection. Board-level protection methods can include methods which rely on obfuscating the hardware access points into the processors and data lines of memory devices. Board layout techniques and package selection can be employed to make it difficult to access critical data and signal lines.

If sensitive information is transferred over unsecured data lines between memory devices and processors, these data lines can be probed and the IP can be intercepted during booting or other memory transfers. If critical signals cannot be accessed, they cannot be probed or tampered with.

Board layout can be done using blind vias and solid power and ground planes to shield access to signal traces on inner layers. Critical data lines between FLASH and processor, as well as JTAG signals, can be placed on inner copper layers.

Selecting BGA packages with fine ball pitch and placing critical signals away from the outermost rows of balls can further complicate malicious attempts to probe signals carrying data between processors and memory chips such as FLASH or DRAM.

Placing processor and memory packages as close together as possible on the board makes it harder for attackers to locate and probe critical signals. These techniques make it difficult for attackers to access signals even when drilling through the PCB. The downside is that BGA package selections and these board layout techniques (which add layers to the boards) will increase the cost of board manufacturing.

Figure 1. Placing processor and memory packages as close together as possible on the board makes it harder for attackers to locate and probe critical signals.

Other mechanical protection methods can be employed to hide chip locations and obscure the pins/balls of the component packages. For example, encapsulation techniques can be used to cover sensitive areas of a board with opaque epoxy.

Multiple device packages can be placed inside the covered area, thus hiding each individual chip's location, orientation and labeling. This is one means for hiding signals on packages with exposed pins such as LQFP and DIP packages.

It can also be a means of preventing access to the outer balls of BGA packages and can be used to cover only critical areas or an entire board. Yet another mechanical protection technique that further obfuscates components is the simple removal of labels from device packages.

Labels can easily be removed either at the time of manufacture or via chemical or mechanical means. Many semiconductor devices are available in standard packages, making it difficult to identify the specific device without opening the package. Packages can also be relabeled to appear to be custom ASICs.

Chip-level protection. Many processors contain on-chip memory including SRAM, ROM or FLASH which cannot be easily read from outside the device. On-chip memory can be utilized to hold sensitive code and data that must be protected from access by unauthorized parties. Access to on-chip memory must be restricted from host devices, as well as from emulator and test equipment via JTAG test ports.

Access restrictions can be implemented by blowing on-chip fuses to disable JTAG, or by providing no connection of JTAG signals from package to board. However, removing access to debug test ports complicates failure analysis and system debug.

The methods described above can help secure sensitive code and data on inherently open devices and systems; however, these methods can still be bypassed. Chemicals can be used to strip away encapsulations used to mask devices.

Common hand tools can be used to overcome mechanical protections. When all else fails, x-ray inspection can locate components and determine signal connections to bypass board level protection.

Chip Decappers, Scanning Electron Microscopes (SEM), Voltage Contrast Microscopy techniques, and Focused Ion Beam (FIB) tools can be employed by well-equipped adversaries to decap chips and perform die analysis. In general, "security through obscurity" is only a temporary deterrent to a determined adversary. Without stronger protection in place, an embedded system can, in effect, be hijacked.

A new way to do IP protection
While many embedded systems developers recognize a need for security, few are adequately prepared to implement it, and security is often an afterthought for many developers. Some attempt to add on security to inherently open devices and systems using some of the software and hardware methods described above. To fulfill the requirements of developers seeking stronger IP protection, embedded processor manufacturers are developing new products with security features integral to their design.

IP protection in this new generation of embedded processors can be enabled by providing a privileged (secure) mode of operation in which only trusted code is allowed to execute. For an application to establish trust and to reach the privileged mode of operation, standards-based cryptographic algorithms can be used to implement digital signature authentication.

Only after successful verification of an application's digital signature does the processor grant the application the right to execute in privileged mode. In order for an application to successfully pass digital signature authentication, it has to be signed using a secret private key known only to the signing party and then verified using the corresponding public key, which can be stored on the processor itself. Once in privileged mode, a trusted application has access to protected memory and control over access restrictions.

Access restrictions prevent non-trusted applications from stealing, tampering with, or interfering in the operation of trusted applications executing in secure mode. Such restrictions may include disabling access via the JTAG test port, unauthorized access to on-chip memory and registers, and unauthorized attempts to change control over program flow.

How might these features be used to protect IP? Shown below is one approach using the Analog Devices' Blackfin processor (Figure 2 below). Assume that we have a software application containing proprietary algorithms we wish to protect. 

We can encrypt the application using any established encryption cipher (such as AES), store the application in flash in encrypted form, and store the decryption key in the Blackfin's secure one-time-programmable (OTP) memory.

A kernel can then be developed to load the application from flash and decrypt it. The kernel should be signed using the secret private key known only to the application developer. Upon successful digital signature authentication, the trusted kernel has access to the contents of secure OTP memory and the decryption key stored therein.

Since only the trusted kernel has access to the decryption key, and since an array of protection measures are established to prevent non-trusted applications from viewing the code of applications running in secure mode, the software IP is not visible to any non-trusted application.

Figure 2: Implementing a software IP protection scheme

Conclusion
By adding security measures that make it prohibitively expensive for thieves to steal IP, developers can help secure their systems. We've presented examples of software and hardware methods used to protect IP in inherently open systems.

Methods of employing security as an afterthought through obfuscation or mechanical protections are not as robust as implementations whose security features have been designed in from the start. A new generation of embedded processors is appearing with integrated security features that meet the growing need for more robust IP protection.

Wassim Bassalee is a SW Systems Engineer at Analog Devices. He focuses on cryptography, security, and their applications in embedded systems.

Phil Giordano is a Senior Applications Engineer with Analog Devices. He joined Analog Devices in 1998 and is currently involved in new product development of embedded processors with a focus on security features.

1

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Looking for a new job?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS





 :