Prevent Any Type-flaw Attacks

To automatically generate executable code from a concrete level protocol specification, we must be careful about type-flaw attacks. Type-flaw attacks work on an intermediate level between the concrete level and the code level, hence existing concrete level protocol verification techniques cannot find them. A notable exception is Long’s work [Long et al., 2007], in which the authors propose to use Object-Z to specify security protocols at both

5.3 From Concrete Level to Code Level

“presentation layer” and “application layer”5 and then use the AVISPA tool [Armando, 2005] to verify protocols.

I have reviewed type-flaw attacks in section 2.2 and demonstrated two type-flaw attacks on the Otway–Rees Protocol in Figure 2.8 and Figure 2.9. In this section, I discuss three schemes to protect a concrete level security protocol from type-flaw attacks and use the Otway–Rees Protocol as an example to show how these schemes work.

Tag Heather et al. [2000] argued that type-flaw attacks can be avoided by tagging every field in a message with a unique identifier which consists of enough information to indicate its intended type. Perrig and Song’s work followed this approach to prevent type-flaw attacks. Their implementation included type information in the constructed messages, and the receiver of a message always verifies the correct- ness of the type information. Note that Meadows [2003] has argued the existence of some complicated type-flaw attacks in which such tags will not suffice.

Figure 5.7 is the Otway–Rees Protocol with tags. The receiver always checks the tags for type information. For example, in the last message, principal A will check the tag for key before he accepts the next bits as a valid key. If an attacker attacks the protocol by replacing the ciphertext{(nonce,Na),(key,Kab)}Kas with

{(nonce,Na),(sessionID,M),(principal,A),(principal,B)}_K

as

as I have demonstrated in Figure 2.8, principal A is able to recognise that the next bits are not a key since he gets a tag which indicates next bits are a session ID, and therefore rejects the message.

Index There is a lightweight approach (compared with the above tag scheme) for preventing type-flaw attacks. In a type-flaw attack, attackers often use one message to replace another one and make the receiver accept the message as valid but confuse the types of mes- sage components (for example, the receiver interprets a principal’s

5_{The authors define “presentation layer” as the low-level representation of messages}

upon which some implementation-dependent attacks such as type-flaw attacks rely and “application layer” as the level at which message content is determined and distinguishable – essentially our “concrete level”.

Chapter 5 Refinement of Security Protocols

1. A→B :   

(sessionID,M),(principal,A),(principal,B),  (nonce,Na),(sessionID,M), (principal,A),(principal,B)  Kas    2. B→S :           

(sessionID,M),(principal,A),(principal,B),  (nonce,Na),(sessionID,M), (principal,A),(principal,B)  Kas  (nonce,Nb),(sessionID,M), (principal,A),(principal,B)  Kbs            3. S→B :    (sessionID,M), {(nonce,Na),(key,Kab)}Kas {(nonce,Nb),(key,Kab)}Kbs    4. B→A :  (sessionID,M), {(nonce,Na),(key,Kab)}Kas 

Figure 5.7: Otway–Rees Protocol with Tags

identifier as a key). Therefore, we can simply give each encrypted packet a unique index (the index should be put inside the cipher) to indicate its order in the protocol and ask the receiver to always check if the index of any incoming encrypted packet is as expected, so that we can prevent an attacker using one message as another and hence prevent type-flaw attack. Essentially, the index is an optimised type marker to the encrypted message as a whole, rather than each field. I use the index scheme in my work to prevent type-flaw attacks because it is simple and relatively efficient.

Figure 5.8 is the Otway–Rees Protocol with indices. Every encrypted message has a unique index. If an attacker attacks the protocol by using the method I demonstrated in Figure 2.8, he sends prin- cipal A message M,{1, Na, M, A, B}_K

as whilst A expects message

M,{3, Na, M, A, B}_Kas. Therefore, principal A rejects the message sent by the attacker and the attack fails.

Rearrange The tag and index schemes may be over protective and unnec- essarily increase message sizes, complexity and other communication overheads. This is particularly the case when resources are limited such as in battery powered embedded systems like mobiles and

5.3 From Concrete Level to Code Level 1. A→B : M, A, B,{1, Na, M, A, B}_Kas 2. B→S : M, A, B,{1, Na, M, A, B}_K as,{2, Nb, M, A, B}Kbs 3. S→B : M,{3, Na, Kab}Kas,{4, Nb, Kab}Kbs 4. B→A : M,{3, Na, Kab}Kas

Figure 5.8: Otway–Rees Protocol with Index

1. A→B : M, A, B,{Na, M, A, B}_K as 2. B→S : M, A, B,{Na, M, A, B}_K as,{Nb, M, A, B}Kbs 3. S→B : M,{Kab, Na}_Kas,{Kab, Nb}_K bs 4. B→A : M,{Kab, Na}Kas

Figure 5.9: Otway–Rees Protocol with Rearranged Messages

smart cards etc. These systems require such overheads to be minimal. Another approach to prevent type-flaw attacks is to rearrange the positions of message components. This is clever and more efficient than the tag and index schemes, but more subtle and difficult to prove the correctness as a general scheme. I have not investigated doing this automatically.

Figure 5.9 is the rearranged version of the Otway–Rees Protocol. We can simply swap the positions of nonce and key in the two ciphers in the third message to prevent the two type-flaws I have demon- strated in Figure 2.8 and Figure 2.9 (that is, the key distribution server S sends B message M,{Kab, Na}_Kas,{Kab, Nb}_K

bs instead of

M,{Na, Kab}Kas,{Nb, Kab}Kbs). It is reasonable to assume that prin-

cipal A is able to recognise its own nonce, so A will not confuse

{Kab, Na}_K

as with {Na, M, A, B}Kas; the same conclusion applies to

Chapter 5 Refinement of Security Protocols