CryptoAPI
CryptoAPI is as fundamental a component of the Win2K security architecture as AD is. The goal of CryptoAPI is to provide one-stop shopping for low-level cryptographic services to all applications and other components of the OS using installable cryptographic service providers, as Figure 2 shows. These CSPs provide key generation, signatures, encryption, hashing, and certificate services through a standard interface. CryptoAPI is similar to the intent of ODBC in which an application can access many different databases through the same ODBC interface.
CryptoAPI supports Win2K's high-level design goal of reducing application development costs in three ways. First, developers don't need to implement cryptographic code. Second, developers can develop an application once that can use different cryptographic standards and protocols. Third, as encryption changes, developers don't need to redesign applications.
CryptoAPI has been around since NT 4.0, but in Win2K, the CryptoAPI has important new features for supporting PKI. For example, developers can request and publish certificates and Certificate Revocation Lists (CRLs) and build certification paths when a server application needs to know whether a certificate is valid. Because CryptoAPI uses X.509v3 and PKCS standards, developers can use it to manage certificates in Win2K's native certificate store, in AD, and in other third-party Certificate Authorities (CAs).
Certificate Server
Certificate Server has also been around since NT 4.0 and has provided the basic functionality of a CA for requesting, issuing, publishing, and managing certificates. Certificate Server offered Authenticode authentication and Secure MIME (S/MIME) integration for Exchange Server, but Microsoft geared Certificate Server mostly for public-key-based client authentication to Microsoft Internet Information Server (IIS). Administrators had to manually edit text files to control Certificate Server's configuration. Certificate Server lacked management features important to enterprise usage of PKI, such as tools to customize certificate types and policy settings, and support for only two-level CA hierarchies (inadequate for large-scale PKI deployment).
In Win2K, Certificate Server's name changes slightly to Certificate Services. Certificate Services is more powerful and better integrated into the rest of the OS. The Microsoft Management Console (MMC) snap-ins provide GUI tools for both the client side and the server side. Although Certificate Services can maintain its standalone data store, for full enterprise functionality, Certificate Services uses AD to store and publish certificates. Using AD, you can easily map certificates to users and leverage the management features of GPE to control for whom, by whom, and for what purposes Certificate Services issues certificates. Finally, Certificate Services now supports multilevel hierarchies.
As you can see in Figure 3, Certificate Services becomes much thinner in Win2K, with pieces of its NT 4.0 forbearer moving to other components. Microsoft added Certificate Services' certificate management functions to CryptoAPI. Microsoft moved Certificate Services' default certificate data store to AD. Because Certificate Services accesses its certificate store through the CryptoAPI, Certificate Services can publish certificates in other third-party directories.
Authentication Services
The SSPI provides authentication services through another API. Client/ server applications need to authenticate the client to the server and sometimes the server to the client. SSPI lends abstraction advantages, which are analogous to the CSP interface, to client/ server applications. Figure 4 shows how the SSPI isolates applications from the details of network security protocols, reduces the application-level code needed to support multiple authentication protocols, and supports authentication based on shared-secret or public-key protocols.
Regardless of the protocol, authentication is based on credentials stored in AD. No need exists for users to have an NTLM account and a Kerberos account. AD associations that map elements of a certificate to the proper AD user object accomplish PKI-based authentication. Applications can use the SSPI directly or through authenticated remote procedure call (RPC) and Distributed Component Object Model (DCOM).
Another major authentication issue is the replacement of NTLM, which is NT 4.0's vulnerable authentication protocol, which uses password hashes stored in the SAM. Win2K will still support NTLM for compatibility with NT. When you use Win2K systems in a workgroup, NTLM authentication will continue to use credentials in the NT SAM. Alternatively, connecting from an NT system to a Win2K server in an AD domain doesn't invoke the SAM; Win2K will validate you against NTLM hashes stored in your AD user object. The important news here is that if you upgrade your NT systems and install the new AD client for Windows 9x systems, you can get risky NTLM authentication off your network because Kerberos is the default authentication protocol for Win2K. Kerberos is more secure than NTLM, and Kerberos is an industry standard that will help you get closer to SSO. Finally, Kerberos addresses problems that have plagued NTLM—in particular, the slowness and lack of impersonation functionality for multiTier server applications. For more information about Kerberos, see Jan De Clercq, "Kerberos in Win2K," October 1999.
Encryption
Two areas in which you can protect crucial data only with encryption are on disk and on the network. In NT 4.0, intruders can easily eavesdrop on network data by using sniffers or can copy data from disks by using direct access tools such as Systems Internals' NTFSDOS utility. Win2K's EFS lets you encrypt files at the file-system level by simply selecting a check box. (For more information about EFS, see Zubair Ahmad, "Windows 2000 EFS," http://www.winntmag.com/articles, InstantDoc ID 5006.) EFS handles encryption and decryption with complete transparency to the user and the application program. You can protect any application's data because the OS handles the encryption.
EFS integrates with Win2K's PKI and supports data recovery in case the user's private key is lost or unavailable. EFS will be a nice enhancement for laptop users because these systems are vulnerable to theft. However, EFS is one area in which Microsoft might back off on the planned functionality in the first release. So, look for limited support for encryption algorithms other than Data Encryption Standard X (DESX) and limited or no smart card support for storing EFS private keys.
To protect data across the network, with complete transparency to the user and the application, Win2K uses IPSec, as Figure 5 shows. IPSec provides authentication, confidentiality, data integrity, and filtering for TCP/IP traffic. IPSec's implementation is below the application protocol layer and lets you secure communications for any application without modifying it. IPSec is a solid Internet protocol with plenty of industry backing.
Microsoft integrated IPSec well, making it easy to deploy and manage. The AD stores IPSec policy, and you control IPSec through GPE. In addition to obvious VPN capabilities, you can secure network communication within your enterprise. For example, you can require authentication of traffic within your R&D department, encryption of communication between R&D and other departments, and no connections between R&D and the Internet. Even though these requirements might affect many systems, you can manage everything centrally through AD.
Advanced Security
The Win2K security architecture is a daunting undertaking of technology and integration. Microsoft uses proven design concepts such as industry standards, protocols, modularity, abstraction, and omnipresent support for PKI to uphold the company's Win2K goals to provide security, openness, mission-critical strength, support for e-business, and reduction of application costs.
Microsoft uses AD throughout the OS and will use AD in future releases of BackOffice as the central data store for directory and policy-related information. I think Win2K's design is Microsoft's best example of analyzing business needs and responding to user requirements. Let's hope that Microsoft's implementation of Win2K is the company's best example of quality to date.
Register
