Certification Authority or Trust center · Verification of Applicant’s Legal Existence and...

1

Certification Authorityor

Trust center

2

Design of one trust center

3

Registration Authority

4

publickey identity

Trust center

guarantees

binding

5

publickey identity

trust center

guarantees

binding

Goal:1. identity →

public key2. public key →

identity

6

publickey identity

Trust center

guarantees

binding

Procedure in TC:1. determines identity

and public key,2. generates digital

name,3. issues certificate.

digitalname

PK-certificate

binding

?

7

publickey identity

trust center

guarantees

binding

guarantee through Registration of the participants.task of the Registration Authority

digitalname

PK-certificate

binding

8

Registration

Data collection and validation (→Registration dataset)Provisions in Certificate Policy

Which data is collected?How is this data collected?

9

RegistrationEstablish

identitycontact informationclient preferencesbilling datapublic keys und proof-of-possession (optional)

Secure „Out-of-Band“ communication channelCheck the authorizationStoring of the registration datasetCreation of a unique digital name (for the certificate)

10

Identity

nameresidencecitizenshipplace and date of birthdata of ID card

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.

biometrical dataemployername of the parentsemail addressobject identifier

11

Contact information

Information about the accessibility of a participant, e.g.

postal addresstelephone numberemail addressdata of ID card

12

Client preferences

Choice of the cryptosystem and parametersDelivery (smart card, PIN-letter, etc.)Certificate’s validity periodPseudonymBilling methodOther...

13

The clients generate their own key.

How to transfer the public key to the trust center?

14

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-formatSignature with a private-key that is generated in

the browser… more

15

Contact information

16

Established identity

17

Client preferences

18

Additional identity information

19

Additional identity information

20

Client preferences

21

Client preferences

22

Public key transfer

23

Public key transfer

31

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 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:http://www.rsa.com/rsalabs/node.asp?id=2132

32

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 CertificationRequestvalue, defined below

33

PKCS#10 ASN.1

CertificationRequest ::= SEQUENCE {certificationRequestInfo CertificationRequestInfo,signatureAlgorithm AlgorithmIdentifier{{

SignatureAlgorithms }},signature BIT STRING

}

34

Proof-of-Possession

How can the trust center be sure that the public key exists?

How can the entity prove to the trust center that it possesses the public key?

35

In PKCS#10 this is performed by signing the request.

CertificationRequest ::= SEQUENCE {certificationRequestInfoCertificationRequestInfo,

signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},

signature BIT STRING}

36

But this solution can be used for signature keys only.

37

For encryption keys:

Encrypt a value and have the entity decrypt it (direct)

Encrypt the certificate and have the entity decrypt it (indirect)

Request the key from the entity.

38

For key agreement keys:

Establishing of a shared secret key between trust center and entity.

39

PoP ASN.1

ProofOfPossession ::= CHOICE { raVerified [0] NULL,signature [1] POPOSigningKey,keyEncipherment [2] POPOPrivKey, keyAgreement [3] POPOPrivKey }

40

PoP Signing Key

POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING

}

41

PoP Encryption Key

POPOPrivKey ::= CHOICE { thisMessage [0] BIT STRING, -- deprecated subsequentMessage [1] SubsequentMessage, dhMAC [2] BIT STRING, -- deprecatedagreeMAC [3] PKMACValue,encryptedKey [4] EnvelopedData }

SubsequentMessage ::= INTEGER {encrCert (0),challengeResp (1) }

42

CMP (RFC 4210)

CRMF (RFC 4211)

CMC (RFC 2797)

XKMS (W3C)

Other registration protocols

43

XKMS

Key Registration Service Protocol

http://www.w3.org/TR/xkms/#_Toc505753161

44

Secure „Out-of-Band“ communication channel

Independent of the PKI (e.g. passwords)

45

Examples

Postident

Secure „Out-of-Band“ communication channel

46

Postident

Secure identification.

The TC issues a coupon.The customer delivers the coupon to the post office.The post office employee checks a valid official document (ID-card, passport, etc.) and fills out an application with the costumer’s data.The application is singed by the costumer.The post office employee sends the application and coupon to the TC.

47

Postident coupon

48

Example of a PostIdent procedure in a trust center../Resources/8.PostIdent_basic_Coupon.pdf

Example of a PostIdent procedure in a bank:../Resources/Commercial_Checking_Account_Form_en.pdf

49

Check the authorization

Is the requester allowed to participate in the PKI?e.g.

Requester is a student of the computer science department.

There are warrantors for the requester.Special qualifications in the certificate? e.g.

monetary limitationsliability provisions access authorization

50

Digital names

Unique mapping to the identity of the participantCreation

description of the identity,contact information,artificial through enumeration or similar,specifications in the policy

Privacy protection guidelines.e.g. :

„Hans Mustermann, born in 1.1.1960 in Musterstadt, Hochschulstr. 10, Darmstadt“

“Hans Mustermann25”“ID-Card No. 123456789”Binary representation of the fingerprint

51

Digital names

Provide a meaningful description of the participant

e.g. in order to search for the participant’s certificate

e.g.:“Hans Mustermann, Computer Science, TU-Darmstadt, Germany”“Hans Mustermann, Hochschulstr. 10, Darmstadt, Germany”“[email protected]”

52

Data sources

Independent ascertainment by the RApersonal contact online-registration

Usage of data from third partiese.g. personnel database, registry officesecurity depends on the data sourceinput assistance or trusted source

These approaches can be combined

53

RA distribution

Centralized

Distributed collection of data, but centralized data management

Decentralized (LRA, Local Registration Authority)

54

Reasons for decentralisation

Topology (e.g. lots of company branches)Separation of the responsibilitiesOn-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 existent and established workflows

Fail-safeness

55

Key/Certificate life cycle and RA Services

Initialization

Issued

Cancellation

RegistrationKey Pair GenerationCertificate Creation and Key/Certificate DistributionCertificate Dissemination Key Backup (if appropriate)

Certificate RetrievalCertificate ValidationKey RecoveryKey Update

Certificate ExpirationCertificate RevocationKey HistoryKey Archive

Source: „Understanding Public-Key Infrastructure“, C.Adams et al., New-Riders Publishing, 1999

Legend:

performsinitialisesdoes not apply

56

Correctness of the registration data setChecking during ascertainmentObsolete data ⇒ refresh

Enforce the Certificate PolicyCompleteness of the registration data setAuthorization

Data protection Access control for registration data sets

Integrity protection of the dataAvailability of the data

BackupVerifiability of the processes (auditing acceptability)

Security requirements for the registration

57

Forged Microsoft-Certificate (26.03.2001)An individual passed off as a Microsoft employeeVerisign 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: http://www.microsoft.com/technet/security/bulletin/MS01-017.mspx

An example of wrong registration

58

Windows property for the certificate

59

Extended validation certificates

In order to issue an extended validation (EV) certificate, thorough validation is perfomed.

http://cabforum.org/EV_Certificate_Guidelines.pdf

60

EV certificates - scope

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

61

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; and

Enable/encrypted communications with a website: Facilitate the exchange of encryption keys in order to enable the encrypted communication of information

62

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 toprovide 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.

63

What is verified

Verification of Applicant’s Legal Existence and IdentityVerification of Applicant’s Legal Existence and Identity – Assumed NameVerification of Applicant’s Physical ExistenceVerification of Applicant’s Operational ExistenceVerification of Applicant’s Domain NameVerification of Name, Title and Authority of Contract Signer &

CertificateVerification of Signature on Subscriber Agreement and EV CertificateVerification of Approval of EV Certificate RequestVerification of Certain Information SourcesOther Verification RequirementsFinal Cross-Correlation and Due DiligenceCertificate Renewal Verification Requirements

http://cabforum.org/EV_Certificate_Guidelines.pdf

67

Registration Examples

THAWTE

TC Trust Center TELESEC

VERISIGN

76

Hi! Please use your browser to go to the following URL: https://www.thawte.com/cgi/enroll/personal/step8.exeOnce you have connected successfully to the above address, you must copy and paste the "probe" and "ping" values below into the appropriate text boxes:Probe: value Ping: valueYou should save this message until you have completed the enrollment process, just in case. But you MUST go to the above URL within 24 hours, or we will delete your request information and you'll have to start over! If you have problems completing the above please contact our support team by going to the following URL: https://www.thawte.com/cgi/support/contents.exeRegards, The thawte team thawte Certification

83

email address

87

keytool -certreq -keystore keystore.ks -file csr.txt -alias myalias

88

-----BEGIN NEW CERTIFICATE REQUEST-----MIIBrDCCARUCAQwbDELMAkGA1UEBhMCREUxDjAMBgNVBTBUhlc3NlMRIwEAYDVQQHEwlEYXJtN57qbnyAfAAAAAAAc3RhZHQxDDKBgNVATA1RVRDEMMAoGA1UECxMDQ0RDMRwGwYDVQQDExRWY5nZWxpcyBLYXJhN57qbnyAfAAAAAAAdHNpb2xpcznzANBqhkiG9w0BAQEFAAOBjQAwgYkCgYEAroJITHFBR5orQ9dB4qkP/gMhS1hCNiowdM2CrJINiowdM2CCCCE+Qrzut77pzzjlEBLQeeMC0Q88LF8tTJfFoUKdGni/PAAiOPHxvNXFFH0YZs4/P7gXMAX+9eEgGNiowdM2CrJINiowdM2CCCCEjL2ig7PyQlkGGwIbvxYQmEX2TKk9tKWqCvFjl6BKTjIIjErmgolyi79dk3Cdwx26Z8CAwEAAaAANiowdM2CrJINiowdM2CCCCEEEMA0GCSqGSIb3DEBBAUAAGBAIvbaheW+lVaDdRN57qbnyAf3qqxD2GcjmBcCcO8v3TN9zc4mSENiowdM2CrJINiowdM2CCCCpXXTFQg4UqO0urJINiowdM2CtrPzlEtORJNtoxxiRLHp9+LLNXnER43nYvcLZ/QIChlfIX6KiPrJINiowdM2CrJINiowdM2CCCCElr81bvYRq6G/bGxrz4K55c17UIqPtlGN7yQEDxYZ5e+-----END NEW CERTIFICATE REQUEST-----

92

The user receives a URL that contains thecertificate inside a PKCS#7 structure

93

keytool -import -file test.crt -alias myalias -trustcacerts -keystore keystore.ks

99


100

Key Authority

101

Motivation

Private key necessary & sufficientEncryptionSignature creationIdentification

⇒Management of the private key is highly security critical

⇒Secure handling of private keys is needed

102

Use

Destruction

Transport

storing

Backup

Recovery

Generation

Life cycle of private keys

start state

state

end state

103

Possession rights

Own key-pairThe key pair of the entitled user (the user is usually associated to the public key)

Foreign key-pairAll key pairs that are not own key-pairs

104

Key Authority

Definition:Owner of the issuer key-pairsThe only instance that is allowed to see foreign key-pairs

Tasks:Everything that it is allowed to performOtherwise nothing

105

Tasks of the KA

IssuingSigning of certificates

RevocationSigning of revocation lists

Key GenerationGeneration of all key-pairs that their owners are not creating on themselves.

106

Tasks of the KA

PersonalizationWrite generated keys on tokensGeneration of a Transport-PIN and a PIN-Letter

Archiving/Backup/RecoveryStorage of keysRecovery of keysIf necessary and not resolved by the owner.

107

Advantages of the KA

Protection of issuer keys and foreign keys by protecting the KA

Single, central object to be protected

KA is located in a known and suited environment (trust center)

Deployment of known technical and organizational protection measures

108

SecurityAccess protection

AuthenticationAccess rights

Secure communicationAuthenticSecret

Cryptographic flexibilityAlgorithms und cryptographic providerFall-back mechanism

LoggingWho did what and when

109

Protection measures

Technical:Physical shieldingCryptographic hardware

Organizational:Offline ModeDual or multi-control

110

More requirements

ScalabilityHigh computational costsLoad variations

RobustnessThe issuer private key is very sensibleKeep doors closed

TransactionalityComplete, consistent, and persistent data

111

Result

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

112

Key/Certificate life cycle and KA Services

Initialization

Issued

Cancellation

RegistrationKey Pair GenerationCertificate Creation and Key/Certificate DistributionCertificate Dissemination Key Backup (if appropriate)




Legend:


113

Example

../Resources/Components.pdf

114

Entrust CAFrom: ENTRUST CPS

Physical ControlsEntrust/Authority software is used as the software component of the Entrust SSL Web Server Certification Authorities. The hardware and software for an Entrust SSL Web Server Certification Authority is located in a secure facility with physical security and access control procedures that meet or exceed industry standards. The room containing the Entrust/Authority software is designated a two (2) person zone, and controls are used to prevent a person from being in the room alone. Alarm systems are used to notify security personnel of any violation of the rules for access to an Entrust SSL Web Server Certification Authority.

115

Entrust CAFrom: ENTRUST CPS

Procedural ControlsAn Entrust SSL Web Server Certification Authority has a number of trusted roles for sensitive operations of the Entrust SSL Web Server Certification Authority software. To gain access to the Entrust/Authority software used in an Entrust SSL Web Server Certification Authority, operational personnel must undergo background investigations. Entrust SSL Web Server Certification Authority operations related to adding administrative personnel or changing Certification Authority policy settings require more than one (1) person to perform the operation.

116

Entrust CA

From: ENTRUST CPS

Key Pair GenerationThe signing Key Pair for an Entrust SSL Web Server Certification Authority is created during the initial start up of the Entrust/Master Control application and is protected by the master key for such Entrust SSL Web Server Certification Authority. Hardware key generation is used which is compliant to at least FIPS 140-1 level 3.

117

Thawte CAFrom: Thawte CPS

Physical ControlsSite Location and Construction

thawte's Certificate and CRL signing systems are housed in secure facilities in Mountain View, California, USA that are protected by multiple tiers of physical security, video monitoring, and two factor authentication including biometrics. Online Cryptographic Signing Units (“CSUs”) are protected through the use of locked cabinets. Offline CSUsare protected through the use of locked safes, cabinets and containers. Access to CSUsand keying material is restricted in accordance with VeriSign and thawte’s segregation of duties requirements. The opening and closing of cabinets or containers in these tiers is logged for audit purposes. Progressively restrictive physical access privileges control access to each tier.

thawte's certificate management systems are housed in secure facilities in the United States that are protected by multiple tiers of physical security, video monitoring, and dual access.

thawte’s RA operations are conducted within thawte facilities on in the United States and in South Africa that are protected by multiple tiers of physical security including proximity badge access.

thawte also maintains disaster recovery facilities in the United States for its CA operations. thawte’s disaster recovery facilities are protected by multiple tiers ofphysical security comparable to those of thawte’s primary facilities.

118

FlexiTrust:

http://www.bundesnetzagentur.de/media/archive/1699.pdf

119


120

Certificate Management Authority

121

Ceritificate Management Authority

The certificate management authority or CMA is a PKI operating component assigned with the task of managing and administrating products of issuers on their behalf.

Offline CAdifficult administration.

RAout of its scope.

122

ArchivingDeliveryPublishingCertificate status information backendCRL managementRenewal notificationError HandlingMiscellaneous tasks

CMA tasks

123

Archiving

LDAP Server

Database

Filesystem

CMA

124

Archiving

Archiving of certificates and CRL

Persistent store (DB, LDAP, etc.)

No need to contact the KA

PSE archiving is supported

125

Delivery

126

Delivery

Delivery of

certificatesPSEsrevocation information

to end-entities.

127

Publishing

128

Publishing

In order to enable clients to search for and locate certificates and CRLs.

Different methods exist LDAP, HTTP, others…

Some certificates may not be published

129

Certificate status information backend

130

Support an OCSP server on providing correct and fresh revocation information.

Secure and trusted backend store isneeded

Provide this information on demand or in cache.

Certificate status information backend

131

CRL management

132

Push CRL serviceswhen a CRL is issued it is pushed to clients that have subscribed with these services.

KA is often offlineOperate as a revocation authority

issuing of indirect CRLs (the issuer of a certificate and the issuer of the CRL are different)

Immediate revocation is possible

CRL management

133

Renewal notificationCertificate renewal

automatic notification of its userautomatic before expiration (notification to KA or RA)

CRL renewalthe validity period of a CRL is shortautomatic regular renewal in order to have a valid CRL alwaysautomatic notification to RA or KAissuing of a new CRL by the CMA (if it is allowed to issue CRLs)

134

Error handling

If an error occurs an administrator is notified(e.g. by an email)

Possible reactions

repeat of a process (e.g. if a certificatecould not be issued, try this once again)

automatic revocation, for example thecertificate is correct but the PSE has a problem

135

Like:

Backup services

Validation services, etc.

Miscellaneous tasks

136

Key/Certificate life cycle and CMA Services

Initialization

Issued

Cancellation

RegistrationKey Pair GenerationCertificate Creation and Key/Certificate DistributionCertificate DisseminationKey Backup (if appropriate)




Legend:


137

Example of certification

KA CMARARequest

138

Example of revocation

RA KA CMARequest

Push

Certification Authority or Trust center · Verification of Applicant’s Legal Existence and...

Documents

Transcript of Certification Authority or Trust center · Verification of Applicant’s Legal Existence and...