How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack Yitao Duan Computer Science Division, University of California, Berkeley, 02/16/ Session Code: CRYP-302B

Multicast Center Members

Multicast Encryption: Securing the Multicast Communication Current IP Multicast does not provide mechanisms to restrict message delivery to a specified set of receivers — Anybody can join the group by sending IGMP messages to its local router — Must use other means to protect the communication Multicast encryption: protecting data confidentiality — Only the intended recipients can access — More issues than unicast encryption e.g. adding/removing members At minimum, must support member revocation

Existing Solutions LKH:[Wallner et al., Wong et al.] Asymmetric key based schemes — Traitor tracing [CFN94] — Broadcast encryption [FN93, BGW05, etc] — ATD-based schemes (more later) Various efficiency — E.g. ATD: O(1) member key, O(t) center key, O(t) message Members don’t have to participate in every re-key operation K 3.8 K 3.1 K 3.2 K 3.3 K 3.4 K 3.5 K 3.6 K 3.7 K 2.1 K 2.2 K 2.3 K 2.4 K 1.1 K 1.2 K0K0 M1M1 M2M2 M5M5 M4M4 M3M3 M6M6 M7M7 M8M8 Keys Assigned to M 1 Member Leaf Node Root Node + Use symmetric key crypto + O(logn) storage, message - Members stateful

ATD: A General Framework for Constructing MultiEnc Based on threshold decryption and asymmetric distribution of the key shares. — Split the secret key SK into n+t shares using a (t+1, n+t) -threshold secret sharing scheme — Give the center t shares, each member 1 share — Ciphertext consists of original ciphertext and t partial decryptions Previous works [NP00, TT01, DF03, AMM99, KHL03] ad hoc: — None of them realized that they were using threshold decryption — Based on specific threshold cryptosystems (e.g. threshold ElGamal) — Rely on specific assumptions (e.g. DDH), each has own proof

Our Results A general ME construction framework with guaranteed security Security proofs/results that — Generalize all existing ATD based schemes — Allow ME construction based on any threshold decryption scheme — Enable new ME constructions using many other primitives Higher security level and efficiency: — Can be more secure than underlying threshold scheme — O(t) center key, O(t) message, constant member key — No expensive verifications that are often necessary to secure a threshold scheme against CCA

Model and Assumptions A single center, n members. Center controls group membership Computationally bounded adversary attacking the scheme from both inside and outside the group — Can see all the cipthertexts — Can corrupt up to t < n members Closed communication — Only the legitimate group members can decrypt a message — Only guarantee the center’s encryption capability — Not a public key setting!

Multicast Encryption An n-way multicast encryption scheme ME = (KeyGen, Reg, E,D) consists of the following set of algorithms: — Key generation: Generates proper keys — Registration: Admits new members — Encryption E: A probabilistic polynomial-time algorithm that, on inputs Σ, the encryption key, and a string m ∈ {0, 1} k, and a set R of revoked users (with |R| ≤ t) and their keys, produces as output ψ ∈ {0, 1} * called the ciphertext — Decryption D: a deterministic polynomial-time algorithm s.t. for all m ∈ {0, 1} k, for all i ∈ U \ R, D( Γ i, E( Σ, {(j, Γ j )|j ∈ R},m)) = m. On all other inputs it outputs a special symbol ⊥ ( Γ i : member i’s key).

Notion of Security: Game ME [Dodis and Fazio 03] M1: The adversary A corrupts a fixed set R of t members. M2: KeyGen is run and keys are given to the parties. A is given the keys of the corrupted members. M3: The center encrypts any message A feeds it. M4: A chooses m 0 and m 1, two target plaintexts, the center chooses b ∈ {0, 1} randomly and returns encryption of m b. M5: A continues to interact with the center. M6: A output b ’ ∈ {0, 1}. Adv = |Pr(b’ = b) – ½| CCA2 attack: A also has access to decryption oracle throughout the game

The Basics: Threshold Decryption SK 1 SK 2 SK n Client Decryption Servers c c c c

The Basics: Threshold Decryption SK 1 SK 2 SK n Client Decryption Servers m1m1 m2m2 m3m3 mnmn m i = D SKi (c)

The Basics: Threshold Decryption SK 1 SK 2 SK n Client Decryption Servers m = η(m 1, … )

Notion of Security: Game TD [SG02] TD1: The adversary A chooses a fixed set of t servers. TD2: KeyGen is run and keys are given to the parties. A is given the keys of the corrupted servers. TD3: A chooses m 0 and m 1, two target plaintexts, the encryption oracle chooses b ∈ {0, 1} randomly and returns encryption of m b. TD4: A output b ’ ∈ {0, 1}. Adv = |Pr(b’ = b) – ½| CCA2 attack: A also has access to decryption oracle throughout the game

Our Constructions PKC Threshold Decryption   Multicast Encryption Symmetric distribution of key shares Asymmetric distribution of key shares

Our Constructions PKC Threshold Decryption   Multicast Encryption Our results Symmetric distribution of key shares Asymmetric distribution of key shares

Construction 1

Theorem 1 Threshold Decryption Scheme (IND-μ) Multicast Encryption (IND-μ) 

Theorem 1 Many existing ATD-based multicast encryptions are special cases of Construction 1 (and the rest are covered by its extension) — All are dlog based systems [NP00, TT01, DF03, AMM99, KHL03] — Can be expressed as Construction 1 with threshold ElGamal Construction 1 can be used to build new ME systems using a whole lot more other primitives — A lot of threshold schemes are proven IND-CCA2 [SG02, CG99, Abe99, JL00 ] — RSA-based systems [SDFY94] (IND-CPA) — Threshold Paillier cryptosystem [FP01, Paillier 99] (IND-CCA2)

Extension An ATD-based multicast encryption is not a threshold scheme — Unlike a threshold scheme, the encryptor has access to and control over t partial decryptions — He can do something to “protect” them (using e.g. MAC [DF03]) — Result: multicast encryption with higher security than the underlying threshold scheme Threshold Decryption Scheme (IND-CPA) Multicast Encryption (IND-CCA) 

Do We Really Need an IND-CCA2 Threshold Scheme? Suppose we want IND-CCA2 multicast encryption Given a PKC, it is often hard to obtain a threshold implementation at CCA level — Many popular IND-CCA2 PKC (e.g. RSA-OAEP [BR94, Shoup01, FOPS01]) do not have IND-CCA2 threshold implementation. — The difficulty: the PKC’s CCA2 security relies on the decryption performing a validity test before generating an output. [SG02] — In threshold setting, where a decryption server sees only a partial decryption, the test may have to be publicly checkable. [LL93, SG02] But, do we really need an IND-CCA2 threshold scheme?

Do We Really Need an IND-CCA2 Threshold Scheme? In multicast, a decryptor sees the final decryption. No need to make the validity test publicly checkable – the original test in the PKC can be carried out and is enough! 

Sharable Trapdoor Permutation-based PKC Many popular PKCs are based on trapdoor permutation — PKCS#1, OAEP [BR94], Bellare and Rogaway [BR93], etc. — Decryption = recovering the pre-image of the trapdoor permutation — They do NOT have secure threshold implementation f PK : {0, 1} k  {0, 1} k a trapdoor permutation and f - SK -1 its inverse. Sharable trapdoor permutation: — S: SK  SK 1, SK 2, …, SK n — η: Given t+1 valid f - SKi -1 (u) can recover f - SK -1 (u), not with less — RSA is such a trapdoor permutation [SDFY94]

Construction 2

Theorem 2 Sharable Trapdoor Permutation-based PKC (IND-μ) Multicast Encryption (IND-μ) 

What Does Theorem 2 Give Us? Ways to construct ATD-based multicast encryption using primitives that do not have secure threshold implementation — Construction 1 not always possible — It is guaranteed that the ME is at least as secure as the PKC A whole lot of new primitives that have never been used before now can be used (the resulting ME is guaranteed IND-CCA1): — RSA-OAEP [BR94, Shoup01, FOPS01], Bellare and Rogaway [BR93], etc. Higher efficiency: no decryption share verification nor publicly checkable validity test on ciphertext necessary

From IND-CPA to IND-CCA: Generic Conversion We can convert IND-CPA PKC into IND-CCA one [NY90, RS91] Also work with threshold schemes [FP01] Corollary: IND-CPA Sharable Trapdoor Permutation- based PKC IND-CCA Multicast Encryption 

Summary: Conversions IND-CPA PKC IND-CCA PKC IND-CPA TD IND-CPA ME IND-CCA TD IND-CCA ME [NY90, RS91,FP01] [FP01] Construction 1 Construction 1e Construction 2

References [NP00] Naor, M., Pinkas, B.: E±cient trace and revoke schemes. In: Proceedings of Financial Crypto (2000) [TT01] Tzeng, W.G., Tzeng, Z.J.: A public-key traitor tracing scheme with revocation using dynamic shares. In: Proceedings PKC ‘01 (2001) 207–224 [DF03]: Public key trace and revoke scheme secure against adaptive chosen ciphertext attack. In: PKC ’03. [AMM99] Anzai, J., Matsuzaki, N., Matsumoto, T.: A quick group key distribution scheme with “entity revocation”. In: ASIACRYPT [KHL03] Kim, C.H., Hwang, Y.H., Lee, P.J.: An efficient public key trace and revoke scheme secure against adaptive chosen ciphertext attack. In: ASIACRYPT [SDFY94] De Santis, A., Desmedt, Y., Frankel, Y., Yung, M.: How to share a function securely. In: STOC 94 [SG02] Shoup, V., Gennaro, R.: Securing threshold cryptosystems against chosen ciphertext attack. J. Cryptology 15 (2002) 75–96

References [CG99] Canetti, R., Goldwasser, S.: An e±cient threshold public key cryptosystem secure against adaptive chosen ciphertext attack. In: EUROCRYPT 1999 [Abe99] Abe, M.: Robust distributed multiplication without interaction. CRYPTO 99 [JL00] Jarecki, S., Lysyanskaya, A.: Adaptively secure threshold cryptography: Introducing concurrency, removing erasures (extended abstract). In: Eurocrypt 00 [FP01] Fouque, P.A., Pointcheval, D.: Threshold cryptosystems secure against chosenciphertext attacks. In: ASIACRYPT [Paillier 99] Paillier, P.: Public-key cryptosystems based on discrete logarithms residues. In: EUROCRYPT [FOPS01] Fujisaki, E., Okamoto, T., Pointcheval, D., Stern, J.: RSA-OAEP is secure under the RSA assumption. In: CRYPTO [LL93] Lim, C.H., Lee, P.J.: Another method for attaining security against adaptively chosen ciphertext attacks. In: CRYPTO [Shoup01] Shoup, V.: OAEP reconsidered. In: CRYPTO 2001.

References [CFN94] Chor, B., Fiat, A., Naor, M.: Tracing traitors. In: CRYPTO [FN93] Fiat, A., Naor, M.: Broadcast encryption. In: CRYPTO [NY90] Naor, M., Yung, M.: Public-key cryptosystems provably secure against chosen ciphertext attacks. In: STOC ’90. [RS91] Rackoff, C., Simon, D.R.: Non-interactive zero-knowledge proof of knowledge and chosen ciphertext attack. In: CRYPTO [BR03] Bellare, M., Rogaway, P.: Random oracles are practical: a paradigm for designing efficient protocols. In: CCS 93. [BR94] Bellare, M., Rogaway, P.: Optimal asymmetric encryption – how to encrypt with RSA. In: EUROCRYPT [BF99] Boneh, D., Franklin, M.: An efficient public key traitor tracing scheme. In: CRYPTO [BGW05] Boneh, D., Gentry, C., Waters, B.: Collusion resistant broadcast encryption with short ciphertexts and private keys. In: CRYPTO 2005.

Thank You Thank You!