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
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
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
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
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
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
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 ...
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
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
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
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)
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
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 xk e 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
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
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
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>
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
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})]
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
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
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
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?