Flashing Recommendations
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 list shows the flashing recommendations from Microsoft in order of decreasing benefit.
- Do not use an end user full flash solution in the field.
- Implement a packet-based signature verification boot loader, as described in Using Encryption and Signatures to Flash subtopic that follows.
Microsoft provides the Enhanced Boot Loader library to help your development effort. In the directories, Enhanced Boot Loader is shortened to SBL. You can find the sample code at %_WINCEROOT%\Platform\Mainstoneiii\Src\Bootloader\Secure_eboot. - Implement a packet-based signature verification boot loader that uses encryption.
If you want to provide additional protection, you can build an encryption system on top of the Enhanced Boot Loader library.
.gif "Bb201900.collapse(en-US,WinEmbedded.60).gif")
Using Encryption and Signatures to Flash
If you decide to allow a full flash solution in the field, Microsoft recommends implementing a signature verification system.
The payload is signed to prevent tampering.
Optionally, the payload can be encrypted if the developer does not want anyone to see what the code does.
Before flashing, the boot loader needs to verify and decrypt if appropriate. Verification should be done at a packet level because RAM limitations would typically prevent the entire payload being verified all at once. The new software can come from a memory card or over USB from a desktop computer.
Note
If a user has access to run code in the device's operating system, the user may be able to read information from the flash ROM.
Advantages
- Requires no special hardware and anyone can flash an approved build.
Disadvantages
- Boot loader needs to verify and optionally, to decrypt.
- Device can be destroyed if a bad packet detected in the middle of a flashing session. If a verification error occurs after the device has been partially flashed, it would make the device unusable.
This scenario only happens if someone is trying to tamper with the device. The boot loader can use a more complicated two-pass approach to avoid this situation. The first pass verifies, but does not flash. If the first pass succeeds, the second pass flashes the device.
The following illustration shows possible architecture to support signed payloads. It also shows a hardware key to protect access to configuration data that might be present for development purposes.
.gif "Bb201900.a41e0050-f612-40cc-b9df-28f13378a075(en-US,WinEmbedded.60).gif")
An alternative for a purely desktop-computer-based solution is to have the desktop-resident software decrypt the payload.
One challenge of using encryption in addition to signature verification is that it makes it difficult to verify what changed from one software release to the next. Consider a test build and then a final candidate. Between the code level and what is on the flash chips, it may be a single byte that differs, but an encrypted build may look very different. Simply signing the image does not have the same problems because only the signature of the affected block(s) will change.
See Also
Tasks
Creating an Enhanced Boot Loader