Cross-Tool Semantics for Protocol Security Goals

Abstract

Formal protocol analysis tools provide objective evidence that a protocol under standardization meets security goals, as well as counterexamples to goals it does not meet (“attacks”). Different tools are however based on different execution semantics and adversary models. If different tools are applied to alternative protocols under standardization, can formal evidence offer a yardstick to compare the results?

We propose a family of languages within first order predicate logic to formalize protocol safety goals (rather than indistinguishability). Although they were originally designed for the strand space formalism that supports the tool cpsa, we show how to translate them to goals for the applied $\pi$ calculus that supports the tool ProVerif. We give a criterion for protocols expressed in the two formalisms to correspond, and prove that if a protocol in the strand space formalism satisfies a goal, then a corresponding applied $\pi$ process satisfies the translation of that goal. We show that the converse also holds for a class of goal formulas, and conjecture a broader equivalence. We also describe a compiler that, from any protocol in the strand space formalism, constructs a corresponding applied $\pi$ process and the relevant goal translation.

A Compilation

In this section we describe our translation of a strand space role into a labeled applied $\pi$-calculus process term.

At a high level, the translation takes a transmission event $+m$ to $\mathsf {out}({ tid },m)$, and it takes a reception event $-m$ to $\mathsf {in}({ tid },z).P$ where P is a sequence of $\mathsf {let}$ bindings that attempt to parse the received term according to the structure of the expected term. The complexity of the latter translation is due to the use of pattern matching for receptions in strand spaces that is absent in processes. If we are to preserve the semantics of the goal language under this translation to the process calculus, we must ensure that receptions based on pattern matching succeed on a given message m if and only if the corresponding sequence of $\mathsf {let}$ bindings succeeds on the same message. This requires some care.

One issue is that there may be several sequences that can be used to verify the structure of a message. Since the parsing process binds some values and requires others already to be bound, some sequences are sensible with respect to some initial input and others are not.

We start with a strand space trace (a sequence of events) constructed from message terms derived from the order-sort signature in Fig. 9. We compute the relation between a strand space trace and a process calculus term two steps.

• 1. Perform a flow analysis to find a set of input basic values (See Fig. 10).

• 2. Translate the trace into a process calculus expression relative to a given set of inputs (See Fig. 13).

The algorithm has been simplified by ignoring role unique origination assumptions, but their processing is sketched near the end of this section. Most of the algorithm described here has been implemented in Prolog. The Prolog implementation operates on a many-sorted algebra isomorphic to the order-sorted algebra as described in [19, Sect. 4]. We leave that translation implicit in this document.

Fig. 9.

Simple crypto algebra signature

The signature in Fig. 9 is a simplification of the one used by cpsa. The Simple Example Protocol initiator role using this signature is:

$$\begin{aligned} { init }(a, b:N, s:S, d:D) = [{\mathord +}\{\!|\{\!|s|\!\}_{{ pk }(a)^{-1}}|\!\}_{{ pk }(b)}, {\mathord -}\{\!|d|\!\}_{s}]. \end{aligned}$$

(3)

1.1 A.1 Flow Analysis

The aim of the flow analysis $C\rhd I$ (see Fig. 11) is to find a set of basic values that allow a procedural interpretation of a trace, in particular, a procedural interpretation of the implied pattern matching that is part of a strand space reception event.

There are two ways to interpret the reception of a pair, either the left part is matched first or the right part. A decryption key might or might not become available based on this choice.

There are two ways to interpret the reception of an encryption. If its decryption key in known at the point of the match, the contents of the encryption can be extracted. Alternatively, if the encryption has been seen previously or can be constructed, then an equality check implements the match.

Fig. 10.

Flow analysis

Fig. 11.

Send flow analysis

Fig. 12.

Receive flow analysis

Figure 12 explores the various possibilities. The flow analysis for the initiator trace is:

$$\begin{aligned} I=\{\{{ pk }(b),{ pk }(a)^{-1},s\}, \{d,{ pk }(b),{ pk }(a)^{-1},s\}\}, \end{aligned}$$

(4)

where $b,a:\mathsf {N}$, $s:\mathsf {S}$, and $d:\mathsf {D}$. Notice the second solution makes little sense. It assumes that the initiator’s initial knowledge includes d, the data it is seeking from a responder. We rely on human intervention to choose sensible sets of input terms.

1.2 A.2 Code Generation

Code generation has the form $C,E_1,N,\ell \gg P,E_2$, where C is a strand space trace, $E_1$ and $E_2$ are maps from strand space terms to process calculus terms, and we are translating the $\ell ^{{ th }}$ send or receive in the trace of the $N^{{ th }}$ role of the protocol.

Fig. 13.

Code generation

Fig. 14.

Send code generation

An analysis begins with an environment $E_0$ mapping each input term computed by the flow analysis to itself. To compute the process calculus term P for a given strand space trace C and role number N, find P such that $C,E_0,N,1\gg P,E_2$ (See Figs. 13, 14, 15 and 16).

To handle role unique origination assumptions, the send code generator in Fig. 14 must prefix the code with a ${\mathsf {new}}$ form for each name that uniquely originates in the transmitted message.

1.3 A.3 Translation Relation

The relation ${ comp }(N, C, P)$ relates a role number and the role’s strand space trace with a process calculus term if

Fig. 15.

Receive code generation

Fig. 16.

Term synthesis

• 1. $C\rhd I$,

• 2. $E_0$ is an environment generated from I, and

• 3. $C,E_0,N,1\gg P, E_2$.

Note that a translation is interesting only if I induces a sensible interpretation of C.

Blanchet Lnitiator Example. Assume the initiator is the second role in the protocol. The initiator trace C is defined in Eq. 3. The initial environment generated from the first input set in Eq. 4 is:

$$E_0=\{({ pk }(b),{ pk }(b)), ({ pk }(a)^{-1},{ pk }(a)^{-1}), (s,s)\},$$

where $b,a:\mathsf {N}$ and $s:\mathsf {S}$.

The process term P that satisfies $C,E_0,2,1\gg P, E_2$, is:

$$ \begin{array}{l} {\mathsf {out}}^{(2,1)}(c,\{\!|\{\!|s|\!\}_{{ pk }(a)^{-1}}|\!\}_{{ pk }(b)}).\\ {\mathsf {in}}(c, x_1).\\ {\mathsf {let}}x_2:\top ={ dec }(x_1,s){\mathsf {in}}\\ {\mathsf {let}}d:\mathsf {D} =x_2{\mathsf {in}}\;(2,2).\;0 \end{array} $$

Blanchet Responder Example. Assume the responder is the first role in the protocol. The responder trace is the one in Eq. 3 after interchanging sends and receives. A sensible set of input basic values is $\{d, { pk }(a), { pk }(b)^{-1}\}$. After inserting the ${\mathsf {new}}$ form by hand, the process term is:

$$ \begin{array}{l} {\mathsf {in}}(c, x_1).\\ {\mathsf {let}}x_2:\top ={ dec }(x_1,{ pk }(b)^{-1}){\mathsf {in}}\\ {\mathsf {let}}x_3:\top ={ dec }(x_2,{ pk }(a)){\mathsf {in}}\\ {\mathsf {let}}s:\mathsf {S} =x_3{\mathsf {in}}\;(1,1).\\ {\mathsf {new}}d:\mathsf {D}.\\ {\mathsf {out}}^{(1,2)}(c,\{\!|d|\!\}_{s}).\;0 \end{array} $$