Secure Download Boot Loader in Windows Embedded CE (Windows Embedded CE 6.0)

1/19/2010

Glen Langer, Program Manager

May 2007

Summary

This whitepaper helps the reader to understand what a secure download boot loader (SDBL) is, why it may be needed for certain embedded platforms, and provides an overview of the implementation and tools used. Specific implementation details to modify source code can be found in the documentation that accompanies Windows Embedded CE.

Applies To

Microsoft Windows Embedded CE 6.0

Threat Scenarios

Digital Signatures

Implementing a Secure Download Boot Loader

Signing the .bin File

Issues and Best Practices

Introduction

As embedded devices become more common and a larger part of our everyday lives, the more important it becomes to securely configure and securely update those devices. A connected device, either wired or wireless, should accept updates to: enhance features, fix bugs, or completely replace all programs stored on the device, including the operating system. Various techniques can be employed, such as collecting updates in the background or checking for updates when a device is first powered on. Each technique addresses different update scenarios with the goal being able to fix bugs more securely and to reduce service costs for devices already deployed.

Beginning in Windows Mobile 5.0, support for collecting updates while the device performs other tasks is available. When the update is ready, a feature called Image Update applies the updates. This approach works well for mobile devices in the hands of an end-user but not necessarily for replacing programs used during manufacturing to test and calibrate the device, to recondition the device at a repair center, or to upgrade a device at a retail store.

These alternate update scenarios are more easily handled by having the device replace the entire image (comprised of the operating system, programs, initialization data, etc.) when first powered on and a small program called a boot loader begins to run. The boot loader “bootstraps” the device by initializing the hardware, preparing the device to run the operating system, loading the operating system into memory, and then starting the operating system which in turn runs and supports the dedicated applications. A Secure Download Boot Loader (SDBL) is a boot loader that is capable of downloading a new image, verifying that the image is from a trusted source, writing the verified trusted image to flash (non-volatile) memory, and then continuing with the boot process described above.

By contrast, a Secure Boot Loader (SBL) verifies an image, already resident in flash, before booting, but typically does not download or write a new image to flash. This paper focuses on a SDBL for updating the device with a signed image as compared to a SBL that verifies a signed image already on the device. Platforms based on either Windows Embedded CE can benefit from a SDBL

Threat Scenarios

Consider that many wireless network operators subsidize the cost of a device based on the promise of a future revenue stream. If the programs on their device are replaced with other programs that do not tie the device to the network, the operator may lose the opportunity to realize the revenue stream. A properly designed and implemented SDBL can protect a device from being subverted by ensuring that only updates from the network operator (the trusted source) can be applied to the device. Updating the device also includes more secure updates to the boot loader. A malicious user could compromise the security of the device by replacing the secure boot loader with a boot loader that allows untrusted programs to be downloaded.

If an attempt is made to download an untrusted image to the device, the SDBL must above all else leave the device in an operable state with the boot loader intact and able to attempt another download. Possible threat scenarios that the SDBL can help protect against include:

• Manufacturing: an initial image on the device during manufacturing is routinely used for testing and calibration. An SDBL can validate that the final retail image is the trusted image and does not allow backdoor access.
• Point of Sale: some devices come without a final image and have the retail image for the local language installed at the POS. An SDBL can validate that the final retail image is the trusted image.
• Malicious End-User: as mentioned above, the cost of a device may be subsidized by the network operator. An SDBL can help ensure that only verified updates from the network operator are applied.
• Hacked Master Image: an image to be distributed as an update is modified to insert a backdoor or virus. An SDBL can validate that only a verified update is applied to the device. (More on this specific issue in the next section.)

Digital Signatures

A trusted program is a program that can be verified as not having been tampered with and can be verified as having been provided by a known, trusted source. An untrusted program could be a program that cannot be verified to be tamper-free (it may or may not have been tampered with, but we cannot tell) or a program that is from a source that cannot be verified as a trusted source.

Using a digital signature is a powerful technique that exists to help verify both the integrity of the program and the source of the program. The first part of this technique uses a numerical representation or digital fingerprint of the original file, created using a cryptographic hashing algorithm, that is then included in a signature that is appended to the file. The signature can later be used to retrieve the digital fingerprint to compare against to detect any tampering with the contents of the file. The second part of the technique uses encryption to verify that the numerical representation itself has not been tampered with.

Different methods can be used for encryption and the method selected for digital signatures uses what is referred to as asymmetric encryption – also known as public key encryption. This method of encryption uses two different keys: a private key is used to encrypt the signature and a public key to decrypt the signature. The keys are a matched pair and guaranteed to be unique and exclusive. Using asymmetric keys means that the public key can be distributed freely without compromising security. If the signature of the signed, distributed image can be successfully decrypted using the public key, then the signature is guaranteed to have been encrypted using the corresponding private key and therefore by someone with access to the private key. Secure storage of the private key is therefore of the utmost importance. Some best practices for private key access and storage are provided at the end of this paper.

File Signing is the process of creating a unique hash from a file, encrypting the hash value with a private key to create a signature, and adding the digital signature to the end of the file. To verify a file’s signature, the appended signature is decrypted using the public key to get the original hash value. This hash value is then compared to a new hash value created using the current contents of the file. If the new and original hash values match, we know three things: 1) the file contents have not been tampered with – the two hash values match, 2) the signature has not been tampered with – the signature (successfully decrypted using public key), and finally that the file came from a trusted source (the owner of private key that created the signature).

A private/public key pair used with a digital signature is part of a Software Publisher’s Certificate (SPC) which can be obtained from a certification authority (CA). Certificates that are currently installed on a system that runs Windows can be viewed by going to the Control Panel and selecting: Internet Properties, Content Tab, and finally, Certificates tab. The following illustration shows an example of installed certificates on a desktop system running Windows:

Implementing a Secure Download Boot Loader (SDBL)

A SDBL can be implemented as either a one-pass or two-pass process. Microsoft recommends using a two-pass process when possible as the advantages outweigh the possible additional hardware cost. A one-pass boot loader downloads the new image and writes to flash in a single pass. An image is comprised of individual packets and each packet is verified and then flashed. This approach is required when the device does not have enough additional RAM to hold the entire, new image. The risk of a one-pass approach is that any disruption in the download or verification process will result in a partial update of the image which can leave the device in an inoperable state. A two-pass boot loader requires additional RAM but allows the entire new image to be downloaded and verified (first pass) prior to writing to flash (second pass). While a two-pass approach reduces the risk of a partial update, it does not remove the risk completely. A fault tolerant approach would be required to address, for example, loss of power during update issues by incorporating a “last known good image” and an atomic transaction to switch from one image to the next. These are design issues with a full range of possible solutions, but outside the scope of this whitepaper.

Microsoft provides sample source code for the SDBL for the Mainstone BSP in Windows Embedded CE 6.0. The SDBL is delivered as a variant of the eboot boot loader which allows implementers to decide when to enable downloading with signature verification during the product development cycle. Adding digital signatures to images can unnecessarily complicate the early development and test processes.

The SDBL relies on support from four libraries, listed below:

• OAL_BLcommon_Secure.lib: provides a framework for image download
• Mincrypt.lib: implements CAPI (Cryptography API)
• LoadAuth.lib: public key routines
• SBLmincrypt.lib: implements .bin (record-ized) and .nb0 (signed raw) signature checking using the SBL_VerifyPacket function

Microsoft has created two utilities to assist with the creation and verification of a digital signature. The utilities were shipped with Windows Embedded CE 6.0 and can be found in the utilities folder for the Windows Embedded CE installation: %_WINCEROOT%\Public\Common\Oak\Bin\I386.

DumpKey extracts a public key from a user-selected signing certificate and copies the public key into a header file that can be compiled with the SDBL source code.

ImageHash uses the corresponding private key to create a digital signature of the image to be downloaded. The digital signature is inserted in the file and is verified by the SDBL by using the matching public key.

DumpKey will display a list of signing certificates currently located in the user store on a Windows XP-based computer (see Figure 1). When a certificate is selected, the public key is dumped to a header file (public_key.h) that can be compiled with the SDBL source code. DumpKey can be used multiple times to create additional public key header files for multiple certificates. The header file is a C/C++ header file containing the public key data and the length of the public key. The following illustration shows how to select a certificate with DumpKey:

When the source code is compiled, public_key.h that was created with DumpKey will be included with the boot loader. The header file defines an array of public keys and lengths packaged in a PUBLICKEYDATA structure that is defined in SBL.h. This structure is passed to SBL_VerifyPacket as an array structure to allow the Secure Boot Loader library to support an arbitrary number of public keys during verification. There is no set maximum number of keys that can be used and multiple keys are encouraged. Sample code for the SDBL can be found in %_WINCEROOT%\Platform\Mainstoneiii\Src\Bootloader\Secure_eboot. The SBL.h header file can be found in %_WINCEROOT%\Public\Common\Oak\Inc. The following libraries are also included: Mincrypt.lib, Loadauth.lib, and SBLMincrypt.lib. These libraries can be found in %_WINCEROOT%\Public\Common\Oak\Lib\<cpu>\<debug | retail>\.

Signing the .bin File

ImageHash.exe is used after running makeimg.exe to create a digital signature and insert it in the image file. The private key corresponding to the public key used in DumpKey is used to digitally sign the file. Selecting a different private key is one test case that can be used later to validate proper detection by the boot loader of an invalid signature.

The following command line example shows the syntax:

ImageHash [–raw] <file name in> <file name out> <max packet size>

ImageHash takes as input an image file with the file path specified in <file name in> and produces a digitally signed image file with the file path specified in <file name out>. The signed image file contains a variable number of signed packets. ImageHash also supports optional command line parameters which can be used to bypass the user interface and automate the selection of a signing certificate. Table 1 lists ImageHash command line parameters.

Due to platform design decisions that restrict RAM size there may not be enough extra memory to be able to hold the entire image in RAM at once. In this case the image can be verified and flashed in units, such as records in a .bin file or packets in a .nb0 file. The maximum packet size is defined by the OEM and specifies the largest record or packet size that the boot loader can handle.

ImageHash uses a .bin hashing method if the optional –raw parameter is not specified. A new .bin file is produced with each .bin record being signed separately. If an individual record is larger than <max packet size>, then ImageHash takes the extra step to break up the record into smaller chunks. Sample code is provided that manages records that have been broken up into chunks. The sample code manages information about the current chunk and total number of chunks in order to allow the boot loader to track progress through the image.

If the –raw parameter is specified, then ImageHash uses a simple block signing method to produce a new output image file with signed packets. The –raw parameter should only be used on .nb0 files. ImageHash creates packets for a .nb0 file that never exceed <max packet size> defined by the OEM and then individually signs each packet.

Issues and Best Practices

When to Implement

Adding support for the SDBL should be done late in the development cycle when the boot loader and platform are already robust. The SDBL should be the last feature enabled in the boot loader.

During development of the SDBL it is recommended to use test versions of the private and public keys, as compared to production versions of the keys. Using test versions reduces the burden and security risk of engineers requiring access to production key pairs during development. Once development and testing of the SDBL is complete, a process must be in place to replace the test key pairs with production keys prior to shipping the device.

The image can be automatically signed after every build by adding ImageHash to:

%_TARGETPLATROOT%\files\postmakeimg.bat

Compromised Keys

The power of digital signatures is founded in having asymmetric keys and, most importantly, securely maintaining the private key. If the private key is compromised, the security of all devices that potentially use that private key have been compromised. A compromised private key could be used to install a tampered image or even replace the secure download boot loader itself.

Recommendations for improving the security of private key storage:

• Use a server shared folder with restricted access
• Store the keys on the hard drive of a workstation that is not connected to the network
• Store the keys using a file system that can store data in an encrypted format
• Restrict physical access to the workstation
• Restrict the list of people who can log on to the workstation
• Back up the keys (and protect the backup)

JTAG

If JTAG pins are exposed on the device, then it is still possible to reprogram the device with a boot loader that removes the security precautions of the SDBL. Possible solutions are using fuses or one-time programmable (OTP) elements to disable JTAG or by using special software keys to enable access to JTAG.

Multiple Public Keys

The SDBL sample code supports the storage and use of multiple public keys. Using multiple keys allows the same SDBL to be used for multiple products (i.e., SKUs) based on the same hardware platform. This can save development time and cost by reusing the same code. Using multiple keys also allows multiple product upgrade paths (based on different keys) or upgrades for special demo models.

Conclusion

Establishing and extending the “Chain of Trust” for an embedded device can help to securely configure and securely update the device.  A Secure Download Boot Loader (SDBL) is one link in the chain and when properly implemented can help reduce service costs for devices already deployed.

For Additional Information

For additional information please see:

• MSDN – Search keywords: “boot loaders”, makecert
• Introduction to Code Signing
• Mainstone III Board Support Package sample source code, Windows Embedded CE 6.0:refer to <drive letter>:\wince600\platform\mainstoneIII\src\bootloader\secure_eboot
• “Implementing Enhanced Boot Loader”Windows Mobile documentation. Step-by-step instructions for modifying sample code.
• Creating an Enhanced Boot Loader
• System Memory Management in Windows CE .NET

See Also

Other Resources

Windows Embedded CE 6.0 Technical Articles