HAL Id: hal-01596010
https://hal.archives-ouvertes.fr/hal-01596010v2
Submitted on 11 Nov 2017
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Formal Analysis of Combinations of Secure Protocols
Elliott Blot, Jannik Dreier, Pascal Lafourcade
To cite this version:
Elliott Blot, Jannik Dreier, Pascal Lafourcade. Formal Analysis of Combinations of Secure Protocols.
FPS 2017 - 10th International Symposium on Foundations & Practice of Security, Oct 2017, Nancy,
France. pp.53-67, �10.1007/978-3-319-75650-9_4�. �hal-01596010v2�
Formal Analysis of Combinations of Secure
Protocols
?
Elliott Blot
1
, Jannik Dreier
2
, and Pascal Lafourcade
1
1
LIMOS, University Clermont Auvergne, France
elliott.blot@gmail.com
2
LORIA, Universit´e de Lorraine, INRIA, CNRS, France
jannik.dreier@loria.fr
3
LIMOS, University Clermont Auvergne, France
pascal.lafourcade@uca.fr
Abstract. When trying to prove the security of a protocol, one usually
analyzes the protocol in isolation, i.e., in a network with no other proto-
cols. But in reality, there will be many protocols operating on the same
network, maybe even sharing data including keys, and an intruder may
use messages of one protocol to break another. We call that a multi-
protocol attack. In this paper, we try to find such attacks using the
Tamarin prover. We analyze both examples that were previously ana-
lyzed by hand or using other tools, and find novel attacks.
1 Introduction
When analyzing the security of protocols, one aims at proving specific security
properties. The most common types of properties are secrecy, meaning that an
intruder cannot know a secret value, and authentication, meaning that if A thinks
he is talking to B, then he is really talking to B. In our digitalized world there
are more and more cryptographic protocols everywhere, and we want to verify
them to ensure their security.
It is not realistic to assume that a protocol is running alone in the network,
and in the real world, an intruder can try to use messages of other protocols in
the network to break a protocol. That is what we call a multi-protocol attack.
More precisely, we study the following problem of multi-protocols attacks.
Given two protocols that ensure a certain security property in isolation, are
they still safe for this property if we put them together in the same network?
Unsurprisingly there exist many combinations of protocols where this is not the
case, i.e., where we can mount multi-protocols attacks.
There are a lot of tools for automatic analysis of security properties, like
ProVerif [3], AVISPA [2], Athena [27], Scyther [12], or Tamarin [23]. But they
?
This research was conducted with the support of the Indo-French Centre for the
Promotion of Advanced Research (IFCPAR) and the Center Franco-Indien Pour La
Promotion De La Recherche Avanc´ee (CEFIPRA) through the project DST/CNRS
2015-03 under DST-INRIA-CNRS Targeted Programme, and by the CNRS PEPS
SISC ASSI 2016/2017.
2
are generally used to analyze the security of a protocol executed in isolation,
meaning that each agent only executes the analyzed protocol. In this paper, our
aim is also to automatically find multi-protocols attacks using Tamarin.
Contributions: Several multi-protocols attacks have been found manually
or using other tools, our aim is to find them automatically using the Tamarin
prover [23]. Our contributions are the following:
– We automatically find all the manual attacks described in [22]. Moreover, we
find novel different attacks on the same properties, or unknown attacks on
different properties. This demonstrates the limitations of a manual approach
for finding attacks. It underlines that automatic verification is a very efficient
approach for analyzing the security of cryptographic protocols.
– We analyzed all the protocols given in [9], where the authors used Scyther,
a different protocol verification tool. We confirm the results from Scyther
using Tamarin.
– We developed an algorithm to simplify the process of creating the multi-
protocol specification file in Tamarin from the individual protocol specifica-
tions. The algorithm also automatically generates necessary helping lemmas
in Tamarin in order to verify the combination of the two protocols more ef-
ficiently. The algorithm is implemented in Python, and available online [15].
Related work: The existence of multi-protocol attack have been introduced
by Kelsey, Schneier, and Wagner in [18]. In this paper the attacks were found
manually and the authors consider protocols crafted to break other protocols.
In [22], Mathuria, Raj Singh, Venkata Sharavan, and Kirtankar found six
multi-protocol attacks based on 13 protocols from literature: Denning-Sacco pro-
tocol [13], amended Woo-Lam protocol [5], ISO Five-Pass protocol [7], Abadi-
Needham protocol [1], six protocols from Perrig and Song using APG [26], and
three protocols from Zhou and Foley using ASPB [30]. In contrast to these works,
we use an automatic verification tool to find these attacks.
Cremers found many multi-protocol attacks in [9], using the tool Scyther,
with 30 protocols from literature including Needham Schroeder protocol [24],
Needham Schroeder symmetric key protocol [24], Needham Schroeder symmetric
key amended protocol [25], Lowe’s modified version of the Needham Schroeder
protocol [19], SPLICE/AS [29], Hwang and Chen’s version of SPLICE/AS [16],
Clark and Jacob’s version of SPLICE/AS [8], a basic SOPH example (Secret-Out
Public-Home), Woo Lam pi f [28], Kao Chow v.1, v.2 and v.3 [17], Yahalom’s
protocol [4], and Lowe’s version of Yahalom protocol [21]. Compared to this work
we use the Tamarin instead of Scyther.
There is also a considerable amount of work of preventing multi-protocol
attacks by construction using special composition frameworks. These frameworks
exist in the computational (e.g., Universal Composability [6]) and in the symbolic
setting (e.g., Protocol Composition Logic [14]).
Outline: The paper is structured as follows. In Section 2, we present the
results we obtain and we compare them with those obtained manually in [22] or
using Scyther [9]. Then, Section 3 discusses our workflow in Tamarin, and finally
the last section concludes the paper.
3
2 Multi-Protocol Attacks
First we define the properties that we want to verify for each protocol. We define
one property for secrecy and two authentication properties.
– Secrecy [10]: if A claims the secrecy of a variable N
A
at the end of the run
of the protocol, then an intruder cannot know this variable.
– Non-injective agreement [11]: if a protagonist A completes a run apparently
with B, then B has run the protocol with A and A agrees with all other
protagonist on all values. This is not exactly the same definition as in [20],
but we keep this definition because it is this one that is used by Scyther.
– Non-injective synchronisation [11]: if a protagonist A completes a run as the
initiator apparently with B as the responder, then B has run the protocol
as the responder with A, and all messages sent and received are exactly like
described in the specification of the protocol, in the same order.
We call a type-flaw attack an attack where the intruder uses data of a different
type than the data expected by the protocol. For example, in such an attack,
the intruder could use two nonces N
1
, N
2
instead of another single nonce N
(N = (N
1
, N
2
)), or uses an ID as a nonce. We consider separately the case
where the intruder can make type-flaw attacks (such attacks are valid) and the
case where the intruder cannot (such attacks are not valid).
All our Tamarin files are available online [15].
2.1 Attacks by Cremers [9]
First we study the protocols analyzed in [9] using Scyther. We modeled all these
protocols individually in Tamarin. Figure 1 presents our results using Tamarin
for the properties described previously, and Figure 2 presents our results for
multi-protocols using Tamarin, where we verify the properties for the first of the
two protocols. In these figures, ni-synch stands for non-injective synchronisation,
sec stands for secrecy and ni-agree stands for non-injective agreement. Moreover,
3 means that we did not find any attacks, and 7 means there is at least one
attack for the property. A yellow box means that the first protocol (the one
for which we verify the security properties in the combination) is safe for this
property in isolation, and red box means that both protocols are safe for this
property in isolation. Empty box means that the property is not relevant for this
protocol, for example the key K
AB
does not exist in the protocol in the property
secrecy A K
AB
and secrecy B K
AB
, or a protagonist A never obtains a nonce
N
B
in the property secrecy A N
B
.
We find the same results with Tamarin as with Scyther. We do not consider
type-flaw attack for these protocols, because the number of combination with
multi-protocol attack is too large (more than 100 different combinations) to
model them all manually with Tamarin. All timings are calculated with 6 CPUs
of 2 GHz and 32 GB of memory.
We can see in Figure 2 that even if two protocols are safe in isolation for a
property, it is not guaranteed that the combination of this two protocols is safe
4
name
ni-
synch
A
ni-
synch
B
sec A
N
A
sec B
N
A
sec A
N
B
sec B
N
B
sec A
K
AB
sec B
K
AB
ni-
agree
A
ni-
agree
B
NSS
0:07
3
0:06
3
0:01
7
-
0:02
3
0:01
3
0:02
3
0:01
3
0:03
3
0:02
3
NSSA
0:16
7
0:37
7
0:05
7
-
0:35
3
10:28
3
0:03
3
0:06
3
0:03
7
0:02
7
NS
0:28
3
0:05
7
0:01
3
0:01
7
0:08
3
0:02
7
- -
0:12
3
0:04
7
NSL
0:22
3
1:07
3
0:01
3
0:04
3
0:07
3
0:02
3
- -
0:08
3
0:17
3
AS
0:09
7
0:04
7
0:03
7
0:02
7
-
0:02
7
- -
0:11
7
0:01
7
AShc
0:05
7
0:05
7
0:04
7
0:03
7
-
0:03
7
- -
0:45
7
0:02
7
K
0:06
7
0:15
7
0:00
7
0:16
7
0:03
7
0:01
7
0:02
3
0:32
3
0:07
7
0:12
7
K2
0:05
7
1:40
7
0:04
7
0:30
7
0:04
7
0:30
7
0:04
3
0:21
3
0:04
7
0:40
7
K3
0:03
7
5:43
7
0:02
7
0:02
7
0:04
7
0:05
7
0:05
3
2:27
3
0:02
7
4:26
7
WLpif
0:00
7
0:01
7
- -
0:00
7
0:00
7
- -
0:00
7
0:01
7
Y
0:04
7
5:53
7
0:04
7
0:12
7
0:24
3
0:13
7
0:09
3
0:12
7
0:03
7
4:18
7
YL
0:12
3
0:32
3
0:01
7
0:02
7
0:07
3
0:15
3
0:05
3
0:11
3
0:06
3
0:17
3
AScj
0:06
7
0:25
7
0:05
7
0:05
3
-
0:01
7
- -
0:02
7
0:06
7
soph
0:00
3
0:01
7
0:00
7
0:01
7
- - - -
0:00
3
0:01
7
Fig. 1. Results found using Tamarin with NS = Needham Schroeder [24], NSS =
Needham Schroeder Symmetric Key [24], NSSA = Needham Schroeder Symmetric Key
Amended [25], NSL = Needham Schroeder Lowe [19], AS = SPLICE/AS [29], AShc
= Hwang and Chen version of SPLICE/AS [16], AScj = Clark and Jacob version of
SPLICE/AS [8], K = Kao Chow [17], K2 = Kao Chow v.2 [17], K3 = Kao Chow v.3 [17],
WLpif = Woo Lam pi f [28], Y = Yahalom [4], YL = Yahalom Lowe [21], soph = a
SOPH basic example. ni-synch denotes non-injective synchronisation, ni-agree denotes
non-injective agreement, and sec A N
A
denotes the fact that A claims the secrecy of
N
A
.
too if they share keys, and multi-protocol attacks are not only due to the other
protocol that is not safe for this property.
We would expect that Tamarin takes more time to analyze properties for
multi-protocols than for protocols in isolation, due to the increased number of
transitions and the larger number of traces with the new protocol.
![Fig. 2. Result found with Tamarin. NS = Needham Schroeder [24], NSS = Needham Schroeder Symmetric Key [24], NSSA = Needham Schroeder Symmetric Key Amended [25], NSL = Needham Schroeder Lowe [19], AS = SPLICE/AS [29], AShc = Hwang and Chen’s version of SPLICE/AS [16], AScj = Clark and Jacob’s version of SPLICE/AS [8], K = Kao Chow [17], K2 = Kao Chow v.2 [17], K3 = Kao Chow v.3 [17], WLpif = Woo Lam pi f [28], Y = Yahalom [4], YL = Yahalom Lowe [21], soph = a SOPH basic example. ni-synch denotes non-injective synchronisation, ni-agree denotes non-injective agreement, and sec A NA denotes fact that A claims the secrecy of NA. * = the first protocol is safe in isolation, ** = both protocol are safe in isolation](/figures/fig-2-result-found-with-tamarin-ns-needham-schroeder-24-nss-2rhom995.webp)
