Revocation methods by 387GGT


									Revocation methods

   Daniele Mazzocchi
CNSG-Politecnico di Torino
part of the presentation is based
 on material prepared by Diana
 Berbecaru and Marius Mariun
  CNSG-Politecnico di Torino
        Revocation Methods
 Digital signature are usually verified
  using public-key certificate (PKC)
 So the question: how you can verify a
  PKC ? depends on the existence of a
  hierarchical PKI or not
     If the PKC certificate is self-signed: you
      have to directly trust it (no other method)
      (e.g., PGP)
     If PKI exists, the PKC is signed by a
      certification authority (CA): you need the
      pkc’s CA
       PKI and Revocation
 For the ca’s PKC you have again the
  problem of validation (typical chicken-
  and-egg problem), you need another
 ...But every PKC has his own validity.
  What happens if one certificate must be
  considered invalid before the expiration
  date ? (e.g., Private key compromise)
Need for a revocation method
   we need a method to revoke the validity
    of a certificate. Requirements:
     timeliness
     complexity
     security
Survey of revocation methods
   CRL (Certificate Revocation List)
       CRLDP, Indirect CRL, dynamic CRLDP,
 Windowed revocation
 Authenticated Data Structures
       Certificate Update Scheme
   skip list
 off-line mechanism
 CRL = list of revoked certificates (e.g.,
  SNs) digitally signed by a revocation
  authority (not necessarily the CA that
  issued the revoked PKC)
     commonly CRL are directly issued by the
     periodically issued (1 day, 1 week, 1
      month: thisUpdate, nextUpdate)
           Pros & Cons of CRL
   Pros
     simplicity
     no need for trusted channel for distributing
   Cons
     timeliness (issuing on periodical basis):
      “window of vulnerability”
     CRL could be huge
     distribution of CRL
Variation on CRL: Indirect CRL
   the issuer is not same as CA but a
    revocation authority (TTP)
     possible to aggregate multiple CRLs from
      different CAs in one
     verifier can avoid requesting different CRLs
      from different sources
     problem: trusting the TTP
   partitioning CRL into smaller pieces
    based on various criteria (structure of
    the company, reason for revocation):
    CRLDP is a pointer (e.g., URI) in the
     smaller CRLs
     more complexity (more CRLs to check)
                  Dynamic CRLDP
 CRLDP doesn’t point to the actual CRL
  but a redirect CRL
 avoid static partitioning

                     redirect CRL   actual CRL

                  Delta CRL
 simple variation
 starting point: a base CRL
 distribution of delta CRL which contains
  the changes occurred
 delta CRL are smaller
       can be issued more frequently
     Windowed revocation
 use of certificate caching
 revocation info in the CRL only as long
  as necessary
 concept of revocation window:
  maximum admitted caching time of the
 concept of implicit revocation: if you can
  retrieve the certificate, it is valid at
  retrieval time
               issuing time
               of following CRL

                                     lifetime of the PKC

                                     minimum time of inclusion
                                     with traditional CRL
                 revocation window

   issuing times for the CRL
TR revocation time
        What is OCSP?
 OCSP = Online Certificate Status Protocol
  (RFC 2560) - June 1999
 in lieu of or as a supplement to checking
  against a periodic CRL, it may be
  necessary to get timely information on the
  revocation status of a certificate
 OCSP may be used to satisfy some
  operational requirements of providing more
  timely revocation information than is
  possible with CRLs (e.g., stock trades,
  funds transfer)
                    OCSP players
                                            1. Cert request

  End entity 2.


   6. Transaction response        5. OCSP response / Error message

                             End entity              4. OCSP request
3. Transaction +             (‘buyer’)
OCSP definitive response
 definitive as in authoritative and serving to
  provide a final solution at one moment!
 all definitive responses must be digitally
     either  by the CA that issued the certificate
     or by a Trusted Responder (the OCSP client
      trusts the TR’s public key)
     or by a CA designated responder (Authorized
      Responder) - it has a specially marked
      certificate issued by the CA saying that it can
      issue OCSP responses on CA’s behalf
Responses for each certificate
   such responses have the following
     target certificate identifier
     certificate status value
         good  - positive answer
         revoked - permanently / temporarily (on-hold)
         unknown - the responder doesn’t know about
          the certificate being requested
     response validity interval
     optional extensions
         Special Timing Fields
   the responses contain three timestamp:
     thisUpdate - time at which the status being
      indicated is known to be correct
     nextUpdate - time at or before which newer
      information will be available
     producedAt - time at which the OCSP
      responder signed this response. Useful for
      response pre-production
             OCSP responders
   authorized responders
     signing key of the responder need not to be the
      CA key
     authority delegation is reflected in the extension
      extendedKeyUsage (id-kp-OCSPsigning)
   revocation checking of an authorized OCSP
    responder. CAs may provide these solutions:
     id-pkix-ocsp-nocheck extension
     CRL distribution points / Authority Information
     no method specified
        Security Considerations
 on-line method
 DoS vulnerability
     flood of queries + production of signatures!
     unsigned responses ----> false responses
     pre-production of responses offer some
      margin against DoS
   pre-computed responses allow replay
    attacks (no nonce included)
       but the OCSP signing key can be kept off-
              Open questions
   Consistency between CRL and OCSP
       possible to have a certificate with two
        different statuses. How is handled such a
 If OCSP is more timely and provides the
  same information as CRLs do we still
  need CRLs?
 Which method should come first -
  priority to OCSP or to CRL?
     Some implementations
 Netscape PSM (Personal Security
  Manager) includes an OCSPclient
 OpenSSL 0.9.7 will offer support for
 Valicert
 Computer Associates
Certificate Revocation System
 proposed by Micali (1996)
 aimed to improve CRL communication
 basic idea: signing a message for every
  certificate stating its status
 use of off-line/on-line signature scheme
  to reduce update cost
    CSR: creation of a certificate
 Two new parameters included in the
  certificate: Y365 and N
 these parameters are obtained from two
  pseudo-random number:
       Y365 =f365(Y0) N=f(N0) where f is a one-way
   f must be one-way on its iterates
              How CSR scheme works
                        daily update Uk
                        for each certificate Ck
         CA                                       Directory

-if still valid Uk =Y365-i=f 365-i(Y0)
-if revoked Uk =N0

NOTE: i=0 in the
issuance date

        On-line/Off-line scheme
 the certifcate contains the public key
  and the two values Y365 and N
 Y365 can be considered as another
     with this public-key you can verify at most
      365 signatures...
     ...but these are no-computationally
      expensive signature (e.g. computable on-
   the only expensive signature is the one
    in the PKC (e.g. computed off-line)
             General scheme
 with an ordinary signature you sign off-
  line an information which acts as the
  public-key for another scheme
 this second is a fast one-time signature
       when you have to sign an actual message
        you use the one-time scheme
        Certificate revocation tree
 proposed by Kocher (1998)
 based oh hash tree
     hash tree are not new: proposed by Merkle in
      another context in 1979 (one-time signature)
     improvement for Lamport-Diffie signature scheme
     based on the following idea: if I want to sign a bit
      of information I give to someone the image (y) of
      produced by applying a one-way function F to x
     eventually I reveal the pre-image x s.t. y=F(x)
            Kocher proposal
 express ranges of SN of certificates (5 to
  12) means: 5 is revoked, the others larger
  than 5 and smaller than 12 are good. Put
  the hash of these ranges in the leaves
 the response includes the corresponding
  tree leaf, the necessary hash values along
  the path to the root, the signed root
 the CA periodically updates the structure
  and distributes it trough untrusted servers
  called Confirmation Issuers
                     Example of CRT
                                            N0,0         A0 (- to 7)
  query: Is 67
  revoked?                         N1,0   SHA
                                            N0,1         A1 (7 to 23)
                      N2,0   SHA                   SHA
                                            N0,2         A2 (23 to 27)
                                   N1,1   SHA
  Signed                                    N0,3         A3 (27 to 37)
root (N 3,0)   SHA
                                            N0,4         A4 (37 to 49)
                                   N1,2   SHA
                                            N0,5         A5 (49 to 54)
                      N2,1   SHA
                                            N0,6         A6 (54 to 88)
                               N1,3       SHA
                                            N0,7         A7 (88 to +)
     Characteristics of CRT
 the response could be used as a proof
 the length of the proof is O(log n)
 there is only a digital signature for tree
  root (could be done off-line)
Authenticated Data Structures
 proposed by Naor and Nissim (1998)
 suggested as an improvement of CRT
       O(log n) burden for search but with more
        efficient update scheme
   based on a data structure known as 2-3
       introduced by Hopcroft (1970)
    Authenticated dictionary
  data structure representing a set of
  elements supporting authenticated
  membership queries and update
 use of hash trees
 to have better performance use 2-3 tree
                2-3 trees (1)
   two properties:
     each interior node has two or three children
     each path from the root to a leaf has the
      same length
 all elements are ordered by some linear
  order <
 elements are placed in the leaves
 if a is to the left of b then a<b
                      2-3 trees (2)
   at each interior node:
     record the smallest element that is descendant
      of 2nd child
     if there is 3rd child record also the smallest
      element that is descendant from that child
             Binary                   2-3 tree
                6                     3   5

         4        7
                              2   -   4   -           6 7
     2        5

1        3                1       2   3       4   5    6    7
 if k levels then 2k-1n of leaves  3k-1
 for n elements at least 1+log3n and no
  more than 1+log2n levels
 test membership in O(log n)
 insertion/deletion requires only changes
  on the search path
    Use of 2-3 trees for revocation
 the root is digitally signed
 each leaf stores a revoked certificate SN
 the value of an internal node i = hash
  function (values of its children)
 update the structure
     delete each expired certificate SN (updating
      the nodes on the deletion path)
     insert newly revoked certificate SN (updating
      the nodes on the insertion path)
       Response to queries
 if the certificate SNx is revoked, for each
  node on the path from root to leaf SNx
  the directory supplies its value and its
  children values
 if SNx is valid, directory supplies the
  paths to two neighboring leaves l1 ,l2
  s.t. l1< SNx<l2
      Other possible uses
 use of the same structure for short-term
  certificates (e.g. issued daily) which
  doesn’t require revocation scheme
 the idea is CA performs a simple
  computation (e.g. only necessary
  updates) and sends a common update
 this message permits the users to prove
  the validity of their certificates
        Certificate update scheme
 the users get an initial certificate from CA
 the certificates are updated with the
  messages sent from the CA
       the path is used to prove the certificate validity
 CA updates its copy of the tree and
  publishes the changes
 user with non-revoked certificate locates the
  lowest node v, on a path that coincides with
  his path, and copies the new values from v
  up to the root (update of the path)
 another way of implementing efficiently an
  authentication dictionary
 proposed by Goodrich and Tamassia (2000)
 skip-list introduced by Pugh in 1990
 same performance of 2-3 tree with an easier
  (?) to implement/manage data structure
 use of commutative hashing
             Commutative hashing
   considered hash function h with two
    arguments h(x,y)
       digest for the pair <x,y>
 possible to extend the use to larger
  h(x1,x2,...xm)=h(x1,h(x2,...h(xm-2,h(x m-1,xm))...))
 required commutative function: h(x,y)=h(y,x)
 candidate construction
       h(x,y)=f(min{x,y},max{x,y})
                Skip-list search
S5   -                                             +
          v8         v7
S4   -         17                                  +
                     v6             v5
S3   -         17             25                   +
S2   -         17             25              55   +
S1   -    12   17             25        38    55   +
S0   -    12   17    20       25        38    55   +
    Autheticated Dictionary from
              Skip List
 a collection of values f(v) computed
  accumulating the element of the SL
  using the hash function
 a statement containg f(Start point) and a
  timestamp signed by the authority
 the bottom list contains the serial
  number of the revoked certificate Cr
 if revoked the reply consists of a path
  from S to Cr (with hash computation)
 if still valid the reply consists of two
  paths from S to two consecutive
  revoked certificate S1 ed S2 s.t.
method   space update       update query       query      verify
               time         info   time        info       time
CRL      O(n)      O(n)     O(n)    O(n)       O(n)       O(n)

Micali   O(N)      O(N)     O(N)    O(N)       O(1)       O(t)

Naor     O(n)      O(log n) O(1)    O(log n) O(log n) O(log n)
Skip List O(n)     O(log n) O(1)    O(log n) O(log n) O(log n)

 n: revoked PKCs       N: issued PKCs      t: updates since creation
 “A certified digital signature” R.C.Merkle
 “On Certificate Revocation and
  Validation”, P.C. Kocher
 “Efficient Certificate Revocation”
 “On-line/Off-line Digital Signature”
  S.Even,O.Goldreich, S.Micali
 “Certificate Revocation and Certificate
  Update” M.Naor, K. Nissim

To top