How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack

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

2. Multicast Center Members

3. 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

4. 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 M7 M3 M2 M1 M4 M8 M6 M5 Keys Assigned to M1 K0 Root Node K1.1 K1.2 K2.1 K2.2 K2.3 K2.4 Leaf Node K3.1 K3.2 K3.3 K3.4 K3.5 K3.6 K3.7 K3.8 Member + Use symmetric key crypto + O(logn)storage, message - Members stateful

5. 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

6. 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

7. 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!

8. 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).

9. 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 m0 and m1, two target plaintexts, the center chooses b ∈ {0, 1} randomly and returns encryption of mb. • 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

10. The Basics: Threshold Decryption Decryption Servers SK1 c SK2 c c Client c SKn

11. The Basics: Threshold Decryption Decryption Servers SK1 m1 SK2 m2 m3 Client mn SKn mi = DSKi(c)

12. The Basics: Threshold Decryption Decryption Servers SK1 SK2 Client m = η(m1, … ) SKn

13. 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 m0 and m1, two target plaintexts, the encryption oracle chooses b ∈ {0, 1} randomly and returns encryption of mb. • TD4: A output b’ ∈ {0, 1}. • Adv = |Pr(b’ = b) – ½| • CCA2 attack: A also has access to • decryption oracle throughout the game

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

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

16. Construction 1

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

18. 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)

19. 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) 

20. 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?

21. 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!

22. 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 • fPK:{0, 1}k {0, 1}k a trapdoor permutation and f-SK-1 its inverse. • Sharable trapdoor permutation: • S: SK SK1, SK2, …, SKn • η: Given t+1 valid f-SKi-1(u) can recover f-SK-1(u), not with less • RSA is such a trapdoor permutation [SDFY94]

23. Construction 2

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

25. 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

26. 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 

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

28. References • [NP00] Naor, M., Pinkas, B.: E±cient trace and revoke schemes. In: Proceedings of Financial Crypto 2000. (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 1999. • [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 2003. • [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

29. 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 2001. • [Paillier 99] Paillier, P.: Public-key cryptosystems based on discrete logarithms residues. In: EUROCRYPT 1999. • [FOPS01] Fujisaki, E., Okamoto, T., Pointcheval, D., Stern, J.: RSA-OAEP is secure under the RSA assumption. In: CRYPTO 2001. • [LL93] Lim, C.H., Lee, P.J.: Another method for attaining security against adaptively chosen ciphertext attacks. In: CRYPTO 1993. • [Shoup01] Shoup, V.: OAEP reconsidered. In: CRYPTO 2001.

30. References • [CFN94] Chor, B., Fiat, A., Naor, M.: Tracing traitors. In: CRYPTO 1994. • [FN93] Fiat, A., Naor, M.: Broadcast encryption. In: CRYPTO 1993. • [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 1991. • [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 1994. • [BF99] Boneh, D., Franklin, M.: An efficient public key traitor tracing scheme. In: CRYPTO 1999. • [BGW05] Boneh, D., Gentry, C., Waters, B.: Collusion resistant broadcast encryption with short ciphertexts and private keys. In: CRYPTO 2005.

31. Thank You Thank You!