Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
Expand Minimize

Security Features in Windows CE .NET

Windows CE .NET

Marcus Ash and
Mukkul Dasgupta
Microsoft Corporation

January 2003

Applies to:
    Microsoft® Windows® CE .NET

Summary: Security is becoming increasingly important in the world of smart, connected devices. This paper discusses the various security mechanisms and features that device manufacturers and developers can use to build Microsoft Windows CE .NET-based applications and devices with enhanced security. Topics covered include Windows CE .NET operating system security, cryptography, authentication, smart cards and public key technologies. This paper will also discuss common security vulnerabilities and provide tips and best practices to help avoid these pitfalls.


Create a Trusted Environment
Secure Your Communications Network
Secure Your Wireless Network
Use Authentication
Use Credential Manager
Use SSL to Enhance Secure Network Communication
Encrypt Data Using CryptoAPI
Use the Protected Store API
Generate Random Data Using CryptGenRandom
Isolate Sensitive Data in a Smart Card
Practice Secure Coding Techniques
Additional Resources

Create a Trusted Environment

Microsoft® Windows® CE devices send, receive and process information that requires protection from potentially unsafe applications. To help protect your device, you can implement security measures that can help prevent the OS from loading unknown modules, restrict access to system application programming interfaces (APIs), and prevent write access to parts of the system registry. You can designate a module as trusted or not trusted when certifying applications. The kernel can use this information to prevent unauthorized applications from loading or limit their access to the system.

To help create a trusted environment, you must implement the following functions:

  • OEMCertifyModuleInit
  • OEMCertifyModule

Before the kernel loads an application, the OEMCertifyModule function verifies the application signature to help protect your system from unfamiliar applications. This ensures that the Windows CE .NET–based platform loads an application only if it contains a valid digital signature. The following table further describes the functions.

Function Description Return value
OEMCertifyModuleInit Enables the OS loader to notify the OEM that a new module is being loaded. Allows the OEM to decide whether to verify the module for safety. TRUE or FALSE
OEMCertifyModule Allows the OS loader to pass the module code (for example, DLL, EXE and OCX) to the OEM for verification that it is safe to run on the system. OEM_CERTIFY_TRUST



The following table describes the return values for OEMCertifyModule function.

Return value Description
OEM_CERTIFY_TRUST Fully trusted application to perform any operation
OEM_CERTIFY_RUN Trusted application to run, but restricted from making any privileged function calls
OEM_CERTIFY_FALSE Not trusted and therefore not allowed to run

An OEMCertifyModule function can perform any type of check on the module that is loading. For example, the function may perform a cyclic redundancy check or a certificate check. When a dynamic-link library (DLL) loads into the address space of an .exe file, the trust level of the .exe file determines the final access level. For example, when an .exe file with the OEM_CERTIFY_RUN trust level tries to load a DLL that has a higher trust level (OEM_CERTIFY_TRUST), the final trust level of the DLL is OEM_CERTIFY_RUN. On the other hand, when the .exe file tries to load a DLL that has a lower trust level, the DLL will fail to load.

The following table shows the different combinations of .exe file and DLL trust levels.

EXE trust DLL trust Final DLL trust
Note   When you implement the trusted security model, untrusted drivers will fail to load. The OEM must verify all third-party drivers as trusted.

The simplest implementation of the trusted model uses the OEMCertifyModule function to return OEM_CERTIFY_RUN for all applications. This allows applications that are not part of the ROM MODULES section of the image to run, but they are restricted from making privileged function calls. By using the OEMCertifyModule implementation at run time, you do not have to specify which applications are trusted. If OEM_CERTIFY_FALSE is returned, applications in RAM will not be able to run. Regardless of which implementation of the trusted model you choose, OEMCertifyModuleInit or OEMCertifyModule, the operating system files in the ROM MODULES section of the image will always run with full privileges.

See also

  • OEMCertifyModuleInit
  • OEMCertifyModule

Creating a signature

To create a digital signature from a file, run the file through a hash function and then sign the resulting hash with a private key. An easy way to create a digital signature from a file is to use Signfile.exe, which is included in Microsoft Platform Builder. Signfile.exe is a tool for signing an executable file with a private key supplied by a cryptographic service provider (CSP).

Signfile.exe uses the Secure Hashing Algorithm (SHA) to compute the cryptographic hash. SHA generates a 20-byte hash from an arbitrarily sized byte string. Signfile.exe pads the hash as specified by Public-Key Cryptography Standards #1 (PKCS1) and encrypts it by using the RSA public key algorithm. The key modulus length can be from 512 through 1,024 bits. The resulting signature is the same size as the modulus. For example, the signature for a 1,024 bit key is 128 bytes. Signfile.exe then uses the ImageAddCertificate and ImageGetDigestStream Microsoft Windows NT® functions to embed the signature in a portable executable (PE) file.

The following list shows the contents of the PE file memory:

  • Microsoft MS-DOS® header
  • Offset of PE header (offset 0x3c)
  • PE header
  • Section headers
  • Section
  • Debug information and certificates (if any)

The PE header begins with a 4-byte sequence, "PE\0\0", which identifies the MS-DOS header. The MS-DOS header is followed by a standard Common Object File Format (COFF) header. This COFF header is followed by an optional header that is always present on Windows .exe and .dll files. The last field in a PE header is an optional data directory table. The following table shows the size of the PE header elements.

PE header element Size
"PE\0\0" 4 bytes
COFF header 20 bytes
Optional header; standard for Windows files 96 bytes
Optional header; data directory table Size varies

Each entry in the data directory table consists of an IMAGE_DATA_DIRECTORY structure. The fifth structure in the data directory table contains certificate table information. This is stored in an array of WIN_CERTIFICATE structures. A certificate is a digitally signed statement that contains information about an entity and that entity's public key. Certificates are not loaded into memory as part of the PE file.

The following code example shows the format of a WIN_CERTIFICATE structure that is needed to support the PKCS1 standard.

typedef struct {
     // Standard WIN_CERTIFICATE fields (8 bytes)
     DWORD dwLength;
     WORD wRevision;
     WORD wCertificateType;    // = WIN_CERT_TYPE_PKCS1_SIGN
     // WIN_CERT_TYPE_PKCS1_SIGN fields follow
     DWORD cbSignedData;
     // optional signed attributes
     BYTE bSign[MAX_RSA_KEY_BITS/8]; // PKCS1 signature

Signfile.exe appends the WIN_CERTIFICATE structure to the end of the file and updates the file header accordingly. For sample Signfile.exe code, see %_WINCEROOT%\Public\Common\Oak\Tools\Signfile.

Verifying a signature

An OEM can verify that a file contains the proper signature by using the OEMCertifyModule function before the kernel loads the file.

Using this method, the kernel uses the same hash formula to calculate a signature during the verification process that it used during the signature generation process. OEMCertifyModule compares the signature it calculated from the hash to the signature in the file. If the signatures do not match, OEMCertifyModule prevents the file from loading.

Because the size of a PE file header can vary, OEMCertifyModule may not be able to process the entire header in a single call. Because the signature is at the end of the file, it is not possible to specify a hash function in the signature; you must use Secure Hash Algorithm (SHA) or another fixed hash function. When computing the hash, SHA excludes the following data from the file:

  • Checksum field in the Windows COFF header (4 bytes)
  • Certificate data directory structure (8 bytes)
  • WIN_CERTIFICATE structure (size varies)

You can either write the code that is necessary to implement the signature verification and signing tool yourself or use the sample verification library Loadauth.lib. This is included in Platform Builder in the processor-specific directory under %_WINCEROOT%\Public\Common\Oak\Lib, and the signing tool Signfile.exe.

The following table shows the functions contained in Loadauth.lib library.

Function Description
InitPubKey Initializes a public key to be used for signature verification
CertifyModuleInit Initiates the process of verifying a signature on a module for the purpose of certifying the module
CertifyModule Streams the bytes of a module for certification
CertifyModuleFinal Returns the final certification status of a file and any data embedded in the signature

To use the sample verification library (Loadauth.lib)

  1. Add OEMCertifyModuleInit and OEMCertifyModule to the OEM adaptation layer (OAL) and initialize the function pointers.
  2. Create and export a hard-coded public key.

    The key must have a PUBLICKEYBLOB format. You can use the Signfile.exe tool to complete this step.

  3. Incorporate the public key into the operating system (OS) image.

    You can do this by modifying the OAL according to the sample code in %_WINCEROOT%\Platform\%BSP%\Kernel\Hal.

The following code example shows an implementation of the OEMCertifyModuleInit and OEMCertifyModule functions using Loadauth.lib functions.

/* The signature public key BLOB */
const unsigned char g_bSignPublicKeyBlob[] = {
// Declarations for load-time signature checking 
// of RAM executables
typedef BOOL (* OEMLoadInit_t)(LPWSTR lpszName);
typedef DWORD (* OEMLoadModule_t)(LPBYTE lpData, DWORD cbData);

extern OEMLoadInit_t pOEMLoadInit;
extern OEMLoadModule_t pOEMLoadModule;
extern BOOL InitPubKey(const BYTE *KeyBlob, DWORD cbKeyBlob);

// Loadauth library routines
extern BOOL CertifyModuleInit(void);
extern BOOL CertifyModule(PBYTE pbBlock, DWORD cbBlock);
extern BOOL CertifyModuleFinal(PBYTE *ppbSignData,
                               PDWORD pcbSignData);

// Called once for each RAM executable module
// to initialize signature checking
static BOOL OEMCertifyInit(LPWSTR lpszName)
    return CertifyModuleInit();

// called one or more times after OemLoadInit
static DWORD OEMCertifyModule(LPBYTE lpData, DWORD cbData)
    if (cbData)
        // process module bytes
        return CertifyModule(lpData, cbData);
        // final call
        DWORD dwTrustLevel = OEM_CERTIFY_FALSE;
        LPBYTE pSignedData;
        DWORD cbSignedData;
        BOOL fRet = CertifyModuleFinal(&pSignedData,
        if (fRet)
            // the file has a valid signature
            // we expect the trust level to be returned as
            // signed data
            if (cbSignedData < sizeof(CHAR))
                dwTrustLevel = OEM_CERTIFY_RUN;
            switch (*pSignedData)
                case 'T' :
                    dwTrustLevel = OEM_CERTIFY_TRUST;
                case 'R' :
                    dwTrustLevel = OEM_CERTIFY_RUN;
                    dwTrustLevel = OEM_CERTIFY_FALSE;
        #ifdef DEBUG
        if (!fRet)
                                          check failed.\r\n"));

        // return one of the OEM_CERTIFY levels
        return dwTrustLevel;

void OEMInit()
    // Set the module signature verification hooks.
    pOEMLoadInit = OEMCertifyInit;
    pOEMLoadModule = OEMCertifyModule;
    // Initialize the signature verification public key.
    // Other OEM initialization steps

Note   You can use any name for the functions OEMCertifyModuleInit and OEMCertifyModule. However, it is important to initialize the two kernel pointers, pOEMLoadInit and pOEMLoadModule, in the OEMInit function to these named functions.


Signfile.exe signs an executable with a supplied private key.

You can use the following command-line parameters with this tool.

signfile [ parameters ]


-f PEFile
Specifies the file to be signed.

    Appends signature to PE File.

-k KeyName
Uses a private key from the named CryptoAPI key container.

-p Cfile
Outputs the public key to a file as a C structure.

-s AttribString
Specifies an optional attribute string to be included in signature. For example, you can add a string to indicate the trust level of the application.

-p SignFile
Outputs the signature to a file.

The following command-line example shows how to sign Xyz.dll by using the private key in key container TESTKEY1024.

Signfile -fXyz.dll -a -kTESTKEY1024

For more information about this tool, see Creating Digital Signatures.

Trusted APIs

In addition to the OEM functions, the CeGetCurrentTrust and CeGetCallerTrust APIs enable a DLL to query the trust level of a calling application. You can use these functions to verify the trust levels of the applications.

The following table shows the application programming interfaces (APIs) that can be called only by trusted applications:


The following table shows file-based APIs that are influenced by the SYSTEM attribute that can be set on a file.


For more information, see File System Security.

The following table shows database APIs that are influenced by the SYSTEM attribute that can be set on a database.

For more information, see Database Security.

In addition, the debug flags DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS of the CreateProcess API are restricted. If these flags are used by a non-trusted application, the identified process will still launch but no debugging will occur.

Debug flags, DEBUG_ONLY_THIS_PROCESS and DEBUG_PROCESS, in the CreateProcess API are also restricted.

The registry architecture in Windows CE .NET is designed to allow only trusted applications that you have identified to modify keys and values in protected portions of the registry.

Because most of the registry is unprotected, OEMs must place all important registry information in one of the protected keys.

Note   All applications have read-only access to all registry keys and values.

In Windows CE .NET, the following registry root keys and their subkeys are protected from untrusted applications:


Untrusted applications are also not allowed to modify protected data. They receive the ERROR_ACCESS_DENIED return value if they attempt to use the following registry functions:

  • RegSetValueEx
  • RegCreateKeyEx
  • RegDeleteKey
  • RegDeleteValue

See also

  • Protected Registry Keys and Values
  • Database Security
  • Core OS Interface

Object store security

The object store provides several elements of security in a trusted environment. System files are protected so that they cannot be read or modified by untrusted applications. System files are files that have the system attribute set. For more information, see File System Security.

The system also protects a set of registry keys so that they cannot be modified by untrusted applications. All applications can read all registry keys and values, but only trusted applications can modify values or subkeys below protected keys. The system protects a base set of keys. This set of keys is extensible by the OEM. For more information, see Protected Registry Keys and Values and Request Additional Secure Registry Keys.

Additionally, databases that are stored within the object store can be given a system flag. System databases cannot be read or modified by untrusted applications. Databases that are stored in separate database volumes rather than in the object store can be protected by setting the system attribute on the file, just as for any other file in the file system.

Database security

Windows CE .NET allows trusted applications to mark a system flag on databases to deny access to untrusted callers. Untrusted applications cannot open, read, or modify databases that are marked with the system flag. Trusted callers can set the CEDB_SYSTEMDB flag inside the CEDBASEINFOEX structure passed to CeCreateDatabaseEx2 or CeSetDatabaseInfoEx2 to help protect a database.

This feature helps protect a single database, not an entire database volume. Setting FILE_ATTRIBUTE_SYSTEM on the volume file helps protect database volumes. System databases cannot be created inside database volumes that do not have FILE_ATTRIBUTE_SYSTEM set to block untrusted applications from accessing and/or deleting a file containing a system database using the Microsoft Win32® file APIs. Because an untrusted application cannot access any file with the system file attribute set, adding the system flag to a database inside a database volume does not give it any additional security. Therefore, this feature is most useful in databases that are stored within the object store. Removing the system file attribute from a database volume that contains a system database will expose that database to access by untrusted applications and is not recommended.

Secure Your Communications Network

Security for communications requires special attention because the network interface provides an access point to a device that can be used remotely by an attacker. It is easier for an attacker to remain anonymous or undetected through a network-based attack. This makes determining the source of the attack more difficult.

In general, client applications on a network are relatively more secure than servers or service applications. Clients initiate contacts with specific servers and specify the nature of their requests. This allows the client applications to determine the nature of incoming data and the identity of the server or service; they can reject unsolicited communications. Although Clients are not immune to security problems, they have more control over the nature of communications because they initiate communications, which reduces the surface of vulnerability. Examples of client applications are browsers, e-mail clients and FTP clients.

Servers are more exposed because they wait to receive requests from clients on the network. Requests can come from anywhere in the network. When the server is exposed to the public interface, the surface vulnerability increases considerably. Examples of server applications include Web servers, FTP servers and Telnet servers.

The following list describes the mitigations techniques you can use:

  • Authentication. When setting up authentication, you should consider whether it is important to authenticate the client to the server, the server to the client, or both. For example, when you connect to a bank, you need to verify the identity of the entity that you are giving credentials to. In this case, you need mutual authentication. On the other hand, when you browse a Web site to get information, you may not care about the identity the entity that is providing the information.

    When considering authentication methods, you should be aware that some methods are more vulnerable than others. For example, some methods pass user names and passwords in clear text, which allows anyone who is monitoring the communication to intercept user credentials.

    For more information about authentication, see Authentication Services.

  • Tamper-resistant and privacy-enhanced technologies. To help protect data and other assets from being accessed, changed, and deleted, you can use Secure Sockets Layer (SSL) protocol. It encrypts data as it travels between the client and the server and it uses message authentication codes to provide data integrity. For more information, see Use SSL to Enhance Security of Network Communication.
  • Limited access to services and data. To help protect data and other assets, you can use access control lists with COM or Web servers to identify the users and determine the access permissions to resources or services. Many server applications offer their own form of control mechanism.
  • Encryption. To enhance privacy and integrity of data, you can use CryptoAPI. This provides services that enable data encryption/decryption schemes, authentication using digital signatures, and encoding/decoding to and from ASN.1 to Microsoft Win32-based applications.

    For more information, see Microsoft Cryptographic System.

  • Isolated process and exception handling to provide stability and availability of services. Make sure that your servers or service applications handle process or memory failures gracefully by using useful error messages. Malicious attackers may cause your application to fail or they may tie up network services by flooding the device with too many requests or by sending huge files. For example, Message Queuing (MSMQ) rejects SOAP-based messages sent through HTTP when the message sizes exceed the limits defined in the registry. MSMQ sends an error message when a message is rejected. The buffer size can be optimized for specific applications through the registry.

    You can provide stability for your application by terminating a service before the device resources are consumed. For example, Universal Plug and Play (UPnP) limits the number of subscribers to the service and rejects new subscriptions when the maximum number is reached. The subscriber limit can be optimized for specific applications through the registry.

  • Adding a firewall to your internetwork. To isolate internal data packets from exposure to the Internet, you can add a network firewall. This also helps protect random Internet traffic from entering your internetwork.

See also

Secure Your Wireless Network

Unlike wired networks, wireless networks can reach beyond the walls of buildings. In many deployments, wired network security depends on the physical security of the networks behind locked doors of the buildings. You need to pass through the building security to get access to the network. On the other hand, wireless networks can be monitored and attacked from outside the walls of buildings.

To mitigate security risks, many wireless networks provide ways to encrypt transmissions. You can use simple static encryption (WEP) network keys or more advanced techniques that generate and rotate the WEP keys to help provide privacy. For the most advanced protection, specifically for 802.11, you should use 802.1X industry standard as defined by the Institute of Electrical and Electronics Engineers, Inc. (IEEE). It provides for individual authentication and enhanced privacy by being able to generate and plug in WEP keys. Furthermore, these WEP keys can be generated per user and rotated often based on the policy. For detailed information, see the IEEE Web site.

Note   802.1X is intended only for enterprise deployments. Windows CE .NET does not support mutual authentication in wireless networks.

Windows CE .NET uses a number of authentication methods that can be plugged in to 802.1x to customize the authentication methods. You can use simple user name and passwords, certificates, smart cards, or biometrics. The EAP-MD5 supports user name and passwords and the EAP-TLS supports certificate-based authentication. You can also develop your own authentication scheme. For more information, see 802.1x Authentication and the IEEE Web site.

You should be aware of another potential security risk that is not software related. Basic interference can cause a network to slow down or stop altogether, if the RF spectrum of the network is jammed with RF noise. Although this intrusion does not compromise privacy, it poses a denial of service risk. You should work with your wireless vendor to determine the best approach to mitigate this risk.

Use Authentication

You can control access to the device and services only to authorized users by implementing authentication protocols available in Windows CE .NET. Some are built into the feature and others require you to add features to your operating system. For example, if your want to use NTLM SSP and/or Kerberos SSP, you need to add these features to your operating system. NTLM and Kerberos are implemented through the Security Support Provider Interface (SSPI).

SSPI is available through the Secur32.dll module, which is a well-defined, commonly used API for obtaining integrated security services for authentication, message integrity and enhanced message privacy. It provides an abstraction layer between application-level protocols and security protocols. Because different applications require different ways of identifying or authenticating users and different ways of encrypting data as it travels across a network, SSPI provides a way to access dynamic-link libraries (DLLs) containing different authentication and cryptographic data schemes. These DLLs are called Security Support Providers (SSPs).

The following illustration shows the relationship of the SSP DLLs to the SSPI Secur32.dll, Winsock and WinInet.

Figure 1. Windows CE .NET SSP DLLs

The available SSPs in Windows CE .NET are:

  • Microsoft Windows NT® LAN Manager SSP (NTLM SSP). NTLM SSP is based on Microsoft Windows NT LAN Manager challenge/response and NTLM version 2 authentication protocols used on networks running versions of Windows NT operating system or Windows CE .NET servers.
  • Kerberos SSP. The Kerberos protocol defines how clients interact with a network authentication service. The Kerberos authentication protocol provides a mechanism for mutual authentication between entities before a secure network connection is established.

Note that some schemes are more secure than others. You should keep in that Basic authentication is much weaker than Kerberos when you are determining which scheme best fits the needs of the application.

The following list summarizes the authentication best practices:

  • Use the StartUI component to password-protect a device. Without password protection, anyone can use the device and potentially gain access to resources on a network.
  • Enable device-locking capabilities to require a password to access a device while it is powered on.
  • If you need to keep user credentials on the device, save them in the registry. For best protection, do not store user credentials on the device. This prevents hackers from extracting the network credentials from the device if the device is stolen.
  • If you want to allow users to save authentication information on a device, use Credential Manager. However, you can increase the level of protection if you do not save user credentials on the device itself. If the application is using the Credential Manager, you can set the DisallowSavedNetworkPasswords registry value to 1. This prevents hackers from extracting the network credentials from the device in case the device is stolen.
  • Use smart cards to store user credentials. This prevents hackers from extracting the network credentials from the device in case the device is stolen.
  • Use NTLM SSP or Kerberos SSP in client-server applications. The client applications supply the user name, domain name and password and the server and client applications exchange tokens to complete the authentication.
  • Use Kerberos to provide mutual authentication between entities. This allows the server to authenticate the client and allows the client to authenticate the server. Note that NTLM does not provide mutual authentication.
  • Use a strong authentication protocol. When using NTLM SSP, you can specify the authentication protocols for the client and the server separately. To prevent NTLM SSP from using the weaker authentication protocol, set the LmCompatibilityLevelClient registry value to 3. This specifies that the client will only use NTLM v2 for authentication; however, authentication will fail if the server is not capable of NTLM v2 protocol. You can also set the LmCompatibilityLevelServer value to 2 or 3. This specifies that the server will only use NTLM v2; authentication will fail if the client is not capable of NTLM v2 protocol.

    NTLM v2 authentication protocol is only available in Windows CE .NET 4.1 and later. Servers running Microsoft Windows 2000 and later support NTLM v2.

  • Avoid authentication protocols that use clear text passwords. When using Lightweight Directory Access Protocol (LDAP), use NTLM or Negotiate instead of Basic authentication protocol. Basic uses clear text passwords.
  • Use ldap_bind_s function to use authentication services, such as NTLM or other Security Support Providers. The ldap_simple_bind function uses a clear text password for authentication. For more information, see LDAP Security Model.

See also

Use Credential Manager

You can use the Credential Manager to allow users the option to save authentication information on a device. When a Web site or another computer requests authentication through NTLM or Kerberos, an Update Default Credentials or Save Password check box appears in the Net UI dialog box. If the user selects the check box, the Credential Manager keeps track of the user's name, password and related information for the authentication service in use.

The next time that service is used, the Credential Manager automatically supplies the stored credential. If it is not accepted, the user is prompted for the correct access information. If access is granted, the Credential Manager overwrites the previous credential with the new one.

See also

Use SSL to Enhance Secure Network Communication

To enhance secure network communication, Windows CE .NET also supports Secure Sockets Layer (SSL) 2.0, SSL 3.0 and SSL 3.1 security protocols, which are available through WinInet or directly from WinSock. SSL version 3.1 is also known as Transport Layer Security (TLS). These applications use secure sockets to send and receive encoded data over the communication lines.

Secure socket implementation relies on authentication to determine if a remote host can be trusted. Remote hosts establish their trustworthiness by obtaining a certificate from a certification authority (CA). The CA can, in turn, have certification from a higher authority and so on, creating a chain of trust. To determine whether a certificate is trustworthy, an application must determine the identity of the root CA and then determine if it is trustworthy.

Windows CE .NET-based SSL uses trusted CAs. When a secure connection is attempted by an application, SSL extracts the root certificate from the certification chain and checks it against the CA database. It delivers the server certificate to the application through a certificate validation callback function, along with the results of the comparison against the CA database. You can modify the default SSL behavior by modifying the registry keys. The base registry key is HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL.

Applications bear the ultimate responsibility for verifying that a certificate is acceptable. Applications can accept or reject any certificate. If a certificate is rejected, the connection is not completed. At a minimum, a certificate should meet the following requirements:

  • The certificate must be current
  • The identity in the certificate must match the destination identity.

A list of root certificate authorities is included in the Schannel CA database. These root certificates expire and may need to be updated periodically. Adding certificates to the cryptoAPI store can also update the database.

The following root certificate authorities are included in the Windows CE .NET root certificate store:

  • VeriSign/RSA Secure Server
  • VeriSign Class 1 Public Primary CA
  • VeriSign Class 2 Public Primary CA
  • VeriSign Class 3 Public Primary CA
  • GTE Cybertrust ROOT
  • ThawtePremium Server CA
  • Thawte Server CA
  • Entrust.net Secure Server CA
  • Entrust.net Premium Secure Server CA, also known as Entrust.net CA (2048)

See also

  • SSL Support

Encrypt Data Using CryptoAPI

CryptoAPI provides services that enable application developers to add data encryption/decryption schemes, to authenticate using digital certificates, and to encode/decode to and from ASN.1 to their Microsoft Win32®-based applications. Application developers can use the functions in CryptoAPI without detailed knowledge of the underlying implementation. CryptoAPI works with a number of cryptographic service providers (CSPs) that perform the actual cryptographic functions, such as encryption, decryption and key storage and security.

The three elements of the Microsoft cryptographic system are the operating system, the application and the CSP. Applications communicate with the operating system through the CryptoAPI layer and the operating system communicates with the CSPs through the cryptographic service provider interface (CSPI). The following illustration shows the concept.

Figure 2. CryptoAPI data encryption

CSPs are independent modules, usually DLLs that contain algorithms and perform all cryptographic operations. Ideally, CSPs are written to be independent of a particular application, so that any application will run with a variety of CSPs. In reality, however, some applications have specific requirements that require a customized CSP. OEMs can write their own CSP package and add it to the registry.

The following table shows the predefined CSPs included in Windows CE .NET.

CSP Description
RSA Base Provider Supports digital signature and data encryption. It is considered to be a general-purpose cryptographic tool.
RSA Enhanced Provider Supports 128-bit key encryption. It provides stronger security through longer keys and additional algorithms.
Smart Card CSP Supports smart cards for Windows. A sample smart card CSP in source code can be found in the %_WINCEROOT%\Public\Common\Sdk\Samples\ directory. This CSP illustrates how to properly integrate a smart card with the various functions and services provided by CryptoAPI.

Applications can use CryptoAPI functions to:

  • Generate and exchange keys
  • Encrypt and decrypt data
  • Encode and decode certificates
  • Manage and enhance security of certificates
  • Create and verify digital signatures and compute hash

The capabilities provided by CryptoAPI 1.0 in Windows CE are very similar to those in Windows 2000 and Windows NT; however, only a subset of CryptoAPI 2.0 is supported. The following capabilities available in CryptoAPI 2.0 are supported in Windows CE: encoding and decoding digital certificates based on the X.509 standard and certificate management. The following capabilities are not supported: tools to manage certificate revocation lists (CRLs) and certificate trust lists (CTLs), low-level messaging functions, and simplified messaging functions.

Coredll.lib exports CryptoAPI 1.0 functions and Crypto32.lib exports the CryptoAPI 2.0 functions; all these functions are defined in the Wincrypt.h header file.

The following table shows the algorithms the CSPs contain and their descriptions.

Algorithm Description
CALG_3DES Triple DES encryption algorithm.
CALG_3DES_112 Two-key triple DES encryption.
CALG_DES DES encryption algorithm.
CALG_HMAC* MAC keyed-hash algorithm.
CALG_MAC* MAC keyed-hash algorithm.
CALG_MD2* MD2 hashing algorithm.
CALG_MD4 MD4 hashing algorithm.
CALG_MD5* MD5 hashing algorithm.
CALG_RC2* RC2 block encryption algorithm.
CALG_RC4* RC4 stream encryption algorithm.
CALG_RC5 RC5 block encryption algorithm.
CALG_RSA_KEYX* RSA public-key exchange algorithm.
CALG_RSA_SIGN* RSA public-key signature algorithm.
CALG_SHA* SHA hashing algorithm.
CALG_SSL3_SHAMD5 SLL3 client authentication algorithm used by the schannel.dll operations system. This ALG_ID should not be used by applications.

* Algorithms supported by the Microsoft Base Cryptographic

Best practices

If possible, do not save sensitive data in RAM, the file system, or the registry. The following list shows best practices to use if you must save sensitive data:

  • Cache the data to process memory rather than to the registry or file system.
  • Allow the user to choose whether to save sensitive information, such as credentials. The registry setting HKEY_LOCAL_MACHINE\Comm\Security\DisallowSavedNetworkPasswords identifies whether the option to save credentials is displayed. When the value is 1, no option to save credentials is displayed. When the value is 0, the user interface (UI) allows the user to save credentials.
  • Encrypt and decrypt application data by using CryptProtectData and CryptUnprotectData.
    Note   Although CryptProtectData and CryptUnprotectData use entropy, the encryption is only as strong as the data supplied for encryption. It is important to supply a strong password. A user who supplies a weak password can weaken the effectiveness of encryption.
  • Clear data from temporary storage after use.
  • When appropriate, the application should obtain an additional password or other secret data from the user, and then use pOptionalEntropy to supply the information to CryptProtectData and CryptUnprotectData.

See also

Use the Protected Store API

To help protect sensitive information and to prevent data tampering, the protected store API provides a convenient solution to cryptography, key management and user experience issues. The two CryptoAPI functions, CryptProtectData and CryptUnprotectData, take the user's logon credentials to lock and unlock the private data.

Typically, only a user with logon credentials matching those of the encrypter can decrypt the data. In addition, decryption must be done on the computer where the data was encrypted.

The benefits of the protected store include the following:

  • An easy-to-use application that takes data and optional password or other entropy and receives shrouded data.
  • Enhanced data protection from other users who are able to log on to the same device.
  • Enhanced data protection from tampering while the device is offline.
  • The transparent use of logon credentials to supply the entropy for data protection.
  • OEM extensibility that allows the use of hardware tokens such as smart cards or biometric devices.

See also

Generate Random Data Using CryptGenRandom

Use CryptGenRandom to generate random data. This function has two of the properties of a good random number generator: unpredictability and even value distribution.

On a Windows CE .NET device, entropy is generated for CryptGenRandom by the following sources:

  • Thread and kernel switches (CeGetRandomSeed)
  • The current process identifier (GetCurrentProcessId)
  • The current thread identifier (GetCurrentThreadId)
  • Ticks since boot (GetTickCount)
  • Current time (GetLocalTime)
  • Memory information (GlobalMemoryStatus)
  • Object store statistics (GetStoreInformation)

All of this information is added to a buffer, which is hashed using MD4 and used as the key to modify a buffer, using RC4, provided by the user.

If Cryptography Services features are not included in your platform, you can also use CeGenRandom to generate random numbers.

Isolate Sensitive Data in a Smart Card

You can add an additional layer of security to a Windows CE .NET device by using smart cards to store authentication information or a digital signing mechanism. You can write a custom CryptoAPI provider that exploits a smart card's ability to store information with enhanced security.

The Windows CE .NET smart card subsystem supports CryptoAPI through smart card service providers (SCSPs), which are DLLs that enable access to specific services. The subsystem provides a link between the smart card reader hardware and the applications. Windows CE .NET does not provide SCSPs; typically, the smart card vendor provides the appropriate SCSPs. However, Windows CE .NET provides the interfaces described in the following table.

Subsystem component File Description
Resource manager Scard.dll Uses the Win32 APIs to manage access to multiple readers and smart cards.
Resource manager helper library Winscard.dll Exposes PC/SC services for using smart cards and smart card readers.
Smart card reader helper library Smclib.lib Provides common smart card driver support routines and additional T=0 and T=1 protocol support to specific drivers as needed.
Sample smart card reader drivers Pscr.dllbulltlp3.dllstcusb.dll SwapSmart PC reader driver. Serial reader driver. Universal serial bus (USB) reader driver.

A typical smart card system consists of applications, a subsystem that handles communication between smart card readers and the applications, readers and the smart card.

Implementing a fraction of the smart card CryptoAPI service provider functionality in a separate hardware keeps the cryptographic keys and operations safer because it:

  • Provides tamper-resistant storage for helping to protect private keys and other forms for personal information.
  • Isolates security-critical computations involving authentication, digital signatures and key exchange from other parts of the system.
  • Enables portability of credentials and other private information.

In an organization that uses smart cards, users do not have to remember any passwords at all, only a personal identification number, and they can use the same certificate for other security purposes, such as digitally signing e-mail.

See also

Practice Secure Coding Techniques

The book Writing Secure Code by Michael Howard and David LeBlanc, Microsoft Press, 2002, is an excellent source of secure programming best practices. The book discusses the vulnerabilities of applications to malicious attacks and shows examples of code defects.

One important issue discussed in the book and often overlooked by application developers is buffer overruns. You should avoid using the following C/C++ functions. These functions can cause buffer overruns and cause your application to fail or enable code to be injected into your process space:

  • strcpy
  • strcat
  • memcpy
  • gets
  • sprintf
  • scanf

Be especially careful if you call any of the listed functions to copy data into a stack-based buffer. Generally, it is much easier to execute malicious code when the buffer is allocated on the stack, rather than memory allocated on the heap. For more information about buffer overruns and other techniques for writing secure code, refer to Writing Secure Code, by Michael Howard and David LeBlanc, Microsoft Press Books, 2002.

As the OEM or application developer, you can use samples, such as VMini for sharing your ethernet network and debugging connections, to quickly build and test your application or operating system. To help protect against these types security vulnerabilities, before you ship your product, you must replace the samples with your own application code.

Additional Resources

Windows CE .NET Product Documentation: Enhancing the Security of a Device

Windows Embedded Newsgroups

© 2015 Microsoft