Certificate Revocation : A Survey

Transcription

1 Certificate Revocation : A Survey Gaurav Jain Computer Science Department University of Pennsylvania. Abstract With the increasing acceptance of digital certificates, there has been a gaining impetus for methods to nullify the compromised digital certificates and enable the end user to receive this information before he trusts a revoked certificate. The problem of certificate revocation is getting more and more crucial with the development of wide spread PKIs. We discuss the need and importance of revocation and identify and discuss the options that may be considered by those undertaking to address the revocation of digital certificates. 1 Introduction In the last decade, as more and more security infrastructures have been developed, Public Key Infrastructures (PKI s) gained a considerable attention as they seem to hold a promising foundation for secure electronic commerce [3]. A wide use of PKI requires the ability to verify the authenticity of public keys of the other party. This is achieved through the use of certificates which act as a mean of transferring trust. A certificate is a message signed by a publicly trusted authority (the certification authority), whose public key authenticity may be provided by other means) which includes a public key and additional data, such as expiration date, serial number and information regarding the key and the subject entity. 1.1 Certificates Any data with a digital signature could be called a certificate. Certificates are tamperevident (modifying the data makes the signature invalid) and unforgeable (only the holder of the secret, signing key can produce the signature). These properties make certificates useful in conducting secure electronic transactions. Many different kinds of data can be signed. For example, a certificate may represent a binding (e.g., p Alice is the public key of Alice ), or it may indicate a permission (e.g., Alice has permission to use the printer ). In any case, the signer of the certificate, who is known as the issuing party, may wish to indicate a term of validity for the certificate. For instance, the certificate giving Alice permission to use the printer could be marked valid until the end of the semester. The relying party who examines a certificate must take this validity period into account: when deciding whether to let Alice print documents on the printer, the relying party should consider the certificate invalid if the semester is over, and deny access. 1.2 Revocation When a certificate is issued, its validity is limited by an expiration date. However, there are circumstances (such as when a private key is revealed, or when a key holder changes affiliation or position) where a certificate must be revoked prior to its expiration date. Thus, the existence of a certificate is a necessary but not sufficient evidence for its validity, and a mechanism for determining whether a certificate was jaing@saul.cis.upenn.edu 1

2 revoked is needed. Understanding revocation is an important business concern to service providers and well as the users of the authentication service and it has also be argued that the running expenses of a PKI derives mainly from administering revocation [12]. The revocation management needs to be clearly defined for the Certificate Authorities (CA) and users: CAs must provide a revocation service in a trustworthy manner and therefore, publish a proper security policy. A user needs to know how and when a revocation must be initiated and also gets informed. The revocation is initiated by the owner of the certificate (subject), by an authorized representative which is already mentioned in the certificate or by a CA. Only the CA revokes certificates and complies with a revocation request since the initiator is able to prove his authorization Revocation Requirements A revocation needs to be fast, efficient, timely and particularly appropriated for large infrastructures. Due to that, it is necessary e.g. to reduce the number of time-consuming calculations like verification processes of a digital signature and to apply other mechanisms, or to minimize the amount of data transmitted. It is also desirable that a method provides suspending a certificate temporarily (placed onhold) and also a reuse. A few criteria have been discussed in literature [9, 8, 13] to establish the metrics with which various revocation approaches can be analyzed. These include: Population Size- The absolute size of the number of potentially revocable certificates can strongly influence the approach taken. Extremes could be a closed community of twenty members to the entire Internet. A solution intended to address a large population may require more resources and complexity as compared to a smaller group. Acceptable Latency in Revocation - The degree of timeliness relates to the interval between when a CA made a record of the revocation and when it made the information available to the relying parties. A more eager mechanism to update and convey this information will proportionally consume more bandwidth. Moreover, if the interval is small, there might not be anything new to update and most (or all) of the bandwidth might be used for passing redundant information. Connectivity - Does the relying party need to be online in order to ascertain the reliability? Online mechanisms create mission critical components in the overall security design. This dimension of the problem can inform the designers of online mechanisms of the need to facilitate off line caching of prior data. Security Considerations - In a majority of cases, a certificate will expire without ever being have to be revoked. One of the most troubling scenario would be the compromise of the private key. Without an effective compromise, a security solution based on PKI is at a risk of general system compromise Revocation Classification Methods for revocation can be classified in different ways: By the way of checking - The check can be performed either offline or online, sometimes both methods are applied. Within an offline scheme, the validity information is precomputed by a CA and then distributed to the requester by an non-trusted directory. Within an online scheme, the status information is provided online by a trusted directory. A proof of validity is performed during each request and provides up-to-date information. By their kinds of lists - Negative (black) lists contain revoked certificates and positive (white) lists contribute valid certificates. Sometimes both mechanisms are combined. 2

3 By the way of providing evidence - A direct evidence is given if a certificate is mentioned in a positive or negative list, respectively. Then it is supposed to be not revoked or revoked, respectively. An indirect evidence is given, if a certificate can not be found on a list and therefore, the contrary is assumed. By the way of distributing information - either via a push (when the server periodically updates the client of the revocation) or pull mechanism (when the client ask the server for particular revocation information. 2 Understanding Revocation The problem of certificate revocation is deeper than it seems at the first glance. Consider a digital certificate C 1 issued to Alice which contains Alice s public key (p Alice ) and is signed by Issuer1. Suppose Alice has another digital certificate C 2 with the same public key (p Alice ) and issued by Issuer2, different from Issuer1. The problem arises if Issuer1 revokes the certificate C 1. It means that C 1 is no longer valid but says nothing about C 2 which contains and same identity and public keys as that of C 1. The problem could be resolved if the reason for revocation could be passed on along with the revocation information as discussed [1, 2]. Revocating C 1 could mean UNDO of any of the following: p Alice - which means that Alice s public key could not be trusted anymore as they have been compromised. p Alice Alice - the binding between Alice and her public keys have been compromised. Issuer1 binding on p Alice and Alice - the issuer could no longer vouch for the binding between the keys and the identity. Each of these cases means something different, and chain processing in the presence of revocation information acts differently in each case. Consider the first case above, where revocation of C 1 denotes compromise of the subject public key. In this case, the fact that C 1 is revoked should cause all other certificates that involve the subject public key p Alice to no longer be valid. So, not only is C 1 now invalid, but C 2 itself is also now invalid. Ideally, if any certificate for a given subject public key is revoked for reasons of key compromise, all such certificates would immediately be revoked, but obviously we cannot guarantee this behavior. Thus, it may be argued that relying parties have a duty to check revocation status on all certificates naming a particular subject public key even if they themselves are not relying on those certificates for chainbuilding. The second case, direct revocation of the subject namesubject public key binding by the issuer, is a fuzzier situation. As both the certificates C 1 and C 2 belong to Alice, the relying parties could reasonably choose to reject C 2 if they know C 1 is revoked (even though C 2 is not revoked explicitly). Finally, in the last we have revocation of certificate C 1 because the issuer of that certificate no longer has a relationship with the subject public key. Revocation here speaks not to the validity of the namekey binding but rather to a lack of contractual obligation. Revocation of C 1 should not in any way impact C 2 as there is no authorization statement from the issuer of C 2 concerning the validity of the subject public key p Alice itself. 2.1 Reason for Revocation The fact that the act of revoking a particular certificate needed to be qualified with intended semantics was recognized by the authors of the X.509 standard. In X.509 Version 2 Certificate Revocation Lists (CRLs), it is possible to include a reason code extension on each and every entry in the CRL. Reason codes are semantics modifiers and can specify situations such as: Key compromise CA compromise 3

4 Affiliation change (including subject name changes) Superseded Cessation of operation (the certificate is no longer needed for its original purpose) Thus, one could conceivably decide whether a particular revocation fell into cases (a) (c) above based on reason code, assuming one was present in the CRL and that each possible reason code could be assigned to a particular case. 3 Revocation Mechanics We next discuss the various methods suggested for the revocation. One common characteristic of each of the method is good synchronization with the revocation source either by online status checks or by frequently refreshed certificates. 3.1 Certificate Revocation List (CRL) Certificate revocation lists (CRL) together with X.509 certificates have been introduced in 1988 by ITU- T. The specifiations are now available as an RFC [3]. This is the most common and simplest method for certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time stamped list identifying revoked certificates which is signed by a CA and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (e.g., for verifying a remote user s digital signature), that system not only checks the certificate signature and validity but also acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of suitably-recent may vary with local policy, but it usually means the most recently-issued CRL. A CA issues a new CRL on a regular periodic basis (e.g., hourly, daily, or weekly). An entry is added to the CRL as part of the next update following notification of revocation. An entry may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked certificate s validity period. An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves, namely, via untrusted communications and server systems. One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until the next periodic CRL is issued this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs Delta CRL Since the validity period of certificates is long and the number of users is immense, CRLs can grow extremely large. Therefore, a great amount of data needs to be transmitted. The fact that a CRL is only up-to-date at their point of issuing led to the definition of so called delta-crls. A delta-crl is issued between two CRL updates. It includes only changes since the last issued CRL and so enhances the efficiency. Delta-CRLs contain sequence numbers that allow to verify the completeness of CRL information Partitioned CRL A first observation is that CRL s can be divided according to who might be interested in them. For instance, a single CRL distribution point could be partitioned into a family of CRL s representing different reasons for revocation, possibly issued at different rates. This might allow a short list of compromised keys to be issued with a short validity period while a longer list of some lowerpriority 4

5 revocations is updated less frequently. It also facilitates on demand retrieval of the CRL. For instance, only the CRL for people with names in a certain range may need to be retrieved to check a given certificate Can we do without CRL? Revocation is less likely to be needed if certificates have short validity periods. For example, if permission to use the printer was issued once week rather than once each semester, then on a lot less entries would need to appear on a CRL. If Alice s printer privileges were revoked during the third week, then the serial number for her certificate would only need to appear in a CRL until the end of the third week, and not until the end of the semester. After the first semester, the certificate would be rejected because of expiration anyway, so it does not need to be in a CRL. Carrying this to an extreme, if Alice was required to obtain a fresh certificate with a very short expiration period each time she went to the swimming pool, then the issuer could revoke her privileges very quickly simply by refusing to issue new certificates. Rivest [11] advocates this approach, and it clearly has advantages, e.g., the issuing party does not have to distribute CRL s and the relying party does not need to worry about CRL s going stale. However, there are also drawbacks. Most seriously, it requires Alice to do more work, and worse, it requires the issuer to sign many more certificates than the X.509 approach, potentially placing an unacceptable burden on certificate servers. Another problem is that it does not address the problem of key compromise, which is closely related to revocation; Rivest proposes a separate mechanism, suicide bureaus to handle key compromise. McDaniel and Rubin [6] study the advantages and disadvantages of the two approaches in more detail. 3.2 Certificate Revocation System (CRS) The certificate revocation system (CRS) [7, 10] has been introduced by Silvio Micali in His idea uses online/offline signatures. A CRS mixes positive and negative lists and thus, gives direct evidence. The validity status of each certificate is treated separately. Here, a user sending a query concerning the validity of a single certificate, will get a response containing an individual, short information about this certificate. Depending on the up-to-date-time schedule, the system can either operate online or offline. In the following, we point out the main concept of a CRS. The system is set up as follows: The CA defines n time intervals (e.g., with respect to a year n = 365 and increment i represents a day), within the CRS is periodically updated. Using X.509 certificates, the number of extension fields needs to be extended by two 100-bit fields called Y (for yes ) and N (for no ). Because of CA s signature, the authenticity of both values is guaranteed. The CA constitutes a proper hash function H and chooses (pseudo-)randomly two 100-bit values Y 0 and N 0, where both Y 0 and N 0 are kept secret by the CA. Then the CA calculates: Y Y n = H n (Y 0 ), N H(N 0 ) Value Y 0 is used within n computations but N 0 only once. To keep the CRS up-to-date the CA submits the following information to a directory: a fresh and timestamped list L containing all serial numbers of issued and not-yet-expired certificates, where L is signed by the CA. Also further information are transmitted: new certificates issued within interval i; a 100-bit value V for each certificate determined either by V Y n i = H n i (Y 0 ) if the certificate is neither expired nor revoked, or by V N 0 if the certificate has been revoked within interval i. For revoked certificates the CA may also provide a signed template including additional data like time and reason of revocation. Now, the directory stores the serial numbers of each certificate together with its dedicated value V. A user asking for the validity of a certificate first gains list L. Then he checks the soundness and correctness of the whole list L by verifying the signature. If this succeeds, he determines whether L contains the requested serial number. Further tests are performed by using Y or N. He calculates H i (V ) and examines whether H i (V ) equals Y. If this is true, the certificate is valid within the interval i. Otherwise, he computes H(V) and verifies whether H(V) is equal to N. If any verification succeeds, 5

6 the status of the certificate can determined. This works because Y = H i (H n i (Y 0 )) = H n (Y 0 ) and N = H(N 0 ). All other occurrences come from problems concerning e.g. data transmission, data authenticity or even denial of services. A CRS provides the following advantages: The signed list L is offered off-line. Because a hash function is used and both Y and N are represented by a string of 100 bits, the verification process of V is efficient and therefore, can be calculated online. The directory is not able to forge neither L nor V since Y 0 and N 0 is only known by the CA. Nevertheless, the security of CRS depends also on the secrecy of Y 0 and N 0, and also on their generation process. 3.3 Certificate Revocation Tree (CRT) Kocher [4] suggested the use of Certificate Revocation Trees (CRT) in order to enable the verifier of a certificate to get a short proof that the certificate was not revoked. A CRT is a hash tree with leaves corresponding to a set of statements about certificate serial number X issued by a CA, CA x.the set of statements is produced from the set of revoked certificates of every CA. It provides the information whether a certificate X is revoked or not (or whether its status is unknown to the CRT issuer). There are two types of statements: specifying ranges of unknown CAs, and, specifying certificates range of which only the lower certificate is revoked. For instance, if CA 1 revoked two certificates, X 1 < X 2, than one of the statements is: If CA x = CA 1 and X 1 X < X 2 then X is revoked iff X = v To produce the CRT, the CRT issuer builds a binary hash tree with leaves corresponding to the above statements. A proof for a certificate status is a path in the hash tree, from the root to the appropriate leaf (statement) specifying for each node on the path the values of its children. The main advantages of CRT over CRL are that the entire CRL is not needed for verifying a specific certificate and that a user may hold a succinct proof of the validity of his certificate. The main disadvantage of CRT is in the computational work needed to update the CRT. Any change in the set of revoked certificates may result in re-computation of the entire CRT. 3.4 Online Certificate Status Protocol (OCSP) On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL. On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts the report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. However, these methods impose new security requirements; the certificate validator shall trust the on-line validation service while the repository does not need to be trusted. One of the online method that is gaining popularity is the Online Certificate Status Protocol (OCSP) [5] developed by IETF. It specifies a protocol used to determine the current validity status of a certificate online. OCSP is designed for X.509 certificates but may also work with other kind of certificates. The protocol can be used instead of or even together with CRLs if more timely information about the status is required. Information about the way to obtain a certificates status can be included within the extension fields of a X.509-certificate. The protocol is applied between a client (OCSP requester, acting for the user) and a server (OCSP responder, representing a directory). The client generates a so called OCSP request that primary contains one ore even more identifiers of certificates queried, i.e. their serial number together with other data. Then, the (optionally signed) request is send to the server. The server receiving the OCSP request creates an OCSP response: Since all syntactical and content checks succeed, the response mainly includes a timestamp representing the time when the actual request is generated, furthermore, the identifiers and status values of the requested certificates together with a validity interval. A certificate status value is either set to good, revoked or unknown. Be aware that good implies three meanings: firstly, the certificate is not revoked, but secondly, it may also not be issued yet or even thirdly, the time at which the response is produced is not within the validity of the certificate. Status revoked stands for a revocation or onhold of the certificate. If the answer is unknown the server has no information available about 6

7 the required certificate. The validity interval specifies the time at which the status being indicated is known to be correct and optional the time at or before newer information will be available about the status of the certificate. The OCSP response should be digitally signed either by the server or by the CA. In case of any error the OCSP response contains an error message. The OCSP response is send to the requesting client of the user who then analyzes the data. Formats of request and response are due to the transmission protocol e.g. HTTP or LDAP. Depending on proper defined time schedules, OCSP provides more timely status information than any other method. A preproducing of signed responses is currently optional. OCSP is especially appropriated for attribute certificates where status information always need to be up-to-date. In the practice, the caching of HTTP-browsers must be handled carefully. 3.5 Trusted Directories For an intranet application, one approach to revoking certificates is to simply delete them from the enterprise directory. Such can be the case, for example, when an employee leaves a companythe employees account is deleted from the system, including any digital certificates. To the extent that applications are designed to check for certificates in the directory prior to relying on them, this enables an expedient solution to the revocation requirement. This approach has its cost though: the directory now becomes a prime target of attack, and must be protected with comprehensive security controls. Furthermore, with inter-enterprise PKI, it may not be practical to make the trusted directory available to external relying parties to acquire the necessary account information for privacy reasons. Therefore, the trusted directory approach is of limited utility. 4 Conclusion Regarding revocation of certificates different methods have been developed. Beside the presented methods, further methods exist. If and in which way a revocation method is suited must be analyzed in accordance to their purpose. An important aspect for a decision is its costs. High costs derive from a great amount of transmitted data that is needed to provide a proper revocation, but also from measures to provide the availability of timely data. Using offline systems, commonly the time period between two updates is long and therefore, the validity cannot be assured exactly. However, this is sufficient for the purpose of some applications. Online systems appropriated for purposes where more timely information is needed are obviously more expensive than an offline system. Another aspect is also whether a revocation method is applicatively for a storage equipment like smart cards or other security tokens. The knowledge about different revocation methods is not very widely spread. Efficient and practicable methods are still needed and a topic of today s research. A main requirement for new developments and new ideas is that they can easily be integrated in widely used X.509 certificates. References [1] Fox and LaMacchia. Certificate revocation: Mechanics and meaning. In FC: International Conference on Financial Cryptography. LNCS, Springer-Verlag, [2] Carl A. Gunter and Trevor Jim. Generalized certificate revocation. In Symposium on Principles of Programming Languages, pages , [3] R. Housley, W. Ford, W. Polk, and D. Solo. RFC 2459: Internet X.509 public key infrastructure certificate and CRL profile, January Status: PROPOSED STANDARD. [4] P. C. Kocher. On certificate revocation and validation. In FC: International Conference on Financial Cryptography. LNCS, Springer-Verlag,

8 [5] A. Malpani S. Galperin M. Myers, R. Ankney and C. Adams. RFC 2560: X.509 internet public key infrastructure online certificate status protocol - ocsp, June [6] Patrick McDaniel and Aviel D. Rubin. A response to can we eliminate certificate revocation lists?. In Financial Cryptography, pages , [7] S. Micali. Efficient certificate revocation. Technical Memo MIT/LCS/TM-542b, Massachusetts Institute of Technology, Laboratory for Computer Science, March [8] J. Millen and R. Wright. Certificate revocation the responsible way, [9] M. Myers. Revocation: Options and challenges. In Lecture Notes in Computer Science, volume 1465, pages , [10] Moni Naor and Kobbi Nissim. Certificate revocation and certificate update. In Proceedings 7th USENIX Security Symposium (San Antonio, Texas), Jan [11] Ronald L. Rivest. Can we eliminate certificate revocations lists? In Financial Cryptography, pages , [12] Stuart Stubblebine. Recent-secure authentication: Enforcing revocation in distributed systems. In Proceedings 1995 IEEE Symposium on Research in Security and Privacy, pages , May [13] Petra Wohlmacher. Digital certificates: a survey of revocation methods. In Proceedings of the 2000 ACM workshops on Multimedia, pages ACM Press,