Code Protection for Flash-Based Microcontrollers in Code Distribution

The package information may include: target device designation, code version, size, date, and other information useful to the user. This information can alert the operator that an older version of firmware is being used, which may reduce some of the device's performance, or that an unsupported target device is being loaded.

In today's competitive market, protecting a company's intellectual property (IP) is one of the highest priorities. Years of development may have resulted in designs that contain many trade secrets or proprietary algorithms. As flash-based microcontrollers gain more applications and integrate more features, many companies are moving away from traditional one-time programmable (OTP) microcontrollers (MCUs) and toward flash memory.

Flash memory allows real-time programming at the end of the production line, and also allows code to be modified after production. However, if it is transmitted over the Internet, the company will face the problem of IP leakage to competitors. Various methods should be adopted to control the update authorization and provide field updates in the event of leakage of product IP.

Code protection

There are many ways to protect field-configured software products, and which method is used depends on what the vendor wants to protect. Most software protection mechanisms prevent unauthorized copying of programs or data. It is very easy to copy files today, and many copies can be found quickly via the Internet. When firmware is part of a hardware platform, protecting the IP contained in the firmware is usually more important than protecting the copy of the file. Of course, if firmware updates need to be purchased, then protecting the copy is also important.

Another issue concerns the performance of cryptographic cracking in microcontroller-based products. Both the RSA and DES standards are very demanding in terms of performance and memory. Unfortunately, most microcontrollers have limited resources in both areas, requiring different encryption and decryption methods. We must provide a universal or device-specific key scheme.

Simple Password

Rolling-code generators have been used for many years in a variety of devices such as garage door locks and security access cards. Figure 1 shows how a simple rolling-code generator works. A set of bistable flip-flops with the same clock signal are connected in series, with various taps at their outputs. In the example given, Q2 is not used, and the remaining outputs are connected to a single OR function port, which gets a new input bit at each clock signal edge. The number of possible combinations depends on the number of flip-flops and the number of taps connected to the OR function port.

The outputs of several triggers are usually used as cyclic key codes. In practical applications (such as garage door locks), an identical generator is used to test key codes. As new codes are used over and over, the entire sequence will repeat, which may be after tens or hundreds of millions of key codes. At this time, it cannot be used again. In the case of garage door locks, it can prevent criminals from eavesdropping with wireless receivers and simply reproducing the key code to open the door.

In the case of code encryption, the output of the flip-flop is sent to another OR function port (A1 in Figure 2) with the data to be encrypted or decrypted. Each byte, word, or double word of the data is ORed with the selected flip-flop port and then a user-specified additional function is added. That function can be as simple as adding a constant. This process must be reversible, so the user-defined function is not random. The password determined by the placement of the flip-flop taps, together with the initial state of the shift register and the selected seed, provides the encryption and decryption algorithm. These passwords can be split according to the serial number method to provide unique passwords for specific devices. That is, the serial number of the device only provides half of the password information, and the manufacturer retains the rest of the password information. Obviously, there are many permutations of this scheme.

When a firmware update is released globally, for example, a bug update that applies to all products, a special serial number can be used. The decryption engine first tries the global code, which may be a special digital pattern. If the global code does not decrypt to the correct checksum, the unique password is used. It tells the loader what type of firmware update data the encrypted source file contains.

Transmission method

It is obvious that some kind of decoding engine and code loader must be present in the product. The techniques discussed here can be explained using a COP8 microcontroller. The target controller is the COP8CBR which contains 32KB of flash and 1KB of RAM. For field-updateable devices, it is important to note that the microcontroller must have the ability to program the flash while the program is running. The flash storing the program cannot be updated by holding the controller in reset or requiring external programming. The decoding and loader must reside inside the controller and be completely reliable. The COP8 flash product meets these requirements.

The firmware loader is a code module that runs after reset and can determine whether the current load is valid. If the loaded code is found to be invalid, the loader enters the load mode (LOAD MODE) until there is a solid program that can be operated. This can be achieved through the physical layer interface provided by the controller. COP8 can use the serial port. If the current code is valid, the loader will hand over control to the entry point of the firmware application.

Another feature of the COP8 family is the ability to use a software trap to boot a recovery mechanism. It executes opcode 0x00, which can be programmed into all unused locations. If this opcode is executed, the operation will begin from the software trap vector, causing the loader to re-evaluate the integrity of the firmware. This is a good feature for fault tolerance. If the code is corrupted for whatever reason, the loader will take control, allowing a technician (or user) to reload the firmware. [page]

The loader uses a data packet which has a header and a checksum to verify the transmission. If the packet is transmitted to the controller and the checksum is correct, the loader hands it off to the decryption engine (if it is encrypted). Inside the encrypted data there is another cryptographic checksum which gives the decryption engine a means to verify the cryptographic information. It will first apply the universal code and test the checksum, and if it fails, it will retry using the unique password from the serial number. If it fails again, it tells the loader that the firmware is invalid for this device. This also protects the code from unauthorized tampering and accidental corruption.

If the decryption engine successfully decodes the data, it will hand the data to the program routine that programs the actual flash block in the flash memory. Of course, this procedure is different for different manufacturers, and the procedure for COP8 will be given in the design example below. This program reserves a 128-byte RAM for updating the flash memory. Of course, this RAM can store application data after the loader is completed.

Design Examples

Figure 3 is a flowchart of the firmware loader with decryption capabilities. The loader uses a modified version of the Intel HEX data format that is widely used in programmers and system simulators. This allows applications to support standards and ease of use with existing architectures. The firmware loader is written in COP8 assembly language to reduce code size and take advantage of the full flash memory features of the device.

In simple terms, Intel HEX format is a data record format represented by ASCII encoding, which is used to program object code or data into the device's memory. The format consists of the following fields: a record start field using ASCII character 0x3A or ":", a data length field (two ASCII characters) with a length range of 0x00-0xFF, an offset field, a record type field, an information or data field, and a checksum field. Each field is represented by a standard printable ASCII character. For example, "10" represents hexadecimal 0x10 or decimal 16, which can represent the length field. In fact, its encoding is 0x31, 0x30, which are the ASCII codes for "0" and "1". Because the content is printable ASCII characters and can be viewed by a text editor, it needs to be encrypted.

The table includes the standard Intel HEX format record types. Note that the standard only defines 6 record types. To take advantage of the existing structure, the loader uses the Intel HEX format and specifies encrypted data as a new record type. Record type 0x10 will be used to represent encrypted data and this cannot be changed.

The code loader also needs a flow control method to ensure that the write cycle to the flash memory is completed before the next record is loaded. In most cases, the application will generate files that can be divided into groups of 16 bytes for easy reading. Usually the flash memory is divided into blocks of 128 or 256 bytes, so there must be a loader command to request data from the host to allow for variable record sizes. The loader must be able to handle 256 bytes of data because this is the maximum record size according to the standard. The bottom of the table shows the new extended record type in this example. Because the COP8 family of devices only has 16-bit addresses, record types 0x02 to 0x05 cannot be implemented. For processors with larger flash memories, such as the CR16, which can directly access 16M bytes of memory, extended linear address record types are required.

Looking at the flowchart in Figure 3, the first task after reset is to verify the contents of the flash memory. This is done by reading each 128-byte page (except for the bootstrap verification code and loader code located at the top of the flash memory). This makes it very easy to calculate the checksum by verifying only the application code. But it can also include checking the loader components if necessary. When the checksum check passes, control is vectored to the entry point of the application firmware. It is very important that the entry point remains unchanged. If it is moved, the loader will vector to an incorrect entry point and may crash. Alternatively, the loader can read the entry vector from the code, push the vector onto the stack and return to force execution to start at that address. This scheme allows the entry point to be variable.

If the checksum fails, the loader will maintain control and continue to signal the host to begin loading by whatever means the hardware is designed to implement. The loader can also control the user interface to notify of this status. A simple LED light indicating "Firmware Loading" can be very useful when debugging a system.

The loader will continue to request records from the host until the host indicates that there are no more records via an EOF record. Detected records of type 0x10 will be sent to the decoding engine and the data will be decoded appropriately. This allows the code that actually writes data to the flash to operate on both encrypted and unencrypted data. The unencrypted data path is valuable for development and internal testing. When the EOF record is received, all new firmware data is written to the flash. The loader then returns control to the bootstrap test to verify that the new code has not been corrupted.

As mentioned above, field-updatable devices can be implemented without exposing IP. Using a simple password, the manufacturer's firmware can be protected and customers can update their devices anywhere in the world with internet access.