See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/329015471

Leveraging Blockchain to Enhance Data Privacy in IoT-Based Applications: 7th

International Conference, CSoNet 2018, Shanghai, China, December 18–20,
2018, Proceedings

Chapter · January 2018

DOI: 10.1007/978-3-030-04648-4_18

CITATIONS READS

0 169

3 authors, including:

Truc Dinh Trung Nguyen Hoang-Anh Pham

University of Florida Ho Chi Minh City University of Technology (HCMUT)
6 PUBLICATIONS   1 CITATION    27 PUBLICATIONS   59 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

research on enterprise software and processes View project

A Novel Adaptive Beacon-based Scheme for Warning Messages Dissemination in Vehicular Ad-Hoc Networks View project

All content following this page was uploaded by Truc Dinh Trung Nguyen on 23 November 2018.

The user has requested enhancement of the downloaded file.

Leveraging Blockchain to Enhance Data Privacy
in IoT-based Applications

Truc D. T. Nguyen1 , Hoang-Anh Pham2 , and My T. Thai1

1
Department of Computer and Information Science and Engineering,
University of Florida, Gainesville, FL 32611, USA
truc.nguyen@ufl.edu, mythai@cise.ufl.edu
2
Faculty of Computer Science and Engineering,
HCMC University of Technology, VNU-HCM, Vietnam
anhpham@hcmut.edu.vn

Abstract. In this paper, we present how blockchain can be leveraged

to tackle data privacy issues in Internet of Things (IoT). With the aid
of smart contracts, we have developed a system model featuring a trust-
less access control management mechanism to ensure that users have full
control over their data and can track how data are accessed by third-
party services. Additionally, we propose a firmware update scheme using
blockchain that helps prevent fraudulent data caused by IoT device tam-
pering. Finally, we discuss how our proposed solution can strengthen the
data privacy as well as tolerate common adversaries.

1 Introduction
With the great success of Bitcoin [1], the blockchain technology recently has
become a trending research topic in both academic institutes and industries as-
sociations. In a simple manner, blockchain is a decentralized database that con-
tains linked data blocks where each block is a group of valid and digitally signed
transactions. The blockchain itself is maintained by nodes in a peer-to-peer net-
work. What makes blockchain noticeable is the employment of a decentralized
fashion in which applications can operate efficiently without the need of a central
authority. In specific, it enables a trustless network where participants can trans-
act although they do not trust one another. Smart contracts in the blockchain
context are self-executing and self-enforcing contracts that are stored on chain.
They are deployed with explicit terms and conditions that are publicly visible
to all participants. Blockchain and smart contracts together have motivated nu-
merous decentralized applications such as Golem [2], Augur [3], or Status [4].
Consequently, the blockchain technology has the potential to go beyond financial
transactions and can be leveraged to tackle many problems in other domains,
especially in Internet of Things (IoT), which is currently employing a centralized
architecture.
We are witnessing the incredible growth of smart and networked embedded
devices that Cisco predicts to have about 50 billion connected devices by 2020
[5]. As such, there is an urgent need to shift toward a decentralized model with
2 T. Nguyen et al.

open-access networks and distributed cloud for sustaining the ever-expanding

IoT ecosystem [6]. In a typical IoT system, IoT devices aggregate data from
dedicated sensors, perform preprocessing, and push them to data center or cloud
for storage. These data are then analyzed and processed for different applications.
One critical concern with this type of architecture is the privacy as these data
could be very sensitive and related to private information. In fact, by using a
centralized cloud storage, data’s owners have very limited control and awareness
over their data. They have to put trust in cloud providers and would not know
if the data were being used for bad purposes. In this paper, we propose an IoT-
based system model that adopts blockchain and smart contracts as a solution
for the privacy issue. Particularly, we emphasize the data ownership that users
should have full control over their data and be aware of how they are being used.
Another problem in current IoT systems is that data are only as good as the
IoT devices from which they are originated, there is no guarantee that they are
accurate. In IoT, devices are subjected to be compromised in which a device’s
firmware can be replaced by a malicious one [7–9]. Various incidents about this
type of attack have been recorded [10, 11]. Such attack could take control of the
IoT devices to perform illegal actions or produce false data. In the scope of this
work, we leverage blockchain to help users detect malicious firmwares as well
as make sure that devices are updated with legitimate ones. This solution will
prevent fraudulent data from being published to the network.
Our contributions are summarized as follows:

1. Proposing an IoT system model based on blockchain and smart contracts

that features a trustless access control management. Our solution makes
sure that users are the owners of their data and third-party services can
only access the data given users’ consent.
2. Proposing a firmware update scheme using blockchain to ensure that IoT
devices are programmed with legitimate firmwares. This will help prevent
fraudulent data caused by IoT device tampering.

The remainder of this paper is organized in the following manners. Section 2

introduces the problems that are addressed in this work. The overall design of
the system model is given in Section 3. We describe detailed implementation in
Section 4. Section 5 analyzes the privacy and security of the model. Some related
works are presented in Section 6, and Section 7 provides the final concluding
remarks.

2 Problem statement

This paper mainly tackles the data privacy issues when third-party services are
involved. In specific, we concentrate on IoT-based applications in which data
collected from IoT devices can be accessed by some third-party services given
that the users have consented. Our solution aims to address the following privacy
issues:
 Leveraging Blockchain to Enhance Data Privacy in IoT-based Applications 3

– Access control: the system recognizes users as the owners of their data and
they can authorize other services to access the data. Users have the flexibility
to modify the set of permissions at any given time.
– Data transparency: Third-party services who were granted permissions by
users can easily access the published data; and the assurance that those
published data are officially coming from the users.
– Access tracking: Users are fully aware over what data are being collected
and how they are accessed by third-party services.
Furthermore, we address the attack in which adversaries can tamper with IoT
devices and produce fraudulent data. Our solution makes sure that IoT devices
can obtain the latest official firmware from their vendors and prevent fraudulent
data from being published on blockchain, thereby maintaining the data integrity.

3 System model

Fig. 1. System model

Fig. 1 illustrates an overview of our system model. As can be seen, all

entities interact with each other via a blockchain network. A set of Aggrega-
tors A = {a1 , a2 , ..., an } represents users who own one or more IoT devices
that generate data. An Aggregator can categorize data from IoT devices into
slots so that it can permit third-party services to access only a subset of data.
For example, an Aggregator a1 wishing to categorize its data into tempera-
ture, humidity and location will result in having three slots, that is SLOTa1 =
{[temperature], [humidity], [location]}. Each Aggregator will issue transactions
to the blockchain for granting permissions or publishing data.
4 T. Nguyen et al.

A set of Subscribers S = {s1 , s2 , ..., sn } represents third-party services who

can issue transactions to access data published by Aggregators given appropriate
permissions. A set of Vendors V = {v1 , v2 , ..., vn } represents manufacturers of
IoT devices who are responsible for publishing official firmware images. Each of
Aggregator, Subscriber and Vendor is identified by a set of public-private key
to interact with the blockchain network, they are responsible for securing their
own private keys to avoid being compromised.
Data published by Aggregators are stored in the off-chain storage. This com-
ponent uses a content-based addressing scheme, that means for each piece of
data, its hash corresponds to the address at which it is stored. Thus, this hash
can be used as a pointer to retrieved the data. The off-chain storage could be ei-
ther a distributed peer-to-peer filesystem platform where data are stored across
a set of storage nodes such as IPFS [12], Swarm [13], and Storj [14]; or, even
a centralized cloud with sufficient trust in a third-party service. In case of us-
ing a distributed platform, a node could serve as both a storage node and a
blockchain’s node. The off-chain storage only accepts requests originated from
the blockchain’s nodes.
The blockchain network is deployed with two smart contracts: AccessCon-
trol and FirmwareUpdate that are used for managing access permissions and
updating new firmwares, respectively. We assume that all smart contracts are
correctly deployed. For better understanding the workflow of our system, con-
sider the following example: the Aggregator a1 collects data from IoT devices
and categorizes them into SLOTa1 as above, by issuing a publish transaction to
the blockchain, SLOTa1 is stored in the off-chain storage and its hash is saved
in the blockchain. Assume that a1 wants to share the temperature data with
s1 , location and humidity with s2 , a1 will invoke the AccessControl contract to
grant s1 and s2 access permissions to its specific data slots. The access control
policy of a pair (ai , sj ) is then saved in the AccessControl contract.
Consider that s1 wants to access the temperature data of a1 , it will issue
a retrieve transaction to the blockchain to retrieve the data from the off-chain
storage. This transaction will invoke the AccessControl contract to check for
(a1 , s1 )’s policy to see if s1 has the right to access the temperature data of a1 .
Each Vendor vi will publish the hash of its official firmware images to the
blockchain by using the FirmwareUpdate contract. An Aggregator can monitor
the firmware of its devices by comparing the image hash of the devices with the
one published on the blockchain by Vendors. Therefore, it can update the new
image or know which devices were being tampered.

4 Implementation
4.1 Encryption scheme
Data stored in the off-chain storage are encrypted by the Aggregator. Since
encrypting a large chunk of data using asymmetric encryption schemes is not
known to be efficient, in this work, we employ a hybrid approach with a re-
encryption scheme [15, 16]. We denote EN C(d, k) as encrypting data d using
 Leveraging Blockchain to Enhance Data Privacy in IoT-based Applications 5

key k, DEC(denc , k) as decrypting the encrypted data denc using key k, pk as

public key and sk as private (or secret) key. Our encryption scheme is as follows:

1. An Aggregator ai besides its permanent public/private key (pkai , skai ) will

generate a temporary pair of (pkal i , skal i ) for each of its slot l ∈ SLOTai . With
respect to a slot l, for each Subscriber sj that ai wants to grant access, ai gen-
erates a uni-directional re-encryption key Kal i →sj from skal i and pksj . This
key allows a proxy server to convert from EN C(m, pkal i ) to EN C(m, pksj )
for any message m without revealing the underlying text or skal i [16]. All
re-encryption keys are kept in the AccessControl contract.
2. When ai wants to publish a data slot l, it first signs the data using its private
key skai to create a sigal i which will also be added into l. Then it generates
a new symmetric random key rkal i and uses it to encrypt the data to create
lenc as follows:
lenc = EN C( sigal i |l , rkal i )


(1)
l
3. ai encrypts that random key using
its pkai and prepends  it to the encrypted
data, that means ai will publish EN C(rkal i , pkal i )|lenc
4. When sj is authorized to access that data published by ai , the blockchain
node will perform re-encryption:

EN C(rkal i , pksj ) = Kal i →sj EN C(rkal i , pkal i ) (2)

and then it returns lenc together with EN C(rkal i , pksj ) to sj .

5. Now, sj can perform:

rkal i = DEC(EN C(rkal i , pksj ), sksj )

(3)
sigal i |l = DEC(lenc , rkal i )



At this time, sj can read the published data l, and also verify the sigal i using
pkai to confirm the data’s origin.

Each time ai wants to publish new data, it only needs to repeat from step
2. However, in case ai wants to revoke the access permission of sj to a specific
slot l, it will repeat step 1 to generate a new pair of (pkal i , skal i ) so that the
re-encryption keys are now changed, sj will not be able to decrypt any further
lenc .

4.2 AccessControl Contract

Contract 1 presents the implementation of the AccessControl contract. It holds
a state variable M which is a map between a pair of (ai ∈ A, sj ∈ S) and a
set of policies P . Each element in P is a pair of (lid , Kal i →sj ) where l is the slot
identifier and Kal i →sj is the corresponding re-encryption key as in Section 4.1.
Whenever an ai wants to grant access to any sj , it will issue a transaction that
specifies the set P for each sj to the Share procedure of the contract. At this
time, the variable M will be updated with that new information.
6 T. Nguyen et al.

Contract 1 AccessControl
M : map (ai , sj ) → P . P: a set of policies
AccessLog: record an attempt to access an ai ’s slot by a 5-tuple (sj , ai , l, time, stt)

procedure Share(pkt , P KS , P OL) . Share data slots with Subscribers

Input
pkt public key of the transaction’s issuer
P KS list of Subscribers’ public keys
P OL set of policies for each Subscriber
for pksj ∈ P KS do
P ← P OL[pksj ] . Obtain P of sj
M [(pkt , pksj )] ← P
end for
end procedure

function Access(pka , pkt , lid ) . Check if an Aggregator’s slot is accessible

Input
pka public key of the Aggregator
pkt public key of the transaction’s issuer
lid the slot that needs to be checked
P ← M [(pka , pkt )]
if lid ∈ P then
AccessLog ← (pkt , pka , l, time, T rue)
return True
else
AccessLog ← (pkt , pka , l, time, F alse)
return False
end if
end function

In case an ai wants to deny access from sj to its slot l, ai will generate a

new (pkal i , skal i ) as in Section 4.1 and do not create a re-encryption key for sj .
ai then issues a transaction to the contract to update its policy including new
re-encryption keys for other Subscribers.
Moreover, the contract also has a state variable AccessLog that records an
sj ’s attempt to access a slot l ∈ SLOTai . Each record is a 5-tuple (sj , ai , l, time, stt)
where time and stt dictates the timestamp and status (True/False) of the ac-
cess, respectively. When sj issues a retrieve transaction to access ai ’s data, the
function Access of this contract will be activated to check if the slot is accessible,
and the attempt, whether granted or denied, will be recorded on the blockchain.
If ai wants to see the past contents of this AccessLog variable, it only needs to
traverse back the blockchain history.

4.3 Data publishing and retrieval

For these operations, as they involve a large amount of data, they can only be
executed off-chain. An Aggregator ai who wants to publish a new data slot l will
 Leveraging Blockchain to Enhance Data Privacy in IoT-based Applications 7

first sign and encrypt

it as in Section 4.1. As above-mentioned, the published
data will in fact be EN C(rkal i , pkal i )|lenc , we denote it as lpub . ai will issue a
publish transaction to the blockchain that includes H(lpub ) (hash of lpub ) and
the slot identifier lid . Once the transaction is recorded on the blockchain, ai will
send lpub to a blockchain node(s). This node can be randomly chosen or selected
by proof-of-stake or ai can even send to multiple nodes for redundancy. These
nodes upon receiving lpub first need to verify that H(lpub ) matches the hash
included in the corresponding publish transaction. Then, they upload lpub to the
off-chain storage in which it can later be addressed by H(lpub ).
When a Subscriber sj wants to access the published data of ai , it will issue
a retrieve transaction indicating the pkai and lid . This transaction will trigger
the AccessControl contract at function Access as in Section 4.2. If the function
returns false, no further actions will take place. If it returns true, the blockchain
node will look into the records and find the most recent H(lpub ) associated with
pkai and lid . Then it will use the hash to obtain lpub from the off-chain storage,
perform re-encryption using the key Kal i →sj stored in the AccessControl contract
as in Section 4.1, and return the data to sj . After decrypting, sj can check the
received data’s hash against the record on blockchain.

4.4 FirmwareUpdate Contract

Contract 2 illustrates the implementation of the FirmwareUpdate contract. This

is a simple contract in which it records all firmwares’ hash issued by Vendors.
It has a state variable F that is a map between Vendor vi ∈ V and the hash
of its latest firmware. For simplicity, we assume that each Vendor only issues
one IoT device. Each time a vi wants to publish a new firmware, it will issue a
transaction to invoke the NewFirmware procedure to update the variable F .
An Aggregator ai may use this contract to update its devices’ firmware or
check for device tampering. To update a device, ai only needs to look for the
corresponding Vendor in F for the latest hash, if this hash is different than its
device’s firmware hash, ai can download the new firmware directly from the
Vendor and then verify the downloaded file using the hash in this contract. To
check if its device was tampered, ai will traverse back the blockchain history
of variable F to see whether any of the published hash matches the current
firmware hash of the device. If the result is negative, that means the device’s
firmware was overwritten by attackers.

5 Privacy and Security analysis

As opposed to the traditional cloud-centric IoT model in which data are sus-
ceptible to be manipulated and misused, the Aggregators in this system design
have full control over their data. As can be seen from the AccessControl con-
tract, an Aggregator may modify the set of permissions at any time without the
need of any central authority. By combining with the encryption scheme, the
system makes sure that Subscribers who are not granted permissions will not be
8 T. Nguyen et al.

Contract 2 FirmwareUpdate
F : map between a vi ∈ V to its latest firmware hash

procedure NewFirmware(pkt , h) . Publish new firmware

Input
pkt public key of the transaction’s issuer
h hash of the firmware
if pkt ∈ V then . Check if the issuer is a Vendor
F [t] ← h
end if
end procedure

able to access the Aggregator’s data. An adversary may attempt to take control
of the storage nodes to obtain data, however, the data are all encrypted, thus
without having a re-encryption key issued by the Aggregator, the data cannot
be decrypted. Furthermore, in case of using a distributed storage platform like
distributed hashtable (DHT) [17], data are separated into chunks and are stored
across different storage nodes, it would be hard for someone to assemble the
data. Another way of attack is to have a malicious blockchain node query data
from the off-chain storage or the node itself ignores the access control policy
and gives data to unauthorized Subscribers. However, in the same manner, data
are encrypted, only Subscribers who were granted permissions may be able to
decrypt them.
Subscribers who were given appropriate permission may easily access data
published by the Aggregator. As the system guarantees the data integrity, Sub-
scribers can make sure that the obtained data are accurate, untampered. This is
due to the fact that the off-chain storage uses a content-based addressing scheme,
therefore if the data were altered, it would not be addressable by the hash stored
on blockchain. Additionally, as blockchain is immutable, hashes stored on chain
remain permanently authentic. Thanks to that, even if an Aggregator’s private
key was stolen, data already stored on the off-chain storage could not be modi-
fied. By verifying the signature found in the data, Subscribers can firmly believe
that they are originated from the official source.
Along with sharing data, the system also enables Aggregators to be fully
aware of the shared data. Each time a Subscriber issues a retrieve transaction
to obtain data, the attempt, either successful or failed, will be recorded by the
AccessControl contract. By looking into the records, the Aggregator may track
how its data are being collected by third-party services.
Moreover, by employing the firmware update scheme, we limit attempts to
physically tamper IoT devices that overwrites the firmware in order to produce
fraudulent data to the network. By traversing back all firmware’s hashes stored
on the blockchain, an Aggregator can detect if its devices were compromised,
which also helps discovering some vulnerabilities resided within its system. Ag-
gregators can set up a schedule to check or update new firmware images on a
recurring basis (e.g., daily). In this way, users can assure that malicious firmwares
 Leveraging Blockchain to Enhance Data Privacy in IoT-based Applications 9

will eventually be replaced with legitimate firmwares (given the assumption that
the Vendor keeps its private key secured).
Even though data on chain are publicly accessible, an adversary will not be
able to learn any essential information on the blockchain because it can only see
the access control policy and some hashes. All sensitive data are encrypted and
kept secured off-chain with restricted access. Nevertheless, since our proposed
system relies on blockchain and smart contracts, it can only be as secured as the
blockchain itself.

6 Related Work
Due to the attraction of blockchain and IoT, there are a lot of research efforts
in both academic and industrial works that have addressed the integration of
blockchain and IoT. In [18], the authors gave a detailed review on how blockchain
and smart contracts make a good fit for IoT in which they concluded that the
combination will cause important impact on several industries. Khan et al. [19]
presented current security issues in IoT and asserted that blockchain would be
a key solution. Some other works [20–22] outline aspects and use cases where
blockchain can be combined with IoT. However, none of these works illustrates
the integration in detail.
In [23], the authors presented an access control mechanism using blockchain.
They described the system thoroughly with detailed designs and protocols. Nev-
ertheless, all the operations are executed off-chain, that is, they did not exploit
the smart contracts in their work. Therefore, they missed out some great ad-
vantages of smart contracts such as accuracy, transparency and trust. In our
proposed system, we keep the access control management on-chain with smart
contracts so that the operations are explicitly visible to all participants which
eliminates the possibility of manipulation, bias or error.
The work by Shafagh et al. [24] is the most closely related to ours. They
presented a blockchain-based system for IoT that enabled a secured data sharing
without the need of any central authority. However, they also did not take the
advantages of smart contracts. Furthermore, as they enabled third-party services
to retrieve data directly from the off-chain storage, users could not track how
their data were being accessed. In our proposed solution, all attempts to access
users’ data are all recorded permanently on the blockchain.

7 Conclusion and Discussion

In this paper, we have demonstrated how blockchain can be leveraged to strengthen
data privacy in IoT-based applications. We proposed a system model based on
smart contracts and blockchain that tackles the access control, data transparency
and access tracking issues in IoT when third-party services are involved. Specifi-
cally, the system enables a trustless data sharing mechanism in which users have
full control over their data that they can choose which services are allowed to ac-
cess. Third-party services who were consented can easily access the data with the
10 T. Nguyen et al.

assurance that data are authentic and comes from the right user. Moreover, we
also propose a firmware update scheme to limit the impact of IoT device tamper-
ing in which firmwares are overwritten by malicious ones to produce fraudulent
data.
Since this paper only presents the concepts and modelings, further efforts
should focus on conducting realistic experiments to evaluate the performance
and robustness of the system, especially in terms of latency, throughput and
stability as these are crucial criteria in any IoT application. The proposed system
model can be implemented using some blockchain platforms such as Ethereum
[25] or Hyperledger [26].

Acknowledgment

This paper is partially supported by NSF CNS-1443905 and NSF EFRI 1441231.

References
1. S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
2. “Golem.” [Online]. Available: https://golem.network/
3. “Augur — a decentralized oracle & prediction market protocol.” [Online].
Available: https://www.augur.net/
4. “Status, a mobile ethereum os.” [Online]. Available: https://status.im/
5. D. Evans, “The internet of things: How the next evolution of the internet is chang-
ing everything,” CISCO white paper, vol. 1, no. 2011, pp. 1–11, 2011.
6. P. Brody and V. Pureswaran, “Device democracy: Saving the future of the internet
of things,” IBM, September, 2014.
7. M. B. Barcena and C. Wueest, “Insecurity in the internet of things,” Security
Response, Symantec, 2015.
8. A. Mosenia and N. K. Jha, “A comprehensive study of security of internet-of-
things,” IEEE Transactions on Emerging Topics in Computing, vol. 5, no. 4, pp.
586–602, 2017.
9. O. Arias, J. Wurm, K. Hoang, and Y. Jin, “Privacy and security in internet of things
and wearable devices,” IEEE Transactions on Multi-Scale Computing Systems,
vol. 1, no. 2, pp. 99–109, 2015.
10. G. Hernandez, O. Arias, D. Buentello, and Y. Jin, “Smart nest thermostat: A
smart spy in your home,” Black Hat USA, 2014.
11. C. Miller, “Battery firmware hacking,” Black Hat USA, pp. 3–4, 2011.
12. J. Benet, “Ipfs-content addressed, versioned, p2p file system,”
https://github.com/ipfs/papers, 2014.
13. “Swarm.” [Online]. Available: https://swarm-gateways.net/bzz:/theswarm.eth/
14. S. Wilkinson, T. Boshevski, J. Brandoff, and V. Buterin, “Storj a peer-to-peer
cloud storage network,” 2014.
15. M. Blaze, G. Bleumer, and M. Strauss, “Divertible protocols and atomic proxy
cryptography,” in International Conference on the Theory and Applications of
Cryptographic Techniques. Springer, 1998, pp. 127–144.
16. M. Egorov, M. Wilkison, and D. Nuñez, “Nucypher kms: decentralized key man-
agement system,” arXiv preprint arXiv:1707.06140, 2017.
 Leveraging Blockchain to Enhance Data Privacy in IoT-based Applications 11

17. P. Maymounkov and D. Mazieres, “Kademlia: A peer-to-peer information system

based on the xor metric,” in International Workshop on Peer-to-Peer Systems.
Springer, 2002, pp. 53–65.
18. K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts for the in-
ternet of things,” Ieee Access, vol. 4, pp. 2292–2303, 2016.
19. M. A. Khan and K. Salah, “Iot security: Review, blockchain solutions, and open
challenges,” Future Generation Computer Systems, vol. 82, pp. 395–411, 2018.
20. N. Kshetri, “Can blockchain strengthen the internet of things?” IT
Professional, vol. 19, no. 4, pp. 68–72, 2017. [Online]. Available:
doi.ieeecomputersociety.org/10.1109/MITP.2017.3051335
21. A. Dorri, S. S. Kanhere, and R. Jurdak, “Towards an optimized blockchain for
iot,” in Proceedings of the Second International Conference on Internet-of-Things
Design and Implementation, ser. IoTDI ’17. New York, NY, USA: ACM, 2017,
pp. 173–178. [Online]. Available: http://doi.acm.org/10.1145/3054977.3055003
22. S. Huckle, R. Bhattacharya, M. White, and N. Beloff, “Internet of
things, blockchain and shared economy applications,” Procedia Com-
put. Sci., vol. 98, no. C, pp. 461–466, Oct. 2016. [Online]. Available:
https://doi.org/10.1016/j.procs.2016.09.074
23. G. Zyskind, O. Nathan et al., “Decentralizing privacy: Using blockchain to protect
personal data,” in Security and Privacy Workshops (SPW), 2015 IEEE. IEEE,
2015, pp. 180–184.
24. H. Shafagh, L. Burkhalter, A. Hithnawi, and S. Duquennoy, “Towards blockchain-
based auditable storage and sharing of iot data,” in Proceedings of the 2017 on
Cloud Computing Security Workshop. ACM, 2017, pp. 45–50.
25. G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,”
Ethereum project yellow paper, vol. 151, pp. 1–32, 2014.
26. C. Cachin, “Architecture of the hyperledger blockchain fabric,” in Workshop on
Distributed Cryptocurrencies and Consensus Ledgers, vol. 310, 2016.

View publication stats