Adding a firewall to your internetwork

• 
  Authentication Services
  
• 
  Use SSL to Enhance Security of Network Communication
  
• 
  Cryptography
  
• 
  Certificates
  

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.

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.
  

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.
  

• 
  Authentication Services
  
• 
  LDAP Client
  
• 
  Smart Card
  
• 
  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
  

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.
  

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)
  

• 
  SSL Support
  

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.

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.

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
  

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.

* Algorithms supported by the Microsoft Base Cryptographic

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'>CryptProtectData and CryptUnprotectData.
  

• 
  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.
  

• 
  Cryptography
  
• 
  Certificates
  

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,

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.
  

• 
  Protected Store
  

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)
  

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

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.

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.
  

• 
  Smart Card
  
• 
  Cryptography
  

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.

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