High Robustness Bootloader for x86 Platform

 

 

 

 

Final Report

August 1, 2003

 

 

 

 

Darryl Gamroth 0123949

dgamroth@engr.uvic.ca

CEng 499A Project

 

University of Victoria supervisor:

Dr. Daler Rakhmatov

Industry  supervisor:

Bruce Jenner


Executive Summary

This report is a summary of the progress made on a high reliability/secure bootloader for General Hydrogen Corporation as done for the CEng499A senior design project.

 

This project comprised of three parts: basic low level platform functionality, providing a secure way to verify program binary images, and finally the design and construction of debugging hardware to assist in the development of the system.

 

For the first part, RedHat’s RedBoot was ported to the development hardware (an AMD Élan SC520 x86 compatible microcontroller) and tested for its suitability for this project and to provide the main framework for the application.

 

Secondly an additional framework was added onto RedBoot to provide the capability of having signed program binary images.  The Message Digest 5 (MD5) algorithm is used to create a unique fingerprint for the application and that fingerprint is signed using the RSA public key encryption system.

 

Finally a custom JTAG controller board was designed to provide quick programming of flash to quicken the development cycle.  A Cypress AN2131S USB slave controller was used to control the peripheral and a Texas Instruments SN74LVT8980A was used as the JTAG test bus controller.
Table of Contents

 

Executive Summary.................................................................................................................. i

Introduction............................................................................................................................ 1

Bootloader........................................................................................................................... 2

Low-level Initialization....................................................................................................... 3

Application Signing............................................................................................................... 5

MD5 Fingerprint................................................................................................................ 6

RSA Algorithm.................................................................................................................. 6

JTAG Hardware.................................................................................................................. 10

Why JTAG?..................................................................................................................... 10

JTAG Hardware Design.................................................................................................... 10

Conclusions........................................................................................................................... 14

Recommendations................................................................................................................. 15

Bibliography.......................................................................................................................... 16

Appendices........................................................................................................................... 17

 

Table of Figures

 

Figure 1 RedBoot ROM Monitor architecture [2] 2

Figure 2 Bootloader firmware flowchart 4

Figure 3 RedBoot command monitor prompt 5

Figure 4 RedBoot: invalid application. 8

Figure 5 RedBoot: successfully identifying an image. 9

Figure 6 USB JTAG schematic. 12

Figure 7 Target board (left) attached to USB JTAG (right) 13

Figure 8 JTAG test program   14


 

Introduction

 

General Hydrogen Corporation sponsored the work for this project for a new hydrogen dispenser system.  To ensure that certain safeguards are met the software, although not part of the safety system, was determined to be "as safe as possible".  To meet this goal an off-the-shelf bootloader was to be used as a starting place and the necessary modifications made to it.  This reduced the need to create a system from scratch and be able to leverage existing technologies.
Discussion

Bootloader

 “RedBoot is a complete bootstrap environment for embedded systems. Based on the eCos Hardware Abstraction Layer, RedBoot inherits the eCos qualities of reliability, compactness, configurability, and portability.

 

RedBoot allows download and execution of embedded applications via serial or Ethernet, including embedded Linux and eCos applications. It can be used for both product development (debug support) and in deployed products in the field (flash update and network booting).

 

Ethernet download and debug support is included, allowing RedBoot to retrieve its IP parameters via BOOTP or DHCP, and program images to be downloaded using TFTP. Images can also be downloaded over serial, using X- or Y-modem.

 

RedBoot can be used to communicate with GDB (the GNU Debugger) to debug applications via serial or Ethernet, including the ability to interrupt a running application started by GDB.

 

An interactive command-line interface is provided to allow management of the Flash images, image download, RedBoot configuration, etc., accessible via serial or Ethernet. For unattended or automated startup, boot scripts can be stored in Flash allowing for example loading of images from Flash or a TFTP server.”[1]

 

Figure 1 RedBoot ROM Monitor architecture [2]

 

The reason for choosing RedBoot was simple, it already provided a proven framework for downloading software onto a platform as well as support for a generic x86 PC platform.  What needed to be added were the low level support routines to get the AMD Élan to behave as a generic x86 PC and the security oriented application signing.

 

Low-level Initialization

As shown in Figure 1, RedBoot utilizes a hardware abstraction layer to keep the Bootloader application portable between architectures.  The hardware abstraction layer is provided by the RedHat’s eCos real time operating system; as an added bonus, when the abstraction layer is written both a bootloader and operating system are available for use.  Initial development of this project did exactly that, the hardware abstraction layer was written to conform to the guidelines of porting eCos to a new variant of an existing architecture.  Unfortunately as product development continued it was determined by management that the application being loaded by the bootloader must re-initialize the platform to its desired state to ensure safety.  For the sake of code reuse, the initialization code was broken out into a library for use by both the application and the bootloader.

 

Various application notes from AMD were used as a basis of the system initialization library, in particular the SDRAM sizer application note which determines the configuration of the SDRAM installed in the system and configures the memory controller.  Before control can be turned over to RedBoot, the following hardware must be properly configured:

  • Memory controller (SDRAM)
  • General purpose bus configuration
  • Chip select configuration
  • Interrupt steering controller
  • Programmable I/O configuration

 

Figure 2 Bootloader firmware flowchart

Several modifications were made to RedBoot to remove functionality that would commonly be available but due to security concerns were removed.  Features such as raw binary, S-Record and ELF executable support were removed, along with commands which can modify the contents of system memory.  Below in Figure 3, RedBoot’s command monitor is displayed immediately after boot.

 

Figure 3 RedBoot command monitor prompt

 

Application Signing

 

Typical bootloaders only provide data integrity checks using a Cyclic Redundancy Check (known as a CRC) to ensure that the software to be installed was not corrupted while being downloaded.  Although improbable, it is possible for two different applications to generate an identical CRC.

 

To address the issue of security a different method was devised.  To create a unique “fingerprint” for an application the MD5 algorithm is used.

MD5 Fingerprint

MD5 was developed by Professor Ronald L. Rivest of MIT. What it does, to quote the executive summary of rfc1321, is:

 

“[The MD5 algorithm] takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given pre-specified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA. “

 

An MD5 “fingerprint” of the application is generated as part of the application build process using public domain source code.  This source code is also embedded within the bootloader application to generate a digest for verification.

 

RSA Algorithm

To sign the fingerprint the RSA public key cryptosystem is used.  The term “public key” refers to the fact that knowing how to send a message in code does not help you decrypt the message.  When using public key encryption, only the decryption keys are kept secret while the encryption keys are shared freely.  The RSA algorithm was chosen due simplicity of implementation and effectiveness.  In the case of RSA, security is assured through the assertion that large prime numbers are very difficult to factor.

 

The RSA encryption algorithm works as follows:

 

  1. Two prime numbers (and ) of similar size are chosen randomly.  Even though it is very difficult factor a prime it is relatively easy to test if a number is prime.
  2. Calculate
  3. Choose a value  which is relatively prime to (i.e. , this can be verified using Euclid’s Algorithm)
  4. The message to be encrypted is partitioned such that  (the message) is less than .
  5. The cyphertext (the encrypted message) .  As  gets very large very fast, an algorithm for fast modular exponentiation is used (via the Chinese Remainder Theorem).  In the case of the bootloader, a GNU arbitrary precision library was used.

 

The RSA decryption algorithm:

  1. Using Euclid’s algorithm the decryption key  can be calculated.
  2. Now, destroy p and q such that the original primes cannot be found (RSA works on the assumption that it is impossible/improbable that  can be factored back to  and ).
  3. The message can be recovered using:.

 

The public key for encryption is denoted by, for the bootloader, the public key is part of the bootloader software and is used to verify images; only the encryption algorithm must be implemented in the bootloader.  The private key is given by  and is used by the application developer to sign the binary program image.

 

From the equations above it can be stated that encryption and decryption are inverse functions of one another; ifand  then:

To sign a binary, during the build after the MD5 sum is calculated the decrypt or sign function is called on the digest using the private key.

 

Figure 4 shows an invalid application (either corrupted data or an invalid key was used to create the binary program image).  Figure 5 shows program binary successfully loaded, displaying information about the image.

 

Figure 4 RedBoot: invalid application

 

Figure 5 RedBoot: successfully identifying an image

 

To add an extra amount of security for the program binary, both the header which describes the program and the data contained within can be signed.  At a later date it could be possible to update the system such that the header and data could have different signatures.

typedef struct image_header {

        uint32_t        ih_magic;               /* Image Header Magic Number    */

        uint8_t         ih_hdigest[IH_DIGESTLEN];      /* Image Header MD5 Digest

*/

        uint32_t        ih_time;                /* Image Creation Timestamp     */

        uint32_t        ih_size;                /* Image Data Size              */

        uint32_t        ih_load;                /* Data  Load  Address          */

        uint32_t        ih_ep;                  /* Entry Point Address          */

        uint8_t         ih_ddigest[IH_DIGESTLEN];   /* Image Data MD5 Digest

*/

        uint8_t         ih_os;                  /* Operating System             */

        uint8_t         ih_arch;                /* CPU architecture             */

        uint8_t         ih_type;                /* Image Type                   */

        uint8_t         ih_comp;                /* Compression Type             */

        uint8_t         ih_name[IH_NMLEN];             /* Image Name           */

} image_header_t;

 

 

JTAG Hardware

Why JTAG?

To perform the first write to the embedded system's flash, the JTAG bus is used by bypassing the system processor and using the JTAG serial bus to manually control the processor's input/out bus.

 

Various inexpensive JTAG options are available although almost all utilize the parallel port of a standard PC, and emulate the JTAG serial bus by manually clocking the serial data.  This results in extremely poor performance (a transfer rate of approximately 3kbps) which creates very long programming and read times.

 

The approach taken in this project was to create an alternative using a off the shelf JTAG bus controller chip.  This controller chip provides the parallel to serial conversion and correct sequence control to operate the JTAG state machine.  To further increase the flexibility of this device it was decided to use the USB (Universal Serial Bus) instead of the parallel port.  The result of designing this board was an increase in speed of 100 times.

 

JTAG Hardware Design

 

Previously in Status Report 2 a hardware JTAG adaptor to attach the parallel port of a PC was designed.  Later upon doing research of various microcontrollers for another project, the Cypress AN2131S came up as an easy to use USB microcontroller based upon the Intel 8051 core.  What makes this microcontroller interesting is that it requires no programmer; the microcontroller is bootstrapped via USB.  Upon device connection, the USB bus enumerates the device and determines its identity.  Upon successful identification, the operating system on the PC uploads the required firmware to the device and causes it to simulate the device being removed and plugged back in.

 

To save time in firmware development, it was decided to program the JTAG device to behave as a parallel port.  Although this solution is sub-optimal it is still superior to the parallel port solution in two ways:

  • The JTAG device is powered off the USB port therefore an external power supply is not needed.
  • In the future the firmware can be updated to include more functionality, whereas this would be impossible for a parallel port connected device.

 

The JTAG bus control is provided by a Texas Instruments SN74LVT8980A JTAG TAP (Test Access Port) Master.  High level commands are issued to the controller by the host which causes the controller to generate the signals necessary to operate the JTAG state machine.  To further enhance reads and writes to the target device a 32 bit FIFO is present to buffer the data in both directions to help minimize polling.  To ensure that the target board’s JTAG signals are at the correct voltage level, the JTAG controller is powered by the target voltage supply.  As the JTAG controller is a LVT (Low voltage TTL) part it utilizes 3.3V signaling but is 5V tolerant.

 

 

Figure 6 USB JTAG schematic

 

Figure 7 Target board (left) attached to USB JTAG (right)

 

Figure 8 JTAG test program

Conclusions

I have found this to be an extremely interesting and challenging project.  From doing software design on a full featured processor to developing a USB JTAG board to doing discrete math and encryption; this project touched on a bit of everything.  Personally I found the Élan to be lacking the elegance of a modern RISC architecture simplicity of design.  I will not get a chance to see how this system will operate in the future, but I hope it is of some use to General Hydrogen.

 


Recommendations

 

Overall this project was a very rewarding learning experience.  There were a few lessons learned, all to do with the hardware platform.  Initially the AMD Élan SC520 was chosen due to it’s compatibility with the ubiquitous Intel x86 family of processors and its floating point co-processor for control applications.  By leveraging compatibility, existing compilers in the Linux environment could be used to build target software.  What was not considered was the total lack of development tools for low level operations such as debugging, therefore the following recommendations are made:

 

  • For evaluation purposes, buy an evaluation platform from AMD.  Even though the cost of the development platform is approximately $2000 USD compared to the $200 USD spent on the current off-the-shelf board, the support and tools are well worth it.
  • Buy an off-the-shelf firmware BIOS from General Software Incorporated.  By doing this the low-level step can be ignored and the system will behave as a generic x86 PC.
  • If possible for a later revision or project replace the AMD Élan with a Motorola MPC8241 PowerPC.  General Hydrogen currently owns several high quality debugging tools for the PowerPC platform for a previous project.  The MPC8241 is comparable in performance, capabilities and cost with the AMD Élan SC520.

 

 


 

Bibliography

[1]    “RedBoot" [online] 2003, http://sources.redhat.com/redboot  (Accessed: 26 July 2003).

[2]    Anthony J. Massa, “Embedded Software Development with eCos”, 1st ed. Prentice Hall PTR, 2002, Figure 9.1 pp. 187

[3]    Kenneth H. Rosen, “Discrete Mathematics and Its Applications”, 4th ed. WCB/McGraw-Hill, 1999

[4]    “Boundary Scan (JTAG, IEEE 1149.1)” http://www.acculogic.com/Products/BoundaryScanHome.htm (Accessed: July 31 2003)

 

 


Appendices