Introduction & Background - 3-4 pages / 3 hours - zero plagiarism

Vivekan

out.pdf

Home >Information Systems homework help >Introduction & Background - 3-4 pages / 3 hours - zero plagiarism

Enhancing IoT Security with Blockchain

by Chunchi Liu

B.Sc. in College of Information Science and Technologies, July 2017, Beijing Normal University

A Dissertation submitted to

The Faculty of The School of Engineering and Applied Science

of The George Washington University in partial satisfaction of the requirements

for the degree of Doctor of Philosophy

August 31, 2020

Dissertation directed by

Xiuzhen (Susan) Cheng Professor of Computer Science

28091048

2020

The School of Engineering and Applied Science of The George Washington

University certifies that Chunchi Liu has passed the Final Examination for

the degree of Doctor of Philosophy as of August 25, 2020. This is the final

and approved form of the dissertation.

Enhancing IoT Security with Blockchain

Chunchi Liu

Dissertation Research Committee:

Xiuzhen (Susan) Cheng, Professor of Computer Science, Disser- tation Director

Abdou Youssef, Professor of Engineering and Applied Science, Committee Chair

Hyeong-Ah Choi, Professor of Engineering and Applied Science, Committee Member

Wei Cheng, Assistant Professor, University of Washington, Com- mittee Member

iii

Acknowledgments

Is it just me or all PhD students question about their life choices?

–me.

However, it is lucky for me to have a highly encouraging and supportive

PhD advisor, many intellectually active research fellas of the same interest,

and also many professors, friends and families to help me get over this

extraordinarily hard time of pursuing science.

Prof. Xiuzhen Cheng, Yinhao, Minghui, Huqin, Guangtou, Yawei, Yizhen,

Prof. Yerukhimovich and all other friends and families, thank you. I wouldn’t

finish this if I were alone.

Abstract

Enhancing IoT Security with Blockchain

This thesis explores the emerging technology of blockchain and its appli-

cations in IoT. Blockchain is an interdisciplinary technology build on top

of Cryptography, Distributed Systems and Computer Network. It creates

a secure environment that allows some certain types operations and inter-

actions among participants to be trustworthy. It establishes security on

top of objective cryptographic assumptions and security proofs, instead of

subjective trust assumptions.

In this thesis, we first narrate our understanding on blockchain, then

present our exploratory works on using blockchain to enhance IoT and real-

life security. The first work is Normachain, where we allow the supervisors

to search for illegal information on top of encrypted blockchain transactions

without decrypting it, thus preserving the confidentiality of the transaction

content at the same time. The second work is Tokoin, where we design a

coin-based access control scheme to address the long-existing overprivilege

challenge and weak auditability problem in the field of IoT access control.

In the third work we extend on-chain trust to off-chain by achieving the real

time data consistency between physical objects and their corresponding

digital entities on blockchain. We also fully implement a trusted monitoring

system to support our example of trustworthy physical vaccine shipping.

Table of Contents

Acknowledgments iv

Abstract v

List of Figures viii

List of Tables ix

Chapter 1: Introduction 1 1.1 Understanding Blockchain: An emerging topic . . . . . . . . 1 1.2 Main Components of Blockchain . . . . . . . . . . . . . . . . 2 1.3 Research Challenges . . . . . . . . . . . . . . . . . . . . . . . 3

Chapter 2: Normachain: Searching Encrypted Content in Blockchain 5

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Preliminaries: Searchable Encryption . . . . . . . . . . . . . 7 2.3 Architecture and Adversarial Model . . . . . . . . . . . . . . 9

2.3.1 Three-Layer Blockchain Network Design . . . . . . . 9 2.3.2 Adversarial Model . . . . . . . . . . . . . . . . . . . . 12 2.3.3 System Framework . . . . . . . . . . . . . . . . . . . . 13

2.4 Decentralized PEKS Scheme . . . . . . . . . . . . . . . . . . 15 2.4.1 Distributed Key Generation . . . . . . . . . . . . . . . 15 2.4.2 DPEKS Scheme . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.1 Adversarial Supervisor . . . . . . . . . . . . . . . . . 22 2.5.2 Adversarial Bank . . . . . . . . . . . . . . . . . . . . . 23 2.5.3 Adversarial User . . . . . . . . . . . . . . . . . . . . . 25

2.6 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . 27 2.6.2 Key Distribution and Trapdoor Collection Efficiency 28 2.6.3 Transaction/Supervision Efficiency . . . . . . . . . . 28 2.6.4 Supervision Accuracy . . . . . . . . . . . . . . . . . . 30

Chapter 3: Tokoin: A Coin-based Accountable Access Control Scheme 32

3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.1 Mainstream Access Control Schemes . . . . . . . . . 36 3.3.2 Existing Challenges . . . . . . . . . . . . . . . . . . . 38

3.4 TBAC: Tokoin-Based Access Control . . . . . . . . . . . . . . 43

3.4.1 Design Objectives, System Assumptions, and Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4.2 The TBAC Description . . . . . . . . . . . . . . . . . . 47 3.5 TBAC System Implementation . . . . . . . . . . . . . . . . . 53

3.5.1 TBAC System Description . . . . . . . . . . . . . . . . 53 3.5.2 Authentication, Authorization, and Auditing Processes 60 3.5.3 TBAC Prototype Implementations . . . . . . . . . . . 68

3.6 Case Study: TBAC Assisted In-home Cargo Delivery . . . . 74 3.6.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . 76 3.6.2 Delivery Process . . . . . . . . . . . . . . . . . . . . . 78 3.6.3 Discussions on TEE Cost . . . . . . . . . . . . . . . . 82

3.7 Discussions and Future Research . . . . . . . . . . . . . . . 82 3.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Chapter 4: Extending On-chain Trust to Off-chain – A Trustworthy Vaccine Shipping Example 86

4.1 Motivation and Abstract . . . . . . . . . . . . . . . . . . . . . 86 4.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.3 Definitions and Models . . . . . . . . . . . . . . . . . . . . . 89

4.3.1 Basic Definitions . . . . . . . . . . . . . . . . . . . . . 90 4.3.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4 A Vaccine Transportation Monitoring System . . . . . . . . 93 4.5 Main Scheme: Trust Extension from On-Chain to Off-Chain

Physical World . . . . . . . . . . . . . . . . . . . . . . . . . . 95 4.5.1 TEE-Enabled Trusted Environment Monitoring . . . 95 4.5.2 Consistency Analysis . . . . . . . . . . . . . . . . . . 101 4.5.3 Lost Record Tolerance and Recovery . . . . . . . . . . 105

4.6 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.6.1 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.6.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Bibliography 117

vii

List of Figures

1.1 A General Blockchain Analytical Framework . . . . . . . . . . . 3

2.1 The Three-Layer Sharding Model of NormaChain. . . . . . . . . 10 2.2 The E-commerce Contract Generation and Approval Diagram. . 11 2.3 Setup Efficiency. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.4 Transaction Efficiency on Laptop. . . . . . . . . . . . . . . . . . 26 2.5 Transaction Efficiency on Raspberry Pis. . . . . . . . . . . . . . 29 2.6 Supervision Efficiency. . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Overview of Tokoin-based Access Control Model . . . . . . . . . 46 3.2 The Full TBAC Protocol Sequence Diagram . . . . . . . . . . . . 55 3.3 Block Structure and URPO . . . . . . . . . . . . . . . . . . . . . 63 3.4 The TBAC Mobile App Workflow . . . . . . . . . . . . . . . . . . . 71 3.5 TBAC Assisted In-home Cargo Delivery . . . . . . . . . . . . . . 74 3.6 Experiment Setup of TEE . . . . . . . . . . . . . . . . . . . . . . 76 3.7 Android Tokoin Activities for Cargo Delivery . . . . . . . . . . . . 79 3.8 A Set of Actual Captures of TACO for Overprivileged-Access Moni-

toring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 3.9 function Execution Times . . . . . . . . . . . . . . . . . . . . . . 81

4.1 Block Diagram of the System . . . . . . . . . . . . . . . . . . . . 98 4.2 Flowchart of the System . . . . . . . . . . . . . . . . . . . . . . . 99 4.3 Abstract Architecture of System . . . . . . . . . . . . . . . . . . . 101 4.4 Data uploading illustration . . . . . . . . . . . . . . . . . . . . . 105 4.5 Photo of the vaccine shipping box with sensing devices . . . . . 109 4.6 GPS movement trace and security checkpoints . . . . . . . . . . 111 4.7 Temperature fluctuation . . . . . . . . . . . . . . . . . . . . . . . 112 4.8 Photosensor and its logic voltage level output . . . . . . . . . . . 113

viii

List of Tables

2.1 An Example of a Suspicious Transaction . . . . . . . . . . . . . 31 2.2 An Example of another Suspicious Transaction . . . . . . . . . 31

Chapter 1: Introduction

1.1 Understanding Blockchain: An emerging topic

Blockchain represents a type of secure decentralized system. It creates a se-

cure environment that allows some certain types operations and interactions

among participants to be trustworthy. The security and trustworthiness

is based on cryptographic-level security assumptions only, instead of a

non-mathematical security assumptions. From our understanding, what

blockchain guarantees is trustworthy interaction, a protection towards dy-

namic processes instead of static objects. Static objects are already protected

by cryptography quite well– it does not need blockchain.

Blockchain aims to support many types of trustworthy interactions and

secure processes. The discussion towards the evolution of blockchain gen-

eration (from 1.0 to 3.0) is based on the types of trustworthy interactions

a blockchain can permit. For example, blockchain 1.0 usually refers to

secure financial transaction, which is technically trusted algebraic opera-

tion. Blockchain 2.0 refers to all turing-complete computer programs and

3.0 refers to any digital and physical interactions. Clearly, the current

blockchain only achieves 1.0 in satisfactory efficiency, 2.0 in a mediocre

level efficiency and 3.0 far from achieved.

To build a secure decentralized system that protects dynamic processes,

the main philosophy is to combine interactive cryptographic primitives and

distributed system together. As said earlier, static objects are protected

by cryptography alone quite well. Examples include encryption schemes

for data confidentiality, hash signature for data integrity, just to name a

few. Such static protection cannot guarantee the security of a dynamic,

interactive process, or a complex system. Interactive cryptographic primi-

tives, in the other hand, can enforce the security of an dynamic system well.

For example, digital signatures can establish identity before exchanging

important information, functional encryption can allow agents to compute

encrypted data without knowing the content, verifiable random function

can select a random leader which is known to himself only and unknown to

all others, et cetera. Such interactive cryptographic primitives and protocols,

if used properly, can create some magical and innovative functionalities.

1.2 Main Components of Blockchain

In our previous work, we have concluded a general blockchain analytical

framework that lists out all essential components of a blockchain. We provide

a general blockchain system model by which existing blockchain systems

can be conveniently decoupled, broken down, and efficiently analyzed. This

model could also provide insightful ideas about designing new blockchain

systems based on previous designs. As shown in Fig. 1.1, the Architecture

Formation Algorithm takes as input an Unstructured Network and outputs

a Structured Blockchain Architecture consisting of structured blockchain

nodes. The blockchain system then performs Synchrony Abstraction and

Consensus Algorithm upon this blockchain architecture. The consensus

result is produced by consensus nodes and then stored in the Distributed

Ledger. The Incentive Mechanism aims to reward or penalize blockchain

nodes for maintaining a stable and sustainable status of the blockchain

system.

The most significant one of all is the consensus algorithm. Specifically,

a consensus algorithm is a parallel protocol that collects opinions from

all participants and unify them into one. In general, it coordinates all

Figure 1.1: A General Blockchain Analytical Framework

participants to execute in a unified direction, in order to achieve order and

consistency in a diverse and heterogeneous system. To this reason, we

also consider the consensus algorithm as the the distributed driver of the

system.

1.3 Research Challenges

The research challenges of blockchain can be described in two questions.

• Can we increase blockchain efficiency while compromising no security?

• Can we increase more types of trustworthy interactions of blockchain

while compromising no security?

We call them efficiency challenge and ability challenge. Note the com-

monality is to preserve the security in a cryptographic level. We emphasize

that if blockchain loses cryptographic level security and trustworthiness, it

degenerates into an ordinary distributed system. The efficiency challenge

can be broken down in following specific goals, just to name a few:

• Design of blockchain architecture and consensus algorithm that sup-

ports:

– Scalability of a single chain and cross-chain interoperability

– Simultaneous and parallel processing

– Fast finalization time

• Design of distributed ledger that supports:

– Concurrent writing

– Ledger consistency over the system

– Increased or offloaded storage space

– Safe roll-back mechanisms

The ability challenge is harder to break down into goals, as the problem

itself still under exploration. The long term goal is to design new interactive

protocols that supports general secure computing in practical efficiency.

We leave these questions open for blockchain researchers and my future

endeavors. In this paper, we focus on how to increase real-life security and

IoT security with blockchain.

Chapter 2: Normachain: Searching Encrypted Content

in Blockchain

2.1 Motivation

The fast development of Internet of Things (IoT) permits the new trading

model of IoT-based E-commerce. It realizes person-to-machine (P2M) and

machine-to-machine (M2M) transactions, rather than person-to-person

(P2P) transactions as in the conventional E-commerce. Blockchain’s abil-

ity on governing decentralized networks makes it especially suitable for

designing a self-managing system on IoT devices.

Cryptocurrency, the signature blockchain application however, cannot be

directly applied to the IoT-based E-commerce. For example, the iconic Bit-

coin established their reputation by offering perfect transaction anonymity

and security. However, these impressive features are gained in sacrifice of

legitimacy and efficiency. As for legitimacy, it is often abused by fueling

the digital black markets such as the “Silk Road”, who traded 1.2 billion

USD worth of transactions in 2013 [37]. This symbol of disorder is a major

reason that blockchain is feared and rejected by governments and industries.

Furthermore, its transaction security is maintained at the cost of huge

hash power, which causes high computational overhead. These critical

drawbacks of blockchain are fatal to the future IoT-based E-commerce as

they continue to deter government and industry confidence.

In order to perform necessary legal supervision on transactions, regu-

lators must obtain user’s transaction information to a certain degree. For

example, regulators may need to decrypt a suspicious transaction history to

uncover any illegal or fraudulent transactions. Some systems address this

issue by storing transaction records in plaintext, however, this infringes

on the user’s privacy and can nullify the privacy promised by blockchain.

However if we do not allow such inspection by keeping the records encrypted

and identity anonymous, we face the same anarchy problem. Currently,

blockchain communities seem to be trapped in a dilemma where they have

to choose between privacy and legitimacy. To the best of our knowledge,

NormaChain is the first work to settle the above dilemma and preserve

both essential features. To be more specific, we propose a legal supervision

scheme on blockchain using searchable encryption (SE).

Searchable encryption is a technique that permits search for specific

target keywords on a piece of encrypted data without revealing the plaintext.

As a result, we can search for specific criminal evidence while keeping the

legitimate customers’ information untouched. According to the needs of our

scenario, we adopt the public key encryption with keyword search (PEKS)

scheme [7]. Most importantly, one of our major contribution in our paper is

that we propose a Decentralized PEKS (DPEKS) scheme. In this system, we

eliminate the need of a central authority to perform supervision, which was

needed in the original PEKS scheme. Instead, we distribute the power of

supervision to n different parties to avoid single point corruption. Only when

the target keyword list is approved by all n parties simultaneously, can this

target keyword be allowed to search. This provides a high security to tolerate

any kind of collusion under n−1 parties’ corruption. In the security analysis part in our paper, we show that NormaChain preserves legitimate user’s

private information against the supervisor by proving NormaChain is CCA2-

secure. This means that supervisors cannot attack the system and infer the

encryption key and thus decrypt an arbitrary user’s encrypted information.

Furthermore, we also prove that in our decentralized computing process,

our secret key is kept safe from being cryptanalyzed.

Progressively, our autonomous and lightweight transaction management

platform is designed for IoT E-commerce to address the efficiency challenge.

In the goal of achieving high transaction speed and scalability, we replace the

conventional single layer blockchain to a three-layer sharding blockchain

network, with each layer assigned to different responsibilities. We also

adopt Practical Byzantine Fault Tolerance (PBFT) consensus algorithm in

replacement of Proof-of-Work (PoW) to minimize the overall mining liability

of our nodes.

We lastly present our NormaChain system with full detailed design and

implementation over C++. Our experiment result shows that when hosting

on a consumer-grade laptop, or even on lightweight IoT devices (Raspberry

Pi), the transaction latency remains on the millisecond level and the super-

vision can also be executed in real time. Although the transaction speed is

slightly increased due to the weak computational ability of these devices,

our lightweight system still takes no more than 8 milliseconds to complete

a transaction. The average transaction-per-second (TPS) of NormaChain on

IoT-devices is 113.69. Supervision accuracy reaches 100%.

2.2 Preliminaries: Searchable Encryption

Searchable Encryption (SE) is a theory of carrying out reliable and privacy-

preserving searching on encrypted data. Although it permits the use of

an agent to search through sensitive data, excess leakage of information

is restricted due to SE’s architecture. It is worth mentioning that since

blockchain records are protected by encryption, SE’s functionality of search-

ing over encrypted data is equivalent to that of online search engines used

on the traditional internet infrastructure. Searchable Encryption was first

introduced by Song et al. [52] who is credited with developing Symmet-

ric Searchable Encryption (SSE). In this primitive scheme there are two

cryptographic roles: Alice and Gateway. Alice is the data writer and owner

who holds a private key. The data and trapdoor are both encrypted and

constructed with this private key. Alice can thus grant keyword search

permission to the Gateway for identifying a desired keyword, however, the

Gateway remains unaware of the encrypted text’s contents. This scheme

only permits one data writer and owner, and is therefore called Single Writer-

Single Reader (S/S) searchable encryption scheme. This is not suitable for

our system, as the blockchain is possibly written, shared and maintained

by all nodes, which lead us to a progressive scheme of the Public key En-

cryption with Keyword Search (PEKS), which is published by Boneh et al.

in 2004 [7].

In PEKS, there are three roles instead of two, i.e., Alice, Bob and the

Gateway. Alice is the data and private key holder, while Bob holds only the

public key of Alice and thus can write and encrypt the data, and the Gateway

is the agent of searching. In this scheme, both Bob and Alice can write the

data with the public key, but only Alice can grant permission to search with

the private key. This scheme is thus called Multiple Writer-Single Reader

(M/S) searchable encryption scheme, which supports multiple different

entities to write the data but the only one can search. In this case, it is

suitable to employ PEKS for the data sharing the purpose of the blockchain

system. The ability to search is achieved by the construction of trapdoor. A

trapdoor is a tool that can determine whether the encrypted information

contains a desired keyword while maintaining the text’s encrypted nature.

However, one can see that Alice has the monopoly power of deciding what to

search. This is reasonable if the data is owned purely by Alice, but when a

third-party uploads data, their right to search for an illegal keyword should

be granted. We thus adopt the cryptographic core of PEKS in NormaChain

and further design a decentralized PEKS scheme, where our special needs

can be fulfilled.

2.3 Architecture and Adversarial Model

In this section, we introduce the architecture and adversarial model of

NormaChain. We first introduce the three-layer blockchain network design

of NormaChain, then followed by the essential roles in NormaChain and the

specific adversarial model.

2.3.1 Three-Layer Blockchain Network Design

This network model complies with the hierarchical design concept, which

divides the blockchain network into three layers, each being responsible for

different tasks. This hierarchical design can significantly improve system

performance of blockchain as it assigns tasks by taxonomy, and distributes

them to the best corresponding workers [1]. This design consists of trans-

action, approval, and supervision layers, as demonstrated in Figure 2.1.

In the whole blockchain system, we have two chains, i.e., the transaction

chain and supervision chain, where the former is shared but encrypted

in the transaction and approval layer, and the later is encrypted and kept

private in the supervision layer.

The lowest layer is a public transaction layer consisting of users that

are either online buyers and/or E-commerce merchants. All user nodes,

denoted by Ui, can freely connect and disconnect to the network, as they

are not required to carry out any mining or verification duties. Whenever

any user Ui initiates a transaction T X i, two identical contracts between

��

� ��

��

Figure 2.1: The Three-Layer Sharding Model of NormaChain.

the buyer and seller are automatically generated and sent to the middle

layer’s connected banks for approval (Figure 2.2). Therefore, the transaction

layer does not have any mining liabilities, nor does it has to store the full

transaction chain as those duties are transferred to the approval layer.

Users are only responsible for initiating transactions and sending it to the

buyer’s bank for further processing.

The middle layer is a consortium approval layer. Nodes in this layer

are financial institutes, denoted as Bi for banks, which can only verify

financial transactions for their users’ transactions. These interconnected

nodes authenticate Bi’s identity and authorize him to verify the generated

transaction contract T X i. Once a consensus is reached, Bi can thus verify

the transaction contract, encrypt it with the public key β , and push the

ciphertext CT X i onto the transaction chain. In this way, the transaction

of each user is only known by his corresponding bank and hence user’s

privacy is not shared to other banks in the approval layer. Note that the

public key and the private key pair will be generated distributedly. The

��

� �

��

�

��

Figure 2.2: The E-commerce Contract Generation and Approval Diagram.

public key is revealed to the public as we need it to encrypt messages, but

the private key is scattered into |Bi| pieces and distributed to every bank Bi. The upper layer is a private supervision layer. All nodes in the supervision

layer are authorities that require an invitation to join. These supervisors,

denoted as Si, could be government agencies, law enforcers, NGOs, etc.

Within a period of time, the supervisors can propose to scan a target illegal

keyword list w. All the banks will collaborate to calculate the corresponding

trapdoor Tw, if all of them consider this keyword list w is reasonable and

non-privacy-violating. All attempts to scan the transactions are recorded

on the supervision chain to ensure the accountability of supervision power.

Only if any illegal information or keywords are spotted can it be picked out

for further inspection.

2.3.2 Adversarial Model

We mentioned earlier that there are three cryptographic roles in the PEKS

scheme, Alice, Bob and Gateway. In our scenario, all banks B as a whole

virtually plays the role of Alice by decentralizedly holding a private key α

through a cryptosystem. The public key β is publicly shared to all banks.

Any bank Bi who uses Alice’s public key β for encrypting approved trans-

actions T X i is Bob. Any supervisor Si can be the Gateway with a criminal

target keyword list w by requesting trapdoors from B. Thus supervisors can

search for criminal information without knowing the full contents of user

transactions. In this paper, we emphasize the importance of security and

privacy of all parties. As a result, we analyze and propose the adversarial

models for all parties in NormaChain.

2.3.2.1 Adversarial Supervisor

The role of supervisor in our system is one major source of adversarial

attacks, as government agencies sometimes tend to peek inside the full

information of a customer. So the supervisor adversarial model in this

paper is set as “honest but curious", which means the supervisor would

perform his duties, but stays curious on full customer’s plaintext informa-

tion. Again, a major feature of this paper is to successfully permit a general

privacy-preserving supervision on the blockchain systems to address the

aforementioned problem. In Section 2.5 Security Analysis, we provide the

proof of Chosen Ciphertext Security (CCA) against the supervisor.

2.3.2.2 Adversarial Bank

The adversary model of banks is similar to the adversarial supervisor. They

can be “honest but curious”, but this time, they can curious on recovering

the complete secret key, such that one can decrypt the encrypted information,

or compute any trapdoor he wants. For any bank, he can collect all public

information, such as fractional trapdoor Twi , public key, and etc. He can also

try to collude with other banks to share their private information to make a

malicious impact on the whole. Yet in Section 2.5, we provide rigorous proof

of impossibility to cryptanalyze, recover and obtain other bank’s secret key

share from all accessible information. Even by collusion, it is extremely

hard to obtain enough information for malicious activities.

2.3.2.3 Adversarial User

Since the users in our system bear minimal responsibilities for maintaining

the transaction chain (no mining liabilities), the user adversarial model

does not have much power to perform malicious activities. The adversarial

user model in this paper is set to tamper with the transaction contract and

his balance [57]. This is also easily defensible with blockchain integrity

property.

2.3.3 System Framework

In this section, we provide our specifications of NormaChain framework. It

automatically collects, verifies and records all the transactions, and also

carries out supervisions on it. The specific steps of our framework are

shown as follows:

1. The system generates the key pair (β ,{αi}) = DisKeyGen(n). Then broad-

casts the public key β to all nodes.

2. Any buyer Ui who wishes to initiate transactions sends a message msg

to the seller U j, and both of them generate an identical transaction

contract and send to the buyer’s bank Bi.

3. After the PBFT verification of the bank Bi’s identity, Bi verifies the con-

tracts, decides the contracts to be Approved or Declined, and then writes

on the transaction chain by first fracturing the transaction contract

into words W , and encrypting it as C = PEKS(β ,W ). The contract is

then sent to the supply chain for next step logistics.

4. If any supervisor Si wishes to search for a target criminal keyword list

w, he sends w to all banks B for a consensus process. If this target

criminal keyword list is unreasonable, and 2/3 of all banks’ approval

is not achieved, then trapdoor computation on this keyword list is

rejected. Otherwise, B as a whole returns a corresponding trapdoor

list Tw = TrapdoorCollection(TrapdoorLocal (αi,w)).

5. The supervisor Si can test the recently added, encrypted transaction

C with Res = Test(β ,C,Tw). Si finally receives a list of {0,1}|Tw| indicating the existence of the target criminal keyword. This result is then written

in the supervision chain and if legally warranted, Si can decrypt and

look into that block by requesting the construction of α . Note that this

is the only exception to reconstruct α explicitly.

6. If there is a security threat, or explicit leakage on the secret key α , the

system revokes keypair, go to stage 1); Otherwise go to stage 2).

2.4 Decentralized PEKS Scheme

After initializing the three-layer blockchain network and adversarial model,

we now provide our design of DPEKS on it. As discussed earlier, we adopt

PEKS for NormaChain, as it can support multi-writer and single-reader

(M/S) scheme on encrypted data. We must point out that the original PEKS

scheme relies on a centralized governance of the private key, and thus have

the ability to secretly construct unnecessary trapdoors, or peek into the

encrypted data. Of course one can assume the integrity and the honesty

of the central authority, however it is easy to see that this assumption is

less than vulnerable. In our design, we further expand the PEKS scheme

into a pure decentralized way– no one has the full access to the private

key, while still preserve the ability to collaboratively computing the required

output, i.e., trapdoor. We call this new scheme the Decentralized PEKS,

or DPEKS. This is achieved by combining the Distributed Key Generation

(DKG) scheme and a delicate expansion of the original PEKS scheme. We

also give careful proof of correctness and security of our new scheme.

2.4.1 Distributed Key Generation

The first Distributed Key Generation (DKG) scheme was introduced by

Pedersen et al. at 1991 [45]. It is a delicate design to simultaneously assign

n different secret key shares αi to n different people. The overall secret key α

is virtually shared among all parties as a mathematical combination of all

αi. In this manner, we can promise that no single party can reconstruct or

store the secret key on his own, and the secret key can only to be used by

decentralized collaboration. Thus, we can effectively eliminate the need of a

centralized trust. This is also critical for our Decentralized PEKS scheme.

One of the most commonly used DKG scheme is Joint − Feldman protocol [21]. It is basically letting n players to simultaneously run the Feldman’s

information-theoretic Verifiable Secret Sharing protocol, and finally assign

n secret keys shares αi to n different people. The complete protocol is page

consuming, so we simplify it by omitting the details such that it is more

accessible to all readers. Here we have the simplified DKG algorithm defined

as follows:

DKG(n) ={αi}, (2.1)

αi ∈Zq,i ∈ {1,...,n}

where g is the generator of finite cyclic group Zq of q order, p is a large prime

number and q is a large prime dividing p − 1. The generator g, order q and p are necessary and must be identical to every participant, so they are

pre-settled by the protocol, and distributed to all. The generated secret key

shares αi should satisfy the equation of α = ∑ni=1 αi. Each piece of secret key

share αi can never be revealed to others, or will be considered as collusion.

As the public key is g to the power of the secret key, so according to the

definition of the cyclic group, the overall public key h can be collected as:

h = n

∏ i=1

hi = n

∏ i=1

gαi (2.2)

and explicitly shared to all.

We clarify that we do not need the explicit revealing of private key α to

perform regular functions. In fact, we prohibit any party to reveal his own

secret key share to anyone (which will be seen as collusion) and hence the

secret key α should never be reconstructed explicitly– unless all n parties

are corrupted by the adversary at the same time.

The question here is: if we prohibit explicit reconstruction of the secret

key α , then how can we use it? Note that the only place we need to use the

secret key α as a whole in the original PEKS scheme is when we compute

the trapdoor against illegal keywords. We now prove it in our DPEKS

construction at the following section, that even with the fractions of the

secret key {αi}, one can locally build its fractional trapdoors Twi , which can be further linearly collected as the final functional trapdoor Tw. The

correctness and secrecy of trapdoor are proven in the later context.

Normally, when the supervisor proposes to search for an illegal keyword

list w, all banks will evaluate the necessity of it. If all banks agree that this

list is reasonable, they will collaborate to compute the trapdoor. Otherwise

the keyword list might be harmless and unnecessary, then the bank can

decide to accept or reject– each bank will have its own opinion on customer

protection.

2.4.2 DPEKS Scheme

Here, we have all the prerequisites we need. We can thus propose the

DPEKS and its formal definitions.

Definition 1. A decentralized public key encryption with keyword search

scheme, or DPEKS for short, should consist of the following polynomial-time

algorithms:

1. DisKeyGen(n): Input the total number of n parties, generates a set of

secret key shares α1,α2,...,αn, each hold secretly by the player Pi, and

a corresponding public key β = g∑αi is broadcasted to all.

2. DPEKS(β , W ): Input the public key β and a transaction W , produces a

searchable encryption of W .

3. TrapdoorLocal(αi, w): Input the secret key share αi and a target wordlist

w, outputs a fraction trapdoor list Twi .

4. TrapdoorCollection({Twi},Tw j ) → Tw : Receives all fraction trapdoor Twi from other players, use his own secret key share α j to locally compute

Tw = ∏i∈n\ j Twi · Tw j (where · is the group operation), and broadcasts for verification.

5. Test(β , Ci, Twi ): Input the public key β , a searchable encryption S =

DPEKS(β , W1), and a trapdoor Tw2 . Outputs ‘YES’ if W1 = W2 and ‘NO’

otherwise.

Compared with the original PEKS scheme that was proposed by Boneh

et al. [7], our scheme eliminates the need of a central holder of the secret

key α . Rather, we generate secret key shares αi in a distributed manner,

decompose the computation of fractional trapdoors Twi in the local side

and finally collect them into the complete Tw. This can be reflected as

the difference from the original KeyGen(), to our new DisKeyGen(), and the

Trapdoor() to become TrapdoorLocal() and TrapdoorCollection(). As a result, we

must guarantee that the DPEKS scheme is correctly decomposable and

collectable. Here we define the correctness of DPEKS as follows:

Definition 2. The correctness of DPEKS:

1. The sum of all secret shares αi is the unique secret key α , and all

parties have the same public key of the value h = gα .

2. The Trapdoors are correctly computed within each party, and is correctly

collected, that is: Trapdoor(α) = TrapdoorCollection({Trapdoor(αi)}).

Also, we have to ensure that the secrecy and security are not compro-

mised at this new scheme. Here we define the secrecy of DPEKS as follows:

Definition 3. The secrecy of DPEKS:

1. For any bank Bi, he should never reveal his secret key share αi to any

other bank B j, where j �= i.

2. For any bank Bi, he should never learn the secret key share α j of any

other bank B j through cryptanalysis, where j �= i.

In the following, we will provide the detailed construction and proof

of correctness of our DPEKS scheme. The secrecy is proved in Security

Analysis Section 2.5, where we give rigorous security proofs.

Theorem 1. DPEKS scheme satisfies correctness.

Proof. The first part in Definition 2 is intuitive and is guaranteed in the

Distributed Key Generation in Section 2.4.1. The second part, decompo-

sition and collection correctness is the major difference from the original

PEKS, and is the core part of DPEKS correctness. This part is similar to

the original PEKS scheme, which relies on the bilinear pairing, which is a

variant of Computational Diffie-Hellman problem (CDH) [8].

We construct the cryptographic model using the Bilinear Maps. Let G1,

G2 be two groups of prime order p. This indicates that G1 and G2 are finite

cyclic groups of order p. Let e be a bilinear map where e : G1 × G1 → G2. The map e, as a cryptographic bilinear map, a.k.a. a pairing, must satisfy

properties of computability, bilinearity and non-degeneracy as defined in [9].

Since these definitions are identical with the original paper, we omit them

due to the limited pages. Next, we construct two necessary Hash functions

H1 : {0,1}∗ → G1 and H2 : G2 → {0,1}log p 2 as the Random Oracles.

The following steps are the core cryptographic steps and functions of our

DPEKS scheme. Assume that we have a transaction information W . When

a supervisor Si requests the banks to generate a list of trapdoors Tw for a list

of target illegal keywords w, the aforementioned methods will be executed in

sequence.

– DisKeyGen(n) → (α,β ) : Each bank performs the Joint − Feldman’s protocol parallelly to generate a list of secret key shares αi ∈ Z∗p, where each bank Bi secretly knows αi and α = ∑i∈n αi. It also picks a generator g of

group G1. Then, it outputs the public key β = [g,h = gα ] (broadcasted)

and αi (secretly stored to each). Here, we obtain the asymmetric key

pair of all bank.

– DPEKS(β ,W ) → C :

1. Computes t = e(H1(W ),hr) ∈ G2, for a random r ∈ Z∗p, where W stands for a vector of to-be encrypted transaction information.

2. Outputs C = DPEKS(β ,W ) = [gr,H2(t)], where C is a vector of en-

crypted transaction wordlist. This encrypted transaction data is

also written in the transaction chain as a history.

– TrapdoorLocal(αi,w) → Twi : Outputs a trapdoor list fraction Twi = H1(w)αi ∈ G1 of the target criminal keywords list w.

– TrapdoorCollection({Twi},Tw j ) → Tw : Receives all trapdoors Twi from broad- cast, B j computes the combination of trapdoor list Tw = ∏i∈n\ j Twi · Tw j . All banks then broadcasts Tw for cross-verification using Practical

Byzantine Fault Tolerance algorithm.

1. If cross-verification pass, accept and exit.

2. Otherwise, discard results.

– Test(β ,C,Tw) → Res : Let C = [WA,WB], test if H2(e(Tw,WA)) = WB. If so, out- put ‘YES’; if not, output ‘NO’.

The key is to make sure the secret key is linearly shared (α = ∑i∈n αi),

and hence the functional output (trapdoor Twi ) can be linearly collected due

to group properties. As shown in Section 2.4.1, by generation, the secret

key share is guaranteed to sum up to the secret key α (α = ∑i∈n αi). So it is

critical that the fractional trapdoors can collect up to the correct, complete

trapdoor. This is the major difference between DPEKS and PEKS, and there

is no change in the core bilinear map construction, so we will focus proving

the correctness of our modified part.

For any finite cyclic group G of p order, it is defined as G = < g > =

{gn|n ∈ Z,n ≤ p}, where g is the generator and “·” is the group operation. According to the definition, for any i ∈ Z, gi+1 = gi · g1. Hence we can know:

for all i, j ∈ Z

gi+ j = gi · g j (2.3)

which is critical.

The original Trapdoor function is basically computing the exponential of

group operation H1(w)α , where H1(w) is an element in the group G. According

to the definition of the cyclic group, H1(w) can be represented as gx. As x

is arbitrary and non-critical, we can simplify it to g. Therefore according

to the linear attribute in Eq. 2.3, we can let each local trapdoor Twi to be

computed by secret key share αi at local. Then every bank Bi broadcasts

Twi , collects all of them and uses TrapdoorCollection function to combine them

into the final trapdoor Tw.

Tw = Trapdoor(α) = H1(w)α = gα

=∏ i∈n

TrapdoorLocal(αi) =∏ i∈n

H1(w) αi =∏

i∈n gαi (2.4)

where α = ∑i∈n αi.

Theorem 2. DPEKS scheme satisfies secrecy.

Note that although this design is intriguing and delicate, we must guar-

antee that no secret shares αi can be inferred or stolen by the adversary. We

give security proofs in the Section 2.5, guaranteeing that although we pass

the trapdoor shares Twi to other banks, the secret key share αi is always

kept safe from cryptanalysis.

2.5 Security Analysis

In this section, we analyze the security features of NormaChain.

2.5.1 Adversarial Supervisor

2.5.1.1 Proof of Security against CCA

The supervisor’s adversarial model has been introduced in the previous

section, which is “honest but curious", which means the supervisor would

perform his duties but stays curious about full customer’s plaintext infor-

mation. According to our design goals, we must preserve a benign user’s

privacy; that is, the supervisors should not know anything other than the

{0,1} result of his detection of criminal keywords. We now prove that our NormaChain system preserves customer privacy from supervision.

Chosen Ciphertext Attack (CCA) is a widely used security evaluation

to measure the adversary’s advantage on guessing the answer. It usually

refers to an attack where the adversary (in our scenario, supervisor ASi ) is requesting the encrypter (banks) an adequate amount of ciphertexts

(trapdoors) until they can have a higher advantage of guessing the correlation

of the keyword and the trapdoor. In our scheme, we prohibit the supervisor

to know anything other than the {0,1} when using their trapdoors. We roughly perceive that if a PEKS+blockchain scheme is adaptively CCA-

secure, then this scheme is customer privacy preserving against the supervisor.

In NormaChain, we constructed our PEKS scheme using the bilinear map

and the computational Diffie-Hellman Problem. The bilinear map construc-

tion of PEKS scheme is rigorously proven in the [7] to be semantically secure

against adaptive chosen ciphertext attack (CCA2 secure). As we are con-

structing our DPEKS scheme according to this exact mathematical core, we

claim to have CCA2-security and can, therefore, protect customer privacy

from curious supervisors.

2.5.2 Adversarial Bank

The adversary model of banks was defined similarly as the supervisors.

They are also “honest but curious”, but this time, they can be curious on

recovering the complete secret key, such that one can decrypt the encrypted

information, or compute any trapdoor he wants. There are two ways of

actually achieving this: by cryptanalysis and collusion. Recall in Section

2.3, Theorem 2 claims that DPEKS satisfies secrecy. We now prove both of

these attacks are intractable.

2.5.2.1 Proof of Security against Cryptanalysis

As we mentioned earlier, the computation of the complete trapdoor Tw is by

a multi-party computation. So for each adversary bank ABi , the information of other bank’s secret key share is only accessible from the received bank’s

trapdoor fractions. We now prove that for any bank Bi, he cannot recover

the any bank’s secret key share B j from his fractional trapdoor Tw j .

The proof relies on the hardness of the discrete logarithm problem. Here

we provide the definition of the group discrete logarithm problem.

Definition 4. For a finite cyclic group G of p order, G is defined as G = < g >

= {gn|n ∈ Z,n ≤ p}, where g is the generator and the “·” multiplication is the group operation. Let a be an element of G. An integer k that solves the equation

bk = a is noted as a discrete logarithm problem of a to the base b. Or simply to

compute k = logab.

And also one of the foundational hardness theorems of modern cryptog-

raphy, that is discrete log problem hardness theorem:

Theorem 3. For any sufficiently large group order p, the group discrete loga-

rithm problem is computationally intractable.

As mentioned in Section 2.4, the trapdoor Tw j = g α j . As a result, for

any adversary A, the goal of computing the secret key share of bank B j is to compute α j = log

Tw j g . As stated in the Theorem 3, this problem is

computationally intractable. Hence we can guarantee the security against

cryptanalysis on public information.

2.5.2.2 Proof of Security against Collusion

Another way of stealing the full secret key is to secretly collude and collect

all pieces of secret key share. That is: assuming all banks are semi-honest

and each has a possibility of colluding. An adversary A (could be a bank or supervisor) attempts to corrupt and take control of all n banks. Assume

each bank’s possibility of collusion follows a discrete normal distribution

X ∼ N(μ,σ 2), which we set the average probability of collision is 0.5 (μ = 1/2), and the standard deviation σ is 1/4. For each round, the possibility of each

bank choosing to collude is sampled as pi, and 1 − pi otherwise. So the probability of collision for each round is p = ∏i∈n pi. By simulated sampling

of MATLAB, when n = 10, the typical value of p is approximately 1e−4 ∼ 1e−3. When n = 50, the typical value of p is approximately 1e−16 ∼ 1e−15. When n = 100, the typical value of p is approximately 1e−32 ∼ 1e−30, which is statistically satisfying.

2.5.3 Adversarial User

Since the users in our system are bare minimal responsibilities for main-

taining the transaction chain, the user adversarial model does not have

much to attack against. The adversarial user model in this paper is set to

have a simple goal, which is to tamper the transaction contract and his

balance [57].

2.5.3.1 Proof of Security against Tampering with Data

As stated in the design of our E-contracts, when users want to initiate

a transaction, both the buyer and seller generate an identical E-contract

and send it to the buyer’s bank for approval. With this design, assuming

the communication channel is safe (using SSL/TLS), then the unilateral

tampering of the transaction contract can never succeed. Also, the balance

of the user is also traded in the format of an E-contract and blockchain, so

the balance data integrity of the node is also guaranteed.

�

��

� ��

��

(a) Time Consumption of Distributed Key Generation vs Number of Banks.

��

�

��

�

� ��

��

(b) Time Consumption of Trapdoor Collection vs Number of Banks.

Figure 2.3: Setup Efficiency.

�

��

� ��

��

(a) Time Consumption vs Number of Transactions.

�

��

� �� !� "� #� $� �� !� �"� �#� �$� ��

��

(b) Averaged Time Consumption vs Number of Transactions.

Figure 2.4: Transaction Efficiency on Laptop.

2.6 Evaluation

In this section, we present the evaluation of NormaChain based on our

self-implemented blockchain infrastructure. Our evaluation testifies Norma-

Chain in three major aspects, the efficiencies of transaction/supervision,

i.e., the key distribution/trapdoor collection latencies, the transaction/su-

pervision latencies, and the accuracy of supervision.

2.6.1 Evaluation Setup

For evaluation purpose, we fully implemented the NormaChain infrastruc-

ture that can specifically fit the application setting of IoT devices, which

have limited computational powers and weak security strengths. Even

though there are well-known blockchain-based programming frameworks

in the industry such as Ethereum [58], they all create a virtual machine

upon which the developers implement codes. Then the codes are compiled

with memory-safe language compilers or just-in-time (JIT) compilers and

executed under the protection of the virtual machine. Even though this

configuration can guarantee maximized protection in order to defend against

memory corruption attacks, it sacrifices the efficiencies. According to the

demonstrations presented in two recent works [63][44], the authors of both

papers ran Ethereum on a Raspberry Pi, an embedded device running on a

1.4 GHz 64/32-bit quad-core ARM Cortex-A53 CPU, which assembles most

IoT devices on the hardware level, and found that the overhead can reach

up to 10 minutes for one single transaction. Having realized this fact, we

implement the prototype of NormaChain using native languages, i.e., C/C++,

in order to pursue better performance. As a result, we write 3,601 lines of

codes (LOC) in C/C++ to establish the prototype of NormaChain. Then we

configure the project based on CMake [38], a cross-platform building tool so

that our project can be deployed in almost any platforms including Android,

iOS, Linux, Windows, and Mac OS easily1. Finally, we evaluate our tested

prototype on two Raspberry Pis with ARM instruction set which assembles

most IoT devices and mobile devices in the industrial market, and a laptop

running on Ubuntu 16.04 LTE with Intel Core i7-6500U CPU 2.50GHz x 4 1The source codes of our implementation are available on

https://github.com/yinhaoxiao/NormaChain

CPU. And for the following context, our evaluations are conducted with one

buyer, one seller, three approvers (regular banks), 5 to 50 banks for the key

distribution/trapdoor collection efficiency and one supervisor for other two

aspects.

2.6.2 Key Distribution and Trapdoor Collection Efficiency

As a part of DPEKS setup, we conduct two tests to evaluate the efficiency:

time for distributed key generation and time for trapdoor collection. In

the first experiment, timestamps were recorded in an effort to examine

the number of seconds needed for private key distribution across n banks.

Similarly, the second experiment sought to determine the time consumption

when collecting trapdoors from n banks. In this case, the number of banks

tested ranged from 5 to 50 with an interval of 5. Our results from the first

test showed 5 and 50 banks taking 0.19 and 74.23 seconds respectively. In

contrast, our second test only required an additional 0.2 seconds for every

five additional banks. These results match our expectations as the local

test machine could not efficiently handle multithreaded key distribution.

With this in mind, we expect multiple computationally capable machines to

drastically enhance key distribution efficiency. The data for the results are

shown in Figure 2.3.

2.6.3 Transaction/Supervision Efficiency

We evaluated the efficiencies of both conducting a transaction and a key-

word search. For evaluating the efficiency of transactions, we measure the

time elapsed for transactions running in a single thread. We conducted

two sets of experiments: one with the seller and buyer running on the

Raspberry Pis, and the other one with the seller and buyer running on the

�

��

� ��

��

(a) Time Consumption vs Number of Transactions on Raspberry Pis.

� �

��

��!

��"

��#

��$

�

� �� !� "� #� $� �� !� �"� �#� �$� ��

��

(b) Averaged Time Consumption vs Number of Transactions on Rasp- berry Pis.

Figure 2.5: Transaction Efficiency on Raspberry Pis.

�

��

� �� %� �� %� ��

��

(a) Time Consumption vs Number of Supervisions.

��

��!

��"

� �� !� "� #� &� �� !� �"� �#� �&� ��

�� !� $

��

(b) Averaged Time Consumption vs Number of Supervisions.

Figure 2.6: Supervision Efficiency.

laptop. As a result, the time elapsed for one transaction is 0.003466 seconds

for laptop environment and the time elapsed for one transaction for Rasp-

berry Pi environment is 0.008796 seconds. Similarly, the numbers for 10

transactions, 50 transactions, 100 transactions, and 200 transactions are

1.00099/0.572394 seconds, 0.512963/8.6764 seconds, 6.90184/32.301

seconds, and 22.3544/127.718 seconds respectively (with the format lap-

top/raspberry). In other words, despite running on a lightweight laptop

with only a single thread, our implementation is able to complete 288.52

transactions per second (TPS). And running on computationally limited

embedded IoT devices such as Raspberry Pis, we can achieve 113.69 TPS.

This is a very convincing experiment showing M2M trading model autonomy

of IoT devices. The detailed results are shown in Figure 2.4 and Figure 2.5.

For evaluating the efficiency of supervision, we conducted two sets of

experiments. Both experiments were conducted in the laptop environment.

In the first set of experiments, the keywords sent from the supervisor are

not presented in the pre-stored contracts. In this case, the banks have

to perform the worst-case search, i.e., searching all the contracts. In the

second set of experiments, the keywords for searching exist in the pre-stored

contracts. We evaluate these two sets of experiments based on the situations

where there are 1 pre-stored contract, 10 contracts, 20 contracts and all

the way to 200 with an increment of 10 contracts each time. As a result,

for the situation where there is only 1 contract, a keyword search can be

completed in 0.062977 seconds if the keyword does not exist in the contract;

and it can be completed in 0.048097 seconds if the keyword exists in the

contract. Similarly, such numbers for 10 contracts are 0.520825 seconds,

and 0.446612 seconds; the numbers for 50 contracts are 2.5074 seconds

and 2.14615 seconds; the numbers for 100 contracts are 5.69439 seconds

and 4.68922 seconds, and the numbers for 200 contracts are 9.91123

seconds and 8.28285 seconds. The detailed results are shown in Figure 2.6.

2.6.4 Supervision Accuracy

For evaluating the accuracy of supervision, i.e., testing the accuracies of our

implementation based on the DPEKS algorithm, we evaluate our framework

from three aspects, i.e., calculating the overall accuracy rate, calculating

the false positive rate and calculating the false negative rate. We leverage the

same dataset used for evaluating the efficiency of supervision mentioned

above for this evaluation. As a result, as shown in Table 2.1, the overall

accuracies of all the searches are 100%, with 0% false positive rate and 0%

false negative rate. It is worth mentioning that even though the accuracy of

supervision in NormaChain can reach 100% given all illegal keywords, it

does not rule out the possibilities of crimes due to semantics restrictions.

For example, Table 2.2 shows an example where the drug dealers use jargons

instead of standard words to complete a transaction. In this case, the su-

pervisor searches keywords “cocaine” and “drug dealer” to uncover potential

drug transaction, however, the criminals use the jargons “ice” and “juggler”

to circumvent the supervision. Therefore, in the future study, we intend to

study the possible techniques to strengthen our infrastructures, such as

machine learning or NLP for recognizing black keywords demonstrated in

the work of Yang et al [61].

Table 2.1: An Example of a Suspicious Transaction

Message Cat buys cocaine from Dr. drugdealer Target cocaine drugdealer

Ground Truth 0 0 1 0 0 1 Test Result 0 0 1 0 0 1 Accuracy 100%

Table 2.2: An Example of another Suspicious Transaction

Message Cat buys ice from Dr. juggler Target cocaine drugdealer

Ground Truth 0 0 1 0 0 1 Test Result 0 0 0 0 0 0 Accuracy 0%

Chapter 3: Tokoin: A Coin-based Accountable Access Control

Scheme

3.1 Motivation

General access control schemes have been extensively studied for protecting

core systems in computer security. However, existing mechanisms expose

serious design deficiencies such as coarse granularity and weak auditability,

making them much less effective than expectation in defending against

various attacks. These vulnerabilities give rise to insidious overprivilege

attacks that aim to access unauthorized or excessive resources in stealth,

during which it is hard to trace what has happened and who is responsible

for the event. In this paper, we propose Tokoin (Token+Coin), a general

access control framework that instantiates virtual access powers into secure,

atomic, and accountable cryptographic digital coins, termed “tokoins”, and

manage them using accountable state-transition functions. Under our

framework, a user can safely create a tokoin which can be programmed

with fine-grained access policies defining “who is allowed to do what at

when in where by how”. The tokoin is transferrable, and can be modified

by the creator when necessary, realizing a dynamic access control that

can accommodate the ever-changing physical world. Despite this dynamic

flexibility, only the desired subject who possesses the tokoin can redeem

the granted resource when the access policies carried by the tokoin are

completely satisfied. We analyze the security strength of Tokoin with rigorous

cryptographic proofs, fully implement a Tokoin system with blockchain and

well-studied cryptographic primitives, and present a readily available user

platform. We also demonstrate a case study with performance evaluations

where Tokoin is used to enable a secure in-home cargo delivery in which a

tokoin is employed as a highly secure access capability to open the smart

door lock and monitor the delivery activity.

3.2 Introduction

Access control is a regulation procedure to ensure that the access of a

resource strictly follows the access policies defined by the resource owner.

A complete and effective access control scheme should implement the three

processes of Authentication, Authorization and Auditing to make sure that

an authentic subject has been authorized to access the right amount of

resource, no more no less, under verifiable conditions following a fully ac-

countable procedure. Many access control mechanisms have been proposed

in recent years but almost all of them overlook one or more of the goals

mentioned above [59]. Particularly, coarse-graininess and weak-auditability

are two popular shortcomings of the state-of-the-art access control mecha-

nisms, leaving overprivilege attacks wreck havoc in the practical world. In

this paper, we propose TBAC, a novel Tokoin-Based Access Control model,

to realize fine-grained and accountable access control over physical as well

as digital resources.

The principle of TBAC is to give the resource owners full control over the

accesses towards their resources instead of delegating to any third party.

To achieve this goal, TBAC introduces a coin-based access control model, in

which an access power is created, stored, transferred, revoked, and redeemed

in the form of an accountable digital asset, namely a tokoin (token+coin),

which is managed securely and auditably as a cryptographic coin with the

assistance of the blockchain and Trusted Execution Environment (TEE)

technologies. Any user can issue tokoins representing access powers to

its own resources, and any access activity must be granted by redeeming

a tokoin, which relies on a TEE-enabled trusted access control object to

objectively verify the access conditions and monitor the access procedure.

A tokoin carries a fine-grained access policy specified by the resource owner

to define the access conditions to be met and the access procedure to be

followed. We detail TBAC in this paper by making the following contributions.

First, we introduce tokoin, a cryptographically secure digital asset that

is invented by combining token and coin to materialize a “virtual” access

right such that the resource owner can take full control of the access to its

resource, without the need of delegating or relying on any third party such

as a server. A tokoin carries the so-called 4W1H access policy specified by

the resource owner, which defines who is allowed to do what at when in

where by how, where the 4W present the access conditions that must be

satisfied in order for an access request to be granted, and the 1H describes

the access procedure that must be strictly followed. This 4W1H model

provides fine-grained access control as it can not only precisely describe

the access conditions but also capture the contextual relationships among

all access constraints and actions via operators such as Boolean logic. A

tokoin can only be created and revoked by the resource owner, who also has

the exclusive right to define and dynamically modify the access policy of its

resource; thus realizing our philosophy of resource access should be fully

controlled by its owner.

Second, we propose TBAC, a Tokoin-Base Access Control model that

employs a blockchain for secure tokoin storage and atomic tokoin transfer,

and a TEE-enabled reliable access control object (RACO) to verify the access

conditions and monitor the access procedure. TBAC achieves fine-grained

access control by adopting tokoin that defines the 4W1H access policy,

and strong accountability by employing a blockchain to audit all on-chain

tokoin operations and a TEE-enabled RACO to extend trust from on-chain

to off-chain such that all off-chain activities for accessing the resource can

also be securely logged. TBAC realizes the Authentication, Authorization,

and Auditing processes via the tokoin manipulation functions both on-chain

and off-chain (tokoin redemption) and is secure against various attacks

such as tokoin forgery and access policy violation.

Third, we detail all the tokoin function implementations to demonstrate

how the Authentication, Authorization, and Auditing processes are realized

in TBAC. We also provide Go-Tokoin and Ethereum-Tokoin, two prototypes

of the TBAC distributed ledger with the former following the native design

(Tendermint-BFT) for best performance and the latter showing the adaptivity

of TBAC to mainstream blockchain platforms. The TEE-enabled RACO is

implemented in a low-cost ARM Cortex-M33 based microcontroller protected

by the ARMv8-M TrustZone, to securely sample the physical and digital envi-

ronment for access condition verification and access procedure monitoring.

As the Cortex-M series TEE microcontrollers offer very little usable libraries,

we build our RACO system roughly from the bare metallevel, thus facing a

great engineering challenge. A friendly TBAC Android App is designed for

convenience and better user experience. All codes are open-source and are

available at Github.

Fourth, we describe a TBAC-assisted in-home cargo delivery case study

to demonstrate how TBAC is utilized in realworld applications to achieve

its goal of fine-grained and accountable access control. More importantly,

this case study provides a seamless integration of blockchain and IoT to

extend the on-chain trustworthiness to off-chain for reliable access condition

verification and procedure monitoring. This piece of work itself has its own

significance in many IoT applications that require trusted management. On

the other hand, this case study shows that secure and accountable accesses

to physical resources can be achieved by techniques that are used to be

available only to digital resources.

The paper is organized as follows. We first present the most related

work and analyze the existing challenges in Section 3.3. Then we propose

our tokoin based access control model TBAC in Section 3.4 and detail its

implementation in Section 3.5. The TBAC-assisted in-home cargo delivery

case study is presented in Section 3.6. Finally we discuss additional issues

of TBAC and future research in Section 3.7 and conclude this paper in

Section 3.8.

3.3 Related Work

3.3.1 Mainstream Access Control Schemes

There exist many access control schemes that have been extensively studied

and widely deployed. Examples include Role-based Access Control (RBAC),

Attribute-based Access Control (ABAC), Access Control Matrix (ACM), Access

Control Lists (ACL), Capability-based Access Control (CapBAC), just to name

a few. Most of these schemes can be classified into two categories, namely

Access Control Matrix (ACM) and Capability-based Access Control (CapBAC)

[29] [26].

3.3.1.1 Access Control Matrix (ACM)

An ACM refers to a table that lists precise security entries recording which

user or group has which privileges over what resources. These security

entries are also called security references. A reference server stores these

references and upon access request, it looks up the references and judges

whether the access requester passes the reference check or not. Typical

examples of ACM include the Access Control List from the Unix file system,

which defines whether or not a specific user has Read/Write/Execute privi-

leges over a file, and the Role-based Access Control (RBAC), which extends

the minimum subject unit from an individual to a user group. RBAC is

also proved to be equivalent to ACM with respect to the policies they can

represent [49].

Attribute-based Access Control (ABAC) is an improvement over RBAC

that requires more contextual attributes from the access subject, instead of

the simple “who owning an identity or a role” [28]. ABAC permits a variety

of attributes, and combines them with boolean logic to achieve a finer

granularity of access control. One most common industrial implementation

of ABAC is the eXtensible Access Control Markup Language (XACML). As

ABAC requires the policy script to be explicitly stored, typically in an access

control list or a matrix [32][30], we classify ABAC to the ACM category.

Recent studies utilize blockchain to reliably store such security entries.

Blockchain has served as a trustworthy environment for many different

applications, ranging from secure transactions [39] to trusted verifiable

computing [33]. Zhang et al. developed an ACL-based access control scheme

on top of multiple Ethereum Smart Contracts [63]. Their access control list

follows the classical Unix ACL style {Read, Write, Execute} → {Allow, Deny}, and smart contracts make actual access control decisions. Maesa et al.

implemented a blockchain-based ABAC scheme, where a blockchain is

used to record the location of an externally stored ABAC policy. Upon

access, the ABAC system, which is separate from the blockchain system,

retrieves the policy based on which to make access decisions [36]. Zhu et

al. implemented all basic ABAC components on top of a blockchain, and

proposed a transaction-based access control scheme [64] by setting up a

special policy depository server to store and retrieve the policies to and from

the blockchain ledger. The common idea of the above-mentioned schemes is

to use a blockchain as a trusted source of storage for security entries. The

advantage lies in that the reference verification becomes more transparent

and therefore more secure.

3.3.1.2 Capability-based Access Control (CapBAC)

CapBAC makes use of a certificate-like capability (token) to represent the

access privilege. After authentication, the access server issues a token,

possessing which gives right to access certain resources within a certain

period of time. This is more widely used in industry, and the most popular

CapBAC schemes include OAuth, OAuth2, and JSON Web Token (JWT).

Blockchain-based CapBAC schemes were also proposed recently. Ouad-

dah et al. presented FairAccess, which introduces new types of transactions

that are used to grant, get, delegate, and revoke access priviledges [44]. In

FairAccess, a blockchain token is employed to represent authorization out-

puts. Xu et al. proposed BlendCAC, which uses Ethereum smart contract

in replacement of traditional capability access servers to issue and manage

Linux-style access capabilities [60].

3.3.2 Existing Challenges

Both ACM and CapBAC have cons and pros. ACM is featured by precise

definitions of simple access privileges such as read or write, and is easy to

implement for a small scale system. However, as the number of users and the

graininess of access conditions are increased, higher dimensions of data are

needed, making ACM excessively larger and sparser. To keep ACM practically

small, the operations and the policy granularity must be limited. Obviously,

this makes it hard to release a precise amount of resource, hence causing the

rise of the coarse-graininess problem where the access target and method

are defined vaguely. This coarse-graininess is attributed to ACM’s user-

centric nature, and its inability to depict complex contextual relationships.

An exemplary attempt to overcome the coarse-graininess challenge is ABAC,

as it adds more attributes and permits contextual relationships among the

attributes through boolean logic combinations. Note that ABAC is close to

a satisfactory solution against coarse granularity, but it suffers from high

complexity and verbosity, making it increasingly dim for future worldwide

adoptions [4][35]. 1

Obviously when an access control scheme suffers from coarse granu-

larity, it is easy to release more resource than one needs. This gives rise

to the so-called overprivilege challenge, which refers to the low expressive-

ness of the access policies [24]. It is formally defined as a vulnerability

where a subject receives excessive access privileges, and has been an open

challenge and a popular research topic for a long time [54][18][51]. Felt

et al. found that overprivilege vulnerabilities exist in over one-third of the

total Android-driven IoT devices [16], and Fernandes et al. reported that in

Samsung SmartThings platform over 55% of SmartApps are overprivileged

due to access control coarse-graininess [17]. Zhang et al. discovered that

attackers can create malicious apps on the Amazon skill platform to perform

overprivilege attacks and conduct eavesdropping activities through Alexa

affecting ordinary people’s life [62]. Such attacks have occurred repeatedly 1We claim that a fine-grained access policy should define who is allowed to do what in

where at when by how. We call this 4W1H principle, and ABAC’s policy can be simplified and captured by this 4W1H model.

on many off-the-shelf products such as Amazon Alexa and Google Home all

over the United States, and have been reported by many mainstream public

media [56] [53] [13]. One can see that overprivileged accesses wreak havoc,

thus effective solutions are desperately needed.

The overprivilege problem is further worsened by weak auditability, where

an access scheme fails to audit all access activities. As most access auditing

logs are recorded on the victim device, an attacker can use the excessive

control power obtained from unauthorized or overprivilege attacks to easily

(and in fact, commonly, found by Cozzi et al. [14]) delete the true access ac-

tivity log evidence without being noticed. To make things even worse, a large

portion of devices and platforms such as Nest and Samsung SmartThings

in practice, even do not log access activities [50].

CapBAC provides an unforgeable certificate-like capability (token) to prove

an entitled access power. It also suffers from the coarse-graininess problem

and the overprivilege challenge. Note that the emergence of access tokens

does not necessarily mandate a fine-grained access policy. In practice, the

overprivilege challenge is so fierce that an OAuth token issued to access one

photo in the smartphone can practically be used to access all photos [19].

CapBAC is also vulnerable to the weak auditability problem. For most

mainstream projects and standards, once an access capability is issued,

no constraint is placed to protect the use of such capability – the access

privilege is technically unlimited. We take the most popular and most

widely used CapBAC protocol OAuth 2.0 as an example (OAuth 1.0 is

proved to be unsecure and deprecated [25]): after initial authorization, the

OAuth protocol creates a non-cryptographic token and transfers it through

SSL/TLS to the subject, requiring the subject to be responsible for keeping

the token confidential. Nevertheless, in all CapBAC schemes, whoever

possesses the token is assumed to be the legit access subject, and can

access the resource without further authentication and auditing. As a

result, it is easy to impersonate or steal a token to perform unauthorized

accesses without being detected [27] [17]. This implies the inability of

flexibly transferring or delegating an access privilege to a legit subject in

CapBAC, as there is no standardized transfer method that can audit the

process and guarantee authenticity.

In summary, due to the lack of an accountable and fine-grained access

control scheme, an ordinary adversary can easily over-access the desig-

nated resources, or even perform unauthorized accesses. Such attacks are

worsened by the inability to audit and alarm access activities. Nevertheless,

weak auditability problem is common and has not been attracted sufficient

attention in both academia and industry.

Most countermeasures that attempt to mitigate the overprivilege chal-

lenge are based on security analysis, in which the overprivilege vulnerabil-

ities are inspected as programming deficiencies and are identified based

on the learned characteristics. Fernandes et al. uncovered a severe over-

privilege vulnerability in the Samsung SmartThings platform, which allows

attackers to falsely turn on a fire alarm [17], but they did not propose any

effective defense mechanism. Jia et al. presented a graph-based algorithm

to automatically excavate the overprivilege weaknesses in a smart home

system [31]. Celik et al. hand-crafted 20 common flawed apps, based on

which a model-checking based solution was developed to automatically

identify the flaws [11]. In summary, all the mechanisms mentioned above

mitigate the overprivilege challenges from a security perspective, which is

to first discover the vulnerabilities, then learn features from them, and

finally detect their presence in a general environment. Nevertheless, their

false-negative rates of vulnerability detection are usually high and newly

emerging vulnerabilities (zero-day vulnerabilities) are hard to identify based

on existing approaches.

Existing blockchain based ACM and CapBAC are intuitively simple mar-

riages of blockchain and the corresponding schemes, thus suffering from

the same open challenges. For example, FairAccess cannot guarantee the

fine-graininess of the access policy, its access activities may not comply with

the policies, and its tokens can be used unlimitedly without any restraint

[44]. BlendCAC proposed by Xu et al. [60] shares the same weakness as

FairAccess: it uses Linux style coarse-grained access policy and cannot

restrain unlimited token use. The blockchain-based ACL scheme proposed

by Zhang et al. employes Ethereum smart contracts to host Linux style

access policies, also leaving the coarse-graininess challenge unsolved. Fur-

thermore, it cannot restrain the access in an auditable way [63]. One can

see that the overprivilege and weak-auditability challenges remain open in

existing blockchain-based schemes.

The status-quo urges us to ponder the following question: can we design

an accountable and fine-grained access control scheme that can precisely

define the access privilege and meanwhile enforce high auditability for all

operations towards an access activity? To answer this question, we strive to

design a secure, accountable and fine-grained access control scheme that

allows owners to have cryptographic level security confidence over the uses

of their resources without crossing the access policy boundaries defined

by themselves. We leverage blockchain and cryptographic primitives to

instantiate access capabilities into secure and accountable cryptographic

assets, namely tokoins. A tokoin carries the access policy specified by the

resource owner, which defines who is allowed to do what in where at when

by how to clearly describe the access conditions to be met and the access

procedure to be followed. It can only be created, modified, and revoked by

the owner of the resource, and be redeemed by a legit subject. A tokoin

cannot be easily forged as it is protected by provably secure signatures and

the blockchain consensus. Mandatory auditing over all access activities

is also enforced and secured by the blockchain system and a TEE-enabled

robust access object, whose design effectively extends the on-chain trust

to off-chain such that all off-chain activities related to the access policy

compliance verification and the access procedure itself can be securely

logged and properly stored.

3.4 TBAC: Tokoin-Based Access Control

Tokoin-Based Access Control (TBAC) is a general access control model that

employs cryptographic coins to represent access privileges. Tokoin is termed

by combining “token” and “coin”, for the purpose of materializing access

capabilities as atomic, accountable, and transferable digital assets. In this

section, we first present our design goals, security assumptions, and threat

model, then we detail our TBAC model.

3.4.1 Design Objectives, System Assumptions, and Threat Model

3.4.1.1 Design Objectives

The major objective of TBAC is to provide a flexible and general access

control model that can offer fine-grained and fully-accountable control over

the access of private digital or physical resources. TBAC should be flexible

enough to support simple access control tasks that mainly require identity

authentication, as well as complex ones that require external environment

data inputs. It should be able to precisely define who, what, where, when,

and how, the five critical elements that determine the fine-graininess level

of an access control scheme, to answer the question of who is allowed to

do what in where at when by how. This is termed as the 4W1H access

policy, where the four W ’s specify the access conditions that must be met

in order for an access request to be granted while the H describes the exact

access procedure that must be strictly followed during access. Only the

resource owner has the right to define and modify a 4W1H access policy,

and its five elements can be dynamically changed such that the owner can

flexibly control the access to its resource at its own will. In TBAC, this

4W1H access policy is minted into a tokoin, and within its whole lifetime,

all actions towards the tokoin are securely logged for auditing purpose.

TBAC should comply with the AAA requirements, i.e., it must clearly and

precisely define the Authentication, Authorization, and Auditing processes

that should be implemented by all complete secure access control schemes

from the information security perspective [48]. The Authentication process is

an act of establishing or confirming the identity or capability as authentic;

the Authorization process determines whether a person or a process is

authorized to perform a given access activity; and the Auditing process logs

all access events that have security significance.

3.4.1.2 High-Level System Requirements

To achieve the objectives mentioned above, TBAC makes two important

system requirements to assure security.

First, TBAC relies on a database that supports secure tokoin storage,

atomic tokoin transfer, and accountable activity auditing. Such properties

are very similar to what blockchain can provide. As a result, blockchain is

adopted in TBAC. More specifically, the existence of a blockchain system

that is provably secure for trusted storage (fork-free) and state transitions is

assumed by TBAC. It is employed to manage all operations over a tokoin as

transactions such that the tokoin can be securely stored and all (on-chain)

activities over it can be logged for auditing purpose.

Second, TBAC requires a reliable access control object (RACO) that works

on behalf of the resource owner to verify tokoin capability validity, check if

the fine-grained access conditions are met, make actual access decisions,

and monitor access procedures. This requires an RACO to have secure

connections with the blockchain for tokoin reception and the resource

for access control. Considering the AAA requirements, RACO needs to

establish a trust environment that directly extends that of the blockchain,

i.e., extending trust from on-chain to off-chain, such that one can be sure

that the access policy carried by a tokoin is strictly followed during access

and all access-related activities are securely logged. To achieve this objective,

we adopt a Trusted Execution Environment (TEE), a special kind of trusted

hardware that has a tamper-proof area for secure programs, to host the

RACO and other secure software in TBAC for information collection to realize

secure and accountable access control.

Conceptually, TEE is a tamper-resistant processing environment enabling

isolation and secure storage within a chipset [47]. Technically speaking,

a TEE implements fundamental functions such as secure boot, runtime

isolation, secure storage, secure scheduling, trusted I/O, and trusted re-

mote management. The program executed in TEE resists software attacks

as well as physical tampering such that the authenticity, integrity, and

confidentiality of the codes and runtime states are guaranteed. In this

paper, we assume that long-range vulnerabilities do not tamper programs

within the TEE secure zone, and that any local program can be executed as

expected. However, physical damages and attacks towards TEE hardware

are out of the scope of this paper, thus will not be considered.

3.4.1.3 Threat Model

In this paper, we consider a general but powerful adversary A who knows the details of the TBAC construction procedure, has access to all public

functions, and can read public requests and messages. A may compromise a fraction of the participants but this fraction is not large enough to thwart

the normal secure operations of the underlying blockchain system. It aims

to perform an overprivileged access (an unauthorized access is deemed as

a special kind of overpriviledged access) to the private resource. In practice,

this adversary can be a remote attacker that can penetrate the local network,

or a local attacker, or the hosting access server of the resource, which are

popular in the current IoT industry.

�

��

� ��

��

�� !�"��#�$ ��%

��&��$��

Figure 3.1: Overview of Tokoin-based Access Control Model

3.4.2 The TBAC Description

3.4.2.1 Entity Roles in TBAC

Typically an access control scheme consists of the following entity roles.

An owner owns a piece of private resource D, which could be a hardware

device or a software program. The owner authorizes a subject to access its

resource under a series of restrictions including access conditions and an

access procedure, which together define the access policy. In TBAC we have

a more refined definition of the entity roles, denoted by R = {rO,rS,rC,rACO}, where rO is the resource owner who issues a tokoin t along with an access

policy t.policy for its resource D, rC is the circulator, who must be the current

holder, of the tokoin t that helps transfer t to a legit subject rS. An access

control object rACO is the local robust access control module that actually

controls the access to D on behalf of rO. Upon subject rS’s tokoin redemption

request, rACO verifies if the tokoin capability is valid and if the conditions

required by the access policy are met; and if yes, grants the access to rS

and monitors the access procedure. Note that rC, the circulator and current

holder of t, could be the rO, or a rS, or any other legitimate participant in

TBAC. Also note that rS does not have to be one specific participant – it

could be a group of participants possessing certain legitimacies to access

the resource D. We further emphasize that the minimum atomic access

privilege in TBAC is a tokoin capability, which is an actual instantiation of

the privilege. Within a tokoin access activity, a participant can only have one

role. However, it can participate in multiple activities of different tokoins,

thus can have a different role in each respective activity at any instant of

time. In TBAC, a participant can be uniquely identified by its address or a

public key issued by the system.

3.4.2.2 TBAC Description

The principle of TBAC is to let the resource owner completely control the

access privileges over its resources. To achieve this goal, TBAC manages

the access control powers in the form of secure, atomic, accountable and

policy-programmable cryptographic coins. This approach is featured by four

properties: only the resource owner can create, modify, or revoke a tokoin in

order to completely control the access to its resource; the current holder of a

tokoin can atomically transfer the tokoin and only a legit subject can redeem

the tokoin; all conditions required by the access policy must be met upon

redemption and the exact access procedure defined by the access policy

must be strictly followed for correct resource access; all access activities

must be audited and managed in a secure, accountable, and fine-grained

way.

Fig. 3.1 illustrates the operations of our TBAC model. When the owner

rO of resource D wants to authorize a subject rS to access D, rO drafts an

access policy and securely creates a tokoin. Then the owner rO transfers

the tokoin to the first circulator rC, as demonstrated by the Authorization

Process 1 in Fig. 3.1.

The tokoin circulator rC, if it is not the final subject, accountably transfers

the tokoin to another participant when needed. This can help the resource

owner to deliver the access capability to a legit subject, or dynamically

delegate a different group of subjects to access its resource during the

tokoin transfer process as the resource owner can modify a tokoin before it

is redeemed (labeled by a ∗ in Fig. 3.1). However, although the transfer of a tokoin is allowed between any two participants, the final tokoin redemption

must be performed by a legit subject. By this way one can permit a great

access privilege management flexibility while still guaranteeing that the

final access activity strictly follows the owner’s discretion. This can motivate

new methods in physical resource management such as allowing secure

resource rent, trading of hardware/software resource right-of-use, or as-

signing someone to run an errand more flexibly. We provide a case study

where autonomous secure in-home parcel deliveries are enabled for the

convenience of ordinary people. This is the Transfer Process 2 in Fig. 3.1.

Finally, when a legit subject rS possesses the tokoin and wishes to redeem

for resources, the redemption process checks if all conditions defined in the

access policy are met to ensure that it is indeed a legit subject to access the

right resource under correct conditions. The redemption process also needs

to monitor the access procedure, if defined by the access policy, to make

sure that the procedure is strictly followed. Such a design can guarantee

that despite the flexibility of the access power transfer process, the final

redemption must follow user-defined access rules. Any violation per the

access policy renders the access fail. This is the Redemption Process 3 in

Fig. 3.1.

We would like to emphasize that an access policy carried by a tokoin

can be flexibly defined at any graininess level per the resource owner’s

preferences/needs, by inputting values at different granularity to the who,

what, where, when, and how fields. Moreover, the who field in the access

policy can specify a group of legit subjects to access the resource as the

resource owner may not be aware of the exact subject when the tokoin is

minted. Additionally, the owner can modify any component of the access

policy in a tokoin or simply revoke the tokoin as long as it is not redeemed,

providing strong fine-grained control over its resource access privileges

at any instant of time. On the other hand, one can see that TBAC is

applicable to the access controls over both digital resources as well as

physical resources, as the five fields of a 4W1H access policy model do not

rely on any resource-specific feature. Nevertheless, as a general fine-grained

access control model, TBAC needs to be instantiated differently for different

applications. We detail the TBAC implementation in the next section and

present a case study to demonstrate its applications in Section 3.6.

3.4.2.3 The Properties of a Tokoin in TBAC

To achieve the goal of providing fine-grained accountable access control, a

tokoin in TBAC must possess the following properties:

Security : A tokoin materializes a secure and accountable access power in

the form of a cryptographic coin. It cannot be falsely created, tampered

with, used, or revoked by an adversary.

Atomicity : The transfer of a tokoin requires the simultaneous arrival at the

receiver and removal from the sender, making it hard to double-redeem

the tokoin.

Strong Auditability : All current or historical activities over or changes

to a tokoin, as well as all activities during the access to the resource

based on the policy carried by a tokoin, are securely audited.

Fine-Grained Access Policy : The access policy carried by a tokoin speci-

fies 4W1H such that a user can precisely describe all access details in

the tokoin by carefully defining the access constraints that must be

satisfied and the access procedure that must be strictly followed. The

fine-graininess level is exclusively determined by the resource owner.

Direct Access Privilege Sovereignty : The access privilege over a resource

can only be defined and issued by the resource owner via a tokoin at

its discretion when needed, without any intervention of any third party

access server.

Transferability of Access Power : A tokoin can be transferred from one

holder to another through a properly audited procedure, if needed.

Access Policy Compliance : Only legit subjects defined in the access pol-

icy (the who) are allowed to access the resource when access conditions

are satisfied and the access procedure must be followed.

Dynamic Access : The access privilege carried by a tokoin can be modified

or revoked at anytime and these actions should be performed only by

the tokoin owner.

Access Time Restriction : Obviously, the number of times a tokoin is

allowed to be redeemed can be easily specified by the access policy,

successfully preventing the tokoin from being unlimitedly used.

Access Policy Privacy : The access policy carried by a tokoin can be pro-

tected via attributed-based encryption such that only the designated

subject or subject groups can decrypt the policy for privacy protection.

One can see that there exist five operations over a tokoin: Create, Transfer,

Modify, Revoke, and Redeem. When a tokoin t needs to be created, the resource

owner sends an authenticated Create message carrying the access policy to

the blockchain, which verifies the message, creates a tokoin and assembles

it as a transaction, then places it into the next block. When t needs to be

transferred, modified, revoked, or redeemed, a corresponding authenticated

message needs to be sent to the blockchain, commanding the blockchain

to transfer, modify, revoke or redeem t. More specifically, all the tokoin

manipulation functions are performed on-chain by passing authenticated

messages, and each operation is recorded as a transaction such that all

operations over a tokoin can be securely logged for auditing purpose.

Note that the AAA processes are realized by the five tokoin manipulation

functions with the assistance of the underlying blockchain and RACO via

authenticated messages in TBAC. In the following section we present a

detailed implementation of these tokoin manipulation functions to illustrate

how AAA are achieved.

3.4.2.4 Security Discussions

Intuitively, TBAC may suffer from two attacks: tokoin forgery and access

policy violation. As mentioned in Section 3.4.1.2, TBAC makes two system

requirements: 1) a blockchain distributed ledger that is provably secure to

support trusted storage and atomic state transitions; and 2) a reliable access

control object rACO that can securely retrieve access policies from a tokoin in

blockchain, make access decisions according to the access conditions, and

monitor the access procedures. As all operations of a tokoin are performed

on-chain and all messages are authenticated via provably secure signatures,

the first requirement guarantees that an adversary cannot forge a tokoin by

spoofing a legitimate signature to create a tokoin for or transfer a tokoin to

itself, or fork a chain to include its own tokoin making the forked chain a

legitimate one. On the other hand, the second requirement ensures that

the access policy defined by the resource owner is strictly followed, no more

no less. Based on these considerations, one can safely conclude that TBAC

is secure against tokoin forgery attacks and access policy violation attacks.

3.5 TBAC System Implementation

In this section, we detail an implementation of the TBAC model. We first

provide a system description on TBAC, then present its Authentication,

Authorization, and Auditing processes, and finally describe a native and

a more adaptive TBAC prototype implementations, followed by an Android

App for regular users.

3.5.1 TBAC System Description

TBAC employs a blockchain to fulfill the security requirements of secure

tokoin storage, atomic tokoin transfer, and accountable activity auditing,

and a trusted execution environment (TEE) to collect trusted environment

evidence and make correct final access control decisions.

3.5.1.1 Primitive Elements and Functions

A tokoin t = (tID, pkO, pkH,policy,isValid), where pkO and pkH are respectively

the public keys of the owner and current holder of t, tID is a number uniquely

identifying t among all the tokoins generated by the owner pkO, policy defines

who is allowed to do what by how in where at when, and isValid is a binary

indicator with isValid = 1 if and only if t is still valid (not redeemed and not

revoked). Note that a tokoin t is uniquely identified in TBAC by the two-

tuple pkO and tID, denoted by pkO||tID, as two tokoins generated by different participants may have the same tID. For conciseness, isValid is omitted and

t is used instead of pkO||tID to identify a tokoin, if clear from context. A fine-grained access policy answers who is allowed to do what at when

in where by how, where who is a legit subject that may not be known before

tokoin t is minted, thus we employ a cryptographic Accumulator in t.policy

to define a group of subjects who are allowed to redeem t and access the

resource what. The spatio-temporal access constraints, i.e., when and

where, can be sampled from a device such as a GPS receiver at redemption.

The access procedure is strictly defined by how, which can be specified by

atomic actions to manipulate the resource. Whether or not such a procedure

is strictly followed can be monitored by a software program or a hardware

device such as a video camera. Note that one can have multiple atomic

actions and constraints as well as their relationships (e.g., “and”, “or”,

“not”) defined in policy, capturing the contextual relationships, to precisely

describe under which condition and how the resource should be accessed,

as CapBAC does, to realize access control at the user-defined graininess

level.

TBAC relies on a blockchain public ledger for secure storage and atomic

state transfer. The ledger is maintained by all the blockchain nodes partici-

pating in consensus and block construction. A tokoin is stored on-chain

and all the tokoin manipulation operations are performed on-chain via

function calls that are realized by passing messages, i.e., the function caller

sends a message to all blockchain nodes for tokoin Create, Transfer, Modify,

Revoke, and Redeem. All the messages must be signed by the function caller’s

secret key and all blockchain nodes receiving the message must first verify

its authenticity based on the carried signature. In TBAC, a message from

caller pki has the following format:

msg : [t,op,{policy},{pk′}]σpki (3.1)

where op is the operation code that distinguishes which function to be called

for tokoin t, the braces contain optional information, with {policy} holding a

valid policy if op = create or modify and {pk′} being a new receiver’s address if op = transfer, and σpki is the message signature signed by the secret key

of the function caller pki for message authenticity verification. Note that the

message actually includes the composite ID pki||tID of t but we use t instead of pki||tID here for better clarity.

Owner Circulator Subject

�� create tokoin �

��

� ��

revoke tokoin

modify tokoin � � ��

transfer � to any ��

transfer � to �� Check constraints

Tokoin Protocol

SubProtocol: PolicyCheck

receive � from ��

transfer � to ��

validate �, parse policy check constraints

transfer to first ��

Loop

Par

�

Access Control Object

Alt

Notify �

Check constraints Alt

monitor access procedure

if constraints are not satisfied reject access, transfer � to ��

if constraints are satisfied grant access, continue

if violations detected record evidence,

upload and terminate

if no violations detected success, record evidence,

upload and finish

Figure 3.2: The Full TBAC Protocol Sequence Diagram

Definition 5. For a set of participants ¶ = {P1,...,Pn}, TBAC defines the following nine functions:

Gen: The function Gen generates keys for the participants in TBAC. When

called by participant Pi ∈ ¶, Gen produces a public/secret key pair (pki,ski), returns ski to the caller and broadcasts the corresponding public key pki to

all Pj ∈ ¶. Note that pki can be used to uniquely identify Pi. Verify: The function Verify supports overloading. On inputs of σ and pk,

it outputs 1 if and only if signature σ was indeed signed by participant pk;

on input of t, it outputs 1 if and only if tokoin t is still valid (t.isValid = 1);

and on inputs of t, pk, and role, it outputs 1 if and only if participant pk

holds the role in tokoin t.

Create: The function Create creates a new tokoin t. On input of an access

policy, it outputs a tokoin t = (tID, pki, pki,policy,isValid=1) to the caller Pi,

who then acquires role rO.

Transfer: The function Transfer transfers a tokoin t to a different holder.

When called by participant Pi ∈ ¶, it requires Verify(t, pki,rC) = 1. On inputs of a receiver pk j and a valid tokoin t = (tID, pkO, pki,policy), it modifies t to be

(tID, pkO, pk j,policy), i.e., changing the current holder of t from pki to pk j, who

then acquires role rC.

Modify: The function Modify modifies the access policy of a tokoin t.

When called by participant Pi ∈ ¶, it requires Verify(t, pki,rO) = 1. On inputs of a valid tokoin t = (tID, pkO, pkH,policy) and an updated policy policy∗, it

modifies t to be (tID, pkO, pkH,policy∗).

Revoke: The function Revoke revokes a tokoin t. When called by par-

ticipant Pi ∈ ¶, it requires Verify(t, pki,rO) = 1. On input of a valid tokoin t it outputs a null tokoin ⊥ with isValid = 0.

Redeem: The function Redeem allows Object rACO to redeem resource D.

When called by participant Pi ∈ ¶ with tokoin t, it requires Verify(t, pki,rS) = 1. On input of a valid tokoin t, it releases resource D and revokes t if

PolicyCheck(t.policy) = 1; otherwise, it transfers t back to rS.

PolicyCheck: The function PolicyCheck samples the current digital or

physical environment and verifies whether the redemption conditions and

procedure are completely satisfied. On input of t.policy, it returns 1 if and

only if all the access conditions are met and the access procedure is strictly

followed.

Auditing: The function Auditing logs all activities (mainly the function

calls of Gen, Create, Transfer, Modify, Revoke, and Redeem) and writes them as a

script into the corresponding transactions on the blockchain public ledger.

Among these nine functions, Gen is used during participant registration,

Create, Transfer, Modify, Revoke, and Redeem are used to manipulate a tokoin,

Auditing is called by all the above six functions before their returns to log all

activities for auditing purpose, Verify is called by the five tokoin manipulation

functions to ensure authenticity and operation privilege, and PolicyCheck is

called by Redeem only for redemption policy verification.

A participate can be a regular blockchain node or a user who is able

to talk with the blockchain via a secure channel. Whenever a participant

needs to Create, Transfer, Modify, Revoke, or Redeem a tokoin, a signed message

is sent to the blockchain who then verifies the message authenticity. The

capability of the function caller also needs to be examined before tokoin

manipulation. A tokoin stays on-chain before being redeemed and a new

transaction is issued whenever a function call is made for a tokoin operation.

The transaction contains the tokoin as well as a script describing the calling

message and the activities caused by the operation for auditing purpose.

The nine functions defined above constitute a complete TBAC scheme

that complies with the AAA standard mentioned earlier to control the uses

of the resource D. The Authentication process comprises the functions

Verify and PolicyCheck, with Verify essentially verifying the function caller’s

identity as well as its tokoin capability and PolicyCheck authenticating the

current policy upon access. The Authorization process is made up of five

functions Create, Transfer, Modify, Revoke, and Redeem, with Create creating a

tokoin defining the access privilege while Transfer, Modify, and Revoke making

proper modifications to the tokoin capability, and Redeem finally taking

back the tokoin capability and redeeming the agreed resource. Function

Auditing implements the Auditing process, making accountable audits over

all activities and modifications to the access tokoin.

A full graphical illustration of our TBAC system protocol is illustrated in

Fig. 3.2, which shows a chronological sequence of all the functions defining

AAA. More specifically, a blue vertical rectangle represents a tokoin under

certain operation while the blue vertical line it resides in indicates who

possesses the tokoin; and a small cross says that the tokoin becomes invalid

(t.isValid = 0) or successfully redeemed. We also have a few keywords in

Fig. 3.2, with Loop meaning that all functions within the box can repeatedly

happen, Par signaling that any of the operations in the small box can be

executed, and Alt indicating an if-else branch. In the following subsections

we outline our TBAC building blocks, detail the designs of the AAA processes,

and present our prototype implementations.

3.5.1.2 Building Blocks

In our TBAC implementation, we utilize multiple key cryptographic prim-

itives that are previously proved secure and computationally accessible.

They are carefully chosen to fulfill TBAC’s security requirements while not

over-qualified for the tasks and not increasing unnecessary overhead.

Tendermint-BFT: TBAC runs on top of a blockchain system. We select

a consortium (permissioned) chain setting in which the blockchain security

largely relies on the consensus process (we don’t consider network layer

attacks). For the best collective reliability, we choose Tendermint-BFT as

our consensus algorithm. Tendermint-BFT belongs to the Byzantine Fault

Tolerance (BFT) consensus family, and it is an improved version over the

popular Practical-BFT (PBFT). Ordinary BFTs like PBFT must know the

total number of participating nodes a prior, and may also suffer from Sybil

attacks. Tendermint-BFT addresses these challenges by assigning different

weights to different validator nodes (where PBFT basically assumes the

same weight for every node). The weights can be quantified by stakes, or

other resources or self-defined security indices. This provides both flexibility

and reliability as the security anchors can be carefully selected to enhance

performance. Tendermint-BFT is secure (and fork-proof) when less than

one third of the nodes are malicious, according to the security proofs in

Buchman et al. [10].

Digital Signature: Digital Signature allows anyone to verify whether

a message is indeed signed by the claimed signer, and is not altered in

transit. Our actual TBAC implementation employs ECDSA following the

NIST standard because it uses a shorter 256-bit key and has a lighter

computation burden compared to the RSA-backed DSA, thus especially

suitable for embedded systems. In TBAC, signatures are adopted to verify

function callers’ identities for the purpose of granting them different tokoin

manipulation privileges.

Cryptographic Accumulator: Cryptographic Accumulator is an active

research topic in cryptography. It describes a set of public keys with a short,

verifiable signature. Given a public key, it can efficiently verify whether

or not this key is a member of the group. In TBAC, we make use of a

cryptographic accumulator to authenticate a dynamic group of subject

identities – we do not need to define the exact subject who is allowed to

finally redeem the tokoin, but rather specify a group of subjects. This is

reasonable as we might not know who is the final subject when we mint

a tokoin. As shown in our case study, the subject must be a licensed

deliveryman but it is hard to know ahead of time the exact deliveryman

who actually redeems the tokoin. Therefore we do not appoint an exact

deliveryman when the tokoin is created; instead, we employ a crptographic

accumulator to specify a group of licensed delivery men who can be legal

subjects to redeem a tokoin. Technically, a cryptographic accumulator is

usually implemented by a strong one-way hash function that satisfies the

commutative law.

3.5.2 Authentication, Authorization, and Auditing Processes

3.5.2.1 Authentication

The Authentication process verifies the authenticity of an identity or a tokoin

capability in TBAC. In service of the Authorization process, the Authentica-

tion process in TBAC makes use of functions Verify() and PolicyCheck().

Implementation of Verify(). As mentioned in Section 3.5.1.1, Verify()

is an overloading function that performs the tasks of verifying a message

signature, a tokoin validity, or a participant’s access privilege over a tokoin.

To verify a digital signature, Verify() takes inputs σ and pk, and outputs 1

if and only if σ was indeed signed by pk according to ECDSA. To verify the

validity of a tokoin t, Verify() takes input t and outputs t.isValid. If Verify()

takes inputs t, pk, and role i.e., to verify the role of participant pk in t, we

need to consider two different cases:

• if role = rS, i.e., pk’s subject role needs to be verified, Verify() needs to

check the cryptographic accumulator acc stored in the access policy

carried by t and return 1 if and only if pk is indeed a legitimate subject

for t;

• if role �= rS, Verify() returns 1 if and only if t.pkO = pk if role = rO, or t.pkH = pk if role = rC.

Verify(t, pk,role) must be called by all the tokoin manipulation functions

(except Create) as role defines the privilege of a participant over tokoin t. For

example, Redeem should be called only by a legit subject while only the owner

of a tokoin can modify the tokoin. Note that separating the verification of a

tokoin holder and a legit subject is a good idea because we do not restrain

the transfer of a tokoin, but we do have a clear definition on the subjects.

In other words, there could be a case where the tokoin is transferred to a

wrong participant who is not a subject, but we permit only legit subjects to

access.

The implementation of PolicyCheck() requires a secure and reliable access

control object rACO that samples the current environment to verify whether

the access constraints are satisfied and whether the access procedure is

strictly followed. It is essentially a trusted data intake source that is external

to the blockchain system. In TBAC, we employ TEE to host rACO as it provides

a trusted execution environment that physically isolates security-sensitive

programs to prevent them from being tampered with.

To fully implement PolicyCheck(), we need the object rACO to do two things:

to securely collect the evidence from the physical or digital environment

upon receiving the tokoin redeem call, and to securely communicate with

the blockchain system, parse the tokoin to extract the access policy, and

then compare the policy carried by the tokoin with the evidence collected

from the environment to decide whether the access constraints are satisfied

and whether the access procedure is strictly followed.

Collecting evidence from the TEE environment is not trivial. A possible

approach is to implement the drivers of the monitoring devices for evidence

collection in the TEE secure zone and connect them directly to the external

corresponding physical devices, to make sure that the devices can collect

correct and authentic data without suffering from data interception or

alteration. For example, in our case study, we implement the driver of

a GPS receiver to verify the spatio-temporal access constraints and that

of a camera to monitor the access procedure in a TEE hardware plugged

into the sensor controller. Note that for a more complicated application,

multiple controllers with the TEE hardware can be connected via secure

protocols such as SSL/TLS to monitor a large environment. Under the

security assumption that the TEE secure zone is physically isolated and

tamper-free, one can safely accept the evidence as it is directly and securely

captured.

Next we implement the access control object rACO as a blockchain client

inside the TEE secure zone to ensure that it can directly communicate with

the blockchain network through a secure communication channel supported

by existing techniques such as SSL/TLS. Such a design allows rACO to work

independently as a light-weight blockchain node that does not participate

in ledger maintenance and consensus but can listen on the network layer

messages without relying on any unreliable proxy. After securely fetching

the access policy t.policy from tokoin t, rACO first checks whether the redeem

request does come from a legit subject. This can be done by verifying

whether the subject is a member defined by the Accumulator in t.policy. Then

rACO checks whether other access constraints such as the spatio-temporal

constraints are satisfied by sampling the corresponding devices, and if yes,

rACO grants the access by starting the access procedure, which first converts

the actions defined in t.policy into instructions to make the resource available

to the subject. During this procedure rACO keeps on communicating with

the resource to be accessed and meanwhile sampling the monitoring devices

to ensure that the access procedure is strictly followed. If any violation is

detected during the access procedure, the access is immediately stopped

and appropriate measures are taken. It is all to these implementation

considerations that make rACO securely verify whether the access constraints

and procedure are met upon redemption. Note that all activities involved in

PolicyCheck() are recorded in the TEE secure zone and will be logged in the

blockchain as the transaction script when Redeem() is completed.

3.5.2.2 Authorization

��

�� pk ��pk

��

transaction …

��

�� pk ��pk

��

tokoin …

��

�� pk ��pk

��

tokoin …

��

transaction …

Figure 3.3: Block Structure and URPO

As mentioned earlier, an Authorization process determines whether a

person or a process is authorized to perform a given access activity. In

TBAC, this process grants a privilege to access the resource, modify the

privilege, or redeem a tokoin under correct access policy. It includes the

following five functions, whose implementations are detailed in sequel:

1. Create(): create a new tokoin;

2. Modify(): modify the access policy of an existing tokoin;

3. Transfer(): transfer a tokoin to another participant;

4. Revoke(): revoke a tokoin;

5. Redeem(): take in a tokoin and redeem the resource.

The implementations of these five functions require explanation of the

storage of tokoins. As said earlier, a tokoin should be stored securely

and can be transferred atomically. To achieve this goal, we develop the

UnRedeemed Policy Output (URPO) model, which is similar to Bitcoin’s

UTXO model, to manage the tokoins in the distributed ledger. Any operation

over a tokoin, including the creation of the tokoin, starts from a message

sent to all blockchain miner nodes for verification and consensus approval.

If successful, the process takes in an existing tokoin if available, performs

the operations as requested, and stores the processed tokoin in the next

block within the ledger. This whole process is called a policy transaction, and

its output is either a newly created tokoin for Create or a modified one with

the same tID and pkO as the input tokoin. As long as this policy transaction

output is not redeemed or revoked, the tokoin remains valid (t.isValid = 1).

The main purpose of this design is to maintain high atomicity and ac-

countability of the tokoin operations, which implies that only atomic and

one-to-one transitions can be allowed to operate a tokoin. Each transac-

tion must be verified by all validating nodes in the blockchain with public

knowledge, and no tokoin can be forged or forfeited out of thin air. The block

structure is illustrated in Fig. 3.3. Each block contains a number of tokoins

and each tokoin contains its native information as well as a TX Script field

logging the corresponding message for and activities over the tokoin. An

access policy within a tokoin is represented in the form of JSON key-value

pairs for its simplicity [5, 2], as illustrated in Fig. 3.3. One can see that

such a structure allows users to flexibly define their own access policies at

different granularity levels.

Any registered participant can create a tokoin, as long as it represents it-

self and issues access only to its own resource. To make a tokoin Create() call,

the participant sends out a message msg : [pkO||tID,create,policy]σrO signed by its secret key skO to the blockchain system, where tID is designated by the par-

ticipant and pkO||tID is the composite ID of the created tokoin that is globally unique inside the blockchain. With the public key available, the miner nodes

can Verify(σpkO, pkO), and create a new tokoin t = (tID, pkO, pkO,policy,isValid=1).

Upon the creation of t, the participant acquires the role of rO with respect

to t. All actions performed during the creation of tokoin t are logged in

TX Script and recorded with t in the next block as illustrated in Fig. 3.3.

The implementations of Modify() and Transfer() are similar to that of

Create(), in that they all require an authenticated request message car-

rying the corresponding op code sent to the blockchain system. But there

are subtleties that differ them significantly: Modify() can be called only by a

tokoin owner, and it changes the access policy of the tokoin; Transfer(), on

the other hand, can be called only by the current holder of a tokoin, and

it carries the public key pk′H of the next holder thus changing the current

holder of the tokoin upon completion. Accordingly, the message for Modify()

has a format of [t,modify,policy*]σrO and that for Transfer() has a format of

[t,transfer, pk′H,]σrC , for tokoin t.

When receiving a Modify() message, the verifiers in the blockchain system

first check whether Verify(t, pkO,rO) = 1, and if yes, the access policy of the

tokoin is changed and the corresponding transaction is recorded in the next

block. Note that a revision on an access policy can modify any key-value pair

of the policy, and can add new or delete existing key-value pairs, to redefine

the access policy. Also note that the values within a policy are all plaintext

modifiable except the access subject group, which consists of one or more

individuals and is described by a cryptographic accumulator; therefore, to

add or delete subject pk′, Add/DelACC(pk′) and UpdateACC() should be called

to add or delete the subject and update the value of Accumulator in the

access policy. Similarly, when receiving a Transfer() message, the verifiers

first check whether Verify(t, pkO,rC) = 1, and if yes, the current holder of the

tokoin is changed to pk′H and the corresponding transaction is recorded in

the next block. Note that Modify() and Transfer() do not create a new tokoin

but revise certain field of an existing tokoin, and the revision actions are

recorded in the TX Script field of the corresponding transactions.

The implementation of Revoke() is rather simple. To revoke a tokoin t, the

owner of t sends out a message msg : [t,revoke]σrO to the blockchain system, in

which the verifiers first check whether Verify(t, pkO,rO) = 1, and if yes, t.isValid

is set to 0 nullifying the tokoin t in the system. Note that only the owner of t

can revoke t.

The implementation of Redeem() is a bit complicated. Upon receiving a

Redeem() message msg : [t,redeem]σrS from a subject rS, the verifiers need to

check Verify(t, pkO,rS) = 1, and if yes, t is transferred to rACO, who then calls

PolicyCheck() to redeem the requested resource. If PolicyCheck() successfully

returns, which means that the access process is successful, rACO invalidates

the tokoin t and then sends a confirmation message to the tokoin owner rO.

All activities in the redeem process, including those from PolicyCheck(), are

recorded in the TX Script field of the transaction for Redeem().

3.5.2.3 Auditing

Auditability and traceability are native in TBAC, as all operations over a

tokoin and all resource access activities are logged within the TX Script

field of a transaction stored in the blockchain. Such auditing evidence is

publicized and verified by the whole blockchain system, and as a result, it

is globally legit. Under the security assumption that the blockchain system

is free from forking and the consensus process is not compromised, the

auditability of the tokoin manipulation and access control activities can be

securely guaranteed.

3.5.2.4 Summary

There are three unique distinctions that differentiate TBAC from other

access control models. First, fine-grained access control can be achieved

by realizing an access policy that defines who is allowed to do what at

when in where by how, where who, what, when and where constitute the

access constraints that must be satisfied in order for an access request to

be granted and how describes the access procedure that must be strictly

followed to guarantee access safety while avoiding access violations. Second,

an access privilege, which is intrinsically metaphysical, is transformed to a

digital asset, i.e., a tokoin, that is stored in a blockchain and managed with

atomic and accountable operations as if it is a cryptographic coin. Third,

the validation of the access policy is performed at the TEE secure zone that

physically protects all related programs and securely collects environment

evidence for correct access decisions. These design considerations ensure

that TBAC can provide fine-grained and accountable access control with

cryptographic level security confidence while making unauthorized resource

access impossible.

Now one can safely claim that TBAC ensures all access activities to

be securely restrained to what the resource owner has authorized to (No

Overprivilege) and to be publicly recorded with no stealthy access (No Weak

Auditability).

3.5.3 TBAC Prototype Implementations

Our TBAC system consists of three components: (1) a blockchain-based

distributed ledger that securely manages the tokoin access capabilities,

supports secure atomic tokoin operations in the form of transactions, and

logs all activities with security significance for auditing purpose, (2) a

trusted local access control system within a TEE chipset that hosts the

programs of embedded blockchain clients and sensor drivers in its secure

zone for collecting trusted environment evidence upon redemption and

making correct, attack-free access control decisions, and (3) an App-based

user interface for a good user experience.

We have two implementations of the first component: a native implemen-

tation Go-Tokoin in Go language (Golang) that follows our original design for

the best performance, and an Ethereum based implementation Ethereum-

Tokoin in Solidity that shows adaptivity of TBAC to mainstream platforms.

We run Ethereum-Tokoin in both Ethereum Mainnet and Quorum, a consor-

tium fork version of Ethereum that uses Raft or Istanbul-BFT consensus2.

The tokoin functions are tested on the Native Go-Tokoin and the adaptive

Ethereum-Tokoin. The experiments are run with seven virtual nodes on

top of a PC with the following setup: 8-Core Intel i7-6700HQ @ 2.6GHz,

16G memory, Ubuntu 18.04.1 GNU/Linux. We record and analyze the 2https://github.com/jpmorganchase/quorum

performance of the implementations for the same case study in Section.3.6.

One can preview the results in Fig. 3.9, which indicate that our native

Go-Tokoin takes typically 40-60 millisecond to confirm each transaction,

while the Ethereum-Tokoin in Quorum consortium chain takes about 1

second (more than a magnitude) and that in Mainnet takes about 30 to 50

seconds (one more magnitude than that).

3.5.3.1 Go-Tokoin: Native Golang Implementation

We implement the main blockchain system of TBAC with over 4000 line of

codes in Golang, including the Tendermint-BFT consensus and the inter-

communication protocols between a participant and the blockchain ledger.

Golang is selected because it is a memory-safe, high-concurrent, high-usable

language that is quite popular in the security community. As we build our

native system pretty much from scratch, we concentrate on flexibility and

customized optimization while strictly following the detailed construction

presented in Section 3.5.1.1. A complete working system is available in

Github at https://github.com/zhuaiballl/Go-Tokoin.

3.5.3.2 Ethereum-Tokoin: Adaptive to Mainstream Platforms

Although our Go-Tokoin native implementation has better performance and

more design flexibility as demonstrated by our case study in Section 3.6,

we still want TBAC to be readily available in other mainstream blockchain

platforms. Thus we implement all required TBAC functions in Ethereum

Solidity, in the form of a smart contract (technically called interface). As

we manage tokoins as digital assets, we develop the interface on top of

Ethereum ERC token standards, which stand for Ethereum Improvement

Proposals. Popular ERC token standards include ERC-20, ERC-777, etc.;

however most of them create coins that are fungible, which means that all

the coins are identical and of the same data. This can perfectly serve the

need of cryptocurrency, but clearly it cannot meet the need of TBAC, as we

may modify and revoke a tokoin, and need to trace and audit all tokoins.

Thus we choose ERC-721, a special ERC token standard that is often used

to represent the different ownerships over digital assets or collectibles, and

can be tracked individually. Then, we develop our own TBAC Smart Contract

interface on top of ERC 721, implementing the aforementioned TBAC-specific

functions, Ethereum events, and data members. Each user can mint a

tokoin by creating a tokoin smart contract. Users can directly implement

their tokoin contracts with Remix-Ethereum IDE, or simply use the TBAC

mobile App (presented in the following subsection) to auto-generate one.

We keep this open-source on the Github at https://github.com/DES-PER-

ADO/Ethereum-Tokoin.

The implementation of Ethereum-Tokoin is harder than that of the native

Go-Tokoin in two aspects. First, altering access policies in Ethereum-Tokoin

is hard, as smart contracts do not allow data post-alteration whatsoever.

We employ an engineering trick to decouple the logic and the data with

two different contracts to mitigate this problem. Second, during the tokoin

redemption process, we need to intake trusted data from our TEE counter-

part and sensors. However, taking in exogenous, non-blockchain generated

data from external sensors into a smart contract is cumbersome. This is

because of the intrinsic exclusiveness and deterministic requirements of

the smart contract environment. It is null to upload data from a single

point to the smart contract, as the Ethereum VM requires the same logic

and same data input at all nodes. To overcome this problem, we require

rACO to post the sensor data through command sendTransaction to the

full blockchain public network.

��

�� #� ��%

()*��

(+*�� ,

��

(-*�� .��/� �� ,�� ,��.�� 0�

(1*��

(2*�� 3,�� .��

��

� ��

��

“Contract Logic Level Modification”: � �� 4��

“Data Level Modification”: �� .�� 4�

� �� 4 � �� 4��

“Queries for ��!�5��

"��”: �� /��

� �# 5� ��4 �� $��

��%�

(6*�& %��.�� Ethereum-Tokoin

Go-Tokoin

� ��

(7*�� 3,� �� /� �� %�� 4��%�

��

(8*��. �� 4�� 3,�� /� �

�� %�� 4��%��

��

(19*�� 3,�� /� � �� %�� 4��%�� (��*��

�� ( �%��* ��

(+9*��

� ��

Figure 3.4: The TBAC Mobile App Workflow

3.5.3.3 The Robust Access Control Object

The most popular hardware-assisted TEEs include Intel Software Guard

Extensions (SGX), ARM Trustzone technology, and AMD Secure Execution

Environment. In our implementation, we adopt the ARMv8-M TrustZone,

which was introduced by ARMv6 around 2002 and then became popular due

to its low-power consumption. It is comprised of three components, namely

the secure zone, the non-secure callable interface, and the non-secure zone.

The secure code in the secure zone has higher privilege and can access

resources in both secure and non-secure zones, while the non-secure zone

is isolated from secure resources and programs.

To implement the TEE-enabled access control object RACO, we adopt

LPC55S69-EVK, an ARM Cortex-M33 based microcontroller secured by the

ARMv8-M TrustZone. This is because LPC55S69-EVK is one of the very

few off-the-shelf chipsets that support the ARM Cortex-M33 architecture.

Compared to the Cortex-A series, Cortex-M33 has a much lower cost ($10 for

Cortex-M33 compared to ∼$200 for Cortex-A and ∼$400 for Intel SGX), and

its secure area and non-secure area can be precisely partitioned, providing

strong flexibility. The cost we have to pay is the availability of a very little

library for development, thus a majority of our codes are written by us in C

and Assembly. Compared to the rich libraries of Inter SGX and Cortex-A

with developer-friendly IDEs, it looks like we build the TEE system directly

on a baremetal MCU. This part takes up about 6000 lines of code.

Recall that we require rACO to achieve two objectives: i) to securely collect

information that can verify whether the access policy is strictly followed, and

ii) to securely communicate with the blockchain system. The information

that should be collected is application-specific, and is dependent on the

access policy specified by the tokoin t. For example, if when and where are

defined in t.policy, one can employ a GPS receiver to realize the first goal by

implementing its driver in the TEE secure zone and connecting the external

GPS hardware with its driver directly without any intermediary. To realize

the second goal, we implement a blockchain client inside the TEE secure

zone to ensure that it can communicate directly to our blockchain network

via a SSL/TLS secure communication channel. After fetching the access

policy t.policy, its contents are parsed, based on which correct information

can be collected to verify whether the access constraints (who, what, when

and where) are satisfied and the access procedure (how) is strictly followed.

If yes, the tokoin redemption process is successfully completed. The code

for our robust access control object is application-specific as the access

policy (condition and procedure) verification are dependent on particular

applications, and the one for the in-home cargo delivery case study is

available at https://github.com/DES-PER-ADO/TACO.

3.5.3.4 TAP: the TBAC App

To avoid users from being messed up with different programming languages,

and more importantly, to provide a better user experience with no code

exposure, we develop an easy-to-use TBAC mobile APP in Android, namely

TAP, that integrates a TBAC interface with a script/contract wrapper. The

purpose of TAP is to keep users from being exposed to Solidity, Javascript,

Golang, or C code.

When a user logs in with its credentials (for example a username-

password pair or a private key), TAP identifies its identity, searches for

all active tokoins the user is associated with, and lists them in different

categories based on the user’s role as does by a wallet. If the user wishes

to carry out an operation over a particular tokoin, the tokoin needs to be

clicked and the required information needs to be input via the tokoin in-

terface. The input information is then wrapped into Go-Tokoin scripts, or

compiled by the solc Ethereum Javascript commands.

The exact workflow of TAP is shown in Fig. 3.4, which indicates that

different steps are needed for different blockchain platforms. For Ethereum-

Tokoin, we need to initialize a contract, manage tokoins within an existing

contract, or query the public on-chain data. To initialize a contract, a user

can either implement its own contract or modify a default one and define the

access policy at the administrative level. Next, the solc compiler compiles

the created contract into an EVM-compatible Ethereum ABI, which is then

wrapped into the Javascript command .calcContract.new() from the

Web3.js library. To manage tokoins, the user can skip solc and directly

wrap the parameters captured by the textbox and scroll-lists them into JS

commands. These operations must be sent using the sendTransaction()

command from the Web3.js library. To query the public on-chain data,

call() is used. For Go-Tokoin, we do not need an overqualified virtual

machine; instead, one can simply capture the parameters, wrap them in a

msg with different opcodes, and then send the message via .sendTX . One

can see that TAP improves the usability by providing a simple interface for

the users to interact with TBAC. Similarly, the code of TAP is application-

specific and the one for our in-home cargo delivery case study is available

at https://github.com/DES-PER-ADO/TAP-cargo-Delivery

Secure Zone

TACO

Blockchain Network

TACO Initialization 1. Key Generation 2. Standard Pattern Generation 3. Key/Pattern Registration

Confirm and Finalize

Sign Result with

Private Key

��

Transfer Tokoin

Subject ID, Tokoin Validity & Access Constraint

Verification Start

CASE_1: OVERTIME

CASE_2: OVER-PRIVILEDGE

CASE_3: SUCCESS

Create Tokoin

Monitor and Determine Overprivileged-Access

Redeem Tokoin

��

Door Unlocks

Account Initialization 1. Key Generation 2. Client Registration

Non-secure Zone

Figure 3.5: TBAC Assisted In-home Cargo Delivery

3.6 Case Study: TBAC Assisted In-home Cargo Delivery

In this section, we report a case study that employs TBAC to assist in-

home cargo delivery. This case study demonstrates how TBAC and IoT can

seamlessly work together to control a smart lock in a secure, fine-grained,

and accountable manner for safe in-home delivery.

In the US, online-purchased merchandises are usually delivered to the

outside doorstep of a house, thereby risk of being stolen. With the help

of the smart door lock, a deliveryman can open the house door and leave

the cargo inside. This may seem to be a good solution and in fact it has

been adopted by Amazon [3]. Nevertheless, by signing up for this in-home

delivery service, users would surrender to the unlimited, unconditional,

and unauditable accesses to their homes as an unlimited access token is

issued from the door lock manufacturer’s access server to Amazon after

authorizing Amazon the access privilege to the door. It may get worse if the

Amazon’s server is compromised or the token is stolen or abused. In this

section, we show that with TBAC, one can have high confidence that only

the customer-approved accesses can take place, with a complete auditing.

We also emphasize that with a fine-grained access policy specified by the

customer, a robust access control object can monitor the delivery procedure

to ensure that the deliveryman does not intrude the house by doing more

than dropping the package.

Fig. 3.5 demonstrates our TBAC assisted in-home cargo delivery case

study. When an order is placed, a tokoin specifying the detailed access

policy to the customer’s house is also created. The order and the tokoin

are sent together to the seller, who then transfers the tokoin to the first

courier of the package when it leaves the warehouse. In transit the tokoin

changes its holder when the package is handed to a different courier. The

customer can monitor this process via TAP and can change the access policy

based on the shipment status. When a courier arrives at the doorstep of

destination house, the tokoin is redeemed and the package is dropped inside

home if access policy verification succeeds. For security and safety, the

access policy specifies that the deliveryman cannot walk out of the mud

area to enter the main house. Thus a video camera is adopted to monitor

the procedure and a violation is reported immediately when detected. In

the following we present this case study in two processes: an initialization

process and a delivery process.

3.6.1 Initialization

The initialization process consists of customer account initialization and

the robust access control object initialization. Note that we assume that

the seller and its couriers are TBAC clients thus no extra work is needed

here. For the ease of presentation, we name a TBAC access control object a

TACO.

Figure 3.6: Experiment Setup of TEE

Account Initialization. Upon initialization, a customer calls the Gen

function to generate a pair of keys sk and pk, registers itself with and broad-

casts its public key pk to the blockchain network, and keeps the private key

sk to itself. The customer downloads the TAP software and becomes a TBAC

participant who can talk with the blockchain securely.

TACO System Configuration. To establish the TACO for our in-home

cargo delivery case study, we adopt an LPC55S69-EVK microcontroller

secured by an ARMv8-M TrustZone, a smart lock, a GPS receiver, and a low

voltage UART serial image sensor camera. In addition, a testboard is utilized

for debugging purpose. Upon initialization, TACO generates a secret key sk

and a paired public key pk using crypto-libraries in LPC55S69-EVK. Then

it broadcasts its pk to the blockchain for self-registration. The pk is used as

the address and the unique identifier of the TACO system in the blockchain.

TACO also uses the camera to capture the normal background of the home

mud area when nobody shows up, and stores it as a STANDARD PATTERN

into its secure zone for future detection of over-privileged behaviors such as

the deliveryman walking out of the mud area to enter the main room. The

pk and the STANDARD PATTERN are then registered as a transaction in the

blockchain.

Note that we have implemented the drivers of a GPS receiver and a

UART serial camera in the secure zone, which directly connects to the

corresponding devices for secure data collection. Also in our case study

TACO is able to command the smart lock via secure communications with

the lock server, who can securely talk with the smart lock, thus avoiding

the hassle of writing a driver in the secure zone and connecting it to the

lock. Fig. 3.6 illustrates the TEE setup with the sensor camera – the GPS

receiver is omitted for better illustration.

3.6.2 Delivery Process

The delivery process is depicted in Fig. 3.5, whose steps are detailed as

follows.

Create a tokoin. Before an order is placed, the customer mints a tokoin

by sending msg : [pk||tID,create,policy]σrO to the blockchain, who then creates a tokoin t and logs it in a transaction. The policy specifies who (any legit

deliveryman) is allowed to do what (cargo delivery) in where (address of the

house) at when (e.g., 2-3PM tomorrow) by how (enter the house, drop the

package in the mud area, then leave the house in 5 minutes). See Fig. 3.7(a)

and Fig. 3.7(b) for an illustration. The tokoin t and the order together are

then sent to the seller.

Transfer the tokoin. The seller then assigns a courier to this order,

and transfers t to the courier via a Transfer message when the package is

handed to the courier. As we discussed before, t can be freely transferred

among the couriers through a standard transfer operation, which eases the

re-distribution of the delivery job for better logistic convenience. Besides,

the customer has the right to track the tokoin through a tokoin map as

shown in Fig. 3.7(c). It can also modify the tokoin (e.g., changing the delivery

time window) during this process at its will before the tokoin is redeemed.

Redeem the tokoin. A deliveryman arrives at the house address and

wishes to redeem the tokoin t to complete the job. Redeem is then called,

which sends the tokoin t to TACO, who would perform the following tasks

for tokoin redemption.

Access Condition Verification. After receiving t, TACO needs to Verify: 1.

whether t is a valid tokoin; 2. whether the deliveryman is a legit subject ac-

cording to the cryptographic accumulator carried by t.policy; and 3. whether

the spatio-temporal access conditions are met, i.e., the time of delivery and

(a) Creating tokoin (b) Detailed information of a tokoin

Figure 3.7: Android Tokoin Activities for Cargo Delivery

(a) An actual frame of a TACO camera capture

(b) A TACO cap- tured pattern of benign behavior

(d) A TACO cap- tured pattern of a major violation behavior

Figure 3.8: A Set of Actual Captures of TACO for Overprivileged-Access Monitoring

the delivery address are all consistent with what are specified by t.policy. If

all verifications succeed, TACO instructs the smart door lock to open the

door and let the deliveryman in to drop the package.

Access Procedure Monitoring. After entering the house, the deliveryman

should drop the package in the mud area and leave in time specified by

t.policy. To monitor this process, TACO constantly reads inputs from the

UART serial camera and checks the position of the deliveryman by detecting

moving objects in the video. Specifically, TACO computes the difference

between the STANDARD PATTERN and every video frame, and adds them

up as a differential monitoring pattern, which is obviously a bitmap with

boolean 1 for presence and 0 for absence of the deliveryman. The determi-

nation of a violation, i.e., an overpriviledged access, is detected if there is a

boolean 1 out of the mud area, see the illustration in Fig. 3.8, which uses

an imaginary red line to represent the boundary of the mud area.

There are two possible types of violations:

• Case 1: the deliveryman stays longer than the time specified by t.policy.

In this case, TACO would first ring an alarm bell, then send a signed

OVERTIME message to the customer. If the deliveryman does not leave

immediately, TACO may call the police.

• Case 2: the deliveryman walks out of the permitted mud area to enter

the main room. If this case is detected, as shown Fig. 3.8(c)(d), the

corresponding pattern of motion trajectory is recorded as a proof of an

over-privileged behavior; then TACO sends a signed OVER-PRIVILEGED

PATTERN to the blockchain and takes appropriate measures such as

locking the smart door and calling the police.

Post-Access Management. If no violation is detected, TACO sends a signed

SUCCESS to the blockchain after the deliveryman successfully drops the

package in the mud area and leaves the house. Note that all the data for

access condition verification and access procedure monitoring must be

signed with the private key of TACO and stored within the TEE secure zone.

This can guarantee the integrity and the trustworthiness of the data. The

data itself or a digest of the data (if the data is too big) is also sent to the

blockchain to be included in the transaction as a script for auditing the

Redeem operation.

��

�� !

�"!! � ;#� �

�� #

�"$� " �"$# �

$;�� " �;�$ "

�"$� ! �"�; �

!#!%$ �"$!! �$;�� !;;!�

�%�$� $!;";

�"

�""

�"""

�""""

�"""""

�� &�� '� ��( �

��

�) �*

�� (

�+ �,

� ��

��-�� .�� -�� .�� -��' ��

Figure 3.9: function Execution Times

The total time for each tokoin manipulation function is reported in Fig. 3.9.

This figure shows the performance of different TBAC implementations, in

logarithmic scale. The reason why we choose log scale is because the

confirmation times of Go-Tokoin and Ethereum-Tokoin in three different

platforms vary up to two magnitudes. Our native Go-Tokoin takes typically

40-60 milliseconds to confirm each transaction, while the Ethereum-Tokoin

in Quorum consortium chain takes about 1 second (more than a magnitude)

and that in Mainnet takes about 30 to 50 seconds (one more magnitude

than that). One should notice that Go-Tokoin takes much longer time in

Redeem, which includes the time for PolicyCheck. This is because Redeem

requires TACO to sample the sensor readings, analyze the data, and take

corresponding actions if needed, and communicate the data (or its digest)

back to blockchain. Note that the time for monitoring the access procedure

is excluded. Besides, the transaction cost on the Ethereum Mainnet is about

2967k Gas on average ($14.7 USD, in July 16, 2019), while our consortium

Go-Tokoin is free.

3.6.3 Discussions on TEE Cost

We notice that there exist other works that use TEE to perform trustworthy

operations. However, most of them are prohibitively expensive, mainly

because they use the more-easy-to-implement but expensive chipsets such

as the Intel SGX or the Cortex A-series high-performance chipset. Such

chipsets are mostly priced around $300 ∼ $400, which is not practical

for general systems used in our daily life. Cortex M-series chipsets are

specifically designed for embedded systems and real time responses. This

series has very few usable libraries, kernels, and operating systems, which

poses a great engineering challenge on us. We build the system almost

from the bare metallevel. To the best of our knowledge, we are the first

to implement such a trustworthy system using the challenging yet cheap

Cortex M23 MCU, which is priced around $10.

3.7 Discussions and Future Research

In this paper, we emphasize the importance of fine-graininess and strong-

auditability in access control. A coarse-grained access policy opens the

door for overprivilged or even unauthorized accesses while weak-auditability

makes it hard to trace the access process and resolve disputes. According

to our analysis in Section 3.3.2, one can see that ABAC is the only existing

mechanism that can offer fine-grained access control because its access

policies are specified based on attributes and their contextual relationships.

On the other hand, all existing approaches suffer from the weak-auditability

problem.

One may claim that blockchain-based access control can offer strong

auditability as a blockchain is able to audit and trace all activities in nature.

Nevertheless, this nice feature holds true only on-chain and the trust

environment built by a blockchain cannot be easily extended to off-chain.

This implies that the off-chain activities cannot be monitored and audited

by the blockchain. As a typical access control is a process that involves both

digital world and physical world, the physical activities obviously cannot

be audited by a blockchain. In other words, strong-auditability cannot be

achieved unless physical activities can be logged from a trusted source. To

overcome this problem, one needs to extend the trust from on-chain to

off-chain, which is extremely hard in practice.

As Internet of Things (IoT) is regarded as the media to connect physical

world with digital world, intuitively it can be used to extend the on-chain

trust to off-chain. Nevertheless, IoT sensors can be easily hacked, rendering

the sensed data untrustable. Moreover, their light-weight designs make it

impossible to employ well-established security primitives for IoT data, device,

and process protection. In this paper, we creatively employ a TEE trust zone

to host a robust access control object as well as the drivers of IoT devices

to extend the on-chain trust to off-chain by 1) securing connecting the

robust access control object to the blockchain, 2) hard-wiring each trusted

driver to its corresponding device, and 3) signing all data before leaving

the trust zone. Such a design can successfully collect trusted data3, thus

effectively extending trust from on-chain to off-chain. With this design, one

can realize strong auditing in TBAC as all access activities, either on-chain

(tokoin manipulation) or off-chain (access policy compliance verification,

including access condition checking and access procedure monitoring), can

be securely logged and stored. To our best knowledge, this low-cost TEE- 3Physical damages to sensors are out of the scope of our consideration.

enabled approach is the first one that extends trust from the digital world

to the physical world, which has a great potential to enable various novel

applications. This is to be further explored in our future research.

In this paper, we design TBAC that provides fine-grained and strong-

auditable access control by means of a tokoin, which represents the right

to access a resource. A tokoin can be securely transferred and audited

through a standardized process. This enables a new paradigm of manag-

ing hardware resources such as secure IoT resource rental, trading of IoT

resource right-of-use, or flexible errand delegation. For example, a senior

executive may need a secretary to rebook a flight, change a hotel reservation,

or reply a specific email on its behalf. The current solution is to provide

the username/password pair or a picture of the credit card to the secretary.

This certainly harms privacy and is undoubtedly highly insecure. If TBAC

is properly applied, the executive can issue a tokoin to precisely specify the

permitted operations without disclosing username/password or credit card

information. In our future research, we will investigate application-oriented

TBAC implementations to address various domain-specific challenges.

3.8 Conclusions

In this paper we propose TBAC, a fine-grained and accountable access

control model that makes use of blockchain and TEE to realize its goals.

The basic idea of TBAC is to mint a tokoin that materializes the “virtual”

access right into a cryptographically secure digital asset such that the

resource owner can take full control of the access to its resource, without

the need of delegating or relying on any third party such as a server. The

access constraints and the access procedure as well as their contextual

relationships can be precisely defined in a tokoin, which constitutes the

access policy, thus realizing fine-graininess of access control. Moreover,

all actions over the tokoin, either on-chain or off-chain, can be securely

logged, facilitated by the blockchain and a robust access control object

(implemented within the TEE secure zone) for policy compliance verification,

realizing strong auditability. We also present a TBAC assisted in-home

cargo delivery case study to show the effectiveness of TBAC in securing the

procedure for a deliveryman to open a door and drop the package in the mud

area of the room without entering the main room. Our TBAC design and the

case study demonstrate a remarkable idea of extending trust from on-chain

to off-chain, which has its own significance with broad applications and

will be further investigated in our future research.

Availability

Code of Go-Tokoin, Ethereum-Tokoin, TEE-enabled Access Control Object

(TACO) and Tokoin App (TAP) available at:

1. https://github.com/zhuaiballl/Go-Tokoin

2. https://github.com/DES-PER-ADO/Ethereum-Tokoin

3. https://github.com/DES-PER-ADO/TACO

4. https://github.com/DES-PER-ADO/TAP-cargo-Delivery

Chapter 4: Extending On-chain Trust to Off-chain –

A Trustworthy Vaccine Shipping Example

4.1 Motivation and Abstract

Blockchain creates a secure environment on top of strict cryptographic as-

sumptions and objective security proofs. It permits on-chain interactions to

have many trustworthy properties such as traceability, transparency, and ac-

countability. However, current blockchain trustworthiness is only confined

to on-chain, creating a “trust gap” to the physical, off-chain environment.

This is due to the lack of a scheme that can truthfully reflect the physical

world in a real-time and consistent manner. Such an absence hinders

further real-world blockchain applications, especially for security-sensitive

ones.

In this paper, we propose a scheme to extend blockchain trust from

on-chain to off-chain, and implement the full system taking trustworthy

vaccine transportation as an example. Our scheme consists of 1) a TEE-

enabled Trusted Environment Monitoring System that continuously senses

the inside of the vaccine box through trusted sensors and generates anti-

forgery data; and 2) a consistency protocol to upload the environment status

data from the TEE system to blockchain in an orderly, consistent, and

fault-tolerating fashion. Our experiment records the internal status of the

vaccine shipping box during transportation. The results indicate that our

system incurs a maximum of 8 seconds to have the sensed data available in

the blockchain, and no adversary can tamper with the vaccine in any way

without being captured.

4.2 Introduction

Blockchain is a secure environment that permits certain interactions within

it to be trustworthy. It is built on cryptographic assumptions and proofs to

guarantee objective security and trustworthiness. However, currently, its

trustworthiness is confined within the blockchain environment only, and

can be hardly extended into the off-chain physical world. This is manifested

by the lack of strong guarantee that blockchain data truthfully reflects

the physical object it is bound, or that blockchain control instructions are

always correctly deployed to the device it is managing. This “trust gap”

between on-chain and off-chain undermines the trustworthiness property

of blockchain, especially when applying it to security-sensitive physical

world related scenarios.

Taking vaccine transportation as an example – vaccine is critical to pro-

tect citizen health, thus keeping its physical distribution process highly

traceable, transparent, and trustworthy is of paramount significance to

public interest. It is one of the critical scenarios where digital data collected

for monitoring the vaccine transportaiton should strictly reflect the physical

world activities. However, we have seen many tragic cases where the vac-

cines were damaged or counterfeited due to the lack of highly trustworthy

monitoring systems. Data were mostly manually reported and entered, thus

we don’t know if the vaccine was actually exposed to hazardous environ-

ments, defective or tampered with. During a surprise inspection to the

rabies vaccine produced by Changchun Changsheng Ltd, China’s National

Drug Administration (NDA) found more than 250,000 doses of a vaccine

were out of the production standards and the online data did not match with

the actual product [40][55]. The Centers for Disease Control and Prevention

of America (CDC) mandates the vaccine to be stored between 2°C and 8°C.

However, Nelson et al. found that Hepatitis B vaccines in Indonesia was

common to inadvertently freezing and thus harming the bioactivity, though

the use of trusted vaccine vial monitors can significantly reduce the risk of

heat-damage of the vaccines [41]. This “physical intraceability” challenge

are common in many other security-sensitive applications in real life, and

blockchain is not the silver bullet to the problem due to the current trust

gap between on-chain environment and off-chain physical world.

To address this problem, we resort to periodical trustworthy sensing,

creating data anti-forgery proofs, and achieving real-time upload guarantee

to blockchain and error recovery against data losses. Our scheme consists of

1) a TEE-enabled Trusted Environment Monitoring System that periodically

senses the physical environment, creates anti-forgery data records, and

uploads the records to blockchain; and 2) a consistency protocol to upload

the records from the TEE system to the blockchain in an orderly, consistent

and fault-tolerating fashion. We make careful security designs to ensure 1)

no adversary can forge a fake data as all are verified authentic and 2) no

adversary can physically violate the security requirements without being

captured.

The contributions of this paper are summarized as follows.

1. We fully implement a trusted monitoring system to support our trust-

worthy vaccine transportation in real world. We develop the system

using the low-cost Cortex M33 Trusted Execution Environment (TEE)

microcontroller, which enforces strict physical isolation, thus achieving

high security guarantee while keeping the system practically cheap for

IoT applications.

2. We extend the on-chain trust to off-chain by designing a protocol to

achieve the real-time data consistency between physical objects and

their corresponding digital entities. We also analyze the time upper

bound for data consistency considering general blockchain systems.

3. Our system is invulnerable to long-range vulnerabilities. Unless phys-

ically destroyed, any tampering with the system or the monitored

physical object is to be recorded with non-repudiation and traceability.

We also provide a fault-tolerance and error recovery solution against

record losses caused by transmission failures without relaxing any

security requirement.

The rest of this paper is arranged as follows. Section 4.3 presents

the necessary definitions and basic assumptions. Section 4.4 outlines

the vaccine transportation system under our consideration to illustrate

our design. Section 4.5 describes the in-depth technical details of our

TEE-enabled Trusted Environment Monitoring System and the consistency

protocol. Section 4.6 demonstrates our full system and visualizes the critical

data. We finally summarize the related work in Section 4.7 and conclude

the paper in Section 4.8.

4.3 Definitions and Models

In this paper, we intend to extend the on-chain trust to off-chain, and realize

real-time data consistency between them, with high security confidence. To

achieve this goal, we need to define what is real-time data consistency, what

is a physical event of interest and its corresponding digital entity, and how

to achieve the consistency goal.

4.3.1 Basic Definitions

We say a physical event of interest is an object that can be described as a

combination of different types of sensor outputs such as binary, numerical,

or multimedia. We denote this combinatory sensor output as C, which is a

description towards the event. The selection of the sensors is application-

specific, and we actualize our design in Section 4.4. Pattern Γ is defined

accordingly to examine whether or not data C follows a correct pattern. In

practice, Γ and C share the same structure. The examination is done by

computing the deviation between C and Γ. The combination of C and Γ can

describe the basic detail of a physical event and how desirable or how legal

it is. The physical event of interest then can be recorded as a timed object,

denoted as (t,C,π), and uploaded to blockchain, where t is the timestamp

when this event object is created and π is a proof of the authenticity of

the event or (partly) the trustworthiness of the data. We say a prover P

generates such a timed event and the corresponding proof, while a verifier

V verifies it. A prover is usually a physical sensor or an IoT device, while the

verifier can be any public node in the blockchain system. We then define

the trustworthiness of a timed event as follows.

Definition 6 (Trustworthiness of a timed event:). We say a timed event is

trustworthy if it is:

1. generated by a trustworthy program, and

2. uploaded to the blockchain complying with the real-time consistency

requirement.

Here real-time data consistency between on-chain and off-chain is defined

as:

Definition 7 (Real-time On-Chain Off-Chain Data Consistency). For any

event of interest occurred in the physical world at time t, it takes at most δ

more time for the blockchain system to return the same timed event, where δ

is a small real number that is application-specific.

As one can see, these definitions mandate a truthful, robust, and highly-

responsive system that continuously enforces monitoring towards a physical

object, and then uploads the data to blockchain with low latency. This

process must also be efficient enough to achieve the real-time requirement.

We realize this goal by designing a consistency protocol and implementing

the trusted environment monitoring system on top of Trusted Execution

Environment (TEE) in Section 4.5.

A digital entity α can then be formulated as a vector of chronologically

consecutive timed events. In other words, a digital entity α fully describes a

physical object and its state transitions in 4-dimensional space, by schedul-

ing periodical sensing and data reporting every Δt time.

α = (t0,C0,π0),··· ,(ti,Ci,πi) (4.1)

In order to continuously ensure this digital entity α to truthfully describe

the physical object, we define the validity of a digital entity as follows.

Definition 8 (Validity of a digital entity). We say a digital entity α is valid if

for each timed event (ti,Ci,πi) in α , the real-time on-chain off-chain data con-

sistency is strictly maintained, and the time interval between two consecutive

timed events in blockchain is confined within δ̂ , where δ̂ is a real number that

does not significantly deviate from Δt, the sensing interval.

We lastly define a blockchain system as a distributed nework consisting

of n processes (or nodes). We consider a general type of blockchain that

uses partially-synchronous mode [15]1, where the blockchain is mandated

to synchronize blocks at periodical deadlines called Global Standardization

Time (GST). Within the time between two consecutive GSTs, denoted as

ΔGST , the blockchain transactions are packed into one or more blocks,

proposed and verified by most-but-not-all nodes, and not until the next GST

will these blocks be guaranteed to be synchronized into every non-faulty

node’s ledger.

4.3.2 Trust Model

In this study, we trust the TEE hardware is secure against any long-range

vulnerabilities, and blockchain cannot be manipulated by an adversary.

Blockchain: We say a blockchain system is secure if its consensus out-

put is secure against adversaries’ malicious manipulations. The blockchain

produces a block every ΔB time and mandates global block synchroniza-

tion every ΔGST time. With the general partially synchronous assumption

mentioned earlier, and the fact that most non-trivial blockchain systems or

consensus algorithms provide such proofs against malicious manipulations,

one can reasonably make this trust assumption.

TEE: A Trusted Execution Environment (TEE) physically divides a secure

zone and a non-secure zone (some may call rich-environment zone). Pro-

grams in secure zone can only be called by non-secure zone but cannot be

modified or explicitly inspected. It is a general consensus among security

community that programs within the secure zone are invulnerable against

long-range tampering. There is one master secret key mas_sk that is unique 1Solving fault-tolerant consensus in asynchronous network is considered a difficult

problem [20]. While many works claim achievement of asynchronous consensus, they are in fact using a weak, or say partially-synchronous assumption, requiring the network to synchronize at periodical GSTs like Delegate PoS [6] or exist-but-unknown-a-priori upper bounds like PoW [39].

to each TEE system and can be used to exclusively authenticate this trusted

device to the public. This master secret key cannot be explicitly retrieved

or tampered with. We also assume the TEE hardware has a public/private

key pair, denoted by T EE_pk and T EE_sk, as a blockchain client needs to

be implemented in TEE to communicate with blockchain. Note that we

consider physical damage towards TEE out of scope.

4.4 A Vaccine Transportation Monitoring System

In this section we introduce the vaccine transportation system as an example

to demonstrate our design of extending trust from on-chain to off-chain

physical world. More specifically, our scheme is designed to make sure

that the environment within the vaccine shipping box is monitored in a

periodical and trustworthy manner.

We consider an important vaccine is stored inside an insulation box.

This box must be transported from A to B via an approved route. The box

is sealed and is prohibited from being opened. The temperature inside the

box must be kept low and stay stable, in order to preserve the biological

activity of the vaccine. We start by defining possible situations that violate

the security requirements:

1. the box is opened (may destroy or replace the vaccine),

2. the temperature within the box is abnormal (may nullify the vaccine

biological activity),

3. the transportation route is deviated from the predefined one (same as

1),

4. records may be lost (same as 1).

To capture these violations, we place a photosensor, a temperature sensor,

and a GPS locator inside the box. As discussed earlier, pattern Γ needs to

be predefined to determine whether the data C complies with the security

requirements or violates them. In this vaccine transportation system, the

photosensor should always output 0 for constant darkness, indicating the

box is sealed, thus we can define ΓP = {0}; the actual binary data of the photosensor is denoted by L, and L = 1 if the ambient brightness is greater

than the luminous threshold θ and L = 0 otherwise. The temperature sensor

should always report a steady internal temperature with a max deviation

tolerance σ , so ΓT = [K̄ − σ,K̄ + σ], where K̄ is the target ideal temperature. The GPS sensor records the physical shipping trace of the box, and should

follow a geographic pattern from the true origin, following a reasonable

trace, to the final destination. We define ΓG = {(Xi,Yi),ri}, which includes a series of checkpoints (Xi,Yi) by latitudinal and longitudinal coordinates and

a safe radius between the box and the closest checkpoint. If the Euclidean

distance between each location upload (xi,yi) and the nearest checkpoint

(Xi,Yi) is less than ri, the box is considered in a safe area. The actual sensing

data to be uploaded for each sensing is denoted by:

C = (L,K,x,y) (4.2)

We would like to point out that we could use more types of sensors to

monitor the box during transportation. For example, one can use a smart

lock, a motion sensor, a humidity sensor, to enhance the monitoring of the

vaccine box. These sensors are not hard to add-on, as one can see from next

section that our design philosophy can be easily applied to them. This study

represents our exploratory effort towards trustworthy vaccine shipment

and for demonstration purpose we focus on a simple example and design

the most essential components in this paper, leaving other opportunities to

future interested real world system developers.

4.5 Main Scheme: Trust Extension from On-Chain to Off-Chain Phys-

ical World

In this section, we detail the design and implementation of our trust exten-

sion scheme using the vaccine transportation as an example. Our scheme

consists of a TEE-enabled Trusted Environment Monitoring System and a

consistency protocol for uploading data from the TEE system to blockchain

in an orderly fashion. As discussed earlier, vaccines may suffer from coun-

terfeit, physical damage, being unsealed or replaced by fake ones during

transportation. Nevertheless, it is extremely challenging to seamlessly mon-

itor the transportation of vaccines in a trustworthy way in practice. This

“physical intraceability” is common in many security-sensitive real world

applications. We propose a system that permits secure and trustworthy

vaccine shipping, which can capture any tampering and violation to the

physical object with non-repudiation and traceability. We also present a fault

tolerance mechanism that can recover from lost packets due to transmission

failures, ensuring the seamless monitoring of vaccine transportation.

4.5.1 TEE-Enabled Trusted Environment Monitoring

We first introduce our full system of TEE-enabled Trusted Environment

Monitoring System. We develop our system from the bare metal level for

best security guarantee and efficiency/cost performance.

As discussed earlier, the secure zone inside a TEE hardware has the

highest security privilege through physical isolation. Programs implemented

Algorithm 1 Main System Utilities 1: Symmetric Key Derivation and Distribution 2: Function KDF(mas_sk,recp_pk,rec p_addr) 3: //master secret key of the system, recipient (blockchain client) public

key, recipient address. 4: //Symmetric encryption for efficiency, asymmetric signature for public

blockchain verification. 5: sym_sk = EncAES(mas_sk||recp_pk||TRNG()) 6: distribution

=SignRSA(EncRSA(sym_sk,rec p_pk),T EE_sk) 7: 4Gsend(distribution, recp_addr) 8: return sym_sk 9:

10: Retrieving Sensor Data 11: Function Sensors_get(θ ) 12: Initialization: L = 0,K = 0,x = 0,y = 0 13: if (app_ambient_lum() > θ ) then 14: L=1 15: //Hardware level logic 16: end if 17: K = app_temp_get() 18: (x,y) = app_gps_get() 19: return C = (L,K,x,y) 20: 21: Violation Detection 22: Function Violation_check(C,ΓP,ΓT ,ΓG) 23: Initialization: f lagP = f lagT = f lagG = 0, msg = null 24: if (C.L == 1) then 25: f lagP=1 msg.append(“Box opened”) 26: end if 27: if (C.K > ΓT .Kmax || C.K < ΓT .Kmin) then 28: f lagT = 1, msg.append(“Abnormal Temperature”) 29: end if 30: if (min dist{(C.x,C.y),(ΓG.Xi,ΓG.Yi)} > ΓG.ri) then 31: f lagG = 1, msg.append(“Route Deviated”) 32: end if 33: if ( f lagP|| f lagT || f lagG) then 34: t = get_sys_clock() 35: 4Gsend((t,msg),recp_addr) 36: end if 37: return 0

Algorithm 2 Main System Utilities (Continued) 1: Send Data Packets via 4G and Remote Agent Client to Blockchain 2: Function 4Gsend(msg,rec p_addr) 3: app_4G_send(msg,recp_addr) 4: if (Not receiving ACK) then 5: return ‘fail’ 6: else return ‘ok’ 7: end if

in the secure zone can only be called by non-secure zone through a callable-

API, but cannot be modified or inspected by the non-secure zone. Therefore,

the secure zone should execute security-critical jobs such as trusted data

collection, pattern extraction, encryption and decryption. The non-secure

zone can do non-security jobs such as user interface or packet routing. To

make the system function as expected, we first develop drivers of security-

critical sensors within the secure zone, directly connecting them to the

corresponding devices by wire; then we assign higher system interrupt prior-

ities to security-critical tasks in order to achieve high real-time performance.

Fig. 4.1 demonstrates the system block diagram with basic components

introduced as follows.

At the lowest kernel level, a secure boot module and an integrity checker

are first activated after booting. These two modules validate the current

image (burnt-in executable) by computing its RSA signature and comparing

it with the pre-stored correct one. If no corruption is found, the CPU control

is transferred to the secure zone user space. The Protected Flash Region

(PFR) stores the master secret key mas_sk and the key pair T EE_pk and

T EE_sk, and must be checked for integrity by secure boot. If passing the

check, which means that mas_sk and the key pair in PFR are intact, they

are retrieved from PFR and loaded into the secure zone RAM. One can see

that these keys cannot be faked, corrupted, or stolen from the PFR and the

�� /0�� 1�� /�0

��!��

��

� �� !� "�#�$�%� ��

&��

"� ��&�� $�� $

�&��

��

'( � $�� #��

��!�� &�� )�� $� *��

+�� ,��

��-� �

.� ��-� �

� $� �� $� �!��

,/�� &�� %� ��

��"�#�$��

��

' ��*� � �� $ � ��

Figure 4.1: Block Diagram of the System

secure zone. The master secret key mas_sk is used to derive session keys for

AES encryption while the public key pair is used for message authentication

and signature verification.

At the secure zone we develop and assemble the drivers of the photosen-

sor, GPS, camera, and temperature sensor in C language on our own. We

also define critical logics and parameters such as the raw data collecting

procedure, buffer size, inner capture frequency, debug procedures, and so

on. This is reflected by Function Sensors_get(θ) in Algorithm 1, where

θ is a threshold to ensure that the photosensor returns binary 1 if and only

if its reading is above θ .

The data processing and monitoring module collects data from the sen-

sors as C then compares the data with the predefined legit pattern Γ. If this

checking finds any violation against Γ defined in Section 4.4, an immediate

alarm message along with the current timestamp is generated. Note that

this alarm message is directly sent out and does not affect normal data

uploading. This is shown as Function Violation_check(C,ΓP,ΓT ,ΓG) in

Algorithm 1. Next we retrieve the current system clock t, and packs all

into a correct data structures (t,C,π), where π is the publicly verifiable

signature computed using T EE_sk to authenticate the trusted source of data

C. Finally we check if there are lost history data (if so, includes them as f ),

encrypt f ||(t,C,π) with the session key sym_sk, and call 4GSend() presented in Algorithm 1 to upload the data to the blockchain. This procedure is sum-

marized by Algorithm 3 and the flow chart of the data uploading procedure

is illustrated in Fig. 4.2.

��

�� !

"��

�� #�$�

#�$��

��

%��

&��

'��

&( �(�� )�� &� �� /��*��

(�� &��/�!

'��

��

&� � �� +��!

+�� ,��

��

(��

��

&��

'��

�� &�� $�"��

��

#��$��

(��

Figure 4.2: Flowchart of the System

The encryption and signature module performs encryption, signature

signing, and verification. Recall that the system has a master secret key

mas_sk and a public/private key pair T EE_pk and T EE_sk. To save computa-

tional resource, we need a symmetrical session key for encryption with AES.

This symmetrical key sym_sk can be derived as an AES encryption output

of concatenation of the master secret key mas_sk, the recipient public key

rec p_pk, and a True Random Number which is generated by the embedded

True Random Number Generator (TRNG). AES encryption is a common

source of randomness to derive symmetric key. Since it is CCA-secure,

attackers cannot have more than negligible probability to infer mas_sk pro-

viding sym_sk. We then encrypt symmetric key sym_sk once using the remote

blockchain agent’s public key to securely deliver sym_sk. This function is

shown in Function KDF(mas_sk,rec p_pk,rec p_addr).

Finally in the secure zone, a Universal Asynchronous Receiver/Trans-

mitter (UART) module receives a message and sends it out to the non-

secure zone. The 4G or NB-IoT communication module, or LinkServer local

USB debug probe receives the data output from the UART module. For

time-sensitive applications it can use 4G module to transmit; for energy-

efficiency-sensitive applications it can use NB-IoT module to transmit. The

lightweight blockchain client in TEE provides the current remote blockchain

agent server’s address to which data can be redirected after entering the

Internet. A user debug interface connects UART to USB and permits output

via PC at the specific IDE. Fig. 4.3 shows another view of the system.

We notice that there exist other works that use TEE to perform trustwor-

thy operations. However, they are either prohibitively expensive for using the

more-easy-to-implement but expensive chipsets such as the Intel SGX, or

macro-controller Cortex A-series that does not strictly enforce secure zone

physical isolation. In this paper, to the best of our knowledge, we are the

100

�"��#"� ��

��

� ��

��

��!�"�� #�� $

��

"��%��

��!�� &��'��

& ##( � ��

� �� )�� %

�� !�� &��

&��%� � ��

Figure 4.3: Abstract Architecture of System

first to implement the system using Cortex-M series TrustZone Chipset as

it is the first series that physically divides secure zone from the non-secure

zone. It also poses great engineering challenge and overhead for having

very few usable libraries, kernels, and operating systems. We build the

system from the bare metal level using C and Assembly. To the best of our

knowledge, we are the first to implement such a trustworthy system using

the challenging yet cheap Cortex M33 MCU, which is priced around $40,

while most other Intel SGX works cost around $300 ∼ $400.

4.5.2 Consistency Analysis

As discussed earlier, to achieve trusted physical traceability, we must ensure

1. any event that happens must be uploaded and available within δ time;

2. a constant and periodical monitoring every Δt time,

which are respectively the real-time data consistency and digital entity valid-

101

Algorithm 3 Data Uploading Protocol 1: Input: recp_addr,max_ f 2: //Sensing cycle length, remote blockchain agent address, max number

of packet resend tolerance. 3: Initialization: Initialize system hardware. Activate blockchain. Syn-

chronize system clock and blockchain client with external GPS time. 4: KDF(mas_sk,recp_pk,recp_addr) 5: 6: while It is time for periodic reporting do 7: C = Sensors_get(θ ) 8: Violation_check(C,ΓP,ΓT ,ΓG) 9: t = get_sys_clock()

10: π = signRSA(C,TEEsk) 11: if queue!=‘null’&& len(queue)≤ max_ f then 12: f =queue.pop() 13: else if queue!=‘null’&& len(queue)> max_ f then 14: return ‘Exceed maximum recovery tolerance’ 15: end if 16: msg = EncAES( f ||(t,C,π),sym_sk) 17: status=4Gsend(msg, rec p_addr) 18: if status==‘fail’ then 19: queue.push( f ||(t,C,π)) 20: end if 21: end while 22: return 0

102

ity. Algorithm 3 shows the pseudocode of the data uploading protocol. We

now analyze the worst latency performance of this protocol.

Time latency is a sum of three random system delays, i.e., ε = ε1 + ε2 + ε3,

which are described as follows.

1. ε1 is the delay of local data sensing and processing in the system. It

begins at the moment the system starts sensing, and ends by the time

the secure zone outputs a signed ciphertext data D = (t,C,π)|| f as a digital record.

2. ε2 is the delay of transmission between the TEE system to the remote

blockchain agent, who then decrypts the data and relays to the whole

blockchain. It starts by the non-secure world receiving D and ends by

the remote blockchain agent obtaining D.

3. ε3 is the delay of synchronizing the records in the whole blockchain

system. It starts by the first blockchain node receiving D and ends

when all up-to-date blockchain nodes retrieving D from the blockchain.

In our system, we do not require strict synchronization between blockchain

and the sensing system, which is a strong assumption and may disqualify

many real-world applications. Instead, we allow K blocks to be evenly pro- duced between two GST times. Each of this small block proposing time has

a length B and each interval between B is denoted by ΔB. We set K = 3 in this study for illustration purpose. We require that all constantly active and

non-faulty blockchain nodes follow every block production at every B time

and synchronize at every GST. For most lightly-weighted or oblivious nodes

that may disconnect or fail from time to time, they can catch up blocks

afterwards as long as they are active before next GST.

103

Fig. 4.4 shows a normal operation of the system. One can see that time

ti is the local system timestamp at TEE when the event record should be

created, and Ti is the time when blockchain has this event publicly available.

The time gap Δt is the desired period between two planned sensings and ΔT

is the actual time period between two records. We know that the system

latency ε1 is stable for a properly developed system, and the transmission

latency ε2 should also be stable for a high performance transmission protocol

like 4G. The only unstable part that may affect the latency is ε3, as a record

may miss a block production time B. We use εs to denote the clock difference

between the TEE system and the remote blockchain agent, as the agent

actually proposes the record in blockchain.

Theorem 4. Assume that there is no record loss. For a sensing started at

time t, it takes at most δ +ΔB + εs time to have this sensed event available in

blockchain.

Proof. In the worst case, the sensing starts at time t, and after δ time the

record reaches the blockchain. But unfortunately this record just misses

one block production time B so it must wait one more ΔB time to be included

in blockchain. Considering the time synchronizing difference one can get

the result.

Note that for lightly-weighted and oblivious nodes that only synchronize

at GST time, the result in Theorem 4 is further relaxed to δ +ΔGST + εs.

Theorem 5. Assume that there is no record loss. For two consecutive timed

events recorded in blockchain, the maximum time difference is Δt + δ +ΔB + εs.

Proof. We consider the worst case again. After the first timed event took

place, we wait Δt which is the planned period between two sensing actions

104

for the next record. Then according to Theorem 1, it takes at most δ +ΔB + εs

time to have the next timed event to become available in blockchain.

We can also relax ΔB to ΔGST for weakly synchronized or oblivious nodes.

Note that we do not pose any further requirements on blockchain or our

system. For a blockchain with a higher TPS or a shorter finalization time,

the latency upper bound can be further decreased as the blockchain latency

ΔB and ΔGST may decrease.

GST �

�

��

� � � � ��

��

� ��

��

GST��

� � ��

��

Figure 4.4: Data uploading illustration

4.5.3 Lost Record Tolerance and Recovery

The whole system can malfunction in many ways; thus we need to consider

fault tolerance as well as recovery. The malfunction or halt of the TEE

system itself must require manual inspection and restart, and that of the

blockchain is out of the scope of this paper. Therefore we consider fault

tolerance and recovery for the transmissions between the TEE system and

the blockchain system, which is common in real world and doable in a

software level. On the other hand, if communication fails and the system

105

can prove to blockchain that it did create the data record back in time as

expected, those lost or late packets can be accepted without distrusting the

device.

Recall that for each digital record Di = (ti,Ci,πi)|| fi, the lost packets are stored in a queue and can be retrieved by

fi = queue.pop() (4.3)

Note that whenever a record D j is not acknowledged by blockchain, we have

queue.push( f j−1 || (t j,C j,π j)). (4.4)

In other words, if the system does not receive an ACK for a record from

blockchain, it pushes the data into the backup queue and try to resend it

at the next uploading cycle.

By this design, we claim that the system is invulnerable to the following

two common attacks, where 1) an adversary commits a jamming attack

and therefore the 4G module cannot send to or receive from the outer

world any information; and 2) the 4G signal is generally weak or the link is

disconnected. Both cases are common in practice, and appear to have the

device disconnected causing the records to be missed for a period of time.

Note that even when the transmission signal is down, the secure zone is

still constantly monitoring the environment inside the box and this backup

queue cannot be modified as it stays inside the secure zone.

We allow a maximum of max_ f number of consecutive missed packets to

be backed up and resent. If the packets are correctly recovered, at packets

then still follow the correct Δt patterns; thus we consider it acceptable and

not conflicting with the validity defined earlier.

106

Note that in case 1), the adversary may compromise the inner environ-

ment of the TEE system while jamming the communications. Nevertheless,

the records still stay in the secure zone (inside the backup queue), though

jamming prevents them from being sent out. Unless the adversary jams

the system forever or physically destroys the system, this attack action will

sooner or later be publicly revealed.

One last case exists where the system may be attacked without being

noticed, that is, an adversary jams the system for less than max_ f number

of record time and meanwhile 1) successfully breaks into the system and

retrieves the secret key then creates a valid signature, or 2) forges a signa-

ture without the secret key and impersonates this device to upload fake

data. These two cases can be nullified by the following security assump-

tions: 1) a trusted hardware (TEE) protects its programs in the secure zone

from inspection or modification and 2) the unforgeability proof of a secure

digital signature states that no polynomial time adversary can forge a valid

signature with a negligible probability.

4.6 Experiments

In this section, we put our system into an actual test. We implemented the

system as described earlier, attached it into a vaccine shipping box, and

performed consistency monitoring towards the vaccine transportation.

4.6.1 Setup

The system was implemented on an LPC55S69-EVK development board

from the NXP Semiconductor. The board consists of a LPC55S69 dual-

core Arm Cortex-M33 microcontroller, running at 150MHz, and supports

Arm TrustZone technology. For more information regarding LPC55S69-EVK

107

please refer to the user’s manual [43][42].

We developed our own blockchain system using Golang [22] for the best

flexibility support. Golang is quite popular in security community for its

memory-safe, high-concurrent, and high-usable properties. We adopted the

Tendermint-BFT consensus algorithm, which is the Delegate Proof-of-Stake

version of the original Practical Byzantine Fault Tolerance mechanism [10].

Specifically, Tendermint-BFT assigns different weights to different nodes

during BFT voting, while PBFT assigns equal weights to all nodes. This

weight, in practice, can be used to represent different trustworthiness of

different nodes. We implemented the main blockchain system with about

4000 line of codes in Golang. The PC we used is a 8-Core Intel i7-6700HQ @

2.6GHz with 16G memory and Ubuntu 18.04.1 GNU/Linux. We simulated

6 blockchain nodes on top of this PC as our blockchain system.

4.6.2 Evaluation

In our evaluation, we burned the project (containing codes for both the

secure zone and the non-secure zone) into the LPC55S69-EVK board system.

By providing a 5V external power bank, we made the system a standalone

one. The board was positioned to the right side of the inside vaccine shipping

box, leaving all critical sensors on the left side. As one can see from Fig.

4.5, the temperature sensor was the silver textured probe, and the main

part of the photosensor was a light-sensitive LED. The GPS antenna was

small in size and its signal power was not affected when sealed inside the

box. The 4G antenna was attached to the exterior top-left of the box. We

set Δt to be 10 seconds, which means that we sensed the environment and

uploaded to the blockchain one record every 10s. The maximum number

of blocks for error recovery was fixed to 5. In our experiment, we attached

108

the vaccine shipping box at the back seat of a motorcycle. The safe vaccine

transportation temperature was ranged from 13 to 15 degrees.

We rode the motorcycle along a street and continuously collected the

sensor data. To decrease the inside temperature of the vaccine box we

placed two ice bags. The following results represent the data collected

from 19:15:19 to 19:26:47 after the temperature dropped to the safe range,

during which the 4G antenna was unplugged from 19:18:48 to 19:19:08

and from 19:25:48 to 19:26:18 to mimic two short jamming attacks. The

vaccine box was opened at 19:25:27 and remained open until 19:26:47. As

the sensing interval is 10 seconds, we collected in total 92 data points. Due

to jamming we missed 3 records from the first attack and 4 records from

the second one.

$��

��

Figure 4.5: Photo of the vaccine shipping box with sensing devices

From the 92 data points one can experimentally investigate the critical

latencies of the system, i.e., ε1,ε2, and ε3. We observed that ε1 was between 5

to 7 seconds, with a mean of 6.6244 seconds and a variance of 0.2284. This

109

is due to the low computation power of the embedded IoT devices. When

4G signals were stable, the 4G transmission latency ε2 was between 50 and

80 milliseconds, with a mean of 76.3 ms and a variance of 2.2 × 10−5. Each data record was about tens of KB so it did not inflict huge transmission

overhead. The blockchain latency ε3 was less than 60 milliseconds with a

mean of 53.85 ms and a variance of 2.36 × 10−7, as we had only 6 blockchain nodes. The maximum latency among all the data was 7.78 seconds. So one

can safely assert that the total latency upper limit was 8 seconds for our

test system.

Fig. 4.6 visualizes the actual shipping trace. We setup five predefined

security checkpoints (gold stars) and fixed a radius of 500 meters (purple big

circles). The security checkpoints and radius together define an approved

ground transportation trace, which is a road shown as a faint white trace

from left to right2. As one can see from the figure, the location was recorded,

uploaded and authenticated regularly (red dots), demonstrating a trusted

actual transportation trace. Although there were 3+4 planned jamming

losses (green crosses), the records were all resent and recovered by the next

following one. The 3 dropped records in the middle were clear to see as

green crosses, with one of them overlapping with another data. The 4 in

the end were all overlapping with others as we were circling in a small area.

As one can see from the figure, the driver clearly did not deviate from the

predefined route.

During transportation, we first kept the temperature low and made it

stay steady at 14 degrees Celsius. Figure 4.7 shows the recordings of our

actions, where we kept the box closed and sealed during time 0-600 (blue

stars), and then opened it (at a summertime) after time 600 (red stars). Note 2Not to confuse with the grey one, which is a river.

110

39°41'30"N

39°42'N

L a tit

u d e

119°08'E 119°09'E

Longitude

Esri, HERE 2000 ft

500 m

Shipping Trace Actual Uploaded Locations Checkpoints Checkpoint Safe Limits Recovered Lost Positions

Figure 4.6: GPS movement trace and security checkpoints

that the x-axis uses the relative time from 0 to 700 instead of the actual

data collection time for better illustration. After the box was opened, its

internal temperature was quickly increased for 10 consecutive records and

stayed stable at around 24 degrees. When these records were synchronized

at all blockchain nodes, it was easy to observe and prove that this vaccine

was exposed to undesirable temperature and should be no longer acceptable

for customer use. Our planned jamming losses at time 200 (yellow stars)

and 600 (orange stars) were also recovered nicely, as shown in this figure.

The outputs of the photosensor were illustrated in Fig. 4.8. One can see

clearly that the sealed vaccine box was opened at time 600. When the box

was sealed, it remained dark (with a proper threshold that can negate faint

111

0 100 200 300 400 500 600 700

time/s

te m

p e

ra tu

re /

° C

Bad Temperature Normal Temperature Safe Temperature Zone Recovered Normal Temperature Recovered Bad Temperature

Figure 4.7: Temperature fluctuation

LEDs inside the box) and hence the photosensor constantly output 0 (blue

crosses); while when the box was opened at time 600 and was exposed to

the sun, the photosensor snapped the ray and output the 3.3V high logic

voltage level to the board (red crosses indicating the logical output of 1 in

Fig. 4.8). The photo and temperature sensors together can enhance the

confidence that the box and its inside were indeed compromised. Fig. 4.8

also demonstrates that our 3+4 planned jamming losses at around time

200 and 600 were recovered correctly.

4.7 Related Work

There exist a few attempts to extend the blockchain trustworthiness from

on-chain to the physical world, by either applying blockchain directly to the

112

0 100 200 300 400 500 600 700 time/s

P h

o to

s e

n s

o r

lo g

ic l

e v

e l

o u

tp u

Dark--No light Bright--With light Recovered Normal Dark Recovered Violation Bright

Figure 4.8: Photosensor and its logic voltage level output

physical scenarios making use of blockchain security, or using secure hard-

ware or cryptographic primitives to enhance blockchain’s internal security

and trustworthiness.

Blockchain technologies have been applied in the fields of smart city,

autonomous driving, smart home, etc. Zhou et al. proposed a hierarchical

IoT architecture for smart home environments, where each home maintains

a private chain that can hierarchically construct into a public one. However

there were no countermeasures or discussions regarding how to stop the

home owner from faking the record and lying to the public chain and how

to validate the subchain data authenticity at the public chain. Guo et

al. developed an event recording system for autonomous vehicles with

blockchain, and presented the concept of “proof of event”, which is a hash

113

digest of a combination of event locations, embedded vehicle event recorder

readings and timestamps. This digest does not include any unforgeable

data or data from an authenticated source, thus it can be easily faked

afterwards [23]. It is also vulnerable to sybil attacks, where the fake data is

shared among all sybil identities and uploaded by all, in order to increase

the confidence of the fake data.

The above examples demonstrate a common problem shared by most

blockchain applications: the blockchain trustworthiness is confined within

the on-chain environment. There is no strong guarantee that the on-chain

records continuously and truthfully reflect the true physical world, and that

the blockchain control instructions are forcibly deployed on time.

Secure hardware or cryptographic primitives were also employed to en-

hance the blockchain security. Lind et al. proposed TEEChain, a TEE-based

secure payment blockchain network in which TEE was used as treasuries to

manage the off-chain funds and payments inside the TEE secure zone [34].

Ayoade et al. used the Intel SGX to securely offload data from on-chain to

SGX-powered databases, which can hash the stored data and compare to

the correct hash stored in the blockchain for data correctness verification.

Dang et al. managed to scale blockchain via sharding and Intel SGX. They

made use of the protected enclave module in Intel SGX to enhance secu-

rity and increase the performance of the Proof-of-Elapsed-Time consensus

and the PBFT consensus algorithms. Chainlink [12] and Provable [46]

adopted various secure hardware such as Intel SGX to build a trusted inter-

blockchain data exchange solution or website-to-blockchain trusted data

input oracle. Some of these works made impressive progress by achieving

trust extension between blockchains or between a blockchain and other

digital environments, but they cannot extend trust from on-chain to the

114

physical world. Not to mention that Intel SGX is a server-level hardware that

typically costs around $300 to $400, which highly restricts its adoptions by

IoT applications.

In this paper we propose a scheme to extend trust from on-chain to the

off-chain physical world by developing a TEE-enabled trusted environment

monitoring system and a fault tolerance uploading protocol to achieve real-

time high data consistency between on-chain digital world and off-chain

physical world. As far as we know, we are the first to overcome all engineering

challenges and develop such a trustworthy system over the Cortex M33

MCU, which is highly competitive in price – around $40, approximately

one-tenth of that of Intel SGX.

4.8 Conclusions

In this paper, we propose a scheme to extend blockchain trust from on-

chain to off-chain, and implement the full system taking trustworthy vaccine

shipping as an example. Our scheme consists of a TEE-enabled Trusted

Environment Monitoring System that continuously senses and generates

anti-forgery data, and a consistency protocol that uploads data from the

system and blockchain in an orderly, consistent, and fault-tolerating way.

Our experiment records the internal status of the vaccine shipping box

during the whole shipping process. One can see that our system is quite

efficient with approximately 7-second of system processing time, 70ms

of transmission time, and 40ms of blockchain synchronizing time. Our

planned jamming attacks and physical violations are also captured and

errors are recovered as expected.

As an exploratory work, we select vaccine transportation as an exam-

ple and choose the photosensor, GPS sensor and temperature sensor to

115

describe the status of a moving vaccine box. As we have our full system

available, which is a relatively general framework that can customize critical

parameters and tools, researchers can extend to any application of their

interest by developing their own additional sensing devices based on our

system template. We keep this work open-sourced at https://github.com/

zhuaiballl/TEE-enabled_Trusted_Environment_Monitoring_System

116

Bibliography

[1] Hussam Abu-Libdeh, Robbert Van Renesse, and Ymir Vigfusson. Lever- aging sharding in the design of scalable replication protocols. In Pro- ceedings of the 4th annual Symposium on Cloud Computing, page 12. ACM, 2013.

[2] Amazon. Grammar of the iam json policy language. Avail- able at https://docs.aws.amazon.com/IAM/latest/UserGuide/ reference_policies\_grammar.html.

[3] Amazon. Key by amazon smart lock kit. Available at https://www.amazon.com/gp/help/customer/display.html?ie= UTF8&\nodeId=202104340.

[4] Andras Cser. Xacml is dead. Available at https://go.forrester.com/ blogs/13-05-07-xacml_is_dead/.

[5] Axiomatics. Top ten reasons why developers don’t adopt abac. Available at https://www.slideshare.net/Axiomatics/axio-irm- summit-2014/17.

[6] block.one. Eos whitepaper, v2. Available at https://github.com/ EOSIO/Documentation/blob/master/TechnicalWhitePaper.md/, Mar 16 2018.

[7] Dan Boneh, Giovanni Di Crescenzo, Rafail Ostrovsky, and Giuseppe Persiano. Public key encryption with keyword search. In International conference on the theory and applications of cryptographic techniques, pages 506–522. Springer, 2004.

[8] Dan Boneh and Matt Franklin. Identity-based encryption from the weil pairing. In Annual international cryptology conference, pages 213–229. Springer, 2001.

[9] Dan Boneh, Craig Gentry, Ben Lynn, and Hovav Shacham. Aggregate and verifiably encrypted signatures from bilinear maps. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 416–432. Springer, 2003.

[10] Ethan Buchman, Jae Kwon, and Zarko Milosevic. The latest gossip on bft consensus. arXiv preprint arXiv:1807.04938, 2018.

[11] Z Berkay Celik, Gang Tan, and Patrick D McDaniel. Iotguard: Dynamic enforcement of security and safety policy in commodity iot. In NDSS, 2019.

117

[12] ChainLink. The chainlink network provides reliable tamper-proof inputs and outputs for complex smart contracts on any blockchain. Available at https://chain.link, 2020.

[13] CNN Tech. Google admits its new smart speaker was eavesdrop- ping on users. Available at https://money.cnn.com/2017/10/11/ technology/google-home-mini-security-flaw/index.html, Oc- tober 12 2017.

[14] Emanuele Cozzi, Mariano Graziano, Yanick Fratantonio, and Davide Balzarotti. Understanding linux malware. In 2018 IEEE Symposium on Security and Privacy (SP), pages 161–175. IEEE, 2018.

[15] Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the presence of partial synchrony. Journal of the ACM (JACM), 35(2):288– 323, 1988.

[16] Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, and David Wagner. Android permissions demystified. In Proceedings of the 18th ACM conference on Computer and communications security, pages 627– 638, 2011.

[17] Earlence Fernandes, Jaeyeon Jung, and Atul Prakash. Security analy- sis of emerging smart home applications. In 2016 IEEE Symposium on Security and Privacy (SP), pages 636–654. IEEE, 2016.

[18] Earlence Fernandes, Justin Paupore, Amir Rahmati, Daniel Simionato, Mauro Conti, and Atul Prakash. Flowfence: Practical data protection for emerging iot application frameworks. In 25th {USENIX} Security Symposium ({USENIX} Security 16), pages 531–548, 2016.

[19] Earlence Fernandes, Amir Rahmati, Jaeyeon Jung, and Atul Prakash. Decentralized action integrity for trigger-action iot platforms. In Pro- ceedings 2018 Network and Distributed System Security Symposium, 2018.

[20] Michael J Fischer, Nancy A Lynch, and Michael S Paterson. Impossi- bility of distributed consensus with one faulty process. Journal of the ACM (JACM), 32(2):374–382, 1985.

[21] Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosys- tems. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 295–310. Springer, 1999.

[22] Golang. Golang documentation. Available at https://golang.org/ doc/, 2020.

118

[23] Hao Guo, Ehsan Meamari, and Chien-Chung Shen. Blockchain- inspired event recording system for autonomous vehicles. In 2018 1st IEEE International Conference on Hot Information-Centric Networking (HotICN), pages 218–222. IEEE, 2018.

[24] Song Guo and Deze Zeng. Cyber-Physical Systems: Architecture, Security and Application. Springer, 2019.

[25] Dick Hardt et al. The oauth 2.0 authorization framework. Technical report, RFC 6749, October, 2012.

[26] Anthony Harrington and Christian Jensen. Cryptographic access control in a distributed file system. In Proceedings of the eighth ACM symposium on Access control models and technologies, pages 158–165, 2003.

[27] Pili Hu, Ronghai Yang, Yue Li, and Wing Cheong Lau. Application impersonation: problems of oauth and api design in online social networks. In Proceedings of the second ACM conference on Online social networks, pages 271–278, 2014.

[28] Vincent C Hu, David Ferraiolo, Rick Kuhn, Arthur R Friedman, Alan J Lang, Margaret M Cogdell, Adam Schnitzer, Kenneth Sandlin, Robert Miller, Karen Scarfone, et al. Guide to attribute based access control (abac) definition and considerations (draft). NIST special publication, 800(162), 2013.

[29] I Indu, PM Rubesh Anand, and Vidhyacharan Bhaskar. Identity and access management in cloud environment: Mechanisms and challenges. Engineering science and technology, an international journal, 21(4):574– 588, 2018.

[30] Sonia Jahid, Imranul Hoque, Hamed Okhravi, and Carl A Gunter. Enhancing database access control with xacml policy. In Proceedings of the ACM Conference on Computer and Communications Security (CCS), pages 130–133, 2009.

[31] Yizhen Jia, Yinhao Xiao, Jiguo Yu, Xiuzhen Cheng, Zhenkai Liang, and Zhiguo Wan. A novel graph-based mechanism for identifying traffic vulnerabilities in smart home iot. In IEEE INFOCOM 2018-IEEE Conference on Computer Communications, pages 1493–1501. IEEE, 2018.

[32] Günter Karjoth, Andreas Schade, and Els Van Herreweghen. Imple- menting acl-based policies in xacml. In 2008 Annual Computer Security Applications Conference (ACSAC), pages 183–192. IEEE, 2008.

119

[33] Ranjit Kumaresan and Iddo Bentov. How to use bitcoin to incentivize correct computations. In Proceedings of the 2014 ACM SIGSAC Confer- ence on Computer and Communications Security, pages 30–41, 2014.

[34] Joshua Lind, Oded Naor, Ittay Eyal, Florian Kelbert, Emin Gün Sirer, and Peter Pietzuch. Teechain: a secure payment network with asyn- chronous blockchain access. In Proceedings of the 27th ACM Symposium on Operating Systems Principles, pages 63–79, 2019.

[35] Markus Lorch, Seth Proctor, Rebekah Lepro, Dennis Kafura, and Sumit Shah. First experiences using xacml for access control in distributed systems. In Proceedings of the 2003 ACM workshop on XML security, pages 25–37, 2003.

[36] Damiano Di Francesco Maesa, Paolo Mori, and Laura Ricci. Blockchain based access control services. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Commu- nications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pages 1379–1386. IEEE, 2018.

[37] James Martin. Lost on the silk road: Online drug distribution and the ‘cryptomarket’. Criminology & Criminal Justice, 14(3):351–367, 2014.

[38] Ken Martin and Bill Hoffman. Mastering CMake: a cross-platform build system. Kitware, 2010.

[39] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Technical report, Manubot, 2019.

[40] Nature. Chinese maker of faulty rabies vaccines fined bhttps://golang.org/doc/illions of yuan. Available at https: //www.nytimes.com/2018/07/23/world/asia/china-vaccines- scandal-investigation.html, July 23, 2018.

[41] Carib M Nelson, Hariadi Wibisono, Hary Purwanto, Isa Mansyur, Vanda Moniaga, and Anton Widjaya. Hepatitis b vaccine freezing in the in- donesian cold chain: evidence and solutions. Bulletin of the World Health Organization, 82:99–105, 2004.

[42] NXP Semiconductor. Lpc55s69-evk: Lpcxpresso55s69 devel- opment board. Available at https://www.nxp.com/products/ processors-and-microcontrollers/arm-microcontrollers/ general-purpose-mcus/lpc5500-cortex-m33/lpcxpresso55s69- development-board:LPC55S69-EVK, 2020.

[43] NXP Semiconductor. Nxp semiconductors lpc55s6x arm cortex-m33 microcontrollers. Available at https://www.nxp.com/products/

120

processors-and-microcontrollers/arm-microcontrollers/ general-purpose-mcus/lpc5500-cortex-m33/high-efficiency- arm-cortex-m33-based-microcontroller-family:LPC55S6x, 2020.

[44] Aafaf Ouaddah, Anas Abou Elkalam, and Abdellah Ait Ouahman. Fairaccess: a new blockchain-based access control framework for the internet of things. Security and Communication Networks, 9(18):5943– 5964, 2016.

[45] Torben Pryds Pedersen. A threshold cryptosystem without a trusted party. In Workshop on the Theory and Application of of Cryptographic Techniques, pages 522–526. Springer, 1991.

[46] Provable. The provable blockchain oracle for modern dapps. Available at https://provable.xyz, 2020.

[47] Mohamed Sabt, Mohammed Achemlal, and Abdelmadjid Bouabdallah. Trusted execution environment: what it is, and what it is not. In 2015 IEEE Trustcom/BigDataSE/ISPA, volume 1, pages 57–64. IEEE, 2015.

[48] Ravi Sandhu and Pierangela Samarati. Authentication, access control, and audit. ACM Computing Surveys (CSUR), 28(1):241–243, 1996.

[49] Gregory Saunders, Michael Hitchens, and Vijay Varadharajan. Role- based access control and the access control matrix. ACM SIGOPS Operating Systems Review, 35(4):6–20, 2001.

[50] Roei Schuster, Vitaly Shmatikov, and Eran Tromer. Situational access control in the internet of things. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1056–1073, 2018.

[51] Amit Kumar Sikder, Hidayet Aksu, and A Selcuk Uluagac. 6thsense: A context-aware sensor-based attack detector for smart devices. In 26th {USENIX} Security Symposium ({USENIX} Security 17), pages 397–414, 2017.

[52] Dawn Xiaoding Song, David Wagner, and Adrian Perrig. Practical techniques for searches on encrypted data. In Security and Privacy, 2000. S&P 2000. Proceedings. 2000 IEEE Symposium on, pages 44–55. IEEE, 2000.

[53] The Washington Post. Alexa has been eavesdropping on you this whole time. Available at https://www.washingtonpost.com/technology/ 2019/05/06/alexa-has-been-eavesdropping-you-this-whole- time/, May 6 2019.

121

[54] Yuan Tian, Nan Zhang, Yueh-Hsun Lin, XiaoFeng Wang, Blase Ur, Xianzheng Guo, and Patrick Tague. Smartauth: User-centered autho- rization for the internet of things. In 26th {USENIX} Security Symposium ({USENIX} Security 17), pages 361–378, 2017.

[55] The New York Times. In china, vaccine scandal infuriates parents and tests government. Available at https://www.nature.com/articles/ d41586-018-07136-z, October 23, 2018.

[56] USA Today. Amazon secretly recording and storing what your kids say, complaint says. Available at https://www.usatoday.com/story/ tech/2019/05/09/amazon-accused-secretly-recording-kids- echo-dot-speakers/1150651001/, May 09 2019.

[57] Rui Wang, Shuo Chen, XiaoFeng Wang, and Shaz Qadeer. How to shop for free online–security analysis of cashier-as-a-service based web stores. In Security and Privacy (SP), 2011 IEEE Symposium on, pages 465–480. IEEE, 2011.

[58] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151:1–32, 2014.

[59] Yinhao Xiao, Yizhen Jia, Chunchi Liu, Xiuzhen Cheng, Jiguo Yu, and Weifeng Lv. Edge computing security: State of the art and challenges. Proceedings of the IEEE, 107(8):1608–1631, June 2019.

[60] Ronghua Xu, Yu Chen, Erik Blasch, and Genshe Chen. Blendcac: A blockchain-enabled decentralized capability-based access control for iots. In 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pages 1027–1034. IEEE, 2018.

[61] H. Yang, X. Ma, K. Du, Z. Li, H. Duan, X. Su, G. Liu, Z. Geng, and J. Wu. How to learn klingon without a dictionary: Detection and measurement of black keywords used by the underground economy. In 2017 IEEE Symposium on Security and Privacy (SP), pages 751–769, May 2017.

[62] N. Zhang, X. Mi, X. Feng, X. Wang, Y. Tian, and F. Qian. Dangerous skills: Understanding and mitigating security risks of voice-controlled third-party functions on virtual personal assistant systems. In 2019 IEEE Symposium on Security and Privacy (SP), pages 1381–1396, May 2019.

[63] Yuanyu Zhang, Shoji Kasahara, Yulong Shen, Xiaohong Jiang, and Jianxiong Wan. Smart contract-based access control for the internet of things. IEEE Internet of Things Journal, 6(2):1594–1605, 2018.

122

[64] Yan Zhu, Yao Qin, Guohua Gan, Yang Shuai, and William Cheng- Chung Chu. Tbac: transaction-based access control on blockchain for resource sharing with cryptographically decentralized authorization. In 2018 IEEE 42nd Annual Computer Software and Applications Conference (COMPSAC), volume 1, pages 535–544. IEEE, 2018.

123

<< /ASCII85EncodePages false /AllowTransparency false /AutoPositionEPSFiles true /AutoRotatePages /None /Binding /Left /CalGrayProfile (Dot Gain 20%) /CalRGBProfile (sRGB IEC61966-2.1) /CalCMYKProfile (U.S. Web Coated \050SWOP\051 v2) /sRGBProfile (sRGB IEC61966-2.1) /CannotEmbedFontPolicy /Warning /CompatibilityLevel 1.4 /CompressObjects /Tags /CompressPages true /ConvertImagesToIndexed true /PassThroughJPEGImages true /CreateJobTicket false /DefaultRenderingIntent /Default /DetectBlends true /DetectCurves 0.0000 /ColorConversionStrategy /CMYK /DoThumbnails false /EmbedAllFonts true /EmbedOpenType false /ParseICCProfilesInComments true /EmbedJobOptions true /DSCReportingLevel 0 /EmitDSCWarnings false /EndPage -1 /ImageMemory 1048576 /LockDistillerParams false /MaxSubsetPct 35 /Optimize true /OPM 1 /ParseDSCComments true /ParseDSCCommentsForDocInfo true /PreserveCopyPage true /PreserveDICMYKValues true /PreserveEPSInfo true /PreserveFlatness true /PreserveHalftoneInfo false /PreserveOPIComments true /PreserveOverprintSettings true /StartPage 1 /SubsetFonts true /TransferFunctionInfo /Apply /UCRandBGInfo /Preserve /UsePrologue false /ColorSettingsFile () /AlwaysEmbed [ true ] /NeverEmbed [ true ] /AntiAliasColorImages false /CropColorImages true /ColorImageMinResolution 300 /ColorImageMinResolutionPolicy /OK /DownsampleColorImages true /ColorImageDownsampleType /Bicubic /ColorImageResolution 300 /ColorImageDepth -1 /ColorImageMinDownsampleDepth 1 /ColorImageDownsampleThreshold 1.00000 /EncodeColorImages true /ColorImageFilter /DCTEncode /AutoFilterColorImages true /ColorImageAutoFilterStrategy /JPEG /ColorACSImageDict << /QFactor 0.15 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /ColorImageDict << /QFactor 0.15 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /JPEG2000ColorACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 30 >> /JPEG2000ColorImageDict << /TileWidth 256 /TileHeight 256 /Quality 30 >> /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.00000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict << /QFactor 0.15 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /GrayImageDict << /QFactor 0.15 /HSamples [1 1 1 1] /VSamples [1 1 1 1] >> /JPEG2000GrayACSImageDict << /TileWidth 256 /TileHeight 256 /Quality 30 >> /JPEG2000GrayImageDict << /TileWidth 256 /TileHeight 256 /Quality 30 >> /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.00000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict << /K -1 >> /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile () /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False /CreateJDFFile false /Description << /ARA <FEFF06270633062A062E062F0645002006470630064700200627064406250639062F0627062F0627062A002006440625064606340627062100200648062B062706260642002000410064006F00620065002000500044004600200645062A064806270641064206290020064406440637062806270639062900200641064A00200627064406450637062706280639002006300627062A0020062F0631062C0627062A002006270644062C0648062F0629002006270644063906270644064A0629061B0020064A06450643064600200641062A062D00200648062B0627062606420020005000440046002006270644064506460634062306290020062806270633062A062E062F062706450020004100630072006F0062006100740020064800410064006F006200650020005200650061006400650072002006250635062F0627063100200035002E0030002006480627064406250635062F062706310627062A0020062706440623062D062F062B002E0635062F0627063100200035002E0030002006480627064406250635062F062706310627062A0020062706440623062D062F062B002E> /BGR <FEFF04180437043f043e043b043704320430043904420435002004420435043704380020043d0430044104420440043e0439043a0438002c00200437043000200434043000200441044a0437043404300432043004420435002000410064006f00620065002000500044004600200434043e043a0443043c0435043d04420438002c0020043c0430043a04410438043c0430043b043d043e0020043f044004380433043e04340435043d04380020043704300020043204380441043e043a043e043a0430044704350441044204320435043d0020043f04350447043004420020043704300020043f044004350434043f0435044704300442043d04300020043f043e04340433043e0442043e0432043a0430002e002000200421044a04370434043004340435043d043804420435002000500044004600200434043e043a0443043c0435043d044204380020043c043e0433043004420020043404300020044104350020043e0442043204300440044f0442002004410020004100630072006f00620061007400200438002000410064006f00620065002000520065006100640065007200200035002e00300020043800200441043b0435043404320430044904380020043204350440044104380438002e> /CHS <FEFF4f7f75288fd94e9b8bbe5b9a521b5efa7684002000410064006f006200650020005000440046002065876863900275284e8e9ad88d2891cf76845370524d53705237300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c676562535f00521b5efa768400200050004400460020658768633002> /CHT <FEFF4f7f752890194e9b8a2d7f6e5efa7acb7684002000410064006f006200650020005000440046002065874ef69069752865bc9ad854c18cea76845370524d5370523786557406300260a853ef4ee54f7f75280020004100630072006f0062006100740020548c002000410064006f00620065002000520065006100640065007200200035002e003000204ee553ca66f49ad87248672c4f86958b555f5df25efa7acb76840020005000440046002065874ef63002> /CZE <FEFF005400610074006f0020006e006100730074006100760065006e00ed00200070006f0075017e0069006a007400650020006b0020007600790074007600e101590065006e00ed00200064006f006b0075006d0065006e0074016f002000410064006f006200650020005000440046002c0020006b00740065007200e90020007300650020006e0065006a006c00e90070006500200068006f006400ed002000700072006f0020006b00760061006c00690074006e00ed0020007400690073006b00200061002000700072006500700072006500730073002e002000200056007900740076006f01590065006e00e900200064006f006b0075006d0065006e007400790020005000440046002000620075006400650020006d006f017e006e00e90020006f007400650076015900ed007400200076002000700072006f006700720061006d0065006300680020004100630072006f00620061007400200061002000410064006f00620065002000520065006100640065007200200035002e0030002000610020006e006f0076011b006a016100ed00630068002e> /DAN <FEFF004200720075006700200069006e0064007300740069006c006c0069006e006700650072006e0065002000740069006c0020006100740020006f007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400650072002c0020006400650072002000620065006400730074002000650067006e006500720020007300690067002000740069006c002000700072006500700072006500730073002d007500640073006b007200690076006e0069006e00670020006100660020006800f8006a0020006b00760061006c0069007400650074002e0020004400650020006f007000720065007400740065006400650020005000440046002d0064006f006b0075006d0065006e0074006500720020006b0061006e002000e50062006e00650073002000690020004100630072006f00620061007400200065006c006c006500720020004100630072006f006200610074002000520065006100640065007200200035002e00300020006f00670020006e0079006500720065002e> /DEU <FEFF00560065007200770065006e00640065006e0020005300690065002000640069006500730065002000450069006e007300740065006c006c0075006e00670065006e0020007a0075006d002000450072007300740065006c006c0065006e00200076006f006e002000410064006f006200650020005000440046002d0044006f006b0075006d0065006e00740065006e002c00200076006f006e002000640065006e0065006e002000530069006500200068006f006300680077006500720074006900670065002000500072006500700072006500730073002d0044007200750063006b0065002000650072007a0065007500670065006e0020006d00f60063006800740065006e002e002000450072007300740065006c006c007400650020005000440046002d0044006f006b0075006d0065006e007400650020006b00f6006e006e0065006e0020006d006900740020004100630072006f00620061007400200075006e0064002000410064006f00620065002000520065006100640065007200200035002e00300020006f0064006500720020006800f600680065007200200067006500f600660066006e00650074002000770065007200640065006e002e> /ESP <FEFF005500740069006c0069006300650020006500730074006100200063006f006e0066006900670075007200610063006900f3006e0020007000610072006100200063007200650061007200200064006f00630075006d0065006e0074006f00730020005000440046002000640065002000410064006f0062006500200061006400650063007500610064006f00730020007000610072006100200069006d0070007200650073006900f3006e0020007000720065002d0065006400690074006f007200690061006c00200064006500200061006c00740061002000630061006c0069006400610064002e002000530065002000700075006500640065006e00200061006200720069007200200064006f00630075006d0065006e0074006f00730020005000440046002000630072006500610064006f007300200063006f006e0020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e003000200079002000760065007200730069006f006e0065007300200070006f00730074006500720069006f007200650073002e> /ETI <FEFF004b00610073007500740061006700650020006e0065006900640020007300e4007400740065006900640020006b00760061006c006900740065006500740073006500200074007200fc006b006900650065006c007300650020007000720069006e00740069006d0069007300650020006a0061006f006b007300200073006f00620069006c0069006b0065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740069006400650020006c006f006f006d006900730065006b0073002e00200020004c006f006f0064007500640020005000440046002d0064006f006b0075006d0065006e00740065002000730061006100740065002000610076006100640061002000700072006f006700720061006d006d006900640065006700610020004100630072006f0062006100740020006e0069006e0067002000410064006f00620065002000520065006100640065007200200035002e00300020006a00610020007500750065006d006100740065002000760065007200730069006f006f006e00690064006500670061002e000d000a> /FRA <FEFF005500740069006c006900730065007a00200063006500730020006f007000740069006f006e00730020006100660069006e00200064006500200063007200e900650072002000640065007300200064006f00630075006d0065006e00740073002000410064006f00620065002000500044004600200070006f0075007200200075006e00650020007100750061006c0069007400e90020006400270069006d007000720065007300730069006f006e00200070007200e9007000720065007300730065002e0020004c0065007300200064006f00630075006d0065006e00740073002000500044004600200063007200e900e90073002000700065007500760065006e0074002000ea0074007200650020006f007500760065007200740073002000640061006e00730020004100630072006f006200610074002c002000610069006e00730069002000710075002700410064006f00620065002000520065006100640065007200200035002e0030002000650074002000760065007200730069006f006e007300200075006c007400e90072006900650075007200650073002e> /GRE <FEFF03a703c103b703c303b903bc03bf03c003bf03b903ae03c303c403b5002003b103c503c403ad03c2002003c403b903c2002003c103c503b803bc03af03c303b503b903c2002003b303b903b1002003bd03b1002003b403b703bc03b903bf03c503c103b303ae03c303b503c403b5002003ad03b303b303c103b103c603b1002000410064006f006200650020005000440046002003c003bf03c5002003b503af03bd03b103b9002003ba03b103c42019002003b503be03bf03c703ae03bd002003ba03b103c403ac03bb03bb03b703bb03b1002003b303b903b1002003c003c103bf002d03b503ba03c403c503c003c903c403b903ba03ad03c2002003b503c103b303b103c303af03b503c2002003c503c803b703bb03ae03c2002003c003bf03b903cc03c403b703c403b103c2002e0020002003a403b10020005000440046002003ad03b303b303c103b103c603b1002003c003bf03c5002003ad03c703b503c403b5002003b403b703bc03b903bf03c503c103b303ae03c303b503b9002003bc03c003bf03c103bf03cd03bd002003bd03b1002003b103bd03bf03b903c703c403bf03cd03bd002003bc03b5002003c403bf0020004100630072006f006200610074002c002003c403bf002000410064006f00620065002000520065006100640065007200200035002e0030002003ba03b103b9002003bc03b503c403b103b303b503bd03ad03c303c403b503c103b503c2002003b503ba03b403cc03c303b503b903c2002e> /HEB <FEFF05D405E905EA05DE05E905D5002005D105D405D205D305E805D505EA002005D005DC05D4002005DB05D305D9002005DC05D905E605D505E8002005DE05E105DE05DB05D9002000410064006F006200650020005000440046002005D405DE05D505EA05D005DE05D905DD002005DC05D405D305E405E105EA002005E705D305DD002D05D305E405D505E1002005D005D905DB05D505EA05D905EA002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002E05D005DE05D905DD002005DC002D005000440046002F0058002D0033002C002005E205D905D905E005D5002005D105DE05D305E805D905DA002005DC05DE05E905EA05DE05E9002005E905DC0020004100630072006F006200610074002E002005DE05E105DE05DB05D90020005000440046002005E905E005D505E605E805D5002005E005D905EA05E005D905DD002005DC05E405EA05D905D705D4002005D105D005DE05E605E205D505EA0020004100630072006F006200610074002005D5002D00410064006F00620065002000520065006100640065007200200035002E0030002005D505D205E805E105D005D505EA002005DE05EA05E705D305DE05D505EA002005D905D505EA05E8002E> /HRV (Za stvaranje Adobe PDF dokumenata najpogodnijih za visokokvalitetni ispis prije tiskanja koristite ove postavke. Stvoreni PDF dokumenti mogu se otvoriti Acrobat i Adobe Reader 5.0 i kasnijim verzijama.) /HUN <FEFF004b0069007600e1006c00f30020006d0069006e0151007300e9006701710020006e0079006f006d00640061006900200065006c0151006b00e90073007a00ed007401510020006e0079006f006d00740061007400e100730068006f007a0020006c006500670069006e006b00e1006200620020006d0065006700660065006c0065006c0151002000410064006f00620065002000500044004600200064006f006b0075006d0065006e00740075006d006f006b0061007400200065007a0065006b006b0065006c0020006100200062006500e1006c006c00ed007400e10073006f006b006b0061006c0020006b00e90073007a00ed0074006800650074002e0020002000410020006c00e90074007200650068006f007a006f00740074002000500044004600200064006f006b0075006d0065006e00740075006d006f006b00200061007a0020004100630072006f006200610074002000e9007300200061007a002000410064006f00620065002000520065006100640065007200200035002e0030002c0020007600610067007900200061007a002000610074007400f3006c0020006b00e9007301510062006200690020007600650072007a006900f3006b006b0061006c0020006e00790069007400680061007400f3006b0020006d00650067002e> /ITA <FEFF005500740069006c0069007a007a006100720065002000710075006500730074006500200069006d0070006f007300740061007a0069006f006e00690020007000650072002000630072006500610072006500200064006f00630075006d0065006e00740069002000410064006f00620065002000500044004600200070006900f900200061006400610074007400690020006100200075006e00610020007000720065007300740061006d0070006100200064006900200061006c007400610020007100750061006c0069007400e0002e0020004900200064006f00630075006d0065006e007400690020005000440046002000630072006500610074006900200070006f00730073006f006e006f0020006500730073006500720065002000610070006500720074006900200063006f006e0020004100630072006f00620061007400200065002000410064006f00620065002000520065006100640065007200200035002e003000200065002000760065007200730069006f006e006900200073007500630063006500730073006900760065002e> /JPN <FEFF9ad854c18cea306a30d730ea30d730ec30b951fa529b7528002000410064006f0062006500200050004400460020658766f8306e4f5c6210306b4f7f75283057307e305930023053306e8a2d5b9a30674f5c62103055308c305f0020005000440046002030d530a130a430eb306f3001004100630072006f0062006100740020304a30883073002000410064006f00620065002000520065006100640065007200200035002e003000204ee5964d3067958b304f30533068304c3067304d307e305930023053306e8a2d5b9a306b306f30d530a930f330c8306e57cb30818fbc307f304c5fc59808306730593002> /KOR <FEFFc7740020c124c815c7440020c0acc6a9d558c5ec0020ace0d488c9c80020c2dcd5d80020c778c1c4c5d00020ac00c7a50020c801d569d55c002000410064006f0062006500200050004400460020bb38c11cb97c0020c791c131d569b2c8b2e4002e0020c774b807ac8c0020c791c131b41c00200050004400460020bb38c11cb2940020004100630072006f0062006100740020bc0f002000410064006f00620065002000520065006100640065007200200035002e00300020c774c0c1c5d0c11c0020c5f40020c2180020c788c2b5b2c8b2e4002e> /LTH <FEFF004e006100750064006f006b0069007400650020016100690075006f007300200070006100720061006d006500740072007500730020006e006f0072011700640061006d00690020006b0075007200740069002000410064006f00620065002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b00750072006900650020006c0061006200690061007500730069006100690020007000720069007400610069006b007900740069002000610075006b01610074006f00730020006b006f006b007900620117007300200070006100720065006e006700740069006e00690061006d00200073007000610075007300640069006e0069006d00750069002e0020002000530075006b0075007200740069002000500044004600200064006f006b0075006d0065006e007400610069002000670061006c006900200062016b007400690020006100740069006400610072006f006d00690020004100630072006f006200610074002000690072002000410064006f00620065002000520065006100640065007200200035002e0030002000610072002000760117006c00650073006e0117006d00690073002000760065007200730069006a006f006d00690073002e> /LVI <FEFF0049007a006d0061006e0074006f006a00690065007400200161006f00730020006900650073007400610074012b006a0075006d00750073002c0020006c0061006900200076006500690064006f00740075002000410064006f00620065002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b006100730020006900720020012b00700061016100690020007000690065006d01130072006f00740069002000610075006700730074006100730020006b00760061006c0069007401010074006500730020007000690072006d007300690065007300700069006501610061006e006100730020006400720075006b00610069002e00200049007a0076006500690064006f006a006900650074002000500044004600200064006f006b0075006d0065006e007400750073002c0020006b006f002000760061007200200061007400760113007200740020006100720020004100630072006f00620061007400200075006e002000410064006f00620065002000520065006100640065007200200035002e0030002c0020006b0101002000610072012b00200074006f0020006a00610075006e0101006b0101006d002000760065007200730069006a0101006d002e> /NLD (Gebruik deze instellingen om Adobe PDF-documenten te maken die zijn geoptimaliseerd voor prepress-afdrukken van hoge kwaliteit. De gemaakte PDF-documenten kunnen worden geopend met Acrobat en Adobe Reader 5.0 en hoger.) /NOR <FEFF004200720075006b00200064006900730073006500200069006e006e007300740069006c006c0069006e00670065006e0065002000740069006c002000e50020006f0070007000720065007400740065002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e00740065007200200073006f006d00200065007200200062006500730074002000650067006e0065007400200066006f00720020006600f80072007400720079006b006b0073007500740073006b00720069006600740020006100760020006800f800790020006b00760061006c0069007400650074002e0020005000440046002d0064006f006b0075006d0065006e00740065006e00650020006b0061006e002000e50070006e00650073002000690020004100630072006f00620061007400200065006c006c00650072002000410064006f00620065002000520065006100640065007200200035002e003000200065006c006c00650072002000730065006e006500720065002e> /POL <FEFF0055007300740061007700690065006e0069006100200064006f002000740077006f0072007a0065006e0069006100200064006f006b0075006d0065006e007400f300770020005000440046002000700072007a0065007a006e00610063007a006f006e00790063006800200064006f002000770079006400720075006b00f30077002000770020007700790073006f006b00690065006a0020006a0061006b006f015b00630069002e002000200044006f006b0075006d0065006e0074007900200050004400460020006d006f017c006e00610020006f007400770069006500720061010700200077002000700072006f006700720061006d006900650020004100630072006f00620061007400200069002000410064006f00620065002000520065006100640065007200200035002e0030002000690020006e006f00770073007a0079006d002e> /PTB <FEFF005500740069006c0069007a006500200065007300730061007300200063006f006e00660069006700750072006100e700f50065007300200064006500200066006f0072006d00610020006100200063007200690061007200200064006f00630075006d0065006e0074006f0073002000410064006f0062006500200050004400460020006d00610069007300200061006400650071007500610064006f00730020007000610072006100200070007200e9002d0069006d0070007200650073007300f50065007300200064006500200061006c007400610020007100750061006c00690064006100640065002e0020004f007300200064006f00630075006d0065006e0074006f00730020005000440046002000630072006900610064006f007300200070006f00640065006d0020007300650072002000610062006500720074006f007300200063006f006d0020006f0020004100630072006f006200610074002000650020006f002000410064006f00620065002000520065006100640065007200200035002e0030002000650020007600650072007300f50065007300200070006f00730074006500720069006f007200650073002e> /RUM <FEFF005500740069006c0069007a00610163006900200061006300650073007400650020007300650074010300720069002000700065006e007400720075002000610020006300720065006100200064006f00630075006d0065006e00740065002000410064006f006200650020005000440046002000610064006500630076006100740065002000700065006e0074007200750020007400690070010300720069007200650061002000700072006500700072006500730073002000640065002000630061006c006900740061007400650020007300750070006500720069006f006100720103002e002000200044006f00630075006d0065006e00740065006c00650020005000440046002000630072006500610074006500200070006f00740020006600690020006400650073006300680069007300650020006300750020004100630072006f006200610074002c002000410064006f00620065002000520065006100640065007200200035002e00300020015f00690020007600650072007300690075006e0069006c006500200075006c0074006500720069006f006100720065002e> /RUS <FEFF04180441043f043e043b044c04370443043904420435002004340430043d043d044b04350020043d0430044104420440043e0439043a043800200434043b044f00200441043e043704340430043d0438044f00200434043e043a0443043c0435043d0442043e0432002000410064006f006200650020005000440046002c0020043c0430043a04410438043c0430043b044c043d043e0020043f043e04340445043e0434044f04490438044500200434043b044f00200432044b0441043e043a043e043a0430044704350441044204320435043d043d043e0433043e00200434043e043f0435044704300442043d043e0433043e00200432044b0432043e04340430002e002000200421043e043704340430043d043d044b04350020005000440046002d0434043e043a0443043c0435043d0442044b0020043c043e0436043d043e0020043e0442043a0440044b043204300442044c002004410020043f043e043c043e0449044c044e0020004100630072006f00620061007400200438002000410064006f00620065002000520065006100640065007200200035002e00300020043800200431043e043b043504350020043f043e04370434043d043804450020043204350440044104380439002e> /SKY <FEFF0054006900650074006f0020006e006100730074006100760065006e0069006100200070006f0075017e0069007400650020006e00610020007600790074007600e100720061006e0069006500200064006f006b0075006d0065006e0074006f0076002000410064006f006200650020005000440046002c0020006b0074006f007200e90020007300610020006e0061006a006c0065007001610069006500200068006f0064006900610020006e00610020006b00760061006c00690074006e00fa00200074006c0061010d00200061002000700072006500700072006500730073002e00200056007900740076006f00720065006e00e900200064006f006b0075006d0065006e007400790020005000440046002000620075006400650020006d006f017e006e00e90020006f00740076006f00720069016500200076002000700072006f006700720061006d006f006300680020004100630072006f00620061007400200061002000410064006f00620065002000520065006100640065007200200035002e0030002000610020006e006f0076016100ed00630068002e> /SLV <FEFF005400650020006e006100730074006100760069007400760065002000750070006f0072006100620069007400650020007a00610020007500730074007600610072006a0061006e006a006500200064006f006b0075006d0065006e0074006f0076002000410064006f006200650020005000440046002c0020006b006900200073006f0020006e0061006a007000720069006d00650072006e0065006a016100690020007a00610020006b0061006b006f0076006f00730074006e006f0020007400690073006b0061006e006a00650020007300200070007200690070007200610076006f0020006e00610020007400690073006b002e00200020005500730074007600610072006a0065006e006500200064006f006b0075006d0065006e0074006500200050004400460020006a00650020006d006f0067006f010d00650020006f0064007000720065007400690020007a0020004100630072006f00620061007400200069006e002000410064006f00620065002000520065006100640065007200200035002e003000200069006e0020006e006f00760065006a01610069006d002e> /SUO <FEFF004b00e40079007400e40020006e00e40069007400e4002000610073006500740075006b007300690061002c0020006b0075006e0020006c0075006f00740020006c00e400680069006e006e00e4002000760061006100740069007600610061006e0020007000610069006e006100740075006b00730065006e002000760061006c006d0069007300740065006c00750074007900f6006800f6006e00200073006f00700069007600690061002000410064006f0062006500200050004400460020002d0064006f006b0075006d0065006e007400740065006a0061002e0020004c0075006f0064007500740020005000440046002d0064006f006b0075006d0065006e00740069007400200076006f0069006400610061006e0020006100760061007400610020004100630072006f0062006100740069006c006c00610020006a0061002000410064006f00620065002000520065006100640065007200200035002e0030003a006c006c00610020006a006100200075007500640065006d006d0069006c006c0061002e> /SVE <FEFF0041006e007600e4006e00640020006400650020006800e4007200200069006e0073007400e4006c006c006e0069006e006700610072006e00610020006f006d002000640075002000760069006c006c00200073006b006100700061002000410064006f006200650020005000440046002d0064006f006b0075006d0065006e007400200073006f006d002000e400720020006c00e4006d0070006c0069006700610020006600f60072002000700072006500700072006500730073002d007500740073006b00720069006600740020006d006500640020006800f600670020006b00760061006c0069007400650074002e002000200053006b006100700061006400650020005000440046002d0064006f006b0075006d0065006e00740020006b0061006e002000f600700070006e00610073002000690020004100630072006f0062006100740020006f00630068002000410064006f00620065002000520065006100640065007200200035002e00300020006f00630068002000730065006e006100720065002e> /TUR <FEFF005900fc006b00730065006b0020006b0061006c006900740065006c0069002000f6006e002000790061007a006401310072006d00610020006200610073006b013100730131006e006100200065006e0020006900790069002000750079006100620069006c006500630065006b002000410064006f006200650020005000440046002000620065006c00670065006c0065007200690020006f006c0075015f007400750072006d0061006b0020006900e70069006e00200062007500200061007900610072006c0061007201310020006b0075006c006c0061006e0131006e002e00200020004f006c0075015f0074007500720075006c0061006e0020005000440046002000620065006c00670065006c0065007200690020004100630072006f006200610074002000760065002000410064006f00620065002000520065006100640065007200200035002e003000200076006500200073006f006e0072006100730131006e00640061006b00690020007300fc007200fc006d006c00650072006c00650020006100e70131006c006100620069006c00690072002e> /UKR <FEFF04120438043a043e0440043804410442043e043204430439044204350020044604560020043f043004400430043c043504420440043800200434043b044f0020044104420432043e04400435043d043d044f00200434043e043a0443043c0435043d044204560432002000410064006f006200650020005000440046002c0020044f043a04560020043d04300439043a04400430044904350020043f045604340445043e0434044f0442044c00200434043b044f0020043204380441043e043a043e044f043a04560441043d043e0433043e0020043f0435044004350434043404400443043a043e0432043e0433043e0020043404400443043a0443002e00200020042104420432043e04400435043d045600200434043e043a0443043c0435043d0442043800200050004400460020043c043e0436043d04300020043204560434043a0440043804420438002004430020004100630072006f006200610074002004420430002000410064006f00620065002000520065006100640065007200200035002e0030002004300431043e0020043f04560437043d04560448043e04570020043204350440044104560457002e> /ENU (Use these settings to create Adobe PDF documents best suited for high-quality prepress printing. Created PDF documents can be opened with Acrobat and Adobe Reader 5.0 and later.) >> /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ << /AsReaderSpreads false /CropImagesToFrames true /ErrorControl /WarnAndContinue /FlattenerIgnoreSpreadOverrides false /IncludeGuidesGrids false /IncludeNonPrinting false /IncludeSlug false /Namespace [ (Adobe) (InDesign) (4.0) ] /OmitPlacedBitmaps false /OmitPlacedEPS false /OmitPlacedPDF false /SimulateOverprint /Legacy >> << /AddBleedMarks false /AddColorBars false /AddCropMarks false /AddPageInfo false /AddRegMarks false /ConvertColors /ConvertToCMYK /DestinationProfileName () /DestinationProfileSelector /DocumentCMYK /Downsample16BitImages true /FlattenerPreset << /PresetSelector /MediumResolution >> /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles false /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /DocumentCMYK /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ] >> setdistillerparams << /HWResolution [2400 2400] /PageSize [612.000 792.000] >> setpagedevice