A Lightweight Blockchain-based Technique for Anti-Tampering in Wireless Sensor Networks

Full text

A Lightweight Blockchain-based Technique for Anti-Tampering in Wireless Sensor
Networks
Walter Tiberti∗, Alessio Carmenini†, Luigi Pomante∗, Dajana Cassioli†
∗DEWS Centre of excellence, DISIM, University of L’Aquila, L’Aquila, Italy. Email: {walter.tiberti, luigi.pomante}@univaq.it
†DISIM, University of L’Aquila, L’Aquila, Italy. Email: {alessio.carmenini@student., dajana.cassioli@}univaq.it
Abstract—Wireless Sensor Networks (WSNs) are nowadays
used in a variety of applications, to monitor relevant quantities
often in large and harsh environments, thanks to their flexi-
bility and versatility. Unfortunately, the nature of the wireless
communication channel exposes WSN nodes to security risks.
Conventional security countermeasures cannot be applied to
the WSN nodes due their resource limitations. In this paper,
we propose a lightweight blockchain approach to contrast
the physical or logical tampering of WSN nodes. We validate
our approach through experiments showing the performance
impact and the storage footprint due to the use of the proposed
blockchain anti-tampering technique. The proposed approach
appears to be suitable in the context of WSNs, although the
overhead generated by the blockchain depends on the number
of nodes in the WSN.
Keywords-Blockchain, Data Tampering, Anti-tampering,
Wireless Sensor Networks, TinyOS
I. INTRODUCTION
Wireless Sensor Networks (WSNs) consist of a large
number of nodes, named motes, equipped with a number
of sensors and provided with wireless connectivity. These
nodes have limited resources, i.e. energy, memory storage
and computational capacities. Thanks to their flexibility, and
the installation easiness, WSNs represent the best choice
for monitoring large and/or harsh environments. The nature
of the wireless communication channel makes the WSNs
vulnerable from active and passive attacks, which cannot be
prevented by implementing traditional security countermea-
sures, given the motes’ hardware limitations.
In particular, WSN motes are prone to both physical
and logical tampering. In the former case, the WSN node
is compromised with a physical modification (e.g. in its
hardware components) to break, misbehave or cause damage.
In the latter case, instead, the node is compromised in
its behaviour (e.g. by changing its firmware) so that it is
no longer behaving as intended. WSN software is prone
to vulnerabilities because the resource limitation causes
the software to be complex. Therefore, various software
engineering techniques are adopted to reduce the complexity
while improving the development process of WSN software
as, for example the use of middleware [13].
To limit the effects of the tampering it is very important
to detect the compromised nodes and prevent the spread of
the attack towards other nodes. Various tampering solution
are proposed in the literature to detect or limit the effects
of tampering. The physical tampering of a mote can be
detected by using an interrupt-based technique through a
low-cost trigger device as proposed in [1]. However, this
technique requires the node to perform various checking
procedures to reveal the tampering that may have side-effects
on performances. In [2] the authors propose the use of the
Integrated Circuit metrics (ICmetrics) for the computation
of metrics based on hardware and software characteristics.
These metrics are used to generate dynamic cryptographic
keys (used for encryption) which, in case of tampering,
change. Unfortunately, in the absence of other precautions,
an attacker can still perform sniffing and spoofing attacks.
In [3] Unpredictable Software-based Attestation Solution
(USAS) is presented, which is an evolution of Software-
based Attestation for embedded devices (SWATT) [4]. USAS
is an algorithm for compromised nodes detection with the
use of a hierarchical RC4-based pseudo-random number
generator, which starts from a Initiator node (I-node) and
continues on multiple Follower nodes (F-nodes). To detect
tampering, the Base Station (BS) requests the I-node to
perform a random challenge involving a checksum compu-
tation. The result of the computation is used to generate
a series of new random challenge messages for F-nodes.
The checksum results should be verified by the BS for the
compromised nodes’ detection. Both USAS and SWATT
introduce an overhead that can reduce the lifetime of the
motes. In [5] the authors propose the use of Parameter
Grouping for the detection of compromised nodes. Although
the idea is valuable, there is a drawback: the whole test is
conducted in a simulated environment where key parameters,
like e.g. residual node energy, are provided by the simulator,
whereas in a real environment these measured parameters
could have been altered by the attacker.
In this paper we propose a novel technique based on
a lightweight blockchain to empower a WSN coordinator
with the ability to detect compromised nodes. Our approach
is suitable to be utilised in constrained nodes, as WSN

motes, because it does not introduce a significant overhead
in both the messages and memory occupation. Nevertheless,
it guarantees a good level of protection of sensitive data and
nodes operations in mission-critical operations. We focus
on WSN based on the IEEE 802.15.4 standard, which
offers increased capabilities, reduced energy consumption
and features useful in e.g., industrial WSN [16].
In order to offer a complete WSN solution, the proposed
technique can be adopted in conjunction with other solutions
targeting cryptographic services (e.g., [15] and [14]) and
intrusion and attack detection techniques (e.g., [17] and
[18]).
The rest of the paper is organised as follows: in Section
II we describe the proposed system model in terms of
network and software architecture, message format and the
procedures for checking and detecting compromised nodes.
In Section III we show an examplary implementation of
our technique using the TinyOS operating system for WSN.
Finally, in Section IV we present the validation of our pro-
posed technique applied to a common monitoring application
deployed on a WSN, by discussing its performance in terms
of overhead and latency.
II. PRO PO SE D SYS TE M MOD EL
We consider a WSN consisting of several motes and a sink
node, which acts also as PAN Coordinator of the WSN and
serves as the gateway towards the external network(s). In
monitoring applications, the sink mote collects and stores
the data received from other nodes in the WSN before
forwarding them to other networks.
In order to build a secure and flexible communication en-
vironment in this scenario, we use blockchains. A blockchain
is a data structure which exploits hash computations to
provide an immutable and tamper-resistant storage [6].
The proposed software architecture of the WSN motes is
shown in Figure 1.
Figure 1. UML model of the software architecture of the WSN motes.
We use a set of blockchains by means of a Ledger located
in the sink mote. The Ledger is the software component
responsible of the following tasks: message checking,man-
agement of the blockchains, and data storage.
The message checking is performed by means of a Hash
Function component and a timestamp reader component.
The hash function provides the Ledger and the applications
with a method to compute cryptographically-secure hashes.
The timestamp reader is used to compute the time intervals
from a local timer.
The Ledger stores a set of multiple blockchains. Due
to the memory limitations of the WSN nodes, the size
of each blockchain has to be a fixed (and usually small)
value. Considering that sink motes act as bridges towards
traditional networks forwarding (hence, consuming) the data
gathered by the device nodes, we decided to implement a
time-windowing approach with a circular-buffer mechanism
so that we replace obsolete data (which probably has already
been forwarded) with the fresh incoming data. In this way,
we can still store (and verify) data into small and fixed-
length blockchains, overcoming the resource constraints of
WSN motes.
The blockchains are ordered according to the decreasing
reliability of the data they store (i.e., the first contains high-
reliable data while the last contains data with low reliability).
The concept of reliability of WSN nodes and their data is
a central aspect of our technique. We dynamically assign
areliability level (via reliability points) to WSN device
motes which determines the blockchain that the Ledger
has to use to store node data. A node with reliability
points below a given threshold, can get its messages refused
and discarded systematically by the sink node (until WSN
operators action/verification). Reliability points are increased
or decreased depending on the result of the Ledger message
checking. The thresholds and the amount of points increased
or decreased can be selected depending on the application
and on the security requirements.
In summary, the operation of the Ledger is as follows.
Upon the reception of a message, the Ledger:
1) Checks if the sender is considered reliable in terms of
reliability points. The reliability points are represented
by a value assigned by the Ledger to each WSN mote.
The value gets increased (or it is kept constant) when
the WSN mote sends a valid message; it is decreased
otherwise. If the sender is not reliable, its messages
are discarded without any further processing.
2) Authenticates (by verifying the signature) and decrypts
the contents of the received messages.
3) Performs the Hash check: the hash of the last de-
crypted legit message from the same source is com-
pared with the hash contained in the message. If they
differ, the reliability points of the source are decreased.
4) Performs the Time check: the time elapsed from the
last message from the same source is computed by
both the sender and the Ledger. The Ledger checks
whether these time intervals differ by more than a
selected threshold. In this case, the reliability points
of the source are decreased.

5) once the reliability points are updated, the Ledger
assigns the sender mote to a blockchain. If the node’s
reliability points fall below a given threshold, the
Ledger denies the access to the blockchains. If not,
the message is stored in the proper blockchain.
6) Updates the hash value and the time interval to be
expected in the next message by the sender mote with
the hash computed on the current message.
The above described mechanism allows us to provide both
anti-tampering features to the application data (as any other
blockchain-based mechanism) and to the motes of the WSN
themselves. In particular, our approach allows the detection
of a mote that is physically tampered by an attacker, or
injected into the WSN. In fact, actions like these cause the
mote to send messages which hardly pass the Ledger checks.
According to the Ledger operation described above, the
three cases of interest shown in Figure 2 may occur:
Figure 2. System Model.
1) the Mote 1 sends to the sink mote a valid message,
i.e. the hash and timing checks are successful, thus
its message contents are accepted. Subsequently, the
reliability points of Mote 1 are increased or kept
constant and its data is stored in a high-reliability
blockchain.
2) the Mote 2 sends a message which contains a wrong
prevHash and/or a bad time interval. So, the mes-
sage is refused and the reliability of Mote 2 decreases,
eventually causing the coordinator to start storing
Mote 2’s data into a blockchain of lower reliability;
3) the Mote 3 is already classified by the Ledger as
having a very low reliability, hence when it sends
a message which contains a wrong prevHash or
a bad time interval, the message gets refused. Since
Mote 3’s reliability cannot decrease further, i.e. its
messages cannot be trusted anymore, from now on its
communications with the sink mote will be discarded.
The message format adopted for communication is shown
in Figure 3. It is built on top of the IEEE 802.15.4 MAC
to increase data density and to provide the proposed fea-
tures both directly to WSN applications and to higher-level
protocols (e.g. ZigBee [7]).
Figure 3. Proposed message format
The message contains:
•the ID of the sender mote;
•anonce value;
•a generic payload field, freely usable by the applica-
tion/higher layer;
•the prevHash
•the time interval
•a cryptographic digital signature computed on the mes-
sage.
The sender ID is assigned to the source WSN mote during
the programming step.
The nonce field is a pseudo-random values obtained by a
cryptographically-secure pseudo-random number generator
(CSPRNG) used to avoid replay-attacks by forcing each
message to being different even with the same content.
The application payload field is an application-specific
field, which can be used by applications to carry the data of
interest.
The prevHash is part of the main anti-tamper mechanism:
the sender has to fill this field with the hash of its last
un-encrypted message. The receiver (which should track
the prevHash field, for every received message) checks the
field against its stored hash to determine the validity of the
message. In this way, an attacker who wishes to forge a valid
message or perform a spoofing attack, has to know every
previous message hash (down to the first message ever sent
by the victim node) to successfully craft a spoofed message.
Also, the attacker has to know both the cryptographic keys
used respectively to encrypt the data and to sign the message.
Otherwise the message will be incorrectly deciphered or
refused.
In order to provide an additional anti-tampering measure,
we use the time interval field. Together with the hash
calculation, each sending node has to keep track of the
intervals between the message it sends and to fill this field
by using its local free-running timer. On the other hand,
the receiver node does the same, keeping track of the
received messages by using its timers. Even if computed
with two un-synchronized timers, the time difference should
be negligible, and the receiver checks whether this happens
to be. In this way, an attacker needs also to synchronize with
the victim node timer and estimate when (according to this

Figure 4. UML model of the implementation (NesC components) of
proposed technique.
timing) the last message has been sent. This security measure
is not strong as the previous, but it adds an additional barrier
to deter attackers.
The cryptographic digital signature is obtained by a dig-
ital signature protocol taking the message contents as input.
The signature allows the receiver to authenticate the sender
and detect malicious attempts in modifying the message
content.
All the fields described above are encrypted by the sender
and decrypted by the receiver. Our proposed approach uses
the Advanced Encryption Standard (AES) with a key length
of 128 bits and the CCM* mode of operation, in compliance
with the IEEE 802.15.4 [8]. An alternative is to adopt WSN-
specific encryption schemes (e.g., [15] and [14]) which
provide a more complete solution for distributing keys,
encrypting, and authenticating messages.
III. IMPLEMENTATION
The proposed technique has been implemented using the
TinyOS operating system [9]. TinyOS provides a hardware-
independent software layer which can be used to write WSN
software applications for multiple WSN mote hardware
platforms at once. TinyOS and TinyOS-based applications
can be written with the NesC programming language [10], a
C language dialect with additional features (e.g. event-based
programming, split-phase operations, tasks etc.).
The system model components are mapped into NesC
components as shown in the UML component diagram
depicted in Figure 4.
The Ledger functionalities have been implemented though
a new NesC component called LedgerC. The LedgerC
component provides the LedgerI interface, which can be
used by the higher software layer or by the application
to access the proposed platform features. In our case,
we selected the well-known SHA 2 (256bit) cryptographic
hash function, which is still considered extremely secure at
the time of writing. The SHA256 digest computation has
been re-implemented in a new separated component, named
SHA256C. This component provides the HashFunctionI
Figure 5. The scenario adopted for validation of the proposed technique.
interface, used both by the Ledger and the application to
compute hashes.
We consider TinyOS-based applications, hence we
use the LocaltimeMicroC component as Timestamp
Reader component. The LocaltimeMicroC is a TinyOS
hardware-independent component, which can be used to
retrieve the value of a free-running hardware timer with the
resolution of one micro-second.
The implementation described in this section is available
and freely usable in the author’s GitHub page [11].
IV. RES ULT S AN D DISCUSSION
A. Validation
The proposed approach has been validated in the scenario
shown in Figure 5. We used a total of four WSN motes,
three device motes equipped with light sensors and one
mote acting as the sink mote. Every device mote periodically
retrieves a selected number of samples from the light sensor.
When a sufficient number of samples is collected, a new
message is created according the format defined in Section 3
and is sent to the sink mote. The sink mote, using the Ledger
component, performs the checks and provides as output (via
serial port) the results and some additional auditing/logging
information. The validation results are shown in Figure 6
and Figure 7. In the case of a mote sending valid messages
the results of message and timestamp checking are shown
in Figure 6. Then we simulate an attack in which the mote
gets stolen, re-programmed and re-injected into the WSN.
We obtain the results shown in Figure 7 for and the tampered
mote (Mote 1) sending invalid messages. Hence, in the
presence of an attack, our approach detects immediately the
tampered mote.
B. Performance Evaluation
We evaluate the impact on performance and the stor-
age footprint of the proposed approach in terms of the

Figure 6. Well-behaving motes: hash checks and time interval checks are
successful for the device motes
Figure 7. Mote 1 simulate a bad behavior and its messages gets refused,
causing it to lose reliability and the right to store its data inside the sink
mote
following metrics: the increment of the Flash and RAM
memory occupation on device and sink motes due to the
introduction of our blockchain technique, and the average
Latency introduced in the communications.
The metrics defined above have been evaluated through
18 different scenarios (first column of Figure 8), varying the
following configurable parameters:
•The number of motes in the WSN (3, 5 or 10)
•The length of each blockchain in the ledger in terms of
number of stored data blocks (3 or 5)
•The number of different blockchains in the ledger (2,
3 or 4)
The tests have been conducted using as test platform the
Memsic Iris motes [12], both for device motes and for the
(only) sink mote. Note that, in a real WSN deployment, there
are usually more than one sink mote, which are deployed
using more powerful and capable platforms.
In order to evaluate the metrics (and in particular the
latency), the WSN motes have been programmed with a
monitoring application consisting of two motes exchanging
messages. Each mote retrieves a fixed number of samples
from the light sensors, starts a timer and sends the message
to the sink mote. Upon reception, the destination mote
checks the message, stores it in its blockchains and sends
a replay message back to the sender. When the replayed
message reaches the sender, this latter stops its timer and
retrieves the round-trip time. The latency has been then
computed by halving such value. Flash and RAM memory
occupations are available directly from the TinyOS compi-
lation toolchain when compiling the code.
We evaluated all scenarios, obtaining the results shown
in Figure 8 for the sink motes. The resulting overheads
are computed as the increments with respect to the same
monitoring application compiled without using our proposed
approach, which represents the reference benchmark perfor-
mance.
In Figure 8, the fifth column shows the overhead in Flash
memory (i.e. executable code), which is also expressed in
term of percentage in the sixth column. The seventh and
eighth columns show instead the overhead in RAM memory
(i.e. data) as relative value and percentage.
The results show that:
•the Flash memory occupation for the sink mote has
only a very small variation across the scenarios (less
than 40 bytes) hence the overhead is stable at the 40%.
•the RAM occupation, instead, can grow very fast. The
growth is due to the use of RAM as data memory, so,
it is sensible to the number of message storable in each
blockchains and the number of blockchains.
•since rarely the WSN mote software uses a dynamic
memory allocator, all the space needed is pre-allocated.
This causes the number of motes in the WSN to be the
direct factor of the RAM increase.
•It was not possible to test Scenarios 12, 14, 15, 16,
17 and 18 for the latency due to the amount of RAM
required, which is more that the available in the test
platform (8 KB).
Figure 9 shows the memory occupation overhead in a
device mote. Those motes need only to construct a valid
message to communicate with the sink mote and are not
required to store data. The overhead of device motes is less
than ∼13% for the Flash memory and ∼43% for the
RAM occupation. Notice that, since the device motes need
only to be able to sample sensors, construct a valid message
and send it to the sink mote, their memory occupation is
independent from the metrics of our proposed technique.
In conclusion, we can state that, although the proposed
approach requires a more capable sink mote platform to
support a significant number of WSN motes, the overhead
in both performance and memory in common WSN device
motes is negligible, making the proposed approach very
efficient and lightweight even in large WSN.

Figure 8. Results: sink mote (containing the ledger)
Figure 9. Results: device motes
V. CONCLUSION
We proposed an approach based on blockchains to prevent
the physical or logical tampering of WSN nodes. The WSN
coordinator exploits a Ledger to track the activity of WSN
nodes. We measured the overhead generated by the use
of the blockchain approach in real experiments with a
variable number of nodes. We have shown that the overhead
generated can be managed by the resource-constrained WSN
nodes, thus the proposed approach represents a valid and
suitable anti-tampering technique. Finally, this technique can
be adopted in conjunction with other solutions targeting
cryptographic services (e.g., [15] and [14]) and intrusion
and attack detection techniques (e.g., [17] and [18]) to offer
a complete secure WSN solution.
ACKNOLEDGEMENT
This work was partially supported by the Regional Fund
POR FESR Abruzzo 2014-2020, Formal Concession no.
RA/184629/18 (June 28, 2018), project CYBER TRAINER.
REFERENCES
[1] H. Nunoo-Mensah, K. O. Boateng, and J. D. Gadze. Tamper-
aware authentication framework for wireless sensor net-
works. IET Wireless Sensor Systems, 7(3):73–81, 2017.
[2] R. Tahir and K. McDonald-Maier. Improving resilience
against node capture attacks in wireless sensor networks
using icmetrics. In 2012 Third International Conference on
Emerging Security Technologies, pages 127–130, Sep. 2012.
[3] X. Jin, P. Putthapipat, D. Pan, N. Pissinou, and S. K.
Makki. Unpredictable software-based attestation solution for
node compromise detection in mobile wsn. In 2010 IEEE
Globecom Workshops, pages 2059–2064, Dec 2010.
[4] A. Seshadri, A. Perrig, L. van Doorn, and P. Khosla. Swatt:
software-based attestation for embedded devices. In IEEE
Symposium on Security and Privacy, 2004. Proceedings.
2004, pages 272–282, May 2004.
[5] Manyam Thaile and OBV Ramanaiah. Node compromise
detection based on parameter grouping in wireless sensor
networks, 2016.
[6] D. Puthal and S. P. Mohanty. Proof of authentication: Iot-
friendly blockchains. IEEE Potentials, 38(1):26–29, Jan
2019.
[7] Zigbee alliance homepage. https://zigbee.org/.
[8] Ieee standard for low-rate wireless networks. IEEE Std
802.15.4-2015 (Revision of IEEE Std 802.15.4-2011), pages
1–709, April 2016.
[9] Tinyos homepage. http://www.tinyos.net/.
[10] Nesc language repository.
https://github.com/tinyos/nesc.
[11] Proposed technique (wsnlbc) github page.
https://github.com/wtiberti.
[12] Memsic iris hardware manual.
http://www.memsic.com/userfiles/files/
User-Manuals/iris-oem-edition-hardware-
ref-manual-7430-0549-02.pdf.
[13] Corradetti, L., Gregori, D., Marchesani, S., Pomante, L.,
Santic, M., Tiberti, W. A renovated mobile agents mid-
dleware for WSN porting of Agilla to the TinyOS 2.x
platform. IEEE 2nd International Forum on Research and
Technologies for Society and Industry Leveraging a Better
Tomorrow, RTSI 2016.
[14] Pomante, L., Pugliese, M., Marchesani, S., Santucci, F.
WINSOME: A middleware platform for the provision of
secure monitoring services over wireless sensor networks.
9th International Wireless Communications and Mobile
Computing Conference, IWCMC 2013, art. no. 6583643.
[15] Marchesani, S., Pomante, L., Pugliese, M., Santucci, F. Def-
inition and development of a Topology-based cryptographic
scheme for wireless sensor networks. Lecture Notes of
the Institute for Computer Sciences, Social-Informatics and
Telecommunications Engineering, LNICST, 122 LNICST,
pp. 47-64.
[16] W. Tiberti, B. Vieira, H. Kurunathan, R. Severino and E.
Tovar, ”Tightening Up Security In Low Power Deterministic
Networks,” 2020 16th IEEE International Conference on
Factory Communication Systems (WFCS), Porto, Portugal,
2020, pp. 1-7, doi: 10.1109/WFCS47810.2020.9114520.
[17] I. Letteri, M. Del Rosso, P. Caianiello, and D. Cassioli,
”Performance of Botnet Detection by Neural Networks in
Software-Defined Networks” Proc. of ITASEC 2018.
[18] Pomante, L., Pugliese, M., Tiberti, W., Bozzi, L., Santic,
M., Santucci, F. & Di Giuseppe, L., (2018). TinyWIDS:
A WPM-based Intrusion Detection System for TinyOS 2.x
/802.15.4 Wireless Sensor Networks. In Proceedings of the
HiPEAC Conference CS2.