Formal Methods and Cryptography Lecture 25 Formal Methods Formal - - PowerPoint PPT Presentation

formal methods and cryptography
SMART_READER_LITE
LIVE PREVIEW

Formal Methods and Cryptography Lecture 25 Formal Methods Formal - - PowerPoint PPT Presentation

Formal Methods and Cryptography Lecture 25 Formal Methods Formal Methods Logical foundations of computer science Formal Methods Logical foundations of computer science A language that machines can understand Formal Methods Logical


slide-1
SLIDE 1

Formal Methods and Cryptography

Lecture 25

slide-2
SLIDE 2

Formal Methods

slide-3
SLIDE 3

Formal Methods

Logical foundations of computer science

slide-4
SLIDE 4

Formal Methods

Logical foundations of computer science A language that “machines can understand”

slide-5
SLIDE 5

Formal Methods

Logical foundations of computer science A language that “machines can understand” To specify a computational procedure fully formally

slide-6
SLIDE 6

Formal Methods

Logical foundations of computer science A language that “machines can understand” To specify a computational procedure fully formally Don’ t always need a computer: language abstracts away details not relevant to properties of interest

slide-7
SLIDE 7

Formal Methods

Logical foundations of computer science A language that “machines can understand” To specify a computational procedure fully formally Don’ t always need a computer: language abstracts away details not relevant to properties of interest Widely applied in practice

slide-8
SLIDE 8

Formal Methods

Logical foundations of computer science A language that “machines can understand” To specify a computational procedure fully formally Don’ t always need a computer: language abstracts away details not relevant to properties of interest Widely applied in practice Ensures that the procedures designed/analyzed and those implemented are the same

slide-9
SLIDE 9

Formal Methods

Logical foundations of computer science A language that “machines can understand” To specify a computational procedure fully formally Don’ t always need a computer: language abstracts away details not relevant to properties of interest Widely applied in practice Ensures that the procedures designed/analyzed and those implemented are the same Can automate analysis of the designed procedures

slide-10
SLIDE 10

Formal Methods in Cryptography

slide-11
SLIDE 11

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone

slide-12
SLIDE 12

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone A language to unambiguously specify cryptographic protocols and the whole system (in terms of basic building blocks)

slide-13
SLIDE 13

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone A language to unambiguously specify cryptographic protocols and the whole system (in terms of basic building blocks) Automated analysis

slide-14
SLIDE 14

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone A language to unambiguously specify cryptographic protocols and the whole system (in terms of basic building blocks) Automated analysis Security definitions for various tasks are (were) often a list

  • f intuitive high-level properties that must hold in

adversarial environments

slide-15
SLIDE 15

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone A language to unambiguously specify cryptographic protocols and the whole system (in terms of basic building blocks) Automated analysis Security definitions for various tasks are (were) often a list

  • f intuitive high-level properties that must hold in

adversarial environments Formal methods Goal: to be able to analyze any given protocol and see if it satisfies these properties

slide-16
SLIDE 16

Formal Methods in Cryptography

Motivation: security bugs even in simple protocols, if system is under-specified; exhaustive analysis by hand is error-prone A language to unambiguously specify cryptographic protocols and the whole system (in terms of basic building blocks) Automated analysis Security definitions for various tasks are (were) often a list

  • f intuitive high-level properties that must hold in

adversarial environments Formal methods Goal: to be able to analyze any given protocol and see if it satisfies these properties As opposed to finding one protocol (by hand) that satisfies the properties

slide-17
SLIDE 17

Formal Methods in Cryptography

slide-18
SLIDE 18

Formal Methods in Cryptography

Outline:

slide-19
SLIDE 19

Formal Methods in Cryptography

Outline: Develop a formal language for modeling the entire system (protocol, adversary, environment) and its evolution

slide-20
SLIDE 20

Formal Methods in Cryptography

Outline: Develop a formal language for modeling the entire system (protocol, adversary, environment) and its evolution Use abstractions of cryptographic primitives like encryption

slide-21
SLIDE 21

Formal Methods in Cryptography

Outline: Develop a formal language for modeling the entire system (protocol, adversary, environment) and its evolution Use abstractions of cryptographic primitives like encryption Define security properties in this language

slide-22
SLIDE 22

Formal Methods in Cryptography

Outline: Develop a formal language for modeling the entire system (protocol, adversary, environment) and its evolution Use abstractions of cryptographic primitives like encryption Define security properties in this language Given any concrete protocol, map it to the formal language, and use standard formal method tools to automatically analyze it for the security properties

slide-23
SLIDE 23

Formal Methods in Cryptography

Outline: Develop a formal language for modeling the entire system (protocol, adversary, environment) and its evolution Use abstractions of cryptographic primitives like encryption Define security properties in this language Given any concrete protocol, map it to the formal language, and use standard formal method tools to automatically analyze it for the security properties Ensure that security/insecurity in the formal model has useful implications in a more realistic model

slide-24
SLIDE 24

Modeling

slide-25
SLIDE 25

Modeling

Typically, adversary controls the network

slide-26
SLIDE 26

Modeling

Typically, adversary controls the network A “process algebra” or a logic framework to describe what can happen in the system

slide-27
SLIDE 27

Modeling

Typically, adversary controls the network A “process algebra” or a logic framework to describe what can happen in the system Dolev-Yao algebra: Parties can use keys to “encrypt” messages to get opaque symbols that can be operated on only if key is also provided. Deterministic encryption.

slide-28
SLIDE 28

Modeling

Typically, adversary controls the network A “process algebra” or a logic framework to describe what can happen in the system Dolev-Yao algebra: Parties can use keys to “encrypt” messages to get opaque symbols that can be operated on only if key is also provided. Deterministic encryption. BAN logic [Burrows-Abadi-Needham]: principals (parties) can “say” or “see” messages, and “believe” statements like “A said M” or “A believes B said M”. Includes a notion of symmetric keys and public/private keys used for “encryption” (or rather, signcryption)

slide-29
SLIDE 29

Modeling

Typically, adversary controls the network A “process algebra” or a logic framework to describe what can happen in the system Dolev-Yao algebra: Parties can use keys to “encrypt” messages to get opaque symbols that can be operated on only if key is also provided. Deterministic encryption. BAN logic [Burrows-Abadi-Needham]: principals (parties) can “say” or “see” messages, and “believe” statements like “A said M” or “A believes B said M”. Includes a notion of symmetric keys and public/private keys used for “encryption” (or rather, signcryption) spi calculus: incorporates an “encryption” primitive into pi calculus which is used to model concurrent, communicating systems

slide-30
SLIDE 30

Modeling

slide-31
SLIDE 31

Modeling

e.g. Dolev-Yao

slide-32
SLIDE 32

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms

slide-33
SLIDE 33

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms Operations: send/receive terms; pick “nonces”; pair/separate; “encrypt”/“decrypt”

slide-34
SLIDE 34

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms Operations: send/receive terms; pick “nonces”; pair/separate; “encrypt”/“decrypt” For each user X, public operation EX and private

  • peration DX
slide-35
SLIDE 35

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms Operations: send/receive terms; pick “nonces”; pair/separate; “encrypt”/“decrypt” For each user X, public operation EX and private

  • peration DX

DX (EX(m)) can be rewritten as m

slide-36
SLIDE 36

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms Operations: send/receive terms; pick “nonces”; pair/separate; “encrypt”/“decrypt” For each user X, public operation EX and private

  • peration DX

DX (EX(m)) can be rewritten as m Separate(Pair(a,b)) gives a,b

slide-37
SLIDE 37

Modeling

e.g. Dolev-Yao Term-rewriting algebra: operations that can lead to new events are defined by rules for writing new terms Operations: send/receive terms; pick “nonces”; pair/separate; “encrypt”/“decrypt” For each user X, public operation EX and private

  • peration DX

DX (EX(m)) can be rewritten as m Separate(Pair(a,b)) gives a,b No other rewritings; each party can use terms it received and rewrite them (according to the protocol); adversary can obtain the closure of all terms sent out in the network

slide-38
SLIDE 38

Security Properties - 1

slide-39
SLIDE 39

Security Properties - 1

Valid trace of a system: a sequence of events possible in the system (for the given protocol and an arbitrary adversary)

slide-40
SLIDE 40

Security Properties - 1

Valid trace of a system: a sequence of events possible in the system (for the given protocol and an arbitrary adversary) Event: input/output/communication by parties or adversary

slide-41
SLIDE 41

Security Properties - 1

Valid trace of a system: a sequence of events possible in the system (for the given protocol and an arbitrary adversary) Event: input/output/communication by parties or adversary Security property is defined for a trace, and a protocol is called secure if all valid traces satisfy the security property

slide-42
SLIDE 42

Security Properties - 1

Valid trace of a system: a sequence of events possible in the system (for the given protocol and an arbitrary adversary) Event: input/output/communication by parties or adversary Security property is defined for a trace, and a protocol is called secure if all valid traces satisfy the security property e.g.: For a key-agreement protocol, a trace is insecure if it has Alice outputting a nonce R (i.e., event [Alice:(output,R)] ) and the adversary also outputting R (event [Eve:(output,R)] )

slide-43
SLIDE 43

Security Properties - 1

Valid trace of a system: a sequence of events possible in the system (for the given protocol and an arbitrary adversary) Event: input/output/communication by parties or adversary Security property is defined for a trace, and a protocol is called secure if all valid traces satisfy the security property e.g.: For a key-agreement protocol, a trace is insecure if it has Alice outputting a nonce R (i.e., event [Alice:(output,R)] ) and the adversary also outputting R (event [Eve:(output,R)] ) e.g.: (in BAN logic) “(A believes B said X) at some point ⇒ (B said X) before that point”

slide-44
SLIDE 44

Security Properties - 2

slide-45
SLIDE 45

Security Properties - 2

Security in spi calculus (inherited from pi calculus) essentially same as simulation-based security

slide-46
SLIDE 46

Security Properties - 2

Security in spi calculus (inherited from pi calculus) essentially same as simulation-based security Observational Equivalence: Two systems P, Q are

  • bservationally equivalent if for all systems (environments) Z,

the systems (Z|P) and (Z|Q) produce the same outputs

slide-47
SLIDE 47

Security Properties - 2

Security in spi calculus (inherited from pi calculus) essentially same as simulation-based security Observational Equivalence: Two systems P, Q are

  • bservationally equivalent if for all systems (environments) Z,

the systems (Z|P) and (Z|Q) produce the same outputs To define security of a protocol, define an ideal protocol (think as ideal functionality, combined with a simulator for the “dummy adversary”) and require that the two systems are

  • bservationally equivalent
slide-48
SLIDE 48

Security Properties - 2

Security in spi calculus (inherited from pi calculus) essentially same as simulation-based security Observational Equivalence: Two systems P, Q are

  • bservationally equivalent if for all systems (environments) Z,

the systems (Z|P) and (Z|Q) produce the same outputs To define security of a protocol, define an ideal protocol (think as ideal functionality, combined with a simulator for the “dummy adversary”) and require that the two systems are

  • bservationally equivalent

Limitation: original spi calculus incorporated an ideal shared-key encryption and no other cryptographic features; extensions typically limited to secure communication tasks

slide-49
SLIDE 49

An Example

slide-50
SLIDE 50

An Example

Needham-Schroeder-Lowe (public-key) protocol

slide-51
SLIDE 51

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication”

slide-52
SLIDE 52

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication” Or, for “key agreement”

slide-53
SLIDE 53

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication” Or, for “key agreement” Uses an ideal encryption (or signcryption) to let two parties exchange nonces so that each should know that the nonce came from the other party (whose public-key it already has)

slide-54
SLIDE 54

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication” Or, for “key agreement” Uses an ideal encryption (or signcryption) to let two parties exchange nonces so that each should know that the nonce came from the other party (whose public-key it already has) The nonce should be useful as a secret shared-key

slide-55
SLIDE 55

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication” Or, for “key agreement” Uses an ideal encryption (or signcryption) to let two parties exchange nonces so that each should know that the nonce came from the other party (whose public-key it already has) The nonce should be useful as a secret shared-key Most formal frameworks use this example, to show that they can find the bug in the original Needham-Schroeder protocol (1978)

slide-56
SLIDE 56

An Example

Needham-Schroeder-Lowe (public-key) protocol For “mutual authentication” Or, for “key agreement” Uses an ideal encryption (or signcryption) to let two parties exchange nonces so that each should know that the nonce came from the other party (whose public-key it already has) The nonce should be useful as a secret shared-key Most formal frameworks use this example, to show that they can find the bug in the original Needham-Schroeder protocol (1978) Or new bugs in extended settings

slide-57
SLIDE 57

Initiator (Minit): initialize(self, other); newrandom(na); pair(self, na, a na); encrypt(other, a na, a na enc); send(a na enc); receive(b na nb enc); decrypt(self, b na nb enc, b na nb); separate(b na nb, b, na nb); test(b == other); separate(na nb, na2, nb); test(na == na2); encrypt(other, nb, nb enc); send(nb enc); pair(self, other, a b); pair(a b, x , a b x); pair(Finished, a b x, out);

  • utput(out);

done; Responder (Mresp): initialize(self, other); receive(a na enc); decrypt(self, a na enc, a na); separate(a na, a, na); test(a == other); newrandom(nb); pair(other, na, b na); pair(b na, nb, b na nb); encrypt(other, b na nb, b na nb enc); send(b na nb enc); receive(nb enc); decrypt(self, nb enc, nb2); test(nb == nb2); pair(self, x , b a x); pair(Finished, b a x, out);

  • utput(out);

done; Version 1: x=na (Initiator’s nonce output as secret key) Version 2: x=nb (Responder’s nonce output as secret key)

[NSL protocol, from Canetti-Herzog 2006]

slide-58
SLIDE 58

Automated Analysis

slide-59
SLIDE 59

Automated Analysis

Not necessarily very efficient

slide-60
SLIDE 60

Automated Analysis

Not necessarily very efficient Often NP-hard (or even P-SPACE hard). Typical algorithms are exponential in the size of the system

slide-61
SLIDE 61

Automated Analysis

Not necessarily very efficient Often NP-hard (or even P-SPACE hard). Typical algorithms are exponential in the size of the system Typically undecidable when allowing an unbounded number

  • f concurrent sessions
slide-62
SLIDE 62

Automated Analysis

Not necessarily very efficient Often NP-hard (or even P-SPACE hard). Typical algorithms are exponential in the size of the system Typically undecidable when allowing an unbounded number

  • f concurrent sessions

Popular models (Dolev-Yao, BAN logic, spi calculus) have reasonably efficient algorithms for analyzing a variety of security properties, if the system is small (e.g., single session)

slide-63
SLIDE 63

Automated Analysis

Not necessarily very efficient Often NP-hard (or even P-SPACE hard). Typical algorithms are exponential in the size of the system Typically undecidable when allowing an unbounded number

  • f concurrent sessions

Popular models (Dolev-Yao, BAN logic, spi calculus) have reasonably efficient algorithms for analyzing a variety of security properties, if the system is small (e.g., single session) Sometimes state-exploration (using model-checking tools) can be used to discover (some) flaws, but does not prove security

slide-64
SLIDE 64

What does Security in a Formal Model mean?

slide-65
SLIDE 65

What does Security in a Formal Model mean?

“Encryption” as proposed in most of the formal models attributes message secrecy, key-anonymity, non-malleability, circular-encryption security, MAC/signature properties and much more (while requiring it to be deterministic)

slide-66
SLIDE 66

What does Security in a Formal Model mean?

“Encryption” as proposed in most of the formal models attributes message secrecy, key-anonymity, non-malleability, circular-encryption security, MAC/signature properties and much more (while requiring it to be deterministic) Possibly achievable in random-oracle model or generic-group model

slide-67
SLIDE 67

What does Security in a Formal Model mean?

“Encryption” as proposed in most of the formal models attributes message secrecy, key-anonymity, non-malleability, circular-encryption security, MAC/signature properties and much more (while requiring it to be deterministic) Possibly achievable in random-oracle model or generic-group model Security guarantee similar in spirit to these heuristic models

slide-68
SLIDE 68

What does Security in a Formal Model mean?

“Encryption” as proposed in most of the formal models attributes message secrecy, key-anonymity, non-malleability, circular-encryption security, MAC/signature properties and much more (while requiring it to be deterministic) Possibly achievable in random-oracle model or generic-group model Security guarantee similar in spirit to these heuristic models Security against adversaries who use only operations permitted by the formal model

slide-69
SLIDE 69

What does Security in a Formal Model mean?

slide-70
SLIDE 70

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models?

slide-71
SLIDE 71

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model

slide-72
SLIDE 72

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model A formal model is “sound” if we can do the following:

slide-73
SLIDE 73

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model A formal model is “sound” if we can do the following: Translate protocol in computational model to formal

  • model. Get security guarantee for it in formal model.

This should imply security of the original protocol in the computational model

slide-74
SLIDE 74

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model A formal model is “sound” if we can do the following: Translate protocol in computational model to formal

  • model. Get security guarantee for it in formal model.

This should imply security of the original protocol in the computational model

In a specific format, using

  • nly specific

primitives

slide-75
SLIDE 75

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model A formal model is “sound” if we can do the following: Translate protocol in computational model to formal

  • model. Get security guarantee for it in formal model.

This should imply security of the original protocol in the computational model

In a specific format, using

  • nly specific

primitives If primitives satisfy certain security definitions

slide-76
SLIDE 76

What does Security in a Formal Model mean?

Can we develop strong underlying crypto primitives to implement the “encryption” as used in these formal models? Not quite, but maybe strong enough to translate the formal-model guarantees to security guarantees in the computational model A formal model is “sound” if we can do the following: Translate protocol in computational model to formal

  • model. Get security guarantee for it in formal model.

This should imply security of the original protocol in the computational model Soundness of the formal model and formal security property for the computational task and primitive used

In a specific format, using

  • nly specific

primitives If primitives satisfy certain security definitions

slide-77
SLIDE 77

Soundness of Formal Models

slide-78
SLIDE 78

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001)

slide-79
SLIDE 79

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001) Shows soundness for a class of protocols/tasks: protocol secure for the task, if formal protocol has a certain security property in the formal model, and protocol uses CCA secure encryption in place of ideal encryptions in the formal model

slide-80
SLIDE 80

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001) Shows soundness for a class of protocols/tasks: protocol secure for the task, if formal protocol has a certain security property in the formal model, and protocol uses CCA secure encryption in place of ideal encryptions in the formal model Since then extended to various authentication/key-agreement-like tasks (and some computation tasks), against passive and active adversaries, using different formal models (algebras, spi-calculus)

slide-81
SLIDE 81

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001) Shows soundness for a class of protocols/tasks: protocol secure for the task, if formal protocol has a certain security property in the formal model, and protocol uses CCA secure encryption in place of ideal encryptions in the formal model Since then extended to various authentication/key-agreement-like tasks (and some computation tasks), against passive and active adversaries, using different formal models (algebras, spi-calculus) Recent works incorporate signatures, NIZK proofs etc.

slide-82
SLIDE 82

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001) Shows soundness for a class of protocols/tasks: protocol secure for the task, if formal protocol has a certain security property in the formal model, and protocol uses CCA secure encryption in place of ideal encryptions in the formal model Since then extended to various authentication/key-agreement-like tasks (and some computation tasks), against passive and active adversaries, using different formal models (algebras, spi-calculus) Recent works incorporate signatures, NIZK proofs etc. Typically each work considers a specific task, develops a security criterion in a specific formal model, and establishes soundness for protocols using specific crypto primitives (like CCA2 encryption)

slide-83
SLIDE 83

Soundness of Formal Models

Initiated by Abadi-Rogaway (2001) Shows soundness for a class of protocols/tasks: protocol secure for the task, if formal protocol has a certain security property in the formal model, and protocol uses CCA secure encryption in place of ideal encryptions in the formal model Since then extended to various authentication/key-agreement-like tasks (and some computation tasks), against passive and active adversaries, using different formal models (algebras, spi-calculus) Recent works incorporate signatures, NIZK proofs etc. Typically each work considers a specific task, develops a security criterion in a specific formal model, and establishes soundness for protocols using specific crypto primitives (like CCA2 encryption) Somewhat general frameworks: e.g., Backes et al. (CCS 2009)

slide-84
SLIDE 84

Soundness of Formal Models

slide-85
SLIDE 85

Soundness of Formal Models

Several challenges

slide-86
SLIDE 86

Soundness of Formal Models

Several challenges Traditional models usually deterministic (except for picking nonces, and possibly within the encryption operation), but for many interesting tasks cryptographic protocols typically use more randomness

slide-87
SLIDE 87

Soundness of Formal Models

Several challenges Traditional models usually deterministic (except for picking nonces, and possibly within the encryption operation), but for many interesting tasks cryptographic protocols typically use more randomness If model is too general, becomes hard/intractable to automatically reason

slide-88
SLIDE 88

Soundness of Formal Models

Several challenges Traditional models usually deterministic (except for picking nonces, and possibly within the encryption operation), but for many interesting tasks cryptographic protocols typically use more randomness If model is too general, becomes hard/intractable to automatically reason Promising approach: Universal Composition -- require stronger per-session security that will allow decomposing the analysis to be per-session

slide-89
SLIDE 89

Soundness of Formal Models

Several challenges Traditional models usually deterministic (except for picking nonces, and possibly within the encryption operation), but for many interesting tasks cryptographic protocols typically use more randomness If model is too general, becomes hard/intractable to automatically reason Promising approach: Universal Composition -- require stronger per-session security that will allow decomposing the analysis to be per-session Only a few security properties have been considered (related to authentication and secure communication). Need to identify automatically verifiable (and sufficient) criteria for each new task

slide-90
SLIDE 90

Universal Composition

slide-91
SLIDE 91

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model)

slide-92
SLIDE 92

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model) From [GMW’87]. Used by [Pfitzmann-Waidner’01] and [Canetti’01]

slide-93
SLIDE 93

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model) From [GMW’87]. Used by [Pfitzmann-Waidner’01] and [Canetti’01] UC Security [Canetti’01]: security is defined for one session of the protocol, in the presence of an arbitrary environment

slide-94
SLIDE 94

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model) From [GMW’87]. Used by [Pfitzmann-Waidner’01] and [Canetti’01] UC Security [Canetti’01]: security is defined for one session of the protocol, in the presence of an arbitrary environment Composition Theorem: UC security of individual sessions automatically implies UC security of multiple concurrent sessions

slide-95
SLIDE 95

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model) From [GMW’87]. Used by [Pfitzmann-Waidner’01] and [Canetti’01] UC Security [Canetti’01]: security is defined for one session of the protocol, in the presence of an arbitrary environment Composition Theorem: UC security of individual sessions automatically implies UC security of multiple concurrent sessions Drawback: a strong security requirement that is more “expensive” to realize

slide-96
SLIDE 96

Universal Composition

Recall: security guarantee (in computational model) in terms of an ideal functionality (can be used in a formal model) From [GMW’87]. Used by [Pfitzmann-Waidner’01] and [Canetti’01] UC Security [Canetti’01]: security is defined for one session of the protocol, in the presence of an arbitrary environment Composition Theorem: UC security of individual sessions automatically implies UC security of multiple concurrent sessions Drawback: a strong security requirement that is more “expensive” to realize Advantages: 1. Security for concurrent sessions. 2. Easy to use as a sub-module in higher level protocols and analyze

  • security. Analysis of higher level protocols often “automatable”
slide-97
SLIDE 97

Composition Logic

slide-98
SLIDE 98

Composition Logic

Ongoing research

slide-99
SLIDE 99

Composition Logic

Ongoing research Protocol Composition Logic of Mitchell et al.

slide-100
SLIDE 100

Composition Logic

Ongoing research Protocol Composition Logic of Mitchell et al. Formal model and soundness theorems by Canetti-Herzog

slide-101
SLIDE 101

Composition Logic

Ongoing research Protocol Composition Logic of Mitchell et al. Formal model and soundness theorems by Canetti-Herzog Task-Structured Probabilistic I/O Automata

slide-102
SLIDE 102

Composition Logic

Ongoing research Protocol Composition Logic of Mitchell et al. Formal model and soundness theorems by Canetti-Herzog Task-Structured Probabilistic I/O Automata ...

slide-103
SLIDE 103

Secure Computation?

slide-104
SLIDE 104

Secure Computation?

Most tasks formally analyzed relate to secure communication

slide-105
SLIDE 105

Secure Computation?

Most tasks formally analyzed relate to secure communication UC framework in principle allows arbitrary functionalities

slide-106
SLIDE 106

Secure Computation?

Most tasks formally analyzed relate to secure communication UC framework in principle allows arbitrary functionalities Also, possibility of modeling certain homomorphic encryption schemes algebraically (and in a sound manner) if implemented using “non-malleable” homomorphic encryption

slide-107
SLIDE 107

Secure Computation?

Most tasks formally analyzed relate to secure communication UC framework in principle allows arbitrary functionalities Also, possibility of modeling certain homomorphic encryption schemes algebraically (and in a sound manner) if implemented using “non-malleable” homomorphic encryption Challenge: Efficient automated analysis in the resulting formal model

slide-108
SLIDE 108

More Automation?

slide-109
SLIDE 109

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives

slide-110
SLIDE 110

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives Crypto primitives themselves designed and security reduced to computational complexity assumptions by hand

slide-111
SLIDE 111

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives Crypto primitives themselves designed and security reduced to computational complexity assumptions by hand Can this be automated?

slide-112
SLIDE 112

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives Crypto primitives themselves designed and security reduced to computational complexity assumptions by hand Can this be automated? Plausible, if a formal model of complexity assumptions

slide-113
SLIDE 113

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives Crypto primitives themselves designed and security reduced to computational complexity assumptions by hand Can this be automated? Plausible, if a formal model of complexity assumptions Likely, for generic group model (which is a formal model)

slide-114
SLIDE 114

More Automation?

Formal models are used to analyze higher level protocols, reducing their security to the security of underlying cryptographic primitives Crypto primitives themselves designed and security reduced to computational complexity assumptions by hand Can this be automated? Plausible, if a formal model of complexity assumptions Likely, for generic group model (which is a formal model) Recent developments in machine verifiable, machine- assisted proofs: EasyCrypt/CertiCrypt

slide-115
SLIDE 115

Today

slide-116
SLIDE 116

Today

Use of formal methods in cryptography

slide-117
SLIDE 117

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities

slide-118
SLIDE 118

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic

slide-119
SLIDE 119

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic Security in formal model had little bearing as a security guarantee in the computational model (but attacks in the formal model give real attacks)

slide-120
SLIDE 120

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic Security in formal model had little bearing as a security guarantee in the computational model (but attacks in the formal model give real attacks) Soundness guarantees

slide-121
SLIDE 121

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic Security in formal model had little bearing as a security guarantee in the computational model (but attacks in the formal model give real attacks) Soundness guarantees Security in formal models that can be translated to security in computational models

slide-122
SLIDE 122

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic Security in formal model had little bearing as a security guarantee in the computational model (but attacks in the formal model give real attacks) Soundness guarantees Security in formal models that can be translated to security in computational models Composition: to make analysis of complex protocols feasible; also to obtain security in arbitrary environments

slide-123
SLIDE 123

Today

Use of formal methods in cryptography Prior to 2000 (or Abadi-Rogaway), separate communities Dolev-Yao, spi calculus, BAN logic Security in formal model had little bearing as a security guarantee in the computational model (but attacks in the formal model give real attacks) Soundness guarantees Security in formal models that can be translated to security in computational models Composition: to make analysis of complex protocols feasible; also to obtain security in arbitrary environments Ongoing work: Probabilistic models (e.g. Task PIOA), more tasks, more tools for formal analysis