Best Practices for Enhancing Boot Loader Security
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
The following topics discuss best practices to make your boot loader more secure.
Protect the keys
The greatest defense is to keep keys safe. To most software companies that means keeping them on a locked-down computer system. The following list shows some of the techniques used by code-signing authorities:
- Store the keys on the hard drive of a development workstation that is not connected to a network.
The files need to be copied to the development workstation to be signed and then copied off to another development workstation. The benefit of this is approach is that the key(s) never leave a physical location and the developer must be present to sign anything. - Use an encrypted file system, so that even if the development workstation is stolen, the thief would need a login password to access the key.
- Restrict physical access to the development workstation and restrict login.
Locate the development workstation in a server room with limited and monitored access. - Back up the keys.
Keep the backups in appropriate secure locations.
Plan ahead
An existing non-secure boot loader will allow anyone to download to the device. If someone breaks the file format used by Enhanced Boot Loader, they could reconstruct a bin or raw image without signatures. They could then flash this to the old device. Because this would then flash the new boot loader, subsequent flashes would have to be signed correctly.
The best approach is to release the physical device with the new boot loader. Then, the only way onto the device is to have a correctly signed image.
Provide for multiple upgrade paths
The public keys released with the device control what is flashed to it at a later date. This allows a number of scenarios, but must be planned for in advance. Using different and unique keys between different models allows control of how the software is deployed; for example you use the same device for different mobile operators or vertical enterprises. It also allows different upgrade paths, for example, if one device can be upgraded, but another cannot.
For vertical solutions it is usually desirable to use different keys, so that only vertical software can be applied, even if the device has the same hardware as a production model. For example, you can use two different images run on the same hardware. Each image uses a different key for signing.
Protect communication pathways
Many boot loaders have diagnostic modes so that developers can debug settings or use remote configuration tools. Unfortunately there is a risk that tools can be secretly monitored and some unauthorized person can determine how to use the diagnostic mode and change the boot loader.Applications must always verify that communication is from a privileged source.
Manage release to third parties
It is often desirable to release special releases, such as pre-releases, to executives or third parties. However, it is generally necessary to prevent the wider population from flashing such images. This can be achieved by releasing the devices with an additional key installed. Release the device; do not offer an image with the new key in it, because it can be flashed to other devices. Then issuing images signed with this key will only be installable on those devices.
Note
To prevent some of the earlier scenarios discussed, such as stripping the signatures or using an old boot loader, you should also consider the following. Store the keys on an area of the device which does not get re-flashed by the bin or by raw data, for example, the base keys will not be updated by software updates and upgrades.
See Also
Tasks
Creating an Enhanced Boot Loader