Enhancing IoT Security and Privacy with Distributed Ledgers -

A Position Paper

Paul Fremantle

, Benjamin Aziz

and Tom Kirkham

School of Computing, University of Portsmouth, Portsmouth, U.K.

Science and Technology Funding Council, Harwell, U.K.

Keywords:

Internet of Things, Blockchain, Distributed Ledgers, Security, Privacy, Blockchains.

Abstract:

The Internet of Things has a number of well-publicised security ﬂaws, resulting in numerous recent attacks.

In this paper we lay out a framework for looking at how distributed ledgers and Blockchain technology can be

used to enhance the security, privacy and manageability of IoT devices and networks. A signiﬁcant concern is

the inability to process blockchains on small devices. We propose an architecture for IoT security and privacy

based on blockchains that addresses this and other issues. We look at related work and propose areas of further

research.

1 INTRODUCTION

The Internet of Things (IoT) consists of the set of

Internet-connected devices that collect sensor data

and allow control of actuators to measure and affect

the physical world.

Concerns over the security and privacy of the In-

ternet of Things reached a new high when the Mi-

rai botnet caused massive disruption to the Internet

in September 2016. In Fremantle and Scott (2015),

a number of issues are identiﬁed for security of IoT.

The direct cause of the Mirai attack was the use of

a dictionary password attack on devices connected to

the Internet that offered direct access. Other security

concerns about IoT devices include signiﬁcant chal-

lenges in updating devices; lack of clear and effective

registration processes; lack of well deﬁned identity

models; use of IoT devices as attack vectors into more

secure systems; and attacks on physical systems such

as Stuxnet (Langner, 2011).

Distributed Ledger technology, which is based on

the Blockchain (Nakamoto, 2008) construct, provides

a new class of distributed technologies. These sys-

tems are famous for being the basis of cryptocur-

rencies, where there is a fully decentralised system

with no central bank. Such systems are charac-

terised by a distributed, secure, ledger that provides

an immutable, assured record of a set of transactions.

While some blockchains such as Bitcoin have re-

stricted transaction models, others, such as Ethereum,

support more complex transaction models. Effec-

tively, each transaction recorded in the blockchain

can support arbitrary logic which is coded in a script-

ing language, which is Turing complete. This ability

to create new transactions through the use of script-

ing languages is commonly known as Smart Con-

tracts. Together these three constructs — Distributed

Ledger, Cryptocurrency and Smart Contracts — cre-

ate an environment where a set of parties can share in

the governance of the system, even when the identi-

ties and reputation of the parties is not known. Each

party participates in guaranteeing the good behaviour

of the others and of the set of transactions. The bene-

ﬁt of this is that it provides a fair and unbiased system

whereby users can trust in the integrity of the system

independent of any single parties’ overall behaviour.

We propose that this shared governance model has

signiﬁcant beneﬁts for the security and privacy of the

Internet of Things. In this work, we argue that the spe-

ciﬁc characteristics of the blockchain provide unique

approaches to solving problems in the IoT.

The contributions of this paper are: a model for

reasoning about how blockchains can improve pri-

vacy and security in IoT; a set of approaches for im-

proving security and privacy of IoT with blockchains,

derived from the model; and a proposed architecture

for creating distributed trust in a blockchain on low-

power devices.

The rest of the paper is laid out as follows. In

Section 2 we propose reasons why distributed ledger

technologies can help with IoT privacy and security.

In Section 3 we outline a model for reasoning about

344

Fremantle, P., Aziz, B. and Kirkham, T.

Enhancing IoT Security and Privacy with Distributed Ledgers - A Position Paper.

DOI: 10.5220/0006353903440349

In Proceedings of the 2nd International Conference on Internet of Things, Big Data and Security (IoTBDS 2017), pages 344-349

ISBN: 978-989-758-245-5

security and privacy for IoT, and use that model to

identify areas where distributed ledgers can assist. In

Section 4, we propose an implementation plan that

addresses these issues. In particular we aim to solve

the problem of how to provide trust in a blockchain

from a device that lacks the power to participate in the

blockchain. In Section 5 we compare this approach to

related work, and outline a plan of further work in this

area.

2 MOTIVATION

Because of the widespread deployment of IoT to-

gether with the use in many areas where personal in-

formation can be collected or deduced — including

smart homes, health monitoring, smart cars, and ﬁt-

ness tracking — there are ongoing major concerns

about privacy. These include: lack of informed con-

sent for publishing data; ﬁngerprinting of hardware;

and de-anonymisation, amongst others.

The Web and Internet have been driven by hetero-

geneity of clients and services: any browser will work

with any website; any FTP client with any FTP server.

This choice enables several security and privacy bene-

ﬁts. Users can migrate away from insecure or privacy-

leaking systems and services. It also encourages both

client and service providers to produce security up-

dates and improvements to the core protocols and

to the websites and services provided. While there

are problems, this has led to incremental improve-

ments and choices. For example, users concerned

about email integrity and spamming can adopt anti-

spam measures such as the Domain Key Identiﬁed

Mail standard (Crocker et al., 2011). Users concerned

with conﬁdentiality can encrypt email. Users con-

cerned about insecure messaging systems can choose

more secure instant messaging systems such as Sig-

nal

and Threema

. In contrast, the Internet of Things

is fundamentally controlled by the manufacturers of

devices, and does not offer choice for users to migrate

to more secure services. IoT devices are hard-coded

with ﬁrmware that typically connects to a single ser-

vice. In many cases the only true privacy control a

user has is to completely disable a device. Even when

systems use standard protocols, they may not docu-

ment the usage.

As discussed above, blockchains create a dis-

tributed ledger that creates a shared governance.

Blockchains rely on proof that the parties are behav-

ing in a consistent and correct manner, since the par-

ties are not known and are assumed to be inherently

https://whispersystems.org/

https://threema.ch/en

untrustworthy. Bitcoin, the most famous blockchain-

based system, relies on a concept called Proof of Work

to ensure that parties are behaving properly. Other

blockchain systems rely on differing proofs, includ-

ing proof of stake, proof of storage, or combinations

of different proof types. The proof is used to guar-

antee the immutability of an block and each block

guarantees the previous blocks (typically using a con-

struct known as a Merkle Tree) — creating a chain

of blocks known as a blockchain. Because the proof

requires some form of value (whether it is ownership

of a cryptocurrency, expended work, storage of data,

etc), the system can provide rewards for those who

participate. This is the basis of cryptocurrencies. For

example, Bitcoin issues new coins to the participat-

ing system that ﬁrst correctly produces the work that

veriﬁes the latest block.

Therefore, the distributed ledger offers the

promise of creating an environment for IoT networks

where there can be trust, anonymity, and effective

contracts between parties without any single vendor

being in charge, and without requiring any party to

trusted above any other.

However, there remains a major concern. The

processing, memory and code requirements of

blockchains makes them inappropriate to run on IoT

devices and gateways. For example, the current Bit-

coin database is around 80Gb and it takes at least

512MB of RAM and a 1Ghz processor to partici-

pate

. The Simple Payment Veriﬁcation (SPV) model

in Bitcoin supports lighterweight clients that can con-

nect to a random sample of servers, but this is sus-

ceptible to Sybil attacks. Recent work in Frey et al.

(2016) has made it feasible to participate in the Bit-

coin network with a smartphone, but to have an effec-

tive approach for IoT the system must support com-

mon cheap IoT devices. For example, the ESP8266

device is a common device target that offers 1Mb

of program memory and 80Kb of variable memory.

Even with the improvements from Frey et al, this

is still insufﬁcient even to validate the Bitcoin sys-

tem. As a result, we consider this a signiﬁcant is-

sue that needs addressing before the vision of using

blockchains as the basis of IoT security and privacy

can be achieved. To solve this problem, we propose

an avenue of research that can provide trust between

IoT devices and blockchains without requiring the de-

vice to actively participate in the blockchain.

https://bitcoin.org/en/bitcoin-

core/features/requirements

Enhancing IoT Security and Privacy with Distributed Ledgers - A Position Paper

345

3 MODEL

Spiekermann and Cranor (2009) offer a model for

looking at user privacy. In their model, they identify

three spheres: the User Sphere, the Joint Sphere and

the Recipient Sphere. The User Sphere is completely

in the control of the user (e.g. a laptop). The Joint

Sphere refers to areas that may seem to be in the user’s

control, but may have some signiﬁcant control by a

third-party. For example, a cloud email account may

seem like the user can delete emails, but the cloud

provider may in fact back these up and keep a copy.

Finally, once data has been transferred to a third-party,

it is assumed to be in the Recipient Sphere, where the

only controls are legal and contractual.

In the model, a device that offers the user full con-

trol is ﬁrmly in the User Sphere. However, we would

argue that many current devices are actually in the

Joint Sphere. This is where the device appears to be in

the control of the user but in fact is in the control of a

third-party. To give an example, the Google Nest de-

vice offers users the opportunity to apply smart heat-

ing controls to their house. While a number of user-

centred controls give the user the impression that it

is in the User Sphere, there are two key reasons to

counter this: ﬁrstly, the data logged by the device is

extensive and cannot be controlled by the user; sec-

ondly, the device auto-updates itself based on com-

mands from Google rather than based on user input.

Using this model, we can propose clear ap-

proaches that strengthen each of the privacy and se-

curity controls available in each sphere. Figure 1 pro-

vides an overview of this model.

Figure 1: IoT Blockchain applied to Privacy Model.

3.1 User Sphere

Moving privacy and security controls back to the

users inherently strengthens the User Sphere and pro-

vides greater choice, thereby allowing more secure

approaches to ﬂourish. We have identiﬁed a number

of controls which can be managed by a distributed

ledger.

Devices need to have secure identities (Fremantle

et al., 2014), and currently these are either not pro-

vided, or provided by the device manufacturer. Sys-

tems such as NameID

provide a model whereby

secure Web identities can be provided with no cen-

tral trusted system. Instead a distributed ledger (in

this case Namecoin) provides a neutral shared system.

This approach can be extended to IoT to issue each

device with a secure identity based on a distributed

ledger.

A second, related issue, is the ownership of de-

vices. The Mirai botnet spread because dictionary

attacks allowed attackers to take ownership of de-

vices. Some systems offer models of taking owner-

ship securely (e.g. Bluetooth, NFC). In (Fremantle

and Aziz, 2016), a QR code is used in conjunction

with a Web-based system. We propose that the cryp-

tocurrency model of blockchains provides a safer and

clearer model of ownership. Distributed ledgers im-

plicitly support ownership: a Bitcoin transaction is

the transfer of some bitcoins from own owner to an-

other. Similarly, a blockchain for IoT could support

the transfer of ownership of a device from the manu-

facturer to the user, and from one user to another. The

security of this is therefore based on the security of

the blockchain.

A third issue within the User Sphere is updating

the device ﬁrmware. A number of attacks have orig-

inated in lack of updates. One issue is that device

manufacturers are incentivised to create new products

but not to update old products. In (Tindall, 2015), a

model is proposed whereby devices can pay for up-

dates in a cryptocurrency. In addition, blockchains

could be used as the basis for building trust in updates

and also in validating updates.

3.2 Joint Sphere

Recall that the Joint Sphere is the parts of the system

where the user has some form of control over their

data and systems, but the provider also shares con-

trol. For example, a health-monitoring device may

upload data to an Internet-based system and then may

offer users controls on how they share data. A ma-

jor change in legislation around this is the European

Union’s General Data Protection Regulation (GDPR)

which requires much stronger consent controls. Many

systems offer forms of user consent for sharing data

with third parties, but these lack signiﬁcant require-

ments. For example, many users are not aware of how

to revoke consent. Similarly, there is no clear place a

user can identify all the consents they have approved

http://nameid.org

IoTBDS 2017 - 2nd International Conference on Internet of Things, Big Data and Security

346

across different devices. Consent is not just about pri-

vacy. IoT devices often include actuators that can act

based on Commands, and the security of a device in-

cludes ensuring that only authorised systems can issue

commands to devices.

We propose that consent be treated as a contract

in a distributed ledger system. This has several ben-

eﬁts. Firstly, this creates a clear ledger of all issued

consents. Secondly, this creates a clear contractual

obligation on the recipient of the consent to behave

according to the contract, which could (for example)

specify penalties for breaking the contract. Finally,

this model creates a clear opportunity for revocation

of consent, giving a single place to do so.

A related area is that of policies. In this meaning

a policy is a computer-readable expression of rights

and obligations. For example, a consent approval

may refer to a policy: the user might approve sharing

of data to a website based on the fact that the web-

site promises not to share the data to any other body.

Languages such as XACML (Godik et al., 2002) al-

low complex access control policies to be encoded in

XML or JSON. We propose that a distributed ledger

could be used to store and validate policies in an im-

mutable model that could be then used by IoT net-

works and consent models. In addition, the policies

could themselves refer to transactions in a distributed

ledger. We will describe this in the Recipient Sphere.

3.3 Recipient Sphere

The Recipient Sphere is the area where the user’s data

is now out of their control. Ultimately, the user must

rely on legislation or legal contracts in order to main-

tain control of this data. However, we propose that

distributed ledgers can offer a signiﬁcant beneﬁt in

this space. For example, suppose that a user shares

data with a third-party using a smart contract to en-

able consent. The contract refers to a policy that says

the third-party can only share that data with others

(on-bound sharing) if they inform the user of that

on-bound sharing. This policy could point to a new

smart contract that must be executed at the point of

on-bound sharing. By executing this second contract,

the on-bound sharing is logged immutably into a dis-

tributed ledger. Of course, it is hard to police this re-

cipient sphere: it is possible that the third-party web-

site will share data without executing the contract.

There are two defences against this. The ﬁrst is that

they are explicitly breaking a contract and penalties

can occur. In fact, we can envision that these penal-

ties could be implemented directly in the ledger by

smart contracts. If the user can prove data was shared

illicitly, the payment would be automatic.

Spotting these illicit data shares can possibly be

done using a concept of a Trap Street. This is the habit

that map-makers have of including incorrect data to

see if others copy it. Similarly, IoT devices could de-

liberately share incorrect data to speciﬁc parties to see

if it leaks out without a ledger entry to record it.

A similar capability that could be implemented us-

ing distributed ledgers and smart contracts is that of

Data revocation. This would be a situation where a

smart contract is used to trigger the secure deletion of

speciﬁc data.

In summary, we have seen a number of ways

where distributed ledgers can enhance privacy and se-

curity of IoT. We now look at a proposed implemen-

tation.

4 PROPOSED

IMPLEMENTATION

The biggest concern we have regarding the imple-

mentability is the inability of small devices to par-

ticipate in blockchains. Many blockchains provide

lighter-weight models of validation such as the Bit-

coin SPV

and the Ethereum Light Client Protocol

However, even these may require more processing

than an IoT device can provide, and this requirement

may also increase in the future with the growth in the

blockchain ledger.

There already exists a concept in the blockchain

system of an Oracle. An oracle is a system that re-

ports on the world to the blockchain in a reliable fash-

ion. For example, a smart contract may require pay-

ment when a certain condition is met, and the oracle

is used to report to the blockchain when that condi-

tion exists. We propose that the IoT and Blockchain

require the exact opposite - a trusted intermediary that

reports on the state of the blockchain on behalf of the

IoT device. Such an entity, which we call a Pythia,

could interact with the blockchain on behalf of IoT

devices and do so in a trusted fashion. Therefore, it

would act both as an oracle to the device, as well as

an oracle to the blockchain.

In order to allow the Pythia to be trusted, we

propose creating an Open Source codebase that

would be run using Intel Secure Guard eXtensions

(SGX) (Costan and Devadas, 2016). SGX provides

a secure enclave within modern Intel processors that

provides two key beneﬁts that are required by the

Pythia model. Firstly, the code is sealed and pro-

https://en.bitcoin.it/wiki/Thin Client Security

https://github.com/ethereum/wiki/wiki/Light-client-

protocol

Enhancing IoT Security and Privacy with Distributed Ledgers - A Position Paper

347

tected from attack from other code running in the

same processor. Secondly, the code can be validated

using Remote Attestation, which allows code exter-

nal to the processor to verify the speciﬁc codebase

running within the enclave. This veriﬁcation still re-

quires some processing power as it is based on Difﬁe-

Hellman Key Exchange (DHKE). Many devices do

perform aspects of Public Key Cryptography, but we

have not yet assessed the ability of typical devices to

perform DHKE, and that is one of our ongoing goals.

The remote attestation is then used to validate that

the Pythia is indeed running a speciﬁc version of the

open source codebase. In turn, this allows the device

to trust that the Pythia will act as intended with the

blockchain. This model is shown in Figure 2.

The Pythia model is that it offers a set of APIs

to IoT devices, and that these APIs offer capabilities

around device identity, ownership, data sharing con-

sent, etc. A number of these APIs are already in place

in systems such as OAuthing (Fremantle and Aziz,

2016), which utilises the OAuth2 APIs to provision

identities, consent scopes and ownership tokens to de-

vices. We believe that this model can be extended to

interface with blockchain smart contracts. One chal-

lenge is that code running within an SGX enclave only

runs efﬁciently when it ﬁts into 128Mb, which may

prove to be a challenge when building the Pythia.

Figure 2: Proposed Pythia Model.

Given this infrastructure, we propose building a

set of smart contracts that implement the ﬂows iden-

tiﬁed in Section 3. These are:

• Secure Device Identity

• Device Ownership

• Device Updates

• Data sharing and command consent

• Consent logging

• Policy sharing and validation

• Data revocation

We intend to use the Ethereum blockchain as the

basis for this work.

5 RELATED WORK AND

CONCLUSIONS

In Christidis and Devetsikiotis (2016) there is consid-

erable discussion of using blockchains together with

IoT, but this does not focus speciﬁcally on the pri-

vacy and security challenges of IoT. In Milutinovic

et al. (2016), an innovative blockchain is proposed

based on running within an SGX enclave. In Freman-

tle and Aziz (2016) there is a framework for device

identity, registration and consent that is independent

of vendors. However, this still relies on trust in the

central party, which can be obviated with the use of

blockchains and smart contracts. Town Crier (Zhang

et al., 2016) proposes an approach where SGX ex-

tensions are used to feed data into a blockchain in a

trusted manner, acting as an oracle. This does not pro-

pose the opposite ﬂow where the SGX enclave pro-

vides veriﬁed data from the blockchain as in the pro-

posed Pythia.

5.1 Conclusions and Further Work

At the moment, this vision of a blockchain-based IoT

is just a preliminary proposal. Clearly, implement-

ing such a blockchain based on existing distributed

ledgers that enable Smart Contracts such as Hyper-

Ledger or Ethereum is possible. Implementing an

SGX-based blockchain client to provide trusted data

from the blockchain is also clearly possible, although

given the limitations on SGX memory, this may need

signiﬁcant tuning to be effective and efﬁcient. At this

point, we have not evaluated the ability of a device

to perform remote attestation of an SGX enclave, nor

the complexities of the key distribution requirements

to make this possible. We see this as the ﬁrst step

in the ongoing research plan, together with evaluating

the possibilities of running an Ethereum node in an

SGX enclave.

In this paper we have proposed using a distributed

ledger to provide a shared governance model for IoT

devices, networks and cloud systems. Using Spiek-

ermann and Cranor’s Three Layer Privacy model, we

have outlined an approach for evaluating the use of

IoTBDS 2017 - 2nd International Conference on Internet of Things, Big Data and Security

348

blockchains in IoT. We have identiﬁed a number of

key areas where blockchains could be used to improve

privacy and security. We have proposed an system

that we call a Pythia whereby IoT devices can trust

the transactions of a blockchain without requiring the

memory and processor capabilities to actively partic-

ipate in the blockchain.

REFERENCES

Christidis, K. and Devetsikiotis, M. (2016). Blockchains

and smart contracts for the internet of things. IEEE

Access, 4:2292–2303.

Costan, V. and Devadas, S. (2016). Intel sgx explained.

IACR Cryptology ePrint Archive, 2016:86.

Crocker, D., Hansen, T., and Kucherawy, M. (2011). Do-

mainkeys identiﬁed mail (dkim) signatures. Technical

report.

Fremantle, P. and Aziz, B. (2016). Oauthing: privacy-

enhancing federation for the internet of things.

Fremantle, P., Aziz, B., Scott, P., and Kopecky, J. (2014).

Federated Identity and Access Management for the In-

ternet of Things. In 3rd International Workshop on the

Secure IoT.

Fremantle, P. and Scott, P. (2015). A security survey of

middleware for the internet of things. PeerJ PrePrints,

3:e1241v1.

Frey, D., Makkes, M. X., Roman, P.-L., Ta

ıani, F., and Voul-

garis, S. (2016). Bringing secure bitcoin transactions

to your smartphone. In Proceedings of the 15th Inter-

national Workshop on Adaptive and Reﬂective Mid-

dleware, page 3. ACM.

Godik, S., Anderson, A., Parducci, B., Humenn, P., and Va-

jjhala, S. (2002). Oasis extensible access control 2

markup language (xacml) 3. Technical report, Tech.

rep., OASIS.

Langner, R. (2011). Stuxnet: Dissecting a cyberwarfare

weapon. IEEE Security & Privacy, 9(3):49–51.

Milutinovic, M., He, W., Wu, H., and Kanwal, M. (2016).

Proof of luck: an efﬁcient blockchain consensus pro-

tocol. In Proceedings of the 1st Workshop on System

Software for Trusted Execution, page 2. ACM.

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic

cash system.

Spiekermann, S. and Cranor, L. F. (2009). Engineering

privacy. IEEE Transactions on software engineering,

35(1):67–82.

Tindall, K. (2015). How bitcoin might ﬁx the broken in-

ternet of things medium. https://freo.me/2jNZRBm.

(Accessed on 01/20/2017).

Zhang, F., Cecchetti, E., Croman, K., Juels, A., and Shi,

E. (2016). Town crier: An authenticated data feed

for smart contracts. In Proceedings of the 2016 ACM

SIGSAC Conference on Computer and Communica-

tions Security, pages 270–282. ACM.

Enhancing IoT Security and Privacy with Distributed Ledgers - A Position Paper

349