Public Key Infrastructure 101

1. Public Key Infrastructure 101 Mark L. Silverman, CISSP DHHS PKI Program Manager December 7, 2005

2. A Riddle You are standing in a room. On the wall are three toggle light switches, clearly marked on/off and currently all in the off position. One of the switches controls a normal 100 watt table lamp, located in the room next door. It does not matter what the other two switches control. From your room, there is no way that you can see the light from the lamp (no mirrors, extension cords, etc.). By entering the room with the lamp only once, how can you determine which switch controls the lamp?

3. Today’s Objectives • Why PKI • Legislative Requirements • E-Authentication • HSPD-12 • PKI Tutorial • Cryptographic Overview • SMIME and Digital Signatures • PKI Components and Operations • HHS PKI Overview • Certificate Issuance System • Certificate Validation Service • Obtaining HHS Digital Certificates

4. Today’s Objectives (continued) • Microsoft Outlook • Configuring • Sending signed/encrypted email • Receiving signed/encrypted email • Signing with Adobe 7.0 • Signing a MS Word Document • Managing Certificates • Backup (Export) • Copy/Restore (Import) • Web based authentication and signatures (LRA)

5. Why PKI? PKI

6. Extended Trust PKI is the only technology that extends trust beyond the enterprise with no a priori relationship between the trusted parties.

7. President’s Management Agenda Agencies will undertake a Federal Public Key Infrastructure (PKI) to promote digital signatures for transactions within the federal government, between government and businesses and between government and citizens.

8. Federal PKI Drivers • Government Paperwork Elimination Act (GPEA) 1998 Requires Agencies to accept transactions, and maintain records electronically, when practicable • Electronic Signatures in Global and National Commerce Act (E-Sign) 2000 An electronic signatures can not be denied legal status. • E-Government Act of 2002 Achieve interoperable implementation of electronic signatures for appropriately secure electronic transactions with Government. OMB to oversee implementation of electronic Government. • Memorandum Streamlining Authentication and Identity Management (OMB 7/03/03) Agencies will acquire PKI services from shared service providers (see also OMB M 05-05) • E-Authentication Guidance for Federal Agencies (OMB M-04-04 - 12/16/03) Ensure that authentication processes provide the appropriate level of assurance. SP 800-63 - Electronic Authentication Guideline • Policy for a Common Identification Standard for Federal Employees and Contractors (HSPD-12 – 8/27/04) Smartcard ID badge for logical access to Agency IT systems. FIPS 201 - Personal Identity Verification (PIV) of Federal Employees and Contractors

9. E-Authentication OMB M-04-04 PKI level 3 & 4 User ID Password level 2 Business Processes Authentication Mechanism Anonymous Access level 1 Web Pages Time Card Patient Data E-Authentication Risk Assessment: http://www.cio.gov/eauthentication/documents/eraguide.pdf

10. Homeland Security Presidential Directive 12Policy for a Common Id Standard for Federal Employees and Contractors • Mandates new Federal ID Badge that is: • Based on sound criteria to verify an individual employee’s identity • Resistant to fraud, tampering, counterfeiting, and terrorist exploitation • Rapidly verified electronically • Issued only by providers whose reliability has been established by an official accreditation process • Agencies shall, to the maximum extent practicable, require the use of identification by Federal employees and contractors that meets the Standard in gaining physical access to Federally controlled facilities and logical access to Federally controlled information systems. • FIPS 201 -Personal Identity Verification of Federal Employees and Contractors • PIV-1: Identity proofing process October 2005 • PIV-2: Smartcard ID Badge October 2006

11. FIPS 201 PIV Process Registration Authority checks applicant’s identity documents; obtains applicant’s photograph, fingerprints and other background check data. Background check must be completed before badge issuance. Register Issuing Authority verifies applicant against registration data. Then creates and issues badge. Issue Badge loaded with applicant’s biometrics (fingerprints and photograph), PIN and PKI certificate information. PIV-2 Oct 06 Badge accepted / electronically validated by all Agencies. PIN / biometrics used for stronger physical authentication. PKI certificates used for logical authentication to IT systems. Use Local sponsor fills out applicant’s badge request form, which is then approved by an Authorizing Official and forwarded to the Registration Authority. Authorize PIV-1 Oct 05 Each step must be performed independently by different people. Entire process and support systems must be accredited.

12. Tutorial

13. Foundations of PKI Public Key Infrastructure Trust Technology

14. Cryptography • Science of secret (hidden) writing • kryptos – hidden • graphen –to write • Encrypt / encipher • Convert plaintext into ciphertext • Decrypt / decipher • Convert ciphertext into plaintext

15. Early Examples of Cryptography • Julius Caesar (49 BC) substitution cipher Plaintext:ET TU BRUTE Shift Algorithm 3 characters Ciphertext:HW WX EUXWH • Spartan Scytale – fifth century BC

16. Symmetric Key Cryptography Same key used to encrypt and decrypt ciphertext Dear Bob: I am leaving you. Goodbye forever. Alice 011100111001001 110011100111001 001110000111111 encrypt decrypt • Computationally fast • Data Encryption Standard (DES) • Block Cipher, 56 bit key • Triple DES 112 bit key • Advanced Encryption Standard (AES) • Rijndael Algorithm • Belgian cryptographers, Joan Daemen and Vincent Rijmen. • 128, 192, 256 bit keys Alice Bob Dear Bob: I am leaving you. Goodbye forever. Alice

17. Symmetric Encryption Issues • Key (shared secret) vulnerable to discovery • Need to share a unique secret key with each party that you wish to securely communicate • N * (N – 1) Problem • Key management becomes unmanageable

18. Asymmetric Key Cryptography Carol Bob Dear Carol: Alice is gone. Now we can be together Love, Bob encrypt decrypt 011100111001001 110011100111001 001110000111111 Dear Carol: Alice is gone. Now we can be together Love, Bob Carol’s Private Key Carol’s Public Key decrypt encrypt 011100111001001 110011100111001 001110000111111 • Two mathematically related keys • Unable to derive one from the other • Based upon hard problem • RSA - Integer Factorization (large primes) • Diffie-Hellman - Discrete Logarithms • ECES - Elliptic Curve Discrete Logarithm • Public Key Cryptography • One public key published for all to see • Other is private key kept secret by owner Works both ways Can encrypt with either key – decrypt with the other Bob: Leave me alone! Carol Bob: Leave me alone! Carol

19. Asymmetric Advantages • No shared secret key • Public key is public • Can be freely distributed or published • Key management is much easier • Private key known ONLY to owner • Less vulnerable, easier to keep secret • Supports Non-repudiation • Encrypt with sender’s private key (only known by sender) • Sender can not deny sending message • Basis for digital signatures

20. Electronic Signatures Electronic Signature != Digital Signature Electronic Signatures in Global and National Commerce Act (E-Sign) defines: The term ‘‘electronic signature’’ means an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record.

21. Digital Signatures Sue’s Private Key Sue Dear Mr. Bob: We have asked the Court to issue a restraining order against you to stay away from Carol. Sincerely, Sue Yew Dewey, Cheatam & Howe, Law Firm Hash Function Hash Value encrypt 0F47CEFF AE0317DB AA567C29 0101011110000110101 1011110101111010111 Digital Signature A digital signature is a a type of electronic signature. It is a hashof a document encrypted with the author’s private key Dear Mr. Bob: We have asked the Court to issue a restraining order against you to stay away from Carol. Sincerely, Sue Yew Dewey, Cheatam & Howe, Law Firm

22. Validating a Digital Signature 1. Re-compute the hash value 3. Decrypt the original hash Dear Mr. Bob: We have asked the Court to issue a restraining order against you to stay away from Carol. Sincerely, Sue Yew Dewey, Cheatam & Howe, Law Firm 0F47CEFF AE0317DB AA567C29 0F47CEFF AE0317DB AA567C29 decrypt 0101011110000110101 1011110101111010111 Sue’s Public Key 2. Obtain the author’s public key 4. Compare hash values – if match signature is valid Hash proves document unchanged integrity Public key proves authorship non-repudiation

23. Asymmetric Issues • More computationally intensive • 100x symmetric encryption • Generally not used to encrypt data • Encrypt symmetric key (S/MIME) • SSL session key

24. SMIME Encryption Carol's Public Key Dear Carol: I am still hoping when I get out of prison we can be together. Love, Bob Carol Carol's Private Key A032F17634 E57BC43356 743212b9c9 8FA2917342 5633A22201 807732ECF1 3344567520 ABCE4567CD encrypt decrypt decrypt 0111001110 1100111001 0011100001 encrypt Encrypted email uses the recipient's public key Bob Dear Carol: I am still hoping when I get out of prison we can be together. Love, Bob

25. Source of Public Key • Keys can be published anywhere • Attached as a signature to e-mail • Pretty Good Privacy (PGP) -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQCVAwUBOx6SgoFNSxzKNZKFAQGK+gP6AnCVghZqbL3+rM5JMSqoC5OEYIkbvYZN 92CL+YSCj/EkdZnjxFmU9+wGsWiCwxvs/TzSX6SZxlpG1bHFKf0OPu7+JEfJ7J5z cPCSqbFXiXzmukMl5KNx0p0veIDW4DmwleDpkmhT05qnCheweoNyvTSzfA1TGeLl mpjBi6zUjiY= =Xq10 -----END PGP SIGNATURE-----

26. But… • How do you know for sure who is the owner of a public key?

27. Public Key Infrastructure Public Key Infrastructure (PKI) provides the means to bind public keys to their owners and helps in the distribution of reliable public keys in large heterogeneous networks. NIST The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke Public Key Certificates based on public-key cryptography. IETF PKIX working group PKI is electronic identity management!

28. X509.V3 Digital Certificate • Issued by a TRUSTED third party Certificate Authority (CA) • Creates and digitally signs Certificates • Issues Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) • Identity Proofing done by Local Registration Authority (LRA)

29. PKI Users • Subscribers • Entity who obtains certificates from a CA • Person, device, application, etc. • Owns private key associated with public key in certificate • Non-repudiation requires only subscriber has access to private key • CA may escrow private key used for encrypted email • Owner must protect private key • Password • Safer with hardware token / smart card • Relying Party • Entity who receives digital certificate • Trusts CA who attests to certificate holder’s identity

30. How Certificates are used Private key Get CRL to Validate Certificate Certificate 010111 102101 Directory Relying Party B encrypts message to Subscriber Get Subscriber's Certificate Relying Party A Subscriber signs message to A

31. SSL Server Authentication 3 https 1 Trust Issuing CA? 2 4 5 CRL Validate Certificate 7 SSL 6 WWW 1. Client sends https request to server 2. Server sends its certificate to the client 3. Client decides if certificate (and issuing CA) is trustworthy 4. Client validates certificate 5. Client sends to server session key - encrypted with server’s public key 6. Server decrypts session key with its private key 7. Client – Server transactions are now encrypted with session key

32. Ever See this? What do you do?

33. Trusted Third Party But, who are you going to trust? PKI is built upon the concept of the trusted third party (i.e., CA)

34. Who do you Trust? CA George Martha Clark • Everyone trusts their own CA (trust anchor) • Trust all certificates issued by their CA • Single CA model does not scale well • Difficult to manage across large or diverse user communities

35. Hierarchical PKI • CAs have superior-subordinate relationships • Higher level CAs issue certificates to subordinate CAs • Subordinate CA issues certificate to subscriber • Forms a certification path (aka certificate chain) • Chain of certificates from subscriber to root CA • Root CA is top-level, self-signed (i.e., certified) CA

36. Certificate Chain Root CA's Private Key Subordinate CA Certificate Info Sub CA Root CA's Private Key Root Signature Subscriber Certificate Info Subordinate CA's Private Key SubCA's Signature Text Document Subscriber's Private Key Subscriber's Signature Root CA Self Signed

37. Relying Party Certification Path Yellow Blue Gold Red Mark Phyllis A relying party builds a certificate path from the other subscriber to the relying party’s trust anchor Green CA Mark gets cert from Phyllis 1. Phyllis's cert signed by Red CA 2. Red's cert signed by Blue CA 3. Blue's cert signed by Green CA Green CA is Mark's trust anchor, therefore Mark trust's Phyllis's cert

38. What about other CAs? How do you know if you can trust the CA? Then, how much do you trust them?

39. Trust Lists Commercial CAs often come pre-loaded Why and how much do you trust a CA?

40. PKI Policies • Certificate Policy (CP) • High level document • Describes security policy for operating the CA • Defines roles and responsibilities • How CA will be managed • How registration will be performed (i.e., identity proofing requirements) • How subscribers use and handle their certificates and keys • Certification Practices Statement (CPS) • Detailed document • Describes mechanisms and procedures followed by CA to meet the requirements of their CP • Effectively the CA's operations manual. • Together, Determines Assurance Level • How much you should trust the CA’s certificates

41. However…. Most users just click YES to trust CA for expediency   Users generally don’t examine policies

42. Cross-Certified PKIs Green CA Blue CA Red CA • Disadvantages • Can form a MESH PKI • CA needs to maintain multiple relationships with other CAs • Hard to build certification path • Multiple possible paths • Loops and dead ends Gold CA Phyllis Mark • Peer-to-peer trust relationship • Between CAs or hierarchical PKI root CAs • CAs review polices and issue certificates to each other • Advantages • CAs are organizationally independent • Have independent policies • CA compromise does not effect others

43. Bridge PKI Architecture Blue CA Green CA Bridge CA Gold CA Red CA Mark Phyllis • Bridge is trust arbitrator • Only cross-certifies with other CAs • Relationships still peer-to-peer • Bridge is NOT a root CA • Certification path construction is much easier • Bridge does all policy management • Less work for the CAs • Maintains list of revoked CAs (CARL)

44. Federal Bridge Certificate Authority Illinois PKI DOD PKI NFC PKI NASA PKI Health Care BCA Higher Ed BCA Hospital PKI CANADA PKI University PKI All trust relationships handled by bridge CA

45. In HHS CA we Trust CA • DST is cross-certified with the FBCA • DST root is preloaded in browser/outlook trust lists • DST/ACES part of Federal PKI • HHS Certificates issued by Digital Signature Trust, (a commercial CA under GSA ACES) • Trusted TLS (SSL) certificates also available

46. HHS PKI Program

47. Project Goals CAI PKE Maintain and operate a certificate acceptance infrastructure (CAI) to validate the certificates that we receive from inside and outside HHS. Assist in PK-enabling (PKE) HHS business processes. Maintain and operate a public key infrastructure (PKI) to issue digital certificates to HHS entities (e.g., staff, applications, devices). PKI

48. Certificate Issuance System Subscriber goes to registration web site enters MS credentials Directory Record Login AD record is downloaded AD SSL Subscriber selects pass phrase Pass phrase Subscriber’s data stored in RA database Subscriber data Subscriber prints (bar-coded) registration form Subscriber takes form to LRA. Border Directory Data RA App LRA scans form, validates information and approves subscriber SSL Approval Subscriber data Subscriber follows URL to web page and enters their pass phrase Email sent to subscriber SSL Validated subscriber is redirected to CA along with subscriber’s data Pass phrase Certificates downloaded to subscriber’s browser and posted into Border Directory (and subsequently imported into AD)

49. Certificate Validation Service 4 PKE 3b 2 1 3d 3a 3c 1. Application receives certificate HHS PKI Trusted PKI OTHER PKI 2. PKI-enabled applications calls CAM 3. CAM validates certificate with: a. HHS CA (DST) b. Other ACES CAs c. Other CAs directly trusted by HHS d. Other CAs trusted through FBCA 4. CAM logs validation to meet GPEA/NARA electronic records requirements

50. Putting it all together SSL Other PKI Cross-Certification FBCA CRLs Border Directory TLS Reg Staff Reg Certificate Status Information to other PKIs + Signed Documents From other PKIs Encrypted Email Relying Party A Subscriber Subscriber Certificate Status + Certificate Records Digitally Signed Document Certificate Status Relying Party B Archive Signature Validation records