1

Blockchain based trust & authentication for

decentralized sensor networks
Axel Moinet, Benoit Darties, and Jean-Luc Baril,

Abstract—Sensor networks and Wireless Sensor Networks (WSN) are key components for the development of the Internet of Things.
These networks are subject of two kinds of constraints. Adaptability by the mean of mutability and evolutivity, and constrained node
resources such as energy consumption, computational complexity or memory usage. In this context, none of the existing protocols and
models allows reliable peer authentication and trust level management. In the field of virtual economic transactions, Bitcoin has
proposed a new decentralized and evolutive way to model and acknowledge trust and data validity in a peer network by the mean of
the blockchain. We propose a new security model and its protocol based on the blockchain technology to ensure validity and integrity
of cryptographic authentication data and associate peer trust level, from the beginning to the end of the sensor network lifetime.
arXiv:1706.01730v1 [cs.CR] 6 Jun 2017

Index Terms—Bitcoin; blockchain; wsn; authentication; trust management.

1 I NTRODUCTION

S ENSOR Networks and Wireless Sensor Networks (WSN)

are two main components involved in the development
of the Internet of Things (IoT). Security and privacy han-
1.1.2 Blockchain as a secured data structure
Recent work by Zyskind et al. [3] shows the interest of
the blockchain as a personal data management platform
dling for Sensor Networks present new issues due to specific focused on privacy. They outlined how the blockchain helps
constraints. Low resources on computation, hardware func- leveraging user control over data in the context of social
tionalities and energy consumption in WSNs. We can divide networks and big data. Foutiou et al. [4] describe a decen-
research work into two categories: security and privacy for tralized name based security system using blockchains to
the data being sent over the network on one side, and node secure contents access in Information-Centric Networking
authentication and trust management on the other side. based architectures. These approaches prove usability of
Both have been actively explored the last ten years, and the blockchain as a secure decentralized data structure for
some solutions have been brought by researchers. However, new applications, but none has been used to provide node
from our knowledge none of these works propose a com- authentication and trust management in Wireless Sensor
plete model for both content access, security, privacy and Networks (WSN) and in the Internet of Things (IoT).
trust management. In this paper, we focus on addressing
authentication and trust management issues.
1.2 Our Contribution
We propose a model based on blockchain data structure
1.1 Overview
used to store decentralized authentication and node trust
During our researches, we have separated existing work informations. This model is evolutive, adaptative and en-
into two distinct research areas. The first one is authentica- sure reliability over time.
tion and trust management issues in decentralized networks
and WSN. Then we consider ongoing work on blockchains
1.3 Organization
and their applications.
We first explain briefly the blockchain data structure as pre-
1.1.1 Authentication and trust for decentralized networks sented in Bitcoin. Then we present issues in decentralized
We can find a lot of different approaches for authentica- node authentication and trust management for WSN. The
tion in WSN and the IoT in the literature. As outlined last part of this paper describes our model of a blockchain
by Medaglia et al. [1], WSNs have specific security con- based solution for authentication and trust management
straints on node authentication to ensure data validity and which provide a solution to overcome decentralized net-
confidentiality. Trust management is tied to authentication works issues.
mechanisms, as a the mean to identify the trustee and
the truster. We take previous work on trust evaluation in 2 T HE BLOCKCHAIN TECHNOLOGY
distributed networks by Sun et al. [2], as a reference on
In 2008, a person or group of persons known under the
issues concerning trust in decentralized networks for our
name of Satoshi Nakamoto published a paper [5] deal-
work.
ing with a new decentralized peer-to-peer electronic cash
• Axel Moinet, Benoı̂t Darties and Jean-Luc Baril are from the Le2i labora- system. This paper introduces the blockchain as a new
tory, FRE CNRS 2005, Univ. Bourgogne Franche Comté. data structure to store financial transactions, as well as an
E-mail: [email protected] associate protocol to ensure the validity of the blockchain in
Manuscript received February 1, 2017; revised February 1, 2017. the network.
2

2.1 Data structure

Magic no Data payloads
In his paper, Nakamoto describes the blockchain as a Blocksize
Payload 1
database modeled by a linear sequence of blocks, each Blockheader
one containing cryptographic hashes corresponding to the Version
previous and current block to ensure continuity and im- Hashpreviousblock
Root hash of payloads
Hashmerkleroot
mutability. Bitcoin uses the blockchain to store financial Time
Merkle tree Payload 2
transactions and contracts. Bits
Nonce
blockheader blockheader Payloads count
Version Version
Hashpreviousblock Hashpreviousblock
Hashmerkleroot Hashmerkleroot
2
Time SHA-256 Time
Bits Bits
Nonce Nonce Fig. 2. Blocks used as generic storage. We use structured payloads and
replace transactions by payloads in the Merkle root hash computation.
Block 1 Block 2
Magic no Magic no
Root hash of transaction
Blocksize Merkle tree Blocksize
Root hash of transaction
Blockheader
Transaction count
Merkle tree
Blockheader
Transaction count
3 AUTHENTICATION AND T RUST IN WSN
Transactions Transactions
Authentication and trust can be seen as two parts of the
Version Version Version
same problem [7]. Authentication allows us to be sure to
In counter
List of inputs
In counter
List of inputs
In counter
List of inputs
who we are dealing with, trust giving us insights of how we
Out counter Out counter Out counter
List of outputs List of outputs List of outputs can rely on and dealing with a potential risk on an action. If
Lock time Lock time Lock time

transactions
we consider the presence of a master authority in charge of
authentication and trust management, we can easily ensure
Fig. 1. Bitcoin block chaining mechanism. The Merkle root of all transac- a good security and privacy level in the network. However,
tions is included in the block header and then used as input for the next this has a major drawback, the master authority becomes
block in the chain. the central part of the network security and thus the critical
point of vulnerability in the network. In decentralized and
The chaining method used in Bitcoin (Figure 1) ensures ad-hoc networks, this approach is impossible, because we
the immutability by using the hash of the previous header don’t have a node which can assure to be connected at every
block hash in the current block. The header includes the root moment of the network life.
hash of the Merkle tree of all transactions in the block. This
way transactions cannot be changed without changing the
root Merkle hash and then invalidating the block. Due to 3.1 Our Framework
the way the blockchain is built, fork chains can append with To ensure proper organization and content management in
different valid blocks storing different transactions. The decentralized networks, we use a common content model
Bitcoin protocol resolves this issue by selecting the longest based on Service Oriented Architecture [8] adapted for our
blockchain as the correct one. Note that due to this choice, application and compatible with CoAP protocol [9]. This
even after being included in a valid block, transactions can approach allows us to design a RESTful model for inter-
be considered valid only after a subsequent block has been action with the internet, and his currently outlined at one
calculated and successfully included in the blockchain by promising approach to organize sensor networks [10].
the majority of the network [6].
3.1.1 Network services model
Before further introspection on our blockchain based model,
2.2 Secure distributed storage based on blockchains we must define the network model we use. Wireless Sensor
We consider the blockchain data structure outside of its Networks can be well described as decentralized networks
application in Bitcoin, as a generic decentralized secured composed of resource constrained nodes based on embed-
data storage structure. It is possible to use any data payloads ded devices. We choose to model the network as an undi-
other than transactions as parts of the block. The block is rected graph G = (V, E), each vertex describing a node in
then divided in two parts, (a) the block constants and header the network, and each edge links two nodes within trans-
and (b) the data payloads, as shown in Figure 2. mission range from each other. Then we associate abilities
A single modification in one payload of a block will and services to nodes, providing resources on the network.
change its Merkle root hash value, and then invalidate In this model we define two entities formalized as a set of
it. This solution thus provides secure and reliable storage characteristics vectors.
distributed among all peers in the network. Note that this • Network Node (NN) defines a vector of Node Prop-
implies that the complete blockchain and all datas linked to erties (NP) and another of Node Abilities (NA)
it must be duplicate on all peers. The size of data payloads
will influence both the hash calculation algorithm and band-
N P = name energy cpu
width used to maintain the blockchain. Due to bandwidth NN = (1)
N A = camera storage
restriction in the platform we use, we choose to limit the
total size of a block to 5 MB to ensure we have enough stor- • Available Services (AS) defines an Abilities Depen-
age for important security and trust informations without dencies (AD) vector, a Resources Dependencies (RD)
overloading the network with blockchain control data. vector and a Resources Provider (RP) vector
3

Require: currentblock previousblock

  Ensure: block validity
AD = camera storage
1: if not(HashCurrentBlock resolves problem) then
AS =  RD =  (2)
2: return false
RP = videostream videorecording
3: end if
Each node stores services in a Service Registry (SR). 4: if not(MinerApproval payload valid) then
Nodes having the storage ability can store services they 5: return false
cannot deploy to ensure reuse of these services in the future 6: end if
on other nodes. 7: if CurrentBlock has event payload for miner NN then
In the next section, we refer to our service model and 8: return false
related abbreviations to describe our solution providing 9: end if
authentication and trust management mechanisms for de- 10: if not(all payloads in block valid) then
centralized networks. 11: return false
12: end if
13: return true
4 B LOCKCHAIN AUTHENTICATION AND T RUST
M ODULE (BATM) Fig. 3. Block validity check algorithm.
Public Key Infrastructure (PKI) is a major component to
resolve authentication in networks. In 1991, Zimmerman
secondary keys. We ensure key renewal to mitigate attacks
introduce a new concept named web of trust for his Pretty
known for guessing keys by using key validity timeouts.
Good Privacy (PGP) encryption program [11], which was
As network security and privacy relies on informations
then standardized by the IETF under the OpenPGP name.
contained in the blockchain, our design forbid to add blocks
Current version of the standard is described in RFC 4880
uniquely by resolving the problem and satisfy header hash
[12]. OpenPGP use PKI to provide three main functionali-
requirement. More precisely, only authenticated nodes can
ties.
mine new blocks, and only if they haven’t issued a payload
• Confidentiality with Encryption to be included in the block. To fullfill these requirements,
• Authentication via Digital Signature miners must choose which payloads to include in the block
• Web of Trust via identity validation from peers they try to resolve.
To be valid, a block must both resolves the problem and
BATM proposes a new way to achieve these goals using contains a valid Miner Approval (MA) payload generated
the blockchain as the database to store public keys, digital by the Miner, illustrated by the algorithm in Figure 3. This
signature and peer informations, allowing each component kind of payload contain a digital signature of a random
of the network to validate informations about every other value contained in the previous block MA payload, and
node in the network. must correspond to a successfully authenticated node.
This section explains the global design of BATM in
regard to three aspects. First, we focus on authentication, 4.1.2 BATM data payloads
public keys, block mining and their mutual influence. Then
When a NN or AS requests to join the network for the first
we explain principles and particularities of the block ex-
time, it issues a specific Credential Payload (CP) to all NNs.
change protocol and associate rules. Finally, we describe
A CP contains public keys needed to operate in the network.
how the combination of authentication and protocol rules
Authentication request is approved when an authenticated
allows to define a trust management model.
NN includes the CP in a valid block.
Credential status of the NN / AS can be subsequently
4.1 BATM authentication updated by renew payload and revoke payload. Note that
BATM associates cryptographic keys with each NN and when revoking his credential, a NN / AS must provide
AS in the network. We use the idea contained in the PGP a new credential payload to remain authenticated in the
model of a master key to identify a NN or AS among its network. Miners will try to include revoke payload and new
lifespan. This key is only used to generate secondary keys credential payload in the same block to ensure continuity of
for encryption and digital signature. As in most PKI, private node status in the network.
keys are the main component of the system, and so key If we allow submission of payloads without further ver-
management is particularly critical. An attacker can easily ification, every node could be allowed to propose payloads
spoof NN identity if he retrieves its keys. In this regard, in the network. To overcome this issue, payloads use a
implementations will need to be careful in the choice of system of signed hash digests. Every payload must have
the keyring to store private keys, but we won’t address this a hash digest signed by payload issuer as its last entry. This
issue in this paper. way, our payload verification algorithm can easily check
the validity of the data. Note that revoke payload use the
4.1.1 BATM block mining master key to sign data hash, whereas other payloads use
the current signature subkey.
We assimilate each data payload as an event providing
BATM uses 6 different payload types as follows.
informations about the status of a NN and its cryptographic
informations. At authentication, a node submits a creden- • MA (Miner Approval)
tial payload containing its master public key along with • NN and AS Payloads
4

Miner approval Credential Payload

a trust center. Following development will be targeted at
Miner NN UUID Entity UUID NN trust evaluation, but same principles apply to AS, with
ExtraNonce Master pubkey
PreviousBlockRandSign PubSubKey
the particularity that AS reputation level is echoed on each
PubSubKeyRenewBlockID SignedPayloadHash node in the network, thus modifying reputation level on
SignedPayloadHash
each node using it.

Renew Payload Blame Payload Revoke Payload For each payload type, HKT defines events and asso-
Entity UUID Entity UUID Entity UUID
ciates them reputation factors. We note Cevt the reputation
OldPubSubKey DefectiveNNUUID RevokedPubKey factor for the event, and Tevt the time the event occured.
NewPubSubKey BlameBlocksID SignedPayloadHash
SignedPayloadHash SignedPayloadHash
To make the NN reputation evolve naturally over time,
each event reputation factor must be weighted by a function
evolving in time since the event occurs. As we want to
decreasing contribution of a particular event to the NN
Fig. 4. Data payloads available in BATM. All blocks must have a Miner reputation level over time, we need to use a continuous
Approval payload to be valid, to verify which node has allowed the decreasing function such as e−x .
authentication entry.
During it first authentication, a NN has no passed action
to compute a reliable trust value. Thus we choose to grant
– Credentials a base trust value to all nodes when a trusted node gives
– Renew them access to the network by including their credentials in
– Blame the blockchain.
– Ban For the simulations, we used the following values for
– Revoke event reputation factors.

We provide a detailed description of data contained in • Capproval = 1

BATM payloads in Figure 4. Note that Blame and Ban pay- • Cauth = 8
loads are specific payloads used in BATM trust management • Crenew = 2
model. • Cblame = −8
We showed how our model of a PKI using the blockchain • Cban = −16
ensure reliable storage for cryptographic material, and how We have estimated the following formulas to determine
we use it to perform NN authentication on the network. We the reputation of node over time.
then propose a trust management model using informations
contained in the blockchain. X
∀evt ∈ (N, Blk(t)) : CN,t = Cevt (3)
4.2 BATM trust management t=tnow
X −(tnow −t)
The first need for a definition of trust originated from Reputation(N, tnow ) = Cauth + CN,t ∗ e 256

social studies to characterize relations between people in t=tf irst

the society. In this context, we consider relevant to use (4)
Gambetta’s definition of trust [13] as an assumption on the In this formula, tf irst corresponds to the first block in
level of subjective probability about how a particular agent the blockchain after node has authenticated. Ct is used as
will perform an action from a subjective point of view. Note the global coefficient for all events concerning the node at t
that we understand the term of subjective probability as a (the sum of all Cevt at t).
reputation level applied to the realization correctness of a
subsequent action in the future. 4.2.2 Trust evaluation
This interpretation of trust implies that the reputation As we defined it earlier, we consider trust as a probability
level associated with an agent must vary over time to match level that an action will be performed correctly by a NN.
the actual realization of the action. Good behaviour must be In this context, we perform trust evaluation by comparing
rewarded, and bad behaviour must be punished to maintain the current reputation level of a NN to trust him doing
accurate prediction on the realization of actions. certain actions in the network. Currently, we only defined
blockchain related actions and associate them with a trust
4.2.1 Knowledge based trust for BATM level Aevt . This level quantifies the minimum reputation
level for a node to be trusted to fullfill subsequent event evt.
The BATM module includes a trust model called Human-
The trust level is weighted by the number of authenticated
like Knowledge based Trust (HKT), based on human like
NN noted Nauth , in order to be less restrictive on actions in a
behaviour to maintain a reputation level for each node. HKT
small network and more on huge networks. This behaviour
is a compromise between a mutual surveillance by all nodes
allows NN on the network to work properly and becoming
on the network and the presence of a trust center.
trust defaultive in small network, and then raise the trust
We use the payloads contained in the blockchain as an
level required when more nodes are available.
indication of each node behaviour on the network over
BATM defines the following trust levels, as equivalent
time. This way, we ensure a node cannot fool others by
for trust events Cevt described earlier.
tampering data or pretending to be someone else. Thus we
ensure reliability of trust evaluation without the need of • Aauth
5

• Tbanrecover is the time during which a banned NN

will be forbidden to mine subsequent block as pun-
ishment for a bad behaviour in the network.
These timers imply that key validity timeouts must
respect the following rules for BATM to work properly.
• Tsubkey is the timeout for subkeys before renewal. It
must be greater than Trenew , but less than 50∗Trenew
to be overcome issue that an attacker may be able to
guess the key from data collected in the network.
• Tmasterkey is the timeout for the master key. In our
model, it should be greater than 10 ∗ Tsubkey and no
more than 50∗Tsubkey to protect it from key guessing
attacks.
As indication, simulation results showed in Figure 5
used following timer values, in hours.

Fig. 5. Reputation level simulation over 500 hours with 3 NN. After 2 • Trenew = 168
blames, a ban is declared on the node and becomes effective for a 84 • Tblame = 42
hours. • Tbanrecover = 84
As these rules can be defined to different values regard-
• Aban ing the application using BATM, we use the first block in
• Ablame the blockchain to store values to be used. Thresholds will
• Aapproval be defined in the future to overcome a problem with a
We provide following formula to compute values of Aact malicious initial NN, and what we called the origin block
over time, with Aapp being an application factor, allowing problem.
applications to be more or less restrictive on actions.
4.3.1 Origin block problem
Aapp ∗ (Nauth − 1) At startup, the network contains no authenticated node to
Aevt = Cevt + (5)
Cevt realize BATM authentication and trust evaluation, and the
Note that reputation level simulation in Figure 5 does blockchain is empty. This means we need a method to forge
not consider minimum trust level required for a NN to the first block. We choose to let any node craft this special
fullfill an action. block from its own parameters. In fact, the main problem is
We showed how BATM with HKT provide a power- to ensure proper operation in the beginning of the network
ful solution to authenticate nodes and evaluate trust in life, then BATM will adapt itself to events occuring in the
decentralized networks. The system can be made instable network. If the first NN is malicious, it will be banned by
by malicious authenticated nodes overloading the network others node early in the network.
and submitting lots of valid payloads for inclusion in the Since the first block contains all mutable values used
blockchain. To overcome this issue, we define specific rules in BATM, a possible attack will be the inclusion of specific
for payload submission in the network to improve stability values which will tend the system to misbehave. To counter
of the system over time. this threat, future work will provide a formula to estimate
the probability of BATM instability from these values.
4.3 BATM payload rules
To avoid abuse from NN which can overload the network 5 F UTURE WORK
with payloads to be validated, we introduce specific rules We presented the concept and model of BATM, with early
on the payload exchange protocol for BATM. We consider results on reputation evaluation over time. The next step is
two type of rules : timers, key validity timeouts and event to evaluate each part of BATM completely and the global
reputation factors described earlier. Timers are limitation in model. The model itself will be improved depending on
time used to discard payloads and blocks submitted by NN the results, with the objective of more adaptative algorithms
overloading the network. taking AS and NN characteristics as defined in our model.
A set of timers defines the minimum amount of time
expected between two payloads of the same type. BATM 5.1 Trust model
currently uses 3 timers as follows.
BATM with HKT provide a simple way to manage trust
• Trenew is the usual time between two key renewal by in decentralized networks. More researches on HKT per-
a node. If needed, a node is authorized to renew its formance must be conducted, and the model itself may
keys at Trenew /2. Here we ensure there are at most 2 evolve to consider more parameters in trust and reputa-
renews in a Trenew for a given NN. tion evaluation. We think about considering NN and AS
• Tblame is the minimum time between two blames on abilities in account for specific actions, and enhance the
a NN given by the same blamer NN. reputation calculations. For example, a blamer reputation
6

could influence the reputation factor of its blame, and we [4] N. Fotiou and G. C. Polyzos, “Decentralized name-based security
may introduce a time coefficient to raise trust on the overall for content distribution using blockchains,” Proceedings - IEEE
INFOCOM, vol. 2016-September, pp. 415–420, 2016.
time presence of the NN or AS in the network. Another [5] S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,”
possibility is to raise resilience over DoS attacks by requiring www.bitcoin.org, p. 9, 2008. [Online]. Available: https://bitcoin.
blames from different NN or AS before banning one. org/bitcoin.pdf
In this paper, we consider self-organizing networks with [6] I. Eyal, A. E. Gencer, E. G. Sirer, and R. Van Renesse, Bitcoin-ng: A
scalable blockchain protocol, 2016.
no constraints on which NN may ask to authenticate. We [7] B. Solhaug, D. Elgesem, and K. Stolen, “Why trust is not propor-
also let possible a derivative model, using a network mas- tional to risk,” pp. 11–18, 2007.
ter key to allow blockchain supervision and eliminate the [8] T. Erl, Service-oriented architecture: concepts, technology, and design.
Pearson Education India, 2005.
first block problem. A possibility may be to allow specific [9] Z. Shelby, K. Hartke, and C. Bormann, “The constrained applica-
network, for example vendor-specific networks, where NN tion protocol (coap),” Standard Track, Internet Engineering Task Force
can provide a proof of membership by prior network master (IETF), 2014.
key signature. [10] S. De, P. Barnaghi, M. Bauer, and S. Meissner, Service modelling for
the Internet of Things, 2011.
[11] P. R. Zimmermann, The official PGP user’s guide. MIT press, 1995.
[12] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer,
5.2 Real world testing “Rfc 4880 - openpgp message format,” Proposed Standard, Internet
If simulation results fullfill our expectations, BATM will Engineering Task Force (IETF), 2007.
[13] D. Gambetta, “Can we Trust Trust?” Trust: Making and breaking
be included in Multicast Services for Linux (MSL), an coopeative relations, pp. 213–237, 1990.
implementation our SOA network model. Note that MSL
is at development stage for now with now release date.
Moreover, MSL is intended to be used as a real world proof
of concept for our overall design including SOA model and
BATM with HKT.

6 C ONCLUSION
This paper proposes a new application for the blockchain
as a secured decentralized storage for cryptographic keys Axel Moinet is a Ph.D Student at the Le2i laboratory, Univ. Bourgogne
Franche Comté. He works on smart camera based Vision Sensor Net-
as well as trust informations in the context of autonomous works and combinatorics. He graduated from a Master of Engineering
Wireless Sensor Networks. The Blockchain Authentication on Embedded Systems and then worked for Oberthur Cash Protection
and Trust Module and its Human-like Knowledge based as Embedded Software engineer before returning on a Ph.D thesis.
Trust model shows how to use to immutability of the
blockchain to provide solutions to high problematics in the
field of decentralized ad-hoc networks. More precisely, we
show how it is possible to build a complete solution provid-
ing authentication mechanisms as well as trust evaluation
in a self-organized and evolutive network.

Resources
The Service Oriented model is currently under development Benoit Darties is an Associate Professor at the Le2i laboratory, Univ.
Bourgogne Franche Comté. He works on combinatorics and operational
into the Multicast Services for Linux (MSL) framework.
research applied to networks operations. Benoit obtained in 2007 a Ph.D
MSL is a free software and will be publicly available at in Computer Science at University from Montpellier, France. He also
https://bullekeup.github.io/MSL, under the AGPL license. works on the design of low energy consumption mac protocols for WSN.
BATM will be available in MSL in the next months. HKT
simulation files for GNU Octave and MATLAB are available
by mail on request at [email protected].

ACKNOWLEDGMENTS
The authors would like to thank the Burgundy Region and
the FEDER european fund for funding this research work.
Jean-Luc Baril Jean-Luc Baril received his Phd degree in mathematics
and computer sciences from the University of Bordeaux in 1996. He is
R EFERENCES currently Professor in the Computer Science Department of the Bour-
gogne University (LE2I), Dijon-France. His research interests are in the
[1] C. M. Medaglia and A. Serbanati, An Overview of Privacy and Secu- areas of combinatorics, graph theory and algorithmic.
rity Issues in the Internet of Things, D. Giusto, A. Iera, G. Morabito,
and L. Atzori, Eds. New York, NY: Springer New York, 2010.
[2] Y. L. Sun, Z. Han, W. Yu, and K. R. Liu, “A trust evaluation
framework in distributed networks: Vulnerability analysis and
defense against attacks.” vol. 2006, pp. 1–13, 2006.
[3] G. Zyskind, O. Nathan, and A. S. Pentland, “Decentralizing pri-
vacy: Using blockchain to protect personal data,” Proceedings -
2015 IEEE Security and Privacy Workshops, SPW 2015, pp. 180–184,
2015.