Securing PKI: Planning Certificate Algorithms and Usages

Artikel
08/31/2016

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012

Two key factors in implementing a secure PKI are the choices of cryptographic algorithms used throughout the PKI, and determining what the resulting certificates can be used for. Advances in computing capabilities and cryptographic research continue to show that cryptographic algorithms have a finite lifespan. Selection of proper algorithms will ensure that the data and processes they protect have the best possible chance of remaining secure for their useful life.

Cryptographic Algorithms, Key Lengths, and Validity Period

The proper selection of cryptographic algorithms and key lengths is essential to the effective use of certificates. The security of information protected by certificates depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with keys, and the protection afforded to the keys. CAs are presented with many choices of cryptographic mechanisms. Inappropriate or inconsistent choices may result in less security for the certificate subscribers. This section provides recommendations for selecting algorithms, key lengths, and certificate validity period for CAs. Note that recommendations provided in this document are current for the publishing date of the document, but you may need to revisit them as computing capabilities and cryptographic research advance.

Selecting Algorithms and Key Lengths

When designing certificate hierarchy, use only secure cryptographic algorithms and associated key lengths in PKI CAs. Strictly avoid the use of weak cryptographic algorithms (such as MD5) and key lengths. Due to a great deal of attention in cryptography and PKI in recent years, even if you currently employ widely-used cryptographic algorithms (such as RSA/SHA-1 because hash collisions are computationally feasible for MD5 and SHA-1 algorithms which effectively “breaks” them), consider employing new algorithms such as those based on elliptic curve cryptography (ECC).

NIST Special Publication 800-57 Recommendation for Key Management Part 1 (Revision 3) and ENISA’s Algorithms, Key Sizes and Parameters Report – 2013 Recommendations provide detailed recommendations for algorithms, key lengths, and signature schemes. Both documents contain some key lengths comparison for different algorithms and consider 128-bit security level to be the minimum requirement for new systems being deployed. However, take into account the length of time data needs to be kept secure. This is where CA certificate validity period plays its role. The validity period defines how long CA certificates will be trusted because the key length for CA certificates relates to both the security level that needs to be provided and the required duration of the key’s validity. With a longer validity period, plan for a higher security level of crypto algorithms.

With these considerations in mind, the recommended subordinate CAs key length must be at least 2048 bits for RSA and ECC-based subordinate CA keys must use one of the following curves: P-256, P-384, or P-521. For any CA that has certificate expiration more than 15 years in the future, the CA key length that uses RSA must be 4096 bits or greater or, if the CA key uses ECC, the CA key must use either the P-384 or P-521 curve.

The SHA-2 family of hash algorithms is currently the only recommended family of cryptographic hash algorithms. Microsoft recently announced a new policy for CAs that are members of the Windows Root Certificate Program that deprecates the use of the SHA1 algorithm in SSL and code signing certificates in favor of SHA2. The recommendation to discontinue use of SHA-1 is also published as Security Advisory 2880823. The recommendation is to ensure that cryptographic keys have a limited lifetime to mitigate the risk of future advances in the capabilities of cryptographic attacks.

To ensure the effective use of certificates, use the following secure certificate signature scheme and hash algorithm combinations:

RSASSA-PKCS-v1.5 signature scheme as defined in PKCS #1 RSA Cryptography Standard v2.1 with SHA-2 hash algorithms
RSASSA-PSS signature scheme as defined in PKCS #1 RSA Cryptography Standard v2.1 with SHA-2 hash algorithms (while the RSASSA-PSS signature scheme is considered more secure than the RSASSA-PKCS-v1.5 signature scheme, it is not widely supported)
The ECDSA signature scheme with SHA-2 hash algorithms

Most PKI deployments today use the RSA/SHA-1 algorithms rather than ECC/SHA-2 due to limited support for elliptic curve cryptography (ECC) by replying parties. Fortunately, Microsoft Windows Vista® and, Microsoft Windows Server 2008® and later versions support advanced cryptographic algorithms including Elliptical Curve Cryptography (ECC) and Secure Hash Algorithm (SHA) version 2. It is important to perform adequate testing to ensure compatibility with relying party applications. Note that with any choice of cryptographic algorithms and key lengths you should pay significant attention to application compatibility and integration testing as application capabilities may differ. Refer to Common Questions about SHA2 and Windows for answers to common questions about support of SHA-2 on Microsoft Windows® operating systems.

Certificate Validity Periods

During planning and design of your PKI, give consideration to the validity period for each certificate and key in the PKI. When a certificate is checked for expiration, every CA certificate in the chain must be checked. A CA should not issue certificates that have a validity that extends beyond the validity of its own certificate. A Windows Server® CA will not issue certificates beyond the validity of its CA certificate. If you do not plan validity periods correctly, certificate lifetime can become truncated. For example, a certificate that should have a two year validity only has eighteen months because the Issuing CA certificate is due to expire in eighteen months.

As a general rule, the validity period of CA certificates should be at least twice as long as the maximum validity of the certificates issued by the CA. For example, if a CA issues certificates that are valid for two years, the validity period of the CA certificate should be at least four years. A CA certificate is usually renewed in the middle of its lifetime so that it can keep issuing certificates during the full validity period. The recommendation is to renew the CA certificate once while keeping the same key pair and to renew it again while changing the key pair.

Note that special consideration must be given when a CA issues certificates for multiple applications that have different validity periods. For example, an Issuing CA could issue both two year SSL certificates and one year code signing certificates. Each type of certificate will have a different date past which it will not be able to obtain a certificate for the full validity period.

Several reports, such as ENISA Algorithms, Key Sizes and Parameters Report (2013 recommendations), NIST Special Publication 800-57 Part 1 Rev. 3, or BSI Algorithms for Qualified Electronic Signatures provide guidelines for choosing strengths of cryptographic algorithms based on the algorithm security lifetime. For a comparison of the various proposed models, refer here to define the validity period based on your risk assessment.

Be aware of applications that have long-term PKI use cases. For instance, data stored with its original encryption or documents stored with their original digital signatures may require special processing because all of the keys and certificates originally used will have expired or exceeded their initial period of usefulness, as is the case with code signing. It is important to pay attention to persistence and availability of the certificate revocation information with a goal to enable applications to verify original signature, usually with help of time stamping. If you use such applications, ensure that those applications can use expired certificates, or manage the storage of their data such that the original signatures and encryptions are not used.

End Entity Certificate Expiration

Certificate expiration raises the potential for service outage if a certificate is not replaced before it expires. Starting with Microsoft Windows Server 2012® and Microsoft Windows 8®, certificates in the Computer and User Personal certificate stores (also known as the “My” certificate stores) have lifecycle notifications generated, including expiration and near-expiration events. The notification feature allows a script or an executable to launch in response to notifications gathered from the Certificate Enrollment API and Microsoft Windows PowerShell®. Administrators can utilize these notifications to help with managing certificate expiration. Events are written to the CertificateServicesClient-Lifecycle-System or CertificateServicesClient-Lifecycle-User logs. The table below lists the expiration-specific events and their sources.

Event	ID	Level	Detail	Sources
Close to expiration	1003	Warning	Template Subject names EKUs Thumbprint Store Expiration	Autoenrollment, when Renew expired certificates, update pending certificates, and remove revoked certificates is NOT selected.
Expired	1002	Error	Template Subject names EKUs Thumbprint Store Expiration	Autoenrollment, when Renew expired certificates, update pending certificates, and remove revoked certificates is NOT selected.

Close to expiration

1003

Warning

Template

Subject names

EKUs

Thumbprint

Store

Expiration

Autoenrollment, when Renew expired certificates, update pending certificates, and remove revoked certificates is NOT selected.

Expired

1002

Error

Template

Subject names

EKUs

Thumbprint

Store

Expiration

Autoenrollment, when Renew expired certificates, update pending certificates, and remove revoked certificates is NOT selected.

Mixing Cryptographic Algorithms

A common error when planning to support new cryptographic algorithms is to introduce the new algorithm into the existing certificate hierarchy. For example, you may consider establishing a CA that issues ECC based certificates in an existing CA hierarchy that uses RSA. This will not alleviate all security concerns because the CAs in the certification chain are still vulnerable to potential RSA weaknesses. The same applies to the choice of hash algorithms for issued certificates. The recommendations for cryptographic algorithms are:

All keys certified within CA hierarchy use the same asymmetric cryptographic algorithm family. For example, a CA that uses an RSA key should not certify a subordinate CA that uses an ECC key.
The key length of a CA key is the same or longer than the key lengths of the keys certified by the CA
The strength of the hash algorithm used by a CA to sign certificates is comparable to the strength of the CA key. For example, a CA that has a P384 ECC key should use SHA-384 to sign certificates.
The strength of the hash algorithm used by a CA to sign certificates is at least as strong as the hash algorithm used by its subordinate CAs. For example, if a CA uses SHA-256 to sign a subordinate CA certificate, then that subordinate CA must not use SHA-384 to sign certificates it issues.

NIST Special Publication 800-57 “Recommendation for Key Management Part 1 (Revision 3)” provides suggested crypto periods for key types and comparable strengths of crypto algorithms:

Bits of security	Symmetric Key Algorithms	FFC (e.g., DSA, D-H)	IFC (e.g., RSA)	ECC (e.g., ECDSA)
112	3TDEA	L = 2048 N = 224	k = 2048	f = 224-255
128	AES-128	L = 3072 N = 256	k = 3072	f = 256-383
192	AES-192	L = 7680 N = 384	k = 7680	f = 384-511
256	AES-256	L = 15360 N = 512	k = 15360	f = 512+

While planning a PKI deployment, ensure that the CA hierarchy uses consistent asymmetric cryptographic algorithms and key lengths when issuing certificates. When you decide to move to stronger algorithms, consider building a parallel infrastructure built entirely with new algorithms to which you can migrate.

CA Key Usages and Certificate Extensions

Most certificates in use today, including those issued by a CA running Microsoft AD CS, conform to the X.509 v3 standard. This standard provides extensible methods to include additional information using certificate extensions. The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. For example, a certificate can be marked as valid for usages such as “Client Authentication” or “Smartcard Logon”, or can list a specific policy that applies to the certificate. Applications that accept certificates can then be configured to only accept a certificate if the extensions match what it is expecting.

Key Usage

The intended scope of usage for a private key is specified through certificate extensions, including the Key Usage and Extended Key Usage (EKU) extensions in the associated certificate. The cryptographic use of a specific key is constrained by the Key Usage extension in X.509 certificates. All certificates should include key usage as a critical extension. Note that you usually should not change key usage in the end-entity certificates, and AD CS CA will take care of setting the right bits in the keyUsage extension.

The following table summarizes key usages for user certificates:

Signature public keys	digitalSignature bit (0)
RSA public keys to use for key transport	keyEncipherment bit (2)
ECC public keys to use for key agreement	keyAgreement bit (4)

Public keys in CA certificates must be used only for signing issued certificates and status information (for example, CRLs). The following table summarizes key usages for CA certificates:

Public key to use to verify other certificates	keyCertSign bit (5)
Subject public key to use to verify CRLs	cRLSign bit (6)
Subject public key to be used to verify Online Certificate Status Protocol (OCSP) responses	digitalSignature bit (0)

Public keys that are bound into device, applications, and service certificates may be used for digital signature (including authentication), key management, or both. The following table summarizes key usages for device certificates:

Public keys to use for digital signatures	digitalSignature bit (0)
RSA public keys to use for key transport	keyEncipherment bit (2)
ECC public keys to use for key agreement	keyAgreement bit (4)
RSA keys to use both for digital signatures and key management	digitalSignature and keyEncipherment bits
ECC keys to use both for digital signatures and key management	digitalSignature and keyAgreement bits

Extended Key Usages

The other important certificate extension that controls what a certificate is trusted for is the Extended Key Usage (EKU) extension. The Key Usage Extension has an indirect dependency with the EKU extension, so these two extensions need to align. These extensions are usually populated according to RFC 5280 and corresponding certificate usage recommendations - for example, in the Transport Layer Security protocol or for smart card logon.

EKU defines what a certificate will be used for and may contain multiple purposes. Defining the types of certificates supported by the PKI by determining EKUs is a critical part of the solution design process. A common misconfiguration is to Securing Certificate Templates that offer a wide variety of EKUs. You should determine the required capabilities of a certificate before it is issued, and carefully plan their EKUs.

Every PKI-enabled solution should have the type of certificate that matches its trust level and key usage requirements. This could be accomplished by using its own type of certificate that has its own attributes, enrollment process, and target audience. However, it is likely that some solutions can share a certificate for different purposes if the solutions happen to have the same characteristics. For example, a certificate stored on a smart card may be used for workstation logon, VPN access, or for authentication to restricted web sites.

It is important to evaluate whether to use single-purpose or multipurpose certificates. The following table summarizes the benefits of both approaches.

Benefits of Single-Purpose Certificates	Benefits of Multipurpose Certificates
Granular control of certificate usage. Certificates can be individually revoked without affecting other use cases. Certificate usage is limited, so risky scenarios (for example, code signing) are not enabled unintentionally.	Greater usability. Users find multipurpose certificates easy to handle because fewer of them exist.
Limited key usage. Different keys are used for different PKI-enabled services.	A smaller accumulated size. Multipurpose certificates are advantageous when hardware tokens have limited storage capabilities.
Multiple sources. Certificates can be issued through different CAs when different certificate policies, application policies, or issuing policies apply.	Less network overhead. Less demand is placed on the infrastructure because a lower number of certificates are in use.
Archival and Recovery. Certificates that are good for signing and encryption should not be archived. Single purpose certificates allow encryption keys to be archived while allowing signature keys to only exist where they were created.	Less administrative overhead. The smaller number of enrolled certificates reduces the overall management burden placed on the certificate managers.

The EKUs of each certificate type are typically defined as part of certificate profiles (expressed in the CPS). For AD CS enterprise installations, the properties of each certificate type are configured in certificate templates stored in Active Directory®. Microsoft Windows® operating systems come with built-in templates designed for the most common applications. You can use them as is or as the basis for custom certificate templates. Refer to Certificate Template Versions and Options for additional information.

Object Identifiers

EKUs are identified in a certificate by object identifiers (OIDs). An OID is a sequence of integers that uniquely identifies an object, and OIDs are used in the X.509 v3 standard to represent policies, extensions, and attributes in digital certificates. Preferably, the OIDs should be globally unique, especially if the PKI will be used externally.

Quite often customers do not consider OIDs before the PKI deployment starts, but it is not complex to obtain one. If you need to define your own EKU and your PKI will be used across multiple organizations, the EKU needs to have a unique OID assigned either by the Internet Assigned Numbers Authority (IANA) or by a national standards organization. However, if you do not foresee using the OIDs in conjunction with other organizations, the option exists of using private OIDs within the Microsoft IANA-assigned tree. These OIDs are based on the globally unique identifiers (GUIDs) of Active Directory® forests. Such an OID can be obtained by running Microsoft Management Console (MMC) and using the Certificate Template snap-in. In the snap-in, right-click Certificate Templates, and then select View Object Identifiers. The OIDs are in the 1.3.6.1.4.1.311.21.8.a.b.c.d.1 format, where a.b.c.d is a unique string of numbers based on the AD forest’s GUID.

Critical Extensions

Marking an extension as critical is a powerful concept because it enforces common understanding of important certificate fields during certificate chain validation. If a PKI-enabled application does not understand the extension marked as critical, it should not process the certificate. This may affect third party applications or browsers that will use issued certificates. Refer to How Certificates Work and How CA Certificates Work for additional information. Unless you have a full understanding of how your certificates will be used by relying parties, consider limiting the use of the critical flag in End Entity certificates.

CA Certificate Constraints

The goal of stating constraints in a CA certificate is to restrict the scope of the CA and limit the impact of a CA’s security breach on other CAs in the certificate hierarchy. RFC 5280 defines multiple way to express constraints: basic constraints, name constraints, policy constraints, and EKU. The use of these constraints for qualified subordination is explained in Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003.

Unfortunately, support for most of these constraints varies from platform to platform, and it differs between applications (depending on the chain building library used) and kernel-mode/user-mode. These limitations leave only a limited number of practical options to restrict subordinate CA certificates: basic constraints and EKU. By enforcing these CA certificate extensions for all the issuing CAs, you can protect the PKI from an attacker that may use a single compromise of an Issuing CA signing key to issue another subordinate CA certificate in the CA hierarchy and effectively work around controls established in the PKI.

Basic Constraints

The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate. The path length constraint within a basic constraint for CA certificates specifies how many levels of CAs can be subordinated to a CA. This constraint is used to ensure that issuing CAs will not enroll additional subordinated CAs and that non-CA certificates will not be used to sign other certificates. The path length constraint is specified during CA installation and cannot be changed without reissuing the CA certificate.

The Root CA usually has no defined path length constraint (pathLenConstraint=none) that allows you to extend the CA hierarchy in the future. However, if you have a clear understanding that your issuing CAs will issue certificates only to End Entities, then you should limit issuing CAs by specifying the path length constraint and set this constraint to zero. This prevents the Issuing CA from issuing any CA certificates and will be enforced by PKI clients during certificate chain validation. Without this constraint an attacker may use a single compromise of an Issuing CA signing key to issue another subordinate CA certificate in the CA hierarchy and effectively work around controls established in the PKI.

It is not recommended to use [BasicConstraintsExtension] section in the CAPolicy.inf file to specify the path length constraint for a subordinate CA in AD CS. To add this constraint to a subordinate CA certificate if the parent CA has no PathLength constraint in its own certificate, set the CAPathLength registry value on the parent CA. For example, to issue a subordinate CA certificate with a PathLength constraint of 0, use the following command to configure the parent CA.

certutil –setreg Policy\CAPathLength 1

Setting this value causes the CA to behave as though its own certificate had a PathLength constraint of whatever number you specify. Any subordinate CA certificate issued by the parent CA will have a PathLength constraint set appropriately in its Basic Constraints extension. You must restart AD CS CA for this change to take effect. Note that there is no easy way to undo this change and you may need to reissue subordinate CA certificates. Nevertheless, with clear understanding of your CA hierarchy basic constraints together with extended key usage constraints is the powerful mechanism to limit your issuing CAs.

Extended Key Usage Constraints

As mentioned in the Extended Key Usages section, an EKU extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the Key Usage Extension. In general, this extension will appear only in End Entity certificates, but if a CA includes EKUs to state allowed certificate usages, then it EKUs will be used to restrict usages of certificates issued by this CA. For example, if only the EKU for “Server Authentication” is included in the CA certificate, a certificate issued by that CA would not be valid for “Client Authentication.” In this case, EKU extension must not be marked as critical and anyExtendedKeyUsage must not be included in the extension.

Note that you may hit the limitations of software in validation of issued certificates, so in all cases you must test your target scenarios to verify the design decisions.

Constraining CA Certificates

If you intend to restrict subordinate CA certificates, consider the following recommendations:

For subordinate CA certificates, the Basic Constraints extension should be present and marked as critical
The cA field should be set to TRUE
The pathLenConstraint field should be set to the minimum value required to enable the business scenario (i.e. 0 if that CA will issue certificates only to End Entities)
The EKU extension should be present and contain the minimum set of EKU object identifiers (OIDs) to enable the business scenario. Furthermore, the anyExtendedKeyUsage OID (2.5.29.37.0) should not be specified.

Conclusion

Using strong cryptography throughout your PKI helps mitigate threats introduced when a cryptographic algorithm becomes weak and susceptible to failure, which can lead to a full loss of trust in your PKI. Utilizing constraints on End Entity certificates and CA certificates helps to mitigate the risk of having a certificate used for unintended use cases, which may allow access to resources or data that should not be allowed. Constraints also help mitigate the threat of an attacker creating their own subordinate CA in your PKI hierarchy after a compromise, allowing them to create certificates of their choosing.

For a complete list of the recommendations for planning certificate algorithms and usages, along with the level of Determining the Level of Protection Required at which you should consider implementing them, refer to Securing PKI: Appendix F: List of Recommendations by Impact Level.

Delen via