A recent Windows 2000 Magazine Web site Instant Poll found that 75 percent of respondents running Windows NT 4.0 were running the high-encryption (i.e., 128-bit) version of the OS. If your business falls into that category, you might be running the high-encryption system on faith, unaware of the protection that the 128-bit version provides. To answer the question, "What type of protection does the high-encryption version of NT 4.0 provide?" I spent hours digging through documents, security standards, and publications, and polling my colleagues for answers to the following 10 questions.
1. What's encryption?
To understand how NT implements encryption and how encryption protects a system, you first need to know a few basic cryptographic concepts. Encryption is the process of transforming a message (often called plaintext) into ciphertext, a string that appears random and meaningless. Only someone who knows how to unscramble (i.e., decrypt) the ciphertext can read an encrypted message. RSA Laboratories defines cryptography as the "art and science of using mathematics to secure information." Mathematics is the key to a good cryptographic system. Mathematical algorithms that perform encryption are called ciphers.
Cryptography comprises two types of mathematical functions: hashing algorithms and functions that employ a key to transform data. When you use a hashing algorithm to transform data, reversing the algorithm and converting the hash value back into the original message is mathematically impossible. Hashes obscure the length of the original message. When you encrypt data with a function that employs a key, you can decipher the message only when you have the key or keys that the function employs. For more information about encryption, see "Related Articles in Previous Issues."
2. Where do hash algorithms fit in?
Hash algorithms perform a one-way transform on data, which means that you can't invert or reverse a good hash function to reproduce the original data, as you can when you use key-based ciphers. Cryptographic systems commonly use hash functions that produce a fixed-length output, regardless of the size of the input. Therefore, a hash value can represent any piece of data—from a simple password to a 1000-page document—in as few as 16 bytes. When the OS uses a hash value in this way, the value is called a Message Digest (MD).
When you apply a hash function to a document, the fixed-length output uniquely identifies the original document. When the hashed value of the received document is identical to that of the sent document, the receiver knows that no one has modified the document in transit. If the hash value isn't identical, the document is suspect.
Hash functions also help keep passwords secure. Instead of storing a clear-text password, most OSs store a function of a password's hashed value, also called a password derivative. When a user attempts to authenticate, the OS compares the stored password derivative with similarly transformed logon credentials from the client. When the derivatives match, the OS authenticates the user.
3. What's the difference between secret-key ciphers and public-key ciphers?
Key-based ciphers have two primary variants: secret key and public key. Generally speaking, secret-key ciphers are fast to calculate but are difficult to implement securely, whereas public-key ciphers are slower to compute but are much more secure.
Secret-key ciphers. Secret-key ciphers use one key to encrypt and decrypt data. The oldest and most widely used secret-key algorithm is the Data Encryption Standard (DES), which uses a 56-bit key. After several companies demonstrated the inherent weaknesses of 56-bit DES, the US government introduced an improved version called Triple DES (3DES), an extended algorithm that uses one, two, or even three keys and three calculation steps. RSA Laboratories' RC2 and RC4 secret-key ciphers employ algorithms that are more difficult to break than 56-bit DES.
The disadvantage of the secret-key method is that the sender and the receiver must agree on and exchange the secret key that they will use to secure their communication. Developing a technique by which to securely exchange a secret key is difficult. For this reason, key-management protocols exist to securely exchange keys between two systems that an unsecured network connects.
Public-key ciphers. Public-key ciphers use two keys. The most common implementation uses a public key to encrypt data and a private key that is mathematically related to the public key to decrypt data. The private key is the only number the algorithm can use to decrypt the message. Also, unless security has been compromised, only the intended recipient of the message knows the private key. The primary disadvantage of public-key encryption is that it's computationally intensive. RSA, which is the most common public-key algorithm, comes in two flavors: RSA Key Exchange and RSA Signature.
The fastest and most secure cryptographic implementations combine public-key and secret-key algorithms to achieve the best of both worlds. Computationally intensive public-key cryptosystems securely exchange keys and verify the identity of the sender, whereas the much faster secret-key algorithms encrypt data and authenticate both the sender and the receiver (because they exchange and employ the same secret key). According to RSA Laboratories' FAQ, DES computes roughly 100 times faster in software and computes between 1000 and 10,000 times faster in hardware than RSA's public-key algorithm.
4. Why are key lengths important?
If you're concerned enough about security to encrypt your data, you're also concerned that someone might compromise your encrypted data while it's in transit. People who steal and decrypt data for fun or profit are probably well versed in cryptanalysis, which RSA Laboratories defines as "the art and science of breaking encryption or any form of cryptography." The ease with which an intruder can decipher or break in to an intercepted message depends on the length of the encryption key.
The longer a key is in bits, the more time an intruder must devote to trying number combinations to discover the key that will decrypt a message. A 56-bit key presents a large but definite limit to the number of combinations such an intruder would need to check. A malicious user with access to a large array of computers working in parallel can break a 56-bit key encrypted message in a matter of minutes. When a key is 128 bits long, a brute-force attack is 4.7 sextillion (4.7 x 1021) times more difficult.
Even when someone successfully breaks a key, the key can expose only messages encrypted with that key. To limit the amount of data that a stolen or cracked key can compromise, most cryptographic implementations support configurable key lifetimes. In an extremely secure scenario, a key might be good for only one message exchange; in a less demanding environment, a key might expire 1 hour after the final message exchange.
5.What type of encryption does NT 4.0 support?
NT is available in two encryption strengths: standard and high. Encryption strength refers specifically to the length of the keys that NT employs for its RC2 and RC4 secret-key algorithms. Microsoft released the OS with a standard encryption strength of 40 bits but upgraded the standard strength to 56 bits in Service Pack 6a (SP6a). The standard version of NT installs the base Cryptographic Service Provider (CSP), which uses either 40-bit or 56-bit keys, depending on the service pack level.
High-encryption (i.e., 128-bit) updates have been available as separate downloads since SP3. The high-encryption version installs the enhanced provider, which extends the key length of RC2 and RC4 secret-key ciphers to 128 bits, doubles the key length for RSA public-key ciphers, and includes DES or 3DES. Because key length is the most important factor in determining how easily a malicious user can crack an intercepted message, the high-encryption version of NT delivers much stronger protection.
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.
IE. By default, IE 5.5 uses high encryption. To verify your version number, select About Internet Explorer from IE's Help menu. The high-encryption update file for IE 5.0 and IE 4.0, ie5dom.inf, lists one unique file that doesn't appear in the high-encryption version of NT. To verify that you're running the high-encryption version of IE 5.1 or IE 5.0, look for the sch128c.dll file in the \system32 directory. As Figure 2 shows, the Original Filename description on the Version tab of sch128c.dll's Properties sheet shows that this file replaces schannel.dll.
IE 128-bit updates also create a registry entry in the Add/Remove Programs list so that you can uninstall the 128-bit version. Start a registry editor, and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\128PATCH subkey. If this subkey exists, your system is running the high-encryption version of IE.
Using Syskey to Encrypt SAM Passwords
NT never stores a password in clear text. For security purposes, the OS first hashes the password, then modifies the hash value with another function and stores the result, a password derivative, in the SAM database. NT performs a similar operation before caching logon credentials on the local system. Because password protection depends on hashing rather than encryption, the 128-bit version doesn't provide additional password protection.
However, you can introduce a second level of password protection by activating the Syskey feature. This utility, which ships with every post-SP3 system, strongly encrypts all derivative passwords that NT stores in the SAM database. This feature prevents a user with valid or illegally obtained administrative rights from accessing password derivatives.
When you enable Syskey encryption, the utility prompts you to select one of three options for defining and storing the system key that encrypts password derivatives. First, you can use a machine-generated random key and use a complex obfuscation algorithm to store the key on the local system. This option is the only option that permits an unattended system restart. Second, you can select a machine-generated random key and store the system encryption key on a disk. When you shut down the system, NT won't restart until you insert the disk that contains the stored system key. Third, you can enter a password to generate the system key, and NT won't restart until you enter the password during system startup.
If you want to experiment with system-key encryption, I recommend that you read the Microsoft article "Windows NT System Key Permits Strong Encryption of the SAM" (http://support.microsoft.com/support/kb/articles/q143/4/75.asp). Start on a test system, do a full backup, and update the emergency repair disk (ERD) and the security databases (i.e., with the /s option) before you activate Syskey. If you lose the encryption key, the only way you can return the system to its previous state is to repair it with the ERD, which contains the unencrypted password database. Also, restoring a system to the pre-Syskey version is difficult, if not impossible, so be sure to make your decision carefully.
Security Is Never Absolute
The high-encryption version of NT significantly increases the work that an intruder must perform to decrypt intercepted data on a LAN or remote connection. However, security is never absolute. In 2000, RSA Laboratories issued a public challenge to crack its 140-bit RSA encryption key. Someone cracked the key within a month. RSA Laboratories subsequently issued another challenge to crack its 512-bit RSA key. Someone cracked that key in just over 7 months. In response to the results of these challenges, RSA Laboratories currently advocates a minimum key length of 768 bits.
As CPU power increases, so does the ability to crack keys more quickly. To address ever-increasing raw computing power, new encryption algorithms and longer keys will soon raise the bar on data security.
| Related Articles in Previous Issues |
|
You can obtain the following articles from Windows 2000 Magazine's Web site at http://www.win2000mag.com. LAWRENCE E. HUGHES "How Authentication Is Used in Network Applications," October 1997, InstantDoc ID 99. GARY C. KESSLER "Deciphering Cryptography," December 1999, InstantDoc ID 7587 KEITH PLEAS "Securing Windows NT," October 1996, InstantDoc ID 2740 PAULA SHARICK "What's New in SP6a?" May 2000, InstantDoc ID 8451 TAO ZHOU "5 Security Algorithms," August 1998, InstantDoc ID 8257 |
