Transcript Public Key Infrastructure

Internet Security 1 (IntSi1)
6 Public Key Infrastructure
Prof. Dr. Andreas Steffen
Institute for Internet Technologies and Applications (ITA)
Andreas Steffen, 17.10.2011, 6-PKI.pptx 1
Internet Security 1 (IntSi1)
6.1 Certificates
Andreas Steffen, 17.10.2011, 6-PKI.pptx 2
X.509 Certificate Structure
tbsCertificate
version (usually v3)
serialNumber
signature*
issuer
validity
subject
subjectPublicKeyInfo
issuerUniqueID OPTIONAL
subjectUniqueID OPTIONAL
extensions
OPTIONAL
signatureAlgorithm*
Hash Function*
Hash / Fingerprint
Encryption with
Issuer‘s Private Key*
signature
* specifies algorithm used to sign certificate, e.g. sha256withRSA
Andreas Steffen, 17.10.2011, 6-PKI.pptx 3
X.500 Distinguished Name (DN)
OpenSSL
C
ST
L
O
OU
CN
G
S
Email, E
•
•
•
RDN
Country
State or Province
Locality or Town
Organisation
Organisational Unit
Common Name
Given Name
Surname
Email (deprecated)
Microsoft
C
S
L
O
OU
CN
G
SN
E
Example
C= DE
ST= NRW
L= Essen
O= Kool AG
OU= Marketing
CN= Antje Huber
G= Antje
S = Huber
E = [email protected]
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.
Andreas Steffen, 17.10.2011, 6-PKI.pptx 4
X.509v3 subjectAltName
subjectAltName type
OpenSSL notation
IPsec ID type
ipAddress
IP:11.22.33.44
ID_IPV4_ADDR
dnsName
DNS:gateway.kool.net
ID_FQDN
rfc822Name
email:[email protected]
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.44
subjectAltName=email:[email protected],email:[email protected]
•
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.
Andreas Steffen, 17.10.2011, 6-PKI.pptx 5
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 into
4 base64-encoded PEM bytes, thus increasing the certificate file
size 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 symmetrically
encrypted by means of a secret passphrase.
Andreas Steffen, 17.10.2011, 6-PKI.pptx 6
Internet Security 1 (IntSi1)
6.2 Certification Authorities
Andreas Steffen, 17.10.2011, 6-PKI.pptx 7
Trust Models I
PGP Web of Trust
Alice
Trust
Bob
Signed by Bob
Signed by Alice
Certificate
Signed by Dave
Can Carol trust Alice ?
Carol
Trust
Trust
Dave
Signed by Dave
Signed by Bob
Certificate
Signed by Carol
Andreas Steffen, 17.10.2011, 6-PKI.pptx 8
Trust Models II
Trust Hierarchy with Certification Authorities
Verisign
Root CA
Self Signed
HSR CA
Self Signed
Amazon
Intermediate CA
Verisign
Trust
Bob
Alice
Amazon
Amazon
Client
Certificates
Carol
HSR CA
Andreas Steffen, 17.10.2011, 6-PKI.pptx 9
Certificate Registration Process
•
Certification Authority (CA)
• signs and issues the user certificate based
CA Key
Antje
on the user‘s certificate request and
the 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 certificate
request (CR) either to an intermediate RA
or directly to the CA.
#7
CA
Antje
OK
RA
Antje
CR
Antje
Antje‘s Key
Andreas Steffen, 17.10.2011, 6-PKI.pptx 10
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)
Andreas Steffen, 17.10.2011, 6-PKI.pptx 11
Trusted Root Certification Authorities
•
VeriSign
•
Thawte
•
TC Trustcenter
•
QuoVadis Trustlink – www.quovadis.ch
•
Swisscom Solutions - www.swissdigicert.ch
•
SwissSign / DiePost - www.swisssign.ch / postzertifikat.ch
–
www.verisign.com
• U.S.A., Microsoft scandal in 2001, used by postfinance.ch, zkb.ch
–
www.thawte.com
• South Africa, founded by Mark Shuttleworth, cheap
–
www.trustcenter.de
• Germany, qualified certificates, formerly used by webmail.hsr.ch
• Switzerland, qualified certificates, used by switch.ch, hsr.ch
• Switzerland, qualified certificates
• Switzerland, qualified / advanced certificates
Andreas Steffen, 17.10.2011, 6-PKI.pptx 12
Internet Security 1 (IntSi1)
6.3 Certificate Enrollment
Andreas Steffen, 17.10.2011, 6-PKI.pptx 13
SPKAC Certification Request via Browser
•
A „Signed Public Key And Challenge“ (SPKAC) is sent
via POST request to the CA‘s HTTP server.
Andreas Steffen, 17.10.2011, 6-PKI.pptx 14
PKCS #10 Certification Request
certificationRequestInfo
version (v1)
subject
subjectPKInfo
algorithm
subjectPublicKey
attributes
challengePassword
extensionReq
Hash Function*
Hash / Fingerprint
Encryption with
Requestor‘s Private Key*
signatureAlgorithm*
signature
* specifies algorithm used to sign certificate, e.g. sha256withRSA
Andreas Steffen, 17.10.2011, 6-PKI.pptx 15
Simple Certificate Enrollment Protocol (SCEP)
Requestor
PKCSReq
CA
PKCS #7 Envelope
PKCS #10 Request
CertRep, pkiStatus=PENDING
GetCertInitial
polling
CertRep, pkiStatus=PENDING
manual authentication
GetCertInitial
CertRep, pkiStatus=SUCCESS
polling
PKCS #7 Envelope
X.509 Certificate
Andreas Steffen, 17.10.2011, 6-PKI.pptx 16
Internet Security 1 (IntSi1)
6.4 Certificate Revocation
Andreas Steffen, 17.10.2011, 6-PKI.pptx 17
X.509 CRL Structure
version (v1 or v2)
signature*
issuer
lastUpdate
nextUpdate
revokedCertificates
SerialNumber
RevocationDate
crlEntryExtensions(v2)
SerialNumber
···
signatureAlgorithm*
Hash Function*
Hash / Fingerprint
Encryption with
Issuer‘s Private Key*
signature
* specifies algorithm used to sign certificate, e.g. sha256withRSA
Andreas Steffen, 17.10.2011, 6-PKI.pptx 18
CRL Deployment Scheme
#4 #5
0
1
2
3
#6 #7
4
5
6
7
8
9
10
11
12
13
14
days
CRL: 1,2,3
CRL: 1,2,3
CRL: 1,2,3,4,5
CRL: 1,2,3,4,5
CRL: 1...5,6
CRL: 1...6,7
CRL: 1...6,7
Andreas Steffen, 17.10.2011, 6-PKI.pptx 19
Delta CRLs
#4 #5
0
1
2
3
#6 #7
4
5
6
7
8
9
10
11
12
13
14
days
CRL: 1,2,3
Δ:
Δ: 4
Δ: 4,5
CRL: 1,2,3,4,5
Δ:
Δ: 6,7
Δ: 6,7
CRL: 1,2,3,4,5,6,7
Andreas Steffen, 17.10.2011, 6-PKI.pptx 20
X.509v3 CRL Distribution Points
•
•
•
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 =
URI:http://www.kool.net/ca/cert.crl
/* HTTP URI */
crlDistributionPoints =
/* LDAP URI */
URI:ldap://ldap.kool.net/o=Kool AG,c=CH
?certificateRevocationList?base
?(objectClass=certificationAuthority)
•
As an alternative to bulky CRL files, the Online Certificate Status
Protocol (OCSP) could be used to query the status of a certificate.
Andreas Steffen, 17.10.2011, 6-PKI.pptx 21
Online Certificate Status Protocol (OCSP)
with self-signed OCSP certificate
OCSP Server
Kool CA #0
frequent status updates e.g. via CRL
OCSP
Kool CA
OCSP Request:
status of Kool CA #2 ?
Kool CA
optionally signed by Bodo
Bodo
#3
OCSP Reply:
Kool CA #2 good
signed by OCSP Server
Kool CA
Antje
locally stored
#2
Antje
Bodo
OCSP
Kool CA
#0
OCSP
Antje
Authentication
Bodo
Andreas Steffen, 17.10.2011, 6-PKI.pptx 22
Online Certificate Status Protocol (OCSP)
with delegated trust
OCSP Server
Kool CA #0
frequent status updates e.g. via CRL
OCSP
Kool CA
OCSP Request:
status of Kool CA #2 ?
Kool CA
optionally signed by Bodo
Bodo
#3
OCSP Reply:
Kool CA #2 good
signed by OCSP Server
Kool CA
Antje
OCSP is #1
#2
Antje
OCSP
Bodo
Kool CA
Kool CA
Antje
Authentication
Bodo
Andreas Steffen, 17.10.2011, 6-PKI.pptx 23
Internet Security 1 (IntSi1)
6.5 Certificate Policies
Andreas Steffen, 17.10.2011, 6-PKI.pptx 24
basicConstraints – CA Flag
Kool CA #0
Kool CA
User CA #1
Kool CA
Antje
#1
User CA
Bodo
Root CA Certificate
CA:TRUE ; critical
Intermediate CA Certificate
CA:TRUE ; critical
End Entity Certificate
CA:FALSE
#1
Antje
Andreas Steffen, 17.10.2011, 6-PKI.pptx 25
basicConstraints – Path Length Constraint
Kool CA #0
Kool CA
User CA #1
Kool CA
Bob CA
Bob CA
Level 1 Intermediate CA Certificate
CA:TRUE ; critical
#1
Level 2 Intermediate CA Certificate
CA:TRUE ; critical
pathLenConstraint = 0
#1
Level 3 End Entity Certificate
CA:FALSE
User CA
Antje
Level 0 Root CA Certificate
CA:TRUE ; critical
pathLenConstraint = 1
Andreas Steffen, 17.10.2011, 6-PKI.pptx 26
keyUsage Extension
Root CA
certificateSign
crlSign
Kool CA #0
Kool CA
Host CA #1
User CA #2
Kool CA
Kool CA
Gateway #1
Antje
Host CA
User CA
#1
Bodo
User CA
Intermediate CA
certificateSign
crlSign
#2
End Entity Certificates
digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
Andreas Steffen, 17.10.2011, 6-PKI.pptx 27
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
Andreas Steffen, 17.10.2011, 6-PKI.pptx 28