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 Receiving signed/encrypted 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?

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 /16/03) Ensure that authentication processes provide the appropriate level of assurance. SP 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 Personal Identity Verification (PIV) of Federal Employees and Contractors

9 E-Authentication OMB M PKI level 3 & 4 Anonymous Access level 1 Web PagesTime Card User ID Password level 2 Patient Data Authentication Mechanism Business Processes Potential Impact of Authentication Errors1234 Inconvenience, distress, reputationLowMod High Financial loss or agency liabilityLowMod High Harm to agency program or public interests--LowModHigh Unauthorized release of sensitive information--LowModHigh Civil or criminal violations--LowModHigh Personal safety-- LowMod E-Authentication Risk Assessment:

10  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 Personal Identity Verification of Federal Employees and Contractors  PIV-1: Identity proofing process October 2005  PIV-2: Smartcard ID BadgeOctober 2006 Homeland Security Presidential Directive 12 Policy for a Common Id Standard for Federal Employees and Contractors

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

12 Tutorial

13 Foundations of PKI

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 Shift Algorithm 3 characters Ciphertext: HW WX EUXWH Plaintext: ET TU BRUTE Julius Caesar (49 BC) substitution cipher Spartan Scytale – fifth century BC

16 Symmetric Key Cryptography Dear Bob: I am leaving you. Goodbye forever. Alice ciphertext encrypt decrypt Dear Bob: I am leaving you. Goodbye forever. Alice Bob 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 Same key used to encrypt and decrypt

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 decryptencrypt Bob: Leave me alone! Carol Bob: Leave me alone! Carol decryptencrypt Carol’s Public Key Carol’s Private Key Dear Carol: Alice is gone. Now we can be together Love, Bob 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 Dear Carol: Alice is gone. Now we can be together Love, Bob Bob Carol Works both ways Can encrypt with either key – decrypt with the other

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 A digital signature is a a type of electronic signature. It is a hash of 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 encrypt Sue’s Private Key Digital Signature 0F47CEFF AE0317DB AA567C29 Hash Value Hash Function 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 Sue

22 Validating a Digital Signature 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 Sue’s Public Key 0F47CEFF AE0317DB AA567C29 1. Re-compute the hash value 2. Obtain the author’s public key decrypt 0F47CEFF AE0317DB AA567C29 3. Decrypt the original hash 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 Dear Carol: I am still hoping when I get out of prison we can be together. Love, Bob encrypt Carol's Public Key encrypt A032F17634 E57BC b9c9 8FA A ECF ABCE4567CD decrypt Carol's Private Key decrypt Dear Carol: I am still hoping when I get out of prison we can be together. Love, Bob Bob Carol Encrypted uses the recipient's public key

25 Source of Public Key Keys can be published anywhere Attached as a signature to Pretty Good Privacy (PGP) -----BEGIN PGP SIGNATURE----- Version: PGP iQCVAwUBOx6SgoFNSxzKNZKFAQGK+gP6AnCVghZqbL3+rM5JMSqoC5OEYIkbvYZN 92CL+YSCj/EkdZnjxFmU9+wGsWiCwxvs/TzSX6SZxlpG1bHFKf0OPu7+JEfJ7J5z cPCSqbFXiXzmukMl5KNx0p0veIDW4DmwleDpkmhT05qnCheweoNyvTSzfA1TGeLl mpjBi6zUjiY= =Xq 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 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 Relying Party A Relying Party B encrypts message to Subscriber Subscriber signs message to A Get Subscriber's Certificate Directory Get CRL to Validate Certificate Private key Certificate

31 SSL Server Authentication 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 1 2 Trust Issuing CA? 3 Validate Certificate CRL

32 Ever See this? What do you do?

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

34 Who do you Trust? Everyone trusts their own CA (trust anchor) Trust all certificates issued by their CA CA GeorgeMartha Clark 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 Certificate Info Root Signature Sub CA Root Signature Subordinate CA Certificate Info Root CA's Private Key Subordinate CA's Private Key SubCA's Signature Subscriber Certificate Info Subscriber's Signature Text Document Subscriber's Private Key Self Signed

37 Relying Party Certification Path Green CA Yellow Gold Mark Blue Red Phyllis A relying party builds a certificate path from the other subscriber to the relying party’s trust anchor 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…. Users generally don’t examine policies Most users just click YES to trust CA for expediency 

42 Cross-Certified PKIs  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  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 Green CABlue CA Gold CA Red CA Mark Phyllis

43 Bridge PKI Architecture 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) Green CA Blue CA Gold CA Red CA MarkPhyllis Bridge CA

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

45 In HHS CA we Trust  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 PKI Maintain and operate a public key infrastructure (PKI) to issue digital certificates to HHS entities (e.g., staff, applications, devices). CAI Maintain and operate a certificate acceptance infrastructure (CAI) to validate the certificates that we receive from inside and outside HHS. PKE Assist in PK-enabling (PKE) HHS business processes.

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

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

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

51 Obtaining your HHS Certificate

52 Request Your Certificates

53 Identify Yourself

54 ActiveX Requirements

55 Review Steps

56 Identify your Employer

57 Verify Your Information If incorrect, see your local system administrator

58 Pick One-Time Pass phrase You will need this pass phrase to get your certificates in the last step

59 Download/Print Request Form Click here to download form

60 PKI Certificate Request Form Notary information is ONLY collected if can not appear in-person before LRA Second form of ID is needed ONLY if Federal badge doesn’t have unique ID number Photocopy Government picture ID onto form Don’t sign / date until you are before an LRA Contractors need customer’s signature (e.g., PM, AO )

61 Take Completed Form to LRA

62 Enabling ActiveX Tools -> Internet Options -> Security

63 Notification Click on this URL to obtain your certificates

64 Enters Pass Phrase If you forgot your passphrase, you will need to repeat the form creation and LRA process Enter pass phrase

65 Install Active-X Module Click YES to install. Some “locked down” desktops may (currently) require system admin. support

66 Review & Accept Subscriber Agreement Check this box

67 Download Instructions Click link to download PDF Click boxThen click next

68 Begin Retrieval Process Click

69 Microsoft Warning Click YES

70 Change Security Level You MUST click here to set security level to HIGH in order to password protect your private key

71 Set Security Level to High Check HIGH Then click Next

72 Set Password for Private Key You must REMEMBER this password. It can not be reset by an administrator.

73 Click OK to Save Setting After setting security level to HIGH You may now click OK

74 Processing...

75 Review Your Certificates

76 Download Encryption Certificate

77 Repeated Microsoft Warning Click YES

78 Repeat Setting Security Level to High

79 Set Encryption Password You may use the SAME password you entered for your signing Certificate

80 Certificate Download Complete

81 Configuring Outlook Tools → Options

82 Tools → Options → Security → Settings… Click Settings Security tab

83 Specify Signing Certificate Specify ANY name you like Click Choose

84 Select DST ACES Certificate If more than one pick Certificate issued by DST ACES Federal Employee CA

85 Specify Encryption Certificate Click Choose

86 Publish to GAL

87 Enter Certificate Password You will be prompted to enter your password each time you use your certificate Do NOT Check

88 Using Your Certificates

89 Sending Signed/Encrypted

90 If using Microsoft Office Word to edit messages Message Options

91 Security Settings

92 Send NEVER Enter PKI private key password to sign

93 Receiving Secure

94 Click Ribbon for Details Lock shows Message was encrypted

95 Add Buttons to toolbar Uncheck to set to default message editor

96 Configure Message Editor Buttons automatically migrate to Word editor as well

97 Adobe 7.0

98 Create Adobe Signature

99 Position Adobe Signature

100 Select Certificate

101 Specify Reason for Signature

102 Private Key Password NEVER

103 First Time – May not be Trusted

104 Enable Windows Trust

105 Validate Signature Right Click

106 Add Trusted CA (Macintosh) Right Click

107 Signing a Word Document

108 Signed Document Double Click

109 Managing Your Certificates

110 Export (backup/move)

111 Pick First Certificate

112 Specify File and Password This is a NEW password to protect the FILE! Filename Password

113 Enter Certificate Password This is the OLD password used to protect your private key

114 Repeat for Second Certificate

115 Import Certificate Filename and password from export Must enter a name. Use any name you like.

116 Set Security Level to High Import/export is way to password protect private key if you failed to set security level when initially obtaining your certificates.

117 Create New Password This is the password to protect your private key.

118 Repeat for Second Certificate

119 Internet Explorer

120 Tools → Internet Options → Content… Content Tab Click Certificates….

121 Can Export/Import/Delete

122 LRA Subscriber Registration

123 HHS PKI LRA Home Page

124 Certificate Authentication

125 First Time Download

126 LRA Management Page

127 Collect Registration Data

128 Approve Request

129 Registration Complete

130 Questions Answers: