© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited Implementing a Secure and Effective PKI On Windows Server 2012 R2
May 10, 2015
© 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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 3
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 4
Overview of PKI Design Considerations
All PKI designs must balance security, high availability, and cost while considering compatibility/interoperability and leading practices.
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 5
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.
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 6
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)
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 7
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 8
keylength.com
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 9
keylength.com
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 10
keylength.com
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 11
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
Ideal State Real World Experiences
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 12
ssllabs.com
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 13
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.
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 14
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.
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 15
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)
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 16
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 17
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
Ideal State Real World Experiences
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 18
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
Ideal State Real World Experiences
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 19
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 20
Example HSM: SafeNet Luna SA 7000
SafeNet’s Luna SA 7000 Hardware Security Module (HSM) Block Diagram
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 21
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
Ideal State Real World Experiences
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 22
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 23
IANA Private Enterprise Number
Obtain a publically-recognized OID from the IANA – it’s free!
http://pen.iana.org/pen/PenApplication.page
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 24
Security Policy, Certificate Policy, and Certification Practice Statement documents all developed and published
Certificate Policies linked to a publically-registered OID
Assurance levels (amount of identity validation, and level of CA security) aligned with Federal Bridge CA (FBCA)
Implement Leading Practices
Obtain a publically-recognized OID from the IANA; use it to establish certificate policies.
Ideal State
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 25
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 26
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
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 27
Security Policy, Certificate Policy, and Certification Practice Statement documents all developed and published
Certificate Policies linked to a publically-registered OID
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
Implement Leading Practices
Obtain a publically-recognized OID from the IANA; use it to establish certificate policies.
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
Ideal State Real World Experiences
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 28
Issuance/Assurance and Application Policies
Application Policies can also be used for authorization or for certificate selection.
Issuance/AssurancePolicy
Application Policies
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 29
Implement Leading Practices
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:
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 30
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:
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 31
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:
© 2014 West Monroe Partners | Reproduction and distribution without West Monroe Partners prior consent prohibited 32
twitter.com/franklesniaklinkedin.com/in/flesniakflesniak <atsign> westmonroepartners.com
Thanks! Connect with Frank Lesniak: