Download Security Features in Windows CE

Security Features in Windows CE
Marcus Ash and Mukkul Dasgupta
Microsoft Corporation
Originally published January, 2003
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 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 TRUE or FALSE
notify the OEM that a new
module is being loaded.
Allows the OEM to decide
whether to verify the
module for safety.
OEMCertifyModule
Allows the OS loader to pass OEM_CERTIFY_TRUST
the module code (for
OEM_CERTIFY_RUN
example, DLL, EXE and OCX) OEM_CERTIFY_FALSE
to the OEM for verification
that it is safe to run on the
system.
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
OEM_CERTIFY_RUN
OEM_CERTIFY_RUN
OEM_CERTIFY_RUN
OEM_CERTIFY_RUN
OEM_CERTIFY_TRUST
OEM_CERTIFY_RUN
OEM_CERTIFY_TRUST
OEM_CERTIFY_RUN
DLL fails to load
OEM_CERTIFY_TRUST
OEM_CERTIFY_TRUST
OEM_CERTIFY_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 96 bytes
for Windows files
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.
Listing
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 bSignedData[MAX_WIN_CERT_SIGN_DATA_LEN];
BYTE bSign[MAX_RSA_KEY_BITS/8]; // PKCS1 signature
} PKCS1_MODULE_SIGN ;
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.
Listing
/* The signature public key BLOB */
const unsigned char g_bSignPublicKeyBlob[] = {
0x06,0x02,0x00,0x00,0x00,0x24,0x00,0x00,0x52,0x53,0x41,0x31,0x00,0x02,
0x00,0x00,0x01,0x00,0x01,0x00,0xb1,0x00,0x93,0x7c,0x18,0x63,0xce,0xf3,
0x23,0xe3,0x57,0x74,0x13,0x54,0x17,0x2c,0xdb,0xf6,0x56,0x77,0xb3,0x8d,
0x34,0x6c,0x41,0x3d,0x4e,0xbb,0xc1,0xaf,0x3d,0x17,0xb6,0x0e,0x70,0x72,
0x43,0x12,0x1d,0xb1,0x2a,0x57,0x05,0x27,0x58,0x63,0xef,0xb7,0x3b,0x71,
0xee,0xe4,0xcd,0x14,0xbe,0xf7,0x32,0xec,0xa2,0xae,0xbf,0x9a,0x6b,0x75
};
// 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);
}
else
{
// final call
DWORD dwTrustLevel = OEM_CERTIFY_FALSE;
LPBYTE pSignedData;
DWORD cbSignedData;
BOOL fRet = CertifyModuleFinal(&pSignedData,
&cbSignedData);
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;
else
switch (*pSignedData)
{
case 'T' :
dwTrustLevel = OEM_CERTIFY_TRUST;
break;
case 'R' :
dwTrustLevel = OEM_CERTIFY_RUN;
break;
default:
dwTrustLevel = OEM_CERTIFY_FALSE;
break;
}
}
#ifdef DEBUG
if (!fRet)
lpWriteDebugStringFunc(TEXT("OEMCertifyModule:signature
check failed.\r\n"));
#endif
// 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.
//
InitPubKey(g_bSignPublicKeyBlob,sizeof(g_bSignPublicKeyBlob));
//
// 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
Signfile.exe signs an executable with a supplied private key.
You can use the following command-line parameters with this tool:
signfile [ parameters ]
Parameters
-f PEFile
Specifies the file to be signed.
-a
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 list shows the application programming interfaces (APIs) that
can be called only by trusted applications:
AllocPhysMem
CeSetThreadPriority
CeSetThreadQuantum
CheckPassword
ContinueDebugEvent
CryptUnprotectData
DebugActiveProcess
ForcePageout
FreeIntChainHandler
FreePhysMem
InterruptDisable
InterruptDone
InterruptInitialize
KernelLibIoControl
LoadDriver
LoadIntChainHandler
LoadKernelLibrary
LockPages
PowerOffSystem
ReadProcessMemory
ReadRegistryFromOEM
RegCopyFile
RegReplaceKey
RegRestoreFile
RegSaveKey
SetCleanRebootFlag
SetCurrentUser
SetInterruptEvent
SetKMode
SetPassword
SetPasswordStatus
SetProcPermissions
SetSystemMemoryDivision
SetUserData
UnlockPages
VirtualCopy
VirtualSetPageFlags
WaitForDebugEvent
WriteProcessMemory
WriteRegistryToOEM
The following list shows file-based APIs that are influenced by the SYSTEM
attribute that can be set on a file.
CopyFile
CreateFile
CreateFileForMapping
DeleteAndRenameFile
DeleteFile
MoveFile
RemoveDirectory
SetFileAttributes
For more information, see File System Security.
The following list shows database APIs that are influenced by the SYSTEM
attribute that can be set on a database.
CeCreateDatabaseEx2
CeDeleteDatabaseEx
CeMountDBVol
CeOpenDatabaseEx2
CeSetDatabaseInfoEx2
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 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, the following registry root keys and their subkeys are
protected from untrusted applications:







HKEY_LOCAL_MACHINE\Comm
HKEY_LOCAL_MACHINE\Drivers
HKEY_LOCAL_MACHINE\HARDWARE
HKEY_LOCAL_MACHINE\Init
HKEY_LOCAL_MACHINE\Services
HKEY_LOCAL_MACHINE\SYSTEM
HKEY_LOCAL_MACHINE\WDMDrivers
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 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, email
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:




Authentication Services
Use SSL to Enhance Security of Network Communication
Cryptography
Certificates
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 does
not support mutual authentication in wireless networks.
Windows CE 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. 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 SSP DLLs
The available SSPs in Windows CE 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 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 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:




Authentication Services
LDAP Client
Smart Card
Credential Manager
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:




Credential Manager
CredRead
CredWrite
CredFree
Use SSL to Enhance Secure Network Communication
To enhance secure network communication, Windows CE 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 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 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.
CSP
Description
RSA Base Supports digital signature and data
Provider encryption. It is considered to be a
general-purpose cryptographic tool.
RSA
Supports 128-bit key encryption. It provides
Enhanced stronger security through longer keys and
Provider additional algorithms.
Smart
Supports smart cards for Windows. A sample
Card CSP 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_SHA1*
Same as CALG_SHA.
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\DisallowSavedNetworkP
asswords 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:


Cryptography
Certificates
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:

Protected Store
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 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 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 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 does not provide SCSPs;
typically, the smart card vendor provides the appropriate SCSPs. However,
Windows CE provides the interfaces described in the following table.
Subsystem File
component
Description
Resource Scard.dll
manager
Uses the
Win32 APIs
to manage
access to
multiple
readers and
smart
cards.
Resource Winscard.dll
manager
helper
library
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 email.
See also:


Smart Card
Cryptography
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.