In this post I’m going to discuss protecting your system. I’m assuming that your system consists of a circuit board and, perhaps, a processor with code in it. Why would you want to protect your board? You may want, or be obliged, to protect some intellectual property. The system may contain private data that needs to be protected. You may want to keep control of your hardware to get a return on your investment.

How do you go about protecting your project so that it can’t be copied quickly? I’ve seen a few approaches, some naive, some clever, and some that actually work. This week I’ll be looking at some methods of avoiding unwanted duplication of products.

Using the legal system

Assume you have some sort of product that uses electronics, you have a circuit board that is the heart of the system. Can you keep people from copying your circuit board with patents or copyrights? In a word, no.

There is an international treaty that deals with semiconductor mask copyright that gives the company 10 years of copyright protection, and a circuit board is like a chip, but bigger. Unfortunately, the treaty spells out, very specifically, that it is limited to devices built on a semiconductor substrate, and since circuit boards are made on fibreglass, ceramic, plastic, phenolic, or any number of other insulators, they are not covered by the treaty.

In copyright law, you would expect that the lines of the traces would be covered as an art work. Electrical engineers even refer to the traces as art work. But, there’s a problem, the American copyright act states:

Such works shall include works of artistic craftsmanship insofar as their form but not their mechanical or utilitarian aspects are concerned; the design of a useful article, as defined in this section, shall be considered a pictorial, graphic, or sculptural work only if, and only to the extent that, such design incorporates pictorial, graphic, or sculptural features that can be identified separately from, and are capable of existing independently of, the utilitarian aspects of the article.

I think the phrase “features that can be identified separately from, and are capable of existing independently of, the utilitarian aspects of the article” would cover traces that are laid out to look like an otter. If you make funky pictures in copper that are not used in the circuit, those would be covered by copyright.

Since the traces on the circuit board are actually utilitarian, they are not covered by copyright. The American copyright act continues:

A "useful article" is an article having an intrinsic utilitarian function that is not merely to portray the appearance of the article or to convey information. An article that is normally a part of a useful article is considered a "useful article."

The silkscreen layer - the lettering that has the component identifiers, logo, copyright notice, and so forth - is covered by copyright because it is not intrinsically utilitarian and it is used to convey information.

You can’t patent a circuit board. You may patent an invention that is novel, useful, and not obvious. A circuit board could be a component of an invention that is useful, but a circuit board is not novel, it’s not useful by itself except perhaps as a fly swatter, and circuit boards have been around for a lot of years, so they are quite obvious.

If your board consists of an FTDI chip and a couple of connectors, you’ve got a PCB that cannot be protected, and a bunch of parts that someone can buy from Digikey. You’ve got no protection.

Microcontrollers to the Rescue

Since you are reading this post on embedded.fm, I expect that you are comfortable with using microcontrollers. There is a level of obfuscation that comes with using microcontrollers, they are often useless unless you have the firmware.

The original source code for the program running in the microcontroller is covered by copyright, but is the compiled machine code? As it is a utilitarian distillation of the source code, and by being an intangible thing (just a pattern on disk or in a chip) it might not be.

According to the US copyright act:

A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.

Machine code would be software that is used directly by the computer, source code would be used indirectly.

But, in Apple Computer Inc. versus Franklin Computer Corp., 1982, the judge ruled that object code constituted a work of literary art and was eligible for copyright protection even if stored in ROM.

Copyright covers the expression of an idea, not the idea itself. The image in ROM is covered by copyright but not the function that it performs. We can see this in the clean-room reimplementation (with no access to the source code) of the IBM PC BIOS by Phoenix Technologies, and the functional reimplementation of Windows under WINE.

This leaves us with a circuit board that can be copied easily, a set of chips that can be on your desk tomorrow by noon, firmware that is possibly covered by copyright, but the ideas implemented in the firmware are not.

All that a duplication group would have to do is write replacement firmware to run on the copied circuit board. This can be made even easier if they can deduce how your software works by extracting it, decompiling it, and reimplementing it. This assumes that the duplicators don’t just take a copy of the firmware and use it verbatim, since you did not register your copyright in their country and that the people involved respect your copyright. What else can be done?

Obfuscation

If you are working with a microprocessor, which has external ROM and RAM, you’re in trouble. ROMs can be removed from the board and simply read.

You might think that the content can be encrypted, but unless your processor has the facilities to decrypt the instruction stream while in flight, this won’t work. Note: There are some NXP/Freescale processors which support ROM image compression where a Huffman encoding is done on the ROM image, then the Huffman decoding key and compressed image are stored in ROM. However, this wouldn’t take very long to decompress, since the key is given. Clever for saving ROM space, but ineffective for protection.

One clever method to thwart duplicators would be to scramble the address and data lines to your ROMs. The image pulled out would not decompile because the bits aren’t in the correct order. This is, again, clever but not effective, since you can figure out the scrambling by buzzing out the address and data busses with a multimeter.

If your ROM is internal to the processor, but the RAM is available on an external bus, you may be able to take over the address and data busses with the processor halted, drop some code into RAM, adjust the stack so a return from subroutine returns to your RAM routine, then use the processor to dump the ROM.

For more ideas on dealing with protecting exposed memory systems see Fisher in Embedded Systems Programming. The article is a bit old, and microcontrollers have moved on to internal RAM and ROM, but it does give some methods that are helpful in exposed ROM systems.

Programming Port Removal

The next most obvious place for a someone to copy your system would be to read the executable out from the debugging port. ARM processors have JTAG and SWD programming ports, MC68300s and ColdFires use BDM, and Microchip PICs have their ICSP. All of these can be used to take over the processor and read out the code.

The pads for these connections are a production and debugging convenience, but also an entry point for the duplicators. You might think that it is clever to leave them off, but you can always attach directly to the processor pins, or in the case of a ball grid, remove the processor to expose the JTAG pads.

Locking Up

The real way of protecting your design is twofold.

First, if you are getting your boards produced by someone other than your own company, never send out your production firmware. You can give board testing code, but then have the boards sent back to your facility where the real code is installed. You might think that this is a hassle and increases costs, until you find out that there is a second shift producing your product and you will never see any of the revenue.

You could send pre-programmed processors, but there is a thing called “spillage” which is a percentage of extra chips that are budgeted in a production run for when a tray of chips falls on the floor and is thrown away. Think of those as feeding the second shift.

Without the production firmware, your contract manufacturer can still build the boards, but to duplicate your board, they will have to reverse engineer the firmware without you handing them the keys to your design. Firmware is difficult to write, make them work for it.

Second, and most importantly, set the register bits to read lock the processor. This feature is very common in microcontrollers, but many firmware people don’t know about it (because it is not discussed in Uni, Tech school, in desktop programming, EE, or because the manual is 1700 pages long, you don’t know what this register is for, and you just want to get the board working).

After a processor is programmed and verified, the appropriate register bits are turned on permanently that prevent the processor from being read through the debugging port. What happens is, when you use the programming port to read the program out of the processor, you just get back a stream of 0x00 or 0xFF depending on the processor. The code can be executed, but never read again. The processor can be reprogrammed, but only after a complete erase is done.

Once the processor is locked, debugging is impossible through the debug port, until the processor is erased, so this is not something that you use when debugging. But don’t wait too long to experiment with locking the processor, it has to be compatible with your bootloaders and production procedures.

The first time you try locking a processor, you will panic because the processor won’t erase and unlock. You will have to search the user forums to find the proper commands to unlock the processor. Put in the code to lock the processor, test it, then comment it out and put a TODO into your bug tracking system to remind you to turn it back on before shipping.

On a Microchip PIC, there is a series of bits in the CONFIG registers that control the reading and writing of Flash and EEPROM. Be careful, some of the options make the memory unreadable by the processor internally.

On my STM32F407, the locking code looks like this:

/*
 * Arrange for the FLASH array to be unreadable from the JTAG.
 * If the RDP level isn't correct, set it so that next boot it 
 * will be correct
 * Level 0 means no protection
 * Level 1 means protected and can't be read from JTAG. 
 *         Erased when dropped to level 0.
 * Level 2 means protected from JTAG, BOOT0, and every 
 *         other read and write. Can't be erased, ever. 
 *         Don't do this, ever.
 */
//	if ((FLASH_OBInitStruct.RDPLevel) == OB_RDP_LEVEL_0) {
//		(void) HAL_FLASH_OB_Unlock();
//		/* Lock the FLASH from external reads */
//		FLASH_OBInitStruct.OptionType = OPTIONBYTE_RDP;
//		FLASH_OBInitStruct.RDPLevel = READ_PROTECT_LEVEL;
//		HAL_FLASHEx_OBProgram(&FLASH_OBInitStruct);
//
//		/* Launch the option byte loading */
//		(void) HAL_FLASH_OB_Launch();
//
//	}

Standard caveat; I’m not a lawyer, if you want a legal opinion that you can rely on, go give some money to a lawyer. This information is the best I can find, and for those that think I’m wrong, use it for entertainment purposes only.

This post is part of a series. Please see the other posts here.

It's crazy, after 38 years I still remember the combination.