Core OS Security (Windows CE 5.0)
Use the following best practices to enhance the security and reliability of the kernel:
Do not try to hide unencrypted information in ROM because it is information that can be read by everyone.
Do not embed encryption keys in your applications and then save the encrypted files to the file system. Always use some form of encryption, such as the Protected Store API.
Trusted modules should always have the "SYSTEM\" prefix in their event names. This forces the kernel to check the caller's trust level.
Note The "SYSTEM\" prefix can only be used by trusted modules.
Do not use the LoadLibrary function to make assumptions about the system configuration. An application that is not trusted can load a false DLL with the same name as a trusted application. This causes subsequent attempts to load the trusted application to fail because the loader shows it has already loaded the DLL.
When a trusted application calls LoadLibrary, the loader checks the trust level. Because a false DLL is loaded, the loader will fail the check and return failed to LoadLibrary. For example, a rogue application can load a false encryption module, Capi.dll. When a trusted application tries to load Capi.dll, the load will fail. At this point, the trusted application should not make incorrect assumptions, such as it is running in a development configuration instead of a production configuration.
- All configuration information should come from a known good source such as a secure registry or encrypted information.
- Failover should not cause behavior that is not secure.
For more information about Windows CE security services, see Enhancing the Security of a Device.
See Also
Core OS Design Development | Core OS Reference | Core OS Registry Settings
Send Feedback on this topic to the authors