Windows 2000 Developer Services | Programming Server-Side Applications for Microsoft Windows 2000 (Microsoft Programming)

[Previous] [Next]

Before discussing code, I would like to mention the different APIs, or function groups, that Windows 2000 provides to help the developer deal with cryptography, certificates, and security protocols.

CryptoAPI Overview

As you can imagine from our previous discussion on cryptography, software that uses encryption has a fair number of details to consider. At minimum it must be able to create and maintain keys. And it must be able to use these keys to encrypt and decrypt data.

If asymmetrical key encryption is needed, software must also be able to create and manage public/private key pairs. As mentioned earlier, certificates have become an important part of public key management, and software might also have to manage certificates.

Fortunately, the CryptoAPI (also referred to as CAPI) provides all the functionality needed to manage keys and certificates as well as to encrypt and decrypt data. The CryptoAPI is useful if you will be rolling your own security protocol for use with your client and server software.

Typically, you will want to use an existing security protocol, which, thanks to the Security Support Provider Interface (SSPI), you can use without worrying about the details of cryptography and key management.

NOTE
I will cover the CryptoAPI functions used for certificate management in the section "CryptoAPI" later in this chapter. For more information on the CryptoAPI, see the Platform SDK documentation.

Security Support Provider Interface (SSPI)

Windows is able to communicate using different security protocols such as NTLM and Kerberos, which we have already discussed. (I will discuss SSL later in this chapter.) The system's internal implementations of these protocols are in modular units known as Security Support Providers, or SSPs. (An individual SSP is sometimes called a security package, or package). This implementation allows the system to use multiple security protocols in a standardized way. It also allows the developers of Windows to create new SSPs and incorporate them into the system. (In fact, it is also possible for third-party vendors to create SSPs for use with Windows.)

You might have guessed that the system also provides a programming interface for SSPs that allows your software to take advantage of a security protocol provided by the system. This interface is called the Security Support Provider Interface, or the SSPI. The SSPI is a very powerful set of functions. Here are some of the features it provides:

Communication transport independence

Common interface to multiple SSPs

Authentication (including impersonation)

Message privacy (encryption)

Message integrity (signing)

Each of these features is managed by the SSPI functions, so your code doesn't need to deal with the details of encryption and implementing a security protocol. Your code can do what it is already good at, which is communicating information to and from its clients and performing tasks on their behalf.

Before discussing the protocols provided by the SSPI, I would like to say a little more about transport independence. The SSPI builds security blobs that must be sent from client to server and vice-versa. The SSPI will also take your software's data and modify it, creating encrypted or signed security blobs to be sent to and from server and client software. You send a blob returned by an SSPI function, the receiving end passes the blob to its SSPI function, and the function translates the information. The SSPI functions do not actually communicate this data—your software does.

The transport independence of the SSPI awards your software a great deal of flexibility. Because your software's job is to communicate data built by the SSPI, you can use any communication medium you want, including sockets, named pipes, NetBEUI, and IPX/SPX. In fact, one of the designers of the SSPI likes to point out that you could tape the security blobs returned by the SSPI functions to the backs of turtles, so long as a computer can read the blob and pass it back to the SSPI. (Imagine being the author of the first server to impersonate a client, both of which are communicating via a reptile!)

It is difficult to imagine a common client/server environment in which the SSPI won't meet your needs. The most likely scenario is one in which you are forced to adhere to an existing protocol that is not supported by the SSPI. In this case, you might be forced to use the CryptoAPI or some other set of functions to manage cryptography and other details on your own. However, if you have the luxury of designing your client and server from the ground up, or if you are integrating with software that is already using a protocol supported by the SSPI, you should use the SSPI in your code.

Table 12-1 shows the security protocols supported by the SSPI as of the writing of this book, including on which platforms each protocol is available and the special features of each protocol. This information can help you decide which protocol is best for you.

Table 12-1. SSPI protocols

Protocol	Supported Operating Systems	Description
Kerberos	Windows 2000	Windows integrated authentication (that is, token retrieval and client impersonation). Mutual authentication. Delegation. Message encryption and signing. Efficiency and scalability.
NT LAN Manager (NTLM)	Windows 2000, Windows NT, Windows 95/98	Windows integrated authentication (that is, token retrieval and client impersonation). No mutual authentication. No delegation. Message encryption and signing. Reduced efficiency and scalability as compared to Kerberos.
Secure Sockets Layer/Transport Layer Security (SSL/TLS)	Windows 2000, Windows NT	Authentication using certificates and public key infrastructure (PKI). Optional impersonation by mapping certificates to domain accounts. Mutual authentication. Message encryption and signing. Good scalability.
Negotiate	Windows 2000, Windows NT, Windows 95/98	A special protocol that allows the client and server to negotiate the most appropriate protocol to use. The client should never use Negotiate but should select its best supported protocol. The server can use the Negotiate protocol, regardless of the protocol selected by the client.

As you can see from Table 12-1, you have several choices to make when developing a secure server. For enterprise software, you will most likely choose to use Kerberos, NTLM, or Negotiate to communicate between client and server software. For Internet server software, there are some compelling reasons to use SSL, and I will discuss those later.