Rebecca Nielsen Booz Allen Hamilton

1. Observations from the Deployment of a Large Scale PKI Rebecca Nielsen Booz Allen Hamilton

2. DoD PKI Architecture • CA Scalability • Hardware and Software Maintenance • Personnel Agenda Managing the “I” in PKI Technology Challenges Organizational Challenges Conclusions

3. Key Escrow Database Key Recovery Agents Root CA Directory Global Directory Service Subordinate CAs Relying Parties Registration Authorities IssuancePortals Subscribers The DoD PKI Architecture

4. Functions performed by Certification Authorities • Validating credentials of trusted personnel • Publishing certificates • Generating Certificate Revocation Lists (CRL) • Revoking certificates • Responding to requests to search for certificates or groupsof certificates Root CA Subordinate CAs • Take into account all of the required tasks when developing architecture requirements

5. CA Hardware and Software Maintenance • Subordinate CAs are operational for six years, three of which they actively issue certificates and the second three they continue to issue CRLs • Hardware and software product life cycles are significantly shorter • Maintenance costs increase when products are no longer supported by vendors Root CA Subordinate CAs • PKI cycle times are significantly different than hardware and software cycle times

6. Certificate Key Lengths • Over time, requirements for longer key lengths (512-bit, 1024-bit, 2048-bit, etc.) and support for key lengths changes • Three year certificate validity period means three year migration requirement once a change to a new key length has been tested Certificate

7. Certificate Profile Requirements • Microsoft Windows Logon • CRL Distribution Point is Present • Key Usage set to Digital Signature • Extended Key Usage Contains Smart Card Logon Object Identifier • Subject Alternative Name Contains User Principal Name of the Format user@name.com • Federal PKI Path Discovery and Validation Working Group • Authority Information Access Certificate

8. Smart Card Technology • Common Access Cards are valid for three years • Current card uses a 32k chip to store • Java applets • Certificates • Limited user information • Additional requirements have been identified for better security protections, additional certificates, and other user information are driving an upgrade to a 64k card • Card refresh times require three years to fully phase in new capabilities Common Access Card

9. Personnel • Software rollout • Required new roles and new responsibilities • Required new training • Limited success • Common Access Card Rollout • Used existing card issuance personnel • Modified existing processes • Tied certificate issuance to ID card issuance • Certificates issued to over 3 million people Registration Authorities • Integrating PKI rollout with existing processes is a requirement for success

10. Certificate Status Checking • Key Recovery Agenda Managing the “I” in PKI Technology Challenges Organizational Challenges Conclusions

11. Certificate Status Checking – Certificate Revocation Lists • Benefits • Minimum set of data for identifying revoked certificates • Digitally signed by the CA so transmission mechanism is not required to be published • Issues • Limited support for automated CRL downloading • Differences in treatment of validity of CRL after NextUpdate time • Scale of DoD PKI (over 9 million certificates) results in large CRLs (40 megabytes) CRL • Checking certificate revocation status is one of the most difficult technical challenges of PKI

12. Certificate Status Checking – CRL Alternatives • Partitioned CRLs • CA divides certificates into blocks of a preset size based on certificate serial number • CA issues one CRL for each block • Applications that do not use CRL Distribution Points do not support the use of partitioned CRLs well • Delta CRLs • CA issues a full CRL once or periodically, then only issues delta CRLs that contain additional revocations • Delta CRLs are significantly smaller than full CRLs • No single CRL can be considered an authoritative source CRL

13. Certificate Status Checking – Online Certificate Status Protocol • The DoD PKI is deploying an infrastructure to respond to OCSP requests from applications across DoD networks • Benefits • Provides responses for specific certificates instead of all certificates • Offloads revocation checking to dedicated resources • Issues • If OCSP uses CRLs, it does not solve the latency issue • Application relies on signature of OCSP responder instead of CA signature CRL

14. Encryption Private Key Recovery • Issue • Key recovery system was designed to be personnel intensive to support third party key recovery • Use of hardware tokens means that users lose access to their own encryption keys when the card is renewed • Manual system is too time intensive to support recovery of an individual’s own keys • Resolution • Develop an automated process for users to present their new certificates to authorize recovery of their own old keys Key Escrow Database Key Recovery Agents • The person most likely to need key recovery capability is the subscriber

15. The Users • The Managers • The Developers Agenda Managing the “I” in PKI Technology Challenges Organizational Challenges Conclusions

16. Getting User Buy-In • Provide training from the user’s perspective, not how the technology works • Target opportunities for providing additional functionality or shortening process cycle time • Ensure users have all of the tools to be able to use certificates • Train help desk staff to address PKI issues Subscribers • Provide users with new capabilities that help them to get their jobs done, not just PKI certificates

17. Using PKI Requires Enabling Applications • Management of applications is decentralized • Integrating public key technology into applications requires many decisions by many application owners • Resources for public key enabling are the same as resources for system maintenance, hardware and software upgrades, or adding additional functionality • Application owners are resistant to public key enabling if their user population does not yet have certificates Relying Parties

18. Getting Management Buy-In • Ensure that published policy is consistent with overall organizational goals for integrating public key technology • Provide direction for requesting funding as part of the standard budget cycle • Use specific examples when presenting security requirements to application owners • Define business case benefits for PKI in addition to better security – or show business benefits of better security Relying Parties • Application owners need policy, budget guidance, and a business justification for adopting PKI

19. Getting Developer Buy-In • Few individuals understand both PKI and its impact on application architectures • Available training is limited • PKI training tends to cover how to stand up and operate a CA • Web server instructions cover how to install server certificates and turn on client certificate-based authentication • OCSP providers cover how to perform certificate validation • Training for how to integrate certificate information with back end access control systems is not available Relying Parties • Better training is needed to assist developers in public key enabling

20. Agenda Managing the “I” in PKI Technology Challenges Organizational Challenges Conclusions

21. Conclusions • Rollout of PKI across the DoD has been generally successful • Technology challenges have been met with a combination of redundant systems and customized interfaces • Certificate revocation checking is being addressed with the rollout of OCSP responders across the network • Successful PKI implementation has required resolution of existing business process problems • Better training targeted at users, managers, and developers is needed to get the use of PKI integrated into applications