Partager via

Windows Embedded CE 6.0 Security Model

  • Article

1/6/2010

This topic covers the changes in the Windows Embedded CE 6.0 security model.

Old Security Model: Trust Level for Modules

In releases prior to Windows Embedded CE 6.0, there was a concept of trust associated with each module (DLL or EXE). Each module could be categorized as one of the following:

  • Loaded with “full trust” privileges: This was typically the case for a DLL or EXE signed with a certificate that chains to a privileged certification store on the device. In this case the module was allowed to load and the module code can also call all the APIs in the system.
  • Loaded with “run” privileges: This was typically the case for a DLL or EXE signed with a certificate that chains to an unprivileged certification store on the device. In this case the module was allowed to load, but specific API calls (such as SetKMode) could not be made from this module.
  • No privileges: This was typically the case if the DLL or EXE signed with a certificate which is not in any of the certification stores on the device or the module was not signed at all, and the module was being loaded on a trust-enabled system.

In this security model, module trust was fully governed by the certificate (or the lack of a certificate) associated with the given module. On general embedded systems where a certification subsystem was not in the image by default, an OEM could still have limited the API calls to only those modules that reside in ROM.

New Security Model: Trust Level for Modules and APIs

In CE 6.0, the concept of module trust is treated slightly differently and is divided into two parts:

  • Load Privilege: This is used by Windows Embedded CE to decide if a module can be loaded or not (for example, when an application calls CreateProcess or LoadLibrary to launch or load a module). Load privilege decides whether to load the module by determining whether a certification module is built into the Windows Embedded CE powered device or not. For more information, see Load Privilege later in this topic.
  • API Privilege: This is used by Windows Embedded CE to decide if module code can call specific APIs that are categorized as kernel-mode only. The decision for this is based on where the module is loaded. Any code which is loaded above 0x8000_0000 is considered to be running in kernel mode, and any code which is loaded below that address is considered to be running in user mode. Therefore, whether a module can call specific APIs entirely depends on which address space that the module is loaded in. The decision is not related to which certificate is associated with the given module. For more information, see Kernel Mode APIs.

Ee497961.collapse(en-US,WinEmbedded.60).gifLoad Privilege Overview

In CE 6.0, load privilege for a module is based on the following rules:

  • Any module with ROM attribute set on the file is considered to be fully trusted.
  • Any module which is signed with a certificate that chains to a codesign certificate stored on the device is considered to be fully trusted.
  • All other modules are considered to be untrusted.

Considering these rules, the following three cases represent the possible ways that a Windows Embedded CE powered device can be built to accommodate load privilege.

Case 1: Closed box solution

If you want to develop a closed box solution using CE 6.0, then you should consider doing the following:

  1. Enable SYSGEN_CERTMOD in the image. You can set this Sysgen variable at the command-line during a build.
  2. Do not add any certificates to the codesign store on the device.
  3. Ensure that all the modules which are needed to run on the closed box system are in ROM.

Once an image is built with the above properties, then no third-party applications or modules can be loaded on that system.

Case 2: Semi-closed box solution

If you want to develop a semi-closed box solution using CE 6.0, in which only signed modules can be loaded in the system, then you should consider doing the following:

  1. Enable SYSGEN_CERTMOD in the image. You can set this Sysgen variable at the command-line during a build.
  2. Add one or more certificates to the codesign store on the device.
  3. Ensure that all the modules which needed to run on this system are either in ROM or signed with a certificate that is in the codesign store on the device.

A semi-closed box solution is appropriate for an OEM who wants to publish an SDK for their Windows Embedded CE powered device so that ISVs can write applications that target their platform. By enforcing that applications must be signed with an OEM certificate, OEMs can control which applications are permitted to run on the device.

Case 3: Open solution

If you want to develop an open solution using CE 6.0, then you should consider the following:

  • Ensure that SYSGEN_CERTMOD is not set in the image.

When SYSGEN_CERTMOD is not set in the image, all modules in the system are considered as fully trusted for Load Privilege, and any attempt to load any module will proceed normally.

Note that SYSGEN_CERTMOD just governs the load privileges for a module. Once the module is loaded, the set of APIs that the module is permitted to call depends on which mode (kernel mode or user mode) that threads in that module are running in. This is determined by which address space the module is loaded in.

For more information, see the description on API Privilege earlier in this topic.

See Also

Reference

CertInit
CertVerify

Concepts

Trusted Environment Creation

Other Resources

Loading DLLs in Kernel Mode or User Mode: Windows CE 5.0 vs. Windows Embedded CE 6.0
certmod Module