Postings and Rantings on Design Security
(updated
30-JUL-01)
Embedded
System Design Security
The following is a collection design
ideas culled from various personal postings.
In most microprocessor (8032, DS80C320,
PowerPC, Pentium, etc.) or FPGA (Xilinx, Altera, etc.) applications, the configuration
code or application program resides in a separate, external memory. Some designers
are concerned about the security of their application because the external memory
could be simply copied.
There are a number of applicable
techniques to improve the design security for these designs, some costing nearly
nothing to a few costing a few dollars or more per system.
As can be seen by searching other
posts on this site, don't be lulled into a false sense of security by using
a device with on-chip "secure" memory. Even these devices can be hacked by a
sophisticated attacker.
As the old adage goes, "Keys exist
to help honest people remain honest." A determined thief will go to enormous
lengths for valuable booty or if desperate enough. As a general rule, use as
many of the following techniques as economically viable if you are truly concerned
about the problem. However, before adding layers upon layers of obscurity to
your design, ask yourself honestly how much security is really required for
the application. Once you know the answer, here are some techniques that I have
seen successfully used to thwart potential "Copiers".
Black-Topping or Custom
Marking
The Copier first needs to know which
device you are using. One easy method to secure a device is simple "black-topping"
where you cover the top of the device with black paint or remove the top marking
using a chemical solvent. Unless the copier knows which device is buried within
the innocent-looking package, it's difficult to reverse engineer. Black-topping
is more difficult on laser-marked devices where the part number is actually
etched into the package. Black-topping is relatively cheap and particularly
effective. The Copier either needs prior knowledge of what components are on
the board or the ability to open package and observe the die under a microscope
to identify the manufacturer and part type.
One problem with black-topping is
that the Copier knows right away which parts are interesting. Just look for
the parts without a label. There must be something interesting inside. An easy
solution to this might be to purchase labels to affix to the top of the device,
possible with your company's logo. I would still recommend black-topping the
device underneath the label. Labels are easily removed and you still don't want
the Copier to know which device is used.
Also, black-top the external memory
device as well, unless this will drive your manufacturing people crazy. Fortunately,
the pin marker on most black-topped devices is still visible.
Some manufacturers, including Triscend,
offer custom marking options where you can put your own permanent top mark.
This makes the device look like an obscure part or your own customer ASIC. The
cost impact is usually minimal but there are usually some volume purchasing
requirements-e.g., you have to buy more than a few hundred or a thousand.
Swapping Address and
Data Pins to External Device
To thwart a Copier that will simply
make a copy of the external memory device and drop it onto his copy of your
board, swap the order of some of the address and data pins interfacing the processor
or FPGA to the external memory. Ideally, some of the address and data routing
would be on inner layers of the PC board. Why make it easy for the Copier? Sure,
the Copier can buzz out the connections in about half an hour but more than
likely, he'll simple connect D0 on the processor or FPGA to D0 on the external
memory, etc. Make him spin a board or two.
The cost is minimal but you may need
to write software to perform the bit-swapping or location-swapping on your Flash
image. On the Triscend part, if you download through JTAG, the bit-swapping
is done automatically.
Embed Device and Configuration
Memory in Epoxy
To make it more difficult for the
Copier to observe the contents of the external memory or view the data as it
is loaded into the processor or FPGA, embed the devices and their interconnections
in a block or a smattering of epoxy.
A similar technique that I've seen
used is to place the external memory under another component, effectively hiding
it. This is particularly easy if you are using surface mount Flash devices and
anything with a socket or connector.
Battery Back-up Device
Some devices allow you to download
the program into internal SRAM and then battery back the device. For example,
on the Triscend E5 devices, you can download the programmable logic initialization
data directly into the internal configuration memory and your application program
into internal SRAM. You can then set a few security bits to disable the JTAG
interface and the memory interface in order to prevent further probing. In this
case, the embedded 8051 executes code stored in the internal RAM. As long as
VCC stays above 2.4V, the device retains data in internal SRAM-safe from prying
eyes or scope probes. The typical retention current on an E5 device is between
5 to 20 uA, which is equivalent to years of retention with a lithium cell.
Similarly, you can protect your "critical"
code in internal SRAM and fetch the bulk of your code from external memory.
I've seen battery back-up used in
security conscious applications like financial transaction terminals and sonar
buoys. To make the devices really secure, enclose the parts in a metal box that
also routes power to the devices. To look at the devices, you have to open the
box and power disappears, effectively erasing the parts.
Legal Protection with
a Copyright Notice on Board and in Flash Code
The initialization data and program
loaded into the device may qualify as a "computer program" as defined in Section
101, Title 17 of the United States Code, and might therefore be protected under
international copyright laws (I am not a lawyer and cannot give legal advice.
Contact your favorite legal authority for the best way to legally protect your
design.). Personally, while the legal route may hinder reputable companies in
the industrial world, it provides little or no protection on most of the planet.
The only reason to pursue this avenue is that it's relatively easy and cheap
to do. Place an appropriate copyright notice on the external memory device or
adjacent to the device on the PC board. The copyright notice could be as simple
as
© 2001 ABC Industries
but something like
Program code and data
© 2001 by ABC Industries. All rights reserved.
is preferred.
If you want to go this route, go
all the way. You can add a statement on the PC board silkscreen like
Program code and data
© 2001 by Acme Industries. All rights reserved.
This program is proprietary to ABC Industries and copying or other use of
this program is expressly prohibited, except as expressly authorized in writing
by ABC Industries.
This same text should appear as an
ASCII string in your external memory code. Likewise, include the same notice
in all documentation or literature that accompanies the product.
Additionally, place some non-functional
code in the external memory. That way, you can easily prove if someone has legitimately
copied the functionality of your design versus directly copied the external
memory.
In my opinion, here are the disadvantages
of the legal protection route. First, all those notices wave a big red flag
in the face of a potential Copier. You point out which parts of the design are
valuable. Second, the "swift and speedy" justice system can take decades and
lots of money to determine the outcome. Sometimes is pays off--Avant!/Cadence
and a US$195,000,000.00 settlement--and sometimes is probably doesn't even
cover legal fees--Xilinx/Altera
settle for US$20,000,000 after a decade of haggling. Similarly, the legal
route probably affords no protection in the far-flung corners of the globe but
you have to ask yourself if you really believe that you have any competitors
there.
Use an Inexpensive
"Secure" Companion Device
A number of applications use an unsecured
"powerful" device and off-load the security function to some sort of inexpensive
device with embedded security options.
For example, you can create simple
copy protection relatively cheaply. You could implement a small pseudo-random
sequencer (LFSR) in a cheap PAL, GAL, CPLD device or even a cheap microcontroller
(typically less than US$1.00), which may already exist on the board anyway.
The "powerful" unprotected device sends data to the "security" device and compares
the output against an expected value. If "powerful" device does not receive
the appropriate value, it simple does not boot or operate. The LFSR need only
be a few bits to thwart a simple copier.
This technique easily thwarts the
unsophisticated Copier who simply copies the PC board and external memory. It
also requires a more sophisticated Copier to disassemble the code and figure
out how to thwart your security system. I generally include a few "security"
checks throughout my program and use different techniques for sending or checking
the data (bit reversed, inverted, etc.). The sneakiest that I've seen is placing
the "security" check in an infrequently-called interrupt service routine. The
system just seemed to crash randomly after about 15 minutes!
I've seen a number of techniques
used here, some costing as little as US$0.40 in production. I can write another
few thousand words on which technique to use and when. If you have specific
requirements, feel free to contact me. Many times, you can leverage another
component already in the system as the "security" device. If not, I can recommend
a technique our Asian sales team has developed.
Be Obscure
As programmers, we are all taught
to be clear and concise (though you probably can't tell be reading this post).
To thwart potential reverse-engineers, make your code a bit more obscure and
difficult to figure out. Each minute that a Copier spends attempting to reverse-engineer
your code is one minute closer to driving him insane. Make him admit defeat
by including a few nasty code tricks. Hash tables can be particularly nasty
though you don't see them much on 8051s. However, lots of indirect addressing
and bank switching can be mean-spirited.
A word of warning, however: Be sure
to thoroughly comment the trick that you used right there in the source code.
I MEAN IT! Obscurity sometimes even fools the original programmer, especially
when called in debug a problem after months of inactivity.
More Ideas?
Do you have other ideas on the subject?
I'm always interested in hearing about real-world techniques for protecting
(or cracking) designs and for protecting the jobs of designers that innovate
and create value.
