Rick Gentile

Locking Down Intellectual Property
April 2007

At Analog Devices, we have the privilege of working with developers bringing diverse embedded applications to market. The common ground between spaces such as digital radio and portable media players may not be obvious, but similarities under the surface bubble up into general requirements that we channel back into our products. One of the newest: security.

Developers want to secure their intellectual property for a lot of important reasons, including financial and competitive ones. Portions of your code may do something that nobody else knows how to do. You may be using libraries from an outside vendor that you're obliged to secure. In many cases, the motivation is as simple as wanting to authenticate or validate that the software running on a hardware platform is, in fact, authorized to run on that platform.

Of the different techniques that enable security on an embedded processor, most rely on obfuscating the hardware access points into the processor. For example, a designer can make it difficult to access the flash memory holding the code. Maybe debug access points such as JTAG are not brought out to pins easily accessible with a scope or analyzer. Perhaps the memory from which the code is executing resides inside a package that can't easily be accessed without damage to the system.

Protecting IP is one aspect of this discussion. Authentication is another. Hacking a system can easily be done by replacing the code intended to run on a processor with a modified version that does something unintended, and perhaps malicious. Although protection mechanisms can be implemented in a variety of ways, many typical mechanisms can still be bypassed without much effort. Without stronger protection in place, a hardware platform can in effect be hijacked.

While hardware techniques mostly involve obfuscation, software techniques use a combination of obfuscation and encryption. The problem with software-only methods comes from where you run the initial trusted code and where you "hide" the keys in your system.

We are seeing that security is key to today's rollout of embedded systems. In many cases, lack of these capabilities can limit where a product is sold (including complete regions) or may even preclude release altogether.

All of this went into the thinking behind our recent introduction of Lockbox Secure Technology (which I'll call "Lockbox" for short) on Blackfin processors. Our recently announced BF54x and BF52x families provide Lockbox as an integrated feature. We use a standards-based approach that combines hardware and software you can use to facilitate a secure operating environment.

On the memory side, one-time-programmable (OTP) memory and a secure internal ROM provides a trusted starting point. For example, the OTP can be used to hold keys while the secure ROM provides the basic authentication code and framework.

The processor itself also includes an integrated secure-state machine, which allows operation in a secure mode. In this secure mode, you can close the "windows" into the processor memory from outside access. In addition to authentication, the technology also provides a secure infrastructure that lets you augment authentication with your own encryption and decryption schemes.

Lockbox augments another Blackfin architectural feature that allows the processor to be operated either in a Supervisor (or kernel) mode or a User mode. These modes offer a different type of protection that can be used in conjunction with Lockbox to expand the security capabilities of your end system.

IP infringement and destructive hacking being the problems they are, locking down your embedded code to deter tampering makes sense. Lockbox on Blackfin provides the flexibility to implement the more complete security mechanisms called for by future embedded designs. If you haven't already checked it out, read the recent whitepaper: The Next Generation of Secure Technology for Digital Media Devices (pdf, 303,104 bytes).

Rick Gentile leads the Blackfin Processor Applications Group at Analog Devices. He is co-author of the book, Embedded Media Processing.