Certificate-Based Encryption and the Certificate Revocation Problem

Transcription

1 Certificate-Based Encryption and the Certificate Revocation Problem Craig Gentry DoCoMo USA Labs Abstract. We introduce the notion of certificate-based encryption. In this model, a certificate or, more generally, a signature acts not only as a certificate but also as a decryption key. To decrypt a message, a keyholder needs both its secret key and an up-to-date certificate from its CA (or a signature from an authorizer). Certificate-based encryption combines the best aspects of identity-based encryption (implicit certification) and public key encryption (no escrow). We demonstrate how certificate-based encryption can be used to construct an efficient PKI requiring less infrastructure than previous proposals, including Micali s Novomodo, Naor-Nissim and Aiello-Lodha-Ostrovsky. 1 Introduction A (digital) certificate is a signature by a trusted certificate authority (CA) that securely binds together several quantities. Typically, these quantities include at least the name of a user U and its public key PK. Often, the CA includes a serial number SN (to simplify its management of the certificates), as well as the certificate s issue date D 1 and expiration date D 2. By issuing Sig CA (U, P K, SN, D 1,D 2 ), the CA basically attests to its belief that PK is (and will be) user U s authentic public key from the current date D 1 to the future date D 2. Since CAs cannot tell the future, circumstances may require a certificate to be revoked before its intended expiration date. For example, if a user accidentally reveals its secret key or an attacker actively compromises it, the user itself may request revocation of its certificate. Alternatively, the user s company may request revocation if the user leaves the company or changes position and is no longer entitled to use the key. If a certificate is revocable, then third parties cannot rely on that certificate unless the CA distributes certificate status information indicating whether the certificate is currently valid. This certificate status information must be fresh e.g., to within a day. Moreover, it must be widely distributed (to all relying parties). Distributing large amounts of fresh certification information is the certificate revocation problem. Solving this problem seems to require a lot of infrastructure, and the apparent need for this infrastructure is often cited as a reason against widespread implementation of public-key cryptography. E. Biham (Ed.): EUROCRYPT 2003, LNCS 2656, pp , c International Association for Cryptologic Research 2003

2 Certificate-Based Encryption and the Certificate Revocation Problem Some Previous Solutions to the Certificate Revocation Problem The most well-known and a very inefficient public-key infrastructure (PKI) proposal is the certificate revocation list (CRL). A CRL is simply a list of certificates that have been revoked before their intended expiration date. The CA issues this list periodically, together with its signature. Since the CA will likely revoke many of its certificates say, 10% if they are issued with an intended validity period of one year [15] the CRL will be quite long if the CA has many clients. Nonetheless, the complete list must be transmitted to any party that wants to perform a certificate status check. There are refinements to this approach, such as delta CRLs that list only those certificates that have been revoked since the CA s last update, but the transmission costs, and the infrastructural costs necessary to enable the transmission, are still quite high. Another proposal is called the Online Certificate Status Protocol (OCSP). The CA responds to a certificate status query by generating (online) a fresh signature on the certificate s current status. This reduces transmission costs to a single signature per query, but it substantially increases computation costs. It also decreases security: if the CA is centralized, it becomes highly vulnerable to denial-of-service (DoS) attacks; if it is distributed and each server has its own secret key, then compromising any server compromises the entire system [15]. A much more promising line of research, which has not received enough attention from industry, was initiated by Micali [14], [15]. (See also [16], [1], [12].) Similar to previous PKI proposals, Micali s Novomodo system involves a CA, one or more directories (to distribute the certification information), and the users. However, it achieves better efficiency than CRLs and OCSP, without sacrifices in security. Micali s basic scheme (slightly oversimplified) is as follows. For each client, the CA chooses a random 160-bit value X 0 and repeatedly applies a public oneway hash function to it to obtain the 160-bit value X n, where X i = H(X i 1 ). 1 The CA includes X n in the client s certificate: Sig CA (U, P K, SN, D 1,D 2,X n ). If U s certificate is still valid on the ith day after issuance, the CA sends the value of X n i to the directories; otherwise, it does not. In the former case, third party T can verify that U s certificate is still valid by querying a directory, and then checking that H i (X n i )(i times) equals X n, the value embedded in U s certificate. The advantage of Novomodo over a CRL-based system is that a directory s response to a certificate status query is concise just 160 bits (if T has cached Sig CA (U,...,X n )). The length of a CRL, on the other hand, grows with the number of certificates that have been revoked. Novomodo has several advantages over OCSP. First, since hashing is computationally cheaper than signing, the CA s computational load in Novomodo is typically much lower. Second, unlike the distributed components of an OCSP CA, the directories in Novomodo need not be trusted. Instead of producing signatures that are relied on by third parties, 1 For example, the one-way hash may be SHA1, and n may equal 365 if the intended validity period of a certificate is one year and we want a freshness of one day.

3 274 C. Gentry the directories merely distribute hash preimages sent by the CA (which they cannot produce on their own). Third, the lack of online computation by the directories makes Novomodo less susceptible to DoS attacks. Finally, although OCSP already has fairly low directory-to-user communication (one constantlength signature per query), Novomodo s is typically even lower, since public-key signatures are typically longer than 160 bits. Following Micali s proposal, Naor-Nissim [16] and Aiello-Lodha-Ostrovsky [1] proposed different hash-based systems with different computation and communication tradeoffs. Essentially, both of these proposals use binary trees to reduce the CA s computation even further, as well as to reduce CA-directory communication. 1.2 The Problem with Third-Party Queries Novomodo and related proposals are improvements over CRLs and OCSP. However, the infrastructural requirements of these approaches can vary dramatically, depending on how users use their keys. Suppose that users keys are used only to generate and verify signatures (never to encrypt and decrypt). In this case, we do not need any infrastructure to deal with third-party queries i.e., queries by one party on a different party s certificate status. Why not? because a signer can simply send its proof of certificate status to the verifier simultaneously with its signature. In other words, when a protocol allows a client to furnish its certificate status, no third-party queries are necessary. We only need infrastructure that allows each client to obtain its own proof of certification. However, the situation may be different if users use their keys for encryption and decryption. In this case, third party T must obtain U s certification status before sending an encrypted message to U. Getting this information directly from U may not be an option in high-latency applications like (where U might not respond promptly), or in applications where it is preferable to avoid the extra round trip. Conceivably, T could obtain U s certificate status from some other source perhaps a server affiliated with U but not with the CA but this seems ad hoc, and it still requires an extra round trip. Novomodo and related proposals would address this situation by allowing T to make a third-party query. We would like to eliminate, or at least strongly disincentivize, third-party queries for several reasons. First, since third party queries can come from anywhere and concern any client, every certificate server in the system must be able to ascertain the certificate status of every client in the system. The situation is much cleaner if third-party queries are eliminated. Each server only needs to have certification proofs for the clients that it serves. Moreover, these proofs could be pushed to clients, and multicast might be used to dramatically reduce the CA s transmission costs. Second, third party queries multiply the query processing costs of the CA and/or its servers. For example, suppose each client queries the certification status of 10 other clients per day. Then, the system must process 10N queries (where N is the number of clients), rather than just N (if each client only retrieves its own daily proof of certification). Third, nonclient queries are undesirable from a business model perspective: if T is not a client

4 Certificate-Based Encryption and the Certificate Revocation Problem 275 of U s CA, what incentive does the CA have to give T fresh certificate status information? Finally, there is a security consideration: if the CA must respond to queries from nonclients, it becomes more susceptible to DoS attacks. In summary, eliminating third-party queries allows a CA to reduce its infrastructural costs, simplify its business model and enhance security. So, how can we eliminate third-party queries without constraining how users use their keys? We will use an approach based on implicit certification 2 i.e., where T, without obtaining explicit information other than U s public key and the parameters of U s CA, can encrypt its message to U so that U can decrypt only if it is currently certified. 3 This will allow us to enjoy the infrastructural benefits of eliminating third-party queries, regardless of how users use their keys. 1.3 Identity-Based Encryption One way to achieve implicit certification in the encryption context is identitybased encryption (IBE). Shamir [18] originated the concept of identity-based cryptography in 1984, describing an identity-based signature scheme in the same article. However, fully practical IBE schemes have been discovered only recently. We briefly review IBE below. An IBE scheme uses a trusted third party called a Private Key Generator (PKG). To set up, the PKG generates a master secret s, and it publishes certain system parameters params that include a public key that masks s. The PKG may have many clients. Each client has some ID, which is simply a string that identifies it e.g., the client s address. The main algorithms in IBE are as follows. 1. Private key generation: For a given string ID, PKG uses (s, params, ID) to compute the corresponding private key d ID. 2. Encryption: Sender uses (params, ID, M) to compute C, ciphertext for M. 3. Decryption: Client uses (params, d ID, C) to recover M. Notice that a client s public key, ID, can be arbitrary, but standardizing its format allows senders to guess the client s public key rather than obtain it from the client or a directory. Revocation is handled by including the DATE (for example) as part of ID, so that keys expire after one day. Notice also that the PKG generates the private keys of all of its clients. This has several consequences. The most important, for our purposes, is that certification is implicit: a client can decrypt only if the PKG has given a private key to it (in effect, certifying the client). However, there are two negative consequences: 1) private key escrow is inherent in this system i.e., a PKG can easily decrypt its clients messages; and 2 This should not be confused with implicit certification in the context of selfcertified keys. In that context, T still must obtain explicit U-specific information following each certification update. 3 In some of our schemes, T must also obtain the long-lived certificate for U s public key. (But T never needs to obtain U s fresh certificate status information.)

5 276 C. Gentry 2) the PKG must send client private keys over secure channels, making private key distribution difficult. These two disadvantages of IBE, particularly escrow, may be unacceptable for some applications, like . Fortunately, we can get rid of both of them without sacrificing implicit certification. The basic idea is simple, and is the usual way of circumventing escrow: double encryption. 1.4 Our Results We introduce the notion of certificate-based encryption (CBE), which combines public-key encryption (PKE) and IBE while preserving most of the advantages of each. As with PKE, each client generates its own public-key / secret-key pair and requests a certificate from the CA. The main difference is that the CA uses an IBE scheme to generate the certificate. This certificate has all of the functionality of a conventional PKI certificate e.g., it can be used explicitly as proof of current certification (even of a signature key) but it can also be used as a decryption key. This added functionality gives us implicit certification Alice can doubly encrypt her message to Bob so that Bob needs both his personal secret key and an up-to-date certificate from his CA to decrypt. Implicit certification, in turn, allows us to eliminate third-party queries on certificate status. There is no escrow in CBE (since the CA does not know Bob s personal secret key), and there is no secret key distribution problem (since the CA s certificate need not be kept secret). We will introduce CBE more fully in Section 2, and describe a pairing-based CBE scheme secure against chosen-ciphertext attack in Section 3. By itself, ordinary CBE becomes inefficient when the CA has a large number of clients (say, 250 million) and performs frequent certificate updates (say, hourly). Such a CA must issue about 225 million certificates per hour (62500 per second), assuming, as in [15], that about 10% of the CA s clients have been revoked. By current standards, such a CA would need considerable computational power. In Sections 4 and 5, we describe how to refine basic CBE to construct an exceptionally efficient PKI. The scheme of Section 4 reduces the CA s computation through the use of subset covers. The CA embeds a serial number in each client s long-lived certificate that represents the position of the client s leaf in a binary tree. To reconfirm the validity of a client s certificate, the CA publishes the certificate / decryption key of an ancestor of the client leaf. Using this scheme, the CA only needs to compute an average of R total log(n/r total ) certificates, where N is the number of clients and R total is the total number of clients whose certificates have been revoked but have not yet expired. Each certificate is constant length as little as 160 bits and can, if desired, also be used as explicit proof of certification. This scheme manages to achieve bandwidth-efficiency basically identical to a scheme described by Aiello, Lodha and Ostrovsky [1], but with CBE functionality. 4 4 Other tradeoffs are worth mentioning. Unlike ALO, the time need to verify an explicit certification proof in our scheme does not grow linearly with the number of time periods, but ALO might still be faster since it uses hash chains.

6 Certificate-Based Encryption and the Certificate Revocation Problem 277 The scheme of Section 5 combines the use of subset covers with an incremental approach. Using incremental CBE, the CA can reduce its computation dramatically; the CA needs to compute only R period log(n/r period ) certificates per period, where R period is the number of clients whose certificates have been revoked in the period. 5 Since R hour.1n/(365 24) 2850, the CA only needs to compute an average of about 13 certificates per second even if updates are hourly. Using supersingular elliptic curves, this computation is quite reasonable indeed, a single 1 GHz Pentium III PC can handle it easily since each certificate generation essentially amounts to one elliptic curve point multiplication. Each client consolidates its periodic certificates simply by adding them together, and the consolidated certificate acts as the second decryption key. Of course, like the other CBE schemes, this scheme also eliminates third-party queries. In Section 6, we describe various extensions of the CBE schemes, such as hierarchical CBE. Finally, we present a summary. 2 Certificate-Based Encryption 2.1 The Model We now provide a formal security model for certificate-based encryption (CBE). The two main entities involved in CBE are a certifier and a client. Our definition of CBE is somewhat similar to that of strongly key-insulated encryption [10], but, among other differences, our model does not require a secure channel between the two entities. (See Appendix D of [4] for a discussion of this secure channel requirement.) Definition 1. A certificate-updating certificate-based encryption scheme is a 6-tuple of algorithms (Gen IBE, Gen PKE, Upd1, Upd2, Enc, Dec) such that: 1. The probabilistic IBE key generation algorithm Gen IBE takes as input a security parameter 1 k1 and (optionally) the total number of time periods t. It returns SK IBE (the certifier s master secret) and public parameters params that include a public key PK IBE, and the description of a string space S. 2. The probabilistic PKE key generation algorithm Gen PKE takes as input a security parameter 1 k2 and (optionally) the total number of time periods t. It returns a secret key SK PKE and public key PK PKE (the client s secret and public keys). 3. At the start of time period i, the deterministic certifier update algorithm Upd1 takes as input SK IBE, params, i, string s S and PK PKE. It returns Cert i, which is sent to the client. 4. At the start of time period i, the deterministic client update algorithm Upd2 takes as input params, i, Cert i, and (optionally) Cert i 1. It returns Cert i. 5 Aiello, Lodha and Ostrovsky also describe a scheme in which the CA issues R period log(n/r period ) certificates per period, but the size of a client s explicit proof of certification grows linearly with the number of time periods, whereas the length of the proof (a.k.a. the second decryption key) in our scheme tops out at log N.

7 278 C. Gentry 5. The probabilistic encryption algorithm Enc takes (params, i, s, P K PKE,M) as input, where M is a message. It returns a ciphertext C on message M intended for the client to decrypt using Cert i and SK PKE (and possibly s). 6. The deterministic decryption algorithm Dec takes (params, Cert i, SK PKE,C) as input in time period i. It returns either M or the special symbol indicating failure. We require Dec Certi,SK PKE,s(Enc i,s,p KIBE,P K PKE (M)) = M for the given params. Remark 1. CBE does not necessarily have to be certificate updating, and it can be useful for applications other than certificate management. In particular, it may be useful in other situations where authorization or access control is an issue. An encrypter can use CBE to encrypt its message so that the keyholder can decrypt only after it has obtained certain signatures from one or more authorizers on one or more messages. Remark 2. It may seem strange that a certificate or, more generally, a signature can be used as a decryption key. However, as noted by Moni Naor [6], any IBE scheme immediately gives a public key signature scheme as follows: We set the signer s private key to be the master key in the IBE scheme. The signer signs M by computing the IBE decryption key d for ID = M. The verifier merely has to check that d correctly decrypts messages encrypted with ID = M; so, the verifier chooses a random message M, encrypts it with ID = M using the IBE scheme, and then tries to to decrypt the resulting ciphertext with d. If the ciphertext decrypts correctly, the signature is considered valid. Thus, an IBE decryption key is also a signature (or a certificate). This certificate / decryption key can be verified like a signature as explicit proof of certification (even of signature keys), or it can be used as a means for enabling implicit certification in the encryption context, as described in the Introduction. As should be clear from Definition 1, we model CBE essentially as a combination of PKE and IBE, where the client needs both its personal secret key and a certificate / decryption key from the CA to decrypt. The string s may include a message that the certifier signs e.g., the certifier may sign clientinfo = clientname, P K PKE. (Notice that clientinfo contains only longlived information about the client; an encrypter need not know the client s current certificate status.) Depending on the scheme, s may include other information, such as the client s signature on its public key. 2.2 Security Roughly speaking, we are primarily concerned about two different types of attacks: 1) by an uncertified client and 2) by the certifier. We want CBE ciphertexts to be secure against each of these entities, even though each basically has half of the secret information needed to decrypt. Accordingly, we define IND-CCA in terms of two different games. The adversary chooses one game to play. In Game 1, the adversary essentially assumes the role of an uncertified client. After proving knowledge of the secret key corresponding to its claimed public key, it can

8 Certificate-Based Encryption and the Certificate Revocation Problem 279 make Dec and Upd1 queries. In Game 2, the adversary essentially assumes the role of the certifier. After proving knowledge of the master secret corresponding to its claimed params, it can make Dec queries. Roughly, we say that a CBE scheme is secure if no adversary can win either game. Game 1: The challenger runs Gen IBE (1 k1,t), and gives params to the adversary. The adversary then interleaves certification and decryption queries with a single challenge query. These queries are answered as follows: On certification query (i, s, P K PKE,SK PKE ), the challenger checks that s Sand that SK PKE is the secret key corresponding to PK PKE. If so, it runs Upd1 and returns Cert i ; else it returns. On decryption query (i, s, P K PKE,SK PKE,C), the challenger checks that s Sand that SK PKE is the secret key corresponding to PK PKE. If so, it generates Cert i and outputs Dec Certi,SK PKE,s(C); else it returns. On challenge query (i,s,pk PKE,SK PKE,M 0,M 1 ), the challenger checks that s Sand that SK PKE is the secret key corresponding to PK PKE. If so, it chooses random bit b and returns C = Enc i,s,p K IBE,P K PKE (M b); else it returns. Eventually, the adversary outputs a guess b {0, 1}. The adversary wins the game if b = b and (i,s,pk PKE,C ) was not the subject of a valid decryption query after the challenge, and (i,s,pk PKE ) was not the subject of any valid certification query. The adversary s advantage is defined to be the absolute value of the difference between 1/2 and its probability of winning. Game 2: The challenger runs Gen PKE (1 k2,t), and gives PK PKE to the adversary. The adversary then interleaves decryption queries with a single challenge query. These queries are answered as follows: On decryption query (i, s, params, SK IBE,C), the challenger checks that s Sand that SK IBE is the secret key corresponding to params. If so, it generates Cert i and outputs Dec Certi,SK PKE,s(C); else it returns. On challenge query (i,s, params,sk IBE,M 0,M 1 ), the challenger checks that s Sand that SK IBE is the secret key corresponding to params.if so, it chooses random bit b and returns C = Enc i,s,p K IBE,P K PKE (M b); else it returns. The adversary guesses b {0, 1} and wins if b = b and (i,s, params,c )was not the subject of a valid decryption query after the challenge. The adversary s advantage is defined as above. Definition 2. A certificate-updating certificate-based encryption scheme is secure against adaptive chosen ciphertext attack (IND-CBE-CCA) if no PPT adversary has non-negligible advantage in either Game 1 or Game 2. Remark 3. We require the adversary to reveal its secret key to the challenger, because the challenger cannot, in general, otherwise be able to decrypt. By placing constraints on the PKE and IBE schemes used, it may be possible to eliminate this requirement.

9 280 C. Gentry Remark 4. In the sequel, we narrow our focus to pairing-based CBE schemes. In this context (and in the random oracle model), we construct CBE schemes secure against adaptive chosen ciphertext attack, where the parties do not need to reveal their secret keys. 3 A CBE Scheme Based on Boneh-Franklin Roughly speaking, a CBE scheme is created by combining a PKE scheme and an IBE scheme. Since Boneh and Franklin s IBE scheme [6] is currently the most practical, we explicitly describe a CBE scheme that uses it. This scheme adds little online overhead to Boneh-Franklin: encryption complexity is increased slightly, but decryption complexity and ciphertext length are the same as in Boneh-Franklin. 3.1 Review of Pairings Boneh-Franklin uses a bilinear map called a pairing. Typically, the pairing used is a modified Weil or Tate pairing on a supersingular elliptic curve or abelian variety. However, we describe pairings and the related mathematics in a more general format here. Let G 1 and G 2 be two cyclic groups of some large prime order q. We write G 1 additively and G 2 multiplicatively. Admissible pairings: We will call ê an admissible pairing if ê : G 1 G 1 G 2 is a map with the following properties: 1. Bilinear: ê(aq, br) =ê(q, R) ab for all Q, R G 1 and all a, b Z. 2. Non-degenerate: ê(q, R) 1 for some Q, R G Computable: There is an efficient algorithm to compute ê(q, R) for any Q, R G 1. Notice that ê is also symmetric i.e., ê(q, R) =ê(r, Q) for all Q, R G 1 since ê is bilinear and G 1 is a cyclic group. Bilinear Diffie-Hellman (BDH) Parameter Generator: As in [6], we say that a randomized algorithm IG is a BDH parameter generator if IG takes a security parameter k>0, runs in time polynomial in k, and outputs the description of two groups G 1 and G 2 of the same prime order q and the description of an admissible pairing ê : G 1 G 1 G 2. The security of the pairing-based schemes in this paper are based on the difficulty of the following problem: BDH Problem: Given a randomly chosen P G 1, as well as ap, bp, and cp (for unknown randomly chosen a, b, c Z/qZ), compute ê(p, P) abc. For the BDH problem to be hard, G 1 and G 2 must be chosen so that there is no known algorithm for efficiently solving the Diffie-Hellman problem in either G 1 or G 2. Note that if the BDH problem is hard for a pairing ê, then it follows that ê is non-degenerate.

10 Certificate-Based Encryption and the Certificate Revocation Problem 281 BDH Assumption: As in [6], if IG is a BDH parameter generator, the advantage Adv IG (B) that an algorithm B has in solving the BDH problem is defined to be the probability that the algorithm B outputs ê(p, P) abc when the inputs to the algorithm are G 1, G 2, ê, P, ap, bp, cp where (G 1, G 2, ê) isig s output for large enough security parameter k, P is a random generator of G 1, and a, b, c are random elements of Z/qZ. The BDH assumption is that Adv IG (B) is negligible for all efficient algorithms B. 3.2 BasicCBE and FullCBE As mentioned previously, IBE enables signatures to be used as decryption keys. For example, in Boneh-Franklin, a BLS signature [8] is used as a decryption key. Similarly, in BasicCBE, we will use a two-signer BGLS aggregate signature [7] as a decryption key. (See [7] for details on the aggregate signature scheme.) Let k be the security parameter given to the setup algorithm, and let IG be a BDH parameter generator. Setup: The CA: 1. runs IG on input k to generate groups G 1, G 2 of some prime order q and an admissible pairing ê: G 1 G 1 G 2 ; 2. picks an arbitrary generator P G 1 ; 3. picks a random secret s C Z/qZ and sets Q = s C P ; 4. chooses cryptographic hash functions H 1 : {0, 1} G 1 and H 2 : G 2 {0, 1} n for some n. The system parameters are params =(G 1, G 2, ê, P, Q, H 1,H 2 ). The message space is M = {0, 1} n. The CA s secret is s C Z/qZ. The CA uses its parameters and its secret to issue certificates. Assume that Bob s secret key / public key pair is (s B,s B P ), where s B P is computed according to the parameters issued by the CA. Bob obtains a certificate from his CA as follows. Certification: 1. Bob sends Bobsinfo to the CA, which includes his public key s B P and any necessary additional identifying information, such as his name. 2. The CA verifies Bob s information; 3. If satisfied, the CA computes P B = H 1 (s C P, i, Bobsinfo) G 1 in period i. 4. The CA then computes Cert B = s C P B and sends this certificate to Bob. Before performing decryptions, Bob also signs Bobsinfo, producing s B P B where P B = H 1(Bobsinfo). Now, notice that S Bob = s C P B + s B P B is a twoperson aggregate signature, as defined in [7]. Bob will use this aggregate signature as his decryption key! Encryption: To encrypt M Musing Bobinf o, Alice does the following: 1. Computes P B = H 1(Bobsinfo) G Computes P B = H 1 (Q, i, Bobsinfo) G 1.

11 282 C. Gentry 3. Chooses a random r Z/qZ. 4. Sets the ciphertext to be: C =[rp, M H 2 (g r )] where g =ê(s C P, P B )ê(s B P, P B) G 2. Notice that the length of the ciphertext is the same as in Boneh-Franklin. Alice can reduce her computation through precomputation e.g., ê(s B P, P B ) can likely be precomputed, since it is long-lived. Decryption: To decrypt [U, V ], Bob computes: M = V H 2 (ê(u, S Bob )). Notice that Bob s online decryption time is the same as in Boneh-Franklin. BasicCBE is a one-way encryption scheme. It can be made secure (in the random oracle model) against adaptive chosen-ciphertext by, for example, using the Fujisaki-Okamoto transform in a manner similar to [6]. The transformed scheme, which we call FullCBE, uses two additional cryptographic hash functions H 3 and H 4, and a semantically secure symmetric encryption scheme E: Encryption: To encrypt M Musing Bobinf o, Alice does the following: 1. Computes P B = H 1(Bobsinfo) G Computes P B = H 1 (Q, i, Bobsinfo) G Chooses random σ {0, 1} n. 4. Sets r = H 3 (σ, M). 5. Sets the ciphertext to be: C =[rp, σ H 2 (g r ),E H4(σ)(M)] where g =ê(s C P, P B )ê(s B P, P B) G 2. Decryption: To decrypt [U, V, W ], Bob 1. Computes σ = V H 2 (ê(u, S Bob )). 2. Computes M = E 1 H 4(σ) (W ). 3. Sets r = H 3 (σ, M) and rejects the ciphertext if U rp. 4. Outputs M as the plaintext. We can prove that FullCBE is secure in the random oracle model against adaptive chosen-ciphertext attack in two (quite different) ways by showing such an attack implies 1) an existential forgery attack on the aggregate signature scheme, or 2) an adaptive chosen-ciphertext attack on BasicPub hy (a public key encryption scheme defined in [6] and in Appendix A). We use the latter approach. Lemma 1. Let A be a IND-CCA adversary that has advantage ɛ against Full- CBE. Suppose that A makes at most q C certification queries and q D decryption queries. Then, there is an IND-CCA adversary B with running time O(time(A)) ɛ that has advantage at least e(1+q C +q D ) against BasicPubhy. Our proof, given in Appendix A, is similar to Boneh and Franklin s proof of Lemma 4.6 in [6]. Just like an IBE adversary is allowed to choose its identity adaptively, a CBE adversary is allowed to choose its information (including its public key) adaptively. When combined with Theorem 4.5 and Lemma 4.3 of [6], our Lemma 1 gives a reduction from the BDH problem to FullCBE, with time and advantage bounds as in Theorem 4.4 of [6].

12 Certificate-Based Encryption and the Certificate Revocation Problem Using Subset Covers to Reduce CA Computation Using BasicCBE (or FullCBE), a CA that has N (currently valid) clients must compute N certificates per period. BasicCBE may therefore become impractical when N is large and updates are frequent e.g., a CA with 225 million (currently valid) clients that performs hourly updates must compute 225 million certificates per hour (62500 per second) on average. In this section, we show how to reduce the CA s computation using subset covers. 4.1 The General Approach Unlike in BasicCBE, we assume that the CA distributes a long-lived certificate to each client, which it periodically reconfirms (if appropriate). Before encrypting to Bob, Alice must obtain and verify Bob s long-lived certificate. This assumption costs us little, since Alice likely can obtain Bob s long-lived certificate when she obtains Bob s public key. (Recall that the main benefit of CBE is that Alice does not have to obtain fresh certificate status information; obtaining long-lived information is a simpler problem.) We will not concern ourselves with what certification scheme is used to generate the long-lived certificates, but we note that producing long-lived certificates should not add much to the CA s computational burden, since their production is amortized over a long time (assuming clients do not, say, sign-up all at once. ) The CA arranges its N<2 m clients as leaves in an m-level binary tree by embedding a unique m-bit serial number (SN) in each client s long-lived certificate. For each time period, each tree node (including interior nodes) corresponds to an identity, and the CA computes each node s decryption key according to an IBE scheme. Specifically, in time period i, the node corresponding to the (k m)-bit SN b 1 b k may be mapped to i, b 1 b k. The node s associated decryption key is the IBE decryption key for i, b 1 b k. We call i, b 1 b k for 0 k m the ancestors of i, b 1 b m. In time period i, the CA finds a cover of the non-revoked clients i.e., a set S of nodes, such that each of the N R non-revoked clients has an ancestor in S, but none of the R revoked clients does. Such a cover, consisting of at most R log(n/r) nodes, can be found using the Complete Subtree Method described in [17]. The CA then publishes the decryption keys for each node in S; we call these decryption keys reconfirmation certificates. Now, assume that Alice has obtained and verified Bob s long-lived certificate, and therefore knows his public key and his SN. To encrypt to Bob, Alice does not need Bob s reconfirmation certificate. Instead, she encrypts her message m + 1 times, using (Bob s public key and) each of the m+1 identities of Bob s ancestors in the tree. If the CA has published a reconfirmation certificate corresponding to one of Bob s ancestors, Bob will be able to decrypt one of Alice s ciphertexts. In summary, this scheme combines PKE and IBE just like BasicCBE, but it imposes a structure on the identities that permits efficient inclusion and exclusion (à la broadcast encryption). Though the complexity of encryption and the length of the ciphertext is increased, the CA computes only R log(n/r)

13 284 C. Gentry reconfirmation certificates, rather than N R (in BasicCBE). Assuming that long-lived certificates expire 1 year after creation and that the yearly revocation rate is 10% (i.e., R =.1N) as in [15] and [16], the CA s computation is reduced by a factor of about A Pairing-Based CBE Scheme Using Subset Covers The general approach above, while simple, creates difficulties in proving security against chosen-ciphertext attacks, since the same message is being encrypted under different keys. Below, we briefly present a variant of BasicCBE using subset covers, which deviates slightly from the general approach. As above, we assume that Bob has already obtained his long-lived certificate, which contains the serial number b 1 b m. Certification: The CA sets up as in BasicCBE and also uses H 5 : {0, 1} G 1 to map time periods to points. At the start of period i, the CA chooses random x Z/qZ and finds a cover S of the non-revoked clients (using the Complete Subtree Method). Bob s reconfirmation certificate (if it exists) has the form S i = s C T i + xp k together with xp, where T i = H 5 (Q, i), P k = H 1 (b 1 b k ) and b 1 b k S is an ancestor of b 1 b m. Encryption: Alice has already verified Bob s initial certificate, and therefore knows Bobsinf o. Alice chooses random r Z/qZ. She sends the ciphertext C =[rp, rp 1,...,rP m,v], where V = M H 2 (g r ) and g =ê(q, T i )ê(s B P, P B ). Decryption: Bob computes M = V H 2 ( ê(rp,si+s BP B ) ê(xp,rp k ) ). Encryption involves m+1 point multiplications, but decryption involves only two pairing computations. Bob s reconfirmation certificate is concise: just two elements of G 1. (Actually, since xp is common to all clients, we may say Bob s proof consists of just one element of G 1.) Elements of G 1 may be quite short e.g., [8] proposes using an elliptic curve over F 3 97 (about 154 bits) for the BLS signature scheme. We note again that this scheme assumes that the client has already obtained a long-lived certificate. Thus, a Game 1 adversary cannot choose its public key with complete freedom; it must choose one of the N keys initially certified (and collude with the secret key holder). As with BasicCBE, the Fujisaki-Okamoto transform can be used to achieve CCA2 security. We remark, however, that gcca2 security [2] may be considered preferable, because CCA2 security would technically require Bob to confirm that rp i = U i for every i, even when k m. We discuss the chosen-ciphertext security of this scheme in detail in the full version of the paper. 5 Incremental CBE Using Subset Covers Intuitively, it seems like the CA s computation should be less for periods when few new revocations have occurred. However, this is not the case with the scheme of Section 4: if updates are hourly, the CA must compute about R log(n/r)

14 Certificate-Based Encryption and the Certificate Revocation Problem 285 reconfirmation certificates per hour (where R is the total number of revoked clients), even for hours when no client s certificate status has changed. In this section, we describe how to achieve incremental CBE, where the CA s hourly computation is roughly proportional to the number of revocations that occurred during that hour. Specifically, the CA computes at most R hour log(n/r hour ) certificates per hour, where R hour is the number of revocations during the previous hour. Assuming a 10% yearly revocation rate, a CA with 250 million clients performing hourly updates only needs to compute about 13 reconfirmation certificates per second, a dramatic improvement over BasicCBE. (We discuss incremental CBE s performance characteristics in more detail in Section 5.3.) 5.1 Basic Incremental CBE As will become clearer from the detailed description below, this scheme is essentially based on two insights. First, as noted above and in [1], the CA can dramatically reduce its periodic computation by only revoking those clients that have become invalid in the past period. This strategy, however, has a price: a client cannot be considered currently certified (and must not be able to decrypt) unless it has an unbroken chain of periodic reconfirmation certificates for every period from the creation of its long-lived certificate to the present. At first, this seems to suggest that encryption and decryption complexity must be (at least) proportional to the number of time periods that have passed. Fortunately, using pairings, this is not the case: the second insight is an efficient way for each client to consolidate its periodic certificates into a single decryption key (consisting of log N + 1 elements of G 1 ), such that the encryption and decryption complexity and the ciphertext length are about log N times that of BasicCBE, regardless of how may periods have transpired since the client s initial certification. We assume Bob has obtained a long-lived certificate containing his m-bit serial number b 1 b m and the period t 0 in which he was initially certified. Certification: The CA sets up as in BasicCBE and also uses H 5 : {0, 1} G 1 to map time periods to points. At the start of period i, the CA chooses random x Z/qZ and finds a cover S of the clients not revoked during period i 1 (using the Complete Subtree Method). Bob s reconfirmation certificate (if it exists) has the form S i = s C(T i T i 1 )+xp k together with xp, where T i = H 5 (Q, i), P k = H 1 (b 1 b k ) and b 1 b k S is an ancestor of b 1 b m. Consolidation: If the CA has continually reconfirmed Bob s key from its initial certification to the start of period i, we want it to be the case that Bob can compute a consolidated certificate of the form S i = s C (T i T t0 )+x i,1 P 1 + +x i,m P m with Q i,j = x i,j P for 1 j m, for some x i,j Z/qZ, 1 j m, where P j = H 1 (b 1 b j ). Assume he has a consolidated certificate with the correct form at the start of period i 1: S i 1 = s C (T i 1 T t0 )+x i 1,1 P x i 1,m P m with Q i 1,j = x i 1,j P.

15 286 C. Gentry Upon receiving S i and xp, Bob computes his new consolidated certificate as follows: S i = S i 1 + S i, Q i,j = Q i 1,j for j k, and Q i,k = Q i 1,k + xp. Encryption: Alice has already verified Bob s initial certificate, and therefore knows Bobsinfo. Alice chooses random r Z/qZ. She sends the ciphertext C = [rp, rp 1,...,rP m,v], where V = M H 2 (g r ) and g =ê(q, T i T t0 )ê(s B P, P B ). Decryption: Bob computes M = V H 2 ( ê(rp,si+s BP B ) m j=1 ê(rpj,qi,j)). Remark 5. If the CA gives Bob (say) s C T t0 +x t0 P m with Q t0,m = x t0 P (for some x t0 Z/qZ) at the time of initial certification, and Bob consolidates this with his periodic certificates, then T t0 need not be included in the Encryption step. However, the CA may prefer not to constrain how it handles initial certification. 5.2 Security In the full version of the paper, we prove (in the random oracle model, under the Bilinear Diffie-Hellman Assumption, and using the Fujisaki-Okamoto transform) that Bob needs an unbroken chain of reconfirmation certificates from the time of his initial certification to the present to decrypt. We could prove the scheme secure against Game 2 adversaries using similar techniques. Here, in lieu of proof, we provide some rough intuitive justification for incremental CBE s security. S i contains a time component of the form s C (T i T t0 ) and an identity component of the form x 1 P 1 +x 2 P 2 + +x m P m. If Bob tries to consolidate his certificates without his reconfirmation certificate for day z, t 0 <z i, the result will have the form s C (T i T z +T z 1 T t0 )+x 1 P 1 +x 2 P 2 + +x m P m. In other words, the time component of S i will have the incorrect form. If Bob tries to substitute someone else s day z reconfirmation point s C (T z T z 1 )+x k P k, where P k does not correspond to one of Bob s ancestors, the result will have the form s C (T i T t0 )+x 1 P 1 + x 2 P x m P m + x k P k. In other words, the identity component of S i will have the incorrect form. 5.3 Performance Characteristics Like the other CBE schemes, incremental CBE enjoys all the infrastructural benefits of eliminating third-party queries. Also, the CA s computation is minimal; it computes only 13 reconfirmation certificates per second. Since each reconfirmation certificate is essentially equivalent (computation-wise) to a BLS signature, which requires only 3.57 ms to compute on a Pentium III 1 GHz [3], a single PC can easily handle the computation. Distributing the reconfirmation certificates can be handled in a variety of ways. Since CBE eliminates third-party queries, one interesting alternative to the usual directories-based approach is to push certificates directly to the clients they certify i.e., the CA sends each client its reconfirmation certificate rather than waiting for the client s query. This would eliminate queries altogether. 6 If 6 In practice, the CA would probably allow some queries, both by clients and thirdparties. However, CBE allows a CA to discourage queries e.g., by using fees so that the number of queries is reduced to a desired level.

16 Certificate-Based Encryption and the Certificate Revocation Problem 287 the CA uses separate transmissions for each client, the CA s required bandwidth is (320 bits per cert) (225 million certs per hour)/(3600 seconds per hour) = 20 mbits/sec. This figure is a lower bound; it does not include overhead such as packet headers. Such a large transmission may need to be delegated to a number of servers. Theoretically, however, if the CA pushes its certificates, it can dramatically reduce its bandwidth requirements by using multicast. Recall that a reconfirmation certificate for node b 1 b k applies to all of b 1 b k s descendants. So, if the CA sets up multicast address for each interior node, the CA s expected bandwidth requirements are very low only about (160 bits per cert) (13 certs per second) 2.1 kbits/sec. (The certificates are 160 bits in this case, since xp, the other 160-bit value, can be sent to all clients via one multicast). Even if the CA sets up multicast addresses only for high-level nodes (close to the root), it can significantly reduce its bandwidth requirements. For users, incremental CBE is somewhat expensive computationally: encryption and decryption cost about m = log N times that of Boneh-Franklin. This may make the scheme impractical for some applications in the very near future. It may not be a problem for other applications, like , where fast online computation is not such a concern. We expect that, in the future, computational considerations will become less important relative to network considerations (like the latency caused by the (fixed) speed of light), making CBE s advantages more prominent. If desired, however, one can shift some user computation back to the CA by fattening the binary tree (so that each node has more children), or having the CA maintain several trees concurrently, as described in [1]. The total length of a client s consolidated certificate, which can be used as explicit proof of certification (even of signature keys), never grows beyond 160(m + 1) bits. Even though CBE was not originally intended to improve the efficiency of explicit certification, we note that explicit proofs in incremental CBE are more compact than in Aiello-Lodha-Ostrovsky s incremental scheme [1], where the length grows linearly with the number of time periods. 6 Extensions and Generalizations 6.1 High-Granularity CBE Suppose a one hour time granularity is insufficient; we want certificate revocation to be practically instantaneous. One option is for Alice to encrypt using i +1 as the time period during period i. The drawback is that Bob, after receiving Alice s message, may need to wait an hour to decrypt it. Another option, called the SEM architecture, is described in [5]. In SEM, revocation is instantaneous, and so is Bob s ability to decrypt, but he must interact with a security mediator for each message decryption. Below, we briefly describe a high-granularity version of CBE, where revocation is practically instantaneous say, within 1 second but where Bob s interaction with the CA grows not with the number of messages he decrypts, but rather with the number of his sessions.

17 288 C. Gentry In our scheme, the CA uses a recent forward-secure encryption (FSE) scheme [9], but in reverse i.e., the CA relabels the time periods such that given the FSE decryption key for period i, one can compute the decryption key for period j if j<i, but not if j>i. 7 Bob may download such a certificate a few times daily, depending on how often he checks his messages, and use it to decrypt messages from multiple previous time periods. As in [9], the size of this certificate is merely logarithmic in the number of periods for which messages can be decrypted; thus, we can make revocation highly granular without sacrificing much efficiency. Also, this scheme can be combined with (say) incremental CBE: the CA performs hourly updates as in incremental CBE, but employs a subtree of 3600 seconds for clients that request high-granularity certificates. 6.2 Hierarchical CBE Though our previous schemes have used only one CA, adapting CBE to a hierarchy of CAs is fairly straightforward. Perhaps the more obvious approach is simply to combine a HIBE scheme and a PKE scheme, much as CBE combines IBE and PKE. However, using this approach, encryption and decryption complexity, as well as ciphertext length, are all about t times that of Boneh-Franklin, where t is the level of the recipient in the hierarchy. Instead, we use the BGLS aggregate signature scheme. The encryption complexity of this scheme is still proportional to t, but the decryption complexity and ciphertext length are identical to Boneh-Franklin. Suppose Bob is at level t, that his public key is s t P, and that the CAs above him have public keys s j P for 0 j t 1. Certification of CAs: CA j certifies s j+1 P as CA j+1 s public key by producing a signature of the form s j P j+1, where P j+1 = H 1 (s j P, CA j+1 info) and CA j+1 info includes s j+1 P. Certification of Bob: Similarly, Bob s parent CA produces a certificate of the form s t 1 P t, where P t = H 1 (s t 1 P, Bobsinfo) and Bobsinfo includes s t P. Aggregation: Bob signs his key to produce s t P B and aggregates this signature with the certificates in his chain simply by adding them together: S Agg = s t P B + t j=1 s j 1P j. Encryption: We assume Alice knows Bobsinfo and CA j info for 0 j t 1. Alice chooses random r Z/qZ and sends C =[rp, V ], where V = M H 2 (g r ) and g =ê(p B,s tp ) t j=1 ê(p j,s j 1 P ). Decryption: Bob computes M = V H 2 (ê(rp, S Agg )). Remark 6. To handle revocation, we can embed time periods in the various certificates above. However, Alice must know the certification schedules of all of Bob s ancestral CAs, which may make implementation difficult in practice. Remark 7. We note that the second scheme is useful outside of the PKI setting. It provides a general way for making a keyholder s decryption ability contingent on that keyholder s acquisition of multiple signatures / authorizations. 7 We omit the details of our scheme, since we would largely be rehashing [9].