KIERAN JACOBSEN HP Understanding PKI and Certificate Services

KIERAN JACOBSEN HP Understanding PKI and Certificate Services Gold Sponsors Silver Sponsors

AGENDA Why Should I care? Contoso Requirements Design Considerations CA Hierarchy CA Lifespan Physical or Virtual? Private key storage Key lengths Certificate Revocation lists AIA and CDP Locations Stuff we missed… Ouch! Pain Points Power. Shell to the rescue

Why Should I Care? There a number of technologies which need PKI Cloud Infrastructure Federated identity systems. E. G. ADFS HTTPS/SSL SMTPS Multi factor authentication. E. G. Smart cards SMIME Encrypting File System (EFS) Code signing 802. 1 x Authentication and/or NAP Remote Desktop Services Many organizations have legal requirements for PKI with serious financial or legal ramifications for a breach of that infrastructure!

Contoso Requirements Contoso is developing a new web application suite ADFS to provide SSO Almost 1 million end users 3 rd party certificates for HTTPS Private certificate infrastructure for internal use Network is segregated into internal/corporate and perimeter networks. Certificates will be in use both in the corporate and perimeter networks Use of certificates to be extended to other applications, remote access, partners and 3 rd parties at a later date. High availability and continuity planning is a must

Protecting your privates The first rule of security in PKI, is protect the private key! Protecting private key of authorities is absolutely critical If a bad guy has access to your private key or can determine your private key…

CA Hierarchy Single/One Tier Root and Issuing CA on are the same Simple to manage Hard to manage if a breach occurs Not RECOMMENDED!

CA Hierarchy Single/One Tier Two Tier Root and Issuing CA on are the separated Slightly more difficult to manage Security breach of issuing CA easy to manage Highly scalable RECOMMENDED!

CA Hierarchy Single/One Tier Two Tier Three Tier Root, Policy and Issuing CA separated Quite difficult to manage Security breach of issuing CA easy to manage Very highly scalable Not RECOMMENDED!

CA lifespan Certificate Expiry = Date of certificate issue + Validity period defined by: Certificate Template CA Policy Expiry Date of CA’s certificate Certificates cannot be issued by an authority with a expiry which is after the expiry of the authorities own certificate A subordinate authority cannot have its certificate expiry to longer than its superior authority. I. . E. In a two tier hierarchy, issuing CA certificates must have an expiry that is before the Offline Root CA. When an authorities certificate expires: All certificates will have, logically, expired Cannot sign CRL files!

CA lifespan 2 Validity period factors: Deploying an authority is a lot of work Certificates issued must expire before authorities certificate Subordinate authorities must expire before superior authorities Are we going to renew CA certificates or replace? When are we going to start the work? Recommended Validity Periods Offline Authorities: 10 to 25 years Issuing Authorities: 5 to 10 years Replacement Schedule -> Validity Period Replace at 75% Replace at 90% 5 years 3 years, 9 months 4 years, 6 months 10 years 7 years, 6 months 9 years 15 years 11 years, 3 months 13 years, 6 months 20 years 15 years 18 years 25 years 18 years, 9 months 22 years, 6 months

Physical or Virtualized Hardware Physical Hardware Virtualized Hardware dependent Hardware Independent Strong private key protection Weaker private key protection Hard to replicate Easy to replicate Hard to make highly available Highly available by nature Additional key protection options available Only encryption available as an additional layer of protection

Private key storage By default, private keys are stored in Local Certificate Store is vulnerable to: Security vulnerability in software API controlling access Can bypass API with physical access to storage/server Risk mitigation by : Encrypting Operating System disk with Bit Locker Storing physical disk media in a safe Storing Private keys in USB Tokens, Smart cards Ultimate security: Hardware Security Module (HSM)

Key Length Offline authorities (root and policy): 4096 bits Issuing authorities: 2048 bits Certificates: 2048 bits Avoid using keys of 1024 bits and 512 bits.

Certificate Revocation Lists CRL: Certificate Revocation List A list of all the certificates clients should not trust Signed by a the certificate authority which issued the list Each authority will maintain its own list Released on a regular time, generally hourly, daily, weekly, monthly, 6 monthly or yearly. Valid for a limit period of time. The time period is slightly longer than release schedule Delta files can be used

AIA & CDP AIA: Authority Information Access -> used to help validate a certificate is trusted CDP: CRL Distribution Point -> Used to determine a certificates revocation status Protocols allowed: LDAP, HTTP, FTP and UNC Paths Placement of locations Corporate Network DMZ/Permiter External? Cloud? How to we ensure locations are highly available?

AIA & CDP at Contoso LDAP location based off corporate domain, contoso. local Only systems in corporate network will have access HTTP location based of certs. contosocorporation. com Server to be in perimeter network All locations internally have access to this location External access easily made available at a later date

Other things to consider Use Sensible names Define corporate policy: Certificate Policy (CP) Certificate Practice Statement (CPS) Auto Enrollment Online Certificate Status Protocol (OCSP) Key Archival

Deployment summary Hierarchy: 2 Tier – Offline Root and Single Issuing CA Lifespan: Offline: 25 years, to be replaced in 22 ½ years Issuing: 5 years, to be replaced in 4 ½ years Private Key/Hardware: All Virtual Key Lengths: Offline: 4096 bits Issuing: 2048 bits CRL: Offline: Every 6 Months Issuing: Base Weekly, Delta Daily AIA/CDP Locations: LDAP: Contoso. local corporate AD HTTP: certs. contosocorporation. com

OUCH!! Pain points! CA hashing algorithms LDAP for a CRL and AIA distribution point ADFS requires specific CA Template versions AIA specification bug

Power. Shell to the rescue CRL Monitoring and validation Backups Private Key backups CRL Publishing

question and answer time useful links My Website: http: //aperturescience. su Power. Shell CRL Copy by PKI Blog: http: //bit. ly/v 5 Buuf Designing and Implementing a PKI by Directory Services Team: http: //bit. ly/tuf 0 T 6 WIN PRIZES Submit your feedback to WIN. Voyager PRO UC headset. WIN $2650 worth of training from 20% off all books @ MSPress Code ISBRIS Gold Sponsors Silver Sponsors