Cryptography. Lecture 12. Arpita Patra

Transcription

1 Cryptography Lecture 12 Arpita Patra

2 Digital Signatures q In PK setting, privacy is provided by PKE q Integrity/authenticity is provided by digital signatures (counterpart of MACs in PK world) q Definition: A Digital signature scheme Π consists of three PPT algorithms (Gen, Sign, Vrfy): 1 n pk, sk {0, 1} n Gen m {0, 1} * Sign sk σ pk m, σ b {0, 1} Vrfy Ø Randomized Ø pk: public key (verification key) Ø sk: private key (signing key) Ø Usually Randomized Ø σ is signature for m Ø Deterministic Ø b = 0 invalid signature Ø b = 1 valid signature q (pk, sk) plays a different role compared to public-key encryption >> sk signature generation (whereas pk was used for ciphertext generation) >> pk public verification of the signature (whereas sk was used for decryption) q Signatures cannot be obtained by reversing a public-key encryption scheme q Correct ness: Except with a negligible probability over (pk, sk) output by Gen(1 n ), we require the following for every (legal) plaintext m Vrfy pk (m, Sign sk (m)) = 1

3 Digital Signatures : Security q Goal: we want to prevent a situation like the following: Π = (Gen, Sign, Vrfy) m 1 = ( My Lord how are you? ) σ 1 = Sign sk (m 1 ) m 2 = ( Ravana is misbehaving with me ) σ 2 = Sign sk (m 2 ) sk pk

4 Digital Signatures : Security q Goal: we want to prevent a situation like the following: m 1 = ( Ravana is not that bad ) σ 1 = Sign sk (m 1 ) Π = (Gen, Sign, Vrfy) m 2 = ( I am fine here ) σ 2 = Sign sk (m 2 ) sk pk q How to model the above requirement via security experiment? --- Experiment Sig-forge (n) A, Π PPT Attacker A pk m 1,, m q I can forge Π σ 1,, σ q σ i Sign sk (m i ) (m*, σ*) Let me verify Gen(1 n ) Π is existentially-unforgeable/cma if for every PPT A: Pr Sig-forge (n) =1 A, Π negl(n) b = 1 if Vrfy pk (m*, σ*) 0 and (m*, σ*) {(m i, σ i )} b = 0 otherwise

5 MAC vs Digital Signature MAC Digital Signature - Key distribution has to be done apriori. - In multi-verifier scenario, a signer/prover need to hold one secret key for every verifier - Well-suited for closed organization (university, private company, military). Does not work for open environment (Internet Merchant) Not + No completely such assumption correct! needed! Relies on the fact that there is a way to send the public key in an authenticated way to the verifiers + One signer can setup a single public-key/secret key and all the verifiers can use the same public key + Better suited for open environment (Internet) where two parties have not met personally but still want to communicate securely (Internet merchant & Customer) + Very fast computation. Efficient Communication. Only way to do auth in resource-constrained devices such as mobile, RFID, ATM cards etc - NO Public Verifiability & Transferability - Orders of magnitude slower than Private-key. Heavy even for desktop computers while handling many operations at the same time + Public Verifiability & Transferability - NO Non-repudiation (cannot deny only to the person holding the key) + Non-repudiation (cannot deny to anyone)

6 Some Results on Digital Signatures q Feasibility Results for DS: Unlike PKE (which needs more assumption than HF/OWF), DS can be constructed just based on HF (in fact just from OWF) [Rompel STOC 90] q DS Schemes in Practice: >> RSA-FDH (Full Domain Hash) - RSA Assumption + HF PKCS #1 v2.1 >> Digital Signature Algorithm (DSA)- DL + HF- Digital Signature Standard (DSS)

7 Digital Certificates and Public-key Infrastructure (PKI) Public-key World Is pk S indeed a genuine public-key of Sita? (pk S, sk S ) My public-key is pk S Sita Rama

8 Digital Certificates and Public-key Infrastructure (PKI) Trusted Authority PKI (pk M, sk M ) (After verification) cert M S = Sign skm ( Sita s public key is pk S ) Knows that the publickey of is pk M (pk S, sk S ) My public-key is pk S cert M S Sita Rama q Several types of PKI used in practice Ø Single CA, multiple CA, PGP, etc q Public keys of CA are pre-configured in web browsers pk S is a genuine public key if and only if Vrfy pkm ( Sita s public key is pk S, cert M S ) = 1 Ø Programmed to verify the certificates issued by those CAs

9 Putting It All Together TLS (Transport Layer Security) Authenticated Key Exchange Handshake protocol (Public-key crypto) Server Client (Private-key crypto) Authenticated Private Communication (Using keys established by handshake protocol) Record-layer protocol

10 Putting It All Together SSL/TLS (The Handshake Protocol) (pk 1, sk 1 ) (pk 2, sk 2 ) (pk 3, sk 3 ) (pk 4, sk 4 ) CA 1 CA 2 CA 3 CA 4 cert 2 S Certifying that pk S is the public key of the server pk 1, pk 2, pk 3, pk 4 (pre-configured) Server (pk S, sk S ) Client

11 Putting It All Together SSL/TLS (The Handshake Protocol) (pk 1, sk 1 ) (pk 2, sk 2 ) (pk 3, sk 3 ) (pk 4, sk 4 ) transcript CA 1 CA 2 CA 3 CA 4 cert 2 S Supported ciphersuites (hash functions, block ciphers, etc), N C cert 2 S pk 1, pk 2, pk 3, pk 4 (pre-configured) Corresponding ciphersuites, N S, pk S, c (pk S, sk S ) τ C := Mac mk (transcript) Random nonce N C Random nonce N S pmk:= Decaps sks (c) mk:= KDF(pmk, N c, N s ) k C, k C, k S, k S := PRG(mk)? Vrfy mk (transcript, τ C ) = 1 τ S := Mac mk (transcript ) Agreed symmetric keys? Vrfy pk2 (pk S, cert 2 S ) = 1 (c, pmk) Encaps pks (1 n ) mk:= KDF(pmk, N c, N s ) k C, k C, k S, k S := PRG(mk)? Vrfy mk (transcript, τ S ) = 1

12 Putting It All Together SSL/TLS (The Record-layer Protocol) Authenticated communication (k S, k S ) k C, k C, k S, k S Authenticated communication (k C, k C ) k C, k C, k S, k S

13 Public Key Cryptography Whitfield Diffie, Martin E. Hellman: New directions in cryptography. IEEE Transactions on Information Theory 22(6): (1976)

14 What We have seen and not seen? Secure (multiparty) Computation Cryptanalysis Finding flaws/attacks/ insecurities. Side-channels Electronic election, auction, private information retrieval, Outsourcing computation to cloud, Privacy-preserving data mining, signal processing, bioinformatics etc. etc. Leakage Resilient Cryptography Takes into account the side channel information. Special Purpose Encryption Schemes Non-committing Encryption, Deniable Encryption, Id-based Encryption, Attribute-based Encryption, Functional Encryption Homographic Encryption, Fully Homomorphic Encryption Secure + Authenticated Message Communication Secure Storage Special Purpose Digital Signatures Blind Signatures, Group Signature, Signcryption Disc encryption, cloud storage, Cryptography

15 Crypto Zoo We will get Cryptomaniac next semester with course on Secure Computation S Cryptomania: Everything that u can design in Crypto R (x 0,x 1 ) σ x σ Secret Sharing Oblivious Transfer Commitment Schemes Zero Knowledge Proofs Public Key Encryption Hash Functions PRG SPRP MAC Minicrypt: SKC, Digital PRF Signatures One way permutation One way Function Choice is yours; whether u want to confine yourself in Minicrypt or u want turn to a Cryptomaniac.

16 Course on Secure Computation Primitives Definition Paradigms Proof Paradigms >> Oblivious Transfer >> Commitment Schemes >> Zero Knowledge Proofs >> Real World- Ideal World Paradigm >> Universal Composability (UC) Paradigm >> Black-box Reduction >> Non-black-box reduction >> Random-Oracle Model (ROM) >> Secret Sharing >> Threshold Encryption >> Secure Computation in various setting >> Secure Computation of Practical Problems- Set Intersection, Genomic Computation Ø For many constructions based on HF Ø Modeled as a random oracle (a truly random function from X K) Ø Access to H is via oracle calls v To compute H(a), call oracle with a, who returns a random value from co-domain as the output --- once a value is associated as H(a), the association remains fixed for future instances Ø Calls to the oracle are private v If attacker has not queried for H(a), then H(a) remains uniformly random for the attacker >> Byzantine Agreement & Broadcast

17 Concluding Remarks

18

19 El Gamal like KEM Gen(1 n ) (G, o, q, g) h = g x. For random x pk= (G,o,q,g,h,H), sk = x CPA-secure KEM + Encaps pk (1 n ) COA-secure SKE => CPA-secure c = gy for random PKE COA-secure k = H(h y ) = H(g xy. ) SKE (c,k) Dec sk (c) k = H(c x )= H(g xy ) Security 1 Security 2 Security 3 CDH (Weaker than DDH; hard to compute g xy even given g x, g y ) + H is Random Oracle (Random => H behaves like an ideal random function) HDH- Hash Diffie-Hellman (Weaker than DDH but stronger than CDH when Hash function is implemented using known practical ones; hard to distinguish H(g xy ) from a random string {0,1} m even given g x, g y ) where H: {0,1}* -> {0,1} m + No assumption on H. It is incorporated in the above DDH (Strongest Diffie-Hellman Assumption; hard to distinguish g xy from a random group element even given g x, g y ) + Regular H (Regular => The number of elements from G that maps to k is approximately the same for all k)