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.
.gif)
CSPs are independent modules, usually a DLL, 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. EOMs 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 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. |
| Diffie-Hellman CSP | Supports Diffie-Hellman (D-H) key exchange, SHA hashing, DSS data signing, and DSS signature verification. |
| 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 secure certificates.
- Create and verify digital signatures and compute hash.
The capabilities provided by CryptoAPI 1.0 in Windows CE are very similar to the 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 algorithmUsed 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.
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, 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
Last updated on Wednesday, April 13, 2005
© 2005 Microsoft Corporation. All rights reserved.