Full article begins on Page 2
Because it's fairly ubiquitous and accessible, the Internet is a great way to provide code up-dates to customers. But it's an open medium, so it's subject to attacks or theft. By encrypting machine code and placing a wrapper around it to define its function, a simple program can be used to load firmware to a target device.
Wrapper information might consist of the intended target device, code revision, size, date, and other useful user information. This information could warn operators that they might be downgrading a piece of equipment or attempting to load an unsupported target device.
Protecting a company's intellectual property (IP) is a high priority in today's market. Years of development may go into a design that contains trade secrets and proprietary algorithms. Thus, companies are moving away from traditional one-time-programmable microprocessors and to flash-based versions.
Flash allows just-in-time programming at the end of the production line and code changes after production. But when moving this feature to the field via the Internet, designers risk exposing IP to competitors. This article examines ways to provide field updates without exposing a product's IP, plus other features to control update licenses.
|Code Protection||There are many ways to protect software from unauthorized copying, but vulnerability exists with the Internet. For firmware, protecting the IP is most critical.|
|Simple Ciphers||A rolling-code generator consists of serially connected flip-flops, with several of their outputs implemented as a rolling key.|
|Transport Methods||A firmware loader determines whether the current load is valid. It uses data organized into packets that are delivered to the microcontroller and then to the decryption engine.|
|Example Design||The example COP8 firmware loader with decryption uses a modified version of the Intel hex format. A table gives record types for normal Intel hex format.|
Full article begins on Page 2
Because it's fairly ubiquitous and accessible, the Internet is a great way to provide code updates to customers. But it's an open medium, so it's subject to attacks and theft.
By encrypting machine code and placing a wrapper around it to define its function, a simple program can be used to securely load firm-ware to a target device.
Wrapper information might consist of the intended target device, code revision, size, date, and other useful user information. This information could warn operators that they might be downgrading a piece of equipment with a lower revision of firmware, or attempting to load an unsupported target device.
Protecting a company's intellectual property (IP) is one of the highest priorities in today's competitive market. Years of development may go into a design that could contain many trade secrets and proprietary algorithms. As flash-based microprocessors become more available and incorporate more features, companies are moving away from traditional one-time-programmable (OTP) microprocessors.
They're turning to flash, which allows just-in-time (JIT) programming at the end of the production line. This approach also enables code changes after production. But when companies want to move this feature to the field via the Internet, they must address the problem of exposing IP to competitors. Various methods should be employed to control update licenses and provide field updates without exposing a product's IP.
There are many ways to protect software products deployed in the field. The particular method used depends on what the provider is trying to protect. Most software-protection schemes prevent unauthorized copying of programs or data. Copying a file is now trivial. With the Internet, many copies can show up very quickly. In the case of firmware that's part of a hardware platform, copy protection is usually not as significant an issue as protecting the IP contained in the firmware. Yet if the firmware update is a purchased product, copying may still be a concern.
Another problem deals with the amount of performance available to handle decryption ciphers in microcontroller-based products. RSA and DES standards require a good deal of performance and memory. Unfortunately, most microcontrollers have limited resources in both of these areas, requiring a different type of encryption and decryption. It can't tax the microcontroller's performance and must provide methods for keys that can be global or specific to a device.
Rolling-code generators have existed for many years in devices ranging from garage-door openers to secure access cards. Figure 1 shows how a simple rolling-code generator works. A group of serially connected flip-flops with a common clock has various taps at their outputs. In the example shown, Q2 is unused. The remaining outputs go to an exclusive-OR function that supplies the new input bit on every clock edge. The number of combinations depends on the number of flip-flops and the number of taps to the XOR function.
Typically, the outputs of several flip-flops are implemented as a rolling key. An identical generator is used to test the key when it's applied, like in a garage-door opener. As each key is used, it's retired until the entire sequence repeats, possibly millions or billions of keys later. In the garage-door-opener situation, this prevents a criminal from using a radio receiver and simply playing back the codes to open the door at a later time.
In the case of code encryption, the outputs of the flip-flops are applied with an additional exclusive-OR function (A1) to the data being either encrypted or decrypted (Fig. 2). For each byte, word, or double word, the outputs of selected flip-flops are exclusive-OR'ed with the data, plus some additional user-defined function. That function can be as simple as adding a constant. The process must be reversible, so the user-defined function should not be random.
The keys provide the encryption and decryption algorithms with the placement of the taps along the flip-flops, as well as the seed for the initial state of the shift register. These keys can be split to provide unique keys to specific units based on serial numbers. That is, the serial number of a unit may supply half of the key information, and the manufacturer keeps the remainder secret. Obviously, there are many permutations of this scheme.
For global distribution of firmware upgrades, such as bug fixes that should be applied to all products, a special serial number can be used. The decryption engine tries the global key first—possibly a special pattern. If the global key fails to decrypt to a correct checksum, the unique key can be applied. It can tell the loader which type of firmware update the encrypted source contains.
Obviously, some kind of decryption engine and code loader is required within the product. The techniques discussed here can be illustrated with a COP8 microcontroller. The specific microcontroller targeted will be a COP8CBR with 32 kbytes of flash and 1 kbyte of RAM. The one caveat in a field-upgradable system is that the microcontroller must be able to program its own flash memory while still running. The microcontroller can't be held in reset or require any external programming methods to flash the program memory. The decryption engine and code loader must reside inside the microcontroller to be fully secure. COP8 flash products meet this requirement.
The firmware loader is a code module that runs at reset and determines whether or not the current load is valid. If the current code is found invalid, the loader enters into a LOAD MODE until something provides the operating firmware. This can be via any physical-layer interface available on the microcontroller. In the case of the COP8, the serial port will be used. If the current code is valid (good checksum), the loader passes control off to the application-firmware entry point.
Another feature of the COP8 family is a software trap that can be used to vector to a recovery mechanism. It implements an op-code of 0x00, which would be programmed into all unused locations. If this operand were executed, operation would begin at the software trap vector, causing the loader to reevaluate the integrity of the firmware. This is a nice feature for fault tolerance. If the code were corrupted by any means, the loader would gain control and allow a technician (or user) to reload the firmware.
To download a listing, click Download the Code at the bottom of the page.
The loader uses data organized into packets that have a header and a checksum to verify delivery. Once the packet is delivered to the microcontroller and its checksum is validated, the loader passes it to the decryption engine (if encrypted). Located internally in the encrypted data is an additional cipher checksum. This gives the decryption engine a means to verify the key information. It will apply the global key first and test the checksum. If it fails, it will apply the unique key from the serial number and try again. If that fails, the loader is notified that the firmware is invalid for this device. This also offers a way to protect the code from unauthorized tampering or accidental destruction.
If the decryption engine successfully decodes the data, it will pass it to a flash routine that will program the actual block of flash memory. These routines will vary from different manufacturers, though. The COP8 routines are shown in the design example that follows. This routine sets aside a block of 128 bytes of RAM to use for updating the flash. However, this RAM can be used for application data after the loader completes.
Figure 3 shows a firmware loader flow chart with decryption. The loader uses a modified version of the industry-standard Intel hex format commonly implemented in device programmers and in-system emulators. This will provide an existing infrastructure of applications that support the standard and ease of use. The loader firmware will be written in COP8 assembler to minimize code size and exploit all of the device's flash features. For a copy of the code, go to www.electronicdesign.com. For further comments, e-mail the author at the address given at the end of the article.
Briefly, Intel hex format is an ASCII-coded representation of data records used to program object code or data into a device's memory. The format comprises a Start of Record field using an ASCII 0x3A or ':', a Data Length field (two ASCII characters) representing a length of 0x00-0xFF, an Offset field, a Record Type field, an Information or Data field, and a Checksum field. Standard printable ASCII characters represent each field. For instance, '10', which equals 0x10 in hexadecimal, or 16 decimal, might represent a length field. Actually, its coding is 0x31, 0x30, which are the ASCII codes for '1' and '0.' Because the content is in printable ASCII characters, the entire object code can be examined with a text editor, thus the need for encryption.
The table covers record types for normal Intel hex format. Note that the standard defines only six record types. To take advantage of the existing infrastructure, the loader will use the Intel hex format standard and denote encrypted data with a new record type. The record type 0x10 will be selected to represent encrypted data. The choice is arbitrary.
The code loader will also need some method of flow control to make sure that the flash write cycle completes before the next record is loaded. In most cases, applications create files that are broken into groups of 16 data bytes to ease readability. But flash memory usually comes in blocks of 128 or 256 bytes. So, there must be a command from the loader to request data from the host to allow for variable record sizes. The loader has to handle 256 bytes of data as this is the maximum record size allowed by the standard. The bottom of the table shows the new extended record type for this example. Because the COP8 device family has only a 16-bit address, record types 0x02 through 0x05 won't be implemented. For processors with larger flash memory, such as the CR16, which can directly address 16 Mbytes of memory, the extended linear-addressing record types will be required.
Tracing the flow chart of Figure 3, the first task following a Reset is verifying the flash-memory contents. This is accomplished by reading each page of 128 bytes, excluding the boot-verification code and loader code located at the top of flash memory. Only the application code is verified. This makes calculating a checksum much easier. However, it could include checking the loader components of the firmware if desired. If the checksum passes, control is vectored to the entry point of the application firmware. It's very important that this entry location remains the same. If it moves, the loader will vector to an incorrect location and possibly crash. Alternatively, the loader could read an entry vector from the code, push it onto the stack, and return, forcing execution to begin at that location. This allows for variable entry points.
If the code fails the checksum test, the loader firmware will take control and continuously signal the host, by whatever means is designed into the hardware, to begin loading. Optionally, a user interface can be controlled by the loader to signal this state. A simple LED that indicates "firmware load" can be extremely useful when debugging a system.
The loader firmware will request records from the host until the host signals, via an EOF record, that there are no more records. A detected record type of 0x10 will be vectored to the decryption engine, which will decrypt the data in place. This lets the code that actually writes the data to the flash operate on both encrypted and unencrypted data. It may be of value to provide an unencrypted datapath for development and internal testing. When the EOF record is received, all new firmware will be written to flash memory. At this point, the loader passes control back to the boot test to verify that the new code is intact.
As shown above, field-upgradable equipment can be implemented without exposing IP. With a simple cipher, the manufacturer's firmware can be protected and customers can take advantage of upgrading their equipment from anywhere in the world that they have Internet access.
To download a listing, click Download the Code below.