http://www.microsoft.com/DEVNEWS/CAPI4.HTM (PC Press Internet CD, 03/1996)by Elizabeth Wiewall
February 26, 1996 (Revised March 1)
Is your app insecure? Maybe it needs a new companion.
For software applications to take advantage of increasingly sophisticated and feature-rich communications technology, they require an application programming interface (API) that provides security and encryption services. Anyone developing Windows-based collaborative workgroup computing applications, Internet applications, or desktop applications that need security should look at the Microsoft Cryptographic API (CryptoAPI), a new Win32 API.
Some application examples include:
Microsoft's design goals were to make crypto-enabled application development functional, flexible, usable, and exportable for all Windows-based developers.
The architecture of CryptoAPI is modular; all of the actual cryptographic operations are performed by replaceable components known as cryptographic service providers (CSPs). Each CSP contains the core cryptographic algorithm and is written independently of the application, so an application should be able to run with a variety of different CSPs. This allows end users to choose a CSP that has an appropriate level of security, without having to modify the application.
The CryptoAPI supports digital signatures, store-and-forward encryption, and online encryption. It contains 24 function calls that fall into five function groups: Context management, key generation/management, key exchange, data encryption/decryption, and hashing/signature functions.
Context management functions
Applications use these functions to connect to a CSP. The functions enable applications to choose a specific CSP by name, or get a CSP with a specific class of functionality.
Key generation functions
These functions allow applications to generate and customize cryptographic keys. Keys can be generated randomly or derived from a user password. The functions include full support for changing initialization vectors, chaining modes, and other encryption features.
Key exchange functions
These functions allow applications to exchange or transmit keys. When encryption keys are transferred out of the safety of the CSP, they are encrypted with the user's public key, and stay so until they reach the destination user's application. Thus, keys can be transmitted without being compromised. Key exchange functions can also be used to implement a fully authenticated key-exchange protocol, such as PCT or secure sockets layer (see accompanying article, "Other Microsoft Security Technologies").
Data encryption/decryption functions
These functions allow applications to encrypt or decrypt data. Support is also included for simultaneously encrypting and hashing data.
Hashing/signature functions
These functions allow applications to compute a cryptographically secure digest (or "hash") of data, based on the content of a file or message, and enable those hashes to be digitally signed. Once a file or message has been signed, anyone possessing the signer's public key can easily verify the signer's identity and verify that the file or message has not been modified since it was signed.
Figure 1: The CryptoAPI System Architecture
Physically, each CSP is a dynamic-link library (DLL) with an associated cryptographic signature authorizing it for use by CryptoAPI. The job of the CSP is to protect private key information from unintentional exposure.
Note that applications do not communicate with CSPs directly. Instead, all cryptographic function calls are routed through the operating system. Applications with complex requirements may connect to several CSPs at once, using a parameter present in each CryptoAPI function to indicate to the operating system which CSP should be used for the particular operation.
Many CSPs will consist of more than just one DLL, as illustrated in Figure 2.
Figure 2: CSP partitioning options
Many CSPs will have additional components that provide a more secure environment--either for cryptographic computations or for secure key storage. Two examples:
Microsoft licensed cryptographic technology from RSA Data Security to create the base or default software CSP that ships with the operating system. The Microsoft RSA Base provider consists of a software implementation PROV_RSA_FULL provider type (see accompanying table of provider types). This CSP supports both public-key and symmetric (or "conventional") cryptography. It is exportable and will ship everywhere that the CryptoAPI is present.
You will first see the CryptoAPI in Windows NT 4.0 (the release of the Windows NT operating system with the Windows 95 shell) and in a future version of Windows 95. The beta of Windows NT 4.0 was shipped in February to all Microsoft Developer Network Level 2 and Level 3 members. You can download CryptoAPI sample code and the Microsoft CryptoAPI Application Programming Guide from Microsoft's Internet Development Toolbox Web site ).
The Microsoft RSA Base Provider uses the RSA Public-Key algorithm for creating digital signatures and for encrypting key material so it can be safely transported to another user (the process known as "key exchange"). Public keys are limited to 512 bits.
For bulk data encryption, the base provider uses either the RC2 block cipher or the RC4 stream cipher. These are two of the most common encryption algorithms. The encryption keys are limited to 40 bits.
For the creation of message digests, or "hashes," the base provider supports the MD2, MD5, and SHA hash algorithms, which are also among the most common hash algorithms.
An application writer creates crypto-enabled software based on a particular CSP provider type. Once an application has successfully connected to a CSP of a particular type--via the CryptAcquireContext function--it can assume that a certain minimum functionality is supported in each of the four categories: key exchange, signature, encryption, and hashing.
Every CSP of a given provider type must at a minimum support all of the listed algorithms for that type. Additional CSP types will be defined as needed. The table below, Figure 3, lists some of the CSP types already implemented, as well as some that Microsoft anticipates at some point in the future.
Figure 3: CSP provider types
As mentioned previously, the Windows NT 4.0 operating system includes a base or default software CSP. This CSP will be exportable from the U.S. to all countries where the Windows NT operating system is already available. However, the CSP can be replaced by the end user. Companies that make hardware cryptographic devices such as smart cards, or companies that create cryptographic algorithms may want to create a CSP for their own architecture.
If you are interested in creating a CSP, please consult the Microsoft CryptoAPI Web page in the Internet Development Toolbox, and follow the instructions for requesting the developer's kit, known as the CSPDK.
The Microsoft CryptoAPI eliminates the need for each ISV to write its own cryptographic code. Instead, each ISV can simply call replaceable cryptographic service providers, including a base provider that Microsoft will ship in the operating system. The base CSP is already cleared for export.
CryptoAPI also has the potential to ease export approval for applications that use CryptoAPI CSPs to provide security. Since the application does not actually contain any crypto code (remember, the operating system is called via CryptoAPI), Microsoft expects that U.S. government export authorities will waive the export approval requirement for CryptoAPI-enabled applications that do not otherwise implement secure functions. This would occur as soon as federal regulations have been amended.
If you're planning to develop a crypto-enabled application or have questions, send e-mail to cryptAPI@microsoft.com, or see the WinCrypt section in the CompuServe Win32 forum.
Elizabeth Wiewall is a technical evangelist in Microsoft's Developer Division.
To provide better security and privacy on both public and private networks, Microsoft's team of cryptographers and designers are developing new technologies based on public and symmetric key cryptography.
The Private Communication Technology (PCT) specification is designed to secure general-purpose business and personal communications on the Internet. Its features include privacy, message integrity, authentication, and mutual identification. PCT enhances secure sockets layer (SSL) in the areas of authentication and protocol efficiency. By separating authentication from encryption, PCT allows applications to use authentication that is significantly stronger than the 40-bit key limit for encryption allowed by the U.S. government for export. Microsoft's implementation of PCT is backward-compatible with SSL. To request the PCTRef implementation source code for your Windows NT-based or Unix Web server, fill out the request form on the Microsoft Secure Technologies page. PCT will be built into Microsoft's next release of the Internet Explorer Web browser. Watch for other browsers to incorporate this technology as well.
Secure Electronic Transactions (SET) is a converged specification for secure credit card payment on the Internet. SET emerged in February from the convergence of efforts by Microsoft, Visa, MasterCard, IBM, and Netscape. The resulting technology specification will be owned by Visa and Mastercard. Microsoft will create a Win32 implementation of this secure credit card payment scheme for the Internet. Watch the Microsoft Secure Technologies page (http://pct.microsoft.com) for more detail on this secure card payment service and how to integrate it into your products.
MasterCard and Visa plan to publish SET specifications on their respective World Wide Web sites by the end of March (http://www.visa.com and http://www.mastercard.com). Officials of Visa and MasterCard expect that banks will be able to offer secure bankcard services via the Internet to their cardholders in the fourth quarter of 1996.
Also, American Express Travel Related Services Company, Inc. plans to license Microsoft's version of SET protocol for online transactions using the American Express charge card or Optima credit card. It will allow merchants conducting online commerce to route information directly to American Express, avoiding third-party surcharges to consumers. The two companies expect to implement the Internet payment system in the second half of 1996.