COSC 6397 – Information Assurance

Lecture 2 Dr. Verma 1

COSC 6397 – Information Assurance

Module M2 – Protocol Specification and Verification

University of HoustonRakesh VermaLecture 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 Specification of Protocols Specification of properties Protocol analysis


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.


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


Needham-Schroeder ProtocolGoal: to convince B that A is genuinely

operational. Trusted third party S. 1. A -> S : A, B, Na2. S -> A : E(Kas: Na, B, Kab, E(Kbs:

Kab, A))3. A -> B : E(Kbs: Kab, A)4. B -> A : E(Kab: Nb) 5. A -> B : E(Kab: (Nb – 1))


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)


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)


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.


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.

1. A -> B : A, E(Kab: Na) 2. B -> A : E(Kab: Na + 1, Nb) 3. A -> B : E(Kab, Nb + 1)4. B -> A : E(Kab: K’ab, N’b)


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.

1. A -> B : A, E(Kab: Na) 2. B -> A : E(Kab: Na + 1, Nb) 3. A -> Z(B) : E(Kab, Nb + 1)4. Z(B) -> A : E(Kab: Na + 1, Nb)


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.


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.


Example of || Session Attack One way authentication protocol.

Goal: convince A that B is operational.

1. A -> B: E(Kab: Na)2. B -> A: E(Kab: Na+1)


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)


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.


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.


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 to a specific cryptosystem is better than speaking of the security of a protocol in absolute.


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.


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).


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.


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:

1. A -> S : A, B, Na2. S -> A : S, E(Ks-1: S, A, Na, Kb)


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, Na2.1 Z(A) -> S : A, Z, Na2.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)


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)


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:

1. B -> A: choice of Heads or Tails.2. A chooses a key Ka and A -> B: E(Ka:

Heads) , E(Ka: Tails).3. B chooses arbitrarily one of E(Ka: Heads) ,

E(Ka: Tails) and sends his choice, say X, to A.


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.


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.


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.


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.


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.


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)


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.


Basic Steps in Analysis1. Protocol specification - Model the parties

in the protocol, including the Intruder 2. Security Property specification -

Formulate the security goals as a specification the systems should specify

3. Protocol Analysis - Apply available verification techniques, e.g., model checking or theorem proving to establish that protocol meets specification or find a counterexample


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.”


Prolog – Simple ExampleProgram: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.


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


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))


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


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


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))]


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 notation vs abstract notation)


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


Summarizing: We specified the roles of NS:

initiator(A,B,Na, Nb), responder(A,B,Na,Nb)


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


Primary References A short course, “Verification of

Security Protocols,” by S. Etalle “A survey of Authentication

Protocol Literature” by J. Clark and J. Jacob

Documents

COSC 6397 – Information Assurance