Document Sample
Certificates Powered By Docstoc

Robin Burke
ECT 582
Last class

   Public key cryptography
       Solves what problem?
   New problem
       public key identity
Man-in-the-middle attack

 Eve intercepts all communications
 Masquerades as both Bob and Alice

 Bob thinks he has Alice's public key
       but he doesn't
   How can Bob know for sure?

   This issue highlights the problems of trust in
    the digital world
   A lot of infrastructure needs to be in place
       Digital certificates
       Multiple collaborating certification authorities
       Registration authorities
       Certificate directories
       Certificate revocation servers

   We can't trust
       the public key associated with a
   We might trust
       an authoritative source to vouch for
Trusted third party

 Certification authority (CA)
 CA can
     meet with Alice
     look at her driver's license / birth
      certificate / etc
     take her fingerprints
   CA will then
       sign her public key

   When Eve tries to substitute her
    public key for Alice's
     Bob will either notice that the key isn't
      certified, or
     Notice that it is certified but not for
      Alice, for someone else
Masquerading as CA?
   Eve could falsely issue a certificate
       and sign the certificate pretending to be the
   But
       the CA is a big institution
       strong interest in making its correct public
        key well known
   Multiple sources to access the CA's public
       Some public keys are actually bundled with
Public key certificate

 A public key
 An identifier
       whose key?
   The whole package signed by the CA
Benefits of certification

   Alice and Bob can exchange
    certificates directly
     no need for a separate way to
      communicate public keys
     certificate is self-protecting

   Many users can participate
       only need to know CA's public key

   Trust in the CA
       issuance policies
   Security of the CA's private key
       very important!!!
Multiple CAs

   If there is only one CA
       all is simple
   Multiple CAs
     Alice's public key is signed by C1
     Bob's public key is signed by C2

   How can Bob be confident?
       maybe C1 is really Eve in disguise

   Full distribution
       every user has the public key for every CA
       impractical
   Cross certification
       Suppose Alice presents Bob with C1's
         public key
       Signed by C2
       Bob can verify the certificate
       C1's public key can be trusted
       Therefore Alice's public key can be trusted
Hierarchical trust model
   Root CA
      a generally-trusted CA
         • Federal Reserve Bank
      all parties trust root
   Non-root CAs
      have certificates signed by root CA, or
      signed by another non-root CA
         • closer to the root CA
   Certification path
      the chain of certifications from the root to a particular
       public key certificate
   More about this next week
CA relationships
   Intra-organization communication
      Bank ATM network
      Organization can be its own CA
   Open communication
      CA is an independent entity
      third party CA
   The third party CA
      is like a notary public
      is evaluating the truth of a person's representation
      may be liable if due diligence is not performed

   Public key is not valid forever
       limits risk associated with key compromise
       1 year is typical
   Certificates have a valid period
       expired certificate may still be useful (non-
       new certificate issued when old one expires
         • Possibly the same key re-certified
Certificate assumptions

   During the valid period
     public key is valid for use
     association with identity assumed
     revocation notifications will be

   What if Eve hacks into Bob's
    computer and steals his private key?
       Alice will still be sending encrypted
        messages, but now Eve can read
   Certificate must be revoked
     can no longer be trusted
     new certificate issued
     how does Alice find this out?
Revoking a certificate

   Reasons for revocation
     Detected or suspected compromise
     Change of data
         • e.g. subject name
       Change of relationship between
        subject and CA
         • e.g. employee quitting a job from an
           organization which uses the current CA
Who can revoke?

   who revokes?
     the subject
     the CA
     an authorized third party
        • e.g. the organization with an employee
   Authentication of the source of revocation
    request is needed.
What happens?

 The CA determines that the
  revocation request is valid
 Then adds the certificate to its
  "certificate revocation list"
       CRL

   CRL is a time-stamped list of revoked
       digitally signed by the CA
       available to all users
   Each revoked cert is identified by a
    certificate serial number
   CRL contains digital signatures, thus can be
    sent via unprotected channels
   Users of public key certificates should
    check a suitably-recent CRL

   The user of a public key
       must check the CRL
       every time the key is used
       not enough to check when the certificate is
        originally accepted
   CA
       must keep a revoked certificate in the CRL
        until it expires
       list could get large
Suitably recent?

   Question of risk
       what is the risk associated with a
        possibly out-of-date CRL
   CRLs are distributed regularly
       e.g. hourly, daily, biweekly, etc
   “off-cycle” CRL can be issued
       how to detect missing off-cycle CRL?

   Eve steals Bob's private key
   Bob discovers break-in
       requests certificate revocation
   Eve sends a forged message to Alice
   Alice verifies message
       checks CRL
       no problems with Bob's public key
   CA publishes CRL with Bob's revocation
       too late
CRL Distribution

   Pull method
     CA periodically updates CRL
     users check when using a public key

   Push method
       broadcast new CRL when it changes
   Both subject to denial of service
Online status checking
   Online Certificate Status Protocol
   Alice checks Bob's public key directly with the CA
      most effective
      most costly
   Costs
      handling traffic for every public key use
      handling cryptographic operations at high speed
      maintaining high security in Internet environment
   Also subject to denial of service attack
Short-Lived Certificates

   Certificate valid for 1 day at a time
       re-requested each day
       possibly the same public key
   Revocation not necessary
       client stops asking for a new certificate
   Suitable for limited resource systems
       e.g. mobile wireless systems
   Assumes efficient certificate generation

          Who gets sued?
            depends on the timeline
            depends on legal framework

a. Issue of b. Key         d. Revocation
  CRL 1 Compromise             Time        e. Issue of CRL2

                     c. Revocation                            Time
Key pair management

   Public and private keys are generated
       Afterwards, different lives
   Private key
       some kind of secure storage
   Public key
       self-signed certificate
       certification
       then public distribution

   Local generation
     private key never leaves the
      environment where it is used
     required by ANSI security standards

   Central generation
       private key must be communicated to
Protecting the private key

   Smart card
       more secure but
       more expensive
       less portable
   Encrypted data file
       PGP's key ring
   Centralized
       credentials server
       digital wallet
Key pair management

   Public key functions
     encryption
     digital signature

   Different requirements

 Encrypted files and messages may be
  stored indefinitely
 If private key is lost
       the data is effectively garbage
   Private key may need to archived
       more or less permanently
     Key life cycle: encryption
Alice encrypts a message to Bob.
Will use public key if
       certificate is in valid period
       certificate not revoked

      Certificate validity:
       Public key usage:
      Private key usage:


   Key compromise extremely hazardous
     even for historical documents
     non-repudiation lost

 A lost signature key can always be
  replaced for signing the next
 Private key must be securely
     Key life cycle: signature
Alice validates a signed message from Bob.
Will use public key if
       valid period and
       certificate not revoked
Will keep public key for historical validation

           Cert validity:
            Cert usage:
      Public key usage:
     Private key usage:
Key life cycle: real-time
Alice installs software sold by Bob
Bob's signature verifies uncorrupted code
Will use software if
    certificate is valid at installation time
Private key may have short life

        Cert validity:
   Public key usage:
  Private key usage:

   Different constraints on signature vs
     encryption may be regulated
     different algorithms may be preferred

   DSA doesn't support encryption
       reason for development

   Multiple key pairs
     Encryption
     Signing

   PGP
       allows generation of either an
        encryption or signing key
Issuing a certificate

   Alice generates a key pair
     private key stored on hardware device
     public key self-signed

   Alice sends the self-signed public key
       to who?
   Possibly the CA
       more likely an intermediary for the CA
Registration authority

   An agent for the CA
       Deals with people
   Frees the CA
       to deal with bits
   May be internal to an organization
       even if CA is external
RA's responsibility
   Gets Alice's certificate request
      public key
   Verify Alice's identity
      testimonial
      email ping
      documents
      personal presence
      etc.
   Forward request to CA
   Handle all of Alice's other key management needs
      revocation
      expiry
      updated information
CA's responsibility

   Verification of identity
       or requisite trust in RA
 (Very) Secure signing operation
 Certificate returned to requestor
     possibly archived
     possibly made available to public

   Transaction recorded in audit journal
CA's key management

   CA keys have many uses
       signing (real-time validation)
       historical validation
   Short-use private keys
       better security
   But
       a signed certificate can't have a valid period
        beyond the signer's certificate
   CA will need multiple keys for different
Certificate distribution

   Alice sends Bob a two line signed email
       signature ≈ message size
       certificate > message size
         • Alice's public key + CA's signature
       certificate for each CA in certification path
   Certification info could easily be 10x the
    message size
   What if Bob already has Alice's public key?
Certificate + Signature

 Inefficient
 Not practical in network environment

 Different users might need different
  certification paths
       can't predict which certificates to
   Doesn't work for encryption
Directory services

 General case for public key discovery
 Online access to a directory
       request a public key certificate for a
        given user
   In this case
     Alice sends only the signed message
     Bob is responsible for getting Alice's
Directory services

   Proprietary
     Novell
     MS Active Directory
     Lotus Notes
   Older standard
       X.500
   Newer
       LDAP

   Developed by the international standards
   Extremely general
       look up by name
       browse available entities
       representing people, devices, applications,
   Extension for public key certificates
       X.509

 Useful subset of X.500
 Easier to implement than X.500

 Widely available
       Uses X.509 certificates

 A certificate is a data structure
 Typically communicated in a binary
       ASN.1
   If we were starting over today
     we'd use XML
     XML didn't exist in 1988
Certificate format
Certificate fields
   Version
      1,2,3 or 4
        3 is the most widely used
   Serial no
        assigned by CA
   Signature algorithm id
        for CA's signature
   CA id
   Subject id
   Subject algorithm id
   Public key
   Some other stuff
   CA's digital signature
   Many things need to be identified
      what algorithm?
      who is the CA?
      whose key are we signing?
   X.500 Names
      every unique individual
      must have a unique name
      hierarchical naming scheme
   X.500 Object Identifiers
      for things like algorithms
      also hierarchical
      but with integer components
Directory Information Tree

   Country
       C=US, Canada, Mexico, etc.
   Organization
       O=DePaul University, UIC, Northwestern
        University, etc.
   Organizational uint
       OU=CTI, LA&S, Commerce, Theater, etc.
   Common Name
       CN=Robin Burke, Yonghe Yan, etc.
Distinguished name

   A collection of choices at each level of
    the DIT
       leading to an individual
   Not necessarily a person
       printer, router, application, web server
   DN
       {C=US, O=DePaul University,
        OU=CTI, CN=Robin Burke}
Name collision

   Typically we augment the common
    name with some other identifier
     employee / student id
     email address
Object identifiers

   Problem
       different organization may want their own
       impossible to create a list of legal values in
   Like DIT tree
       but with integers
   Used to label
       algorithms
       certificate types

   1.2.840.113549.1.1.5
       this is a digital signature algorithm SHA-1
        from RSA Labs
   How do we know this?
       1 = ISO
       2 = Indicates a member of the organization
       840 = the USA
       113549 = RSA's organizational id
       RSA chooses the rest of the identifiers
Id tree

          0 (itu-t)             1 (iso)            2 (joint-iso-itu-t)

                                               16 (country)
                      2 (member-body)

                                                       840 (us)

                               840 (us)

                                              1 (organization)

                       113549 (rsadsi)
                                                   15678 (sharons)

                              1 (pkcs)

                         1 (pkcs-1)

                      5 (sha-1WithRASEncryption)

                 OID: 1.2.840.113549.1.1.5
X.509 Version 3

 Versions 1 and 2 of X.509 did not
  work well for public key management
 Problems
     multiple public keys per user
     additional required information for
      some purposes
     all certificates not created equal
X.509 Extensions

   Instead of fixing all the fields in v. 3
     an "extension mechanism"
     allow organizations to define their own
      certificate components
   Extensions
     must be registered (object identifier)
     criticality indicator
Standard extensions
   Authority key id
       CA's may have multiple signing keys
       helps to build certification path
   Key usage
       what the certified key is for
   Certificate policies
       under what policy was the certificate issued
       degree of authentication
   Path constraints
       what is a legal certification path from this
Version 3 naming

   Much more flexible naming scheme
       X.500 names OK
   Others
     email address
     domain name
     IP address
     URL
X.509 CRL format

   Similar to certificate itself
   Also
       date/time of issue of this CRL
       date/time of issue of next CRL
   List of revoked certs:
     user certificate: cert serial number
     revocation date
   CRL extensions
Java and X.509 Certificate

 Java provides a standard API for
  X.509 certificate version 3
 X509Certificate class is in
Java Certificate
   JRE provides a keystore of trusted
    certificate authorities
       It is in directory
   Access via "keytool"
       part of Java Development Kit

   Allows many certificate management
     create self-signed certificate
     import / export certificates
     generate Certificate Signing
      Requests, etc.

keytool -certreq -file
   Generates a certificate signing
     for your public key
     can send to CA to be turned into a

   Printing a certificate

Shared By: