coen 351
DESCRIPTION
COEN 351. Certificates, PKI, X509 Standard. Certificates. Key distribution Crucial for authentication, privacy, signing, … Public Key Technology can use Certificates Certificate Authority ( CA ) generates certificates: Certificate = (Name, Public Key) signed by CA - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/1.jpg)
COEN 351
Certificates, PKI, X509 Standard
![Page 2: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/2.jpg)
Certificates
Key distribution Crucial for authentication, privacy,
signing, … Public Key Technology can use
Certificates Certificate Authority (CA) generates
certificates: Certificate = (Name, Public Key)signed by CA
All nodes need to be preconfigured with public key by CA.
![Page 3: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/3.jpg)
Certificate Authority vs.
Key Distribution Center
CA in contrast to KDC: CA does not need to be online. CA not a distributed computing entity.
Simpler, hence more secure. CA crash merely prevents setting up new users. Certificates are not security sensitive. They can be
stored anywhere with universal read privileges. Deleting a certificate would disable the use of the
public key. A compromised CA cannot read conversations, fake
conversations, … However, it can issue bogus certificates.
CA more secure, more convenient than KDC.
![Page 4: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/4.jpg)
Certificate Revocation
A certificate guarantees a public key. But public keys become unusable if the
corresponding private key is stolen. Certificates should not be eternal
They need an expiration date. CA needs to be able to revoke a public
key.
![Page 5: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/5.jpg)
Certificate Structure
Certificate includes: User’s name User’s public key Expiration time Serial number of certificate CA name Issuing CA’s signature on the entire
contents of the certificate.
![Page 6: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/6.jpg)
Certificate Revocation
Certificate Revocation List (CRL) Published periodically by each CA. Lists serial numbers of certificates
that should not be honored. CRLs have issue time.
![Page 7: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/7.jpg)
Certificate Revocation Push or Pull model
Pull: Users access CRL remotely. Push: Broadcast CRL.
Needs reliable distribution mechanism. Needs small CRL.
US DoD Multi-level Information System Security Initiative (MISSI) developed a PKI for the Defense Messaging System.
Used CRL broadcasting only for revocation caused by key compromises.
Reliable access to all participants.
![Page 8: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/8.jpg)
Certificate Revocation
Make certificate revocation unnecessary by handing out only short-lived certificates.
![Page 9: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/9.jpg)
Certificate Revocation Lists
CRLs CRLs can be very large. Publish mostly only a -list.
-list can be very short, often empty. Users update their private copy of the
CRL. From time to time, publish a full list,
or give one only to new users.
![Page 10: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/10.jpg)
Certificate Revocation Lists
First Valid Certificate Goal: Allow to compress CRLs. Certificates have no expiration date. CRL contains a first valid certificate
field. All certificates with a serial number
lower than the valid certificate field are invalid.
![Page 11: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/11.jpg)
Certificate Revocation Lists On-Line Revocation Service (OLRS)
System can be queried over the net whether a certificate is invalid.
If unavailable, Alice can choose to accept certificates on trust.
OLRS certificates OLRS can issue a certificate stating:
“Bob’s certificate is valid as of 6:05 GMT, January 20, 2005.”
![Page 12: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/12.jpg)
Certificate Revocation Lists Good Lists vs. Bad Lists
Good lists are much bigger. Good list publishes all licenses.
Hence, good list contains hashes of certificates. Good lists solve one security problem:
A CA employee can issue a bogus certificate off the books, possibly reusing a valid serial number.
The bogus certificate cannot be put on the bad list, but the good list can be audited.
![Page 13: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/13.jpg)
Certification Paths Alice wants to communicate with Bob:
Bob has a certificate from Cristal. Alice does not know Cristal. Therefore, Alice needs a certificate of
Crystal’s public key. Crystal has a certificate from Dan. Alice does not know Dan. Therefore Alice needs a certificate of Dan’s
public key. …
![Page 14: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/14.jpg)
Trust Anchors
Alice needs to trust someone in the certificate chain.
Alice Bob Crystal Dan
EveFredMicrosoft
![Page 15: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/15.jpg)
Certificate Authorities
Organization might have its own Certificate Authority.
Independent Certificate Authorities are like notaries: Trusted. Disinterested. Attesting to designated facts.
![Page 16: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/16.jpg)
Public Key Infrastructure
PKI consists of the components necessary to securely distribute public keys. Certification Authorities Repository for retrieving certificates Method of revoking certificates Method of evaluation a chain of
certificates
![Page 17: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/17.jpg)
Public Key Infrastructure Issuer: signs certificate with name and
key. Subject: name contained in a certificate. Target: The name in the name-key
association that someone wants to trust. Verifier / Relying Party: Evaluator of a
chain of certificates. Principal: Anyone with a public key. Trust Anchor: public key that someone
has decided to always trust.
![Page 18: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/18.jpg)
PKI Trust Models
Monopoly: There is one single CA in the world.
Vatican, US government, UN, Microsoft, Sun, Verisign, Chief rabbinate, …
The key of the universal trust anchor could never be changed without causing mayhem.
CA needs to verify every-one.
![Page 19: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/19.jpg)
PKI Trust Model Monopoly + Registration Authorities
(RA) Monopolistic CA chooses RAs all over
the world. RA authenticate and issue certificates
accordingly. RA receive a certificate signed by the
CA. In principle, a CA could check on what a RA
does, but in general, they just rubber-stamp.
![Page 20: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/20.jpg)
PKI Trust Model
Monopoly + Delegated CA Monopolistic CA issues certificates
to other CAs. Vouching for keys and vouching for
trustworthiness. CAs issue their own certificates.
![Page 21: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/21.jpg)
PKI Trust Model Oligarchy
Allow for some / many root CAs
Used in web browsers.
Any wrongdoing at any of these CAs can cause serious trouble.
![Page 22: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/22.jpg)
PKI Trust Model
Verisign once certified Microsoft fraudulently.
![Page 23: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/23.jpg)
PKI Trust Model
Anarchy Used by PGP Users configure trust anchors, use
rules on when to trust, … Everyone can issue certificates.
![Page 24: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/24.jpg)
PKI Trust Model
Name constraints Use internet name space. CA only trusted within a certain
domain. SCU CA to be trusted with certifying
SCU students, but not to be trusted with [email protected].
![Page 25: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/25.jpg)
PKI Trust Model
Top-Down with name constraints Monopolistic: there is one root key. CAs responsible for their namespace.
root
.com .gov .edu .fr .uk .de
.ucsc.edu .scu.edu
.coen
![Page 26: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/26.jpg)
PKI Trust Model
Bottom up with name constraints SCU can set up their own CA. So can UCSC. Eventually, they want to cross-link. Business opportunity to provide
cross-link certification service, but business subject to competition.
![Page 27: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/27.jpg)
Certificate Policies
Certificates can spell policies that limit the use of the certificate.
![Page 28: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/28.jpg)
Certification Storage
With Issuer With Subject In a certificate repository.
Choice depends on the PKI model.
![Page 29: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/29.jpg)
Certificate Generation
Creation of public / private key. Subject authentication
![Page 30: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/30.jpg)
Certificate Distribution
Certificate can Accompany signature Distributed via web services
![Page 31: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/31.jpg)
X.509 Certificate FormatX.509 Version Number
Serial Number
Signature Algorithm Identifier
Issuer (X.500 Name)
Validity Period (Start – Expiration dates / times)
Subject (X.500 Name)
Subject Public Key Information: Algorithm Identifier, Public Key Value
Issuer Unique Identifier
Subject Unique IdentifierCA Digital Signature
![Page 32: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/32.jpg)
X.500 Names
X.500 Name in Adobe Acrobat Digital Signature
![Page 33: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/33.jpg)
X.500 Names
Root
USA
CA = US
Santa Clara University
O = Santa Clara University
Department of Computer Engineering
OU = Department of Computer Engineering
Thomas Schwarz, S.J.
CN = Thomas Schwarz, S.J.
Attributes:Telephon = 551-6064email = tjschwarz @scu.edutitle = Associate Professor
DN = {C=US, O=Santa Clara University, OU = Department of Computer Engineering, CN = Thomas Schwarz, S.J.}
![Page 34: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/34.jpg)
X.500 Names X.500 directory consists of a set of entries. Each entry is associated with one real-
world object. Person Device Organization
Each object has a distinguished name (DN).
Entry also has a set of attributes.
![Page 35: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/35.jpg)
X.500 Names Entries logically organized in a directory tree.
Directory Information Tree (DIT) Entries have attributes. Each link in the directory tree is labeled by an
attribute type and a relative distinguished name (RDN).
C ~ Country O ~ Organization OU ~ Organizational Unit CN ~ Common Name
Distinguished names are formed by concatenating the labels on the way from root to the object.
![Page 36: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/36.jpg)
X.500 Names
Root
USA
CA = US
Santa Clara University
O = Santa Clara University
Department of Computer Engineering
OU = Department of Computer Engineering
Thomas Schwarz, S.J.
CN = Thomas Schwarz, S.J.
Attributes:Telephon = 551-6064email = tjschwarz @scu.edutitle = Associate Professor
DN = {C=US, O=Santa Clara University, OU = Department of Computer Engineering, CN = Thomas Schwarz, S.J.}
![Page 37: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/37.jpg)
X.500 Names X.500 names are unique, but can be
reused. I leave SCU, and ten years later they hire
another Thomas Schwarz, S.J. Unlikely in my case, more likely for John Smith.
This can be resolved by using two attributes as labels:
CN = Thomas Schwarz, S.J. EN = 000023812 This is the reason why X.509 uses unique
identifiers. Even though they are difficult to administer.
![Page 38: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/38.jpg)
X.509 Certificate FormatX.509 Version Number
Serial Number
Signature Algorithm Identifier
Issuer (X.500 Name)
Validity Period (Start – Expiration dates / times)
Subject (X.500 Name)
Subject Public Key Information: Algorithm Identifier, Public Key Value
Issuer Unique Identifier
Subject Unique IdentifierCA Digital Signature
![Page 39: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/39.jpg)
X.509 Certificate Format X.509 uses identifiers for the methods
used to form Issuer signature, Certified public key.
These methods are objects that need to be registered.
Objects have unique names, based on the Abstract Syntax Notation 1 Standard.
![Page 40: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/40.jpg)
ASN.1 Based on hierarchical structure. Top level uses integer values:
0 ITU-use 1 ISO use 2 joint ITU-ISO use.
Second level depends on first level for different standards administered by the unit. Under 2, 16 specifies country. Under 2, 16, 840 specifies US.
![Page 41: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/41.jpg)
ASN.1 Based on hierarchical structure. Top level uses integer values:
0 ITU-use 1 ISO use 2 joint ITU-ISO use.
Second level depends on first level for different standards administered by the unit. Under 2, 16 specifies country. Under 2, 16, 840 specifies US.
![Page 42: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/42.jpg)
ASN.1
0 1 2
16 (country)
840 (USA)
1 (Organization)
1589932 SCU
35 COEN
1 Algorithms
1 SuperSchwarz1
Object-Identifier:
{joint-iso-itu-t (2) country (16) us (840) organization (1) SCU (1589932) COEN (35) Algorithms (1) SuperSchwarz1 (1) }
![Page 43: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/43.jpg)
ASN.1
It can happen that the same object gets different names. The lower ranks of the tree are not
administered centrally.
![Page 44: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/44.jpg)
X.509 Certificate Format Naming is a problem.
S/MIME uses X.509 certificates. Needs to associate certificates with
email addresses. Insists that the name contains a
component [email protected]. Only reads this component.
Later versions require to put email address under SUBJECTALTNAME.
![Page 45: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/45.jpg)
X.509 Certificate Format
Naming is a problem. SSL has a similar problem. URLs use the DNS system, not X.500
Some browsers give up, just check whether the certificate is validly signed!
Others insist that CN portion contains the DNS name.
![Page 46: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/46.jpg)
X.509 Certificate Format
Naming is a problem. X.509 directory service largely non-
existent. DNS exists.
![Page 47: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/47.jpg)
X.509 Certificate Format
X.509 Version 3: Single subject needs various public
keys and hence various certificates. Application-specific naming Certificates have different levels of
security, hence different levels of trust.
![Page 48: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/48.jpg)
X.509 Certificate Format
X.509 Version 3: Adds an extension field.
Extension field can contain various entries.
![Page 49: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/49.jpg)
X.509 v.3 Certificate Format
X.509 Version Number = 3
Serial Number
Signature Algorithm Identifier
Issuer (X.500 Name)
Validity Period (Start – Expiration dates / times)
Subject (X.500 Name)
Subject Public Key Information: Algorithm Identifier, Public Key Value
Issuer Unique Identifier
Subject Unique Identifier
ExtensionsCA Digital Signature
Extension Type Criticality Extension Field ValueExtension Type Criticality Extension Field ValueExtension Type Criticality Extension Field ValueExtension Type Criticality Extension Field Value
![Page 50: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/50.jpg)
X.509 v.3 Certificate Format
Naming no longer restricted to X.500 naming system.
![Page 51: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/51.jpg)
X.509 v.3 Certificate Format
New set of standard extensions. Key information. Policy information. Subject and issuer attributes. Certification path constraints. Extensions related to CRLs.
![Page 52: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/52.jpg)
PKIX Working group established by IETF in 1994. PKIX recommended extensions:
AuthorityKeyIdentifier SubjectKeyIdentifier KeyUsage PrivateKeyUsagePeriod CertificatePolicies PolicyMappings SubjectAltName
![Page 53: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/53.jpg)
PKIX PKIX recommended extensions:
IssuerAltName SubjectDirectoryAttribute BasicConstraints NameConstraints PolicyConstraints ExtendedKeyUsage CRLDistributionPoints InhibitAnyPolicy FreshestCRL AuthorityInfoAccess SubjectInfoAccess
![Page 54: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/54.jpg)
PKIX CRL CRL entry contains
Signature Issuer ThisUpdate (time CRL was issued.) NextUpdate UserCertificate
RevocationDate CRLEntryExtensions CRLExtensions
AlgorithmIdentifier Encrypted
Repeats for each entry.
![Page 55: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/55.jpg)
PKIX Online Certification Status Protocol
Implements online status checking for certificates. Real-time status checks. But data is valid for a validity window.
![Page 56: COEN 351](https://reader036.vdocuments.site/reader036/viewer/2022062518/568145b9550346895db2c25a/html5/thumbnails/56.jpg)
Other Standards
PBP standard WAP WTLS
Replaces ASN.1 names with simpler ones.
DNSSEC A type of a certificate for DNS
environment only. SPKI (Simple PKI) RFC 2693,