Поделиться через

Cryptography Security (Windows Embedded CE 6.0)

  • Статья

1/6/2010

CryptoAPI handles credentials and other assets that unauthorized users can access. The following list summarizes the best practices for protecting these assets.

Ee498182.collapse(en-US,WinEmbedded.60).gifBest Practices

Call CryptGetKeyParam to get key length

Your application should verify the key length of the encryption algorithm before using the default service provider. This ensures that the application is using the correct provider. The application can delete or reset the default provider for a device by changing the registry or by calling CryptSetProviderEx. Avoid using CryptSetProviderEx, except as a part of the administrative setup of a device. CryptSetProviderEx affects the behavior of applications that rely on the default behavior of CryptoAPI.

Check certificate status

Applications calling CryptoAPI must check the certificate status retrieved by certain cryptography functions. This will prevent an attacker from using a key pair or certificate that has been revoked to sign digital data. Possible certificate statuses are defined for the CERT_TRUST_STATUS structure.

Protect private keys and user credentials

CryptoAPI stores private keys and applications store user credentials on each device. To prevent hackers from tampering with private keys and/or extracting the user credentials, you must implement a device locking capability that requires a password to access the device when it is powered on. Also, for optimum protection, you can use a smart card to store private keys and use the Smart Card CSP. Implementing proper device protection mechanisms is crucial to the safety of private keys and user credentials.

Do not create your own random number generator

Use CryptGenRandom to generate random data.

Protect application data

To protect sensitive information and to prevent data tampering, use CryptProtectData and CryptUnprotectData. 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.

Note

Although CryptProtectData and CryptUnprotectData use entropy, the encryption is only as strong as the user data supplied for encryption. It is important for the user 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

Your application should clear data from temporary storage after use by calling SecureZeroMemory. In addition, the application should not store a secret key itself. For example, if the application needs to verify that a user knows a password, it can compare the hash of the secret key entered by the user with the hash of the application-stored secret key. In this case, the application only needs to store the hash.

Save sensitive data

If possible, do not save sensitive data in RAM, the file system, or the registry. Instead, cache the data to process memory. Give the user a choice 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, the user interface (UI) does not display an option to save credentials. When the value is 0, the UI allows the user to save credentials.

Specify the service provider by name

Windows Embedded CE includes three cryptographic service providers: Microsoft RSA Base Provider, Microsoft Enhanced Cryptographic Provider, and Smart Card CSP. In Windows CE .NET 4.1 and later, the default provider is Microsoft Enhanced Cryptographic Provider. For Windows Embedded CE, you can also add your own cryptographic service provider. Use the strongest service provider that is appropriate for your application. To ensure that it uses the correct provider, an application should always specify the service provider by name. If the name of the service provider is not specified, CryptoAPI uses a provider of the type designated. This unspecified service provider may be a weaker provider than the application needs.

Ee498182.collapse(en-US,WinEmbedded.60).gifDefault Registry Settings

You should be aware of the registry settings that apply to security. If a value has security implications, you will find a Security Note in the registry settings documentation.

For information about cryptography registry settings, see Cryptography Registry Settings.

It is important to note that if you have the encryption keys forCryptProtectData andCryptUnprotectData stored in the registry, an unauthorized user can gain access to them more easily.

Ee498182.collapse(en-US,WinEmbedded.60).gifFIPS Compliance

Windows Embedded CE supports the technologies that are required for Federal Information Processing Standard (FIPS) compliance. FIPS 140-1 and its successor FIPS 140-2 are U.S. Government standards that provide a benchmark for implementing cryptographic software. They specify best practices for implementing cryptographic algorithms, handling key material and data buffers, and working with the operating system.

An evaluation process administered by the National Institute of Standards and Technology (NIST) Cryptographic Module Validation (CMV) Program (http://csrc.nist.gov/cryptval/) allows encryption product vendors to demonstrate the extent of their compliance with the standards, and thus the trustworthiness of their implementations. Some U.S. Government agencies purchase only FIPS 140-1 or FIPS 140-2 evaluated encryption products. Moreover, the security community at large values products that have completed this evaluation, as it carries the sanction of an independent third party.

While NIST CMV accepts validation test reports for cryptographic modules against only FIPS 140-2 as of May 26, 2002, it states on the CMV program Web page that "agencies may continue to purchase, retain and use FIPS 140-1 validated products after May 25, 2002."

One Windows Embedded CE cryptographic software component has completed the U.S. Government FIPS 140-1 or FIPS 140-2 (as appropriate) evaluation and certification process: the Windows Embedded CE Enhanced Cryptographic Service Provider 5.01 (default cryptographic service provider). This component is used by a variety of Microsoft products running on Windows Embedded CE-based platforms.

The FIPS-compliant cryptographic service provider furnishes the cryptographic services that are used to secure a variety of protocols, including:

  • The IETF RFC 2246 Transport Layer Security (TLS) protocol that is used between Web browser (Internet Explorer) and Web server (Internet Information Server)
  • IPSEC family of protocols that can be used for IETF standard end-to-end encryption with Windows 2000, Windows XP, or Windows Server 2003 systems, which includes:
    • L2TP/IPSec VPN client and server for remote access
    • L2TP/IPSec tunnels for gateway-to-gateway VPN connections
    • IPSec tunnels for gateway-to-gateway VPN connections
  • S/MIME e-mail encryption protocol that is used to protect the confidentiality and integrity of e-mail messages
  • SQL Tabular Data Stream (TDS) protocol that is used with the Windows TLS/SSL Security Provider between SQL clients and SQL Server 2000, or later
  • Microsoft Remote Desktop Protocol (RDP) 5.2, or later, of Terminal Service Client, which is available from Windows Server 2003 and runs on a Windows XP (or above) machine, connecting to a Terminal Server session on a Windows 2003 Server configured for FIPS-compatible encryption

The FIPS-compliant cryptographic service provider can be invoked via standard Windows APIs (CryptoAPI). Thus, third-party and end-user-developed software that requires cryptographic services can call on the services provided by the FIPS 140-1 or FIPS 140-2 cryptographic service provider in the operating system.

See Also

Concepts

Microsoft Enhanced Cryptographic Provider

Other Resources

Cryptography
Certificates