Share via

Key management and protection

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Key management and protection

A key is a secret code or number that is required to read, modify, or verify secured data. Keys are used in conjunction with algorithms (a mathematical process) to secure data.

Key management

Windows XP and the Windows Server 2003 family automatically handle key generation and implement the following keying properties:

  • Variable key lengths

    With IPSec, you can select integrity and encryption algorithms that provide a range of key lengths. Every time the length of a key is increased by one bit, the number of possible keys doubles, making it exponentially more difficult to determine the key. Shorter key lengths are processed more quickly than longer key lengths. Longer key lengths provide a higher level of security, but are more resource-intensive to process.

  • Key material generation: The Diffie-Hellman algorithm

    To enable secure communication, two computers must be able to gain the same shared key (session key), without sending the key across a network and compromising the secret.

    The Diffie-Hellman algorithm predates Rivest-Shamir-Adleman (RSA) cryptographic algorithms and offers better performance. It is one of the oldest and most secure algorithms used for key exchange. The two peers publicly exchange keying information, which Windows XP and the Windows Server 2003 family additionally protect with a hash function signature. Neither peer ever exchanges the actual key; however, after their exchange of keying material, each can generate the identical shared key.

    The Diffie-Hellman keying material that is exchanged by the two parties can be based on 768, 1,024, or 2,048 bits of keying material, known as Diffie-Hellman groups 1, 2, and 2048, respectively. The strength of the Diffie-Hellman group is proportional to the strength of the key that is computed from the Diffie-Hellman exchange. Strong Diffie-Hellman groups combined with longer key lengths increase the computational difficulty of determining a secret key.

    IPSec uses the Diffie-Hellman algorithm to provide the keying material for all other encryption keys. Diffie-Hellman does not provide authentication. In the Windows XP and the Windows Server 2003 family implementation of IPSec, identities are authenticated after the Diffie-Hellman exchange takes place, providing protection against man-in-the-middle attacks.

  • Dynamic rekeying

    IPSec policy controls how often a new key is generated during communication, by using a method called dynamic rekeying. The communication is sent in blocks, and each block of data is secured with a different key. This prevents an attacker who has obtained part of a communication, and the corresponding session keys, from obtaining the remainder of the communication. This on-demand security negotiation and automatic key management service is provided using IKE, as defined in RFC 2409, "The Internet Key Exchange (IKE)."

    IPSec policy allows you to control how often a new key is generated. If no values are configured, keys are regenerated automatically at default intervals.

Key protection

The following features enhance the base prime numbers (keying material) and the strength of the keys for the master and session keys.

  • Key lifetimes

    Key lifetimes determine when a new key is generated, rather than how it is generated. A key lifetime allows you to force an automatic key regeneration after a specific interval of either kilobytes (KB) or seconds, whichever occurs first. This ensures that even if an attacker is able to decipher part of a communication protected by one key, new keys protect the remainder of the communication. Whenever a key lifetime is reached, the security association (SA) is also renegotiated and the key is refreshed or regenerated. For this reason, key lifetimes are also referred to as SA lifetimes. You can specify key lifetimes for the master key and for session keys.

    The master key lifetime corresponds to the IKE SA lifetime created by the IKE main mode (phase I) negotiation. It is configured in terms of time and number of quick mode negotiations, and it applies to all security rules in the IPSec policy. The IKE SA and master key typically have a long lifetime (the default value is eight hours). Master keys are much more resource-intensive to generate than session keys, due to the fact that reauthentication and additional Diffie-Hellman exchanges are required.

    The session keys correspond to the IPSec SAs that are used to protect program traffic. The session keys and IPSec SAs are quickly derived from the master key by the IKE quick mode (phase II) negotiation. Thus the session keys are used to protect the data, and they have lifetimes based on the amount of data sent and the amount of time elapsed since the key started being used. Typically, session keys have shorter lifetimes than master keys. The default values are 100,000 KB (approximately 100 megabytes) or one hour. When the session keys are refreshed, new IPSec SAs replace the old ones. The IPSec SA session keys must be refreshed before either the data or time lifetime expires, or traffic is discarded. A session key will be deleted if the IPSec SAs become idle (by default, SAs become idle after five minutes). Because the master key lives longer than the session key, it allows new IPSec SAs and session keys to be established quickly. To prevent data loss, the quick mode SA session key is generated shortly before the main mode SA expires. The IKE SA and corresponding master key are not deleted when session keys and IPSec SAs are deleted, unless the specified number of quick mode SA negotiations has elapsed.

    For example, if a communication takes one hour (3,600 seconds), and if you specify the minimum session key lifetime of five minutes (300 seconds), more than 12 keys are generated to complete the communication. If a 100 megabytes (MB) file is transferred over a fast corporate LAN using an IPSec security association with a 100 MB and one hour lifetime, at least one, if not two, session rekeys occur.

    Notes

    • To provide maximum protection against cryptographic attacks, the amount of data encrypted using Data Encryption Standard (DES) or Triple DES (3DES) by a single session key should not exceed 100 MB. In a high-security environment, consider using session key lifetimes for MD5 or Secure Hash Algorithm (SHA-1) that are shorter then the default values, to provide stronger protection against future cryptographic attacks.

    • In certain scenarios, there might be practical operational limits on key lifetimes. The shorter the key lifetimes, the more CPU cycles are spent refreshing keys. This might limit either the number of active IPSec SAs that a computer can maintain or the throughput performance of IPSec-secured traffic.

    • Computers running Windows 2000 must have the High Encryption Pack or Service Pack 2 (or later) installed in order to use the 3DES algorithm. If a computer running Windows 2000 receives a 3DES setting, but does not have the High Encryption Pack or Service Pack 2 (or later) installed, the 3DES setting in the security method is set to the weaker DES, to provide some level of confidentiality for communication, rather than blocking all communication. However, you should only use DES as a fallback option if not all computers in your environment support the use of 3DES. Computers running Windows XP or a Windows Server 2003 operating system support 3DES and do not require installation of the High Encryption Pack.

  • Session key refresh limit

    Repeated rekeying off of a session key can compromise the Diffie-Hellman shared secret. Because of this, you might want to set a limit to the number of quick mode session keys that can be derived from a main mode negotiation.

    If you have enabled master key perfect forward secrecy (PFS), the session key limit is not used. Setting a session key limit to 1 is identical to enabling master key PFS. If both a master key lifetime and a session limit are specified, whichever limit is reached first causes a new main mode negotiation. By default, IPSec policy does not specify a session limit.

  • Diffie-Hellman groups

    Diffie-Hellman groups are used to determine the length of the base prime numbers (key material) for the Diffie-Hellman exchange. The cryptographic strength of any key derived from a Diffie-Hellman exchange depends, in part, on the strength of the Diffie-Hellman group on which the prime numbers are based.

    Diffie-Hellman Group 2048 (high) is stronger than Group 2 (medium), which is stronger than Group 1 (low). When a stronger group is used, the key that is derived from a Diffie-Hellman exchange is stronger and more difficult for an attacker to break.

    IKE negotiates which specific group to use, ensuring that there are not any negotiation failures that result from a mismatched Diffie-Hellman group between the two peers.

    If session key PFS is enabled, a new Diffie-Hellman key is negotiated during the first quick mode SA negotiation. This new key removes the dependency of the session key on the Diffie-Hellman exchange that is performed for the master key.

    Both the initiator and responder must have session key PFS enabled, or negotiation fails.

    The Diffie-Hellman group is the same for both the main mode and quick mode SA negotiations. When session key PFS is enabled, even though the Diffie-Hellman group is set as part of the main mode SA negotiation, it affects any rekeys during session key establishment.

    Important

    • For enhanced security, do not use Diffie-Hellman Group 1. For maximum security, use Group 2048 whenever possible. Use Group 2 when required for interoperability with Windows 2000 and Windows XP.

      For more information about Diffie-Hellman groups and key exchange, see Key exchange methods.

    Note

    • Diffie-Hellman Group 2048 is provided only with the Windows Server 2003 family.

  • Perfect forward secrecy

    Unlike key lifetimes, PFS determines how a new key is generated, rather than when it is generated. Specifically, PFS ensures that the compromise of a single key permits access only to data that is protected by it, not necessarily to the entire communication. To achieve this, PFS ensures that a key used to protect a transmission cannot be used to generate additional keys. In addition, if the key that was used was derived from specific keying material, that material cannot be used to generate other keys.

    Master key PFS requires a reauthentication and is resource intensive. When it is enabled, IKE must reauthenticate identities, increasing overhead for domain controllers when Kerberos V5 is used for authentication. It requires a new main mode negotiation for every quick mode negotiation that occurs.

    Session key PFS can be used without a reauthentication and is less resource intensive. Session key PFS results in a Diffie-Hellman exchange to generate new keying material. It requires only four messages and no authentication.

    Unlike session key PFS, master key PFS does not have to be enabled on both peers. This is because master key PFS is not part of the SA negotiation. If the responder requires PFS, and the quick mode SA of the initiator expires, the responder rejects the message from the initiator and requires a new main mode negotiation. The initiator expires the main mode SA and renegotiates. PFS can be individually set for both the master and session keys.