Public Key Infrastructures Chapter 11 Trust Center (Certification Authority)

Transcription

1 Public Key Infrastructures Chapter 11 Trust Center (Certification Authority) Cryptography and Computer Algebra Prof. Dr. Johannes Buchmann Dr. Alexander Wiesmaier

2 Trust center (TC) Trusted third party Serves as trust anchor in hierarchical PKIs Trust center Home of the issuer Provides entities with PKI services Responsible for correct operation of the PKI Usually composted of various Public key components (authorities) guarantees binding Identity 2

3 Free Trust Center Services Source: 3

4 Trust center components (authorities) Registration Authority (RA) (registration, certification and revocation requests,...) requests Request manages Certification Authority (CA) key pairs certificates PSEs revocations maintain sends CA- Product Directory Services (DS) (publication, delivery,...) 4

5 Registration Authority (RA) Contact point for (prospective) PKI entities Registration Authority (RA) (registration, certification and revocation requests,...) Register prospective entities requests Request manages Establish customer relationship Accept requests from entities Usually online maintain Certification Authority (CA) key pairs certificates PSEs revocations sends CA- Product Directory Services (DS) (publication, delivery,...) 5

6 Key/Certificate Life Cycle and RA Initialization Registration Key Pair Generation Certificate Creation and Key/Certificate Distribution Certificate Dissemination Key Backup (if appropriate) Issued Certificate Retrieval Certificate Validation Key Recovery Key Update Legend: performs initialises does not apply Cancellation Certificate Expiration Certificate Revocation Key History Key Archive [Source: Understanding Public-Key Infrastructure, C. Adams et al., New-Riders Publishing, 1999] 6

7 Registration Protocols Certificate Management Protocol (CMP) ftp://ftp.rfc-editor.org/in-notes/rfc4210.txt Certificate Request Message Format (CRMF) ftp://ftp.rfc-editor.org/in-notes/rfc4211.txt Certificate Management over CMS (CMC) ftp://ftp.rfc-editor.org/in-notes/rfc5272.txt XML Key Management Specification (XKMS) 7

8 Registration Authority (RA) Goal: 1. identity public key 2. public key identity trust center guarantees public key binding identity 8

9 Registration Authority (RA) Procedure in TC: 1. determines identity and public key, 2.generates digital name, 3.issues certificate. trust center guarantees? public key binding digital name binding identity PK-certificate 9

10 Registration Authority (RA) trust center Guaranty through Registration of the participants. guarantees Task of the Registration Authority public key binding digital name binding identity PK-certificate 10

11 Registration Establish identity contact information client preferences billing data public keys und proof-of-possession (optional) Secure Out-of-Band communication channel Checking the prospective participant s authorization Storing of the registration dataset Creation of a unique digital name (for the certificate) 11

12 Identity Wikipedia: In philosophy, identity is whatever makes an entity definable and recognizable, in terms of possessing a set of qualities or characteristics that distinguish it from entities of a different type. Or, in layman's terms, identity is whatever makes something the same or different. name residence citizenship place and date of birth data on ID card biometrical data employer name of the parents address object identifier 12

13 Identity Wikipedia: In philosophy, identity is whatever makes an entity definable and recognizable, in terms of possessing a set of qualities or characteristics that distinguish it from entities of a different type. Or, in layman's terms, identity is whatever makes something the same or different. name residence citizenship place and date of birth data on ID card biometrical data employer name of the parents address object identifier 13

14 Contact information Information about the accessibility of a participant, e.g: postal address telephone number address other 14

15 Client preferences Choice of the cryptosystem and parameters Delivery (smart card, PIN-letter, etc.) Certificate s validity period Pseudonym Billing method Other... 15

16 Client Keys The clients may generate their own keys. How to transfer the public key to the trust center? 16

17 Transfer of the public-key PKCS#10 Public-key + additional attributes Signature with the corresponding private-key Directly in the browser (IE, Mozilla, Netscape) special HTML-Form field modified PKCS#10-format Signature with a private-key that is generated in the browser Other ways 17

18 PKCS#10 This document describes syntax for certification requests. A certification request of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. Certification requests are sent to a certification authority, which transforms the request into an X.509 public-certificate. (In what form the certification authority returns the newly signed certificate outside the scope of this document. Available at: 18

19 PKCS#10 This document describes syntax for certification requests. A certification request of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. Certification requests are sent to a certification authority, which transforms the request into an X.509 public-certificate. (In what form the certification authority returns the newly signed certificate outside the scope of this document. Available at: 19

20 PKCS#10 This document describes syntax for certification requests. A certification request of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. Certification requests are sent to a certification authority, which transforms the request into an X.509 public-certificate. (In what form the certification authority returns the newly signed certificate outside the scope of this document. Available at: 20

21 PKCS#10 The process by which a certification request is constructed involves the following steps: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity s private key. 3. The CertificationRequestInfo value, a signature algorithm identifier, and the entity's signature are collected together into a CertificationRequest value, defined below 21

22 PKCS#10 The process by which a certification request is constructed involves the following steps: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity s private key. 3. The CertificationRequestInfo value, a signature algorithm identifier, and the entity's signature are collected together into a CertificationRequest value, defined below 22

23 PKCS#10 The process by which a certification request is constructed involves the following steps: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity s private key. 3. The CertificationRequestInfo value, a signature algorithm identifier, and the entity's signature are collected together into a CertificationRequest value, defined below 23

24 PKCS#10 The process by which a certification request is constructed involves the following steps: 1. A CertificationRequestInfo value containing a subject distinguished name, a subject public key, and optionally a set of attributes is constructed by an entity requesting certification. 2. The CertificationRequestInfo value is signed with the subject entity s private key. 3. The CertificationRequestInfo value, a signature algorithm identifier, and the entity's signature are collected together into a CertificationRequest value, defined below 24

25 PKCS#10 ASN.1 CertificationRequest ::= SEQUENCE { } certificationrequestinfo signaturealgorithm signature CertificationRequestInfo, AlgorithmIdentifier{{ SignatureAlgorithms }}, BIT STRING 25

26 Proof-of-Possession (PoP) How can the trust center be sure that the private key exists? How can the entity prove to the trust center that it possesses the private key? 26

27 PoP: PKCS#10 In PKCS#10 this is performed by signing the request. CertificationRequest ::= SEQUENCE { certificationrequestinfo CertificationRequestInfo, signaturealgorithm AlgorithmIdentifier{{ SignatureAlgorithms }}, signature BIT STRING } BUT: This solution can be used for signature keys only. 27

28 PoP: Encryption Keys Encrypt a value and have the entity decrypt it (direct) Encrypt the certificate and have the entity decrypt it (indirect) 28

29 PoP: Key Agreement Keys Establishing of a shared secret key between trust center and entity. 29

30 PoP: CRMF ProofOfPossession ::= CHOICE { raverified [0] NULL, signature [1] POPOSigningKey, keyencipherment [2] POPOPrivKey, keyagreement [3] POPOPrivKey } Certificate Request Message Format (CRMF) ftp://ftp.rfc-editor.org/in-notes/rfc4211.txt 30

31 PoP: CRMF Signing Key POPOSigningKey ::= SEQUENCE { poposkinput [0] POPOSigningKeyInput OPTIONAL, algorithmidentifier AlgorithmIdentifier, signature BIT STRING } 31

32 PoP: CRMF Encryption Key POPOPrivKey ::= CHOICE { thismessage [0] BIT STRING, -- deprecated subsequentmessage [1] SubsequentMessage, dhmac [2] BIT STRING, -- deprecated agreemac [3] PKMACValue, encryptedkey [4] EnvelopedData } SubsequentMessage ::= INTEGER { encrcert (0), challengeresp (1) } 32

33 Example: Thawte Certificates 33

34 Thawte: Registration 34

35 Thawte: Request Certificate 35

36 Thawte: Client preferences 36

37 Thawte: Additional identity information 37

38 Thawte: Certificate Address 38

39 Thawte: Client preferences Extensions 39

40 Thawte: Client preferences Key Size 40

41 Thawte: Key Generation (1) 41

42 Thawte: Key Generation (2) 42

43 Thawte: Request + Pub Key Submission 43

44 Thawte: Request Confirmation 44

45 Thawte: Certificate Notification 45

46 Thawte: Certificate Retrieval 46

47 Thawte: Review Certificate (1) 47

48 Thawte: Review Certificate (2) 48

49 Secure Out-of-Band communication channel Independent of the PKI: Face-to-face communication (i.e. local presence) previously established shared secrets (e.g. passwords) Third party services (e.g. Postident) 49

50 Example: Registration with Postident 1. The TC issues a coupon 2. The customer delivers the coupon to the post office 3. The post office employee checks a valid official document (IDcard, passport, etc.) and fills out an application with the customer s data 4. The application is signed by the customer and the post office employee 5. The post office employee sends the application and coupon to the TC 50

51 Postident coupon 51

52 Postident examples Example of a Postident procedure in a trust center file://../resources/8.postident_basic_coupon.pdf Example of a Postident procedure in a bank: file://../resources/commercial_checking_account_form_en.pdf 52

53 New possibility: Registration with the npa 53

54 Check the authorization Is the requester allowed to participate in the PKI? E.g. requester is a student of the computer science department E.g. there are warrantors for the requester Special qualifications / restrictions in the certificate? E.g. monetary limitations E.g. liability provisions E.g. access authorization 54

55 Digital Names Representation of the participant Meaningful description of the participant OR Pseudonym In both cases: unique mapping digital name participant Creation Description of the identity, Contact information, (Artificially) unique e.g. by enumeration or similar, Compliant to specifications in the policy Compliant to privacy protection guidelines Examples: Hans Mustermann, born in in Musterstadt, Hochschulstr. 10, Darmstadt Hans Mustermann25 ID-Card No Binary representation of the fingerprint 55

56 Data Sources Independent ascertainment by the RA personal contact online-registration Usage of data from third parties e.g. staff database, registry office security depends on the data source input assistance or trusted source These approaches can be combined 56

57 RA Models Centralized One RA for all participants Decentralized (Local Registration Authority, LRA) Different RAs for different participant groups Hybrid models E.g. distributed collection of data, but centralized data management 57

58 Reasons for Decentralization Topology (e.g. lots of company branches) Separation of the responsibilities On-site registration better identification (known requester) distribution of the cost (registration is time consuming) less work for the end-entity (e.g. registration at the workplace) use of established workflows Fail-safeness 58

59 Security Requirements for the Registration Correctness of the registration data set Checking during ascertainment Obsolete data refresh Enforce the Certificate Policy Completeness of the registration data set Authorization Data protection Access control for registration data sets Integrity protection of the data CRC, MAC, digital Signatures, Availability of the data Backup Verifiability of the processes (auditing acceptability) Logging 59

60 An Example of Wrong Registration Forged Microsoft-Certificate ( ) An individual passed off as a Microsoft employee VeriSign issued - without any further examination - two certificates. Danger: The users can be tricked that software has been created by Microsoft and that Microsoft guarantees the security of the software. Affected: executable files, ActiveX Controls or Office- Macros. The certificates have been revoked. These two certificates have been explicitly marked as invalid. More: 60

61 Forged Microsoft Certificates Windows property for the certificate C:\Windows\System32\certmgr.msc 61

62 Extended Validation Certificates In order to issue an extended validation (EV) certificate, thorough validation is performed. file://../resources/ev_certificate_guidelines.pdf 62

63 EV Certificates Scope EV Certificates are intended for use in establishing web-based data communication conduits via TLS/SSL protocols. 63

64 EV Certificates Primary Purposes Identify the legal entity that controls a website: Provide a reasonable assurance to the user of an Internet browser that the website the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation, and Registration Number Encrypted communications with a website: Facilitate the exchange of encryption keys in order to enable the encrypted communication of information 64

65 EV Certificates Primary Purposes Identify the legal entity that controls a website: Provide a reasonable assurance to the user of an Internet browser that the website the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation, and Registration Number Encrypted communications with a website: Facilitate the exchange of encryption keys in order to enable the encrypted communication of information 65

66 EV Certificates Secondary Purposes To help establish the legitimacy of a business claiming to operate a website by confirming its legal and physical existence, and to provide a vehicle that can be used to assist in addressing problems related to phishing and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the owner of a website, EV Certificates may help to: (1) Make it more difficult to mount phishing and other online identity fraud attacks using SSL certificates; (2) Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves and their legitimate websites to users; and (3) Assist law enforcement in investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. 66

67 EV Certificates Secondary Purposes To help establish the legitimacy of a business claiming to operate a website by confirming its legal and physical existence, and to provide a vehicle that can be used to assist in addressing problems related to phishing and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the owner of a website, EV Certificates may help to: (1) Make it more difficult to mount phishing and other online identity fraud attacks using SSL certificates; (2) Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves and their legitimate websites to users; and (3) Assist law enforcement in investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. 67

68 EV Certificates Secondary Purposes To help establish the legitimacy of a business claiming to operate a website by confirming its legal and physical existence, and to provide a vehicle that can be used to assist in addressing problems related to phishing and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the owner of a website, EV Certificates may help to: (1) Make it more difficult to mount phishing and other online identity fraud attacks using SSL certificates; (2) Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves and their legitimate websites to users; and (3) Assist law enforcement in investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. 68

69 EV Certificates Secondary Purposes To help establish the legitimacy of a business claiming to operate a website by confirming its legal and physical existence, and to provide a vehicle that can be used to assist in addressing problems related to phishing and other forms of online identity fraud. By providing more reliable third-party verified identity and address information regarding the owner of a website, EV Certificates may help to: (1) Make it more difficult to mount phishing and other online identity fraud attacks using SSL certificates; (2) Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves and their legitimate websites to users; and (3) Assist law enforcement in investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject. 69

70 EV Certificates: What is Verified? Applicant s Legal Existence and Identity Applicant s Physical Existence Applicant s Operational Existence Applicant s Domain Name Name, Title and Authority of Contract Signer More 70

71 EV Certificates Example: VeriSign 71

72 Certification authority (CA) Conduct issuing tasks Use issuer private key(s) Handle entity key pairs Generate PSEs Often offline and physically shielded (strong room) maintain Registration Authority (RA) (registration, certification and revocation requests,...) requests Certification Authority (CA) key pairs certificates PSEs revocations sends Request CA- Product Directory Services (DS) (publication, delivery,...) manages 72

73 Key/Certificate life cycle and CA Initialization Registration Key Pair Generation Certificate Creation and Key/Certificate Distribution Certificate Dissemination Key Backup (if appropriate) Issued Certificate Retrieval Certificate Validation Key Recovery Key Update Legend: performs initialises does not apply Cancellation Certificate Expiration Certificate Revocation Key History Key Archive [Source: Understanding Public-Key Infrastructure, C. Adams et al., New-Riders Publishing, 1999] 73

74 CA: Motivation Private key necessary & sufficient Decryption Signature creation Identification Management of the private key is highly security critical Secure handling of private keys is needed 74

75 CA: Key Management Tasks Generation Backup Storing Recovery Transport Use Destruction start state state end state 75

76 KA: Possession Rights Own key-pair The key pair of the entitled user (the user is usually associated to the public key in the corresponding certificate) Foreign key-pair All key pairs that are not own key-pairs 76

77 KA: Definition / Tasks Definition: Owner of the issuer key-pair(s) The only instance that is allowed to see foreign key-pairs Tasks: All actions that require or allow access to issuer key-pairs or foreign key-pairs. 77

78 Tasks of the KA (1) Issuing (issuer keys) Signing of certificates Revocation (issuer keys) Signing of revocation lists Key Generation (foreign keys) Generation of all key-pairs that their owners are not creating on themselves. 78

79 Tasks of the KA (2) Personalization Write generated keys on tokens Generation of a Transport-PIN and a PIN-Letter Archiving/Backup/Recovery Storage of keys Recovery of keys If necessary and permitted 79

80 Advantages of the KA Protection of issuer keys and foreign keys by protecting the KA Single, central instance to be protected KA is located in a known and suitable environment (trust center) Deployment of known technical and organizational protection measures 80

81 KA: Security Access protection Authentication Access rights Secure communication Authentic Secret Strong cryptography Flexible algorithms and cryptographic providers Fall-back mechanisms Logging Who did what and when 81

82 KA: Protection Measures Technical: Physical shielding Cryptographic hardware Organizational: Offline Mode Dual or multi-control 82

83 KA: More Requirements Scalability High computational costs Load variations Robustness The issuer private key is very sensible Keep doors closed Transactionality Complete, consistent, and persistent data 83

84 KA: Effect Maximum protection of private keys KA protects all issuer private keys KA protects all foreign private keys within the trust center KA supports the protection of private keys of their owners 84

85 Example: Firefox Key Manager 85

86 FF Key Mngr: certificate attributes 86

87 FF Key Mngr: Key usage 87

88 FF Key Mngr: certificate type 88

89 Directory Services (DS) Publish PKI information Deliver PSEs Manage certificate lifecycle Usually online Registration Authority (RA) (registration, certification and revocation requests,...) requests Request Certification Authority (CA) key pairs certificates PSEs revocations manages maintain sends CA- Product Directory Services (DS) (publication, delivery,...) 89

90 Key/Certificate life cycle and DS Initialization Registration Key Pair Generation Certificate Creation and Key/Certificate Distribution Certificate Dissemination Key Backup (if appropriate) Issued Certificate Retrieval Certificate Validation Key Recovery Key Update Legend: performs initialises does not apply Cancellation Certificate Expiration Certificate Revocation Key History Key Archive [Source: Understanding Public-Key Infrastructure, C. Adams et al., New-Riders Publishing, 1999] 90

91 Certificate notification 91

92 Certificate retrieval 92

93 (Automatic) certificate installation 93

94 Ceritificate Management Authority (CMA) The certificate management authority (CMA) is a PKI operating component. It has the task of managing and administrating products of issuers on their behalf. Why not done by: Offline CA Difficult administration RA Out of its scope 94

95 CMA Tasks Archiving Delivery Publishing Certificate status information backend CRL management Renewal notification Error Handling Miscellaneous tasks 95

96 CMA: Archiving Archiving of certificates and CRL Persistent store (DB, LDAP, etc.) No need to contact the KA PSE archiving is supported 96

97 CMA: Archiving 97

98 CMA: Delivery Delivery (to end-entities) of Certificates PSEs Revocation information 98

99 CMA: Delivery Server LDAP Server 99

100 CMA: Publishing In order to enable clients to search and download certificates and CRLs Different methods exist LDAP, HTTP, others Some certificates may not be published at all Depending on policy 100

101 CMA: Publishing 101

102 CMA: Certificate status information backend Support an OCSP server in providing correct and fresh revocation information. Secure and trusted backend store is needed Provide this information on demand or in cache. 102

103 CMA: Certificate status information backend 103

104 CMA: CRL management Push CRL services when a CRL is issued it is pushed to clients that have subscribed with these services But: CA is often offline Operate as a revocation authority issuing of indirect CRLs Immediate revocation is possible 104

105 CMA: CRL management CRL 105

106 CMA: Renewal Notification Certificate renewal automatic notification (before expiration) of the participant of KA or RA CRL renewal the validity period of a CRL is short automatic regular renewal in order to always have a valid CRL automatic notification to RA or KA issuing of a new CRL by the CMA (if it is allowed to issue CRLs) 106

107 CMA: Error handling If an error occurs an administrator is notified (e.g. by an ) Possible reactions repeat the process e.g. if a certificate could not be issued, try this once again automatic revocation, for example the certificate is correct but the PSE has a problem 107

108 CMA: Other Tasks Backup services Validation services, etc. Others 108

109 FlexiTrust CA FlexiTRUST RA Database KA End-Entity PKI Clients CMA LDAP Evaluated and approved for qualified Signatures: file://../resources/1699.pdf Internet 109

110 FlexiTrust CA: Certification Request RA KA CMA 110

111 FlexiTrust CA: Revocation Request RA KA CMA Push 111