# Security in Distributed Systems by Verifiable Location-Based Identities

Simon Tschirner, Katharina Zeuch, Sascha Kaven, Lorenz Bornholdt, Volker
Skwarek
<EMAIL_ADDRESS>
RTC Digital Business Processes, Faculty of Life Sciences
Hamburg University of Applied Sciences, Ulmenliet 20, 21033 Hamburg, Germany
corresponding author<EMAIL_ADDRESS>
###### Abstract

Proof-of-Location (PoL) is a lightweight security concept for Internet-of-
Things (IoT) networks, focusing on the sensor nodes as the least performant
and most vulnerable parts of IoT networks. PoL builds on the identification of
network participants based on their physical location. It introduces a
secondary message type to exchange location information. Via these messages,
the nodes can verify the integrity of other network participants and reach a
consensus to identify potential attackers and prevent malicious information
from spreading.

The paper presents the concretization of the concept to allow implementation
on real hardware. The evaluation based on this implementation demonstrates the
feasibility of PoL and enables identifying further steps to develop a
deployable protocol.

###### Index Terms:

Wireless sensor networks, Internet-of-Things, Consensus, Security, Trust.

##  I Introduction

The Internet-of-Things (IoT) belongs to the fastest developing fields during
the past decade. With its growth, it is safe to assume that there are (soon)
tens of billions of IoT-devices existing [2]. Their application spread to
almost every field of life, covering everything from industrial production
plants to children toys, from large scale sensor applications for
environmental monitoring to health care applications, from automotive devices
to home appliances. Among these applications are many safety-critical tasks,
where a malfunction or malicious tampering with devices can impact human
health, may have a large financial impact, or tampers with privacy.

Their increasing spread and importance also increase the interest attackers
are developing for IoT-devices.

At the same time, IoT-networks are prone to attacks, due to their typical
properties. Alaba et al. [3] provide a comprehensive review on IoT-security.
Naturally, inter-connectedness combined with little resources at their
disposal characterises IoT-devices. Requirements on costs, size and energy
consumption are strong, which means that their design provides computation and
memory capacity close to the bare minimum required to fulfil their tasks.

Traditional security mechanisms, e.g. encryption of memory and data
transmission, in turn requiring strong computational power, contradicting the
common light-weight nature of IoT-devices [4].

An aspect of IoT security is the ability to trust in data received from a
device that is part of the network. This use case is typical for wireless
sensor networks (WSN), which are, when connected via a gateway to the
internet, also a part of the IoT. In large WSNs, sensor nodes (SN) cover an
area, exceeding the transmission range of a single SN. These scenarios use
multi-hop communication, where multiple SNs forward data from its source to
the sink (gateway). The WSN has to ensure that sensed data will not be altered
(in an undesired way) on its path from the original SN to the sink.

Thus, IoT requires security mechanisms despite containing SNs as the least
performant parts. Recent surveys identified many security issues in IoT [4,
5], while approaches to secure IoT have been proposed in the literature as
well, e.g. [6].

One lightweight security approach focused on WSNs is provided by [7], a so-
called _Proof-of-Location_ (PoL). They propose to secure a WSN by using a
trust mechanism consisting of a combination of redundant localisation of
sensor nodes and consensus generation within a WSN.

The main purpose of this paper is to address the challenge arising from a
combination of the light-weight nature of IoT devices with the computational
complexity of effective security mechanisms. Thereby, the following research
questions will be addressed:

Q1.

How can PoL become an implementable, usable protocol?

Q2.

Can PoL serve as a short-range communication light-weight security mechanism?

This paper further defines the PoL protocol, reaching an implementable state.
Detailed extensions for the concept of PoL include its implementation and
evaluation in the field of short-range communication. The presented extensions
incorporate the understanding of an IoT device’s identity proposed by Wöhnert
et al. [8].

The rest of the paper is structured as follows: First, the background focuses
on the usage of identity to create trust in data from IoT devices. Further
identity-based attacks, avoidable by using the presented concept, are
depicted. Section III describes how the presented concept has been developed
to create a solution to the identified identity-based attacks. The description
of the concept itself follows in Section IV. Implementation details are shown
in Section V and experimental results from a concrete implementation are
presented in Section VI. Finally, conclusions and future work are summarised.

##  II Trust and Identities in the Internet of Things

Securing a WSN contains two aspects:

  * •

ensuring trust in the system’s data and

  * •

ensuring that only authorised devices enter the network.

First, a basic understanding of the term _trust_ is necessary. Often, trust is
defined as requiring psychological and sociological abilities [9]. Considering
that WSNs do not offer these abilities, a more technical approach is needed.
Taking into account [10] and [11], trust in a computer(-system) and its data
resembles the fact that the computer(-system), device or algorithm was not
manipulated by a malicious agent [11]. This absence of manipulation leads to a
reduction of uncertainty about data and devices within the network. According
to [10], this is a necessary prerequisite for the development of trust.
Consequently, this paper assumes that trust in the system’s devices implies
trust in the system’s data.

Second, the term _identity_ has to be discussed. ISO defines identity as
“characteristics determining who or what a person or thing is” [12]. A unique
identity gives us a mean to distinguish every single device from any other
device in a network.

A closer analysis of possible attacks on WSNs reveals the possibility to
reduce several different attacks to the ability to pretend false identities.
Using this ability is known as Sybil attack, first mentioned by [13]. Examples
of related attacks are a replay attack as well as an active man-in-the-middle
attack. Both aim to inject false data or commands into a network. Also,
Denial-of-Service (DoS) attacks, working with any form of flooding mechanisms,
have to present a valid identity to make SNs process messages instead of
immediately dismiss them. Unique device identification is required to avoid
unauthorised devices entering the network,

Wöhnert [8] propose an approach for defining the identity of cyber-physical
IoT devices. They define identity as a combination of a finite number of
attributes that the IoT device has. The concept presented in this paper takes
advantage of the distributed nature of WSN to secure such identities of the
network’s devices. It uses mechanics inspired by distributed ledger technology
(DLT) – consensus and data distribution.

The consensus is used in DLT-systems to aim for a system wherein the trustor
does not need to trust one trustee or a third party. Instead, it has to trust
in the system itself, its algorithm and the totality of entities. Often,
consensus mechanisms implement Byzantine Fault Tolerant protocols as described
by Lamport [14]. The other DLT-principle is the distribution of data. Every
entity can own a copy of the ledger, including all network transactions, to
ensure transparency. Later this paper describes how the proposed approach
uniquely identifies devices in the network, using distributed, identity-
related data in combination with a consensus on this data.

Given the proposed mechanism of secured, unique identification, it is even
possible to estate trust in data: assuming that a device is trustworthy, based
on its identity and the past behaviour of this identity, data provided by this
identified device is trustworthy.

##  III Securing WSNs via Location-Based Consensus

As described in the previous section, a set of entities can build a unique
identity. This section defines these entities as well as the DLT-mechanisms
that secure the identity-related information.

SNs can have various attributes that create their identity. The more
attributes used for identification, the easier it is to guarantee a unique
identification. However, the usage of complex identity profiles in WSN is
inadequate due to memory and computational restrictions. Therefore, a more
light-weight approach is needed. Several approaches include the location of a
node, e.g. as a context for measured data [15, p. 2519]. Its location is a
unique attribute of a device, as there is physically no possibility that two
devices are at the same location. Thus location would be a unique attribute,
forming a device’s identity. Using a node’s location for identification and
trust in its data has been introduced by [16] and further described as _Proof-
of-Location_ (PoL) in [7]. This paper focuses on a detailed description of PoL
and presents concrete steps towards its implementation.A focus lies on the
DLT-mechanisms that should prohibit or at least identify attempts to tamper
with data integrity as stated by [17, chapter “paying for integrity”].

PoL, as described by [7], is a very light-weight approach, as the required
authentication information is naturally available in WSNs and often already
accessible through the used hardware, e.g. via the received signal strength
indicator (RSSI). This value gives a rough estimation of the distance between
two nodes. PoL uses the lateration of RSSI-values from different nodes in
range to derive a node’s location. Despite knowing that using RSSI for
localisation has its limitations [18], it will be used as an example
throughout this paper, exploring if the proposed concept around PoL works in
principle. In practice, depending on the application, one has to expect that
the resolution of positioning based on RSSI is not high enough to guarantee
consistency and uniqueness of a derived SN’s location.

Trust in an identity based on the location, as proposed by PoL, can be
categorised into direct trust and recommended trust [19, p. 46]. On the one
hand, there exists direct trust, SNs have in the node they localise
themselves. On the other hand, parties not involved in the localisation must
have confidence in the localised node due to tamper-proof determination of its
location and integrity of the result. Consequently, trust within a system
builds upon the identification of the nodes based on their location.

Additionally, the consensus among the network participants, the sensor nodes,
on data integrity is key for their persistence. When a certain number of nodes
in the network with (explicit) or without (implicit) communication agrees on
the trustworthiness of certain information, it gets stored by the system
(without further defining or explaining different implementations of the
storage right now).

From a security perspective, implementation of PoL covers all aspects of the
CIA3-goals [20] but confidentiality, which still has to be achieved using
standard cryptographic methods. All other aspects are covered by a combination
of a BFT communication protocol and an identity check (see Section IV). Data
_integrity_ by means of unauthorised alteration according to ISO-definitions
such as [21] or at least its detection is achieved by the BFT [14] itself: The
combination of redundant communication and repetition using different message
propagation paths helps to detect unintended alterations. Note that this
method does not secure that the data itself is correct. As the data originates
from a sensor, the sensor’s output must be true and valid. _Availability_ is
defined as accessibility and usability of the data on demand [21]. Technically
seen, the availability is ensured by the broadcast of the different message
types further described in Section IV. Therefore, messages are not sent via
one single, attackable way but to many recipients. _Authenticity_ (=
verifiable identity of the origin of messages, derived from [21]) and
_accountability_ are created by independent verification of the identity of
the original sender of a message using distance information of multiple
recipients. They have to additionally exchange their knowledge about the
distance according to BFT-communication, as explained in Section IV.

##  IV Concept of Proof-of-Location

A conclusion from the discussion of trust and identity from the previous
sections is that network communication can be secured by identification of
_trustworthy_ and _untrustworthy_ communication participants. PoL utilises
this principle and uses a node’s location as the key component for its
identity. The most suitable scenarios for PoL are those where nodes are
typically in a fixed location or at least in a fixed relative location to each
other. Examples are (long-term) measurement campaigns where nodes are supposed
to report certain information from determined locations or logistics
scenarios, where nodes are located inside a freight container. The container
moves, while the relative location of the nodes inside stays the same. For a
static network, nodes not changing their location are defined as
_trustworthy_. Nodes changing their location are seen as _untrustworthy_ and
such is the information spread by those.

Considering mobile nodes requires additional mechanics. Either a node has to
report to the network when it becomes aware of being moved, e.g. using values
from acceleration sensors, or the protocol needs to be adjusted. A possibility
is that the mobility of a node becomes part of its identity. Another option is
the usage of additional attributes or knowledge of the network’s history.
However, these considerations are beyond the scope of the presented work.

###  IV-A Basic Principle

A precondition is that each node knows its exact, relative location, e.g. as a
result of an initialisation phase (not considered in this paper). During
further communication, nodes have to create a representation of the network
topology by identifying and storing other nodes’ positions additional to
attributes, which can be considered part of their identity. Once a node has an
overview of the surrounding network, it is possible to relate received
messages, their source and the source’s stored location. It is possible to
verify the source’s location and thus the trustworthiness of its transmitted
information. In consequence, nodes can monitor manipulation attempts.

The topology storage plays a central role in the implementation of PoL. It
stores the different node’s locations, related measurement data and further
attributes needed for their identification. Thus it is a node’s memory of the
network and its main tool to identify attacks.

###  IV-B Message Types

The implementation of PoL presented in this paper utilises three message types
for communication inside the network: _payload messages_ , _BFT messages_ ,
and _alert messages_. Payload messages contain the actual payload, i.e. the
sensed data. BFT messages transmit and exchange location-related information,
a precondition to identifying (malicious) nodes. Alert messages indicate that
a node detects a problem, either a violation of a predefined condition
connected to the original measurement task or a manipulation attempt on the
network or identities inside the network.

Since only the first message type spreads sensed information, messages of the
other two types (except alerts connected to the measurement task) introduce
additional overhead caused by the implementation of PoL. Thus, to keep the
approach light-weight, usage of these types has to be limited.

####  IV-B1 Payload Message

Payload messages contain sensed data. This message includes the payload and
the payload signed with the node’s location (cf. Figure 1). Signing the
payload, on the one hand, connects it to a particular location. On the other
hand, it allows the receivers (B, C and D) to validate the sender’s (A)
identity.

Figure 1: Payload messages (here emitted by A) include payload and payload
signed with the node’s location. Receiving nodes can use their information
about the sender’s location to confirm that both sender and receiver share the
same information about the senders’ position.

When such a payload message is received, the recipients will try to verify the
sender’s location. They could, e.g., sign the original payload again, using
the sender’s location from their topology storage. The transmission contains
additional contextual information (e.g. has the sender previously sent the
same class of information from the same position?). Extraction of this and
comparison to historical information allows for further analysis of a sender’s
and message’s integrity.

####  IV-B2 BFT Message

BFT messages spread localisation information inside the network. In the
current implementation, the _topology storage_ is a kind of memorised map in
which each node stores the identity information it gains about other nodes.
Identity information about a node can be sent by the node itself, extracted or
measured from direct communication with that node, or information about a
node, spread by a third node.

RSSI values are a measured value from communication, as further explained in
the following sections. BFT messages are the other two sources of information.
In the protocol presented in this paper, BFT messages are the first level of
distrust or dissent: Whenever a node receives a message from a sender of which
it cannot prove identity, it emits a BFT message. In this case, an identity
that cannot be proven means that not enough information is present in the
receiving node’s topology storage or that measured information, e.g. the RSSI
value, is not consistent with the available information in topology storage.

Figure 2: B is emitting a BFT message, which expresses dissent with A’s
identity and typically contains its sender’s (B) location, stored identity of
the payload message sender (A), and measured $RSSI_{AB}$.

BFT messages (cf. Figure 2) contain the BFT message sender’s (B) location,
stored identity of the payload message sender (A), and measured $RSSI_{AB}$.
Receivers can add this information (if trusted) to their topology storage to
complete their picture of the network. The node, which is the object of the
BFT message, e.g. the identity of which is challenged, can respond, too. BFT
messages can be seen as necessary to create a consensus – or rather dissent –
as the more BFT messages from different nodes are emitted about the same node
(object of the BFT message), the clearer it becomes that the object actually
might be manipulated.

####  IV-B3 Alert Message

The paper distinguishes two completely different types of alerts: Alerts
according to the measurement tasks, e.g. a measured temperature reaches a set
limit, and alerts regarding network infrastructure. Both types are
semantically similar, high priority messages, required to be processed by
their receiver’s (cf. Figure 3).

Figure 3: A is emitting an alert message, containing its identity, the alert-
type and object.

Alert messages contain their sender’s identity, alert type and object.
Depending on the type, the object is either a sensor and its sensed value
leading to the alert or a response to a BFT message about the node itself. How
a node can react to a BFT message will be explained in the following section.

##  V Architecture, Algorithms and Communication Protocol

The key of the presented concept is the verification of a node’s identity by
its location and, hence, to trust messages from identified nodes. As
established, in addition to payload messages (cf. Figure 1), BFT messages (cf.
Figure 2) are introduced. Figure 4 depicts a sequence diagram, showing a node
generating and transmitting a payload message.

Figure 4: Node sensing a value, preparing and transmitting a payload message
(P1).

###  V-A Reception of Payload Messages

The nodes store received messages in a pool of not validated messages (cf.
Figure 5). Messages remain in this pool until the node located its sender and
validated that its location is consistent with the location information used
to sign the message. It is possible to define a specific time frame during
which a message remains in the pool for validation. If validation is not
possible during this time frame, the node could discard a message as invalid.

Figure 5: Received payload messages are stored in a pool for later validation (P2). TABLE I: Topology storage (for sensor node A) | A | B | C | D | MAC | Sensor | Location | Trust
---|---|---|---|---|---|---|---|---
A |  | $RSSI_{AB}$ | $RSSI_{AC}$ | $RSSI_{AD}$ | $MAC_{A}$ | $SensorType_{A}$ | $Location_{A}$ | $A_{Tr}$
B | $RSSI_{BA}$ |  | $RSSI_{BC}$ | $RSSI_{BD}$ | $MAC_{B}$ | $SensorType_{B}$ | $Location_{B}$ | $B_{Tr}$
C | $RSSI_{CA}$ | $RSSI_{CB}$ |  | $RSSI_{CD}$ | $MAC_{C}$ | $SensorType_{C}$ | $Location_{C}$ | $C_{Tr}$
D | $RSSI_{DA}$ | $RSSI_{DB}$ | $RSSI_{DC}$ |  | $MAC_{D}$ | $SensorType_{D}$ | $Location_{D}$ | $D_{Tr}$

A node’s message pool is checked regularly for new or not validated messages
(cf. Figure 6). To locate other nodes and thus validate their messages,
specific information for localisation has to be stored. This is done in the
topology storage (see Table I). This storage contains information about
transmitted and derived locations of nodes and RSSI-values on individual
communication paths, e.g. in the form $RSSI_{Sender,Receiver}=-42$. The
topology storage does not only include topology information for connections
from or to the receiving node itself. It also stores topology information of
connections between other nodes (limited to those in range). Additionally, the
storage has a third dimension, keeping a (limited) history of topology and
identity information.

Figure 6: Processing of received transaction messages; extraction of relation
and validity check (P3).

For each message in the pool, topology information is derived and stored
(transitions 2 to 5, Figure 6). If the extracted connection between two nodes
is new to the node, the node adds it to the topology storage. Otherwise, the
node adds the RSSI value of the current message to the existing entry. This
history of RSSI values is essential. It allows filtering to reduce noise or
tracking of other irregularities like node movement.

From stored topology information, a node tries to generate the sending node’s
location key. It is possible to confirm the generated location key with the
received hashed payload by hashing the payload locally (transitions 6 to 8,
Figure 6). If the two hashed payloads match, the message is successfully
validated and will be stored in the receiver’s trusted memory (transition 9,
Figure 6). Otherwise, there is either not enough topology information to
localise a node or the known information does not lead to a validation (e.g.,
in case of movement or manipulation of the sending node). In this case, a BFT
message is sent (transition 10, Figure 6).

###  V-B Emission of BFT Messages

BFT messages ensure the availability of sufficient context information inside
the network’s nodes to verify the sending node’s location. If the context is
insufficient or inconsistent with the currently experienced situation, nodes
actively try to improve context by sending out BFT messages. They contain the
BFT sender’s relative location, the payload message sender’s identity and its
$RSSI_{SR}$. Other nodes react to BFT messages, as depicted in Figure 7.

Figure 7: Response to a received BFT message (P4).

First, the original topology information, i.e. the topology information
derived by the receiver of the payload message, who is now emitter of the BFT
message, is extracted and stored (transitions 2 to 4, Figure 7). Then,
analogue to processing of payload messages, the relation between sender and
receiver of the BFT message is derived and stored (transitions 5 to 8, Figure
7). In practice, the emission of BFT messages is, while possibly triggered by
a received payload message, asynchronous to the transmission of payload
messages. After a round of BFT messages, nodes in the range should have enough
context to decide if a received payload message is to be trusted or not.

BFT messages of different depth and different triggers for BFT messages are
possible. A second-level BFT message could be a reply to a BFT message,
triggered by the reception of BFT messages from a non-validated node. This
message could include the original BFT message, location and $RSSI_{SR}$, as
derived by the BFT message’s receiver. However, the more and the longer BFT
messages become, the less light-weight would the protocol be. Therefore this
is not suitable for PoL as presented in this paper.

###  V-C Emission of Alerts

Attack related alerts and _trust scores_ inform about the behaviour of nodes
that could be an attack. Trust scores are a part of identity in the topology
storage (cf. Table I), managed locally by each node. Two conditions determine
if the trustworthiness of a node in range is low: A low trust score or the
presence of a larger number of BFT messages objecting the node in question. As
explained above, BFT messages are emitted when the identity of a node cannot
be proven. Multiple BFT messages about the same node, therefore, indicate that
something is wrong with that node. The trust score is a second measure and
adjusted according to the behaviour of that node.

For a node $A$ (assumed to be trustworthy), suspicious behaviour of a node $B$
would be to receive a BFT message from $B$ about $A$ ($BFT_{BA}$), as long as
$A$ is not aware of any movement. There are five reasons for $A$ receiving a
$BFT_{BA}$ message:

  1. 1.

Node $A$ has moved,

  2. 2.

Node $B$ has moved,

  3. 3.

There was a measurement error,

  4. 4.

A malicious node $A^{\prime}$ has sent a payload message, pretending to be $A$
that $B$ responded to, or

  5. 5.

Node $B$ is malicious and sends a BFT message to manipulate the network’s
trust towards $A$.

The decision tree in Figure 8 depicts, how node $A$ reacts to a received
$BFT_{BA}$ message. The tree tends to lead to “ignore”-states if it is not
possible to identify the reason for the BFT message with certainty. This saves
operations and keeps the protocol light-weight. In general, the protocol is
robust against a node missing a manipulation attempt, especially since it is
quite likely that other nodes will identify the attempt anyway, rather than
sending a possibly unjustified alert.

Figure 8: Decision tree depicting how node A processes reception of a BFT
message from node B with node A as object.

Decision levels three and four in the tree in Figure 8 are about
trustworthiness or rather distrust of one node in another:

$\begin{array}[]{l}\theta_{XA}=(A_{Tr}<\varepsilon)\ \vee\
(|BFT_{YA}|>\tau)\big{|}Y\in Node\end{array}$

Distrust of X against A ($\theta_{XA}$) is a binary function, becoming $true$
if the trust of $X$ in $A$ ($A_{Tr}$) is lower than a limit $\varepsilon$ or
$X$ receives a number of BFT messages ($|BFT_{YA}|$) exceeding a limit $\tau$
(dependent on the number of nodes in range). In other words: if $X$ has a low
trust score on $A$ or a certain number of nodes in $X$’s range question $A$’s
identity, $X$ has distrust in $A$.

The first two levels of the tree interpret the received BFT message and
compare the claimed RSSI value ($RSSI(BFT_{BA})$) with the measured value
($RSSI_{BA}$) and historical values from the topology storage. If all of these
values are consistent, the case is ignored completely, as there is no clear
indication of why $B$ sent a BFT message. If only the historical values are
inconsistent, distrust is taken into account. If $A$ has distrust against $B$,
e.g. because several BFT messages with $B$ as an object are received, $B$
might have sent a BFT message because it was the node moved. As a result, $A$
emits a BFT message to indicate a problem with $B$ ($S!(BFT_{AB})$). The
problem is not that striking, that an alert has to be sent. However, if
history is inconsistent, $A$ has no distrust against $B$, but there is a
distrust in $A$ (since $A$ is the perspective, distrust can only mean that
several $BFT_{XA}$ messages are received, i.e. BFT messages with $A$ as
object). Now $A$ must admit that something is wrong with itself. Either $A$
has moved, or an $A^{\prime}$ tries to steal $A$’s identity. As an honest
node, $A$ emits a _“self-distrust” alert_ , meaning that $A$ believes $B$ and
thinks that it got attacked or manipulated and thus should not be trusted
anymore.

If $RSSI(BFT_{BA})$ claimed by $B$ is inconsistent with $RSSI_{BA}$ measured
by $A$, this is suspicious. If $RSSI_{BA}$ is consistent with history, $B$
seems to be at its usual location, so the sent $RSSI(BFT_{BA})$ might be a
measurement error. Still, if there is distrust against $B$ (i.e. $B$ has low
trust or several nodes seem to see $B$ at a different location) but not
itself, $A$ it emits a $BFT_{AB}$ message. If history is inconsistent with
$RSSI_{BA}$ and $A$ has distrust against $B$, while no further BFT messages
are indicating that $A$ might have been manipulated, $A$ emits a _“distrust”
alert_ against $B$, meaning that $A$ believes that $B$ has sent the original
BFT message maliciously.

The next step is to implement the reception and processing of a distrust
alert. A decision tree analogously to Figure 8 becomes very large and is
infeasible to depict here. One reason for this is that the receiver (e.g. node
$C$) has to ensure that $A$’s alert is not an attack-attempt itself, e.g. by
ensuring that the BFT message, the distrust alert replies to, really has been
sent.

In a nutshell, the tree has three outcomes: (1) ignore, (2) accept, and (3)
reject. An accept of the distrust alert means, that $C$ also sees $B$ as
untrustworthy, as a result, $B$’s trust will be reduced ($B_{Tr}--$). A reject
means that $A$’s alert is not trusted and therefore will lead to a reduction
of $A$’s trust score and additionally increase the trust score for all nodes
that participated in the dissent, i.e. that also indicated a trust problem
regarding $A$ by sending a related BFT message:

$\begin{array}[]{l}A_{Tr}--,\forall BFT_{XA}:X_{Tr}++\end{array}$

To exemplify: A distrust alert by $A$ regarding a BFT message from $B$ is
accepted, if

  * •

$C$ has received the related BFT message ($BFT_{BA}$),

  * •

$C$ can confirm $A$’s identity, i.e. the measured $RSSI_{AB}$ is consistent
with the information in the topology storage and there is no distrust against
$A$ ($\theta_{XA}==false$) and

  * •

there is doubt about $B$’s identity, i.e. $RSSI_{BC}$ is inconsistent with
information in the topology storage and there is a distrust against $B$
($\theta_{XB}==true$) – again, meaning that the trust in $B$ is already low or
there is a consent in the network that $B$’s identity has been tampered with,
manifested in several $BFT_{XB}$ messages.

##  VI Evaluation

This section evaluates the utility and practicability of the described
concepts. For this purpose, a test scenario has been developed based on two
use cases from ongoing research projects. The main goal is to show the
feasibility of localisation for identification; therefore, the focus lies on
the emission of BFT messages implemented and tested on embedded hardware.

The following describes the test scenario, implementation details and
experimental results. Early tests have shown that further effort would be
necessary to tackle instability issues of RSSI value measurements. Thus, an
analysis tool has been developed to identify a suitable filter and proper
parameters. Subsection VI-C describes the tool and method.

###  VI-A Use Cases & Test Scenario

Several ongoing research projects have shown the need for PoL. The two most
important use cases that finally inspired the test scenario are:

  * •

Freight tracking in logistics as researched in the HANSEBLOC-
project111https://www.hamburg-logistik.net/hansebloc/. During the
transportation of goods, PoL can discover the unwanted and unauthorised
movement of goods. Assuming goods transported on pallets, each pallet can be
equipped with a SN, thus creating a WSN. Since pallets should not change their
relative position during transportation, application of PoL is feasible;

  * •

Measurement campaigns in a city’s sewage system monitoring as in the research
project WaterGridSense4.0222https://www.watergridsense40.de/. The deployed WSN
consists of one sensor node per surface water drain. Secure supervision of a
sewage system to detect illegal external sewage injection is enabled by using
PoL.

These use cases differ in their realisation. They are combined into one
experimental test scenario, evaluating the functionality of PoL
implementation. For convenience, arbitrary sensor values (temperature) account
for the payload. The focus lies on optimising RSSI value filters to enable
stable and faultless release of BFT messages, as these are the core of the
subsequent PoL security mechanisms.

Five SNs are arranged in a distributed topology on three height levels, as
shown in Figure 9. Nodes’ plane distances vary between a half and two metres.
Node 2, 3 and 5 are on the same height level. Node 1 is put one meter below
them and node 4 one meter above. While SNs 1 to 4 are static, SN 5 moves
twice: (1) it is moved away from the network to position 5’ and (2) it is
returned into the network to position 5.

Figure 9: Arrangement of SNs. All nodes static, while node 5 moves from
position 5 to 5’ and back.

###  VI-B Embedded Implementation

Network communication follows the open-source standard _OpenThread_. The five
SNs in the experimental scenario are based on Particle Xenon boards equipped
with the NRF52840 microcontroller. The final hardware developed in the
aforementioned research projects uses the same microcontroller on a custom-
designed board with a smaller footprint; however, the Particle boards are a
suitable prototyping platform. The Particle Xenon boards offer the possibility
to use Zephyr as the operating system and programming with C.

As mentioned in Section II a SN’s identity is defined as the sum of its
attributes. For the sake of simplicity, besides a SN’s localisation, each SN
is identified by its MAC address. Using the MAC address is sufficient for the
experimental scenarios. However, real applications should take further
attributes into account. The topology matrix is implemented as a struct
containing the known RSSI-values. The structs are arranged in a kind of ring
storage. Whenever a new RSSI-value is received, either by direct measurement
or extracted from a BFT message, it is stored. Yet, there exists no
implementation of an initial localisation phase. Therefore, only RSSI-values
are available for localisation. BFT messages are implemented and sent when a
SN senses a deviation in the RSSI-values. A filter determines the deviation
threshold, described in the subsequent subsection. BFT messages can be
received and initially handled. Implementation of alerts or responses to BFT
messages is still a work in progress.

###  VI-C Filter Determination

Measurement of RSSI-values is very dependent on environmental conditions and
affected by noise. The presented concept assumes that for RSSI-values
$RSSI_{XA}=RSSI_{AX}$ is true. Initial tests have shown that this is true
within a deviation of $\pm 5$dB. Nevertheless, raw values measured by SNs vary
at almost every timestep. Thus, to guarantee a reliable emission of BFT
messages, the need for a more sophisticated filter was obvious from the
beginning. The main requirements for the filter are:

  * •

it shall be able to filter outlier values so that there are no false BFT-
messages sent to the network and

  * •

it shall not miss actual changes in a node’s current location, hence sending
too few BFT-messages;

  * •

whilst movement of a SN shall only be indicated by a limited amount of BFT-
messages per SN.

The first two restrictions are required so that no false movement is
indicated, while actual movements are not dismissed. The third restriction is
required to prevent overloading the WSN with redundant messages. To overcome
this problem a two-step process is required – smoothing RSSI-values and then
determine whether to send a BFT-message or not.

With each experiment, all measured RSSI-values were logged to develop a
suitable filter. A self-developed Python-based analysis tool processed the
log-files. The analysis tool provides various filters: simple moving average
filter, exponential smoothing filter, dynamic moving average filter, Gaussian
filter, median filter, and Kalman filter (c.f. [22]). Figure 10 shows the
varying smoothing quality of the different filters. By further examination, a
combination of median filter and Kalman filter has proven to fit best. Thus
raw measurement values are now first fed into a median filter and,
subsequently, the result values are handed to a Kalman filter. The second
process step is a function to trigger BFT-messages. The function uses the
smoothed RSSI-values and triggers a BFT-message if the current values differ
from the previous values by more than a previously set threshold.

Figure 10: Exemplary close up on RSSI-values and resulting data created by
various smoothing filter, showing differences in their smoothing qualitiy.

###  VI-D Experimental Results

In the experimental setup, the MAC-address of the SNs is used as a reference.
This is the main identifier of each SN. This identification shall be backed up
by the node’s location, based on RSSI values relative to the other nodes in
range. Location is the “true identity”, as described in the concept in Section
IV. A manipulation is assumed when the MAC-address is not backed up by the
location anymore, i.e. when a SN is moved or a malicious node tries to fake
another SN’s MAC-address but sending from a different position. In this case,
it is expected that (a majority of) other SNs in the network recognise the
discrepancy between MAC-address and location and therefore emit a BFT-message.

The experiment shall prove that a movement is recognised, while false
positives are minimised. Correct emission of BFT messages is the fundamental
requirement to implement and utilise PoL. While a couple of test runs have
shown that RSSI-measurement is symmetrical within a range of 5 dB, further
runs have been performed to gather data, to find useful filter parameters as
described before. Figure 11 depicts the data collected through measurement
with the SN arrangement depicted in Figure 9 using the SNs described in VI-B,
using the final filter settings. It shows the raw RSSI-values that SN five
received from the other SNs. Also shown are the RSSI-values smoothed by the
defined filter-combination of a median and a Kalman filter. The change of
position relative to the other four nodes can be seen in the RSSI-values node
five determined about these nodes. As it was a movement away from the other
nodes, the depicted RSSI-values are decreasing (at $\sim$300 seconds). Then
staying constant for the time the SN held its distant position and increasing
again as it was put back to its original position. Thus, because the chosen
filter smooths outliers while movements are still recognisable, it is suitable
for the desired use cases.

The figure also shows that sensor node five received BFT-messages about itself
from each other node. These were received, and hence previously sent, directly
after sensor node five moved. As figure 11 depicts, the movements of sensor
node five triggered up to two BFT-messages at each sensor node.

Figure 11: RSSI-values (blue) and BFT-messages (red) received by SN five
during experimental setup and median-kalman filter smoothed RSSI-values
(orange).

Given these results, it can be stated that the selected filter is suitable for
the test scenario and that the basic mechanics of PoL are implemented and
tested successfully:

  * •

RSSI-values can be measured and used to gain a stable image of the nodes’
location in the network, i.e. the network topology

  * •

Based on the RSSI-values, nodes can identify their peers

  * •

Manipulation of a node, resulting in transmissions from a different location,
can be recognised by its peers

  * •

BFT messages are emitted and received reliably, allowing the nodes to
communicate detected manipulation.

In consequence, the basic requirements for more comprehensive implementation
and evaluation of PoL are met.

##  VII Conclusion

###  VII-A Summary

Proof-of-location (PoL) is a new approach to enable secure communication in
IoT. It aims to identify maliciously or manipulated network participants based
on those devices’ location. PoL uses a new type of communication messages, so-
called BFT messages, to identify nodes and manipulations. With BFT messages,
nodes can reach a consensus – the PoL – on the nodes’ trustworthiness inside
the network. This paper presented PoL in detail and an approach for its
implementation. The first steps to develop PoL into a protocol have been
taken. Central parts of PoL have been implemented on prototypical IoT-
hardware, communicating via Bluetooth low energy. The implementation
identifies nodes based on RSSI-values and shows PoL’s usefulness and
feasibility as a light-weight protocol. Several experiments have led to an
adequate filter function, delivering reliable results using PoL. Emission of
BFT-messages in case of identification of manipulation attempts has been
implemented and successfully proven.

###  VII-B Future Work

The results presented in this paper show the fundamental feasibility of PoL.
Future research includes the complete implementation and formal verification
of the remaining communication processes described above. Further processing
of BFT and alert messages still needs to be implemented and evaluated.
Finally, an automatic adjustment, depending on environmental conditions, of
smoothing parameters in the filter function is desired. In this way, the
approach could adapt more easily to different environments.

## Acknowledgment

This research was performed within the project Watergridsense 4.0 and
supported by the German Ministry of Education and Research (BMBF Grant No.
02WIK1474B).

## References

  * [1]
  * [2] Statista, “Internet of things (iot) connected devices installed base worldwide from 2015 to 2025.” [Online]. Available: https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/
  * [3] F. A. Alaba, M. Othman, I. A. T. Hashem, and F. Alotaibi, “Internet of things security: A survey,” _Journal of Network and Computer Applications_ , vol. 88, pp. 10–28, 2017. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1084804517301455
  * [4] A. Hameed and A. Alomary, “Security Issues in IoT: A Survey,” in _2019 International Conference on Innovation and Intelligence for Informatics, Computing, and Technologies (3ICT)_. IEEE, pp. 1–5, 2019. [Online]. Available: https://ieeexplore.ieee.org/document/8910320/
  * [5] F. Meneghello, M. Calore, D. Zucchetto, M. Polese, and A. Zanella, “IoT: Internet of Threats? A Survey of Practical Security Vulnerabilities in Real IoT Devices,” vol. 6, no. 5, pp. 8182–8201, 2019. [Online]. Available: https://ieeexplore.ieee.org/document/8796409/
  * [6] U. Farooq, N. Ul Hasan, I. Baig, and N. Shehzad, “Efficient adaptive framework for securing the Internet of Things devices,” vol. 2019, no. 1, p. 210, 2019. [Online]. Available: https://jwcn-eurasipjournals.springeropen.com/articles/10.1186/s13638-019-1531-0
  * [7] L. Bornholdt, J. Reher, and V. Skwarek, “Proof-of-location: A method for securing sensor-data-communication in a byzantine fault tolerant way,” in _Mobile Communication-Technologies and Applications; 24. ITG-Symposium_. VDE, 2019, pp. 1–6.
  * [8] K. H. Wöhnert, S.-J. Wöhnert, T. Thiel, R. Weißbach, and V. Skwarek, “Secure cyber-physical object identification in industrial iot-systems,” _Procedia Manufacturing_ , vol. 51, pp. 1221–1228, 2020.
  * [9] C. D. Schultz, “A trust framework model for situational contexts,” in _Proceedings of the 2006 International Conference on Privacy, Security and Trust Bridge the Gap Between PST Technologies and Business Services - PST ’06_. Markham, Ontario, Canada: ACM Press, 2006, p. 1. [Online]. Available: http://portal.acm.org/citation.cfm?doid=1501434.1501494
  * [10] S. Flowerday and R. von Solms, “Trust: An Element of Information Security,” in _Security and Privacy in Dynamic Environments_ , S. Fischer-Hübner, K. Rannenberg, L. Yngström, and S. Lindskog, Eds. Springer US, vol. 201, pp. 87–98, 2019. [Online]. Available: http://link.springer.com/10.1007/0-387-33406-8_8
  * [11] A. Jøsang, “The right type of trust for distributed systems,” in _Proceedings of the 1996 Workshop on New Security Paradigms_ , ser. NSPW ’96. New York, NY, USA: ACM, 1996, pp. 119–131. [Online]. Available: http://doi.acm.org/10.1145/304851.304877
  * [12] ISO/IEC, “Iso/iec 23093-1:2020(en) information technology — internet of media things — part 1: Architecture.” [Online]. Available: https://www.iso.org/obp/ui/#iso:std:iso-iec:23093:-1:ed-1:v1:en:term:3.2.8
  * [13] J. R. Douceur, “The sybil attack,” in _Peer-to-Peer Systems_ , P. Druschel, F. Kaashoek, and A. Rowstron, Eds. Berlin, Heidelberg: Springer, 2002, pp. 251–260.
  * [14] L. Lamport, R. Shostak, and M. Pease, “The Byzantine generals problem,” _ACM Transactions on Programming Languages and Systems (TOPLAS)_ , vol. 4, no. 3, pp. 382–401, 1982.
  * [15] X. Oscar Wang, W. Cheng, P. Mohapatra, and T. Abdelzaher, “ARTSense: Anonymous reputation and trust in participatory sensing,” in _2013 Proceedings IEEE INFOCOM_. Turin, Italy: IEEE, Apr. 2013, pp. 2517–2525. [Online]. Available: http://ieeexplore.ieee.org/document/6567058/
  * [16] V. Skwarek, “Blockchains as security-enabler for industrial iot-applications,” _Asia Pacific Journal of Innovation and Entrepreneurship_ , vol. 11, no. 3, pp. 301–311, 2017.
  * [17] D. Drescher, _Blockchain Basics: A Non-Technical Introduction in 25 Steps_. Berkeley, CA: Apress, 2017.
  * [18] K. Heurtefeux and F. Valois, “Is rssi a good choice for localization in wireless sensor network?” in _2012 IEEE 26th International Conference on Advanced Information Networking and Applications_ , March 2012, pp. 732–739.
  * [19] H. Li and M. Singhal, “Trust Management in Distributed Systems,” _Computer_ , vol. 40, no. 2, pp. 45–53, Feb. 2007. [Online]. Available: http://ieeexplore.ieee.org/document/4085622/
  * [20] W. Stallings and L. Brown, _Computer Security: Principles and Practice_ , 4, New York, NY: Pearson, 2018, oCLC: 1024109104.
  * [21] International Standardisation Organisation, “ISO/IEC 29182-2:2013(en), Information technology — Sensor networks: Sensor Network Reference Architecture (SNRA) — Part 2: Vocabulary and terminology,” International Standardisation Organisation, Geneva, Switzerland, International Standard 29182-2:2013, 2013.
  * [22] W. Bulten, A. C. V. Rossum, and W. F. G. Haselager, “Human slam, indoor localisation of devices and users,” in _2016 IEEE First International Conference on Internet-of-Things Design and Implementation (IoTDI)_ , April 2016, pp. 211–222.