1 / 28

Internet Security 1 ( IntSi1 )

Internet Security 1 ( IntSi1 ). 6 Public Key Infrastructure. Prof. Dr. Andreas Steffen Institute for Internet Technologies and Applications (ITA). Internet Security 1 ( IntSi1 ). 6.1 Certificates. X.509 Certificate Structure.

shaman
Download Presentation

Internet Security 1 ( IntSi1 )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Internet Security 1 (IntSi1) 6 Public Key Infrastructure Prof. Dr. Andreas SteffenInstitute for Internet Technologies andApplications (ITA)

  2. Internet Security 1 (IntSi1) 6.1 Certificates

  3. X.509 Certificate Structure tbsCertificate version (usually v3) serialNumber signature* issuer validity subject subjectPublicKeyInfo issuerUniqueID OPTIONAL subjectUniqueID OPTIONAL extensions OPTIONAL Hash Function* Hash / Fingerprint Encryption withIssuer‘s Private Key* signatureAlgorithm* signature * specifiesalgorithmused to signcertificate, e.g. sha256withRSA

  4. OpenSSL RDN Microsoft Example C Country C C= DE ST State or Province S ST= NRW L Locality or Town L L= Essen O Organisation O O= Kool AG OU Organisational Unit OU OU= Marketing CN Common Name CN CN= Antje Huber G Given Name G G= Antje S Surname SN S = Huber Email, E Email (deprecated) E E = antje@kool.net 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.

  5. 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:antje@kool.net ID_USER_FQDN 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. • 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:antje@kool.net,email:antje@kool.de

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

  7. Internet Security 1 (IntSi1) 6.2 CertificationAuthorities

  8. Trust Models IPGP Web of Trust Alice Bob Trust Signed by Bob Signed by Alice Signed by Dave Certificate Can Carol trust Alice ? Trust Carol Dave Trust Signed by Dave Signed by Bob Signed by Carol Certificate

  9. Trust Models IITrust Hierarchy with Certification Authorities Verisign HSR CA Root CA Self Signed Self Signed Amazon Intermediate CA Verisign Trust Bob Alice Carol ClientCertificates Amazon Amazon HSR CA

  10. CA Key Antje Antje Antje OK CR #7 RA Antje CA Antje‘s Key Certificate Registration Process • Certification Authority (CA) • signs and issues the user certificate basedon the user‘s certificate request andthe clearance provided by the RA. • Registration Authority (RA) • verifies the certificate request against theuser‘s identity based on official documents(ID or passport) and personal appearance. • User • Generates an RSA key pair and sends thepublic key embedded in a certificaterequest (CR) either to an intermediate RAor directly to the CA.

  11. 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)

  12. Trusted Root Certification Authorities • VeriSign–www.verisign.com • U.S.A., Microsoft scandal in 2001, usedbypostfinance.ch, zkb.ch • Thawte–www.thawte.com • South Africa, foundedby Mark Shuttleworth, cheap • TC Trustcenter – www.trustcenter.de • Germany, qualifiedcertificates, formerlyusedbywebmail.hsr.ch • QuoVadis Trustlink – www.quovadis.ch • Switzerland, qualifiedcertificates, usedbyswitch.ch, hsr.ch • Swisscom Solutions - www.swissdigicert.ch • Switzerland, qualifiedcertificates • SwissSign / DiePost - www.swisssign.ch / postzertifikat.ch • Switzerland, qualified / advancedcertificates

  13. Internet Security 1 (IntSi1) 6.3 CertificateEnrollment

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

  15. PKCS #10 Certification Request certificationRequestInfoversion (v1)subjectsubjectPKInfo algorithm subjectPublicKey attributes challengePassword extensionReq Hash Function* Hash / Fingerprint Encryption withRequestor‘s Private Key* signatureAlgorithm* signature * specifiesalgorithmused to signcertificate, e.g. sha256withRSA

  16. PKCSReq PKCS #7 Envelope PKCS #10 Request CertRep, pkiStatus=PENDING GetCertInitial polling CertRep, pkiStatus=PENDING manual authentication GetCertInitial polling CertRep, pkiStatus=SUCCESS PKCS #7 Envelope X.509 Certificate Simple Certificate Enrollment Protocol (SCEP) CA Requestor

  17. Internet Security 1 (IntSi1) 6.4 CertificateRevocation

  18. Hash Function* Hash / Fingerprint Encryption withIssuer‘s Private Key* signatureAlgorithm* signature * specifiesalgorithmused to signcertificate, e.g. sha256withRSA X.509 CRL Structure version (v1 or v2)signature*issuerlastUpdatenextUpdaterevokedCertificates SerialNumber RevocationDate crlEntryExtensions(v2) SerialNumber· · ·

  19. #4 #5 #6 #7 CRL Deployment Scheme 0 1 2 3 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

  20. #4 #5 #6 #7 Delta CRLs 0 1 2 3 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

  21. 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): • As an alternative to bulky CRL files, the Online Certificate Status Protocol (OCSP) could be used to query the status of a certificate. crlDistributionPoints = /* HTTP URI */ URI:http://www.kool.net/ca/cert.crl crlDistributionPoints =/* LDAP URI */ URI:ldap://ldap.kool.net/o=Kool AG,c=CH ?certificateRevocationList?base ?(objectClass=certificationAuthority)

  22. frequent status updates e.g. via CRL Kool CA OCSP Antje Bodo OCSP Request:status of Kool CA #2 ?optionally signed by Bodo OCSP Reply:Kool CA #2 goodsigned by OCSP Server locally stored OCSP Antje Bodo Kool CA #2 #0 #0 #3 Kool CA Kool CA Kool CA OCSP Authentication Online Certificate Status Protocol (OCSP)with self-signed OCSP certificate OCSP Server Antje Bodo

  23. frequent status updates e.g. via CRL Kool CA OCSP Antje Bodo OCSP Request:status of Kool CA #2 ?optionally signed by Bodo OCSP Reply:Kool CA #2 goodsigned by OCSP Server isOCSP OCSP Kool CA Bodo Antje #2 #3 #0 #1 Kool CA Kool CA Kool CA Kool CA Authentication Online Certificate Status Protocol (OCSP)with delegated trust OCSP Server Antje Bodo

  24. Internet Security 1 (IntSi1) 6.5 CertificatePolicies

  25. Root CA CertificateCA:TRUE ; critical Intermediate CA CertificateCA:TRUE ; critical End Entity CertificateCA:FALSE Antje Bodo #1 #1 Kool CA User CA #0 #1 User CA Antje Kool CA Kool CA basicConstraints – CA Flag

  26. Bob CA Antje #1 #1 User CA Kool CA #0 #1 Bob CA User CA Kool CA Kool CA basicConstraints– PathLengthConstraint Level 0RootCA CertificateCA:TRUE ; criticalpathLenConstraint = 1 Level 1IntermediateCA Certificate CA:TRUE ; critical Level 2IntermediateCA CertificateCA:TRUE ; criticalpathLenConstraint = 0 Level 3 End EntityCertificateCA:FALSE

  27. Gateway #1 Antje #1 Bodo #2 Kool CA Host CA User CA #2 #1 #0 Host CA User CA User CA Kool CA Kool CA Kool CA keyUsage Extension Root CAcertificateSigncrlSign Intermediate CAcertificateSigncrlSign End Entity CertificatesdigitalSignaturenonRepudiationkeyEnciphermentdataEnciphermentkeyAgreement

  28. Extended Key Usage (EKU) • serverAuth TLS Web serverauthentication • clientAuth TLS Web clientauthentication • codeSigningSigning of downloadable executable code • emailProtectionE-mailprotection • timeStampingAuthorized to timestampdocuments/messages • ocspSigningAuthorized to sign OCSP responses

More Related