Information Systems Security 12th International Conference ICISS 2016 Jaipur India December 16 20 2016 Proceedings 1st Edition Indrajit Ray
Information Systems Security 12th International Conference ICISS 2016 Jaipur India December 16 20 2016 Proceedings 1st Edition Indrajit Ray
com
https://textbookfull.com/product/information-systems-
security-12th-international-conference-iciss-2016-jaipur-
india-december-16-20-2016-proceedings-1st-edition-indrajit-
ray/
OR CLICK BUTTON
DOWNLOAD NOW
Information Systems
Security
12th International Conference, ICISS 2016
Jaipur, India, December 16–20, 2016
Proceedings
123
Lecture Notes in Computer Science 10063
Commenced Publication in 1973
Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen
Editorial Board
David Hutchison
Lancaster University, Lancaster, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA
Friedemann Mattern
ETH Zurich, Zurich, Switzerland
John C. Mitchell
Stanford University, Stanford, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Dortmund, Germany
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbrücken, Germany
More information about this series at http://www.springer.com/series/7410
Indrajit Ray Manoj Singh Gaur
•
V. Kamakoti (Eds.)
Information Systems
Security
12th International Conference, ICISS 2016
Jaipur, India, December 16–20, 2016
Proceedings
123
Editors
Indrajit Ray Dheeraj Sanghi
Colorado State University IIIT Delhi
Fort Collins, CO Delhi
USA India
Manoj Singh Gaur V. Kamakoti
Malaviya National Institute of Technology IIT Madras
Jaipur Madras
India India
Mauro Conti
University of Padua
Padua
Italy
We feel privileged and honored to have been associated with the 12th International
Conference on Information Systems Security (ICISS 2016), held during December 16–
20, 2016, at Malaviya National Institute of Technology Jaipur, India. Since its
inception in 2005, this conference has become one of the major events in India in the
domain of information systems security.
For successful hosting of any conference of high repute, there is always a team of
volunteers contributing to its success. Our thanks go to the program chairs, Indrajit
Ray, Mauro Conti, and V. Kamakoti, along with the Program Committee members for
their outstanding job of completing rigorous reviews of submitted papers and selecting
the best from the lot. We would like to thank all the invited speakers for accepting our
invitations to deliver keynotes at this conference.
The tutorial chairs, Gaurav Somani and Devesh Jinwala, did an excellent job in
arranging interesting tutorials. We would also like to thank the tutorial speakers for
offering tutorials at ICISS16. The Organizing Committee co-chairs, Vijay Laxmi,
Preety Singh, and Rajveer Singh Shekhawat, did a commendable job in the conference
management.
The Publications Committee comprising Sonal Yadav, Ramesh Battula, Shweta
Saharan, and Santosh K. Vipparthi worked very hard for the delivery of the pro-
ceedings under a very tight schedule. As publicity chairs, Tooska Dargahi, Chhagan
Lal, Priyadarsi Nanda, and Smita Naval did a wonderful job resulting in the highest
submissions of papers in this year’s edition.
We hope that you will find these proceedings of ICISS 2016 a stimulating and
inspiring source for future research.
This volume contains the papers presented at the 12th International Conference on
Information Systems Security (ICISS 2016), held December 16–20, 2016, in Jaipur,
India. The conference was started in 2005 to cater to cyber security research in India.
Since then it has evolved into an attractive forum internationally for researchers in
academia, industry, and government to disseminate their latest research results in
information and systems security.
ICISS 2016 continued that trend. This year, we received 196 submissions from 17
different countries on 30 different subtopics of interest in information security. The
papers were reviewed by a Program Committee (PC) of 67 internationally renowned
researchers. After a rigorous review process, during which each paper received multiple
reviews, a total of 24 full papers and eight short papers were accepted. We thank the
authors of the 196 papers for their contributions, without which this conference would
not have been possible. We are very grateful to the PC members and external reviewers
who put in enormous efforts in reviewing and selecting the papers. Without their hard
work, this conference would not have been a success.
One of the hallmarks of the ICISS conference series is the high-quality
plenary/invited presentations. This year we were fortunate to have five eminent
speakers give invited presentations: Patrick McDaniel (Pennsylvania State University),
V.S. Subrahmanian (University of Maryland, College Park), Ahmad-Reza Sadeghi
(Technische Universität Darmstadt), Rinku Dewri (University of Denver), and Jeremías
Sauceda (EnSoft Corp). We are very thankful to the invited speakers, who agreed to
present at the conference coming from far-off places in mid-December. The conference
included several tutorials on various topics in cyber security, as well as short talks to
facilitate discussions on emerging topics. We would like to thank the tutorial speakers
for their time and efforts.
We thank all the members of the Organizing Committee for making all the
arrangements. We are grateful to MNIT, Jaipur, for all the support they provided. We
would like to thank the architects of EasyChair for providing a highly configurable
conference management system. The entire process of submission, refereeing, and
e-meeting of the PC for the paper selection was done through the EasyChair system.
Last but not least, we gratefully acknowledge Springer for sponsoring the ICISS
Best Paper Awards starting with this year’s conference. A special thanks to Alfred
Hofmann of Springer for not only readily agreeing to publish the conference pro-
ceedings in the LNCS series, but also helping institute this award. Thanks go to his
team and, in particular, Anna Kramer for preparing the proceedings meticulously and in
time for the conference.
General Co-chairs
M.S. Gaur MNIT Jaipur, India
Dheeraj Sanghi IIIT Delhi, India
Program Co-chairs
Indrajit Ray Colorado State University, USA
Mauro Conti University of Padua, Italy
V. Kamakoti IIT Madras, India
Organizing Co-chairs
Vijay Laxmi MNIT Jaipur, India
Rajveer Singh Shekhawat Manipal University Jaipur, India
Preety Singh LNMIIT Jaipur, India
Awards Committee
Dhiren Patel SVNIT Surat, India
Sanjay Chaudhary Ahmedabad University, Ahmedabad, India
X Organization
Publications Committee
Sonal Yadav MNIT Jaipur, India
Ramesh Babu Battula MNIT Jaipur, India
Shweta Saharan MNIT Jaipur, India
Santosh K. Vipparthi MNIT Jaipur, India
Publicity Committee
Tooska Dargahi University of Rome Tor Vergata, Italy
Chhagan Lal University of Padua, Italy
Priyadarsi Nanda UTS, Australia
Smita Naval IIIT Kota, India
Steering Committee
Udaykumar Yaragatti MNIT Jaipur, India
Sushil Jajodia George Mason University, USA
Chandan Mazumdar Jadavpur University, India
Bimal Kumar Roy ISI, Kolkata, India
Arun K. Pujari Central University of Rajasthan, India
S. Sancheti Manipal University Jaipur, India
R.K. Shyam Sundar IIT Bombay, India
Authentication
Privacy
Software Security
Short Papers
1 Introduction
Time synchronization protocols based on broadcast or multicast play an impor-
tant role in distributed computer networks such as sensor networks [24]. In many
cases, protection of time synchronization packets is indispensable in order to
guarantee the integrity and authenticity of time information; this is especially
true in open environments like the internet. In general, the performance of time
synchronization protocols decreases due to latencies caused by computational
operations, in particular by cryptographic operations. This decrease in perfor-
mance needs to be considered in the design of security measures (see e.g. [16]).
The Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol and
its variants [8,10,17–19] rely on symmetric cryptography and use delayed disclo-
sure of keys to acquire the asymmetric properties that are desired for broadcast
c Springer International Publishing AG 2016
I. Ray et al. (Eds.): ICISS 2016, LNCS 10063, pp. 3–22, 2016.
DOI: 10.1007/978-3-319-49806-5 1
4 K. Teichel et al.
communication. They thus fulfill the special security requirements for broad-
cast time synchronization and are employed by multiple time synchronization
protocols. The fact that delayed disclosure requires the participants to agree on
a schedule creates a challenging interaction between the security mechanisms
and the time synchronization process. In this paper, we discuss the security of
time synchronization broadcast associations secured via variants of the TESLA
protocol, particularly with respect to this interaction. We highlight a specific
attack vector that an adversary can follow to circumvent the security measures
of such associations and to deliver false timing information to a participant.
We give a generalized description of the attack vector and use it on a minimal
example protocol for illustration. We also discuss feasible countermeasures that
can either make the attack theoretically impossible (which requires a significant
effort, possibly requiring a change in the communication structure) or mitigate
the attack by making its execution practically impossible. Next we present a
model in UPPAAL [2] that allows the analysis of the behavior of the protocol
participants’ clocks during an attack; this model also allows the assessment of
the effectiveness of the countermeasures discussed. In addition, we investigate
the extent to which specific existing time synchronization protocol specifications
might be vulnerable to the attack vector discovered. One of the intentions of this
paper is to facilitate discussion about the attack vector, and to supply a basis
for possible further analysis.
The remainder of this paper is structured as follows: Sect. 2 provides an
overview of the two main approaches to time synchronization (unicast-type
and broadcast-type communication) and of the usual security measures that
each approach entails. Section 3 defines the notation used throughout the paper,
discusses the underlying assumptions and defines a Minimal Example Proto-
col (MEP) for illustration in later sections. Section 4 shows the attack vector
on broadcast-type time synchronization protocols that have been secured with
TESLA-like mechanisms, exemplified by means of the MEP. In Sect. 5, we dis-
cuss a selection of possible countermeasures against the attack vector shown.
Section 6 presents our automated analysis in UPPAAL and provides its results;
these concern, on the one hand, quantification of the parameters that allow
the attack to happen and, on the other hand, the effectiveness of some of the
countermeasures discussed in previous sections. Section 7 presents three exam-
ples in which TESLA-like mechanisms are employed to secure broadcast-type
time synchronization: Network Time Protocol (NTP) secured by Network Time
Security (NTS) [23], TinySeRSync [24], and Agile Secure Time Synchronization
(ASTS) [27]. This section gives an assessment on how robust those protocols are
against the attack vector under discussion. Finally, Sect. 8 concludes the paper.
Fig. 1. Schematic depiction of typical message exchanges that are used for time syn-
chronization between Alice and Bob. The left diagram depicts one-way synchronization,
while the right diagram depicts two-way synchronization.
exchanges for these two kinds of transfer. Although there are exceptions, net-
work protocols for time synchronization typically use two-way transfer when
they employ unicast-type communication (one sender, one receiver), whereas
they use one-way transfer when they employ broadcast-type communication
(one sender, multiple receivers). The exchange of time synchronization proto-
col packets between the nodes involved is accompanied by a delivery delay δ
whose characteristics depend on the underlying network. If one-way time trans-
fer is used (Fig. 1, left diagram), messages are transmitted only from the time
server to the time client. In this case, the delivery delay has to be estimated and
the estimate has to be applied to the time offset between server and client. If
two-way time transfer is used (Fig. 1, right diagram), messages are exchanged
mutually between a client and a server. This offers more information on the
delay of the transfer messages (it is bounded by the round trip of the message
exchange), and allows elimination of the delay dynamically, under the assump-
tion that the network delay is symmetric for the two directions, i.e., that ξ = 1/2
in the figure.
enabling the server to regenerate the shared key [11,22] or by having the server
encrypt its full association state and distribute it to the appropriate client [5].
Besides symmetric key techniques, external security measures such as MACsec,
IPsec, and (D)TLS are candidates for securing time synchronization protocol
packets [6,16]. It is also possible to use asymmetric cryptography for the cre-
ation of signatures for time synchronization traffic, although this comes at the
cost of significant overhead and is therefore often excluded as a possibility [16].
In the remainder of this work, we forego further detail on securing unicast-type
time synchronization traffic, since our focus is on attacking a particular scheme
for securing broadcast-type time synchronization.
For securing broadcast-type time synchronization messages, the specifications
generally use different techniques than those used in the unicast case. Although
broadcast-type time synchronization might seem like an application for classical
asymmetric cryptography, the computational cost is often an essential argument
against it. Instead, specifications often apply the TESLA protocol [18] or one
of its variants [8,17]. This class of specifications (the entirety of which we call
“TESLA-like mechanisms”) achieves asymmetric properties while using purely
symmetric cryptography. They can be used for securing broadcast-type time
synchronization either natively for a newly specified protocol [24,27] or as an
addition to existing protocols [22]. Typically, the symmetric cryptographic mea-
sures are hash-based message authentication codes (MACs), which have a very
low computational cost. The asymmetric properties are achieved by using a pre-
defined schedule for usage and disclosure of keys: The sender attaches to each
packet a MAC generated with a key that has not yet been disclosed and is thus
known only to the sender itself at that point in time. A receiver buffers a packet
for later validation of the included MAC. At a later time, the sender discloses
the key, enabling the receivers to start the validation of the buffered MACs. For
the scheme to work, it a receiver must be sure that the key used to generate a
received packet has not been disclosed; otherwise, the MAC and therefore the
whole packet may have been generated by an adversary. To this end, a prede-
fined time schedule is used: time is partitioned into intervals in advance. Each
time interval is associated with a key which is obtained in reverse order from a
one-way key chain. For details on this, we recommend that the reader to either
consult Reference [18] or study the way that keys are generated in the Mini-
mal Example Protocol in Sect. 3. Because TESLA-like mechanisms are based on
releasing messages on a pre-determined schedule, they require the client to have
its clock loosely synchronized with the server’s in order to establish the required
security property. Loose synchronization is important as an initial requirement,
which is typically met by performing time synchronization exchanges during
the bootstrapping of the broadcast message stream. Such prior time synchro-
nization exchanges are usually secured by means of methods other than the
TESLA-like mechanism; these methods usually have a higher overhead, either
computationally or in terms of communication bandwidth. However, the security
of any TESLA-like scheme is based on the assumption that any client’s clock is
loosely synchronized to that of the server not only initially, but that it keeps the
Attacking Time Synchronization Secured with TESLA-Like Mechanisms 7
In this section, we define the Minimal Example Protocol (MEP), which is used for
illustration in later sections. When correctly applied, it provides the clients with
guarantees for packet integrity, linked with strong source authentication. Before
we present the protocol’s steps, we supply some essential protocol notation.
The agent names Alice, Bob, and Mallory are representative of a client,
server, and attacker, respectively. In short form, the client, Alice, is denoted
as A, the server, Bob, is denoted as B, and the attacker, Mallory, is denoted
as M . The clock of a participant X is denoted by CX and CX (t) denotes the
value that clock reads at time t. Furthermore, the expression Adj(CX , δ) denotes
the process responsible for adjusting the clock CX to compensate for a reported
offset of amount δ from a reliable time synchronization source. The binary oper-
ator || is used to represent the concatenation of messages. We assume that
there is a fixed cryptographic hash function h that all participants have agreed
on using. For a given key value K and message m, the expression MAC[K](m)
stands for the keyed hash message authentication code using the hash function h
mentioned above, computed over m and with K as the key.
f f f f
K0 K1 ... Kn−1 Kn
f f f
K1 ... Kn−1 Kn
| | | | |
I1 ... In−1 In
Course of time and key usage
Fig. 2. Depiction of the generation of the one-way key chain for TESLA-like mecha-
nisms.
Below, we present the protocol steps of the MEP, which help with the expla-
nation of the attack in Sect. 4, and also serve to illustrate possible countermea-
sures in Sect. 5. We assume that Alice wants to synchronize her clock CA to
Bob’s reference clock CB . For simplification, we also assume that Bob’s refer-
ence clock is perfect, i.e., that for any absolute time value t we have CB (t) = t.
8 K. Teichel et al.
Additionally, we assume that for a chosen number n of intervals, Bob has gen-
erated a one-way key chain as follows (a graphic representation of this scheme
can be seen in Fig. 2):
1. He has generated a key Kn randomly.
2. He has then applied a one-way function f to generate Ki = f n−i (Kn ), for all
values i with 0 ≤ i ≤ n − 1.
3. He has applied another one-way function f to generate a chain of MAC
keys Ki = f (Ki ), for 1 ≤ i ≤ n.
Furthermore, we assume that Alice has received the following set of TESLA
parameters in a way that guarantees that they are the same values that Bob
uses:
– the starting time s1 of the first interval I1 ,
– the uniform duration L of all time intervals,
– the disclosure delay d, denoting the number of intervals between the usage
and disclosure of a key in the chain,
– the base key K0 for the one-way key chain, and
– the one-way functions f and f .
Additionally, we assume that there is a constant delay Δ for messages traveling
from Bob to Alice and that Alice has precisely estimated Δ.1
We define the MEP as follows: The time server, Bob, sends a broadcast-
type packet Pi at the starting time si of each interval Ii . Such a packet is
constructed by defining Pi = i || CB (si ) || MAC[Ki ](CB (si )) || Ki−d , where for
all cases i − d ≤ 0, a predefined “empty” value is used instead of Ki−d .
When Alice receives Pi at time ri , she first checks the timeliness of Pi . In
the MEP, she does this by simply checking the inequality CA (ri ) − Δ < si+1 , in
which CA (ri )−Δ represents the assumed sending time of Pi . If Alice has verified
the timeliness of a packet Pi , she saves Pi together with the value CA (ri ) of her
clock at the reception time of Pi . An additional action that Alice takes upon
receipt of any packet Pi is to check whether the disclosed key Ki−d is a valid
key (whenever it is not the empty value). She can do this by using the one-way
function f to check Ki−d against an already verified key, for example K0 (in this
example, she verifies the equality K0 = f i−d (Ki−d )). When Alice has verified a
key Ki−d , she can then use it to derive Ki−d . With this, she can try and verify the
integrity of Pi−d (recall that Pi−d , together with the timestamp value CA (ri−d ),
was stored beforehand, given that its timeliness was verified at reception time).
For the verification of a packet Pi−d ’s integrity, Alice simply verifies that her cal-
culation of the message authentication code MAC[Ki−d ](CB (si )) agrees with the
MAC value included in Pi−d . If Alice has verified the integrity of a packet Pi−d ,
she calculates the difference δi−d = CA (ri−d ) − (CB (si−d ) + Δ) and then starts
the process Adj(CA , δi−d ). For the purpose of this minimal example protocol,
we assume that Adj(CA , δi−d ) simply sets the clock CA back by δi−d .
1
To model Δ as factually constant in the network simplifies the analysis. Assuming
that Alice treats it as constant makes sense because, as long as she only has one-way
time synchronization communication data available, she cannot reliably determine
or compensate for varying network delays.
Attacking Time Synchronization Secured with TESLA-Like Mechanisms 9
3. After the effect of the first delay has appeared, Mallory delays another stream
of packets, beginning with Pi2 . Due to adjustments to Alice’s clock because
of the delay added to the time synchronization packets Pi1 , Pi1 +1 , . . . , Pi2 −1 ,
the timeframe in which Alice will accept Pi2 as timely has increased by d2 .
Hence, Mallory is able to delay the stream of packets beginning with Pi2 by
an amount d1 + d2 , which is strictly greater than d1 .3
4. The procedure described in Step 3 is iterated further, resulting in ever larger
possible delays. These delays in turn lead to ever larger offsets between
Alice’s and Bob’s clocks, and therefore to ever larger timeframes during which
Alice still accepts packets as timely. At some point, the offset surpasses the
value (d − 1) · L, where L is the length of the time intervals, and d is the
disclosure delay as defined for the TESLA scheme.
When the offset between Alice’s and Bob’s clocks is larger than (d−1)·L, Phase 1
is finished, and Mallory switches to Phase 2 of the attack. There is now sufficient
time to intercept a packet using a disclosed key from Bob, to forge a packet based
on that key, and to relay the forged packet to Alice fast enough that Alice still
accepts it as timely. Using this technique, Mallory is now able to successfully
pretend to be Alice’s time server, Bob. The security gained by using the TESLA
protocol on the time synchronization traffic is therefore compromised.
We now go through the procedure of the attack, supplying specifics for an
application of it to the MEP, where d = 2 is chosen for simplicity. We start with
the steps for Phase 1 (see also Fig. 3 for an illustration).
For Phase 2, Mallory can use the resulting overlap intervals in which Bob’s
and Alice’s clocks have an offset of more than one interval. She can intercept
all packets starting from P7 , blocking them from being delivered. When Bob
sends P9 (which includes K7 ), Alice still believes to be in time interval I7 . At this
point, Mallory can read K7 , derive K7 and invent a bogus packet Q7 , complete
with a valid MAC using K7 as its key. She has a timeframe of 23 · L to do this
and deliver Q7 to Alice, who will then still accept it as timely. If she keeps this
technique up for P8 and P9 , she can disclose the intercepted (correct) key K7
3
Note that the value of d2 is unknown to Mallory. However, she is able to estimate it
from her knowledge of the time synchronization mechanism.
Attacking Time Synchronization Secured with TESLA-Like Mechanisms 11
I1 I2 I3 I4 I5 I6 I7 ...
| | | | | | | |
P6
P1 P2 P3
P5 d1+d2
d1 d1 d1
P4 d1 +d2
| | | d1 +d2
I1 I2 I3
| | | |
I3 I4 I5 I6
| |
I5 I6 I7
Y1 Y2
to Alice in a believable way. Alice will then validate the bogus packet Q7 and
adjust her clock according to the bogus time values that it might carry.
The attack relies purely on the interdependency of clocks and cryptography
that is specific to time synchronization protocols which are secured with TESLA-
like mechanisms. There are no weaknesses in the preparation stage needed for
the attack to work. In particular, it can be assumed that the client, Alice, and the
server, Bob, have clocks which are initially synchronized to a specified degree; the
attack works even if this initial synchronization is impossible to disrupt. Also,
it can be assumed that the broadcast schedule for a TESLA-like mechanism
(Reference [18] provides some detail) has been exchanged securely; the attack
works even if this exchange is impossible to disrupt.
Note that, in the MEP, we chose the mechanism of bluntly “hard-setting”
the absolute value for the actual adjustment of the clock mostly for its simplic-
ity of presentation. Many time synchronization protocols will use a more refined
mechanism. For example, the NTP will try to make clock adjustments using
only frequency corrections, using increased frequency if the clock is behind its
reference clock and decreased frequency if it is ahead. It will set the absolute
clock value only if the network communication implies large offsets persistently
for a long period of time [14,15]. In addition to the differences between how
protocol specifications describe clock adjustment, some specifications (such as
the one for PTP) only provide abstract concepts for reading and setting clocks,
leaving the technical details open. In such cases, the specific technical processes
for clock adjustment depend on the particular implementation. However, using
means of clock adjustment other than hard-setting or having restrictions on when
hard-setting may occur can only delay the effect of an attacker’s manipulation
for a certain amount of time. Eventually, even large offsets will always be cor-
rected if they are reported persistently (see Option 5 in Sect. 5 and the related
discussions).
12 K. Teichel et al.
5 Discussion of Countermeasures
We now look at methods which might mitigate or counter the attack described in
Sect. 4. Let us first consider techniques which do not change the protocol itself,
but some aspect of the channel(s) via which it is used.
Option 1: Alice can try to mitigate her vulnerability to the attack by select-
ing multiple channels via which she synchronizes her clock. The approaches
in this direction range from just picking multiple time servers [12] to using
multiple network paths in order to reach the same time server via different
channels [21].
Option 2: Another way of defending against the attack is to enforce the confi-
dentiality of the time synchronization traffic, e.g. by means of full encryption
of all packets (see, for example, Sect. 5.8 of [16] for some discussion about
confidentiality in the context of time synchronization).
Ideally, if Mallory cannot identify the packets she needs to delay, she cannot
perform Phase 1 of the attack. Additionally, she may also not be able to execute
Phase 2 under perfect confidentiality, because she would be unable to extract
Bob’s disclosed keys. However, it should be noted that keeping time synchro-
nization traffic confidential is not as simple as merely encrypting the pack-
ets, as metadata already provides a great deal of information and Mallory can
mount attacks even with incomplete information. Additionally, confidentiality in
a broadcast setting would require either a group key solution or asymmetric cryp-
tography. A group key approach is ineffective if Mallory finds a way to join the
group. Asymmetric cryptography contradicts the requirement of low computa-
tional cost, which is the main advantage of employing TESLA-like mechanisms.
In contrast to Options 1 and 2, which work purely by changing the time syn-
chronization protocol’s underlying channel(s), the options below employ modi-
fications to the protocol message flow to defend against the attack.
Such auxiliary time synchronization mitigates the effect of Phase 1 of the attack
because the gradually introduced offset is negated. Most specifications that rely
on TESLA-like mechanisms have some method of achieving initial time synchro-
nization, which can be applied as an alternative communication channel.
Option 5: In order to mitigate the attack, it also helps if regulations are enforced
for the clock adjustment mechanism that limit the amount of offset that can
be maliciously introduced during Phase 1. Plausibility checks can be used for
this purpose, as well as ignoring measured offsets that are above the specified
upper bounds.
By itself, this option can only delay the time by which Mallory is able to switch
from Phase 1 to Phase 2. It can, however, keep a TESLA-like mechanism prov-
ably secure over a certain period of time. This option can therefore also be used
to more efficiently utilize other options, namely Option 4 or 3, as it provides
better guidelines for the frequency in which these options need to be applied.
To explore this issue further, we introduce a parameter Dmax which represents
14 K. Teichel et al.
the maximum amount of offset that Mallory can additionally introduce over the
course of one interval by using delay attacks as described in Phase 1 of the
attack. This parameter is assumed to be simplified in the sense that it is already
adjusted for values like the existing offset between the participants’ clocks before
the interval in question (caused by Mallory or other influences), the frequency
error of Alice’s clock, and fluctuations in the network delay. Under this assump-
tion, we get inequalities 0 < Dmax ≤ L.
A disadvantage of both Options 3 and 4 is that inserting auxiliary commu-
nication into a broadcast-based protocol might represent a significant change
to the communication model, making these options significantly more intricate
to adopt than Option 1 or 2. On the other hand, Options 3 and 4 have the
advantage that they can provide complete protection from Phase 2 of the attack
described in Sect. 4. For this purpose, it is necessary to additionally regulate the
configuration values (specifically the number of intervals and interval length of
the TESLA-like mechanism, as well as aspects of clock adjustment as discussed
under Option 5) of the employed protocol in such a way that it makes reaching
Phase 2 of the attack very difficult or even impossible.
For the automated analysis presented in Sect. 6, we have chosen to include
Options 3 and 5 in the model. The model could easily be adjusted to allow
Option 1 to be included as well, but we did not pursue this path because we
found the security gains for that option to be much harder to quantify, and
decided it was not worth the additional state space growth. Modeling Option 2
went against our decision to eliminate cryptographic aspects from the model.
Option 3 is not included in the model because, for the state space growth it
causes, its practical relevance is doubtful due to the fact that, if a protocol does
not already include a timeliness confirmation exchange, it takes a great deal of
effort to integrate it retroactively.
4
The UPPAAL source code is available for download here: http://www8.cs.fau.de/
∼milius/UPPAAL%20Model%20(TESLA-Like%20Mechanisms).zip.
16 K. Teichel et al.
was completed, while Queries 2 and 3 were always affirmed. This implies that
Phase 1 of the attack can be completed in the model if and only if the protocol
runs for at least (d−1)·L/Dmax + d intervals and that this represents a sharp
bound. On the one hand, these results affirm that the attack is feasible against
the unmodified MEP. On the other hand, they also affirm that a combination
of countermeasures 4 and 5 can protect against the attack if the combination
of nmax , L and Dmax is chosen correctly.
The checks were performed on a computer running a 64-bit version of Win-
dows 7 on an Intel i5 dual core at 2.6 GHz, with 8 GB of RAM. To date, we have
only been able to run the command line verifier tool of UPPAAL under Win-
dows, where it can apparently use only 2 GB of RAM. Therefore, 2 GB of RAM
represents a bottleneck for our checks under the requirement of precise runtime
and memory usage logs. Under these conditions, the 1/9 ratio of Dmax to L was
the best that allowed all query checks to finish. Performance data can be seen
in Fig. 4. The relevance of the analysis of the protocol to practical applications
will increase depending on how small the ratio of small-step delays to interval
lengths can be made. We are working on refining the model further in order to
obtain better results in this area; an attempt to also model the server’s clock to
be more independent from the overall run time of the system is among the next
measures to be tried in order to improve the ratio.
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
textbookfull.com