OPEN PROBLEMS IN PROTOCOL VERIFICATION

1. OPEN PROBLEMS IN PROTOCOL VERIFICATION Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC 20375 meadows@itd.nrl.navy.mil http://chacs.nrl.navy.mil

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

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

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

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

6. GDOI PROTOCOLS Groupkey 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

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

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

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

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

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

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

13. 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 > e Domain(R) iff < x1,.., xk-1 > e Domain(R) and xke 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> e R when < x1,.., xk > e Dom(R) • A subtype of R is a restriction of R to some subset of its domain

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

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

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

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

18. START CONSTRUCTING TREE • Root node is [{<I,R,S>},f,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 e 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})]

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

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

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

22. 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?