Secure Boot

Security starts with the device boot process. If you want to build a really secure device one possible attack pattern you have to consider is image replacement or modification. To protect against this, you need to create a chain of trust in the boot process so it will be impossible for the attacker to compromise the device's integrity.

Creating a chain of trust requires some level of support from the hardware. The specific type and architecture of such support has an impact on the aggregate of boot security.

From a security point of view, probably the best hardware support is when firmware code is stored in internal read-only-chip memory. Chassis intrusion detection can then protect exposure of these chips to the outside world (and wipe such chips if there is an intrusion). In this case the firmware code is executed on device boot and its task is to download other code from an external source (flash memory, serial port, USB). The external code is first loaded to internal read-write chip memory. Then the original firmware code verifies the new code's integrity and if verification succeeds the firmware passes control to the new downloaded code.

Code integrity is typically verified by using a hash of the data comprising the code (SHA1 for example), and a digital signature. The firmware code contains one or more public keys used to verify a hash digital signature. To sign code that will be downloaded, you have to have access to the private key matching a public key stored in firmware.

Another problem you will typically face with this solution is the maximum size of an image which can be downloaded. In most cases the size of code is limited to the internal CPU/SoC memory (usually SRAM or dynamic cache). This is because the chip can't initialize or use external memory (The original firmware can't assume a particular type of RAM, or that the RAM is protected from exposure).

If your system doesn't have this type of security or such functionality is not available, another way to solve the issue is to make sure that code which is downloaded after reset can't be modified. This solution is somewhat weaker than the firmware solution, as an attacker can replace the chip storing the boot code. In fact, this is really the only difference - with the caveat that in the case where firmware code is stored on the same chip as the CPU it is much more difficult to replace (and probably too costly). However in most cases this solution is sufficient.

There are different ways to make code read-only. One is the "write-once" approach - where as soon as you write code to some memory, that memory can't be changed. Another way is to use chips which allow you to create partitions which are modifiable only when you know a password. A further reasonable solution can be a sticky read-only flag, which makes part of memory read-only until reset.

In both cases the size of code which can get executed in the initial phase is typically limited. This requires you to be very efficient in implementation. There is one thing you must not forget even when dealing with efficiency - don't broke chain of trust. In other words, the code in the intermediate loader must also verify the integrity of code it downloads before passing control to that code.

To summarize, in most cases there will be one of the following chains used for a secure boot:

a. Firmware -> Intermediate Loader (XLDR) -> Boot Loader (BLDR/EBOOT/IPL) -> Windows CE OS
b. Intermediate Loader (XLDR) -> Boot Loader (BLDR/EBOOT/IPL) -> Windows CE OS
c. Boot Loader (BLDR/EBOOT/IPL) -> Windows CE OS
d. Windows CE OS

The last variant can't be used in a secure boot scenario in most cases as it will quite difficult to implement the Windows CE OS update mechanism.

In all cases each block of code passes control to its successor and must make sure that the integrity of that successor is not compromised. The extra point is that there must be a mechanism which makes it impossible to modify the first code in chain.

It was mentioned that the method used to verify code integrity is in most cases based on asymmetric cryptography using private and public keys. As part of a secure eboot solution Windows CE ships libraries which can be used to implement secure boot.

It is also a good idea to check your hardware for cryptographic modules. In most of the latest chips you will find hardware supporting a public key infrastructure which can be used in the secure boot scenario.

Focusing on the last step in boot chain - loading Windows CE OS image - requires you to choose from one of two approaches depending on your architecture:

a. The downloaded OS image will be signed and verified as a single BLOB (binary large object).
b. Each executable in the downloaded OS image will be signed and verified independently.

If your device uses Image Update, you have to use the second of these approaches. This is necessary because image update allows updates to individual image components.

---

Go up to BSP Advanced Features
Go up to Big Book of BSP

PS – We value your feedback, but please DO NOT directly edit this page. Instead, submit your feedback and topical suggestions to bspwiki ‘at’ microsoft ‘dot’ com.

---