{'fraction_non_alphanumeric': 0.0390521327014218, 'fraction_numerical': 0.005781990521327014, 'mean_word_length': 4.411915579657042, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Strand-Based Approach to Patch Security Protocols

In this paper, we introduce a mechanism that aims to speed up the development cycle of security protocols, by adding automated aid for diagnosis and repair. Our mechanism relies on existing verification tools analyzing intermediate protocols and synthesizing potential attacks if the protocol is flawed. The analysis of these attacks (including type flaw attacks) pinpoints the source of the failure and controls the synthesis of appropriate patches to the protocol. Using strand spaces, we have developed general guidelines for protocol repair, and captured them into formal requirements on (sets of) protocol steps. For each requirement, there is a collection of rules that transform a set of protocol steps violating the requirement into a set conforming it. We have implemented our mechanism into a tool, called SHRIMP. We have successfully tested SHRIMP on numerous faulty protocols, all of which were successfully repaired, fully automatically.


Introduction
A security protocol is a protocol that aims to establish one or more security goals, often a combination of authentication, confidentiality or non-repudiation. Security protocols are critical applications, because they are crucial to provide key Internet services, such as electronic-banking. So, security protocols are thoroughly studied to guarantee that there does not exist an interleaving of protocol runs violating a security goal, called an attack. Designing a security protocol is, however, error-prone. Although security protocols may be extremely simple, consisting of only a few steps, they are difficult to get right. Formal methods have been successfully used to identify subtle assumptions underlying a number of faulty protocols, yielding novel attacks.
In this paper, we introduce a mechanism that aims to speed up the development cycle of security protocols, by adding automated support for diagnosis and repair. Our mechanism has been especially designed to fix protocols that are susceptible to an attack of the full class replay [37]. 1 This attack class includes a number of sub-classes; some are well known, such as reflection, and unknown key share, but others have passed slightly ignored, like type flaw. 2 Overview of Approach for Comparison There exist several approaches to security protocol development, ranging from the systematic generation of a protocol (called protocol synthesis) to the transformation of a given protocol into one that is stronger, up to some specified properties (called protocol compiling). Protocol synthesis (blindly) generates a candidate protocol, and then tests it to see if it complies with the intended security requirements. By contrast, protocol compiling (blindly) transforms an input protocol, by wrapping it with explicit security constructs; thus, protocol compiling barely depends on the security guarantees provided by the input protocol, if any. Our method is in between, and follows the formal approach to software development; it is applied after a failed verification attempt, in order to spot a protocol flaw, and suggest a candidate patch.
To compare the relative value of our approach against that of all these competitors, we suggest to use efficiency of a given output security protocol. There are three common criteria for measuring this dimension [23]: Round complexity, the number of rounds until the protocol terminates. A round is a collection of messages that can be simultaneously sent by parties, assuming that the adversary delivers all these messages intact, immediately, and to the corresponding party. Message complexity, the maximum number of messages sent by any single party. Communication complexity, the maximum number of bits sent by any single party. We shall have more to say about this later on in the text, when comparing our method against rival techniques (see Section 8.) Contributions of Paper In this paper, we make four key contributions. First, we provide a fully automated repair mechanism, which supersedes and surpasses our previous methods (see [25,21].) The new mechanism has been entirely developed within strand spaces [39], and it is no longer heuristic-based. We have used strand spaces to provide a full characterization of a wide class of protocol attacks, and our repair strategies, in a way amenable to mechanization. Our mechanism for protocol repair has been successfully tested on a number of faulty protocols collected from the literature. Second, we provide a handful of basic principles for protocol repair, stemmed from our insights on our strand spaces characterization of a failed verification attempt. Our repair principles are simple and intuitive, and follow from a straight formalization of an interleaving of partial protocol runs, and the way messages are used to achieve an attack. Third, we provide an extension of the theory of strand spaces, which encapsulates issues about the implementation of messages, hence, providing a neat border between reasoning about the representation of a message, from reasoning about its actual form (a byte stream). Our extension consists of an equivalence relation over messages, and a distinctive notion of message origination. With it, we have been able to capture type flaw attacks, using the constructions of the strand spaces calculus. What is more, our abstraction of messages enables the transparent application of our strategies for protocol repair; that is, we can fix protocols that are subject to a replay attack because a protocol message can be mixed up with other one, without considering whether message confussion exploits a type flaw or not. Fourth, we provide a comparison of protocol repair against other prominent approaches for protocol development, concluding that our approach gives the designer a better insight for protocol development, guiding the conception for the rôle of messages and their composition.
Overview of Paper The remaining of the paper is organized as follows: first, we overview our approach to protocol repair (see Section 2). Then, we introduce notation and key, preliminary concepts (see Section 3). Next, we introduce and discuss the soundness of our extended version of strand spaces, suitable to capture type flaw attacks (see Section 4). Then, after describing the kinds of flaws we want to automatically repair (see Section 5), we provide a method for automatic protocol repair (see Section 6), and the results obtained from an experimental test (see Section 7). We conclude the paper, after comparing related work and giving directions to further work (see Sections 8 and 9).

Protocol Repair: General Approach
Our approach to protocol repair involves the use of two tools (see Fig. 1). One tool is a protocol verifier (e.g. OFMC [6,5], ProVerif [8], or Cl-Atse [40]), which is used to analyze the protocol at hand and to yield an attack on that protocol, if the protocol is faulty. The other tool, called Shrimp, embodies our mechanism for protocol repair. Shrimp compares the attack against a run of the protocol where the penetrator does not participate, called a regular run. This comparison usually spots differences that indicate where the protocol went wrong. Depending on these differences, Shrimp offers various candidate patches, each of which modifies the protocol in a specific way. Some patches may rearrange parts of an individual message or enrich it with additional information, while others may alter the flow of messages in the protocol.
Our approach to protocol repair is iterative. Since we proceed from a local perspective to fix a problem that has become apparent during attack inspection, we cannot guarantee that a fix will remove all flaws from the protocol. So, the mended protocol is sent back to the verification tool for reanalysis. If this tool still detects a bug, either because this other bug was already present in the original protocol (as often is) or because it was introduced by our method (as has never happened so far), we iterate, applying our repair strategies on the mended protocol.
Our patches change the protocol in a very restricted and conservative way, since we have no explicit representation of the intended purpose of a protocol. For example, suppose that to prevent a replay attack we have to change the structure of an individual message in a protocol so that it uniquely determines the protocol run, as well as the protocol step it originates from. To preserve the semantics of that message, we modify it only in such a way that the new message preserves both encryption (it is encrypted in the same way) and information (it contains all information present in the original message), with respect to the knowledge of some keys.
Attack analysis and protocol repair are driven by a handful of informal guidelines for protocol design. We have translated these principles into formal requirements on sets of protocol steps. For each requirement, there is a collection of rules that transform a set of protocol steps violating the requirement into a set conforming it. The correction of security protocols incorporates the use of several of these rules. However, protocol patches are not independent; so a rule requires preconditions to be applicable and should guarantee postconditions once it has been applied.
We have developed our mechanism within (our extension to) the theory of strand spaces [39]. Thus, the specification of a protocol and of one of its associated attack have both to be given using the strand space notation. Extra machinery is required to translate a given protocol specification so it is suitable for the chosen verification tool (see Fig. 1). Also, extra machinery is required to Figure 1: Overview of the general approach translate the attack output by that verification tool, if the protocol is faulty, so that the attack can be used by Shrimp. We will see later on in the text that since a protocol specification and a protocol attack must each form a bundle, this translation is straightforward. However, care needs to be taken when the attack to the protocol is type-flaw, since in this case the translation needs to deal with the introduction of special construction blocks that justify the type flaw attack. We call these construction blocks implementation traces, as shall be seen in Section 4. A preliminary version of Shrimp is available at http://homepage.cem.itesm.mx/raulm/pub/shrimp/.
such that for every v 2 ∈ V , the two following conditions hold: i) if sign(v 2 ) = −, then there is a unique v 1 ∈ V with v 1 → v 2 ; and ii) if v 1 ⇒ v 2 then v 1 ∈ V and v 1 = s, i and v 2 = s, i + 1 . ≺ B and B denote respectively the transitive and the transitive-reflexive closure of (→ ∪ ⇒).
Let s a be the strand of participant a. If a is honest, then the strand s a , as well as each individual strand node, s a , i , is said to be regular. Otherwise, it is said to be penetrator. Let v = s a , j be some node in the strand of participant a; then, we use Agent(v) = a to denote the strand participant name.
The pair (Σ, P) is said to be an infiltrated strand space, whenever Σ is a strand space and P ⊆ Σ, such that every p ∈ P is a penetrator strand. In an infiltrated strand space, (Σ, P), the penetrator can build masquerading messages using M, K, F, T, C, S, E, and D, only. Notice that penetrator traces of type M cannot suddenly output an unguessable nonce, which are modelled using origination assumptions.
A bundle is said to be regular, if it contains no penetrator strands, and it is said to be penetrator, otherwise. A message m is said to be a component of a node v if it is a component of msg(v). A node v is said to be a M, K, . . . node, if it lies on a penetrator strand with a trace of kind M, K, . . . .
The following section is entirely devoted to the extension of strand spaces that allows the capture of type-attack flaws.

Extending Strand Spaces to Capture Type Flaw Attacks
The strand space approach, [39], see above, introduces messages as a freely generated datatype, built up on atomic messages, like nonces, names, or keys, with the help of the two constructors, namely: concatenation and encryption. Hence, messages are considered to be different if their syntactical representations (as constructor ground terms) are different. However, in practice, messages are typically implemented as byte-streams, and their parsing as messages may not be unique: there might be two different messages that share the same implementation as a bytestream. Thus, the expectation of the receiver about a byte-stream controls the interpretation it gives to the message. Put differently, a penetrator can fake a message (or parts thereof) by (re-)using messages of the wrong type but with suitable implementation.
Example 1 For example, consider the Woo Lam π 1 protocol [41], given as a bundle below (there, and henceforth, Init, Resp, and Serv stand for the initiator, responder, and the server, respectively):

Init Resp Serv
This protocol is vulnerable to a type flaw attack, when the implementation of nonces can be confused with the implementation of encrypted messages, giving rise to the following attack: That n b and {|a; b; n b | } kas can be confused is not unreasonable, since the receiver, b, does not know the key, k as , shared between a and s, and it is therefore not able to realize the hidden structure of the message under encryption.
Strand spaces cannot represent the attack above, since terms are freely generated. Hence any guarantees we might obtain from this theory could make use of the freeness axioms, and so could not be transferred to a situation where they do not hold. So, in what follows, we will extend the strand space notation to deal with type flaw attacks.

Theories of Message Implementation
In a first step, we have to specify the implementation of messages, which we use to represent a run of the protocol in practice. We assume that there is some translation function I that maps any message t (given in the freely generated datatype) to its implementation I(t). Furthermore, we assume also that there are implementations {| | } I and ; I for concatenation and encryption on the implementation level, such that I is a homomorphism from messages to their implementations. We also assume that I denotes a faithful representation on individual message types, i.e. we can distinguish the implementations of, for instance, two agents or two nonces (while still a nonce and a key can share a common implementation). The following definition formalizes this idea and provides the minimal requirements to an implementation.
Definition 1 (Implementation, ≈) Let R be a set and let I be a mapping from A to R. (I, R) is an implementation of A iff the following holds.
where x and y are all meta-variables. We write m 1 ≈ I m 2 iff I(m 1 ) = I(m 2 ). If I is fixed by the environment we simply write m 1 ≈ m 2 , instead of m 1 ≈ I m 2 For a typical setting, we might need to extend Definition 1 with additional axioms specifying in more detail how messages and their operations are implemented. For example, one might like to formalize an implementation theory which copes with message length, i.e. one which assumes that all types of atomic messages have a specific length. Then, reasoning about such a theory requires arithmetic (and, in the worst case, properties of least common multiples). Another example extension of Definition 1 is the use of Meadow's probabilistic approach [30] to reason about the equality of the implementations of two messages.

Implementation Traces
We now introduce the new ability of the penetrator that enables it to reinterpret a message m as another message m , as long as they share a common implementation. Since the Dolev-Yao-like abilities of a penetrator are formalized by the set of penetrator traces (which it can use to analyze, reuse and synthesize messages), we enlarge this set by an additional rule, we call I-trace.
Definition 2 (Penetrator Trace) Let K P denote the keys initially known to the penetrator. Then, a penetrator trace of the extended strand space is either a penetrator strand, as given in Section 3, or the following: 3 (I)mplementation: −m, +m , provided that m ≈ m , but m = m .
We call the messages m and m camouflaged and spoofed, respectively. Example 2 Consider the example flawed protocol Woo Lam π 1 , introduced in Example 1. To capture the attack to this protocol, we first formalize the theory for the implementation of messages. So, besides the axioms given in Definition 1 (which hold for all implementations), we require that the implementation of nonces can be confused with the implementation of encrypted messages: hence, we add the following axiom: Then, we build the penetrator bundle describing the type flaw attack, as follows: This bundle contains two I-trace instances. The first instance is used to reinterpret the nonce n b as an encrypted message {|m| } k . To justify the application of the trace, both messages have to agree on their implementation, i.e. I(n b ) = I({|m| } k ). Both, m and k, appear for the first time 4 at the second node of this I-trace, which basically means that the penetrator is free to choose m and k such that I(n b ) = I({|m| } k ) holds. Axiom 7 guarantees that the penetrator will always find appropriate values for m and k, and justifies the application of the I-trace rule. The second instance of an I-trace rule is used to revert the reinterpretation and replaces {|m| } k by n b inside a message. The justification of this application is rather simple: the penetrator has chosen m and k such that I(n b ) = I({|m| } k ) holds. Applying axioms (1) and (2), we can deduce that then also I({|a; b; n b | } k bs ) = I({|a; b; {|m| } k | } k bs ) holds, which guarantees the applicability of the I-trace rule also in this case.
In what follows, we will abstract from this example and formalize the justification of I-trace rule applications in general.

Originating Terms and Implementation Equivalences
The application of the I-trace rule demands that two messages m and m share the same implementation. The proof for this precondition is done within the underlying implementation theory. In the example above we have used the fact that the penetrator is free to choose m and k appropriately. Therefore, to justify the rule application we have to prove that: which is an easy consequence of axiom (7). Notice that the proof obligation would change if the penetrator were not free to choose m and k, because both messages have occurred on regular strands before applying any I-trace rule. In such a case, we would have to prove: to ensure that the penetrator can always camouflage {|m| } k by n b regardless of how m and k have been chosen beforehand. As a consequence all nonces and encrypted terms would share the same implementation. Furthermore, due to the injectivity (5) of the implementation for nonces, (9) implies that the set of messages can only contain a single nonce and a single encrypted term. In practice, the proof obligation (9) is too strong and might prevent to reveal an attack since a honest principal could have unintentionally chosen m and k in such a way that actually I(n b ) = I({|m| } k ) holds. However, the probability for this to happen is similar to the probability that two principals will independently choose the same nonce in order, for instance, to use it as a challenge. This actually justifies our use of (8), and also illustrates the abstraction we have made in order to avoid probability calculations, like they are done in [30,31].
The question of selecting either (8) or (9) for justifying the first I-trace in Example 2 depends on the fact whether m and k originate at the second node of the I-trace or not. The notion of a node originating a term (e.g. a nonce) comprises the principal's freedom to choose an appropriate value for the term (e.g. the nonce). In the original approach, the notion of a node originating a term is a syntactical property of strands [39]: ; and m msg(v ), for every v ⇒ + v. m is said to be uniquely originating if it originates on a unique v ∈ V ." Any information that a strand, or its respective principal learns, occurs syntactically within some received message. Hence, a nonce originates in a particular node of a strand if it does not occur syntactically in any previous node of this strand. In our setting, the situation is different, since an information might be semantically included in a message but camouflaged by using I-traces.
For example, consider the second I-trace, spy, 4 ⇒ spy, 5 , in the attack given in Example 2, Although n b occurs in spy, 5 , it has been introduced in the bundle already in spy, 2 , and was received by the I-trace camouflaged as {|m| } k in spy, 4 .
To guarantee that a term originates also in terms of its implementation at a specific node, c.f. n b , we have to make sure that it was never subject to a camouflage. Therefore, given a node v of a bundle, we collect all camouflages introduced by I-traces occurring in front of v in the set of equational constraints of v: Definition 3 (Equational constraints) Let B = V , (→ ∪ ⇒) be a bundle and let v ∈ V . Then, the equational constraints of v wrt. B, written EQ B (v), is a set of pairs given by: where v 1 ⇒ I-trace v 2 denotes both that v 1 and v 2 both lie on a penetrator strand, and that they are interconnected via a trace of kind I.

Example 3
Going back to our running example, we find that EQ( spy, Using Definition 3, we can adapt the notion of messages originating in a node to our settings. In an abuse of notation, we extend the above definition also to encrypted messages. Hence, an encrypted message {|m | } k originates at a node v (in B) iff {|m | } k and v satisfy the conditions of the atomic message m and node v in Definition 4. In our example of the Woo Lam π 1 protocol, both m and k originate at spy, 3 .  Example 4 (The KP Protocol) Another example protocol that is subject to a type flaw attack is KP (see Fig. 2). Snekkenes [36] discusses this protocol and illustrates the attack. The type flaw attack to KP is based on the facts that: 1. On step 3, the responder, b, extracts {|a; b; n a ; k s | } kas from the component encrypted under k bs , and, then, on step 4, sends this extracted message to a; 2. Keys, agents and encrypted share common implementations (c.f. the first component of the fourth message of the responder); and 3. Therefore, the implementation of message 3 can be misinterpreted (in a different run) to be the implementation of the first component of message 4.
Similar to the previous example, we build up an appropriate message theory reflecting the assumptions laid on before. Besides axioms (1)-(6), we require additional axioms specifying the assumption that keys (generated dynamically by the server) and agents (or encrypted messages, respectively) potentially share the same implementation: Fig. 3 illustrates the resulting attack in the strand space notation using our notion of I-traces. This example penetrator bundle contains three I-traces. Node spy, 7 originates the key k s on the penetrator strand. Since this key originates at spy, 7 , the penetrator is free to choose its value, and axiom (10) guarantees that there is an appropriate key k s possessing the same implementation as a. Similar arguments hold for spy, 7 originating m and k by using axiom (11). For spy, 9 , it is the case that EQ B ( spy, 9 ) = { a, k s , k s , {|m| } k }, which justifies the application of the I-trace rule application, since it implies trivially that I({|m| } k ) = I(k s ) holds.

Protocol Flaws
In this section, we will analyze the different types of flaws resulting in an insecure protocol. The main source of such flaws in security protocols is that typically a protocol is not run in isolation, but that there are, simultaneously, multiple run instances of the same protocol that might interfere with each other. Typically, the penetrator carries out an attack on a protocol run, by reusing information gathered from another run (or even from the same one). Hence, patching security protocols is mostly concerned with disambiguating individual protocol messages in order to avoid that a message in some protocol run can be misinterpreted either as another message at a different protocol step, or as a message of the same protocol step but on a different protocol run. We start with an investigation of how to find the steps in a protocol that cause the misuse of messages and then we will discuss possible changes in the shape of such messages to avoid the confusion.

Locating the Reuse of Messages
In order to fix a protocol, we must analyze the input attack bundle of the protocol with the aim of identifying the positions where messages, eavesdropped from one or more runs, are fed into some others. So, in this section, we will provide the notation that is necessary to split an attack bundle into strand sets representing the different protocol runs involved therein. We will also define the notion of canonical bundle, which represents an ideal protocol run imposed by a set of given honest strands. Comparing the message flow in the canonical bundle versus the attack bundle enables us to determine the crucial steps in the protocol which cause the flawed behavior.

Roles and Protocol Participation
We start with the formal introduction of roles as a sort of generic strands. Roles are instantiated to strands, by renaming generic atomic messages to specific elements in TK. We also consider penetrator traces as roles.

Definition 5 (Roles)
A role r is a pair s, M of a strand s and M ⊆ TK of atomic messages occurring in s. Intuitively, r denotes a strand s parameterized in M .
In abuse of notation we identify a role r with its strand s if M is the set of all atomic messages occurring in s.

Definition 6 (I-th
Step Execution of a Strand) Let r = s, M be a role and let 1 ≤ i ≤ #(s). Then, a strand s is an instance of r, up to the execution of step i, iff there is a renaming , then s is said to be complete; otherwise, it is said to be partial. Given a set R of roles, then R H denotes the regular roles in R, and R P those of the penetrator. Likewise, let T be a set of strand instances, then T H denotes all regular, possibly partial, strand instances, and T P all the penetrator ones.
Example 5 The classical Needham-Schroeder Public Key (NSPK) protocol consists of two roles: Then, from these roles, we may obtain the following strand instances: A bundle B is constructed from a set of roles, by combining various role instances with the help of inter-strand communication, →. Hence, stripping off inter-strand communication from a bundle, B, we end up with a multiset T of isolated instances of some roles.
Definition 7 (R-Bundles) Let R be a set of roles and T be a multiset of (possibly partial) strand instances of roles in R. Then, B is a R-bundle out of T iff (i) each node in a strand of T is also a node in B and vice versa, and (ii) n ⇒ n iff n ⇒ B n for all nodes n, n of B (and T respectively).
We define a canonical bundle to be a bundle representing an intended run of a protocol. In a canonical bundle, each role is instantiated by a strand exactly once, and each strand instance is complete. Furthermore, the strands of a canonical bundle, and thereby the associated roles, are all regular.
Given a canonical R-bundle B we can easily retrieve R (up to isomorphism) from B (or T ) by collecting all (renamed) strands occurring in B (or T , respectively).
Furthermore, we can consider each finite, acyclic graph and that R is the set of all roles extracted from B. Later on, we use this property in order to formulate changes of a protocol (i.e. changes of the roles of a protocol) simply by changing the original canonical protocol and interpret the resulting graph as the canonical bundle of the new protocol comprising also its new roles (up to isomorphism).
In what follows, we will use sans serif fonts to indicate messages in canonical bundles. Furthermore, we use the superscript c to denote a canonical bundle B c , and the roles R c or set of strand instances T c of a canonical bundle. In the examples, we also assume that the honest roles of a canonical bundle are normalized so that α = {}, and then write r, i , instead of r[#(r), {}], i . To illustrate our ideas and definitions, we will make use of various protocols as running examples. We first present canonical bundles of these protocols.

Example 6
We start with the NSPK protocol. Given the roles R c NSPK = {Init, Resp} of NSPK, (12) and (13), we obtain the following canonical bundle, B c :

I nit Resp
Example 7 As another example, consider the Wide-Mouth-Frog (WMF) protocol. With R c WMF = {Init, Serv, Resp}, the canonical bundle of this protocol is as follows: Ser v Resp Example 8 As a third example, look into the Woo Lam authentication protocol: ⇓ + a; b; n; n kas − − → − a; b; n; n kas ⇓ + a; b; n; n kas ; a; b; n; n k bs − − → − a; b; n; n kas ; a; b; n; n k bs ⇓ ⇓ − b; n; n ; k ab kas ; a; n; n ; k ab k bs ← − − + b; n; n ; k ab kas ; a; n; n ; k ab k bs ⇓ − b; n; n ; k ab kas ; n; n k ab ← − − + b; n; n ; k ab kas ; n; n k ab I nit Resp Ser v Example 9 Our last example is the Denning-Sacco-Shared Key (DSSK) protocol.

Characterizing the Perspective of each Participant in a Protocol Attack
Attacks detected by some security protocol analyzer typically involve different (partial) protocol runs. Messages generated in one run are misused to fake messages in other runs. Since honest principals only see the messages of a protocol that they receive or send, each principal develops his own view on the protocol run. In the attack of the NSPK protocol, see Example 10, Alice assumes she is communicating with Charly, while Bob thinks he is communicating with Alice. However, both views are not compatible. In the following definition, we truss compatible strands of honest principals to so-called protocol sections. While in a canonical bundle all honest strands belong to a single protocol section, the attack bundle of NSPK consists of two protocol sections denoting the (faked) protocol runs of Alice with Charly and Alice with Bob, respectively.
Definition 9 (Protocol Section) Let B c be a canonical R c -bundle out of some T c and let B be an R-bundle out of some T . A set T ⊆ T is a protocol section wrt. B c iff there is a renaming β such that, for all r[i, α ] ∈ T , there is one, and only one, r[#(r), α] ∈ T c , with α being a function denoting the composition of β and α and subject to the domain TK(r). We call β the canonical renaming for T wrt. B c .
We call the mapping that maps each node of a regular strand Example 10 To exemplify all these notions, let us study again the attack on NSPK, illustrated in the bundle shown below.
Besides the two roles of R NSPK , this bundle contains the penetrator traces (K), (E), and (D).
It is therefore an R-bundle, with R = {(K), (E), (D)} ∪ R NSPK . T consists of the six individual strands occurring in the bundle.
Using the canonical bundle B c given in Example 6, this attack bundle contains an instance is not a protocol section, because β and β are incompatible.
Example 11 Concerning the WMF protocol (see Example 7) AVISPA [3] has found that it fails to guarantee weak authentication of the responder, Bob, to the initiator, Alice, yielding the attack bundle shown below: Comparing this attack bundle against the canonical one, B c , shown in Example 7, we notice that it contains instances for the initiator and responder strands, while the server is impersonated by the penetrator: Again, T 1 ∪ T 2 is not a protocol section, because β init and β resp are not compatible.
Example 12 DSSK is vulnerable to a so-called multiplicity attack (see Section 6.3): Thus, apart from penetrator activities, an attack bundle contains honest strands that operate under different assumptions (captured by the specific elements in TK instantiating each strand). This is in contrast with a canonical bundle, where all strands operate for the same run (parameters). A protocol section hence groups together all the honest strands in the attack bundle operating under the same assumptions. This is the rationale that enables us to compute the minimal set of protocol sections which, together with the penetrator's activities, constitutes a given attack bundle.
Example 13 Let us illustrate coverage through two examples. Go back to Example 10; there, {T 1 , T 2 } is a coverage of T ; it is also optimal since T 3 is not a protocol section. Now go back to the attack bundle given in Example 12; then, we obtain an optimal coverage consisting of two protocol sections: the first covers an instance of the entire canonical bundle, while the second consists only of the second copy of the responder strand.

The Misuse of Messages
In what follows, we characterize situations in which the penetrator confuses an honest principal, by misusing an observed encrypted message. In a first step, we characterize the conditions under which a honest principal will accept a received message, because it satisfies his expectations, as formulated in the definition of the protocol.
Definition 11 (Acceptable Messages) Let m, m be messages, K a set of keys and V ars ⊂ TK(m) be a set of atomic messages in m. Then, m is accepted for m wrt. a renaming σ with DOM (σ) ⊆ V ars and keys K , iff K (m, m , σ) according to the following rules: if σ 1 , σ 2 compatible and I(m ) = I(m 1 ; m 2 ) (Seq) if σ 1 , σ 2 compatible, and We say m is accepted for m wrt. atoms V ars and keys K if there is a renaming σ with DOM (σ) ⊆ V ars such that m is accepted for m wrt. σ and K .

Example 14
For example, consider again the attack to the NSPK protocol (see Example 10). For the sake of simplicity, assume that I is the identity function. In the second step of her strand, Alice, a, expects a message m = {|n a ; n b | } ka . Suppose she receives m = {|n a ; n c | } ka , then we can derive:

Enc
Example 15 As a second example, consider now the type flaw attack on the flawed Woo Lam π 1 protocol, given in Example 2 (see Example 2). In step 3 of his strand, Bob, b, expects a message of the form {|a; b; n b | } kas , but receives n b instead. According to our definition, b will accept n b provided that there is an instantiation σ for n b and k as such that I(σ({|a; b; n b | } kas )) = I(n b ). Assuming b takes the key k as to be k, then we would infer the following conditions as those under which b accepts n b as a legal message: Now, an obvious misuse is that the penetrator sees an encrypted message in a protocol run and reuses it in another run, but in the same step. We can easily detect this case, by comparing the protocol sections of the node where the message is originating and the node where the message is received by the honest principal. We call such a situation a cross-protocol-confusion. Another misuse is to use some encrypted message observed in a run to camouflage another message of a different step (but possibly in the same run), because they coincide in their structure. In order to detect this new situation, we compare the attack bundle with the canonical bundle and check whether the encrypted message in the attack bundle and its counterpart in the canonical bundle originate at corresponding message positions. We call this alternative situation message confusion.
The definition below captures our intuition of the misuse of messages; it makes use of the standard notion of message position, which is an address represented by a string. Roughly, the subterm of m, at position π, m|π, is captured as follows: m| = m, f (m 1 , . . . , m k )|i · p = m i |p, where and · respectively stand for the empty string, and string concatenation. We use m[π ← m ] to denote the message that results from replacing m|π with m in m.
Definition 12 (Confusion) Let B be an R-bundle out of some T , B c be a canonical R c -bundle with R H ⊆ R c . Let C be an optimal coverage of T wrt. B c and θ be the corresponding canonical mapping. Then, there is a confusion in a honest node v ∈ B iff there is a position π of v with {|m| } k = msg(v)|π, originating in an honest node v ∈ B, at some position π of msg(v ), such that either: • v and v are located on strands of different protocol sections, giving rise to a cross-protocol confusion and v ∈ B causing the cross-protocol confusion with {|m| } k , or • msg(θ(v))|π does not originate in θ(v ) or EQ B c (θ(v )) I(msg(θ(v ))|π ) = I(msg(θ(v))|π), giving rise to a message confusion and v ∈ B causing the message confusion with {|m| } k .  [3, β ], 2 ) = r resp , 2 of the canonical bundle at position root. Notice also that ∅ {|n, n | } ka = {|n, n | } ka holds.

Limits of Changing Messages to Protocol Fix
We now deal with the situation in which an attacker has already been able to trick an honest principal into accepting a message m , instead of an expected message, m, for a given protocol. Therefore, we want to change the protocol in such a way that the attacker is no longer able either to construct m from a collection of eavesdropped messages, or to pass m as a camouflaged message for m. To formalize this idea, we first introduce the following definitions.
Definition 13 (Agents Knowledge) Let s be a strand of a bundle B. Further, let TK Init and K Init respectively be the set of atomic messages in s and the set of keys, initially known to the agent of s. In particular, TK Init includes all atomic messages that are originating in s.
Given a node s, i of s then pred ( s, i ) is the closest negative predecessor node of s, i , if any, and it is undefined, otherwise; i.e. if ∀1 ≤ j < i. sign( s, j = +. The set of known keys K s,i in a negative node s, i , with i ≤ #(s), is defined by: and the set of known atomic messages TK s,i in a negative node s, i , with i ≤ #(s), by: Now, if a protocol has to be changed in order to avoid confusions, there are two opposing requirements. On the one hand, we would like to add additional information into individual messages to allow the recipient to distinguish the original from the faked message. But, on the other hand, we would not like to change the intended semantics of the protocol. Our approach is not based on any explicit semantics of the protocols under consideration, but the semantics is only implicitly given by the syntactical design of the protocol. When changing steps of the protocol syntactically, we ought to make sure that the implicit semantics of the protocol is not changed either. We try to achieve this goal by changing individual protocol steps only using conservative extensions and reshuffles of messages.
Suppose, for example, that to patch a protocol, we need to modify an encrypted term, t. Clearly, upon the reception of t, a principal can decompose it into the subterms that are visible under some known keys, K . When patching a protocol by modifying t into t , we further require that, under K , t exposes at least the same information to the principal as t.
Definition 15 A message substitution σ is information enhancing wrt. a set M of messages iff

Example 21
The message substitution σ in Example 20 is information enhancing wrt. {C, D}.

Definition 20 (Collision Freeness) Let m be a message and M ⊆ A be a set of messages.
Then, m is collision free with respect to M iff for all m ∈ M it is the case that m ≡ m .

Protocol Repair
We have seen that we find bugs in protocols by analyzing a bundle containing a penetrator strand. Often, our analysis suggests a change in the structure of a message, and, in that case, it identifies the node originating such message considering a bundle denoting an intended protocol run. With this, we compute the changes to be done in one such a regular bundle, which are then propagated to the protocol description. The following definitions aim at a meta-theory to allow for tracing the consequences of changing all the nodes in the set of strands caused by a change in a particular node.
Definition 21 (Adaptation) Let B be a bundle, v 0 be a positive node in B and σ be a message substitution. The adaptation Ad (B, v 0 , σ) of B wrt. v 0 and σ is a graph B that is isomorphic to B; we shall use ζ to denote the corresponding isomorphism that maps the nodes of B to nodes of B . The message of each node in B is defined by msg(ζ(v)) = msg(v) if v 0 B v and msg(ζ(v)) = σ(msg(v)) otherwise.
Suppose B is an R-bundle, then the adaptation Ad (B, v 0 , σ) can be considered as a canonical R -bundle where R is the set of renamed strands embedded in Ad (B, v 0 , σ) (c.f. Section 5.1.1). (B, v 0 , σ) of a canonical bundle is safe iff Dom(σ) originates in v 0 and σ is information enhancing.
Let v an arbitrary node of B. We do a case analysis on the position of v relative to v 1 and v 2 : ζ 1 (v))).

Patch Methods for Protocols
In their seminar paper, [1] Abadi and Needham proposed general guidelines for a protocol design, which cope with the problem of disambiguating messages in a protocol. In particular, the principle 3, agent naming, prescribes that all agent names relevant for a message should be derivable either from the format of the message or from its content. This prevents the reuse of a message in the corresponding step of a different run of the same protocol. Principle 10, recognizing messages and encodings, deals with the second source of misuse and demands that a principal should be able to associate which step a message corresponds to. These principles will result in different ways to fix a flawed protocol.
We shall now discuss various rules to fix a faulty protocol. As already illustrated in Section 2, we use a standard protocol analyzer, like AVISPA, to generate an example of an interleaving of protocol runs in which a honest principal has been spoofed. This example is translated into the strand space notation forming an attack bundle B. Additionally, we translate the intended protocol run into a canonical bundle B c . Comparing both bundles provides the necessary information where and how we have to change the protocol. The first step is to construct a coverage for B, representing the different views of the honest principals on the protocol runs of the attack. The ultimate goal is to remove all confusions occurring in B by small changes of individual protocol steps. Therefore, we will analyze the various sources for confusions and how they can be avoided by patching the protocol. The type of patch rule used depends on the type of confusion (c.f. Definition 12).
A rule (to patch a protocol) is a patch method, a tuple comprising four elements: i) a name, ii) an input, iii) preconditions, and iv) a patch. The first element is the name of the method, a string, meaningful to the flaw repair performed by the method. The second element is the input: a bundle B describing the attack, a canonical bundle B c describing the intended run of the protocol, and a distinguished node in B causing a confusion. The third element is the preconditions, a formula written in a meta-logic that the input objects must satisfy. Shrimp uses these preconditions to predict whether the associated patch will make the protocol no longer susceptible to the attack. Finally, the fourth element is the patch, a procedure specifying how to mend the input protocol.

Patching Protocols with a Message Confusion Flaw
Suppose that a given attack bundle B has a message confusion in some node v ∈ B. This means that a honest principal accepted a message in some step of the protocol that was faked by the penetrator. Since the confusion is fatal, the penetrator reused some encrypted message from another message (possibly from a different protocol step) that he could not construct himself. Hence, the problem is that the encrypted messages within the reused message can be confused with the encrypted message that is part of the expected message. To fix this vulnerability we have to change one of these messages to break the similarity. The simplest way of doing this is to rearrange the information stored in the message. For instance, we may reverse messages of a concatenation occurring in msg(v). In general, we search for a message m such that msg(v) ≡ m, but msg(v) = m. In some cases, and in particular if msg(v) simply is an encrypted atomic message, there are no messages m satisfying these conditions, and we have to extend msg(v) with an additional information bit, typically a tag, to resolve the confusion.

Definition 24 (Message-Encoding Rule)
The message-encoding rule is the following transformation rule: Input: B c , B with a node v ∈ B causing a message confusion with a message t = msg(v)|π Preconditions: i) msg(θ(v))|π originates at v in B c at position π , ii) v belongs to a protocol section with renaming β Patch: Let t be a message and B c a graph such that i) σ = {msg(v )|π ← t } is an information enhancing message substitution wrt. TK v , ii) t is collision free wrt. msg(v ) for all nodes v in B c , and iii) msg(v) is not accepted for β(σ(msg(θ(v)))) wrt. TK v and the known keys K v in v.

I nit Ser v Resp
Example 24 In case of the Woo Lam π 1 protocol (see Example 2), there is a message confusion in v = r resp [5, β], 5 with t = {|a; b; n b | } k bs , t originates in r resp [5, β], 4 while in the canonical bundle the corresponding message {|a; b; n b | } k bs originates in v = r Serv , 2 at top level. Again, we obtain a suitable message t = b; a; n b by permuting the messages of t such that σ = {t ← t } is an information enhancing message substitution wrt. TK θ(v ) . t is obviously collision free with all nodes of the canonical bundle B c and {|a; b; n b | } k bs is not accepted for {|b; a; n b | } k bs wrt. ∅ and {k bs }.
Thus, the resulting bundle Ad (B c , v , σ) looks as follows: Ser v Notice that the intruder can elaborate a type flaw attack on a protocol whenever he is able to make a protocol principal accept a message of one type, m, as a message of another, m . In that case, m and m share the same implementation, m ≈ m . Thus, to remove the protocol type flaw, it suffices to break m ≈ m . So message-encoding will attempt this by rearranging m's structure while keeping its meaning intact. If this operation does not suffice to break the confusion between m and m , it will then insert into m vacuous terms, tags actually, as in [20]. Finally, when incurring on these changes, our methods ensure that the new protocol message does not clash with some other.

Patching Protocols with a Cross-Protocol Confusion Flaw
Protocol guarantees are usually implemented via cyphertexts (c.f. the rationale behind an authentication test [18]). To realize authentication, the name of the agents that are relevant for the intended consumption of a cyphertext, namely the originator and the intended recipients, should be all derivable from the cyphertext itself (c.f. principle 3 for protocol design of Abadi and Needham [1]). When this is not the case, the associated message, and the protocol itself, has agent naming problems.
When an agent naming problem occurs, a penetrator can reuse the message corresponding to the i-th step of the protocol in some run, to camouflage that of the i-th step but of another run. Thus, the penetrator reuses one or more associated message cyphertexts so as to impersonate the corresponding originator or as to redirect them to an unintended recipient. From a technical point of view, such a message lacks sufficient information about the particular protocol run it was generated for.
We introduce a method designed to fix a faulty protocol with a cross-protocol confusion flaw. We fix this flaw inserting the names of the correspondents that are not explicitly mentioned in the message that has been reused to carry out the attack.
Definition 25 (Agent-Naming Rule) The agent-naming rule is the following transformation rule: Input: B c , B with a node v ∈ B causing a cross-protocol but not a message confusion with a message t.

Preconditions:
i) t originates in v ∈ B at position π, ii) v belongs to a protocol section with renaming β, and iii) v belongs to a protocol section with renaming β , with β = β Patch: Let t be a message such that Then, return Ad (B c , θ(v ), σ) as a result of the patch.
Obviously, β and β differ only 5 in their renaming of the atomic message b, which results in a patched message t = {|n; n ; b| } ka that is to be expected in r init [3, β], 2 . Therefore, we adjust the protocol using σ = {{|n; n | } ka ← {|n; n ; b| } ka } and obtain the fixed protocol (cf. the original definition, given in Example 6) by Ad (B c , θ(v ), σ):

Patching Protocols with a Replay Protection Flaw
The agent-naming rule fails to patch a protocol if the set {m ∈ TK v | β(m) = β (m)} is empty, which means that there are two identical copies of an honest strand in the penetrator bundle contributing to different protocol runs. In other words, the behavior of this principal is deterministic with respect to the messages received from its environment. This gives rise to a multiplicity attack in which the penetrator simply replays a communication from a (pre-)recorded protocol run, and causes an agent to consider that somebody is trying to set up a simultaneous session, when he is not [26]. The session-binding rule deals with faulty protocols that contain this kind of flaw, called replay protection. Two example faulty protocols of this kind are WMF (c.f. Example 7) and DSSK (c.f. Example 9) protocol. None of these protocols satisfies strong authentication of B to A, Both prescribe the responder, b, to react upon an unsolicited test [18].
In both cases, the responder b participates in the protocol only in a passive way, by receiving some message. Unless the responder stores details about each protocol run, it cannot distinguish copies of such a message replayed by an attacker, from genuine messages in independent protocol runs. Technically speaking, there are no atoms that originate on the responder strand allowing it to actively differentiate individual protocol runs. Shrimp is equipped with a repair method that introduces a nonce-flow requirement to fix this flaw [1,35,26,18] (c.f. principle 7 for protocol design of Abadi and Needham.) The idea is to use some handshake or challenge-response approach to involve the responder actively in the protocol.

Definition 26 (Session-Binding Rule)
The session-binding rule is the following transformation rule: Input: B c , B with a node v ∈ B causing a cross-protocol but not a message confusion with a message {|m| } k .

Preconditions:
i) v belongs to a protocol section T with renaming β, ii) v belongs to a protocol section T with renaming β and T = T , and iii) {|m| } k originates in v ∈ B at position π. Patch: Introduce a challenge-response between the strand s of θ(v) and the strand s of v , where v is a minimal element wrt.
where n is a nonce originating in v 1 , f is an arbitrary injective function on nonces, and either k = k −1 ∈ K s,#s ∩ K s ,#s \ K P , or k and k −1 are the public and private key of Obviously, this patch solves the problem of having identical copies of the same honest strand s in a penetrator bundle. Since the newly introduced nonce originates in s, it also uniquely originates in a faithful realization of the protocol; i.e. the honest principal will generate individual (i.e. different) nonces for each individual protocol run.

Example 26
Consider the patched Wide-Mouth-Frog protocol in Example 23. After eliminating the message confusion there is still an attack possible as illustrated in the following penetrator bundle. As Lowe [26] has described the attack, the penetrator impersonates the server and replays the server's response making the responder to believe that a second session has been established.
Obviously, there is a cross-protocol confusion in the first node of the second responder strand with the message {|a; t a+d ; k| } k bs . The responder strands belong to different protocol sections; however, both agree in their renamings β, β of the canonical bundle. This prevents the application of the agent-naming rule and enables the application of the session-binding rule. Init, 1 is the only B c -minimal element of {v | v B c Resp, 1 } and we choose to use the increment by one as f . K Init,1 ∩ K Resp,1 \ K P = {k, k as } ∩ {k, k bs } = {k}. Hence, we select k as the encryption key for the challenge response and we obtain the following patched canonical bundle:

I nit Ser v Resp
Example 27 As another example consider the attack on the DSSK protocol in Example 12. Again we have two identical copies of the responder strand. Similar to the previous example, there is crossprotocol confusion in the first node of the second responder strand with the message {|b; k ab ; a; t s | } k bs . Again, Init, 1 is the only B c -minimal element of {v | v B c Resp, 1 } and we choose to use the increment by one as f . With K Init,3 ∩ K Resp,1 \ K P = {k ab , k as } ∩ {k ab , k bs } = {k ab } we choose k ab as the encryption key and obtain the following patched DSSK protocol:

Combining Rules
As already mentioned in Section 5.3, our approach runs a protocol verifier and uses its output, in particular the faulty protocol run, to compute the attack bundle and to select an appropriate patch rule to fix the protocol. We apply one rule at a time and resubmit the patched protocol to the protocol verifier. This process iterates until either no more flaws are detected by the verifier, or there are no more applicable rules. Since this approach constitutes some sort of rewrite system on security protocols, it is tempting to analyze formal properties of rewrite systems, like confluence and termination in this setting. Suppose there is a faulty security protocol containing various flaws. In the first place, the order in which Shrimp examines the flaws depends on the order in which attacks on the security protocol are discovered by the protocol verifier. Given a particular attack bundle, we may have different messages that allow the penetrator to mount the attack. Concerning a particular message, at most one of the rules message-confusion, agent-naming and session binding would be applicable, because the preconditions of the three rules exclude one another. As far as an attack makes use of a faulty implementation and the attack bundle involves I-traces, there is a choice point between patching the implementation, such that the type confusion is no longer applicable or patching the protocol itself so that any type confusion does not cause any harm. Both patches are independent of each other, since they operate on different levels. If the attacker bundle reveals several flaws, i.e. there are various messages that can be misused to mount an attack, then, lemma 18 guarantees that rules based on adaptations like the message-confusion and the agent-naming rules commute.
There is no strong argument concerning the termination of Shrimp, although in all our examples (see Section 7) it was never the case that our approach did not terminate. One reason is that rules working on ambiguous messages will disambiguate them with respect to the entire bundle. Therefore, the number of potentially ambiguous messages in a protocol will decrease with each application of such a rule.

Protocol
Source Attack Source Woo-Lam π 1 [41] [20] Otway-Rees [9] [9] Neuman-Stubblebine [33] [12] KP [36] [36] NSLPK [26] [20] BAN Yahalom [9] [9] GDOI [31] [31]  Tables 2 and 1 summarize our results. We considered 40 experiments, of which 20 involve protocols borrowed from the Clark-Jacob library; 6 4 are variants of some of these protocols (annotated with ); 5 were borrowed from the literature (these 5 protocols are all known to be susceptible to a type flaw attack); and 11 are protocols output by Shrimp, a next-generation of an input protocol. Next-generation protocols are shown in a separate row within the associated entry. Protocol verification was carried out using AVISPA. Table 2 portrays information about protocols that were fixed fully automatically. Each row displays the result of testing a protocol against a (hierarchical) collection of properties: secrecy, s, weak authentication of the initiator, wa i (respectively responder, wa r ) and strong authentication of the initiator, sa i (respectively responder sa r ), where wa i < sa i (respectively wa r < sa r .) 6 The Clark-Jacob library comprehends 50 protocols, 26 out of which are known to be faulty. So our validation test set contains all but 6 of these security protocols. The faulty protocols that were left out are not susceptible to a replay attack.
While secrecy has a definite meaning, authentication is not; however, Lowe's hierarchy of authentication [27] has become the standard reference in the literature. Not surprisingly, AVISPA's levels of authentication, namely: weak authentication, and (strong) authentication, correspond to Lowe's. We refer the reader to [27] for the precise meaning of these terms.
The table separates the verification results for the original protocol, before, and the mended protocol, after, as output by Shrimp. The field value that exists at the intersection between a protocol P and a property φ might be either T, meaning P satisfies φ, F, meaning P does not satisfy φ, or X, meaning this property was not tested (because P was not expected to satisfy it.) Column M specifies the method that was applied to modify each faulty protocol: message (E)ncoding, agent (N)aming or session (B)inding. In all our experiments, the application of a patch method yielded a revised protocol able to satisfy the security property that the original one did not. Whenever applicable, each mended protocol was then further requested to satisfy the remaining, stronger properties in the hierarchy, thus explaining why some entries have several runs. Note that in the discovery of some attacks we had to specify the possibility of losing a session key (annotated with †.) Shrimp is thus able to automatically identify a flaw and a successful candidate patch in 33 faulty protocols. Of these experiments, it applied 12 times agent-naming, 5 times messageencoding, and 17 times session-binding. Notice that Shrimp was able to repair 18 protocolos of the 20that were borrowed from Clark and Jacob. The other two protocols could not be corrected automatically, since we are currently extending Shrimp so as to incorporate our extension of the strand spaces to fully account for the theory presented in this paper. So, the faulty protocols in Table 1 have been tested by hand only.
Further development work is also concerned with automatically translating a protocol (respectively an attack) from a strand space notation to AVISPA HLPSL, and back. While most of these translation can be automated, we anticipate human intervention will be required for the formulation of security goals, using AVISPA's special predicates, namely: witness, (weak ) authentication, and authentication on.
We have made Shrimp try to patch the IKEv2-DS protocol, which is part of AVISPA's library and an abstraction of IKEv2. We found that, upon an abstraction of the equational issues inherent to the AVISPA attack, Shrimp successfully identifies a violation to a good practice for protocol design: the omission of principal names. While the revised protocol is up to satisfy strong authentication on the session key, this patch may be subject to a criticism because IKEv2 was deliberately designed so that no principal should mention the name of its corresponding one. We then deleted agent − naming and re-ran our experiment; this time Shrimp applied session binding suggesting a protocol similar to IKEv2-DSx, which also is part of AVISPA's library and attack-free.

Related Work
We now proceed to compare our method against techniques that are rival in the sense outlined in Section 1.

On Protocol Repair
R. Choo [13] has also looked at the problem of automated protocol repair. His development framework applies the SHVT model checker [34] to perform a state-space analysis on a (indistinguishablenessbased) model of the protocol (encoded using asynchronous product automata) under analysis. If the protocol is faulty, Choo's framework will first check if the associated attack is captured in the database of attack classes, and then will apply the repair. Unfortunately, the attack classes are not formalized, and it is not clear whether for each class there is an associated repair method. [13] introduces only one repair method; the method indiscriminately inserts the names of all the participants involved in every cyphertext of the protocol. By way of comparison, for each attack class we provide a formal characterization, amenable to mechanization, and an specific repair strategy.
What is more, if applied, our naming repair mechanism will selectively introduce only the agent names required to rule out the attack. Also, the class of replay attacks, fully captured by our methods, comprehends the attack classes involved in [13].

On Protocol Compiling
The compiling approach to protocol development takes a protocol that is weak, in some security sense, and returns other that is stronger, and made out of modifications of the input one. Example methods in this vein include [22,16,2]. They are all based on the seminal work of Canetti on universal composition, which we describe first as it will be the starting point of our comparison.
Canetti's Universal composition theorem [11] is used to deduce the security of a complex system, from a proof of the security of its constituents. For security protocol development, composition theorems are very attractive, since they assert that if a protocol is secure, when considered in isolation, then it will remain secure, even if simultaneously run an unbounded number of times. In particular, [11] has shown that for universal composition of a protocol to hold, it suffices that each of its runs is independent, and that run independency can be guaranteed prefixing a pre-established Session ID (SID) into every plaintext message, which is to be subject of a cryptoprimitive (encryption or signing) by the protocol. We call this transformation SID session tagging. Although Canetti provides various ways of forming and pre-establishing a SID, it is common for a SID to be set the concatenation of the participants' names, together with the fresh nonces such participants have all previously generated, and exchanged one another (thus the name pre-established SID).
Canetti's proof hinges on the assumption of state disjointness across all instances of a protocol, thus, ruling out the possibility of using, for example, long-term keys. Accordingly, Canetti and Rabin [10], later on, showed that Canetti's results still holds for an, albeit limited, shared randomness, including long-term keys. Put differently, SID session tagging is enough to provide state disjointness.
Yet, Küsters and Tuengerthal [24] have recently shown that SID session tagging is quite a strong transformation for separating runs one another. In particular, they established that universal composition can be achieved on two provisos: first, that the protocol is secure in the singlesession setting, and, second, that it satisfies a property they call implicit disjointness. To put it another way, real-world security protocols do not typically use a pre-established SID; therefore, it is necessary to find a further ordinary condition, namely: implicit disjointness, whereby state disjointness can be guaranteed. For a protocol P to satisfy implicit disjointness, two conditions are required. First, participants are not compromised. Second, conversations in a session, especially decryption preceeded by encryption, must match. Session matching is, in turn, guaranteed by an appropriate partnering function. Together, implicit disjointness and single-session security, resemble Gutmann's notion of skeleton [19]. Implicit disjointness can be met simply by selectively inserting randomness in cryptographic material.
In the remaining of this section, we survey protocol compiling methods, stemmed from composition theorems. We shall assume that, after k previous rounds, participants a 1 , . . . , a k have exchanged fresh nonces, n 1 , . . . , n k , to come out with SID = a 1 ; . . . ; a k ; n 1 ; . . . n k .
Katz and Yung [23] first showed how to turn a Key Exchange (KE) protocol, known to be secure against a passive adversary, into one that is secure against an active adversary; i.e., into an authenticated KE protocol. Their method transforms each protocol step, j. a i → a i+1 : j; a i ; m, into: Later on, Cortier et al. [16] suggested a transformation that guarantees beyond authentication, at the cost of assuming a weaker input protocol that is only functional. Each protocol step, j. a i → a i+1 : m, they change into: which makes heavy use of cryptoprimitives. Notice that, in particular, [23,16]'s methods depend on the creation of new signing/encryption key pairs, apart from those that already appear in the original protocol. Finally, Arapinis et al. [2] suggested a straightforward application of Canetti's universal composition theorem, using SID session tagging, although only cyphertexts are modified. Notice that the plus of this method is that it does not require the creation of new key pairs. Thus, following the result of [24], all these protocol refinement techniques have several weaknesses. Firstly, most assume the existence and availability of a public key infrastructure. Secondly, they increase both the round complexity, and the message complexity: the extra message exchange implements actually a form of contributary key-agreement protocol; yet, minimizing the number of communications usually is a design goal. Thirdly, they involve additional, indiscriminate computational effort, associated to the extra encrypted material, thus increasing the communication complexity. Fourthly, SID session tagging is as typing tagging (see review on [20] below), albeit dynamic, and thus poses the same additional vulnerabilities (the adversary knows SID, and, therefore, can use it to drive the breaking of long-term keys). And fifthly, in all these mechanisms, it is assumed that the participants are all honest: this is restrictive, since it is necessary to consider attacks where the penetrator is part of the group, or even where several participants collude to exclude one or more participants, as in [32]. These properties are all in contrast with our approach, since: we do not require extra key pairs; we selectively include extra rounds, by means of key confirmation; we selectively insert extra bits of information on an specific message; and we minimize the use of tags.
Concluding, even the less heavily cryptographic dependant mechanism of protocol refinement [2] would 'repair', for example, NSPK (see Example 6) as follows: This increases the number of rounds, and triples the size of the messages to be ciphered. Also, notice that Choo's approach would not include the extra first two steps, but would tag each message to be cyphered using SID = a; b. By way of comparison, our repair mechanism would yield NSLPK (see Example 14.)

On Further Strategies for Protocol Repair, Based on Old Principles
When considering an automatic protocol repair mechanism like ours, one wonders whether there is an upper bound as to the information that every message should include to avoid a replay. If there is one, we could simply ensure that every message conforms it previous to any verification attempt. Carlsen [12] has looked into this upper bound. He suggested that to avoid replays every message should include five pieces of information: protocol-id, session-id, step-id, message subcomponentid and primitive type of data items. In a similar vein, Malladi et al. [29] suggested one should add a session-id contributed to by every participant to any cyphertext in the protocol, as in [11], and Aura [4] suggested one should also use several crypto-algorithms in one protocol and hash any authentication message and any session key. Protocol designers, however, find including all these elements cumbersome. 7 By comparison, Shrimp only inserts selected pieces of information considering the attack at hand but may add steps to the protocol if necessary to fulfill a stronger security property. What is more, it follows, from Canetti's universal composition theorem, that these all principles are subsumed by SID session tagging, which inserts even less information.

On Protocol Synthesis
Complementary to ours is the work of Perrig and Song [35], who have developed a system, called APG, for the synthesis of security protocols. The synthesis process, though automated, is generate and test: APG generates (extends) a protocol step by step, taking into account the security requirements, and then discards those protocols that do not satisfy them. APG is limited to generate only 3-party protocols (two principals and one server). As a reduction technique, it uses an impersonation attack and so rules out protocols that (trivially) fail to provide authenticity. The main problem to this tool is the combinatorial explosion (the search space is of the order 10 12 according to the authors).

On Type Flaw Attacks
In the past, several approaches have been developed to deal with potential type flaw attacks. This work can be classified into two different areas: The first area is concerned with changing the representation of messages to prevent type flaw attacks in the first place. Heather et al. [20] use a tagging of messages to identify the type of a message in a unique way. Considering original messages combined with their tagging as new atomic entities, such messages constitute a generated algebraic datatype with non-overlapping ranges of the constructors satisfying the most important properties of the abstract message theory. Since tags themselves will reveal information about a message to a penetrator there are several refinements of this tagging approach to minimize the set of subterms of a message that have to be tagged (e.g. [28,29]).
The second area is concerned with the verification of protocols that may contain type-flaw attacks. A prominent approach is to replace the standard representation of messages as a freely generated datatype by a more involved datatype dealing with equations between constructor terms. As a consequence, terms representing messages have to be unified modulo a theory modeling the equality relation on messages. While this approach assumes that only entire messages can be interpreted in different ways, Meadows [30,31] investigated the problem that the implementation of a message could be cut into pieces and one of such pieces might be used to mock another message, e.g. some part of a bit-string representing an encrypted message is reused as a nonce. In her model, messages are represented as bit-streams. Based on an information flow analysis of the protocol and the knowledge how abstract messages are represented as bit-streams, probabilities are computed as to how likely a message could be guessed (or constructed) by a penetrator. This is in contrast to our possibilistic approach, in which we abstract from unlikely events, e.g. that independently guessing a key and a nonce will result in messages that share the same implementation. This is reflected in our notion of originating messages occurring on I-traces. The strand space approach excludes protocol runs in which messages are not uniquely originating resulting in a possibilistic approach in a somewhat idealized world. In our approach, for instance, a nonce can be only camouflaged by a message, which itself is camouflaged at some point with the help of the same nonce (c.f. definition 4).
We separate the protocol level operating on abstract messages from its implementation level. This is in contrast to many other approaches that encode implementation details in an equality theory on (abstract) messages. The benefit is that we can use (arbitrary) algebraic specifications to formalize properties (in particular equality and inequality) of the message implementation. This knowledge about the implementation is used to verify side conditions of I-traces. In order to apply I-traces in the penetrator bundle we have to make sure that both messages of the trace share the same implementation. This is a task that can be given to an automated theorem prover or to specialized deduction system incorporating domain specific knowledge (e.g. SMT-provers).

Conclusions
We presented a framework for patching security protocols. The framework is formalized based on the notion of strand spaces, which we have extended to deal also with type flaw attacks. Given a specification for the implementation of messages, an additional I-trace rule allows the penetrator to interchange messages that share the same implementation. While the original purpose of this extension was to provide a uniform representation language for protocol runs (potentially containing type flaw attacks), it is also interesting to investigate how the verification methodology of strand spaces can be lifted to our extended approach.
Based on this formalization, we classify the situations in which a penetrator can reuse messages communicated by honest principals to mount attacks. This gives rise to various patch rules, which cope with different types of flaws. It is interesting to see that there are typically two alternative ways to overcome type flaw attacks. On the one hand, we can change the implementation in order to avoid the particular equalities on implemented messages; and, on the other hand, we can change the protocol on the abstract level, in order avoid situations in which one can exploit these properties in the implementation. The framework has been implemented in the Shrimp system and successfully evaluated in a large set of faulty security protocols.