Internet Security 1 ( IntSi1 )

Andreas Steffen, 17.10.2011, 6-PKI.pptx 1

Internet Security 1 (IntSi1)

Prof. Dr. Andreas Steffen

Institute for Internet Technologies and Applications (ITA)

6 Public Key Infrastructure



6.1 Certificates


X.509 Certificate Structure

* specifies algorithm used to sign certificate, e.g. sha256withRSA

signatureAlgorithm*

Hash Function*

Hash / Fingerprint

Encryption withIssuer‘s Private Key*

signature

tbsCertificate version (usually v3) serialNumber signature* issuer validity subject subjectPublicKeyInfo issuerUniqueID OPTIONAL subjectUniqueID OPTIONAL extensions OPTIONAL


X.500 Distinguished Name (DN)

• The subject and issuer certificate fields both contain a DN.

• A DN consists of a variable number of Relative DNs (RDNs).

• Use of special characters (ä, ö, ü, @, #, etc.) in a DN might lead to interoperability problems due to ambiguous ASN.1 encoding.

CSTL

Country State or Province Locality or Town

O OrganisationOU Organisational UnitCN Common NameG Given NameS SurnameEmail, E Email (deprecated)

CSLOOUCNGSNE

OpenSSL Microsoft RDN C= DE ST= NRW L= Essen O= Kool AG OU= Marketing CN= Antje Huber G= Antje S = Huber E = [email protected]

Example


X.509v3 subjectAltName

• Email addresses should be coded as subjectAltNames of type rfc822Name (Thunderbird and Outlook mail readers support this). The use of email RDNs in the subject DN is strongly deprecated.

ipAddress

DNS:gateway.kool.net

subjectAltName type OpenSSL notation IP:11.22.33.44

email:[email protected]

dnsName

rfc822Name

IPsec ID typeID_IPV4_ADDR

ID_FQDN

ID_USER_FQDN

• A X.509v3 certificate extension can contain an unlimited number of subjectAltNames. Example in OpenSSL notation:

subjectAltName=DNS:gateway.kool.net,IP:11.22.33.44subjectAltName=email:[email protected],email:[email protected]


Certificate Formats (DER/PEM/PKCS#12)

• Binary DER Format (*.der, *.cer)0x30 0x82 0x04 0xb1 0x30 0x82 0x03 0x99...0xDC 0x0D 0x34 0xD6 0x0C

• Base64 PEM Format (*.pem, *.crt, *.cer)-----BEGIN CERTIFICATE-----MIIEsTCCA5mgAwIBAgIBITANBgkqhkiG9w0BAQQFA...3A001gw=-----END CERTIFICATE-----

• Via a lookup table 3 binary-encoded DER bytes are converted into4 base64-encoded PEM bytes, thus increasing the certificate filesize by about 30%.

• PKCS #12 Transport Container (*.p12, *.pfx)• Private Key• User or Host Certificate• Root CA certificate plus any Intermediate CA certificate in

the chain.• In order to protect the private key, the PKCS#12 file is

symmetricallyencrypted by means of a secret passphrase.



6.2 Certification Authorities


Trust Models IPGP Web of Trust

Alice Bob

Carol Dave

Signed by Dave

Signed by Bob

Signed by Dave

Signed by Carol

Signed by Alice

Signed by Bob

Can Carol trust Alice ?

Trust

Trust

Trust

Certificate

Certificate


Trust Models IITrust Hierarchy with Certification Authorities

Verisign HSR CA

Amazon

Carol

Self Signed

Verisign

Self Signed

HSR CA

Alice

Amazon

Bob

Amazon

Root CA

Intermediate CA

ClientCertificates

Trust


Certificate Registration Process

• Certification Authority (CA)• signs and issues the user certificate based

on the user‘s certificate request andthe clearance provided by the RA.

• Registration Authority (RA)• verifies the certificate request against the

user‘s identity based on official documents(ID or passport) and personal appearance.

• User• Generates an RSA key pair and sends the

public key embedded in a certificaterequest (CR) either to an intermediate RAor directly to the CA.

Antje

RA

OK

Antje

Antje

CR

Antje‘s Key

Antje

CA

#7CA Key


Certificate Classes• Class 0

• Demo certificates for testing. No authentication whatever required.Usually expire after 30 days.

• Class 1• Ascertain that a given e-mail address exists and that the

owner of the respective public key has access to it. Low-level identity check.

• Class 2• Designed for companies and thus a personal identification is

not necessary. A copy of proof of the register of companies to establish persons authorised to sign and a written request will suffice.

• Class 3• Apart from the verification of the e-mail address also a

personal identification of a person on the basis of an ID or passport required.For companies, personal presence of authorized person required.

• Class 4• Identification process must take place at the site of an

official registration authority (state or community office)


Trusted Root Certification Authorities

• VeriSign – www.verisign.com• U.S.A., Microsoft scandal in 2001, used by postfinance.ch,

zkb.ch• Thawte – www.thawte.com

• South Africa, founded by Mark Shuttleworth, cheap • TC Trustcenter – www.trustcenter.de

• Germany, qualified certificates, formerly used by webmail.hsr.ch

• QuoVadis Trustlink – www.quovadis.ch• Switzerland, qualified certificates, used by switch.ch, hsr.ch

• Swisscom Solutions - www.swissdigicert.ch• Switzerland, qualified certificates

• SwissSign / DiePost - www.swisssign.ch / postzertifikat.ch• Switzerland, qualified / advanced certificates



6.3 Certificate Enrollment


SPKAC Certification Request via Browser

• A „Signed Public Key And Challenge“ (SPKAC) is sentvia POST request to the CA‘s HTTP server.


PKCS #10 Certification Request


signatureAlgorithm*

Hash Function*

Hash / Fingerprint

Encryption withRequestor‘s Private Key*

signature

certificationRequestInfoversion (v1)subjectsubjectPKInfo algorithm subjectPublicKey attributes challengePassword extensionReq


Simple Certificate Enrollment Protocol (SCEP)

Requestor CA

PKCS #10 Request

PKCSReq

PKCS #7 Envelope

CertRep, pkiStatus=PENDING

CertRep, pkiStatus=SUCCESS

X.509 CertificatePKCS #7 Envelope

CertRep, pkiStatus=PENDINGGetCertInitial polling

GetCertInitial polling

manual authentication



6.4 Certificate Revocation


X.509 CRL Structure


signatureAlgorithm*

Hash Function*

Hash / Fingerprint

Encryption withIssuer‘s Private Key*

signature

version (v1 or v2)signature*issuerlastUpdatenextUpdaterevokedCertificates SerialNumber RevocationDate crlEntryExtensions(v2) SerialNumber · · ·


CRL Deployment Scheme

CRL: 1,2,3CRL: 1,2,3

CRL: 1,2,3,4,5CRL: 1,2,3,4,5

CRL: 1...5,6CRL: 1...6,7

0 1 2 3 4 5 6 7 8 9 1011 12 13 14days

#4#

5#

6#

7

CRL: 1...6,7


Delta CRLs

0 1 2 3

CRL: 1,2,3

4 5 6 7

Δ:

8 9 1011 12 13 14days

Δ: 4Δ: 4,5

CRL: 1,2,3,4,5Δ:

Δ: 6,7Δ: 6,7

#4#

5#

6#

7

CRL: 1,2,3,4,5,6,7


X.509v3 CRL Distribution Points

• As an alternative to bulky CRL files, the Online Certificate Status Protocol (OCSP) could be used to query the status of a certificate.

• Users are admitted on the basis of a valid X.509 certificate.• In order to lock out a user, the corresponding certificate

must be revoked and the CRL made quickly available to all VPN end points.

• The X.509v3 certificate extension field crlDistributionPoints can define one or several Uniform Resource Identifiers (URIs):crlDistributionPoints = /* HTTP URI */ URI:http://www.kool.net/ca/cert.crlcrlDistributionPoints = /* LDAP URI */ URI:ldap://ldap.kool.net/o=Kool AG,c=CH ?certificateRevocationList?base ?(objectClass=certificationAuthority)


Antje Bodo

Kool CA

Kool CA

#0

Online Certificate Status Protocol (OCSP)with self-signed OCSP certificate

OCSP Server

OCSP Reply:Kool CA #2 good

signed by OCSP Server

OCSP

Kool CA

Bodo

OCSP Request:status of Kool CA #2 ?optionally signed by Bodo

Bodo

Kool CA

#3

frequent status updates e.g. via CRL

AntjeAntje

Kool CA

#2

Authentication

OCSP

OCSP

#0locally stored


Antje Bodo

Kool CA

Kool CA

#0

Online Certificate Status Protocol (OCSP)with delegated trust

OCSP Server

OCSP

Kool CA

Bodo

OCSP Request:status of Kool CA #2 ?optionally signed by Bodo

Bodo

Kool CA

#3

frequent status updates e.g. via CRL

AntjeAntje

Kool CA

#2

Authentication

OCSP Reply:Kool CA #2 good

signed by OCSP Server

OCSP

Kool CA

#1isOCSP



6.5 Certificate Policies


Kool CA

Kool CA

#0 Root CA CertificateCA:TRUE ; critical

basicConstraints – CA Flag

Intermediate CA CertificateCA:TRUE ; critical

User CA

Kool CA

#1

End Entity CertificateCA:FALSE

Antje

User CA

#1

Bodo

Antje

#1


Bob CA

User CA

#1 Level 2 Intermediate CA Certificate

CA:TRUE ; criticalpathLenConstraint = 0

Antje

Bob CA

#1 Level 3 End Entity CertificateCA:FALSE

Kool CA

Kool CA

#0 Level 0 Root CA Certificate

CA:TRUE ; critical pathLenConstraint =

1

basicConstraints – Path Length Constraint

Level 1 Intermediate CA Certificate CA:TRUE ; critical

User CA

Kool CA

#1


Kool CA

Kool CA

#0 Root CAcertificateSigncrlSign

Intermediate CAcertificateSigncrlSign

End Entity CertificatesdigitalSignaturenonRepudiationkeyEnciphermentdataEnciphermentkeyAgreement

Host CA

Kool CA

#1 User CA

Kool CA

#2

Gateway

Host CA

#1 Antje

User CA

#1 Bodo

User CA

#2

keyUsage Extension


Extended Key Usage (EKU)

• serverAuth TLS Web server authentication• clientAuth TLS Web client authentication• codeSigning Signing of downloadable executable

code • emailProtection E-mail protection• timeStamping Authorized to timestamp

documents/messages• ocspSigning Authorized to sign OCSP responses

Internet Security 1 ( IntSi1 )

Documents