Posted by Upender Sandadi
Happy New Year to everyone!!! I hope you all had a wonderful start to the new year. This was one of those articles I had written before the year end but never got it posted. So here we go. One more aritcle on CE 6.0. This time the topic is: Module security.
In Windows CE releases previous to CE 6.0, there was a concept of trust associated with each module (dll or exe). Each module can be categorized as:
As you can see module trust is fully governed by the certificate (or there lack of) associated with the given module. On general embedded systems where generally certification subsystem is not in the image by default one can still limit the API calls to only those modules which are in ROM.
Now coming to CE 6.0, concept of module trust is treated slightly differently and is actually divided into two parts:
Now let us look at “Load Privilege” in CE 6.0 in little bit more detail. In CE 6.0, load privilege for a module is based on the following rules:
Given the above rules, here are the possible ways a CE6 device can be built.
Case 1: if an OEM wants to develop a closed box solution using CE 6.0, one possible approach would be to
Once an image is built with the above properties, then no third party applications or modules can be loaded on that system.
Case 2: if an OEM wants to develop a semi-closed box solution using CE 6.0, where only signed modules can be loaded in the system, then the approach would be to:
This would be a good solution if OEM wants to publish an SDK for their device so that ISVs can write applications targeting their platform. By enforcing that the applications be signed with an OEM certificate, OEMs can control what applications are allowed to run on the device.
Case 3: if an OEM wants to develop a completely open solution using CE 6.0, then the approach would be to:
In this case where SYSGEN_CERTMOD is not set, then 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 what APIs the module can call depends on which mode (kernel mode or user mode) threads in that module are running in. This is given by which address space the module is loaded in. See the API call privileges notes given above.
I hope this clarifies the role certmod plays in CE6.0 images.
UPDATE (April 2nd 2007):
The default sources file in public\common\oak\drivers\security\certmod\dll lists the DLLENTRY as "DllMain". This is not a problem for CE build since that uses the settings specified in public\common\cesysgen\makefile which sets the right DLLENTRY. So if you are going to replace certmod with your own certification module, make sure you set the DLLENTRY to "_DllMainCRTStartup". This is required for evgen (library which certmod links with) to be properly initialized when certmod.dll loads.