1 / 44

COSC 6397 – Information Assurance

COSC 6397 – Information Assurance. Module M2 – Protocol Specification and Verification University of Houston Rakesh Verma Lecture 2 of M2 (This work is supported in part by NSF). Contents of M2. Cryptographic basics Types of Protocols Security properties Taxonomy of Flaws and Attacks

isi
Download Presentation

COSC 6397 – Information Assurance

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. COSC 6397 – Information Assurance Module M2 – Protocol Specification and Verification University of Houston Rakesh Verma Lecture 2 of M2 (This work is supported in part by NSF) Dr. Verma

  2. Contents of M2 • Cryptographic basics • Types of Protocols • Security properties • Taxonomy of Flaws and Attacks • Specification of Protocols • Specification of properties • Protocol analysis Dr. Verma

  3. Security Flaws • Flaw – a protocol property that contradicts the security requirements. • Security flaw – a part of a program that can cause the system to violate its security requirements. Finding security flaws demands some knowledge of the system security requirements. • The proof of a flaw is commonly known as an “attack” and it is generally presented as actions performed on the protocol. Dr. Verma

  4. Freshness Attacks • Occurs when a message (or message component) from a previous run of a protocol is recorded by intruder and replayed in the current run. • Reason – critical messages used in protocol without including Nonces or timestamps. • Example – symmetric key protocol of Needham and Schroeder Dr. Verma

  5. Needham-Schroeder Protocol Goal: to convince B that A is genuinely operational. Trusted third party S. • A -> S : A, B, Na • S -> A : E(Kas: Na, B, Kab, E(Kbs: Kab, A)) • A -> B : E(Kbs: Kab, A) • B -> A : E(Kab: Nb) • A -> B : E(Kab: (Nb – 1)) Dr. Verma

  6. Freshness Flaw in NS Protocol • Denning and Sacco in 1981. • Problem is with Message 3. Nothing in this message to indicate that it was created by S as part of the current protocol run. • Assume Z knows previously distributed K’ab (compromised by cryptanalysis). • Z monitors and records E(Kbs: K’ab, A) Dr. Verma

  7. Freshness Flaw in NS Protocol • Notation: Z(A) – Z acting in place of A. 3. Z(A) -> B: E(Kbs: K’ab, A) 4. B -> Z(A): E(K’ab: Nb) 5. Z(A) -> B: E(K’ab: Nb – 1) Dr. Verma

  8. Type Flaws • Messages consist of a sequence of fields each with some value. Extraction of message fields requires knowledge of their types. Message is implemented as a sequence of bits, so to extract the first field, we need its type/length. • Such information can be implicit -- receiver has previous knowledge about the message’s fields, their types and positions. • Another solution -- represent types explicitly in the transmitted data structure. Dr. Verma

  9. Type Flaws • Type flaws – when an adversary can induce the receiver to infer message component types which are different from the real ones. • Andrew Secure RPC Protocol, provides a good example of this class of flaws. • A -> B : A, E(Kab: Na) • B -> A : E(Kab: Na + 1, Nb) • A -> B : E(Kab, Nb + 1) • B -> A : E(Kab: K’ab, N’b) Dr. Verma

  10. Type Flaws (contd.) • Notation: Mn – Message n. • If nonces and keys are represented as bit vectors of same length (e.g. 128 bits), then intruder Z can record M2, intercept M3 and replay M2 as M4. • A -> B : A, E(Kab: Na) • B -> A : E(Kab: Na + 1, Nb) • A -> Z(B) : E(Kab, Nb + 1) • Z(B) -> A : E(Kab: Na + 1, Nb) Dr. Verma

  11. Andrew Secure RPC Protocol • Protocol is flawed in other ways as well. • Example – M4 of a previous run can be recorded and replayed. (BAN 1989) • What kind of attack is that? • Answer – Freshness Attack. Dr. Verma

  12. Parallel Session Attacks • Flaw – when the protocol dialog allows an adversary to know some secret information or to predict the content of some encrypted messages. • Attack – when >= 2 runs are executed concurrently and messages from one are used to form messages in another. Dr. Verma

  13. Example of || Session Attack • One way authentication protocol. Goal: convince A that B is operational. • A -> B: E(Kab: Na) • B -> A: E(Kab: Na+1) Dr. Verma

  14. Parallel Session Attacks • Intruder Z can play role of B both as responder and initiator. Attack works by starting another run in response to initial challenge. 1.1 A -> Z(B): E(Kab: Na) 2.1 Z(B) -> A: E(Kab: Na) 2.2 A -> Z(B): E(Kab: Na+1) 1.2 Z(B) -> A: E(Kab: Na+1) Dr. Verma

  15. Parallel Session Attacks • At the least, A now believes that B is operational. • In fact, B may no longer exist. • In this attack, Z used A to do some work for Z. “Poses question to A”. • A acts as an oracle (since always provides correct answer). Attack also called an oracle attack. Dr. Verma

  16. Implementation Dependent Attacks • Cryptosystems used within protocols are supposed to be perfect, modulo a set of properties containing at least integrity and confidentiality. • However, these conditions are not sufficient for some protocols, because their security can be severely affected by the implementation adopted for cryptographic functions. Dr. Verma

  17. Implementation Dep. Attacks • The interaction between cryptosystems and cryptographic protocols has not been deeply studied – open area of research. • However, clearly, speaking of the security of a protocol combination with respect toa specific cryptosystem is better than speaking of the security of a protocol in absolute. Dr. Verma

  18. Example – Impl. Dep. Attack • Proposed by Shamir, Rivest and Adleman: 1. A -> B : E(Ka: M) 2. B -> A : E(Kb: E(Ka: M)) 3. A -> B : E(Kb: M) • Assume that we use the XOR function to encrypt messages. E(K: M) = M xor K. • Since k xor k = 0, the decrypting operation is the same: D(K: E(K: M)) = (M xor k) xor k = M. Dr. Verma

  19. Example – Imp. Dep. Attack • The intent of this protocol is to transmit a secret message M from principal A to principal B. • However, if we compute the XOR of the three messages used in this protocol E(Ka: M) xor E(Kb: E(Ka: M)) xor E(Kb: M)), the result is M (the message which is supposed to be secret). Dr. Verma

  20. Binding Flaws • In public key cryptography, the integrity of public keys is paramount. • Assume your public key is Ky and intruder’s public key is Ki. If intruder can convince others that your public key is Ki, then they will encrypt secret information using Ki, which the intruder can read. • To avoid such a flaw, a verifiable binding between agents and public keys must be established. Dr. Verma

  21. Binding Flaws • Generally, in distributed systems, a trusted server is in charge of key distribution. Each principal uses an authentication protocol to get public keys of other principals from the server. • However, if authentication protocol is not carefully designed, binding flaws occur. Example: • A -> S : A, B, Na • S -> A : S, E(Ks-1: S, A, Na, Kb) Dr. Verma

  22. Binding Attack • All components are concatenated and encrypted under S’s private key allowing the principal playing the role A to be sure about the origin of the message. S sent in clear to tell A which public key to use for decryption. • Attack (shown by Hwang and Chen): 1.1 A -> Z(S) : A, B, Na 2.1 Z(A) -> S : A, Z, Na 2.2 S -> Z(A) : S, E(Ks-1: S, A, Na, Kz) 1.2 Z(S) -> A : S, E(Ks-1: S, A, Na, Kz) Dr. Verma

  23. Binding Attack • Suggest a simple fix for this problem. • Answer: Include the name of the party in M2 whose public key is being sent. • M2 should be: S, E(Ks-1: S, A, Na, B, Kb) Dr. Verma

  24. Repudiation Flaws • A protocol contains a repudiation flaw if at least one principal is able to deny its participation in any run of this protocol. • An example of this category of flaws is the coin-flip protocol (Toussaint). It can be used by 2 principals to toss a coin over a phone: • B -> A: choice of Heads or Tails. • A chooses a key Ka and A -> B: E(Ka: Heads) , E(Ka: Tails). • B chooses arbitrarily one of E(Ka: Heads) , E(Ka: Tails) and sends his choice, say X, to A. Dr. Verma

  25. Repudiation Flaw Example 4.A decrypts X, compares result with B’s initial choice and sends Ka to B. 5. B decrypts X and compares result with his initial choice. • The probability that A wins is equal to B’s (1/2) as shown by Toussaint. • However, in this protocol, the result of the game is known by A before B. So, if A discovers she has lost, she can abort the protocol at step 4 and never reveal Ka to B. Dr. Verma

  26. Other Flaws • Elementary Flaws: Some cryptographic protocols provide only marginal protection against an adversary. In general, this category of protocols is breakable with a little effort. (Arbitrary!) • A little protection or a non-protection of a protocol leads in almost all the cases to so-called elementary flaws. Simple example: 1 A -> B : E(Ka-1: Na, Kab) 2 B -> A : E(Kab: Na) • Proposed by Nesset to highlight a limitation of BAN logic as a tool for cryptographic protocol analysis. Dr. Verma

  27. Other Flaws • Aim of this protocol is to exchange a secret key Kab between A and B. • Flaw in this protocol is obvious since Kab is transmitted in a message encrypted under A’s private key. • Then, all other principals can read the content of this message and the key that is supposed to be secret is in fact a broadcasted information. Dr. Verma

  28. Other Flaws • Password Guessing Flaws: occur if it is easy for an adversary to guess a secret key. An intruder can do an exhaustive search in a word space smaller than the whole key space to look for keys that are not randomly selected. • This category of flaws is independent from the protocol design but related to cryptographic techniques used to generate keys. Dr. Verma

  29. Other Flaws • Calculi Flaws: Normally, after receiving a message, the receiver does some verification in order to know if this received message is expected or not. • However, if these computations are not completed or not correctly done, then a calculi flaw could arise. Dr. Verma

  30. Protocol Analysis Approaches • Four types of approaches (Meadows) • Type I – model and verify the protocol using specification languages and verification tools not specific to cryptographic protocols (Kemmerer,Varadharajan) • Type II – develop expert systems that protocol designer can use to investigate different scenarios (Millen et al., Longley and Rigby) Dr. Verma

  31. Protocol Analysis Approaches • Type III – model the requirements of a protocol family using logics developed for the analysis of knowledge and belief (BAN logic) • Type IV – formal model based on algebraic term rewriting properties of cryptographic systems (Dolev and Yao, Meadows, … ) • Type I is least popular, Type III is most common. We will study a Type IV approach. Dr. Verma

  32. Basic Steps in Analysis • Protocol specification - Model the parties in the protocol, including the Intruder • Security Property specification - Formulate the security goals as a specification the systems should specify • Protocol Analysis - Apply available verification techniques, e.g., model checking or theorem proving to establish that protocol meets specification or find a counterexample Dr. Verma

  33. Protocol Specification • Specification language – Prolog • Prolog – Horn clause logic. A Prolog program consists of a set of Horn clauses and a query or goal • A Horn clause is of the form • P :- q1, … , qn. • Read as: “If q1 and q2 … and qn, then P.” Dr. Verma

  34. Prolog – Simple Example Program: ancestor(A, A). ancestor(A, B) :- edge(A, X), ancestor(X, B). edge(a, b). edge(a, c). edge(d, a). Goal: ancestor(Y, b). Prolog uses unification to solve goals. Unification: compute substitution that makes 2 terms identical. Dr. Verma

  35. Prolog – Preliminaries • Variables: begin with uppercase or with _ • Na, Nb, A, B, _a are variables • a, na, nb, b are non-variable terms • variable are terms Dr. Verma

  36. Prolog – Preliminaries • Complex terms can be built using predicate (function) symbols: • pk(b) is a non-variable term (pk is a function symbol) • pk(B) • Nb*pk(B) is the same as *(Nb, pk(B)): * is an infix-operator • send(Nb*pk(B)) Dr. Verma

  37. Learning by Example: Needham-Schroeder 1. A->B : [A, Na]*pk(B) 2. B->A : [Na, Nb]*pk(A) 3. A->B : [Nb]*pk(B) • Notation • [t1, t2]: pairing (these are lists in PROLOG) • msg*k: asymmetric encryption • pk(A): public key of A Dr. Verma

  38. Roles A -> B : [A, Na]*pk(B) B -> A : [Na, Nb]*pk(A) A -> B : [Nb]*pk(B) • Here we have 2 ROLES • one INITIATOR (A) • one RESPONDER (B) • A’s role is specified as a sequence of EVENTS Dr. Verma

  39. Events • events are actions, two kind: • send(t) • recv(t) • t is a term (a message) • the crucial part of a role is a list of actions: [recv([A, B]), send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B))] Dr. Verma

  40. Specifying a Role • Fixed (abstract) notation: name(Variables) = [Actions]. • E.g. initiator(A,B,Na,Nb) = [ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B))]. • The tool notation is different! (compiler notationvs abstract notation) Dr. Verma

  41. The Responder • How does the responder look like? • Just exchange “send” and “recv” responder(A,B,Na,Nb) = [ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B))]). • Any name is good (not only “responder”) • Notice ALL THESE VARIABLES! • names & nonces are not fixed • roles are parametric Dr. Verma

  42. Summarizing: • We specified the roles of NS: initiator(A,B,Na, Nb), responder(A,B,Na,Nb) Dr. Verma

  43. Summarizing: • We still have to specify how the session looks like • how many initiators & how many responders • NB: a recent result by Comon-Lundh & Cortier states that 2 agents are sufficient (but give no limit on the number of sessions) • The names of the agents • are there agents playing both as initiator and responders? • We need to define a scenario Dr. Verma

  44. Primary References • A short course, “Verification of Security Protocols,” by S. Etalle • “A survey of Authentication Protocol Literature” by J. Clark and J. Jacob Dr. Verma

More Related