6. Why is the CryptoAPI important?
The CryptoAPI gives the OS—and developers who want to create secure applications—access to a broad collection of cryptographic functions that are generically called CSPs. This module contains links to housekeeping functions, key-generation functions, certificate encode and decode functions, certificate store functions, message encryption and decryption services, message signatures, and low-level support calculations. To prevent tampering, the CryptoAPI doesn't let programs interact directly with the CSPs that perform encryption, decryption, and hash functions.
Microsoft supports two versions of the CryptoAPI: the base provider, rsabase.dll, and the enhanced provider, rsaenh.dll. The standard version of NT installs rsabase.dll, and the high-encryption version installs rsaenh.dll. Table 1 shows the differences between the key lengths of the base-provider and enhanced-provider DLLs. The enhanced-provider DLL doubles the key lengths for public-key and secret-key algorithms and adds DES or 3DES encryption. The base-provider RC2 and RC4 key lengths are 56 bits in SP6a and later and 40 bits in earlier versions.
Both the base and enhanced CSPs have companion signature files. The base-provider rsabase.dll signature file is rsasig.dll, and the enhanced-provider rsaenh.dll signature file is enhsig.dll. The CryptoAPI periodically validates the signature on the companion file to ensure that no one has surreptitiously modified the cryptographic provider components.
7. What type of protection does the high-encryption version provide?
Understanding that the high-encryption (i.e., 128-bit) version of NT uses the same hashing algorithms as the standard version is important: The high-encryption update doesn't improve the security of data that the OS protects with hash functions. However, the high-encryption version delivers greatly improved security for all OS functions that use encryption to protect data. The 128-bit version includes the enhanced CSP, which employs 1024-bit keys for RSA algorithms, 128-bit keys for RC2 and RC4 secret-key algorithms, and access to DES and 3DES algorithms. If you compare the key lengths for the two providers in Table 1, you see that the high-encryption version uses keys that are at least twice as long as the standard version's keys. Because cracking a long key is difficult, the high-encryption version seriously extends the security of your network.
High encryption provides the most secure communication between domain controllers (DCs), servers, and workstations and the most secure connections between Microsoft Outlook and Microsoft Exchange Server. The high-encryption version also provides the best protection for remote users who use encryption to access a LAN through dial-up or VPN connections.
Secure Netlogon channels. The high-encryption version enhances security for a variety of operations, including crucial communication between DCs, servers, and workstations. One major benefit is that a 128-bit key, rather than a 40-bit or 56-bit key, encrypts all secure Netlogon channels. DCs use a secure Netlogon channel to create trust relationships with one another, so they can securely replicate SAM and LSA data and coordinate account password changes. DCs also use secure Netlogon channels to implement cross-domain trusts and pass-through authentication. NT workstations and servers create secure Netlogon channels to a DC for computer account authentication and password synchronization. An intruder who captures packets must crack a 128-bit key to successfully decrypt any of these messages.
RAS and RRAS connections. You can configure a RAS or RRAS server and RAS clients to require encryption. When you configure a remote connection and select the Require encryption option, both server and client will refuse connections that aren't encrypted. When the server and client do establish a connection, whether it's a dial-up Point-to-Point Protocol (PPP) or PPTP VPN connection, both endpoints use a 128-bit key to encrypt the data they transmit. PPTP connections also encapsulate encrypted data inside a second network packet that provides an additional level of security.
RPC and SSL connections. The high-encryption version uses longer keys to secure remote procedure call (RPC) and encrypted Secure Sockets Layer (SSL) connections. Any application that requests secure RPC automatically uses 128-bit secret-key encryption. An example of a secure RPC connection is the connection that Outlook creates with an Exchange Server system. Also, any application that wants to use a secure socket can request an encrypted SSL connection. The most familiar SSL connection is one that the server and client create when you connect to a secure Web site (i.e., https://).
8. How do I upgrade NT to high encryption?
Initially, Microsoft released NT with a standard encryption strength of 40 bits. In SP3, Microsoft offered the first 128-bit high-encryption version, then in SP6a upgraded the standard encryption strength to 56 bits. You should install the high-encryption version on DCs, servers, and workstations when you want
- the most secure communication between DCs, servers, and workstations
- the best data encryption for remote users who access the LAN through dial-up or VPN connections
- the most secure connections between Outlook and Exchange Server
- the most secure connections to a protected Web site
To upgrade a system to 128-bit encryption, simply install the current service pack's high-encryption version. The high-encryption updates for NT SP6a, SP5, and SP4 are available for download from http://www.microsoft.com/technet/security/crypload.asp. Figure 1 shows that this page also has links to high-encryption updates for Win2K, Microsoft Internet Explorer (IE), Outlook 2000, Win2K Terminal Services Advanced Client (TSAC), and service-pack-specific versions of NT Server 4.0, Terminal Server Edition (WTS).
9. How do I upgrade IE to high encryption?
Installing the high-encryption version of IE when you upgrade the OS is a good idea. IE 5.5 (the most recent version) natively supports 128-bit encryption, but earlier versions don't. Because of a change in US export laws, Microsoft no longer distributes high-encryption versions of IE on CD-ROM.
You can download high-encryption updates for earlier versions of IE from Microsoft's controlled Web site at http://www.microsoft.com/windows/ie/download/128bit/intro.htm. To ensure compliance with new government regulations, the Web site verifies that you're downloading from a US location (including territories, possessions, and dependencies) and requires you to complete an online export notice form before you download any files.
IE 5.1, IE 5.0, and IE 4.x updates are specific to NT service packs, so be sure you download the file for the service pack level you need to update. You download one file for SP5 or SP4 and another file for SP6a or SP6. Both versions contain the same seven files, but some of the DLLs are a different size, ostensibly to accommodate service pack implementation differences. The IE high-encryption download contains the files rsaenh.dll, sch128c.dll, enhsig.dll, ie5dom.inf, advpack.dll, w95inf32.dll, and w95inf16.dll. If you want to upgrade to the high-encryption version of IE 5.01 or IE 5.0, you need to download only one file for all versions of NT 4.0 and Windows 9x.
10. How do I check the encryption level?
Suppose you're starting a job at a new security-conscious site. You need to be able to verify the installed systems' encryption level. Documentation describing the files that the 128-bit version installs or modifies can be difficult to find. After a thorough search, I finally downloaded the high-encryption updates for SP6a and SP5, expanded the files, and examined the update.inf files that guide the high-encryption update process.
NT. According to the 128-bit SP6a update.inf file, the installation replaces four existing files in the \system32 directory—schannel.dll, security.dll, ntlmssps.dll, and ndiswan.sys—with high-encryption files of the same name. The high-encryption version numbers for these files are as follows:
- schannel.dll—4.87.1959.1877
- security.dll—4.0.1381.336
- ntlmssps.dll—4.0.1381.336
- ndiswan.sys—4.0.1381.279
If these four files exist in the system root with these version numbers, the system you're checking is running high encryption. The 128-bit version also installs rsaenh.dll with the version number 5.0.1877.8 and the companion signature file enhsig.dll with the version number 5.0.1877.7. However, because the IE high-encryption update installs the same files, the presence of these files doesn't necessarily imply that the OS is the 128-bit version. Several Microsoft Knowledge Base articles incorrectly state that you can verify the 128-bit version of the OS simply by checking for the presence of rsaenh.dll and enhsig.dll.
Prev. page
1
[2]
3
next page 
