DISCLAIMER: The following are my personal opinions and not the opinions of the companies for which I now or previously worked.

I'm happy to hear that you still feel that the Triscend E5 is still a "A cool part, a wonderful solution to many problems ...".

The lack of design security “problem” that you mention is common to any microprocessor (8032, DS80C320, PowerPC, Pentium, etc.) or FPGA (Xilinx, Altera, etc.) application where the code resides in a separate, external memory. I was a microcontroller or FPGA applications engineer for over 15 years so this issue has been around a long time. There are a number of applicable techniques, 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 just because it has 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 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 real-world 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 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 Obsure
=======================================
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.