SECURITY AND VERIFICATION Lecture 4: Cryptography proofs in context Tamara Rezk INDES TEAM, INRIA January 24 th, 2012.

Slides:



Advertisements
Similar presentations
Types and Programming Languages Lecture 4 Simon Gay Department of Computing Science University of Glasgow 2006/07.
Advertisements

Robust Sender Anonymity Tamara Rezk FMCrypto (work in progress) G.Barthe, A.Hevia, Z.Luo, T.Rezk, B.Warinschi April, 28 th – Campinas, Brazil.
Security of Multithreaded Programs by Compilation Tamara Rezk INDES Project, INRIA Sophia Antipolis Mediterranee Joint work with Gilles Barthe, Alejandro.
Cryptography and Game Theory: Designing Protocols for Exchanging Information Gillat Kol and Moni Naor.
Probabilistic Public Key Encryption with Equality Test Duncan S. Wong Department of Computer Science City University of Hong Kong Joint work with Guomin.
SECURITY AND VERIFICATION
Foundations of Cryptography Lecture 10 Lecturer: Moni Naor.
Vote privacy: models and cryptographic underpinnings Bogdan Warinschi University of Bristol 1.
1 How to transform an analyzer into a verifier. 2 OUTLINE OF THE LECTURE a verification technique which combines abstract interpretation and Park’s fixpoint.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Efficient Zero-Knowledge Proof Systems Jens Groth University College London.
SECURITY AND VERIFICATION Lecture 1: Why to prove cryptography? The origins of provable cryptography Tamara Rezk INDES TEAM, INRIA January 3 rd, 2012.
CS555Topic 191 Cryptography CS 555 Topic 19: Formalization of Public Key Encrpytion.
Security Definitions in Computational Cryptography
CS 395T Computational Soundness of Formal Models.
Introduction to Computability Theory
Co-operative Private Equality Test(CPET) Ronghua Li and Chuan-Kun Wu (received June 21, 2005; revised and accepted July 4, 2005) International Journal.
Asymmetric Cryptography part 1 & 2 Haya Shulman Many thanks to Amir Herzberg who donated some of the slides from
Overview of Cryptography Anupam Datta CMU Fall A: Foundations of Security and Privacy.
Princeton University COS 433 Cryptography Fall 2005 Boaz Barak COS 433: Cryptography Princeton University Fall 2005 Boaz Barak Lecture 2: Perfect Secrecy.
Protocol Composition Logic Arnab Roy joint work with A. Datta, A. Derek, N. Durgin, J.C. Mitchell, D. Pavlovic CS259: Security Analysis of Network Protocols,
Operational Semantics Semantics with Applications Chapter 2 H. Nielson and F. Nielson
1 CIS 5371 Cryptography 9. Data Integrity Techniques.
CS555Spring 2012/Topic 41 Cryptography CS 555 Topic 4: Computational Approach to Cryptography.
Princeton University COS 433 Cryptography Fall 2005 Boaz Barak COS 433: Cryptography Princeton University Fall 2005 Boaz Barak Lecture 2: Perfect Secrecy.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Automatic Implementation of provable cryptography for confidentiality and integrity Presented by Tamara Rezk – INDES project - INRIA Joint work with: Cédric.
CMSC 414 Computer and Network Security Lecture 3 Jonathan Katz.
8. Data Integrity Techniques
Digital signature in automatic analyses for confidentiality against active adversaries Ilja Tšahhirov, Peeter Laud.
Cryptography Lecture 8 Stefan Dziembowski
CIS 5371 Cryptography Introduction.
Reading and Writing Mathematical Proofs
1 Lect. 13 : Public Key Encryption RSA ElGamal. 2 Shamir Rivest Adleman RSA Public Key Systems  RSA is the first public key cryptosystem  Proposed in.
Background on security
CS555Spring 2012/Topic 111 Cryptography CS 555 Topic 11: Encryption Modes and CCA Security.
MA/CSSE 473 Day 10 Primality testing summary Data Encryption RSA.
IND-CPA and IND-CCA Concepts Summary  Basic Encryption Security Definition: IND-CPA  Strong Encryption Security Definition: IND-CCA  IND-CPA, IND-CCA.
Cryptography Lecture 2 Arpita Patra. Summary of Last Class  Introduction  Secure Communication in Symmetric Key setting >> SKE is the required primitive.
1 Reasoning about Concrete Security in Protocol Proofs A. Datta, J.Y. Halpern, J.C. Mitchell, R. Pucella, A. Roy.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
Chapter 3 Part II Describing Syntax and Semantics.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Secure Computation Lecture Arpita Patra. Recap >> Improving the complexity of GMW > Step I: Offline: O(n 2 c AND ) OTs; Online: i.t., no crypto.
Digital Cash Protocols: A Formal Presentation Delwin F. Lee & Mohamed G.Gouda The University of Texas at Austin Presented by Savitha Krishnamoorthy CIS.
CS555Spring 2012/Topic 71 Cryptography CS 555 Topic 7: Stream Ciphers and CPA Security.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
1 CIS 5371 Cryptography 1.Introduction. 2 Prerequisites for this course  Basic Mathematics, in particular Number Theory  Basic Probability Theory 
Process Algebra (2IF45) Basic Process Algebra Dr. Suzana Andova.
Cryptography Lecture 10 Arpita Patra © Arpita Patra.
Cryptography Lecture 3 Arpita Patra © Arpita Patra.
A plausible approach to computer-aided cryptographic proofs (a collection of thoughts) Shai Halevi – May 2005.
1 CIS 5371 Cryptography 1.Introduction. 2 Prerequisites for this course  Basic Mathematics, in particular Number Theory  Basic Probability Theory 
Cryptography Lecture 6 Arpita Patra. Quick Recall and Today’s Roadmap >> MAC for fixed-length messages >> Domain Extension for MAC >> Authenticated Encryption:
Verified protocol implementations in F*
B504/I538: Introduction to Cryptography
Authenticated encryption
Group theory exercise.
Secrecy of (fixed-length) stream ciphers
Topic 11: Authenticated Encryption + CCA-Security
Proving Properties of Recursive Functions and Data Structures
Cryptography Lecture 3 Arpita Patra © Arpita Patra.
B504/I538: Introduction to Cryptography
Soundness of Formal Encryption in the Presence of Key Cycles
Cryptography Lecture 12 Arpita Patra © Arpita Patra.
This Lecture Substitution model
The power of Pairings towards standard model security
COP4020 Programming Languages
Presentation transcript:

SECURITY AND VERIFICATION Lecture 4: Cryptography proofs in context Tamara Rezk INDES TEAM, INRIA January 24 th, 2012

QUESTIONS OF TODAY What can fail when encryption is put in larger program contexts? How to automatically verify it?

What can fail when encryption is put in larger program contexts? Security relying on CPA ? 1. x:= E (s,y) 2. k e, k d := G e (); k’ e, k’ d := G e (); y:= E (x, k e ); x’:= D (y, k’ d ) 3. k e, k d := G e (); y:= E (x, k e ); y’:= E (k d, k e ) 4. k e, k d := G e (); k’ e, k’ d := G e (); if (y=0) then {k e := k’ e } else {skip} ; y’= E (x, k e )

What can fail when encryption is put in larger program contexts? Security relying on CPA ? 1. x:= E (s,y) The program is not secure if y is not an encryption key generated by the generation function.

What can fail when encryption is put in larger program contexts? Security relying on CPA ? k e, k d := G e (); k’ e, k’ d := G e (); y:= E (x, k e ); x’:= D (y, k’ d ) The program is not secure if a different decryption key does not match the encryption key.

What can fail when encryption is put in larger program contexts? Security relying on CPA ? k e, k d := G e (); y:= E (x, k e ); y’:= E (k d, k e ) The CPA property does not state anything in case that the adversary is given the decryption key, even if this one is encrypted. This is called a key cycle. A key cycle occurs when there is an encryption of the decryption key with the corresponding encryption key. A longer key cycle: E ( E (k d, k’ e ), k e )

What can fail when encryption is put in larger program contexts? Security relying on CPA ? k e, k d := G e (); k’ e, k’ d := G e (); if (y=0) then {k e := k’ e } else {skip} ; y’= E (x, k e ) If y can hold the value 0 then the encryption keys are swaped. In this case a decryption x= D (u’, k d ) may fail.

What can fail when encryption is put in larger program contexts? Security relying on CPA ? Even if we use encryption schemes that are proved to be Resistent to chosen plaintext attacks, we need to check: Keys are correctely genereated Decryption key is not leaked to the adversary There are no key cycles No accidental leak of private information to the adversary No mix of different encryption schemes

What can fail when encryption is put in larger program contexts? Security relying on CPA We will state formally the security property desired and we will see an automatic verification method: Property: computational non-interference Method (static) : a type system

Computational Non-Interference for V (CNI) CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; P ; A The adversary does not have access to variables in B i, neither to b. It has access to variables V in I

Computational Non-Interference for V (CNI) CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; P ; A i I only writes variables in V. B i only writes variables outside V. A program P is CNI for variables V if for all I, B i, the advantage of A is negligible on a security parameter.

CNI = b:={0,1} I if (b=0) then {x:=1} else {x:={0,1}}; g:=x; A ; The program “g:=x “ is not CNI (the adversary cannot see x, but can see g).

CNI = b:={0,1} I P[A] ; The program is CNI if the adversary and the program P do not have b.

Types A type T contains a data type t and a security level l T:= t(l) l := L | H with L ≤ H t:= DATA | ENC T k | KE T k | KD T k k := K | K1 | K2 | …

Typing rules A typing rule is of the form: constrains F ├ commmand : l constrains F ├ expression: t(l) where F is a mapping from variables to types

Typing rules Typing rules for expressions: F ├ v: DATA (L) F ├ x: F(x) F ├ ei : DATA(li) l = U li F ├ op (e1,…, en) : DATA (l)

Typing rules Typing rules for a value expression (VAL): F ├ v: DATA (L) Values are always typed as public and DATA. For example: F ├ 0: DATA (L)

Typing rules Typing rules for a variable expression (VAR): F ├ x: F(x) Variables are typed according to map F. If F(y) = ENC DATA(L) K (L) then F ├ y: ENC DATA(L) K (L)

Typing rules Typing rules for an operation expression (OP): F ├ ei : DATA(li) l = U li F ├ op (e1,…, en) : DATA (l) Operations on expressions are always of type DATA. The security level is the join of the security levels of the parameters. For example: If F(y) = DATA (H ) then F ├ y + 3 : DATA (H) If F(y) = ENC DATA(L) K (L) then y + 3 is not typable

Typing rules Typing rule for assignment command (AS): F(x) = t(l) F ├ e : t(l’) l’ ≤ l F ├ x:= e : l The typing rule prevents explicit information leakage. For example, if F(x) = DATA (L) and F(y) = DATA (H) then x := y is not typable but y:=x is F ├ y: = x : H

Typing rules Typing rule for assignment command: F(x) = t(l) F ├ e : t(l’) l’ ≤ l F ├ x:= e : l The typing rule also prevents a violation of the data type wrt cryptographic types. For example, if F(x) = DATA (L) and F(y) = KE DATA(L) K (L) then neither x := y or y:=x are typable

Typing rules Typing rule for assignment command: F(x) = t(l) F ├ e : t(l’) l’ ≤ l F ├ x:= e : l Notice that in this rule there is NO INFORMATION FLOW from high (H) to low (L).

Typing rules Typing rule for if command (IF): F ├ e : DATA(l) F ├ P1 : l1 F ├ P2 : l2 l≤ l1 ∩ l F ├ if e then P1 else P2 : l The typing rule prevents implicit flows of information. For example: if F(y) = DATA(H) and F(x) = DATA(L) then if y=1 then x:=1 else x:=0 is not typable.

Typing rules Typing rule for if command (WHILE): F ├ e : DATA(l) F ├ P : l1 l≤ l F ├ while e P : l The typing rule prevents implicit flows of information. For example: if F(y) = DATA(H) and F(x) = DATA(L) then F ├ while x=1 (y:= y + 1) : L

Typing rules Typing rule for probabilistic function command (PROBFUN): F(xi) = DATA(li) l = ∩ li F ├ yi : DATA(li’) li ≤ l F ├ x1, x2.. := f(y1,y2, …) : l Probabilistic function {0,1} has no parameters and is trivially typable F ├ x : = {0,1} : F(x) If F(ke) = KE T K (L) and F(kd) = KD T K (L) then ke, kd:= G e () is not typable

Typing rules Typing rule for sequence (SEQ): F ├ c1 :l F ├ c2:l’ F ├ c1; c2: l ∩ l’ Sequence is typable if all subcommands are typable.

F(y) = t’(l’) l’’ ≤ l’ t’= DATA F ├ y: t’(l’) F(x) = t(l)F(x) = t’(l’’ ) OP F ├ y+1 : t’(l’) AS AS F ├ x:=1 :l F ├ y:=x+1:l’ SEQ F ├ x:= 1; y:= x + 1 : l1 To see that program is typable solve the constrains: l1= l ∩ l’ F(x) = t(l) and F(x) = t’(l’’ ) F(y) = t’(l’) and t’= DATA l≤ l’ A N EXAMPLE Typing derivation

Typing rules Typing rule for sequence: F ├ c1 :l F ├ c2:l’ F ├ c1; c2: l ∩ l’ Sequence is typable if all subcommands are typable.

Typing rules Typing rule for key generation (GEN): F (ke) = KE T K (L) F (kd) = KD T K (H) F ├ ke, kd: = G e () : L Notice that the type T must coincide as well as key label K for the corresponding pair of keys.

Typing rules F (ke) = KE T K (L) F (kd) = KD T K (H) GEN F ├ ke, kd: = G e () : L A key generation command can also be typed by the PROBFUN typing rule, if the types for ke and kd are DATA: F (ke) = DATA (L) F (kd) = DATA (H) PROBFUN F ├ ke, kd: = G e () : L

Typing rules F (ke) = KE t(H) K (L) F (x) = ENC t(H) K (L) F(y) = t(H) ENC F ├ x:= E (y,ke) : L Notice that in this rule there IS INFORMATION FLOW from high (H) to low (L). But if the encryption scheme is CPA then it is “secure” to have it.

Typing rules F (ke) = KE t(H) K (L) F (x) = ENC t(H) K (L) F(y) = t(H) ENC F ├ x:= E (y,ke) : L If there is no flow of information, encryption can still be typable by PROBFUN: F (ke) = DATA(L) F (x) = DATA(L) F(y) = t(L) PROBFUN F ├ x:= E (y,ke) : L

Theorem If 1. program P is typable with F, F ├ P: l 2. all encryption schemes used in P are CPA 3. each key label K in F is used for at most one key generation command typed with GEN then P is CNI for the set of L variables. We will prove this using games.

Lemma If 1. program P is typable with F, F ├ P: l 2. neither rule ENC or GEN are used to type P then P is CNI for the set of L variables. Furthermore Pr[CNI(P) ; g=b] = 1/2 The theorem is a generalization of this lemma. It is useful for the proof of the theorem. We will prove this lemma using games.

Lemma If 1. program P is typable with F, F ├ P: l 2. neither rule ENC or GEN are used to type P then P is CNI for the set of L variables. The proof is by structural induction on P, using the game based technique.

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; P ; A We will prove it for base cases: when P is a single command.

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; x:=e ; A Two cases to analyze: either F(x) = t(L) or F(x) = t(H).

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; x:=e ; A If F(x) = t(H), then by moving the command to B i, by subexpression elimination, we obtain a valid CNI command.

Proof CNI1 = b:={0,1} ; I if (b=0) then { B 0; x:=e } else { B 1; x:=e }; A If F(x) = t(H), then by moving the command to B i, by subexpression elimination, we obtain a valid CNI command.

Proof CNI1 = b:={0,1} ; I if (b=0) then { B 0; x:=e } else { B 1; x:=e }; A Since the adversary does not have access to variables in B i, we can apply deadcode

Proof CNI2 = b:={0,1} ; I A Since the adversary does not have access to variables in B i, we can apply deadcode and CNI1≈ g CNI2 By semantics probability of the adversary of guessing b is ½. End of the case for F(x) = t(H).

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; x:=e ; A Two cases to analyze: either F(x) = t(L) or F(x) = t(H).

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; x:=e ; A If F(x) = t(L), and because by assignment rule there is no flow from high to low, we know that e contains low variables. Then by moving the command to I, by swap (code motion), we obtain a valid CNI command.

Proof CNI1 = b:={0,1} ; I ; x:=e if (b=0) then { B 0 } else { B 1 }; A Since the adversary does not have access to variables in B i, we can apply deadcode

Proof CNI2 = b:={0,1} ; I A Since the adversary does not have access to variables in B i, we can apply deadcode and CNI1≈ g CNI2 By semantics probability of the adversary of guessing b is ½. End of the case for F(x) = t(L).

Proof CNI = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; if e then P1 else P2 ; A If it is typed as L, by the expression typing rules variables in e are L. Hence, for each execution of CNI the value of e is determined by command I. We will do two transformations: one for when the value of e is true and one for false (the case false is analog).

Proof CNI1 = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; P1 ; A If the value of e is true then the CNI program is equivalent to CNI1. By inductive hypothesis we conclude.

Proof CNI1 = b:={0,1} ; I if (b=0) then { B 0 } else { B 1 }; P1 ; A If the value of e is true then the CNI program is equivalent to CNI1. By inductive hypothesis we conclude. Other cases as exercise.

Theorem If 1. program P is typable with F, F ├ P: l 2. all encryption schemes used in P are CPA 3. each key label K in F is used for at most one key generation command typed with GEN then P is CNI for the set of L variables. We will prove this using games.

Proof sketch We eliminate one key label at the time to obtain P\K. P\K only encrypts 0s for each message m encrypted in P. We show that P\K can be typable without encryption rules. We replace in P, encryption by call to the CPA oracle E. We obtain P* that encrypts either m or 0. CPA(P*) = b:={0,1};ke,kd:= G(); b1:={0,1}; I; if b1 then B0 else B1; P*; A ; if b1=g1 then g:=1 else g:=0

Proof sketch If P is x:= E (y,ke) then P* is x0:= 0; x1:=y; E ; x:= c and P\K is x:= E (0,ke)

READING Slides, Notes, Bibliography Slides and exercises: www-sop.inria.fr/members/Tamara.Rezk/teaching Semantics and Program Analysis of Computationally Secure Information Flow - Laud Cryptographically sound implementations for typed information-flow security – Fournet, Rezk