Implementing a Secure and Effective PKI on Windows Server 2012 R2

© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited

Implementing a Secure and Effective PKIOn Windows Server 2012 R2

© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 2

Quick Introduction

Frank Lesniak


Today’s Agenda

I. Overview of PKI Design Considerations

II. Quick Intro to Cryptographic Algorithms

III. Maximizing Cryptographic Security

IV. Quick Intro to Hashes

V. Quick Intro to Certificate Revocation

VI. Maintaining Compatibility and Interoperability

VII. High Availability Considerations

VIII.Certificate Authority Hierarchies

IX. Minimizing Cost

X. Implement Leading Practices

XI. Design Recommendation Summary

XII. PKI Pitfalls


Overview of PKI Design Considerations

All PKI designs must balance security, high availability, and cost while considering compatibility/interoperability and leading practices.


Quick Intro to Cryptographic Algorithms

Principle: One-way functions for encrypting and decrypting messages (functions are one way if their inverse

function is computationally-infeasible) Non-symmetric:

Public key – known or supplied to everyone that needs itPrivate key – known only to one entity

Purposes: Key Establishment (Exchanging or agreeing upon a symmetric encryption key)• Symmetric keys are preferred for encryption because they can encrypt/decrypt data ~100-1000X faster than

an asymmetric algorithm Nonrepudiation (Without a doubt, Jane is the person that completed this transaction)• Digital signature

Authentication (Jane is who she says she is)• Challenge-response and digital signature

Encryption (Sometimes…)• Remember: symmetric protocols are usually used for encryption

Public key algorithms are non-symmetric and form the basis for certificate-based security.


Uses large public and private keys (integers represented by 2048 or 4096 bits).

Doubling an attacker’s effort requires the addition of 20-30 bits (Paar and Pelzl, 2010).

One-way function guaranteed by the fact that it’s difficult to factor large integers.

Larger key sizes mean larger ciphertexts and digital signatures.

RSA is often slower than ECC, except for signature validation with small RSA keys.

RSA has widespread industry adoption; sometimes hardware is optimized for RSA crypto protocols.

An attack on a 3072-bit RSA private key requires ~2128 steps. For comparison, it would take a ~7680-bit key length to provide protection for attacks of up to 2192 steps; this key length is not supported in most RSA implementations (Paar and Pelzl, 2010).

ECDSA (Digital Signature Algorithm)ECDH (Diffie-Hellman Key Exchange) Uses smaller public and private keys (commonly, integers

represented by 256 or 384 bits). Doubling an attacker’s effort requires the addition of only two bits

(Paar and Pelzl, 2010). One-way function guaranteed by the fact that it’s difficult to compute

the inverse of an elliptical discrete logarithm function with appropriate parameters.

Smaller key sizes result in smaller ciphertexts and digital signatures. ECC often has performance advantages over RSA. ECC has limited industry adoption, but is starting to gain in popularity

(NSA Suite B compliance; embedded applications because compact ECC engines require less computational power than RSA).

If the ECC keys are chosen with care, there are fewer attack vectors currently available for it than RSA. However, this may be due to the fact that ECC is less popular than RSA, and therefore ECC has received less attention.

Attack on a 256-bit ECC key requires ~2128 steps. For comparison, a 384-bit ECC key provides protection for up attacks of up to 2192 steps; ECC key lengths of 384-bits are commercially-viable (Paar and Pelzl, 2010).

Quick Intro to Cryptographic Algorithms

ECC is more commercially-viable at higher encryption levels than RSA.

RSA Elliptic Curve Cryptography (ECC)


Use the largest possible key length Keep CAs in service for the longest amount of time

possible Once a certificate is issued, let it be in service until

the asset retires, or until the asset is stolen/compromised

Use perfect forward secrecy (PFS) algorithms whenever possible (e.g., Diffie-Hellman Ephemeral)

CA lifetime limited by operating system support lifecycle… unless you upgrade the OS – not all of my clients are willing to do that.

Key length is directly related to the length of time that a CA certificate is “in service”

Asset lifetimes usually exceed certificate lifetimes. Certificate renewal processes are important

Not all browsers/applications support PFS

Maximizing Cryptographic Security

A certificate key length is proportional to its lifetime. Established studies relate the two.

When choosing either a key length or the amount of time that a certificate is service, review keylength.com (demo)

Recommendation

Ideal State Real World Experiences


keylength.com


Use the largest possible key length Keep CAs in service for the longest amount of time

possible Once a certificate is issued, let it be in service until

the asset retires, or until the asset is stolen/compromised

Use perfect forward secrecy (PFS) algorithms whenever possible (e.g., Diffie-Hellman Ephemeral)

CA lifetime limited by operating system support… unless you upgrade the OS – not all of my clients are willing to do that.

Key length is directly related to the length that a CA certificate is “in service”

Asset lifetimes usually exceed certificate lifetimes. Certificate renewal processes are important

Not all browsers/applications support PFS

Maximizing Cryptographic Security

A certificate key length is proportional to its lifetime. Established studies relate the two.

When choosing either a key length or the time that a certificate is service, review keylength.com (demo) For RSA CAs, use 4096-bit key length. Put Root CAs in service for 16 years (~2030), and subsequent CAs in

the hierarchy at half the lifetime of the parent CA. RSA Root CA, 4096-bit key length, certificate expires in 2030 RSA Policy Issuing CA, 4096-bit key length, certificate expires and is renewed in 2022 Maximum certificate lifetime ~4 years; RSA certificates of 2048 bit key length OK until at least 2020-2022.

Configure web servers that deal with sensitive information to prefer Diffie-Hellman Ephemeral (DHE) (demo)

Recommendation



ssllabs.com


Quick Intro to Hashes

Hash functions compute a message digest – a brief thumbprint of the binary content of a message

Six Essential Properties (Paar and Pelzl, 2010): Arbitrary message size Hash of a message always has a fixed length Efficiency / performance One-wayness (given only a hash h1, it is computationally-infeasible to find its message m1) Given a message m1 and hash h1, it is computationally-infeasible to find a different message m2 with the

same hash value h1

Armed with a hash function, it is computationally-infeasible to find two different messages m1 and m2 with the same hash value h1

(In order to meet these last two requirements, hash functions should have at least a 160-bit output length)

Uses: Used as part of the public-key cryptography digital signature and message authentication processes Have other cryptographic uses such as the storage of password hashes for password verification

Hash functions are important to cryptography; they must be one-way and collision resistant.


Quick Intro to Hashes

Most popular hashing protocols: MD5 SHA-1 SHA-2 family (primarily, SHA-256 and SHA-384) SHA-3 family (primarily, SHA3-256 and SHA3-384)

MD5 has serious security weaknesses and should not be used, except possibly in situations where collision resistance is less important than one-wayness (e.g., password hashing).

A theoretical attack against SHA-1 has been proposed that would take 261 steps. Although this would be a computationally-intense attack on today’s hardware, SHA-1 is weak compared to the modern public-key algorithms illustrated earlier (e.g., attacks against a 256-bit or 384-bit ECC key requires ~2128 steps or ~2192 steps, respectively)

SHA-2 is similar to SHA-1. However, the attacks proposed against SHA-1 would not work on SHA-2, making SHA-2 a more-effective choice at the moment.

Since attacks have been proposed against MD5, and because of the theoretical attacks proposed against SHA-1 and SHA-2, SHA-3 was created in Oct 2012 out of a desire to have a dissimilar hash function available.

Whenever possible, use the SHA-2 family of hash functions.


Quick Intro to Certificate Revocation

Since certificates are implicitly valid until they expire, admins need a way to revoke a cert.

Even though its certificate was still valid, the admin needs a channel to tell others about the “hack”!

Sometime after the three year certificate is issued (at T0), the web server is compromised

As soon as the administrator finds out that the server is compromised, he/she revokes the certificate (at T1)


Quick Intro to Certificate Revocation

Certificate Authorities publish a Certificate Revocation List (CRL) to communicate certificate revocation to certificate clients

CRLs are published at periodic intervals, sometimes every several days. Delta CRLs, if enabled, publish a list of certificates revoked since the last full CRL was published. Delta CRLs

are also published periodically – usually every few hours. They reduce the amount of time that it takes to communicate a revoked certificate

CRLs offer increased compatibility with legacy certificate clients, but they are not realtime.

T1:CertificateRevocation

Certificate StillConsidered Valid

T2:Delta CRL PublishedCertificate Considered Revoked!

T3:Full CRL Published

OCSP offers a real-time status check


Elliptical Curve Cryptography (ECC) signature algorithm (ECDSA) instead of RSA

Again, largest possible key length SHA-3 (Keccak) cryptographic hash algorithm Online Certificate Status Protocol (OCSP) – use it

exclusively for real-time revocation status If RSA is used, use RSASSA-PSS instead of RSASSA-

PKCS1-v1_5

Few applications support the use of elliptical algorithms Example app that does: IPsec Example app that does not:

System Center Configuration Manager, Lync SHA-3 was recently standardized, and there is

almost no industry support yet Few applications support RSASSA-PSS

Maintain Compatibility and Interoperability

Industry adoption of cryptographic algorithms lags development by several years.

Implement RSA instead of ECDSA/ECDH (RSASSA-PKCS1-v1_5; AlternateSignatureAlgorithm=0) Test applications with ECDSA/ECDH and put pressure on vendors for support Implement a 4096-bit key length on CA certificates; do not use 1024-bit key lengths at all! Implement SHA-256 instead of SHA-3 algorithms; do not use SHA-1! Implement both OCSP and legacy CRLs If you have applications incompatible with RSA 4096 or SHA-256, or if you need to have

elliptical support, build a separate CA hierarchy for these exceptions

Recommendation



Highly-available Online Certificate Status Protocol (OCSP) – providing real-time revocation status checking

Clustered Certificate Authorities, to provide HA to certificate request/issuance

ADCS not seen as an important app; difficult to convince management to invest

CRLs published to Active Directory (LDAP) for inexpensive HA OCSP clients will fall back to CRL

VM platform’s inherent high-availability is “good enough”

High Availability Considerations

Most of the time, CA clustering is unnecessary. Focus HA efforts on certificate revocation.

CA Certificates Only Utilized on Corporate Network Publish CRL to LDAP (AD forest name, not server name) Implement OCSP on Issuing CA

CA Certificates Used by External Parties Implement web server farm with reverse-proxy; both OCSP and CRL

Build in CRL “overlap period” long enough to account for largest expected Issuing CA outage

Recommendation



Use Hardware Security Modules (HSMs) to secure private keys

Minimizing Cost

Build a two-tier PKI hierarchy. VMs are OK to use when you can appropriately secure them.

Ideal State


Example HSM: SafeNet Luna SA 7000

SafeNet’s Luna SA 7000 Hardware Security Module (HSM) Block Diagram


Use Hardware Security Modules (HSMs) to secure private keys

Implement Offline Root and Offline Policy CAs in hardware, in a vault, under lock and key, and with 24x7 security monitoring

Clients do not want to add hardware to their datacenter

Clients do not have resources to keep CAs in a guarded vault

Most clients are not currently using internal PKIs to secure high-value transactions with external parties

Minimizing Cost

Build a two-tier PKI hierarchy. VMs are OK to use when you can appropriately secure them.

Build at two-tier PKI: Offline Root CA; Online, combination Policy/Issuing CA

Secure access to your virtualization, storage, and backup platforms so that only CA administrators can access them – then virtualize your CAs.

If you can’t secure your VM platform, build your root CA as a virtual machine on reliable, compact hardware with mirrored storage. Secure this computer in a safe.

If you can’t secure your VM/storage platform, or need to allow non-CA administrators to access the VMs, consider a HSM to protect the private key.

Do not install ADCS on an Active Directory Domain Controller!

Recommendation



Security Policy, Certificate Policy, and Certification Practice Statement documents all developed and published

Certificate Policies linked to a publically-registered OID

Implement Leading Practices

Obtain a publically-recognized OID from the IANA; use it to establish certificate policies.

Ideal State


IANA Private Enterprise Number

Obtain a publically-recognized OID from the IANA – it’s free!

http://pen.iana.org/pen/PenApplication.page






Assurance levels (amount of identity validation, and level of CA security) aligned with Federal Bridge CA (FBCA)



Ideal State


FBCA Assurance Levels for Human Subscribers (Quoted Text)

Rudimentary• No identification requirement; applicant may apply and receive a certificate by providing his

or her e-mail address

Basic• Identity may be established by in-person proofing before a Registration Authority or Trusted

Agent; or remotely verifying information provided by applicant including ID number and account number through record checks either with the applicable agency or institution or through credit bureaus or similar databases, and confirms that: name, DoB, address and other personal information in records are consistent with the application and sufficient to identify a unique individual.

• Address confirmation:• a) Issue credentials in a manner that confirms the address of record supplied by the

applicant; or• b) Issue credentials in a manner that confirms the ability of the applicant to receive

telephone communications at a number associated with the applicant in records, while recording the applicant’s voice.

Most customers use rudimentary and basic assurance levels – though they are not necessarily fully-compliant with the FBCA.

Most clients are not doing these things

http://www.idmanagement.gov/sites/default/files/documents/FBCA_CP_RFC3647.pdf


FBCA Assurance Levels for Human Subscribers (Quoted Text)

Medium (Commercial Best Practices - CBP)• Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity

certified by a State or Federal Entity as being authorized to confirm identities; information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in-person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act-compliant picture ID1, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired.

• Clarification on the trust relationship between the Trusted Agent and the applicant, which is based on an in-person antecedent identity proofing event, can be found in the “FBCA Supplementary Antecedent, In-Person Definition” document.

• For PIV-I, credentials required are two identity source documents in original form. The identity source documents must come from the list of acceptable documents included in Form I-9, OMB No. 1115-0136, Employment Eligibility Verification. At least one document shall be a valid State or Federal Government-issued picture identification (ID). For PIV-I, the use of an in-person antecedent is not applicable.

High• Identity established by in-person appearance before the Registration Authority or Trusted Agent; information

provided shall be checked to ensure legitimacy• Credentials required are either one Federal Government-issued Picture I.D., or two Non-Federal Government I.D.s,

one of which shall be a photo I.D. (e.g., Drivers License)

Avoid the use of “medium assurance” unless your organization is rigorous about meeting its requirements. High assurance is reserved for government agencies.

Not for amateurs!

US Gov’t Use, Only





Assurance levels (amount of identity validation, and level of CA security) aligned with Federal Bridge CA (FBCA)

Clients do not have security policies, certificate policies, or CPSes written

Clients do not want to wait for the IANA to issue a Private Enterprise Number (PEN)

IANA often exceeds their stated SLA of 30 days, delaying projects



Complete PEN registration with the IANA ~60 days before beginning a PKI implementation. If you do not have policies written, use placeholders:

Use your publically-registered OID (PEN) to state the assurance levels you will support Certificates using auto-enrollment are rudimentary assurance; certificates reviewed by an administrator are basic

assurance. Do not claim FBCA-compliant assurance levels unless you implement proper polices and procedures (i.e.,

implemented and enforceable policies, ID checks, role separation, recording proper information, etc. – see http://www.idmanagement.gov/sites/default/files/documents/FBCA_CP_RFC3647.pdf)

Define your own application policies that indicate the purpose of a certificate.

Recommendation





Issuance/Assurance and Application Policies

Application Policies can also be used for authorization or for certificate selection.

Issuance/AssurancePolicy

Application Policies



Keep offline CAs disconnected from the network during maintenance Exchange data via USB key or virtual floppy disk

Publish a CRL and use OCSP for the Root CA, not just the Issuing CA Can revoke Issuing CA if it is compromised CRL expiration every six months works for most customers. “Emergency CRL” can be published if needed

Make note of CA maintenance intervals, and proactively address them. Every six months: boot up offline root CA and generate a new CRL and OCSP Response Signing cert At halfway through a CA certificate lifetime: renew CA certificate with same key At expiration of CA certificate: renew CA certificate with new key

Test PKI in an isolated test environment – do not test in your production Active Directory! For test environments: standalone domain controller with single-tier CA (ADCS installed on the DC) Be sure to test certificate renewal as well as issuance – not all applications play nice with certificate renewal

Do not load default templates on your Issuing CA (LoadDefaultTemplates=0) Prevents accidental certificate deployment, especially the deployment of Kerberos certificates to Active

Directory Always duplicate the Microsoft default certificate templates and make changes to the duplicated

template. Exception: CA Exchange certificate – Microsoft Enterprise CAs are hardcoded to look for the “CAExchange”

template.

Other PKI recommendations:


Design Recommendations Summary

Offline Root CA:• Not joined to Active Directory• Network disconnected; use virtual floppy disk or USB drive to exchange data• RSA with 4096-bit key; SHA-256• 16-year validity (expiration in ~2030)• CRL and OSCP Response-Signing Certificate published ~every six months

Online Policy & Issuing CA:• Joined to Active Directory forest• Policies defined:• Rudimentary Assurance• FBCA-Compliant Rudimentary Assurance• Basic Assurance• FBCA-Compliant Basic Assurance• FBCA-Compliant Medium Assurance Commercial Best Practices• FBCA-Compliant Medium Hardware Assurance Commercial Best Practices (HSMs, only!)

• RSA with 4096-bit key; SHA-256• 8-year validity (expiration in ~2022)• CRL published ~every 3 days; delta CRL published ~every 8 hours

In most client environments, I recommend the following two tier hierarchy:


PKI Pitfalls

Not making CRL highly available ADCS on a production environment’s Domain Controller Deploying an obsolete key length, cryptographic hash protocol, or inappropriate validity

period Selecting cryptographic algorithms or key lengths that are incompatible with applications Implementing a single tier PKI in production (i.e., Enterprise Root CA) Virtualizing Root CA and not restricting hypervisor access or access to backup files Reactive Root CA maintenance (AKA waiting for things to break) Accidentally deploying Kerberos (secure LDAP) certs Connecting an offline CA to the network to complete maintenance Testing PKI in a production Active Directory environment Not considering full certificate lifecycle / renewal processes No issuance or application policies Not publishing CRL to the Internet when certificates are used externally Not running web servers through the ssllabs.com test and correcting security vulnerabilities

Avoid these mistakes when implementing your certificate authorities:

https://www.ssllabs.com/ssltest/


twitter.com/franklesniaklinkedin.com/in/flesniakflesniak <atsign> westmonroepartners.com

Thanks! Connect with Frank Lesniak:

Implementing a Secure and Effective PKI on Windows Server 2012 R2

Technology

Transcript of Implementing a Secure and Effective PKI on Windows Server 2012 R2