1 / 44

Qualitative Properties of Network Protocols and their Verification using Process Calculi

Qualitative Properties of Network Protocols and their Verification using Process Calculi. Daniele Gorla Dagstuhl, February 1st, 2010. Overview. Qualitative properties of Network protocols Formalizations of protocols and of their properties Process algebras

laquinta-liz
Télécharger la présentation

Qualitative Properties of Network Protocols and their Verification using Process Calculi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Qualitative Properties of Network Protocols and their Verification using Process Calculi Daniele Gorla Dagstuhl, February 1st, 2010

  2. Overview • Qualitative properties of Network protocols • Formalizations of protocols and of their properties • Process algebras • Verification tools (behavioural equivalences, type systems, modal logics, traslation into logic progr.)

  3. Network protocols and their properties

  4. Protocol “…is a set of rules which is used by computers to communicate with each other across a network … that controls or enables the connection, communication and data transfer between computing endpoints” (Wikipedia)

  5. Protocol: main ingredients • A network • where different computers (or principals) are connected • that interact with each other • by following a fixed set of rules • to achieve some goal

  6. Rules governing a Protocol • Formats of the messages • Access to the communication medium • Reaction to abnormal behaviours (loss of connection, transmission errors, …) • Meaning of the data exchanged • Handling low level features (crossing network interfaces, firewalls and tunnels, administrative frontiers, … ) Usually specified in a very verbose and imprecise way in their documentation

  7. Goals of a Protocol • Establish/close a (secure) connection between principals • Negotiate some features of the connection • Synchronization of remote principals • Exchage data • Correct corrupted messages • e-commerce and/or e-voting • …

  8. Properties of Protocols • Predicates describing the goals of the protocol • They can be • Boolean (i.e., YES or NO): qualitative • Numeric: quantitative Examples: • Qualitative: secrecy, authenticity, integrity, availability, … • Quantitative: throughput, bandwidth, speed, … • Double-sided: non-interference

  9. Formalizing network protocols and their properties

  10. Specifying a Protocol • Long natural language descriptions (ambigouos, error-prone, difficult to understand) • Formal specifications (more precise, less error prone, easier to understand) • Protocol narrations: describe what data the various prinicipals should send and how they react to the reception of some message • Process calculi: formal settings, with clear syntax and semantics, equipped with very powerful reasoning techniques

  11. Protocol narrations: an example Needham-Schroeder authentication protocol (1978): Msg 1. A → B : {nonceA, A}kB+ Msg 2. B → A : {nonceA, nonceB}kA+ Msg 3. A → B : {nonceB}kB+ This protocol aims at ensuring both A and B of each other’s identity.

  12. Problems of protocol narrations The sequence of messages is not enough to completely describe a protocol. We need to specify: • The need for trusted entities, third parties, time servers, … • Which data are fresh and which ones are known at the outset by each principal • How principals handle received messages • If a principal can play different roles in the same protocol and/or it can participate to different protocols simultaneously • Assumptions on the cryptographic primitives • …

  13. The attacker • It may participate in some protocol runs • It may know some data in advance • It may intercept (both listen and remove) messages from communication channels • It may inject any message it can produce • It can NOT guess secrets (usually) • It can NOT break cryptography • It can NOT play certain roles (e.g., trusted servers or certifying authorities)

  14. Needham-Schroeder is vulnerable! Attack (G. Lowe, 1995): Msg 1. A → I : {nonceA, A}kI+ Msg 1’. I → B : {nonceA, A}kB+ Msg 2. B → I : {nonceA, nonceB}kA+ Msg 2’. I → A : {nonceA, nonceB}kA+ Msg 3. A → I : {nonceB}kI+ Msg 3’. I → B : {nonceB}kB+ 1, 2’, 3: A and I mutually authenticate 1’, 2, 3’: I and B authenticate, but B believes to speak with A Attack of I against A: • B is a bank • A is a bank client • I can send the message {nonceA, nonceB, “transfer money from A’s account to I’s one”}kB+

  15. Fixing Needham-Schroeder G. Lowe 1997: Msg 1. A → B : {nonceA, A}kB+ Msg 2. B → A : {B, nonceA, nonceB}kA+ Msg 3. A → B : {nonceB}kB+ This protocol should be safe against all attacks; how to formally prove this?

  16. On the meaning of Properties Also properties need to be properly specified  usually as predicates on the behaviours of the system (i.e., protocol + environment) Example: Secrecy • P(x) is secure is, for every term M and M’, P(M) is observationally equivalent to P(M’) • P preserves the secrecy of M under the initial attacker knowledge S if, for every run of P, the attacker cannot infer M from S and from what he has observed during that run According to the different meaning of a property, a protocol can work well or not

  17. Summing up • Protocol narrations are better than informal descriptions • Still a lot of details to specify outside the narration itself • E.g., properties need to be properly specified (outside the narration) • Problems in verifying correctness of protocols (no formal reasoning technique)

  18. Process Algebras

  19. Interesting Features of PAs • Formal syntax and operational semantics • Simple to understand • Expressive and easily extensible with advanced features (cryptography, mobility, connectivity, …) • Easy to model ideal channels but also noisy channels (mostly with probabilistic PAs) • Well-suited for representing open systems with different entities involved • Several assumptions are built in into the syntax/semantics • Equipped with reasoning techniques (equivalences, at least; but also type systems, modal logics, verification tools, …)

  20. CCS: syntax Milner 1980: P ::= 0 | a.P | a.P | .P | P+P | P|P | (va)P | A Features: • (event-based) synchronization between parallel processes • Internal actions • Non-determinism + interleaving semantics • Reserved (i.e., localized) events • Recursive process definitions (A = P)

  21. CCS: operational semantics μ.P μ→ P for μ{a,a,} P μ→ P’ P+Q μ→ P’ and viceversa P  μ→ P’ P|Q μ→ P’|Q and viceversa P a→ P’ Q a→ Q’ P|Q → P’|Q’ and viceversa P μ→ P’ μ{a,a} A = P Pμ→ P’ (va)P μ→ (va)P’ A μ→ P’

  22. CCS: observational semantics Dozens of equivalences: • Trace equiv.: P  Q iff P μ1→…μk→  Qμ1→…μk→ • Bisimulation equiv.: P ~ Q iff  P μ→ P’  Q μ→ Q’ s.t. P’ ~ Q’ • Their weak versions,  and , that abstract from internal moves • … Forming a lattice of equivalences:   ~

  23. CCS: An example A semaphore: S = p.S’ S’ = v.S A binary semaphore: BS = p.BS’ BS’ = p.BS’’ + v.BS BS’’ = v.BS’ Implementing a binary semaphore with two unary ones: BS ~ S | S Remark: equivalences in CCS can be proved by hand or by exploiting automatic tools (e.g., Concurrency Workbench)

  24. An advanced PA: the pi-calculus Adding name passing and testing to CCS (Milner et al. ’89): P ::= 0 | a(x).P | a<b>.P | .P | P+P | P|P | (va)P | if a = b then P else P | A Remark: the name passed in an output can be reserved; this causes a (capture avoiding) scope extension to include the receiver in the scope of the reserved name, while keeping the reserved name fresh.

  25. Pi-calculus: operational semantics A labelled semantics is possible but quite subtle. It is better a reduction semantics (capturing the ’s): a(x).P | a<b>.Q → P{ b/x } | Q P → P’ P → P’ P  Q → Q’  P’ P|Q → P’|Q (va)P → (va)P’ P → P’ where  rearranges processes to let them evolve according to some reduction rule. Key rule: P | (va)Q  (va)(P | Q) if a  fn(P)

  26. Pi-calculus: an example • Two principals (A and B) • that want to establish a reserved channel • by exploiting the help of a server (S) • that shares with both of them a reserved channel By using protocol narrations and (symmetric) encryption: Msg 1. A → S : {k}kAS Msg 2. S → B : {k}kBS Msg 3. A → B : {M}k By using the pi-calculus: A(m) = (vk)kAS<k>.k<m> S = kAS(z).kBS<z> B = kBS(x).x(y) P(m) = (vkAS)(vkBS)(A(m) | S | B) Property (secrecy): P(M) ~ P(M’) (semi)automatic tools: Mobility Wbench

  27. More advanced features for PAs • (Flat) process distribution and mobility (distributed pi-calculus): N ::= l:P | N||N | (va)N P ::= … | go_l.P • (Flat) process distribution and mobility between (dynamically) linked nodes (t-Klaim): N ::= … | { l  l’ } P ::= … | conn_l.P | acpt_l.P | disc_l.P • (Hierarchical) process distribution and mobility (Ambient calculus): P ::= ... | a[P] | in_a.P | out_a.P | open_a.P • Calculi for MANETs, Wireless Networks, …

  28. PAs with cryptography: the applied pi-calculus Pi-calculus + data term construction/destruction (Abadi & Fournet ’01): M ::= a | f(M1,…,Mn) P ::= 0 | a(x).P | a<M>.P | P|P | (va)P | A if M = M’ then P else P | let x = g(M1,…,Mn) in P else P Examples: • sencr(a,k) represents {a}k let x = sdecr(M,k) in P else Q behaves like • P{N/x} , if M = sencr(N,k), for some N • Q, otherwise • pub(k) and sec(k) represent k+ and k-, respectively • pencr(a,pub(k)) represents {a}k+ let x = pdecr(M,sec(k)) in P else Q behaves like • P{N/x} , if M = pencr(N,pub(k)), for some N • Q, otherwise

  29. Applied pi: an example Establishing a secret channel, revisited: Msg 1. A → B : {k}kB+ Msg 2. B → A : {k}kA+ Msg 3. A → B : {s}k In applied pi: A(s) = (vk)c<pencr(k,pub(kB))>.c(x). let y = pdecr(x,sec(kA)) in if y = k then c<sencr(s,k)> B = c(x).let y = pdecr(x,sec(kB)) in c<pencr(y,pub(kA))>.c(z).let w = sdecr(z,k) in … P(s) = (v kA)(v kB)(A(s) | B) Secrecy: P(M) ~ P(M’), for every M and M’ near to automatic tools

  30. Advantages of PAs (up to now) • Easy to translate protocol narrations in PAs: • message numbers: given by sequencing • endpoints of a communication: sender and receiver • message: argument of the output • Extra information is usually not needed in PAs (built in into the syntax/semantics): • new names cannot be confunded with existing names (thanks to scope extension) • the adversary is a normal process in parallel (so it is clear what he can/cannot do and what it does/doesn’t know)  it is not necessary to explicitly specify it !! • robustness w.r.t. any attack is given by the fact that equivalences are congruences (at least w.r.t. parallel composition) • Formal and natural way to express and verify protocol properties

  31. Formalizing the other notion of secrecy • Given a set of messages S, the knowledge associated to it is the least set K(S) s.t. • S  K(S) • f M1,…,Mn  K(S). f(M1,…,Mn)  K(S) • Given a process P0 and a set of messages S0, we want to relate every reduct P of P0 to the set of messages S that the intruder knows in correspondence to P. Formally, let R be such that: • (P0, S0)  R • For every (P,S)  R • If P → P’, then (P’,S)  R • If P a(x)→ P’, a and M  K(S), then (P’{M/x} , S)  R • If P (vm1…mk)a<M>→ P’, m1…mk are fresh and a  K(S), then (P’, S  {M})  R • Secrecy: P does not reveal M from S iff  (P’,S’)  R . M  K(S’)

  32. Verifying secrecy via types • Types for traditional calculi and languages: • track the structure of values and/or processes • ensure progress (no execution will be get stuck because of a type error) • In the last decade • used also to ensure advanced properties of programs (e.g., secrecy, anonimity, availability, responsiveness, … )

  33. A generic type system for Applied pi A generic type system for secrecy (Abadi & Blanchet ’05): • A set of types T (to be assigned to names) • Tpublic T (the types of names known to the attacker) • Typing processes:  ⊢ a : t  ⊢ M : t’ t’  conveys(t)  ⊢ P  ⊢ a<M>.P  ⊢ a : t  t’  conveys(t) . , x : t’ ⊢ P  ⊢ a(x).P

  34. Soundness Thm (subject reduction): If  ⊢ P and P → Q, then  ⊢ Q Thm (secrecy): If  ⊢ P,  ⊢ M : t and t  Tpublic, then P does not reveal M from S, where S = {a |  ⊢ a : t  t  Tpublic} Efficient type checking and type inference algorithms, at least for some instances of the general type system

  35. Verifying secrecy via logic programming • Translate the protocol and the attacker into Horn clauses • Assume some starting public knowledge • Use resolution to infer new information • Exploit existing LP tools (e.g., theorem provers) or build new ones

  36. ProVerif: a LP tool for the Applied pi • Two predicates: attacker(M) the attacker knowns M message(a,M) M may appear along a • The initial knowledge of the attacker (S) is modeled by adding the fact attacker(a) , for every a  S • Rules for the attacker (for every f): attacker(x1) … attacker(xn)  attacker(f(x1,..,xn)) message(x,y)  attacker(x)  attacker(y) attacker(x)  attacker(y)  message(x,y) • Rules for the protocol (induction over the syntax): [a(x).P]h = [P]h  message(a,x) [a<M>.P]h = [P]h  {h  message(a,M)} • Thm (secrecy): if the fact attacker(M) cannot be derived, then P does not reveal M from S

  37. Secrecy via Modal Logics • Modal logics have been used to express properties of processes since early ’80s (Hennessy-Milner logic) • Advanced process algebras have their advanced modal logics (pi-calculus, Ambient, Applied pi, …) • They usually characterize some behavioural equivalence (e.g., strong bisimilarity)  indecidable, but with decidable meaningful fragments • Very useful for proving that two processes are NOT equivalent

  38. A Modal Logic for Applied Pi Huttel et al (2002, for the spi-calculus): Formulae φ ::= tt |  iI φi | φ | φp | φa Proc.Form. φp::= aφ | aφ Attacker F. φa::= ‹M›φ The attacker is represented by the set of messages it knows The satisfaction relation: (S,P)  φ Characterizing equivalences: P ≈SQ iff φ. (S,P)  φ (S,Q) φ (S,P) ≈ (S’,Q) iff φ. (S,P)  φ (S’,Q) φ

  39. Some Inference Rules (S,P)  tt always (S,P)  φ iff not (S,P)  φ (S,P)   iI φi iff for all i. (S,P)  φi (S,P)  aφ iff (S,P)  ‹a›  P aM P’. (S{M},P)  φ (S,P)  aφ iff (S,P)  ‹a›  M . (S,P)  ‹M›  P a(x) P’. (S,P{M/x})  φ{M/x} (S,P)  ‹a›φ iff a  K(S) (S,P)  φ (S,P)  ‹f(M1..Mn)›φ iff for all i. (S,P)  ‹Mi› (S,P)  φ

  40. Simple Examples • P = (vk) c<{a}k> • Q = c<{a}k> • φ = c‹a› • S =  or S = {c}: (S,P)  φ and (S,Q)  φ ( P ≈S Q ) • S = {c,k}: (S,Q)  φ but (S,P)  φ ( P ≈S Q ) • S = {c} and S’ = {c,{k}k}: (S,P)  φ and (S’,Q)  φ ( (S,P) ≈ (S’,Q) ) • S = {c} and S’ = {c,k}: (S,Q)  φ but (S,P)  φ ( (S,P) ≈ (S’,Q) )

  41. Model Checking • Checking equivalences via exhaustive state exploration (instead of using proof-techniques and algorithms) • Problem: bounding the search space • Bounded replication (to describe finitely many parallel instances of the protocol) • Symbolic representation of the possible messages that an attacker can build • Any attack found in this way is indeed an attack to the protocol • Passing the analysis does not imply absence of any attack  find conditions for this to hold

  42. Conclusions • PAs are good means for specifying and verifying protocols and their properties • A lot of techniques: samples based on • equivalences • equivalence checkers • type systems • theorem provers • modal logics • model checkers • Many more (control flow, abstract interpretation, flow logic, …) • Some approaches already proved equivalent (modal logic and bisimulation for CCS and pi-calculus; types and logic programming for Applied Pi; types and flow logic for KLAIM; …)

  43. Developments • More sophisticated PAs and verification techniques • More case studies !!!

  44. Some References • Abadi. Security protocols: principles and calculi. FOSAD’07 • Abadi. Security protocols and their properties. Foundations of Secure Computation, 2000 • Abadi & Blanchet. Analyzing security protocols with secrecy types and logic programs. JACM 2005 • Abadi & Fournet. Mobile values, new names and secure communication. POPL’01 • Cardelli & Gordon. Mobile Ambients. TCS 2000 • De Nicola, Gorla & Pugliese. Basic observables for a calculus for global computing. I&C 2007 • Durante, Sisto & Valenzano. Automatic testing equivalence verification of spi-calculus specifications. ACM TOSEM 2003. • Frendrup, Huttel & Jensen. Modal logics for cryptographic processes. EXPRESS’02. • Hennessy. A distributed pi-calculus. CUP, 2007 • Lowe. Breaking and fixing the Needham-Schroeder public-key protocol using FDR. TACAS’96 • Milner. Communicating and mobile systems. CUP 1999 • Schneider. Security properties and CSP. IEEE SSP 1996 • Schneider. Verifying authentication protocols in CSP. IEEE TSE 1998

More Related