Docstoc

Certificates

Document Sample
Certificates Powered By Docstoc
					Certificates

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?
Complex

   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
Trust

   We can't trust
       the public key associated with a
        message
   We might trust
       an authoritative source to vouch for
        Alice
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
Man-in-the-middle?

   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
        CA
   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
    key
       Some public keys are actually bundled with
        IE
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
Issues

   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
Solutions

   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
Validity

   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-
        repudiation)
       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
      correct
     revocation notifications will be
      published
Revocation

   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
          quitting
   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

   CRL is a time-stamped list of revoked
    certificates,
       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
Note

   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?
Example

   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
      depository
     users check when using a public key

   Push method
       broadcast new CRL when it changes
   Both subject to denial of service
    attacks
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
       Liability

          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
                        Request
Key pair management

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

   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
        user
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
Encryption

 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
                                 Encryption

      Certificate validity:
       Public key usage:
      Private key usage:

                                        Decryption
Signature

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

 A lost signature key can always be
  replaced for signing the next
  document
 Private key must be securely
  destroyed
     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:
                                        Validation
                              Signing
Key life cycle: real-time
validation
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

                                      Install
        Cert validity:
   Public key usage:
  Private key usage:
                              Sign
Also

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

   DSA doesn't support encryption
       reason for development
Solution

   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
    purposes
Break
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
        include
   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
      certificate
Directory services

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

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

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

 Widely available
       Uses X.509 certificates
X.509

 A certificate is a data structure
 Typically communicated in a binary
  format
       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
IDs
   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
        "objects"
       impossible to create a list of legal values in
        advance
   Like DIT tree
       but with integers
   Used to label
       algorithms
       certificate types
Example

   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
        certificate
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.security.cert
Java Certificate
Management
   JRE provides a keystore of trusted
    certificate authorities
       It is in directory
        $JREHOME/lib/security/cacerts
   Access via "keytool"
       part of Java Development Kit
Keytool

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

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

   Printing a certificate

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:10/8/2011
language:English
pages:72