How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack
description
Transcript of How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen Ciphertext Attack
How to Construct Multicast Cryptosystems Provably Secure Against Adaptive Chosen
Ciphertext Attack
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
Yitao DuanComputer Science Division, University of California, Berkeley,
02/16/2006 - 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
K3.8K3.1 K3.2 K3.3 K3.4 K3.5 K3.6 K3.7
K2.1 K2.2 K2.3 K2.4
K1.1 K1.2
K0
M1 M2 M5M4M3 M6 M7 M8
Keys Assigned to M1
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 m0 and m1, 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
SK1
SK2
SKn
Client
Decryption Servers
c
c
c
c
The Basics: Threshold Decryption
SK1
SK2
SKn
Client
Decryption Servers
m1
m2
m3
mn
mi = DSKi(c)
The Basics: Threshold Decryption
SK1
SK2
SKn
Client
Decryption Servers
m = η(m1, … )
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 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
PKCThreshold
Decryption
Multicast Encryption
Symmetric distribution of key shares
Asymmetric distribution of key shares
Our Constructions
PKCThreshold
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
• 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]
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 1
Construction 1e
Construction 2
Construction 2
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
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.
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.
Thank You
Thank You!