Equivalence Properties by Typing in Cryptographic Branching Protocols
Abstract
Recently, many tools have been proposed for automatically analysing, in symbolic models, equivalence of security protocols. Equivalence is a property needed to state privacy properties or gamebased properties like strong secrecy. Tools for a bounded number of sessions can decide equivalence but typically suffer from efficiency issues. Tools for an unbounded number of sessions like Tamarin or ProVerif prove a stronger notion of equivalence (diffequivalence) that does not properly handle protocols with else branches.
Building upon a recent approach, we propose a type system for reasoning about branching protocols and dynamic keys. We prove our type system to entail equivalence, for all the standard primitives. Our type system has been implemented and shows a significant speedup compared to the tools for a bounded number of sessions, and compares similarly to ProVerif for an unbounded number of sessions. Moreover, we can also prove security of protocols that require a mix of bounded and unbounded number of sessions, which ProVerif cannot properly handle.
1 Introduction
Formal methods provide a rigorous and convenient framework for analysing security protocols. In particular, mature pushbutton analysis tools have emerged and have been successfully applied to many protocols from the literature in the context of trace properties such as authentication or confidentiality. These tools employ a variety of analysis techniques, such as model checking (e.g., Avispa [6] and Scyther [31]), Horn clause resolution (e.g., ProVerif [13]), term rewriting (e.g., Scyther [31] and Tamarin [38]), and type systems [7, 12, 16, 17, 18, 19, 20, 21, 34, 36, 37].
In the recent years, attention has been given also to equivalence properties, which are crucial to model privacy properties such as vote privacy [8, 33], unlikability [5], or anonymity [9]. For example, consider an authentication protocol \(P_{pass}\) embedded in a biometric passport. \(P_{pass}\) preserves anonymity of passport holders if an attacker cannot distinguish an execution with Alice from an execution with Bob. This can be expressed by the equivalence \(P_{pass}( Alice )\;\approx _t\; P_{pass}( Bob )\). Equivalence is also used to express properties closer to cryptographic games like strong secrecy.
Two main classes of tools have been developed for equivalence. First, in the case of an unbounded number of sessions (when the protocol is executed arbitrarily many times), equivalence is undecidable. Instead, the tools ProVerif [13, 15] and Tamarin [11, 38] try to prove a stronger property, namely diffequivalence, that may be too strong e.g. in the context of voting. Tamarin covers a larger class of protocols but may require some guidance from the user. MaudeNPA [35, 40] also proves diffequivalence but may have nontermination issues. Another class of tools aim at deciding equivalence, for bounded number of sessions. This is the case in particular of SPEC [32], APTE [23], Akiss [22], and SatEquiv [26]. SPEC, APTE, and Akiss suffer from efficiency issues and can typically not handle more than 3–4 sessions. SatEquiv is much more efficient but is limited to symmetric encryption and requires protocols to be welltyped, which often assumes some additional tagging of the protocol.
Our Contribution. Following the approach of [28], we propose a novel technique for proving equivalence properties for a bounded number of sessions as well as an unbounded number of sessions (or a mix of both), based on typing. [28] proposes a first type system that entails trace equivalence \(P \;\approx _t\; Q\), provided protocols use fixed (longterm) keys, identical in P and Q. In this paper, we target a larger class of protocols, that includes in particular keyexchange protocols and protocols whose security relies on branching on the secret. This is the case e.g. of the private authentication protocol [3], where agent B returns a true answer to A, encrypted with A’s public key if A is one of his friends, and sends a decoy message (encrypted with a dummy key) otherwise.
We devise a new type system for reasoning about keys. In particular, we introduce bikeys to cover behaviours where keys in P differ from the keys in Q. We design new typing rules to reason about protocols that may branch differently (in P and Q), depending on the input. Following the approach of [28], our type system collects sent messages into constraints that are required to be consistent. Intuitively, the type system guarantees that any execution of P can be matched by an execution of Q, while consistency imposes that the resulting sequences of messages are indistinguishable for an attacker. We had to entirely revisit the approach of [28] and prove a finer invariant in order to cope with the case where keys are used as variables. Specifically, most of the rules for encryption, signature, and decryption had to be adapted to accommodate the flexible usage of keys. For messages, we had to modify the rules for keys and encryption, in order to encrypt messages with keys of different type (bikey type), instead of only fixed keys. We show that our type system entails equivalence for the standard notion of trace equivalence [24] and we devise a procedure for proving consistency. This yields an efficient approach for proving equivalence of protocols for a bounded and an unbounded number of sessions (or a combination of both).
We implemented a prototype of our typechecker that we evaluate on a set of examples, that includes private authentication, the BAC protocol (of the biometric passport), as well as Helios together with the setup phase. Our tool requires a light type annotation that specifies which keys and names are likely to be secret or public and the form of the messages encrypted by a given key. This can be easily inferred from the structure of the protocol. Our typechecker outperforms even the most efficient existing tools for a bounded number of sessions by two (for examples with few processes) to three (for examples with more processes) orders of magnitude. Note however that these tools decide equivalence while our type system is incomplete. In the case of an unbounded number of sessions, on our examples, the performance is comparable to ProVerif, one of the most popular tools. We consider in particular vote privacy in the Helios protocol, in the case of a dishonest ballot board, with no revote (as the protocol is insecure otherwise). ProVerif fails to handle this case as it cannot (faithfully) consider a mix of bounded and unbounded number of sessions. Compared to [28], our analysis includes the setup phase (where voters receive the election key), which could not be considered before.
The technical details and proofs omitted due to space constraints are available in the companion technical report [29].
2 HighLevel Description
2.1 Background
Trace equivalence of two processes is a property that guarantees that an attacker observing the execution of either of the two processes cannot decide which one it is. Previous work [28] has shown how trace equivalence can be proved statically using a type system combined with a constraint checking procedure. The type system consists of typing rules of the form \(\varGamma \vdash P \sim Q \rightarrow C\), meaning that in an environment \(\varGamma \) two processes P and Q are equivalent if the produced set of constraints C, encoding the attacker observables, is consistent.
The typing environment \(\varGamma \) is a mapping from nonces, keys, and variables to types. Nonces are assigned security labels with a confidentiality and an integrity component, e.g. \(\mathtt {HL}\) for high confidentiality and low integrity. Key types are of the form \(\mathrm {key}^{l}(T)\) where l is the security label of the key and T is the type of the payload. Key types are crucial to convey typing information from one process to another one. Normally, we cannot make any assumptions about values received from the network – they might possibly originate from the attacker. If we however successfully decrypt a message using a secret symmetric key, we know that the result is of the key’s payload type. This is enforced on the sender side, whenever outputting an encryption.
A core assumption of virtually any efficient static analysis for equivalence is uniform execution, meaning that the two processes of interest always take the same branch in a branching statement. For instance, this means that all decryptions must always succeed or fail equally in the two processes. For this reason, previous work introduced a restriction to allow only encryption and decryption with keys whose equality could be statically proved.
2.2 Limitation
If B declines to communicate with A, he sends a decoy message \(\mathtt {aenc}(N_b,\mathtt {pk}(k))\) where \(\mathtt {pk}(k)\) is a decoy key (no one knows the private key k).
2.3 Encrypting with Different Keys
The beginning of the responder protocol can be typed using standard techniques. Then however, we perform the test \(y_2 = \mathtt {pk}(k_a)\) on the left side and \(y_2 = \mathtt {pk}(k_c)\) on the right side. Since we cannot statically determine the result of the two equality checks – and thus guarantee uniform execution – we have to typecheck the four possible combinations of \(\mathtt {then}\) and \(\mathtt {else}\) branches. This means we have to typecheck outputs of encryptions that use different keys on the left and the right side.
To deal with this we do not assign types to single keys, but rather to pairs of keys \((k,k')\) – which we call bikeys – where k is the key used in the left process and \(k'\) is the key used in the right process. The key types used for typing are presented in Fig. 1.
As an example, we consider the combination of the \(\mathtt {then}\) branch on the left with the \(\mathtt {else}\) branch on the right. This combination occurs when A is successfully authenticated on the left side, while being rejected on the right side. We then have to typecheck B’s positive answer together with the decoy message: \(\varGamma \vdash \mathtt {aenc}(\langle y_1, \langle N_b, \mathtt {pk}(k_b) \rangle \rangle ,\mathtt {pk}(k_a)) \sim \mathtt {aenc}(N_b,\mathtt {pk}(k)) : \mathtt {LL}\). For this we need the type for the bikey \((k_a,k)\).
2.4 Decrypting Nonuniformly

The message is a valid encryption supplied by the attacker (using the public key \(\mathtt {pk}(k_a)\)), so we check the \(\mathtt {then}\) branch on both sides with \(\varGamma (z')=\mathtt {LL}\).

The message is not a valid encryption supplied by the attacker so we check the \(\mathtt {else}\) branch on both sides.

The message is a valid response from B. The keys used on the left and the right are then one of the four possible combinations \((k_a,k), (k_a,k_c), (k,k_c)\) and (k, k).

In the first two cases the decryption will succeed on the left and fail on the right. We hence check the \(\mathtt {then}\) branch on the left with \(\varGamma (z')=\mathtt {HL}\) with the \(\mathtt {else}\) branch on the right. If the type \(\varGamma (k_a,k)\) were different from \(\varGamma (k_a,k_c)\), we would check this combination twice, using the two different payload types.

In the remaining two cases the decryption will fail on both sides. We hence would have to check the two \(\mathtt {else}\) branches (which however we already did).

While checking the \(\mathtt {then}\) branch together with the \(\mathtt {else}\) branch, we have to check \(\varGamma \vdash 1 \sim 0 : \mathtt {LL}\), which rightly fails, as the protocol does not guarantee trace equivalence.
3 Model
In symbolic models, security protocols are typically modelled as processes of a process algebra, such as the applied picalculus [2]. We present here a calculus used in [28] and inspired from the calculus underlying the ProVerif tool [14]. This section is mostly an excerpt of [28], recalled here for the sake of completeness, and illustrated with the private authentication protocol.
3.1 Terms
We consider the set \(\mathcal {T}(\mathcal {F}_c\cup \mathcal {F}_d\cup \mathcal {C},\mathcal {V},\mathcal {N}\cup \mathcal {K})\) of cryptographic terms, simply called terms. Messages are terms with constructors from \(\mathcal {T}(\mathcal {F}_c\cup \mathcal {C},\mathcal {V},\mathcal {N}\cup \mathcal {K})\). We assume the set of variables to be split into two subsets \(\mathcal {V}= \mathcal {X}\uplus \mathcal {AX}\) where \(\mathcal {X}\) are variables used in processes while \(\mathcal {AX}\) are variables used to store messages. An attacker term is a term from \(\mathcal {T}(\mathcal {F}_c\cup \mathcal {F}_d\cup \mathcal {C},\mathcal {AX},\mathcal {FN}\cup \mathcal {FK})\). In particular, an attacker term cannot use nonces and keys created by the protocol’s parties.
A substitution \(\sigma = \{M_1 / x_1, \dots , M_k / x_k\}\) is a mapping from variables \(x_1, \dots , x_k \in \mathcal {V}\) to messages \(M_1, \dots , M_k\). We let \(\mathrm {dom}(\sigma ) = \{x_1, \dots , x_k\}\). We say that \(\sigma \) is ground if all messages \(M_1, \dots , M_k\) are ground. We let \(\mathrm {names}(\sigma ) = \bigcup _{1 \le i \le k} \mathrm {names}(M_i)\). The application of a substitution \(\sigma \) to a term t is denoted \(t\sigma \) and is defined as usual.
3.2 Processes
Security protocols describe how messages should be exchanged between participants. We model them through a process algebra, whose syntax is displayed in Fig. 2. We identify processes up to \(\alpha \)renaming, i.e., avoiding substitution of bound names and variables, which are defined as usual. Furthermore, we assume that all bound names, keys, and variables in the process are distinct.

\(\mathcal {P}\) is a multiset of processes that represents the current active processes;

\(\phi \) is a substitution with \(\mathrm {dom}(\phi )\subseteq \mathcal {AX}\) and for any \(x\in \mathrm {dom}(\phi )\), \(\phi (x)\) (also denoted \(x\phi \)) is a message that only contains variables in \(\mathrm {dom}(\sigma )\). \(\phi \) represents the terms that have been sent;

\(\sigma \) is a ground substitution.
The semantics of processes is given through a transition relation \(\xrightarrow {\;\alpha \;}\), defined in Fig. 3 (\(\tau \) denotes a silent action). The relation \(\xrightarrow {\;w\;}_*\) is defined as the reflexive transitive closure of \(\xrightarrow {\;\alpha \;}\), where w is the concatenation of all actions. We also write equality up to silent actions \(=_\tau \).
Intuitively, process \(\mathtt {new}\; n.P\) creates a fresh nonce or key, and behaves like P. Process \(\mathtt {out}(M).P \) emits M and behaves like P, provided that the evaluation of M is successful. The corresponding message is stored in the frame \(\phi \), corresponding to the attacker knowledge. A process may input any message that an attacker can forge (rule In) from her knowledge \(\phi \), using a recipe R to compute a new message from \(\phi \). Note that all names are initially assumed to be secret. Process \(P ~~Q\) corresponds to the parallel composition of P and Q. Process \( \mathtt {let}\; x = d \;\mathtt {in}\; P \;\mathtt {else}\; Q\) behaves like P in which x is replaced by d if d can be successfully evaluated and behaves like Q otherwise. Process \(\mathtt {if}\;M = N \;\mathtt {then}\; P \;\mathtt {else}\; Q\) behaves like P if M and N correspond to two equal messages and behaves like Q otherwise. The replicated process !P behaves as an unbounded number of copies of P.
Example 1
3.3 Equivalence
When processes evolve, sent messages are stored in a substitution \(\phi \) while the values of variables are stored in \(\sigma \). A frame is simply a substitution \(\psi \) where \(\mathrm {dom}(\psi ) \subseteq \mathcal {AX}\). It represents the knowledge of an attacker. In what follows, we will typically consider \(\phi \sigma \).
Intuitively, two sequences of messages are indistinguishable to an attacker if he cannot perform any test that could distinguish them. This is typically modelled as static equivalence [2]. Here, we consider of variant of [2] where the attacker is also given the ability to observe when the evaluation of a term fails, as defined for example in [25].
Definition 1
Then two processes P and Q are in equivalence if no matter how the adversary interacts with P, a similar interaction may happen with Q, with equivalent resulting frames.
Definition 2
(Trace Equivalence). Let P, Q be two processes. We write \(P \sqsubseteq _tQ\) if for all \((s,\phi , \sigma )\in \mathrm {trace}(P)\), there exists \((s',\phi ', \sigma ')\in \mathrm {trace}(Q)\) such that \(s =_\tau s'\) and \(\phi \sigma \) and \(\phi '\sigma '\) are statically equivalent. We say that P and Q are trace equivalent, and we write \(P \approx _tQ\), if \(P \sqsubseteq _tQ\) and \(Q \sqsubseteq _tP\).
Note that this definition already includes the attacker’s behaviour, since processes may input any message forged by the attacker.
Example 2
4 A Type System for Dynamic Keys
The types for messages are defined in Fig. 4 and explained below. Selected subtyping rules are given in Fig. 5. We assume three security labels \(\mathtt {HH},\mathtt {HL}\) and \(\mathtt {LL}\), ranged over by l, whose first (resp. second) component denotes the confidentiality (resp. integrity) level. Intuitively, values of high confidentiality may never be output to the network in plain, and values of high integrity are guaranteed not to originate from the attacker. Pair types \(T * T'\) describe the type of their components and the type \(T \,\vee \,T'\) is given to messages that can have type T or type \(T'\).
The type \(\tau ^{l,{a}}_{n} \) describes nonces and constants of security level l: the label \({a}\) ranges over \(\{\infty ,1\}\), denoting whether the nonce is bound within a replication or not (constants are always typed with \({a}=1\)). We assume a different identifier n for each constant and restriction in the process. The type \(\tau ^{l,1}_{n} \) is populated by a single name, (i.e., n describes a constant or a nonreplicated nonce) and \(\tau ^{l,\infty }_{n} \) is a special type, that is instantiated to \(\tau ^{l,1}_{n_j} \) in the jth replication of the process. Type \(\llbracket \tau ^{l,{a}}_{n} \,;\, \tau ^{l',{a}}_{m} \rrbracket \) is a refinement type that restricts the set of possible values of a message to values of type \(\tau ^{l,{a}}_{n} \) on the left and type \(\tau ^{l',{a}}_{m} \) on the right. For a refinement type \(\llbracket \tau ^{l,{a}}_{n} \,;\, \tau ^{l,{a}}_{n} \rrbracket \) with equal types on both sides we write \(\tau ^{l,{a}}_{n} \).
Keys can have three different types ranged over by KT, ordered by a subtyping relation (SEqKey, SSesKey): \(\mathrm {seskey}^{l,a}(T)<:\mathrm {eqkey}^{l}(T) <:\mathrm {key}^{l}(T)\). For all three types, l denotes the security label (SKey) of the key and T is the type of the payload that can be encrypted or signed with these keys. This allows us to transfer typing information from one process to another one: e.g. when encrypting, we check that the payload type is respected, so that we can be sure to get a value of the payload type upon decryption. The three different types encode different relations between the left and the right component of a bikey \((k,k')\). While type \(\mathrm {key}^{l}(T)\) can be given to bikeys with different components \(k \ne k'\), type \(\mathrm {eqkey}^{l}(T)\) ensures that the keys are equal on both sides in the specific typed instruction. Type \(\mathrm {seskey}^{l,a}(T)\) additionally guarantees that the key is always the same on the left and the right throughout the whole process. We allow for dynamic generation of keys of type \(\mathrm {seskey}^{l,a}(T)\) and use a label a to denote whether the key is generated under replication or not – just like for nonce types.
Constraints. When typing messages, we generate constraints of the form \((M \sim N)\), meaning that the attacker may see M and N in the left and right process, respectively, and these two messages are thus required to be indistinguishable.
Due to space reasons we only present a few selected rules that are characteristic of the typing of branching protocols. The omitted rules are similar in spirit to the presented ones or are standard rules for equivalence typing [28].
4.1 Typing Messages
The typing judgement for messages is of the form \( \varGamma \vdash M \sim N : T \rightarrow c \) which reads as follows: under the environment \(\varGamma \), M and N are of type T and either this is a high confidentiality type (i.e., M and N are not disclosed to the attacker) or M and N are indistinguishable for the attacker assuming the set of constraints c is consistent.
Confidential nonces can be given their label from the typing environment in rule TNonce. Since their label prevents them from being released in clear, the attacker cannot observe them and we do not need to add constraints for them. They can however be output in encrypted form and will then appear in the constraints of the encryption. Public nonces (labeled as \(\mathtt {LL}\)) can be typed if they are equal on both sides (rule TNonceL). These are standard rules, as well as the rules TVar, TSub, TPair and THigh [28].
A nonstandard rule that is crucial for the typing of branching protocols is rule TKey. As the typing environment contains types for bikeys \((k,k')\) this rule allows us to type two potentially different keys with their type from the environment. With the standard rule TPubKeyL we can only type a public key of the same keys on both sides, while rule TPubKey allows us to type different public keys \(\mathtt {pk}(M),\mathtt {pk}(N)\), provided we can show that there exists a valid key type for the terms M and N. This highlights another important technical contribution of this work, as compared to existing type systems for equivalence: we do not only support a fixed set of keys, but also allow for the usage of keys in variables, that have been received from the network.
To show that a message is of type \({\{T\}}_{T'}\) – a message of type T encrypted asymmetrically with a key of type \(T'\), we have to show that the corresponding terms have exactly these types in rule TAenc. The generated constraints are simply propagated. In addition we need to show that \(T'\) is a valid type for a public key, or \(\mathtt {LL}\), which models untrusted keys received from the network. Note, that this rule allows us to encrypt messages with different keys in the two processes. For encryptions with honest keys (label \(\mathtt {HH}\)) we can use rule TAenc to give type \(\mathtt {LL}\) to the messages, if we can show that the payload type is respected. In this case we add the entire encryptions to the constraints, since the attacker can check different encryptions for equality, even if he cannot obtain the plaintext. Rule TAencL allows us to give type \(\mathtt {LL}\) to encryptions even if we do not respect the payload type, or if the key is corrupted. However, we then have to type the plaintexts with type \(\mathtt {LL}\) since we cannot guarantee their confidentiality. Additionally, we have to ensure that the same key is used in both processes, because the attacker might possess the corresponding private keys and test which decryption succeeds. Since we already add constraints for giving type \(\mathtt {LL}\) to the plaintext, we do not need to add any additional constraints.
4.2 Typing Processes
Rule POut states that we can output messages to the network if we can type them with type \(\mathtt {LL}\), i.e., they are indistinguishable to the attacker, provided that the generated set c of constraints is consistent. The constraints of c are then added to all constraints in the constraint set C. We define \(C{\cup _{\forall }}c' := \left\{ (c \cup c',\varGamma ) \;\; (c,\varGamma ) \in C \right\} \). This rule, as well as the rules PZero, PIn, PNew, PPar, and PLet, are standard rules [28].
Rule PNewKey allows us to generate new session keys at runtime, which models security protocols more faithfully. It also allows us to generate infinitely many keys, by introducing new keys under replication.

Both \(\mathtt {then}\) branches: In this case we know that key k was used for encryption on both sides. Because of \(\varGamma (k,k)=\mathrm {key}^{\mathtt {HH}}(T)\), we know that in this case the payload type is T and we type the continuation with \(\varGamma ,x:T\).
Because the message may also originate from the attacker (who also has access to the public key), we have to type the two \(\mathtt {then}\) branches also with \(\varGamma ,x:\mathtt {LL}\).

Both \(\mathtt {else}\) branches: If decryption fails on both sides, we type the two \(\mathtt {else}\) branches without introducing any new variables.

Left \(\mathtt {then}\), right \(\mathtt {else}\): The encryption may have been created with key k on the left side and another key \(k'\) on the right side. Hence, for each \(k' \ne k\), such that \(\varGamma (k,k')\) maps to a key type with label \(\mathtt {HH}\) and payload type \(T'\), we have to typecheck the left \(\mathtt {then}\) branch and the right \(\mathtt {else}\) branch with \(\varGamma ,x:T'\).

Left \(\mathtt {else}\), right \(\mathtt {then}\): This case is analogous to the previous one.
The generated set of constraints is simply the union of all generated constraints for the subprocesses. Rule PIfAll lets us typecheck any conditional by simply checking the four possible branch combinations. In contrast to the other rules for conditionals that we present in a companion technical report, this rule does not require any other preconditions or checks on the terms \(M,M',N,N'\).
4.3 Typing the Private Authentication Protocol
We now show how our type system can be applied to type the Private Authentication protocol presented in Sect. 2.3, by showing the most interesting parts of the derivation. We type the protocol using the initial environment \(\varGamma \) presented in Fig. 1.
We focus on the responder process \(P_b\) and start with the asymmetric decryption. As we use the same key \(k_b\) in both processes, we apply rule PLetAdecSame. We have \(\varGamma (x)=\mathtt {LL}\) by rule PIn and \(\varGamma (k_b,k_b) = \mathrm {key}^{\mathtt {HH}}(\mathtt {HH},\mathtt {LL})\). We do not have any other entry using key \(k_b\) in \(\varGamma \). We hence typecheck the two \(\mathtt {then}\) branches once with \(\varGamma ,y:(\mathtt {HH}* \mathtt {LL})\) and once with \(\varGamma ,y:\mathtt {LL}\), as well as the two \(\mathtt {else}\) branches (which are just \(\mathtt {0}\) in this case).
Typing the let expressions is straightforward using rule PLet. In the conditional we check \(y_2 = \mathtt {pk}(k_a)\) in the left process and \(y_2 = \mathtt {pk}(k_c)\) in the right process. Since we cannot guarantee which branches are taken or even if the same branch is taken in the two processes, we use rule PIfAll to typecheck all four possible combinations of branches. We now focus on the case where A is successfully authenticated in the left process and is rejected in the right process. We then have to typecheck B’s positive answer together with the decoy message: \(\varGamma \vdash \mathtt {aenc}(\langle y_1, \langle N_b, \mathtt {pk}(k_b) \rangle \rangle ,\mathtt {pk}(k_a)) \sim \mathtt {aenc}(N_c,\mathtt {pk}(k)) : \mathtt {LL}\).
Figure 9 presents the type derivation for this example. We apply rule TAenc to give type \(\mathtt {LL}\) to the two terms, adding the two encryptions to the constraint set. Using rule TAencH we can show that the encryptions are welltyped with type \({\{\mathtt {HL}\}}_{\mathrm {pkey}(\mathrm {key}^{\mathtt {HH}}(\mathtt {HL}))}\). The type of the payload is trivially shown with rule THigh. To type the public key, we use rule TPubKey followed by rule TKey, which looks up the type for the bikey \((k_a,k)\) in the typing environment \(\varGamma \).
5 Consistency
Our type system collects constraints that intuitively correspond to (symbolic) messages that the attacker may see (or deduce). Therefore, two processes are in trace equivalence only if the collected constraints are in static equivalence for any plausible instantiation.
However, checking static equivalence of symbolic frames for any instantiation corresponding to a real execution may be as hard as checking trace equivalence [24]. Conversely, checking static equivalence for any instantiation may be too strong and may prevent proving equivalence of processes. Instead, we use again the typing information gathered by our type system and we consider only instantiations that comply with the type. Actually, we even restrict our attention to instantiations where variables of type \(\mathtt {LL}\) are only replaced by deducible terms. This last part is a key ingredient for considering processes with dynamic keys. Hence, we define a constraint to be consistent if the corresponding two frames are in static equivalence for any instantiation that can be typed and produces constraints that are included in the original constraint.

Open image in new window and Open image in new window denote the frames that are composed of the left and the right terms of the constraints respectively (in the same order).

\(\phi _\mathtt {LL}^{\varGamma }\) denotes the frame that is composed of all low confidentiality nonces and keys in \(\varGamma \), as well as all public encryption keys and verification keys in \(\varGamma \). This intuitively corresponds to the initial knowledge of the attacker.

Two ground substitutions \(\sigma , \sigma '\) are welltyped in \(\varGamma \) with constraint \(c_\sigma \) if they preserve the types for variables in \(\varGamma \), i.e., for all x, \(\varGamma \vdash \sigma (x) \sim \sigma '(x) : \varGamma (x) \rightarrow c_x\), and \(c_\sigma = \bigcup _{x\in \mathrm {dom}(\varGamma )}c_x\).
The instantiation of a constraint is defined as expected. If c is a set of constraints, and \(\sigma \), \(\sigma '\) are two substitutions, let Open image in new window be the instantiation of c by \(\sigma \) on the left and \(\sigma '\) on the right, that is, Open image in new window .
Definition 3
(Consistency). A set of constraints c is consistent in an environment \(\varGamma \) if for all substitutions \(\sigma \), \(\sigma '\) welltyped in \(\varGamma \) with a constraint \(c_\sigma \) such that Open image in new window , the frames \(\phi _\mathtt {LL}^{\varGamma } \cup \) Open image in new window \((c)\sigma \) and \(\phi _\mathtt {LL}^{\varGamma } \cup \) Open image in new window \((c)\sigma '\) are statically equivalent. We say that \((c,\varGamma )\) is consistent if c is consistent in \(\varGamma \) and that a constraint set C is consistent in \(\varGamma \) if each element \((c, \varGamma ) \in C\) is consistent.
Compared to [28], we now require Open image in new window . This means that instead of considering any (well typed) instantiations, we only consider instantiations that use fragments of the constraints. For example, this now imposes that low variables are instantiated by terms deducible from the constraint. This refinement of consistency provides a tighter definition and is needed for non fixed keys, as explained in the next section.
6 Soundness
In this section, we provide our main results. First, soundness of our type system: whenever two processes can be typed with consistent constraints, then they are in trace equivalence. Then we show how to automatically prove consistency. Finally, we explain how to lift these two first results from finite processes to processes with replication. But first, we discuss why we cannot directly apply the results from [28] developed for processes with long term keys.
6.1 Example
Therefore, our first idea consists in proving that we only collect constraints that are saturated w.r.t. deduction: any deducible subterm can already be constructed from the terms of the constraint. Second, we show that for any execution, low variables are instantiated by terms deducible from the constraints. This guarantees that our new notion of consistency is sound. The two results are reflected in the next section.
6.2 Soundness
Our type system, together with consistency, implies trace equivalence.
Theorem 1
(Typing implies trace equivalence). For all P, Q, and C, for all \(\varGamma \) containing only keys, if \(\varGamma \vdash P \sim Q \rightarrow C\) and C is consistent, then \(P \approx _tQ\).
Example 3
The first key ingredient in the proof of Theorem 1 is the fact that any welltyped low term is deducible from the constraint generated when typing it.
Lemma 1
(Low terms are recipes on their constraints). For all ground messages M, N, for all \(\varGamma \), c, if \(\varGamma \vdash M \sim N : \mathtt {LL} \rightarrow c\) then there exists an attacker recipe R without destructors such that \(M = R (\) Open image in new window \((c)\cup \phi _\mathtt {LL}^{\varGamma })\) and \(N = R (\) Open image in new window \((c)\cup \phi _\mathtt {LL}^{\varGamma })\).
The second key ingredient is a finer invariant on protocol executions: for any typable pair of processes P, Q, any execution of P can be mimicked by an execution of Q such that low variables are instantiated by welltyped terms constructible from the constraint.
Lemma 2
For all processes P, Q, for all \(\phi \), \(\sigma \), for all multisets of processes \(\mathcal {P}\), constraint sets C, sequences s of actions, for all \(\varGamma \) containing only keys, if \(\varGamma \vdash P \sim Q \rightarrow C\), C is consistent, and \((\{P\},\emptyset ,\emptyset ) \xrightarrow {\;s\;}_* (\mathcal {P},\phi ,\sigma )\), then there exist a sequence \(s'\) of actions, a multiset \(\mathcal {Q}\), a frame \(\phi '\), a substitution \(\sigma '\), an environment \(\varGamma '\), a constraint c such that:
– \((\{Q\},\emptyset ,\emptyset ) \xrightarrow {\;s'\;}_* (\mathcal {Q},\phi ',\sigma ')\), with \(s =_\tau s'\)
– \(\varGamma ' \vdash \phi \sigma \sim \phi '\sigma ' : \mathtt {LL} \rightarrow c\), and for all \(x\in \mathrm {dom}(\sigma )\cap \mathrm {dom}(\sigma ')\), there exists \(c_x\) such that \(\varGamma ' \vdash \sigma (x) \sim \sigma (x) : \varGamma '(x) \rightarrow c_x\) and \(c_x\subseteq c\).
Note that this finer invariant guarantees that we can restrict our attention to the instantiations considered for defining consistency.
As a byproduct, we obtain a finer type system for equivalence, even for processes with long term keys (as in [28]). For example, we can now prove equivalence of processes where some agent signs a low message that comes from the adversary. In such a case, we collect \(\mathtt {sign}(x,k)\sim \mathtt {sign}(x,k)\) in the constraint, where x has type \(\mathtt {LL}\), which we can now prove to be consistent (depending on how x is used in the rest of the constraint).
6.3 Procedure for Consistency

First, variables of refined type \(\llbracket \tau ^{l,1}_{m} \,;\, \tau ^{l',1}_{n} \rrbracket \) are replaced by m on the lefthandside of the constraint and n on the righthandside.

Second, we check that terms have the same shape (encryption, signature, hash) on the left and on the right and that asymmetric encryption and hashes cannot be reconstructed by the adversary (that is, they contain some fresh nonce).

The most important step consists in checking that the terms on the left satisfy the same equalities than the ones on the right. Whenever two left terms M and N are unifiable, their corresponding right terms \(M'\) and \(N'\) should be equal after applying a similar instantiation.
For constraint sets without infinite nonce types, \(\mathtt {check\_const}\) entails consistency.
Theorem 2
Example 4
6.4 From Finite to Replicated Processes
The previous results apply to processes without replication only. In the spirit of [28], we lift our results to replicated processes. We proceed in two steps.
 1.
Whenever \(\varGamma \vdash P \sim Q \rightarrow C\), we show that: \({\left[ \,{\varGamma }\,\right] _{1}}\cup \cdots \cup {\left[ \,{\varGamma }\,\right] _{n}}\! \vdash \!{\left[ \,{P}\,\right] _{1}} \dots {\left[ \,{P}\,\right] _{n}} \sim {\left[ \,{Q}\,\right] _{1}} \dots  {\left[ \,{Q}\,\right] _{n}} \rightarrow {\left[ \,{C}\,\right] _{1}}{\cup _{\times }}\cdots {\cup _{\times }}{\left[ \,{C}\,\right] _{n}}\), where \({\left[ \,{\varGamma }\,\right] _{i}}\) is intuitively a copy of \(\varGamma \), where variables x have been replaced by \(x_i\), and nonces or keys n of infinite type \(\tau ^{l,\infty }_{n} \) (or \(\mathrm {seskey}^{l,\infty }(T)\)) have been replaced by \(n_i\). The copies \({\left[ \,{P}\,\right] _{i}}\), \({\left[ \,{Q}\,\right] _{i}}\), and \({\left[ \,{C}\,\right] _{i}}\) are defined similarly.
 2.
We cannot directly check consistency of infinitely many constraints of the form \({\left[ \,{C}\,\right] _{1}}{\cup _{\times }}\cdots {\cup _{\times }}{\left[ \,{C}\,\right] _{n}}\). Instead, we show that it is sufficient to check consistency of two copies \({\left[ \,{C}\,\right] _{1}}{\cup _{\times }}{\left[ \,{C}\,\right] _{2}}\) only. The reason why we need two copies (and not just one) is to detect when messages from different sessions may become equal.
Formally, we can prove trace equivalence of replicated processes.
Theorem 3
Consider P, Q, \(P'\), \(Q'\), C, \(C'\), such that P, Q and \(P'\), \(Q'\) do not share any variable. Consider \(\varGamma \), containing only keys and nonces with finite types.
Assume that P and Q only bind nonces and keys with infinite nonce types, i.e. using \(\mathtt {new}\; m : \tau ^{l,\infty }_{m} \) and \(\mathtt {new}\; k : \mathrm {seskey}^{l,\infty }(T)\) for some label l and type T; while \(P'\) and \(Q'\) only bind nonces and keys with finite types, i.e. using \(\mathtt {new}\; m : \tau ^{l,1}_{m} \) and \(\mathtt {new}\; k : \mathrm {seskey}^{l,1}(T)\).

\(\varGamma \vdash P \sim Q \rightarrow C\),

\(\varGamma \vdash P' \sim Q' \rightarrow C'\),

\(\mathtt {check\_const}({\left[ \,{C}\,\right] _{1}}{\cup _{\times }}{\left[ \,{C}\,\right] _{2}}{\cup _{\times }}{\left[ \,{C'}\,\right] _{1}}) = \mathtt {true}\),
Interestingly, Theorem 3 allows to consider a mix of finite and replicated processes.
7 Experimental Results
We implemented our typechecker as well as our procedure for consistency in a prototype tool TypeEq. We adapted the original prototype of [28] to implement additional cases corresponding to the new typing rules. This also required to design new heuristics w.r.t. the order in which typing rules should be applied. Of course, we also had to support for the new bikey types, and for arbitrary terms as keys. This represented a change of about 40% of the code of the software. We ran our experiments on a single Intel Xeon E52687Wv3 3.10 GHz core, with 378 GB of RAM (shared with the 19 other cores). Actually, our own prototype does not require a large amount of RAM. However, some of the other tools we consider use more than 64 GB of RAM on some examples (at which point we stopped the experiment). More precise figures about our tool are provided in the table of Fig. 11. The corresponding files can be found at [27].
We tested TypeEq on two symmetric key protocols that include a handshake on the key (YahalomLowe and NeedhamSchroeder symmetric key protocols). In both cases, we prove key usability of the exchanged key. Intuitively, we show that an attacker cannot distinguish between two encryptions of public constants: \(P.\mathtt {out}(\mathtt {enc}(a,k))\;\approx _t\; P.\mathtt {out}(\mathtt {enc}(b,k))\). We also consider one standard asymmetric key protocol (NeedhamSchroederLowe protocol), showing strong secrecy of the exchanged nonce.
7.1 Bounded Number of Sessions
We first compare TypeEq with the tools for a bounded number of sessions. Namely, we consider Akiss [22], APTE [23] as well as its optimised variant with partial order reduction APTEPOR [10], SPEC [32], and SatEquiv [26]. We step by step increase the number of sessions until we reach a “complete” scenario where each role is instantiated by A talking to B, A talking to C, B talking to A, and B talking to C, where A, B are honest while C is dishonest. This yields 14 sessions for symmetrickey protocols with two agents and one server, and 8 sessions for a protocol with two agents. In some cases, we further increase the number of sessions (replicating identical scenarios) to better compare tools performance. The results of our experiments are reported in Fig. 11. Note that SatEquiv fails to cover several cases because it does not handle asymmetric encryption nor else branches.
7.2 Unbounded Number of Sessions
8 Conclusion and Discussion
We devise a new type system to reason about keys in the context of equivalence properties. Our new type system significantly enhances the preliminary work of [28], covering a larger class of protocols that includes keyexchange protocols, protocols with setup phases, as well as protocols that branch differently depending on the decryption key.
Our type system requires a light type annotation that can be directly inferred from the structure of the messages. As future work, we plan to develop an automatic type inference system. In our case study, the only intricate case is the Helios protocol where the user has to write a refined type that corresponds to an overapproximation of any encrypted message. We plan to explore whether such types could be inferred automatically.
We also plan to study how to add phases to our framework, in order to cover more properties (such as unlinkability). This would require to generalize our type system to account for the fact that the type of a key may depend on the phase in which it is used.
Another limitation of our type system is that it does not address processes with too dissimilar structure. While our type system goes beyond diffequivalence, e.g. allowing else branches to be matched with then branches, we cannot prove equivalence of processes where traces of P are dynamically mapped to traces of Q, depending on the attacker’s behaviour. Such cases occur for example when proving unlinkability of the biometric passport. We plan to explore how to enrich our type system with additional rules that could cover such cases, taking advantage of the modularity of the type system.
Conversely, the fact that our type system discards processes that are in equivalence shows that our type system proves something stronger than trace equivalence. Indeed, processes P and Q have to follow some form of uniformity. We could exploit this to prove stronger properties like oblivious execution, probably further restricting our typing rules, in order to prove e.g. the absence of sidechannels of a certain form.
Notes
Acknowledgments
This work has been partially supported by the European Research Council (ERC) under the European Union’s Horizon 2020 research (grant agreements No. 645865SPOOC and No. 771527BROWSEC).
References
 1.Machine readable travel document. Technical report 9303. International Civil Aviation Organization (2008)Google Scholar
 2.Abadi, M., Fournet, C.: Mobile values, new names, and secure communication. In: 28th ACM SIGPLANSIGACT Symposium on Principles of Programming Languages (POPL 2001), pp. 104–115. ACM (2001)Google Scholar
 3.Abadi, M., Fournet, C.: Private authentication. Theoret. Comput. Sci. 322(3), 427–476 (2004)MathSciNetCrossRefGoogle Scholar
 4.Adida, B.: Helios: webbased openaudit voting. In: 17th Conference on Security Symposium, SS 2008, pp. 335–348 (2008)Google Scholar
 5.Arapinis, M., Chothia, T., Ritter, E., Ryan, M.: Analysing unlinkability and anonymity using the applied pi calculus. In: 2nd IEEE Computer Security Foundations Symposium (CSF 2010). IEEE Computer Society Press (2010)Google Scholar
 6.Armando, A., et al.: The AVISPA Tool for the automated validation of internet security protocols and applications. In: Etessami, K., Rajamani, S.K. (eds.) CAV 2005. LNCS, vol. 3576, pp. 281–285. Springer, Heidelberg (2005). https://doi.org/10.1007/11513988_27CrossRefGoogle Scholar
 7.Backes, M., Catalin, H., Maffei, M.: Union, intersection and refinement types and reasoning about type disjointness for secure protocol implementations. J. Comput. Secur. 22(2), 301–353 (2014)CrossRefGoogle Scholar
 8.Backes, M., Hritcu, C., Maffei, M.: Automated verification of remote electronic voting protocols in the applied picalculus. In: 21st IEEE Computer Security Foundations Symposium, CSF 2008, pp. 195–209. IEEE Computer Society (2008)Google Scholar
 9.Backes, M., Maffei, M., Unruh, D.: Zeroknowledge in the applied picalculus and automated verification of the direct anonymous attestation protocol. In: IEEE Symposium on Security and Privacy, SP 2008, pp. 202–215. IEEE Computer Society (2008)Google Scholar
 10.Baelde, D., Delaune, S., Hirschi, L.: Partial order reduction for security protocols. In: Proceedings of the 26th International Conference on Concurrency Theory (CONCUR 2015). LIPIcs, vol. 42, pp. 497–510. LeibnizZentrum für Informatik (2015)Google Scholar
 11.Basin, D., Dreier, J., Sasse, R.: Automated symbolic proofs of observational equivalence. In: 22nd ACM SIGSAC Conference on Computer and Communications Security (ACM CCS 2015), pp. 1144–1155. ACM, October 2015Google Scholar
 12.Bengtson, J., Bhargavan, K., Fournet, C., Gordon, A.D., Maffeis, S.: Refinement types for secure implementations. ACM Trans. Program. Lang. Syst. 33(2), 8:1–8:45 (2011)CrossRefGoogle Scholar
 13.Blanchet, B.: An efficient cryptographic protocol verifier based on prolog rules. In: 14th IEEE Computer Security Foundations Workshop (CSFW 2014), pp. 82–96. IEEE Computer Society, June 2001Google Scholar
 14.Blanchet, B.: Modeling and verifying security protocols with the applied pi calculus and ProVerif. Found. Trends Priv. Secur. 1(1–2), 1–135 (2016)Google Scholar
 15.Blanchet, B., Abadi, M., Fournet, C.: Automated verification of selected equivalences for security protocols. J. Logic Algebraic Program. 75(1), 3–51 (2008)MathSciNetCrossRefGoogle Scholar
 16.Bugliesi, M., Calzavara, S., Eigner, F., Maffei, M.: Resourceaware authorization policies for statically typed cryptographic protocols. In: 24th IEEE Computer Security Foundations Symposium, CSF 2011, pp. 83–98. IEEE Computer Society (2011)Google Scholar
 17.Bugliesi, M., Calzavara, S., Eigner, F., Maffei, M.: Logical foundations of secure resource management in protocol implementations. In: Basin, D., Mitchell, J.C. (eds.) POST 2013. LNCS, vol. 7796, pp. 105–125. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642368301_6CrossRefMATHGoogle Scholar
 18.Bugliesi, M., Calzavara, S., Eigner, F., Maffei, M.: Affine refinement types for secure distributed programming. ACM Trans. Program. Lang. Syst. 37(4), 11:1–11:66 (2015)CrossRefGoogle Scholar
 19.Bugliesi, M., Focardi, R., Maffei, M.: Authenticity by tagging and typing. In: 2004 ACM Workshop on Formal Methods in Security Engineering, FMSE 2004, pp. 1–12. ACM (2004)Google Scholar
 20.Bugliesi, M., Focardi, R., Maffei, M.: Analysis of typed analyses of authentication protocols. In: 18th IEEE Workshop on Computer Security Foundations, CSFW 2005, pp. 112–125. IEEE Computer Society (2005)Google Scholar
 21.Bugliesi, M., Focardi, R., Maffei, M.: Dynamic types for authentication. J. Comput. Secur. 15(6), 563–617 (2007)CrossRefGoogle Scholar
 22.Chadha, R., Ciobâcă, Ş., Kremer, S.: Automated verification of equivalence properties of cryptographic protocols. In: Seidl, H. (ed.) ESOP 2012. LNCS, vol. 7211, pp. 108–127. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642288692_6CrossRefGoogle Scholar
 23.Cheval, V.: APTE: an algorithm for proving trace equivalence. In: Ábrahám, E., Havelund, K. (eds.) TACAS 2014. LNCS, vol. 8413, pp. 587–592. Springer, Heidelberg (2014). https://doi.org/10.1007/9783642548628_50CrossRefGoogle Scholar
 24.Cheval, V., Cortier, V., Delaune, S.: Deciding equivalencebased properties using constraint solving. Theoret. Comput. Sci. 492, 1–39 (2013)MathSciNetCrossRefGoogle Scholar
 25.Cheval, V., Cortier, V., Plet, A.: Lengths may break privacy – or how to check for equivalences with length. In: Sharygina, N., Veith, H. (eds.) CAV 2013. LNCS, vol. 8044, pp. 708–723. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642397998_50CrossRefGoogle Scholar
 26.Cortier, V., Delaune, S., Dallon, A.: SATEquiv: an efficient tool for equivalence properties. In: Proceedings of the 30th IEEE Computer Security Foundations Symposium (CSF 2017). IEEE Computer Society Press, August 2017Google Scholar
 27.Cortier, V., Grimm, N., Lallemand, J., Maffei, M.: TypeEq. https://members.loria.fr/JLallemand/files/typing
 28.Cortier, V., Grimm, N., Lallemand, J., Maffei, M.: A type system for privacy properties. In: 24th ACM Conference on Computer and Communications Security (CCS 2017), pp. 409–423. ACM (2017)Google Scholar
 29.Cortier, V., Grimm, N., Lallemand, J., Maffei, M.: Equivalence properties by typing in cryptographic branching protocols. Research report, Université de Lorraine, CNRS, Inria, LORIA; TU Wien, February 2018. https://hal.archivesouvertes.fr/hal01715957
 30.Cortier, V., Smyth, B.: Attacking and fixing Helios: an analysis of ballot secrecy. J. Comput. Secur. 21(1), 89–148 (2013)CrossRefGoogle Scholar
 31.Cremers, C.J.F.: The Scyther tool: verification, falsification, and analysis of security protocols. In: Gupta, A., Malik, S. (eds.) CAV 2008. LNCS, vol. 5123, pp. 414–418. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540705451_38CrossRefGoogle Scholar
 32.Dawson, J., Tiu, A.: Automating open bisimulation checking for the spicalculus. In: IEEE Computer Security Foundations Symposium (CSF 2010) (2010)Google Scholar
 33.Delaune, S., Kremer, S., Ryan, M.D.: Verifying privacytype properties of electronic voting protocols. J. Comput. Secur. 17(4), 435–487 (2009)CrossRefGoogle Scholar
 34.Eigner, F., Maffei, M.: Differential privacy by typing in security protocols. In: 26th IEEE Computer Security Foundations Symposium, CSF 2013, pp. 272–286. IEEE Computer Society (2013)Google Scholar
 35.Escobar, S., Meadows, C., Meseguer, J.: A rewritingbased inference system for the NRL protocol analyzer and its metalogical properties. Theoret. Comput. Sci. 367(1–2), 162–202 (2006)MathSciNetCrossRefGoogle Scholar
 36.Focardi, R., Maffei, M.: Types for security protocols. In: Formal Models and Techniques for Analyzing Security Protocols, Cryptology and Information Security Series, chap. 7, vol. 5, pp. 143–181. IOS Press (2011)Google Scholar
 37.Gordon, A.D., Jeffrey, A.: Authenticity by typing for security protocols. J. Comput. Secur. 11(4), 451–519 (2003)CrossRefGoogle Scholar
 38.Meier, S., Schmidt, B., Cremers, C., Basin, D.: The TAMARIN prover for the symbolic analysis of security protocols. In: Sharygina, N., Veith, H. (eds.) CAV 2013. LNCS, vol. 8044, pp. 696–701. Springer, Heidelberg (2013). https://doi.org/10.1007/9783642397998_48CrossRefGoogle Scholar
 39.Roenne, P.: Private communication (2016)Google Scholar
 40.Santiago, S., Escobar, S., Meadows, C., Meseguer, J.: A formal definition of protocol indistinguishability and its verification using MaudeNPA. In: Mauw, S., Jensen, C.D. (eds.) STM 2014. LNCS, vol. 8743, pp. 162–177. Springer, Cham (2014). https://doi.org/10.1007/9783319118512_11CrossRefMATHGoogle Scholar
Copyright information
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.