Detecting and Resolving Type Flaws in Security Protocols Michael - PowerPoint PPT Presentation

Detecting and Resolving Type Flaws in Security Protocols Michael Banks Department of Computer Science, University of York 26th February 2009

Outline 1 Security Protocols 2 Type Flaws: Attacks and Defences 3 Detecting and Resolving Potential Type Flaws 4 Summary and Conclusions

What is a Security Protocol? A security protocol comprises a prescribed sequence of interactions between entities [designed to provide] security services across a distributed system. (Ryan and Schneider, 2001) Principals (entities) interact by sending and receiving sets of terms: Principal IDs A , B , S Secret Keys K AS , K BS , K AB Nonces N A , N B Timestamps T A , T B , T S Terms may be encrypted to ensure their secrecy or integrity.

The Otway-Rees Key Transport Protocol Key distribution problem (informal description): A and B wish to communicate with each other in private. S is a key server, trusted by A and B to generate session keys. Otway and Rees (1987) proposed a key transport protocol: A → B : M , A , B , { N A , M , A , B } K AS 1 . 2 . B → S : M , A , B , { N A , M , A , B } K AS , { N B , M , A , B } K BS S → B : M , { N A , K AB } K AS , { N B , K AB } K BS 3 . 4 . B → A : M , { N A , K AB } K AS

Outline 1 Security Protocols 2 Type Flaws: Attacks and Defences 3 Detecting and Resolving Potential Type Flaws 4 Summary and Conclusions

A Type Flaw in the Otway-Rees Protocol (Boyd, 1990) Recall the Otway-Rees protocol: 1 . A → B : M , A , B , { N A , M , A , B } K AS B → S : M , A , B , { N A , M , A , B } K AS , { N B , M , A , B } K BS 2 . 3 . S → B : M , { N A , K AB } K AS , { N B , K AB } K BS 4 . B → A : M , { N A , K AB } K AS Let’s assume that | K AB | = | M | + | A | + | B | . An adversary Z may intercept (1) and impersonate B in (4): 1 . A → Z ( B ) : M , A , B , { N A , M , A , B } K AS 4 . Z ( B ) → A : M , { N A , M , A , B } K AS Upon receiving message (4), A may interpret � M , A , B � as K AB !

Why Are Type Flaw Attacks Possible? A type flaw attack on a security protocol is an attack where a field that was originally intended to have one type is subsequently interpreted as having another type. (Heather, Lowe, and Schneider, 2000) Type flaws are implementation-dependent: (Carlsen, 1994) A type flaw may be exploited if term widths coincide in the protocol implementation. Belief logics do not consider implementation details! (Burrows et al., 1989; Syverson and van Oorschot, 1996)

Preventing Type Flaws by Adding Contextual Information Record the intended type of each term in a packet in a “type tag”: 1 . A → B : M , A , B , {� nonce , sid , pid , pid � , N A , M , A , B } K AS 2 . B → S : M , A , B , {�· · · � , N A , M , A , B } K AS , {�· · · � , N B , M , A , B } K BS 3 . S → B : M , {� nonce , key � , N A , K AB } K AS , {� nonce , key � , N B , K AB } K BS 4 . B → A : M , {� nonce , key � , N A , K AB } K AS Potential drawbacks: Recipients need to check that packets are tagged correctly. Tagging all packets is sometimes unnecessary (Carlsen, 1994) and may allow cryptanalysis. (Mao and Boyd, 1994) Meadows (2002, 2003) argues that tagging may not prevent complex type flaw attacks which confuse tags with terms. Possible optimisation: type tag indexes. (Heather et al., 2000)

Preventing Type Flaws by Reordering Terms Change the order of terms in individual packets: 1 . A → B : M , A , B , { N A , M , A , B } K AS 2 . B → S : M , A , B , { N A , M , A , B } K AS , { N B , M , A , B } K BS 3 . S → B : M , { K AB , N A } K AS , { K AB , N B } K BS 4 . B → A : M , { K AB , N A } K AS The Good No extra communication or processing overheads. The Bad Not a general solution: for some protocols, no term reordering eliminates all type flaws. The Ugly Considered an ad hoc method by Boyd and Mathuria (2003); few references to reordering in the literature.

Reordering Terms Cannot Resolve All Type Flaws Consider the Andrew Secure RPC protocol (Satyanarayanan, 1989): 1 . A → B : A , { N A } K AB 2 . B → A : { N A + 1 , N B } K AB 3 . A → B : { N B + 1 } K AB B → A : { K ′ AB , N ′ 4 . B } K AB If | N A | + | N B | = | K ′ AB | + | N ′ B | , then Z may mislead A in (4): → B : A , { N A } K AB 1 . A 2 . B → A : { N A + 1 , N B } K AB → Z ( B ) : { N B + 1 } K AB 3 . A 4 . Z ( B ) → A : { N A + 1 , N B } K AB This protocol also contains a freshness flaw in (4). (Burrows et al., 1989; Clark and Jacob, 1997)

Na¨ ıvely Reordering Terms May Introduce New Type Flaws Consider the Neuman and Stubblebine (1993) initial exchange: 1 . A → B : A , N A B → S : B , { A , N A , T B } K BS , N B 2 . 3 . S → A : { B , N A , K AB , T B } K AS , { A , K AB , T B } K BS , N B A → B : { A , K AB , T B } K BS , { N B } K AB 4 . If | N A | = | K AB | , then Z may masquerade as A and S to mislead B : 1 . Z ( A ) → B : A , N A → Z ( S ) : B , { A , N A , T B } K BS , N B 2 . B 4 . Z ( A ) → B : { A , N A , T B } K BS , { N B } N A This flaw was discovered independently by Syverson (1993) and Hwang et al. (1995); the protocol is also vulnerable to a parallel session attack. (Hwang et al., 1995; Clark and Jacob, 1997)

Na¨ ıvely Reordering Terms May Introduce New Type Flaws Is the “permuted protocol” (Syverson, 1993) free of type flaws? 1 . A → B : A , N A 2 . B → S : B , { A , T B , N A } K BS , N B 3 . S → A : { B , N A , K AB , T B } K AS , { A , K AB , T B } K BS , N B 4 . A → B : { A , K AB , T B } K BS , { N B } K AB Hint: what if | N A | = | K AB | = 2 × | T B | ?

Na¨ ıvely Reordering Terms May Introduce New Type Flaws Is the “permuted protocol” (Syverson, 1993) free of type flaws? 1 . A → B : A , N A 2 . B → S : B , { A , T B , N A } K BS , N B 3 . S → A : { B , N A , K AB , T B } K AS , { A , K AB , T B } K BS , N B 4 . A → B : { A , K AB , T B } K BS , { N B } K AB Hint: what if | N A | = | K AB | = 2 × | T B | ? Assuming that Z knows a recent timestamp T ′ B ≃ T B : : A , � X , T ′ 1 . Z ( A ) → B B � → Z ( S ) : B , { A , T B , � X , T ′ 2 . B B �} K BS , N B : { A , T B , � X , T ′ Z ( A ) → B B �} K BS , { N B } � T B , X � 4 . B may interpret � T B , X � as K AB . (Syverson, 1993)

Classifying Type Flaws We assume the Dolev and Yao (1983) threat model for adversary. Class I An adversary exploits a type flaw by substituting one encrypted packet for another encrypted packet. Class II An adversary induces a type flaw by changing plaintext terms, or by substituting a plaintext term for an encrypted packet. Note: this classification is original and provisional!

Outline 1 Security Protocols 2 Type Flaws: Attacks and Defences 3 Detecting and Resolving Potential Type Flaws 4 Summary and Conclusions

Extracting Terms from Messages Let rec n denote the recipient of msg n . Let readable( msg n ) denote the terms in msg n which rec n can read: readable( msg 1 ) = { M , A , B } ( rec 1 = B ) readable( msg 2 ) = { M , A , B , N A , N B } ( rec 2 = S ) readable( msg 3 ) = { M , K AB , N B } ( rec 3 = B ) readable( msg 4 ) = { M , K AB , N A } ( rec 4 = A )

Constructing Principal Knowledge Each principal P “knows” an initial set of terms, initial( P ): initial( A ) = { M , A , B , S , N A , K AS } initial( B ) = { B , S , N B , K BS } initial( S ) = { A , B , S , K AS , K BS } Let knows n ( P ) denote P ’s knowledge after msg n has been received: knows 0 ( P ) = initial( P ) � readable( msg n ) if P = rec n knows n ( P ) = knows n − 1 ∪ ∅ otherwise

Applying Principal Knowledge Let packets( msg n ) denote the set of packets p k in msg n for which rec n knows the key k to decrypt p k : packets( msg n ) = { p k | p k ∈ msg n ∧ k ∈ knows n ( rec n ) } We can identify the terms in each packet which rec n recognises from previous knowledge: ∀ p k ∈ packets( msg n ) • checkables n ( p k ) = p k ∩ knows n − 1 ( rec n ) checkables 2 ( { N A , M , A , B } K AS ) = { A , B } checkables 2 ( { N B , M , A , B } K BS ) = { A , B } checkables 3 ( { N B , K AB } K BS ) = { N B } checkables 4 ( { N A , K AB } K AS ) = { N A }

Constructing Packet Templates Treating each p k as a sequence of terms, template n ( p k ) replaces each subsequence of non-checkable terms in p k with a wildcard: template 2 ( { N A , M , A , B } K AS ) = � ⋆, A , B � K AS template 2 ( { N B , M , A , B } K BS ) = � ⋆, A , B � K BS template 3 ( { N B , K AB } K BS ) = � N B , ⋆ � K BS template 4 ( { N A , K AB } K AS ) = � N A , ⋆ � K AS For each p k in packets( msg n ), we require rec n to verify that all checkables n ( p k ) are located at their respective offsets in p k .

Finding (Class I) Type Flaws by Template Matching Will the recipient of msg n , expecting to find p k , accept q k ′ instead? To find out, we check whether template n ( p k ) matches any encrypted packet q k ′ ( � = p k ) in messages 1 .. n :  � m ∈ 1 .. n ∧ q k ′ ∈ packets( msg m )  �   q k ′ � = p k ∧ k ′ = k � ∧ flaws n ( p k ) =  q k ′ � � ∧ q k ′ matches template n ( p k )  � flaws 3 ( { N B , K AB } K BS ) = {{ N B , M , A , B } K BS } flaws 4 ( { N A , K AB } K AS ) = {{ N A , M , A , B } K AS }