Increasing the trust between automotive actors using a
Hyperledger Fabric blockchain
ERIK COMSTEDT
KTH ROYAL INSTITUTE OF TECHNOLOGY
SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE
automotive actors using a Hyperledger Fabric
blockchain
ERIK COMSTEDT
Degree programme in Computer Science and Engineering &
Master in Computer Science Date: July 15, 2019
Supervisor: Hamid Reza Faragardi Examiner: Elena Troubitsyna
School of Electrical Engineering and Computer Science Host company: Scania
Swedish title: Förstärkt förtroende mellan fordonsaktörer med hjälp
av en Hyperledger Fabric blockkedja
Abstract
It is a well-established phenomenon that blockchain technology can be ap- plied to reach a consensus between entities which do not trust one another.
Moreover, blockchain technology also allows these trustless entities to reach an agreement on a shared ledger. Through its trustless consensus and shared ledger properties, the blockchain technology can provide trust between trust- less parties. The present-day automotive industry suffers from several trust issues between the involved parties during a vehicle’s life cycle.
In this thesis, it is evaluated whether a blockchain-based solution can be ap- plied to address the trust issues between involved parties in the automotive industry. A proof of concept is implemented using Hyperledger Fabric. In order to evaluate whether the proposed solution can improve trust, in addition to the proposed solution, a centralized database approach is implemented as the baseline which is considered as the traditional solution. A comparison between the two solutions is then carried out. The evaluated aspects in the comparison are security, performance, and usefulness, where security is con- sidered as the most vital aspect.
The experiments show that the blockchain-based solution achieves a higher
degree of both security and usefulness, whereas the baseline solution (i.e., the
database solution) achieves better performance. The overall conclusion of our
experiments implies that the blockchain-based solution is significantly more
trustworthy than the traditional database implementation. The conclusion is
motivated by the fact that the blockchain-based solution is superior in terms
of both security and usefulness.
Sammanfattning
Det är ett välkänt faktum att blockkedjeteknik kan utnyttjas för att komma fram till en överenskommelse mellan medlemmar i ett nätverk som nödvändigtvis inte litar på varandra. Utöver detta faktum, har blockkedjetekniken möjliggjort att förtroendelösa medlemmar kan komma till samtycke om en gemensam in- formationslog. Genom dess förtroendelösa överenskommelseprocess och ge- mensamma informationslogsegenskaper, kan blockkedjetekniken skapa för- troende mellan förtroendelösa medlemmar. I dagens fordonsindustri finns flera förtroenderelaterade problem mellan olika aktörer under ett fordons livscykel.
Den här rapporten utvärderar om en blockkedjebaserad lösning kan applice- ras för att lösa de förtroenderelaterade problem som existerar mellan diverse involverade parter under ett fordons livscykel. En implementation för att på- visa konceptet skapas med hjälp av blockkedjeramverket Hyperledger Fabric.
För att utvärdera om den föreslagna lösningen kan förbättra förtroende skapas även en alternativ lösning baserad kring en centraliserad databas. En jämförel- se mellan de två lösningarna utförs sedan. Då den alternativa lösningen anses vara den traditionella metoden för att lösa problem av denna karaktär, används den alternativa lösningen som en ursprungspunkt för jämförelsen. Jämförel- sen utvärderar aspekterna säkerhet, prestanda och användbarhet, där säkerhet anses vara den viktigaste aspekten.
Jämförelsen visar att den blockkedjebaserade lösningen uppnår en högre grad
av både säkerhet och användbarhet. Medan ursprungslösningen, det vill sä-
ga den databasbaserade lösningen, uppnår bättre prestanda. Slutsatsen av våra
experiment antyder att den blockkedjebaserade lösningen är betydligt mer för-
troendefull än den traditionella databasbaserade lösningen. Slutsatsen motive-
ras av att den blockkedjebaserade lösningen uppnådde bättre resultat gällande
både säkerhet och användbarhet.
Acknowledgements
First, I would like to thank all the people that I had the chance to meet during my thesis project at Scania. In particular my host company supervisor Sussi Miller-Tiedemann and my group manager Katarina Prytz, for their continuous support and assistance throughout this project.
I would also like to thank Megha Gangwal, a master’s student from Stockholm
University that also wrote a blockchain related master thesis at the same de-
partment at Scania as the author of this thesis. Although the theses differ in
terms of research question, methodology, and evaluation method, they have
both evaluated how trust with regard to historical vehicle information may be
increased through Hyperledger Fabric. Therefore, as a significant amount of
discussion has taken place between the authors, it is possible that shared ideas
and opinions could be included in both theses.
1 Introduction 1
1.1 Research objective . . . . 3
1.2 Research question . . . . 3
1.3 Research delimitations . . . . 3
2 Background 5 2.1 Blockchain . . . . 5
2.1.1 Cryptographic hash functions . . . . 5
2.1.2 Hash pointer and hash chain . . . . 6
2.1.3 Merkle tree . . . . 7
2.1.4 Digital signatures . . . . 8
2.1.5 Transactions . . . . 9
2.1.6 Block . . . . 9
2.1.7 Nodes . . . . 10
2.1.8 Creation of new transactions and blocks . . . . 11
2.1.9 Consensus procedures . . . . 12
2.1.10 Smart Contract . . . . 14
2.1.11 Private blockchain . . . . 14
2.2 Hyperledger Fabric . . . . 15
2.2.1 Peers . . . . 15
2.2.2 Ledger . . . . 17
2.2.3 Chaincode . . . . 18
2.2.4 Channel . . . . 18
2.2.5 Organization . . . . 18
2.3 Centralized database . . . . 19
2.4 Security threats . . . . 20
2.4.1 CIA triad . . . . 20
2.4.2 Common Vulnerability Scoring System . . . . 21
2.4.3 Denial of Service attack . . . . 22
vi
2.4.4 Injection attack . . . . 22
2.5 Context . . . . 22
3 Related works 24 4 Methodology 27 4.1 Problem definition and literature review . . . . 28
4.2 Answering the research question . . . . 30
4.2.1 Literature study . . . . 30
4.2.2 Solution design . . . . 30
4.2.3 Implementation . . . . 32
4.2.4 Evaluating results from the implemented solutions . . 35
4.3 Concluding the thesis . . . . 35
5 Gathering results and evaluation 37 5.1 Security evaluation . . . . 37
5.2 Performance evaluation . . . . 38
5.3 Usefulness evaluation . . . . 38
5.4 Answering the research question . . . . 39
6 Evaluation results 40 6.1 Security evaluation . . . . 40
6.1.1 Denial of Service attack . . . . 40
6.1.2 Injection attack . . . . 44
6.2 Performance evaluation . . . . 48
6.2.1 GetHistory . . . . 48
6.2.2 CreateVehicle . . . . 49
6.2.3 Hyperledger Fabric network scalability . . . . 50
6.2.4 Assessment . . . . 51
6.3 Usefulness evaluation . . . . 52
7 Conclusions 54 7.1 Limitations . . . . 56
7.2 Sustainability and societal aspects . . . . 57
7.3 Future work . . . . 58
Bibliography 59
A Design model details 66 A.1 Requests . . . . 66 A.2 Data to store . . . . 68
B CVSS 70
B.1 Metrics . . . . 70
B.2 Scoring . . . . 72
B.3 Metric values . . . . 74
Introduction
This chapter serves as an introduction to the topic of the thesis. Furthermore, the chapter also introduces the research question.
The idea behind the blockchain technology first reached mainstream attention through Satoshi Nakamoto’s Bitcoin research paper from 2008. Within this paper, Nakamoto introduces his underlying thoughts behind what would later become the world’s most successful cryptocurrency [1]. The core principle of the Bitcoin idea was to allow payments to be sent between two different par- ties directly. Through this property, the need for a mutually trusted third party, such as a bank, to act as the middle man could be removed. Due to the success of the Bitcoin cryptocurrency, several other cryptocurrencies would emerge within the years following Nakamoto’s report. Some examples of such cryp- tocurrencies are Litecoin [2] and Dogecoin [3].
However, following the successful launch of bitcoin, researchers began to spec- ulate whether the blockchain technology used within bitcoins transaction sys- tem could be used in other applications as well [4]. Researchers within the field begun to explore and evaluate varying new use cases for the blockchain technology. They concluded that one advantage of the blockchain is that it is possible to utilize it as a decentralized and distributed database. Each peer in such a database structure contains a copy of the blockchain, which gets updated whenever a new block gets appended to the end of the chain. Decentralization, in itself, has been described as possibly being the next major disruptive tech- nology within computing [4]. Several recent studies show that, due to this decentralization property, one can apply the blockchain technology to several different areas, such as data management [5], healthcare [6], and logistics [7].
1
There have been numerous studies that have investigated potential blockchain applications within the automotive industry. Several modern-day vehicles of- fer a plethora of Internet of Things (IoT) based features when purchased or leased. However, these IoT features also introduce several risk factors that have to be considered, varying from location tracking to remote hijacking of a vehicle [8]. Furthermore, with the ongoing development of autonomous vehi- cles, critical security measures and mechanisms have to be in place. Previous research shows that a blockchain approach may be the solution to some of these introduced problems [8][9][10].
In the automotive industry, selling and leasing of previously used vehicles through third-parties is a common practice. In fact, third-party purchases are more frequent than purchases directly from the manufacturer [11]. The buyer is typically interested in information regarding the vehicle during these types of affairs. This information could include things such as mileage and what kind of maintenance services the vehicle has had. Generally, a vehicle’s value increases if it has a low mileage count and an extensive service history [12].
In the present-day automotive industry, this type of service history is typically kept and stored within physical printed logbooks [12]. However, there is no way that the customer can guarantee that the information written in the logs for a given vehicle is valid. Sometimes sellers are attempting to scam purchasers when selling or leasing used vehicles [13]. This fact makes a sell or lease sit- uation of a previously used vehicle a perfect example of a situation where the involved parties do not trust each other. The situation is, therefore, an ideal scenario for blockchain technology to thrive.
A distributed and decentralized ledger system could serve as a step towards achieving trust between involved parties. The system could store historical information regarding all vehicles that are part of the system, and by such re- move the need for physical service logs or vehicle odometers. Furthermore, the system would introduce protection against fraud. The information would be distributed among all vehicles and stored as transaction data in such a system.
Therefore, it would be difficult for a user to tamper and manipulate with pre-
viously stored transaction data. Additionally, the suggested system would be
able to provide information about the vehicle’s history to insurance providers
and similar. The insurance providers that receive this information would be
able to consider it trustworthy and valid due to the blockchain’s properties.
Another benefit of this system would be the ability to track past insurance claims made by the vehicle’s owner.
In recent years, applications of blockchain technology similar to the system presented in the above paragraph have been proposed. One proposal suggests that it might be possible to apply a blockchain type of approach to storing and verifying vehicle service history [14]. Another research project proposes a system for tracking and verifying a vehicle’s odometer reading based on a blockchain [15].
1.1 Research objective
In order to solve the challenges introduced by the previous section, a decen- tralized and blockchain-based system is proposed by this thesis. The system provides a method to store vehicle information in a distributed fashion, acces- sible through either some IoT device or through an application.
The objective can thus be described as investigating and evaluating whether such a system can be implemented. The aim of the system becomes to increase the trust between the system’s users by storing trustworthy vehicle information in a secure and accessible way.
1.2 Research question
In order to evaluate how effective the implemented system is, the system has to be evaluated. The evaluation will be performed through a comparison against an alternative system on three different aspects, namely security, performance, and usefulness.
The research question for the thesis can be formulated as: Can a decentralized system for a vehicle’s history, which stores transactions on a blockchain, in- crease the security, performance, and usefulness compared to other methods?
1.3 Research delimitations
The research question introduced in section 1.2 mentions that the thesis aims to compare a blockchain-based system for vehicle history with other methods.
Within the scope of this thesis, other methods refer to a centralized database
that stores the same information as the blockchain-based system. The central-
ized database chosen is a DynamoDB service. A private blockchain, built on
the Hyperledger Fabric framework was chosen for the blockchain implemen-
tation. The evaluated aspects are security, performance, and usefulness. The
security aspect is limited to an evaluation of two successful attacks on both
implementations, and their respective consequences with regards to confiden-
tiality, integrity, and availability. The performance aspect is limited to eval-
uating the transaction throughput for a read and write operation within both
implementations. Additionally, the scalability of the Hyperledger Fabric net-
work is evaluated during the performance tests. The scalability is evaluated by
measuring the transaction throughput after increasing the number of endors-
ing peers within a given organization. A questionnaire evaluates the useful-
ness aspect. In the questionnaire, the security and performance advantages for
each solution are presented to the questionnaire participants. They are after
that asked to make a judgment on whether they consider the blockchain-based
implementation to be more useful than the database-based implementation.
Background
This chapter presents essential background information, aiming to give the reader knowledge regarding the theoretical background of the thesis. The first section describes the blockchain technology and how the technique works. Fol- lowing the first section is a description of Hyperledger Fabric, the blockchain framework used for the proposed system in this thesis. The third section de- scribes a centralized database, which is used as a benchmark for evaluation in this thesis. The fourth section describes security threats and how they may be analyzed. The chapter concludes with a section that puts all the introduced concepts together and describes each concept in the context of the thesis.
2.1 Blockchain
A high-level description of a blockchain is a database structured as a linked list.
Each element in this linked list is referred to as a block. Several transactions, which is an instruction that modifies the state of the blockchain database, is stored in each block. A blockchain consists of several aspects: sufficient back- ground theory regarding these aspects will be presented in this section.
2.1.1 Cryptographic hash functions
A hash function can be defined as a type of function, which takes some data of any length as input and returns a string that consists of a fixed number of bits. The input data is typically referred to as a message, and the output string is commonly known as a hash [16]. Hash functions are present in many me- chanics within information security, such as digital signatures and password protection [17].
5
There are several properties that a hash function may have. These properties are listed below:
1. Deterministic: Given some input M, the hash function H returns output H(M) = x that is unique for M [16].
2. One-way: Given some input M, it is easy to compute H(M) = x. How- ever, given x it is infeasible to extract M from H(M) = x through other means than brute forcing [18].
3. Collision-free: It is infeasible to find two values for M and M’ such that M 6= M
0and H(M ) = H(M
0)[18].
A hash function must fulfill all three of the previously presented properties to considered useable within cryptography.
In addition to the properties mentioned above, it is generally desirable that a cryptographic hash function possesses a property called the avalanche effect.
This property implies that even the slightest modification (such as flipping a bit) to the input message to the function will result in an output hash that is vastly different from the previous, unmodified, input message [19]. The avalanche effect makes it so that if an attacker knows a message M and its hash H(M) = x, the attacker cannot easily guess the message M’ if they have access to the hash x’, and x and x’ are similar but not identical.
2.1.2 Hash pointer and hash chain
A hash pointer is a pointer that points to both the hash and the storage loca- tion of some data within a system. The hash is computed by using the data as input to some hash function. When using a hash pointer it is not only possible to fetch data, but also to verify that some adversary has not illegally modified the fetched data. Since modification of the data would cause the data’s hash to change. When applying the concept of hash pointers several times in a se- quence, a hash chain is created.
The hash chain can be seen as a one dimensional linked list like structure and
was first proposed in 1981 [20]. In this structure, each entry consists of a hash
pointer as well as some hashed data, where each entry’s hash pointer points to
the previous entry’s data. If the chain is using a collision-free hash function, changing the contents of one entry will render the succeeding entry’s hash pointer invalid. Given this property, it is possible to determine if the contents of the hash chain have been tampered with by some adversary.
Figure 2.1. The figure shows several hash pointers linked together to form a hash chain.
2.1.3 Merkle tree
A Merkle tree [21], also commonly referred to as a hash tree, is a tree-like
data structure. In a Merkle tree, every leaf node contains a hash. The non-leaf
nodes within the tree also contain hashes, which are calculated by computing
the hash of the node’s two children. This means that the number of hashes will
decrease by half when traversing one layer upwards in the tree. Furthermore,
as the root node’s hash value is dependent on all other hash values within the
tree, it can be used as a representation of the entire tree [22].
Figure 2.2. The figure depicts an example of a Merkle tree.
2.1.4 Digital signatures
A digital signature is as the name implies, a type of signature. Similar to a reg- ular, handwritten signature, a digital signature provides a method to verify that a message M was sent by some user U [23]. Furthermore, also similar to real life signatures, only the person that created the message will be able to create a valid signature. The uniqueness property of a signature is achieved through the use of a pair of public and private keys. Given a scenario where Alice wishes to send a message to Bob, she will first generate a key-pair Alice
publicas well as Alice
private. Alice keeps the key Alice
privateto herself and distributes the key Alice
publicto the world. Bob can then obtain a copy of Alice
publicfor ver- ification purposes. Alice then creates a message M and signs the message using her own private key Alice
private.
Alice
signature= sign(M, Alice
private)
Alice then sends both the message M , as well as the signature Alice
signatureto Bob. Once the message arrives at Bob, he can verify that Alice is the author
of the message using Alice
public.
V erif ication = verif y(M, Alice
signature, Alice
public) [23]
2.1.5 Transactions
In the introductory paragraph for this section, we stated that a transaction could be summarized as an instruction that modifies the current state of the chain.
Each instruction is also added as a public entry in the network’s ledger, that is, the blockchain. The type of instructions a transaction may contain varies with the use case for the blockchain. If we, for example, consider the bitcoin blockchain, each transaction contains a payment transaction. If the blockchain is applied for another use case, these transactions might contain other instruc- tions that are not necessarily related to currency transfer. An example of a non-currency related transaction would be changing the ownership of a vehi- cle. The transaction would then be an instruction or statement that indicates that the ownership of a given vehicle should be changed from one person to another. [24]
Figure 2.3. An example of a set of transactions is shown in the figure. Initially, Charlie sends ten coins to Alice and one coin to Bob. In the next step, Alice sends ten coins to Bob.
2.1.6 Block
The contents of a block can be split into two different categories. These cat-
egories are referred to as header and payload, where the payload contains a
set of transactions. A Merkle tree (see section 2.1.3), is typically constructed from the chain of transactions in the payload. From this Merkle tree, a Merkle root can be computed. The Merkle root becomes the hash of the block and will be included in the header. The header also includes additional informa- tion, such as the hash pointer to the previous block and a timestamp of when the block was created [1][25]. Since the Merkle root becomes the hash of the block, it suffices to change one transaction within one block in order to com- pletely change the hash of the block. This property allows for an accessible way to evaluate the block’s integrity and whether a block has been modified or not. It also makes the blockchain very difficult to modify. Since the blocks are stored according to the hash chain structure, modifying the contents of a block would the block’s hash to change. This would, in turn, cause the succeeding block’s hash pointer to become invalid.
Figure 2.4. The figure shows an example of a set of blocks. The left block contains the transactions T 1 − T 4. These transactions form a Merkle tree, and the Merkle root of this set of transactions becomes the hash for this block.
2.1.7 Nodes
A blockchain network consists of several nodes that are ideally peer-to-peer
connected. Transactions between nodes occur directly between the involved
nodes, without a centralized authority. Generally, each node within the net-
work stores a local copy of the entire blockchain. Therefore, one only has to
evaluate a single node within the network in order to determine the state of
the blockchain in all nodes. Furthermore, all nodes are considered equal, and
there is no hierarchy present [24].
While there is no hierarchy within the network, the nodes that are members of the network may have different roles. There are two main roles that a node may take, full blockchain node as well as miner node. Some blockchain im- plementations, such as bitcoin, also apply a lightweight node [26].
Full nodes are the standard nodes, which keep an up to date record of the entire blockchain. These nodes have the property that they can, freely and without obtaining any reference from a third party, verify any given transaction pre- sented to them [24].
Miner nodes are nodes whose main task and purpose are to create new blocks.
The miner nodes typically apply specialized hardware in order to solve the proof-of-work algorithm efficiently. This procedure will be described more in detail in sections 2.1.8 and 2.1.9. Some miner nodes may also be full nodes, but it is not required [24].
Lightweight nodes is a more lightweight version of the traditional full nodes.
The main difference between a lightweight node and a full node is that rather than having all blocks stored locally, the lightweight nodes stores the headers of the blocks [24].
2.1.8 Creation of new transactions and blocks
When a transaction has been completed on a node in the network, the node will proceed to notify other nodes in the network regarding the transaction that just took place. Furthermore, almost every node within the network keeps and maintains a list of temporary transactions. This list is referred to as a transac- tion or memory pool. The contents of a nodes transaction pool are forwarded to its adjacent nodes whenever the contents of the transaction pool get updated [27].
The nodes within a network do not necessarily have to be a complete network;
that is there does not have to exist direct connections between all nodes. There-
fore, it might require several steps for a given node’s transaction list to reach
all nodes in the network. If a node receives information regarding a transac-
tion, which contradicts a transaction that is already stored in the given nodes
transaction pool, the received information with be discarded [27].
A disagreement may arise if two contradicting transactions appear simultane- ously at separate nodes in the network. Both of the nodes will attempt to notify as many other nodes as possible regarding their transaction. The nodes will consider the first valid transaction they receive to be the correct one, which is the cause of disagreement. However, network nodes have to agree on one blockchain state. It is, therefore, up to the miner nodes to decide which trans- action should be included in the next block.
Similar to full nodes, miner nodes will store all incoming transactions in their transaction pool. In addition to this, the miner nodes will also add this infor- mation into something called a candidate block. A candidate block is a fixed size block that the miner will attempt to get accepted into the blockchain. The miner will fill out the required block header fields with the corresponding in- formation. Once the miner has finalized this step, the actual "mining" can take place, which involves finding a solution to a proof-of-work algorithm. The block will only be considered valid if the miner can find a correct solution to the proof-of-work [24].
2.1.9 Consensus procedures
As explained in section 2.1.8, a disagreement might occur between the nodes in the network. Therefore, a consensus procedure is required in order to reach an agreement between the nodes regarding the state of the blockchain. Instead of applying a type of voting system for reaching a consensus, the blockchain reaches a consensus by having all nodes follow an established set of rules for each interaction between each other. Due to this, the consensus becomes a natural side effect of following and applying these rules [24]. There are four processes that, separately, occur on the network. The processes are Indepen- dent transaction verification, Proof-of-work, Independent block verification, and Block assembly.
Independent transaction verification is one of the four properties that the
network applies in order to establish a consensus. In section 2.1.8, it was ex-
plained that when a new transaction takes place, it will be forwarded to all
neighboring nodes. The nodes may then update their corresponding transac-
tion pools with the forwarded transaction before forwarding it further. How-
ever, the nodes also validate the transactions before adding them to their trans-
action pool and forwarding them further. This property will ensure that only
valid and verified transactions are forwarded further across the network [24].
A Proof-of-work is a difficult problem that the miner must solve in order to get their block accepted into the chain. Even though the problem may be hard to solve, it is easy to verify a solution to it. An example of a proof-of-work problem would be given some hash function H, find some input i that returns a hash that begins with a certain number of 0’s. The input to the hash function H consists of the miner’s block’s hash, as well as a nonce. The miner will then get back some output. If the output satisfies the conditions to solve the proof- of-work, the miner saves this nonce value and proceeds to the next step in the block creation process. However, if the output does not satisfy the conditions, then the miner tries a new nonce until a valid result is obtained. In practice, several quadrillion computations are required in order to find a valid solution to the proof-of-work [24].
Algorithm 1 Proof-of-work
1:
procedure proofOfWork(h, t) . The hash for the block, target hash
2:
n ← 1
3:
while true do
4:
r ← H(h + n) . Compute the hash
5:
if r < t then
6:
return t . If the constraints are satisfied
7:
end if
8:
n ← n + 1 . Else, try the next nonce
9:
end while
10:
end procedure
Independent block verification is the third rule out of four. When a miner has created a candidate block, they will send this block to all of its neighbors in the network. The neighbors will verify that the block is indeed a proper block. Verification is performed at each node by processing through a series of checks that validate the block. Some conditions that are evaluated are; the block’s structure, if the block’s timestamp is within a reasonable time frame, and that the answer to the proof-of-work algorithm is correct. If any of these checks fails, the block is considered invalid and will be discarded [24].
Block assembly is the final step of the consensus procedure. In this step,
the node that has verified the correctness of a block will attempt to append the
verified block to the blockchain. The block is typically appended to the branch
of the blockchain that has the most work behind it. The branch with the most work behind it will naturally become the longest chain as well [24].
2.1.10 Smart Contract
A smart contract is a set of instructions, or more precisely executable source code, which may be implemented on top of the blockchain. The smart con- tract is executed on all nodes in the network and contains rules for how parties interact with each other. If the rules are met when the smart contract is noti- fied, the defined transaction is automatically enforced. A smart contract can thus be seen as a method to automate both the execution and verification of transactions [27].
Figure 2.5. An example of a smart contract is shown in the figure. Execution of this contract will change the ownership of the vehicle with ID 1 from Org_A to Org_B.
2.1.11 Private blockchain
This section has thus far described the elements of a general blockchain net-
work. This type of network is publicly open for anyone to join. Furthermore,
the contents of the network’s ledger are visible to anyone in the world. How-
ever, while this is the general case for how a blockchain network is deployed,
there are other types of blockchain network architectures as well. The other
primary type of blockchain network architecture is a private blockchain.
There are several differences between a public blockchain and a private blockchain.
A private blockchain is a private network, which generally is controlled by an organization. Unlike a public network, a private blockchain network is not open. Instead, one or several network administrators within this organization are responsible for adding or removing nodes from the network. A private blockchain network is thus more controlled than a public blockchain network, and can, therefore, apply a more relaxed consensus procedure. For example, in a private blockchain network, one could assign nodes within the network to act as verification nodes. These nodes will be the only transaction- and block verifiers in the network. This change decreases the number of verifications drastically, as now only a specific subset of the network is required to verify transactions. It is, however, required to have a high level of trust in the verifi- cation nodes for this system to be useable in practice [28].
Due to the permissioned and simplified consensus procedure, a private blockchain network can process a higher number of transactions per minute compared to a public blockchain network [28].
2.2 Hyperledger Fabric
Hyperledger [29] is the shared name for several open source projects related to blockchains maintained by the Linux Foundation, aiming to develop and provide open source blockchain-based distributed ledgers. The Hyperledger project contains several frameworks for implementing blockchain networks, such as Fabric, Iroha, and Sawtooth. Fabric has, however, emerged as the most popular choice out of the frameworks that are included in the Hyperledger project [30], and is also the choice of framework for this thesis. Hyperledger Fabric is a private blockchain (see section 2.1.11). This section will introduce and explain the most vital components in Hyperledger Fabric.
2.2.1 Peers
A peer in Hyperledger Fabric is roughly the equivalent of a node (see section
2.1.7) in more traditional implementations of blockchain. Peers are the most
fundamental component of a Hyperledger Fabric network. Both ledgers and
chaincode are present on a peer. Ledgers and chaincode are introduced in
the succeeding sections (2.2.2 and 2.2.3). A peer may hold several different
ledgers and may have several different chaincodes installed on them. A client
application may interact with a peer in order to access the set of ledgers or chaincode that is available on that peer [31].
Figure 2.6. The figure illustrates a high-level view of a peer in Hyperledger Fabric.
There are three types of peers within a Hyperledger Fabric network. These types of peers are Endorsing peers, Ordering service, and Committing peers.
They are all configured a bit differently, and each plays a different role in the Hyperledger Fabric transaction flow.
Endorsing peer: These peers will simulate the result of a transaction (see sec- tion 2.1.5), that is, a chaincode invocation, on their local copy of the ledger.
This simulation will result in a transaction proposal. These peers may also serve as an endorser. In that case, they will receive a transaction proposal ori- enting from some other endorsing peer. They will then simulate performing the transaction, using the same chaincode and transaction parameters as listed in the transaction proposal, on their local copy of the ledger. During the sim- ulation, the endorsing peer also notes down for which version of the key this simulation is valid. A key is an identifier for an object in the ledger, such as an ID, which the transaction issuer wishes to modify. Every time a transaction proposal is performed on a key, that key’s version increases by one. The result of this simulation is called an endorsement response. After the simulation has concluded, the endorsing peer signs the endorsement response using their pri- vate key [31].
Ordering service: This peer will receive an invocation request. An invoca-
tion request is a set of one or many endorsement responses, which has been
generated by endorsing peers. The ordering service will take the incoming invocation request and put it into a candidate block (see section 2.1.8). Once the first invocation request has been put into the block, the committing peer will start a timer. In the traditional blockchain implementation, the size of a block (see section 2.1.6) is defined by some constant. However, that is not the case in Hyperledger Fabric. Instead, the size of a block is dynamic and is determined by the number of valid transactions issued during a set duration of time. The duration of time is, however, a constant that is specified when defin- ing the network. The timer that was started when the first entry was added to the block will count up to this duration constant. Once the counter reaches the duration constant, the ordering service forwards the contents of the block to the committing peers [31].
Committing peer: A committing peer carries out two procedures, validate and commit. The validation process occurs first and consists of four validation tasks, signatures, endorsement responses, chaincode policy, and key version.
Upon receiving the block containing invocation requests from the ordering ser- vice, the committing peer will take the first invocation request in the block and begin the validation process. If an invocation response passes the validation process, it gets marked as a valid transaction. Otherwise, the transaction is marked as invalid. The committing peer repeats this process until all invoca- tion requests in the block have been processed. Once all requests have been processed, the committing peer adds the new block to their ledger before no- tifying other peers about the ledger update. Invalid transactions are retained but are not added to the ledger [31].
2.2.2 Ledger
Ledgers record all transactions that have been generated through the execution of chaincode. A ledger within Hyperledger Fabric consists of two different components, the world state as well as a blockchain. The world state can be seen as a storage unit, which contains a copy of the current state of the ledger for some key k. The advantage of storing information regarding the current state in a separate item is that it allows easy access to the most recent state.
Therefore, the otherwise necessary step of traversal through the entire trans-
action chain can be avoided. The blockchain part of the ledger serves as a
transaction log, which contains a log of all issued transactions on the ledger
[32].
Figure 2.7. The figure shows a high-level view of the ledger in Hyperledger Fabric.
2.2.3 Chaincode
In the previous section, it was explained that the ledger holds information about the current state, as well as the historical values for some key within the net- work. The other component of a peer, the chaincode, allows for modification and updates of those states. It also allows for the creation of new states. In Hyperledger Fabric, chaincode serves as a smart contract (see section 2.2.10), containing a specific set of rules for a transaction. It is the chaincode that is executed when a client wishes to perform a transaction. There is also a possi- bility to define something called a policy for a chaincode. A policy is a type of endorsement requirement for a transaction proposal using this chaincode, which must be fulfilled for the transaction proposal to be considered valid [27].
2.2.4 Channel
A channel allows different peers in a Hyperledger Fabric network to establish private communication between each other. Ledgers are typically shared on a channel level, and all peers that are members of a specific channel each have a copy of the same ledger. Transactions on that ledger will only be visible to peers that have access to that ledger and are members of the channel [31].
2.2.5 Organization
An organization, which may also be referred to as members, is a group of one
or several peers within a Hyperledger Fabric network. A peer has to be part of
an organization. Organizations can vary in size, ranging from a small number of peers for a small organization to a large number of peers for a large-scale global organization. An organization may also contain membership groups, which is a group made up of a subset of members in an organization. For ex- ample, an organization can create multiple membership groups and add them to different channels. [33][34].
Figure 2.8. The figure shows a high-level view of a Hyperledger Fabric net- work. The clients may connect to a peer within a channel, and invoke that peer’s chaincode in order to access the corresponding ledger.
2.3 Centralized database
A centralized database is a database system that is based around a single stor- age location for information, in contrast to a distributed database, where infor- mation is not bound to a specific source. In a distributed database, the infor- mation is spread out across multiple locations. In both cases, the information in the database is accessible from numerous points [35].
One advantage of a centralized database is that it is possible to access all infor-
mation from a single location. This means that when a user performs a query
on the database, the system does not have to check for the specified item in
multiple locations. A disadvantage is that bottlenecks may occur during high in- and outgoing traffic. Centralized databases are also more vulnerable to ac- cidents. Since information is only present in one location, it may be lost in the case of an accident [35].
A database can either be relational or non-relational. Relational databases are the traditional form of databases and are typically presented as a table. The columns of the table typically refer to a specific attribute and the rows refer to the value of a given attribute. The table contains a key column, which must always contain a unique value for each entry. This key-value is used when a user attempts to read or write information from the database [35]. Most rela- tional databases use Structured Query Language (SQL) to read and write data from the database [36].
In a non-relational database, information is not stored in table form. Instead, information is stored and accessed through other means. Some examples of information storage are through documents, key-values, or graphs. In a doc- ument based non-relational database, the information is stored as an object.
Generally, this object is written in BSON or XML format and may contain multiple attributes that describe the object. Unlike relational databases, non- relational databases do not use SQL to access and modify data stored in the database. Non-relational databases are, therefore, commonly referred to as NoSQL databases [36].
2.4 Security threats
2.4.1 CIA triad
When analyzing and discussing security issues and problems, it is a good idea
to establish a type of baseline for evaluating the potential security issues of a
given system. One of the most established baseline evaluation models is the
CIA triad. The CIA triad evaluates a given system’s security based on the
three factors confidentiality, integrity, and availability [37].
Figure 2.9. The figure shows the CIA triad’s three components.
Confidentiality
One could describe confidentiality as a concept that is similar to privacy. In practice, it refers to the act of protecting data within a given system so that unauthorized actors may not view or access it. A loss of confidentiality could, for example, be stolen user credentials, which would allow an attacker unau- thorized access to the system [37].
Integrity
The integrity aspect of the CIA triad refers to preventing data within a given system from being changed or modified through unauthorized or illegal means.
An example could be overwriting or deletion of data from the system. Pre- serving a high degree of integrity becomes crucial when the system handles sensitive data [37].
Availability
The third and last aspect of the CIA triad is availability. Availability refers to is the ability to access the data within a given system when needed. A cause for loss of availability could be one or several faults in the services used within the system to access data. Examples could be anything from operating system problems to network issues [37].
2.4.2 Common Vulnerability Scoring System
The Common vulnerability scoring system (CVSS) [38] is an evaluation pro-
cess that may be used to evaluate how severe a given vulnerability or attack
would be on a given system. The result of the evaluation will produce a dec-
imal number between zero and ten, which serves as a metric to indicate how severe a given vulnerability is. Zero is considered not severe at all, and nine or above is considered critical. Different metrics based around the system and the chosen vulnerability, are being taken into account when calculating the score.
The metrics are categorized into three categories, base, temporal, and environ- mental. The base category is mandatory, and the temporal and environmental categories are optional to use. Only the mandatory base category was applied when calculating the score in this thesis. More information about the different metrics and how the CVSS score is calculated is found in Appendix B.
2.4.3 Denial of Service attack
A denial of service attack is a type of attack in which the attacker attempts to put a system or network into a state where it is no longer available to use for legitimate users. It is generally performed by over-flooding the target system with a large number of requests in an attempt to overload the system. A dis- tributed denial of service attack is a variant of a denial of service attack. The difference between the two is that in a distributed denial of service attack, the incoming traffic to the target system is orienting from many different sources.
In the non-distributed case, traffic is instead coming from a single source. This type of attack is generally a threat to a system’s integrity and availability [39].
2.4.4 Injection attack
An injection attack is a type of attack in which an attacker injects untrusted input into a system that ends up having malicious consequences. The effects of a successful attack may allow the attacker to perform malicious actions, such as commands, queries, write operations, on the vulnerable system. There are several different types of injection attacks, such as code injection, CRLF injec- tion, SQL injection, and NoSQL injection. Since there exist so many different variants of injection attacks, it is only natural that there also exist several dif- ferent outcomes for these variants. Therefore, an injection attack can be seen as a threat to all three aspects of the CIA triad, depending on which variant of an injection attack is being used [37][40].
2.5 Context
This section motivates why each of the proceeding sections is relevant to the
thesis.
Section 2.1 introduces background knowledge regarding the blockchain concept- and technology. It is vital for the reader to develop an understanding of how blockchain technology functions in order to understand the technical aspects of this thesis. Therefore, key concepts such as transactions, blocks, nodes, and consensus procedures, are introduced. Furthermore, as the succeeding section describes Hyperledger Fabric, Smart contracts and private blockchains are also introduced.
In section 2.2, the blockchain framework Hyperledger Fabric is described.
The proof-of-concept solution implemented in this thesis is based on Hyper- ledger Fabric. In order to understand how the technical aspects of the pro- posed system, the reader is required to possess some knowledge regarding both blockchain technology and Hyperledger Fabric. The different components of Hyperledger fabric are referred to later in the thesis. They are, therefore, in- troduced in this section.
Section 2.3 describes a database and its functionality. Given that we use a cen- tralized database as a baseline for comparison in this thesis, general knowledge about such a system is required. The section also describes the differences be- tween a centralized and distributed database, as well as the differences between a relational and a non-relational database.
Finally, section 2.4 introduces the CIA triad and the Common vulnerability
scoring system. Both the CIA triad and CVSS were used as security measures
during the evaluation process of the thesis. The two attacks that were assessed
during the security evaluation are also described in this section.
Related works
This chapter introduces the state-of-the-art, as well as recent works within the field related to the thesis scope.
While the blockchain technology is still at a relatively young age, there has been a fair bit of research within the topic during the last few years. During the earlier years of blockchain technology’s lifetime, most research was car- ried out with regards to the financial sector. However, as mentioned in chapter 1, several other use cases for blockchain technology has emerged during the last few years.
The difficulty required to modify previous blocks within the blockchain makes it a suitable method for storing time-based entries. More precisely, it makes it suitable as a logging method. Huang, Li, and Zhang show that a traditional log system cannot be guaranteed to be secure enough, and that information in such a log system can easily be falsified. They present a blockchain-based logging solution, which improves the security of the logging system in place [41]. A blockchain-based log system has also been proved to have properties that would allow administrators to detect log manipulation easily, further in- creasing the security [42].
There have been several scenarios that have been highlighted by researchers and alike as scenarios in which a blockchain implementation may enhance an already existing IoT-based implementation. Comparisons have been made between IoT systems implemented without and with blockchain technology.
The results have shown that a blockchain implementation for IoT devices can guarantee a higher level of security than an IoT system that does not apply
24
the technique [43]. One suggestion on how such a system could be practically implemented is Flowchain [44]. Flowchain is a distributed ledger approach, that attempts to apply the benefits of the blockchain technology to IoT devices [44]. In the Flowchain research paper, a suggestion for a new type of mining system, tailored for IoT, is presented. The proposed system aims to address the technical challenges introduced when applying blockchain technology for IoT devices. It has also been studied whether it is feasible to use a blockchain- based solution to control and manage IoT devices [45].
Similar to many other industries, the automotive industry has embraced the concept of IoT. The number of connected devices within a single automotive vehicle has increased dramatically over the last few years [46]. However, one drawback of combining IoT devices and vehicles is the security and privacy risk. Charlie Miller and Chris Valasek highlight this in their report Remote Ex- ploitation of an Unaltered Passenger Vehicle [47]. Their report showed that it was possible to compromise the IoT-based entertainment system installed in the vehicle remotely. The compromise allowed them to perform various ac- tions on the vehicle without having physical access to it. Their results show that there are exploitable flaws in vehicular IoT devices and that exploitation of these flaws could have severe consequences [47]. If a vulnerability is located within an IoT device in some vehicle, it is crucial to get the firmware for that device updated as soon as possible. There has been some research regarding whether it is possible to provide firmware updates over the wireless network to vehicles with affected IoT devices [48].
Several papers have investigated the possibilities of improving IoT security through blockchain technology. One report investigates whether a blockchain- based approach may increase the security in communication used by the IoT devices in a smart vehicle [49]. The report also discusses how such a system would serve as a protection to the privacy of the users of the vehicle [49].
Furthermore, the system is also said to increase the security of the vehicular ecosystem [49]. Kim and Singh [10][50] stresses that there exist trust issues regarding the data received and broadcasted within communication channels in smart vehicles. They also argue for how a blockchain proposal, which has been used within Bitcoin to achieve trust [1], can be applied in order to achieve secure and trustworthy communications within smart vehicles [10][50].
Within automotive research and development, researchers have been inspired
by the fact that the blockchain technology can increase security and trust-
worthiness in communications and transactions. Some studies have evaluated whether blockchain technology is suitable as a fraud protection system within the automotive industry. Chanson, Fleisch, Bogner, and Wortmann introduce an Ethereum blockchain-based solution in for providing a trustworthy log of a vehicle’s current and historical odometer rating [15]. They argue for how such an implementation would both increase the trustworthiness of transactions in regards to buying and selling vehicles. Additionally, they mention that traffic security would improve because it would be less likely to see well-worn vehi- cles driving on the streets with such a system in place.
Another example of an even more elaborated solution comes from Brous- miche, Heno, Poulain, Dalmieres, Hamida in their 2018 report Digitizing, Se- curing and Sharing Vehicles Life-cycle Over a Consortium Blockchain: Lessons Learned [14]. The report presents a system for tracking a vehicle’s odometer rating, as well as tracking and verifying a vehicle’s service history. The results show that the system can provide more trustworthy transactions between two peers during the resale of a vehicle.
The last two mentioned works are closely related to the scope of this thesis.
This thesis will attempt to evaluate further whether a blockchain approach is
suited for this type of use case.
Methodology
This chapter presents the research methodology used applied during the the- sis, as well as the methods applied in order to address the formulated research question.
The methodology applied was inspired by [51]. Similarly to [51], the meth- ods involved in the research methodology can be categorized into different methods. The different methods are presented in figure 4.1. The 4th method, answer research question, is the largest out of the five methods and consists of several sub-methods. Throughout this chapter, a number within round paren- theses refers to the number associated with that particular method in figure 4.1.
27
Figure 4.1. The research methodology and methods used to answer the re- search question.
4.1 Problem definition and literature review
The first step in the process was to investigate different aspects of the automo- tive industry in order to evaluate where there exist problems related to trust (1). Since trust can be seen as quite a subjective choice of words, early dur- ing this process, several discussions took place in order to define trust means.
Within the scope of this thesis, trust is broken down into two main categories, security, and performance. Security refers to how well defended the system is against attacks towards the three categories of the CIA triad (see section 2.4.1).
Performance refers to the overall transaction throughput within a system. In
[52], it is stated that upon the performance of a promise, a promisor is con-
sidered to have gained trustworthiness. Given that the end users of the system
expect a certain level of performance, one could consider a system that is not
able to provide sufficient performance to be untrustworthy. In other words, the
user may consider the system less trustworthy than a system that can provide a
higher degree of performance. Since the lower performing system is less likely
to fulfill the promise of matching the end users needs, it could also be seen as
less trustworthy. It was considered more important to achieve a higher de-
gree of security than performance when defining trust. The motivation behind
considering security the most important category was based on discussions
with people with expertise within the automotive industry. Furthermore, it
has been shown that application users consider security, followed by perfor-
mance, as the two most important aspects of a given system [53]. This fact served as additional motivation as to why security should be considered the most important category.
Figure 4.2. The figure shows the definition of trust that was used within the thesis.
Several discussions then took place with people working in the automotive in- dustry, regarding where there currently exist trust related issues. One of the points that came out of these discussions was that there exist trust issues with regards to selling or leasing a previously owned vehicle. More specifically, there exist issues are related to the integrity of the provided information in such situations. Based on the information that came out of these discussions, it was decided that the thesis should investigate if the trust between different actors involved in a sell or lease situation of a previously owned vehicle could be increased through some technique.
Several techniques were evaluated before finally deciding on the blockchain
technology (see section 2.1) as the foundation for the implementation. It was
also decided that this implementation should be used to store information re-
garding a vehicle during its entire life cycle. Furthermore, it was decided that
a comparison against an alternative implementation should take place. The
comparison would serve as an evaluation of the two implementations in terms
of the two aspects of trust. Additionally, it was decided that a smaller scale
usefulness evaluation regarding the blockchain-based implementation would
be carried out. The purpose of the usefulness evaluation was to evaluate if
the proposed system would be considered a useful addition to the automotive industry. Within this thesis, usefulness is defined as a summary of the pros and cons of a given implementation. Based on the pros and cons, a judgment is made on how likely the given implementation is to be developed and used in practice.
A literature study on related works was also conducted (2), which can be read in chapter 3. Furthermore, once the problem definition was finalized, and the blockchain technology had been chosen as a suitable technology, the thesis research question was formulated (3).
4.2 Answering the research question
This section describes the methods applied in order to answer the research question (4).
4.2.1 Literature study
The first step towards answering the research question was a detailed literature study, with the purpose to get insight into the state-of-the-art and sufficient ex- pertise within the related fields (4.1). The fields that were investigated were blockchain technology in general, as well as several blockchain frameworks.
Additionally, methods for evaluating security and performance were studied.
Once sufficient background information had been processed, it was decided that Hyperledger Fabric (see section 2.2) would be used as the framework for the blockchain implementation. The motivation being that Hyperledger Fabric should be able to achieve a high level of performance, due to its relaxed con- sensus procedure. It was also decided that a centralized database (see section 2.3) would be used for comparisons against the blockchain-based implemen- tation. This choice was based on the fact that databases are considered the traditional solution for these types of systems.
4.2.2 Solution design
Once the detailed literature study had concluded, further discussions were held
with developers within the automotive industry. These discussions were to get
an insight from people with expertise regarding objectives and requirements
for the proposed system. Based on the discussions that took place, a number
of requirements were defined for the proposed system.
1. The system should store historical data regarding a vehicle in an acces- sible way. An interface for easily accessing the data, such as an application, should be present.
2. There should exist several roles that may be associated with an account.
The roles requested were vehicle owners, vehicle dealers, insurance company employees, and service station employees.
3. A set of requests for accessing and updating data should be available.
Certain requests should only be available to specific roles.
A design model was created, based on the agreed requirements, which is pre- sented in the figure below.
Figure 4.3. The figure shows an overview of the design model.
The design model contains an application that the user may utilize to interact
with the system. A user identity service is in place, which the user must autho-
rize themselves against before they are allowed to perform any operations on
the system. The data storage point is a Hyperledger Fabric blockchain in the
proposed system. In the alternative solution used for comparison, the data stor-
age is handled by a centralized NoSQL database. A user may query or write
data to the data storage point through a number of HTTPS requests. More in-
formation about the requests, as well as the structure of how the data is stored
in the data storage point, can be found in Appendix A.
4.2.3 Implementation
Based on the design model defined in the previous step, two different solu- tions were implemented (4.3). Both solutions apply the design structure that was presented in figure 4.3, where the only difference between the implemen- tations is the data storage point. Both of the implementations provide the same features, which are listed in the Requests section of Appendix A.
4.2.3.1 Hardware
Both of the solutions were built using the same hardware. The same hardware was also later used for the evaluation procedure, which is introduced in section 4.2.4. The machine used for hosting the end user application had the following specifications.
Processor: Intel Core i7 2.60GHz.
Memory: 16 GB.
Operating System: Windows 10 Enterprise. Version 1803.
The remaining units present in figure 4.3 are implemented in a cloud comput- ing manner and is thus implemented on an AWS Elastic compute cloud (EC2) instance [54]. The instances used has the following specifications:
Processor: 1 vCPU (A hyperthread of an Intel Xeon core).
Memory: 2 GB.
Operating system: Amazon Linux AMI 2018.03.
4.2.3.2 Blockchain-based implementation
The blockchain-based implementation uses a small scale implementation of
a Hyperledger fabric network as a data storage point. The peers (see section
2.2.1) run in separate container environments, to simulate the distributed struc-
ture of a real-life Hyperledger Fabric network. All of the peers have instruc-
tions in the form of chaincode (see section 2.2.3) installed on them. The chain-
code that is present on the peers is written in the Go programming language
and uses fabric-shim [55] for accessing ledgers (see section 2.2.2). The chain-
code allows the nodes to perform, and verify transactions that have been for-
warded to the network. Furthermore, the installed chaincode verifies that the transaction request is coming from an actor that has the necessary priveledges to perform this transaction. Additional checks, for invalid input handling, are also present in the chaincode. One such example is a check that validates that the new odometer reading value in an incoming request is larger than the al- ready existing odometer reading value for the vehicle the request attempts to modify. Algorithm 2 presents the chaincode for updating the odometerRead- ing value for a vehicle. The other chaincode functions are implemented simi- larly to Algorithm 2.
Algorithm 2 putOdometer
1:
procedure putOdometer(accessT oken, vehicleid, odometerReading)
2:
if accessT oken.group 6= Servicestationemployee then
3:
return unauthorized
4:
end if
5:
vehicle ← shim.getState(accessT oken, vehicleid)
6:
if odometerReading > vehicle.odometerReading then
7:
vehicle.odometerReading ← odometerReading
8:
shim.putState(vehicleid, vehicle)
9:
return success
10:
end if
11:
return f ail
12:
