open problems in protocol verification

22
OPEN PROBLEMS IN PROTOCOL VERIFICATION Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 [email protected] http://chacs.nrl.navy.mil

Upload: saddam

Post on 15-Jan-2016

36 views

Category:

Documents


0 download

DESCRIPTION

OPEN PROBLEMS IN PROTOCOL VERIFICATION. Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 [email protected] http://chacs.nrl.navy.mil. IN ORDER FOR FIELD TO SURVIVE, NEED TO MAKE OUR RESULTS USEFUL. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: OPEN PROBLEMS IN PROTOCOL VERIFICATION

OPEN PROBLEMS IN PROTOCOL VERIFICATION

Catherine MeadowsCode 5543

Center for High Assurance Computer SystemsNaval Research Laboratory

Washington, DC [email protected]://chacs.nrl.navy.mil

Page 2: OPEN PROBLEMS IN PROTOCOL VERIFICATION

IN ORDER FOR FIELD TO SURVIVE, NEED TO MAKE OUR

RESULTS USEFUL• What research community has been doing in that

direction– Analyzing standards, etc.– Communicating results to people responsible– Works best when you can do this early on– Works best when you can get protocol writers involved– Would work best of all if you could get protocol writers

using the tools themselves

• What’s the next step

Page 3: OPEN PROBLEMS IN PROTOCOL VERIFICATION

REQUIREMENT INPUT• Most obvious way

– have protocol designers generate informal requirements

– translate them into your own formalism

– Problem: easy for misunderstanding or error to creep in

• Next step– Develop formalism that is closestto how engineers actually

represent requirements

– Problem here: haven’t yet discovered any such suitable notation for crypto protocols

– Closest thing: message flows• Describes how protocol supposed to behave in absence of intruder

• Challenge: Develop requirements language usable by both protocol designers and protocol verifiers

Page 4: OPEN PROBLEMS IN PROTOCOL VERIFICATION

WHAT IS A TYPE CONFUSION ATTACK?

• Attack that relies on a principal’s inability between two strings of two different types– Hard to verify that type confusion attacks are realistic– Depends on formatting of data

• What we show in this talk– Example of a realistic type confusion attacks– Outline of a technique for detecting type confusion

Page 5: OPEN PROBLEMS IN PROTOCOL VERIFICATION

GDOI• Protocol facilitating distribution of group keys by

Group Key Distribution Center (GCKS)– Embodies SMuG framework and architecture

• Based on ISAKMP and IKE– Standards developed for key exchange– Used to distribute security associations

• Protocol uses– IKE to distribute pairwise SAs– Groupkey Pull Protocol initiated by member to distribute

KEK SAs to new group member– Groupkey push Datagram to distribute KEK and TEK SAs

to existing group members

Page 6: OPEN PROBLEMS IN PROTOCOL VERIFICATION

GDOI PROTOCOLSGroupkey Pull Protocol

        Initiator (Member)                   Responder (GCKS)        ------------------                   ----------------

        HDR*, HASH(1), Ni, ID    -->

                                  <--     HDR*, HASH(2), Nr, SA

        HDR*, HASH(3) [, KE_I]    -->

[,CERT] [,POP_I]

                                  <--     HDR*, HASH(4), [KE_R,] SEQ,

KD [,CERT] [,POP_R]

CERT used to verify information about principals

POP used to verify possession of key provided in CERT

POP = signature on hash of Ni,Nr

Groupkey Push Message

Member                    GCKS or Delegate

        ------                    ----------------

                     <---- HDR*, SEQ, SA, KD, [CERT,] SIG

Page 7: OPEN PROBLEMS IN PROTOCOL VERIFICATION

POSSIBLE ATTACK

• In third message of groupkey pull protocol, GCKS signs (NA,NB)

– NA member’s nonce, NB the GCKSs nonce

• Suppose– Group member dishonest

• Then ...

Page 8: OPEN PROBLEMS IN PROTOCOL VERIFICATION

DETAILS OF ATTACK• Use fact that groupkey push message likely to end in

a random number• Create fake groupkey push message:  

– HDR, SEQ, SA, KD’– Minus signature, part or all of random number at end of KD, and final

encryption

   DISHONESTMEMBER --> GCKS :

HDR*, HASH(1), Ni = (HDR’, SEQ, SA, KD), ID

• GCKS sends back POP signature on (HDR’, SEQ, SA, KD, Nr)

• Encrypt with KEK• Results in authenticated fake groupkey push message

Page 9: OPEN PROBLEMS IN PROTOCOL VERIFICATION

HOW TO AVOID THESE

• Require principals not to accept signed message unless contains nonce contributed by that principal– Not an option for group protocols

• Require different mechanisms for different apps.– Examples

• Different signature keys for POP and groupkey• Different hash function• Keyed hash function with different keys

– Often the best option, but too much reliance on this could lead to intractable key management problem

• Solution chosen: take signature over message and header indicating type of message– Similar to solution recommended by Heather, Lowe and Schneider

Page 10: OPEN PROBLEMS IN PROTOCOL VERIFICATION

WHY WORRY ABOUT TYPE CONFUSION WHEN SEEMS EASY

TO AVOID IT?• Can design protocols so that they are free of type

confusion, but what about protocols they interact with?

• A similar type confusion attack we found with NPA relied upon interaction with ISAKMP, protocol GDOI built on top of

• Type confusion analysis will help us determine whether or not it is safe for two protocols to interact– Carrying Herzog and Guttman’s work one step further– They show protecting against harmful interaction boils

down to protecting against confusion between messages

Page 11: OPEN PROBLEMS IN PROTOCOL VERIFICATION

A CLOSER LOOK: WHEN IS THE GDOI ATTACK POSSIBLE?• Depends upon relationship between types and

lengths of data used in the two messages• First message contains two random strings Ni and

Nr– Only Nr recognizable by message generator

• Second message contains a string of recognizable and random fields F, followed by a random string S

• Constraints are– Length(Ni) ≥ Length (F)– Length(Nr) ≤ Length(S)– Length(Ni) + Length(Nr) = Length(F) + Length(S)

Page 12: OPEN PROBLEMS IN PROTOCOL VERIFICATION

SOLUTION WILL HAVE THREE PARTS

• Definition of type, and type local to a principal• Definition of game between intruder and signer of

a message• Procedure for determining whether or not intruder

can win

Page 13: OPEN PROBLEMS IN PROTOCOL VERIFICATION

DEFINITION OF TYPE AND MESSAGE TYPE

• A type is either a set of bit-strings, or a random variable whose domain is bit-strings

• A message type is a function from lists of bit-strings to types such that:– < x1,.., xk > Domain(R) iff < x1,.., xk-1 > Domain(R) and xk R < x1,..,

xk > – R(i) is defined where I is the empty string– For now will assume all message types bounded

• Idea is that type of k’th term determined by value of previous k-1 terms– Example: x1 = “nonce”, X2 = 16-bit integer N, x3 = integer of length N

• We say that < x1,.., xk > R when < x1,.., xk > Dom(R)• A subtype of R is a restriction of R to some subset of its

domain

Page 14: OPEN PROBLEMS IN PROTOCOL VERIFICATION

DEFINITION OF LOCAL TYPE

• A type local to A is a type such that A can determine whether or not a bit-string is in the type– A’s name: consists of one value– All names: consists of all values having name format– A nonce of length N generated by A: a random variable

w. uniform distribution over terms of length N– A nonce of length N generated by B: all terms of length

N

• A local message type is a message type from bit-strings to local types

Page 15: OPEN PROBLEMS IN PROTOCOL VERIFICATION

EXAMPLE

• M = <NONCEI,NONCEA> where NONCEI is a nonce of length 2^16 generated by I and NONCEA nonce of lengt 2^16 generated by A

• Message type local to A is– R(i) = all integers of length 2^16– R(NONCEI) = random variable w. uniform distribution over

integers of length 2^16

• N = <nonce,Length,RANDA> where Length is a field of lenth 32, and RANDA is a nonce of length LENGTH, both generated by A

• Message type local to B is– S(i) = nonce– S(nonce) = all integers of length 32– S(<nonce,N>) = all integers of length N

Page 16: OPEN PROBLEMS IN PROTOCOL VERIFICATION

GAME BETWEEN INTRUDER, A AND B

• Intruder and A play a game in which intruder tries to make A sign a message of type local to A R that is also type local to B S

• One goes first, generates a sequence of terms• The other goes second, generating a list of terms

– May or may not have seen terms previously generated by other

• Continue in this fashion until done• A’s strategy: obey the rules of the protocol• I’s strategy: maximize chance of producing a message of type

S• For purposes of exposition, will assume that terms generated

in order they appear in the message

• IN our example, I tries to choose NONCEI to maximize probability that <NONCEI,NONCEB> will be confused with <nonce,N,RANDA>

Page 17: OPEN PROBLEMS IN PROTOCOL VERIFICATION

THE ZIPPER: A PROCEDURE FOR DETECTING TYPE CONFUSION

Construct tree with nodes of the form[{<x1|| … ||xk, R’, S’>}, C, p] where

– C set of constraints on lengths

– R’ subtype of R such that <x1,…,xk> in domain(R)

– S’ subtype of S consisting of all elements s such that x1 || … || xk a prefix of support s and constraints from C satisfied

– p is a probability greater than some chosen number q

Page 18: OPEN PROBLEMS IN PROTOCOL VERIFICATION

START CONSTRUCTING TREE

• Root node is [{<I,R,S>},,1]• Construct constraints as follows:

– C1 = l(x1) ≤ l(y1)

– C2 = l(x1) > l(y2), l(x1) ≤ l(y1 + y2)

– …

– Cm = l(x1) > l(y1 + … + ym-1), l(x1) ≤ l(y1 + … + ym)

• For each constraint Ci, and each possible x1, find R’ = { r R | r satisfies Ci & probability of there existing member s of S satisfying Ci whose support agrees with R on x1 is p >= q}

• New node is [{<x1,R’,S’>},Ci,max({p})]

Page 19: OPEN PROBLEMS IN PROTOCOL VERIFICATION

NODES IN EXAMPLE

• C1 =l(NONCEI ≤ l(nonce)– probability of a match is 1 if NONCEI chosen to be

prefix of nonce, negligible otherwise, so choose NONCEI a prefix of nonce

• C2 = l(NONCEI) > l(nonce), l(NONCEI) ≤ l(nonce + N)– Probability of match is 1 if NONCEI has nonce as

prefix, neglible otherwise, so chose NONCEI with nonce as prefix

• C3 = l(NONCEI) > l(nonce + N), l(NONCEI) ≤ l(nonce + N + RANDA)– Probability of match is 1 if NONCE 1 has nonce and N

as prefix, and l(NONCE1) - l(nonce) - l(N)) ≤ N

Page 20: OPEN PROBLEMS IN PROTOCOL VERIFICATION

CONTINUE TO CONSTRUCT TREE

• Given node [ {<x1||x2…||xk, R”, S”>}, C, v]• Suppose that l(x1+ … + xk) ≤ l(y1+…+yj) appears in C• New set of constraints is

C U {l(x1 + … + xk+1) ≤ l(y1 + … + yj)}C U {l(x1 + … + xk+1) > l(y1 + … + yj),

l(x1 + … + xk+1) ≤ l(y1 + … + yj+1)}…C U {l(x1 + … + xk+1) > l(y1 + … + ym-1),

l(x1 + … + xk+1) ≤ l(y1 + … + ym)}If k +1 = n, last one should be an equality

• For each new C, find all < x1,.., xk+1 > such that probability of finding member of S” with x1 ||…||xk in prefix is p such that pv > q

• New node is [ {< x1 || x2,…|| xk+1, R’’’, S”’>}, C’, max(pv)] where R’’’ and S’’’ agree on x1 || x2,…|| xk+1

Page 21: OPEN PROBLEMS IN PROTOCOL VERIFICATION

LOOK AT EXAMPLE AGAIN

• C1 =l(NONCEI ≤ l(nonce)– Add l(NONCEI + NONCEA) ≤ l(nonce), won’t work,

nothing left to match rest of message– Only one that could work is l(NONCEI + NONCEA) =

l(nonce + N + RANDA)• Requires random variable to have its own length minus

length of leftover bit of “nonce” appearing at designated point

• You can calculate the probability

• C3 = l(NONCEI) > l(nonce + N), l(NONCEI) ≤ l(nonce + N + RANDA)– Add l(NONCEI + NONCEA) = l(nonce + N + RANDA)– Requires NONCE A to be confused with portion of

RANDA of same length as NONCEA• Works because type of RANDA is all numbers of that length

Page 22: OPEN PROBLEMS IN PROTOCOL VERIFICATION

CONCLUSION -- WHAT’S NEXT?

• Look around for more type confusion examples– How well do our results apply?– probably best to look in cases where protocols interact

• Refine procedure?– Difficulty -- we’re looking for examples of bad typing

systems, not good ones

• Implement?