Keywords Blockchain · Data privacy · Information security · Distributed ledger · Hyperledger Sawtooth · Information ecosystem (IES)

Blockchain Technologies Towards Data
Privacy—Hyperledger Sawtooth as Unit
of Analysis

Pascal Moriggl, Petra Maria Asprion, and Bettina Schneider

Abstract For digital business models data is the most crucial asset—this calls
for increased awareness of appropriate privacy protection measures. The Euro-
pean Union General Data Protection Regulation is a consequence that followed the
discussions and now forces organizations to ensure that their information ecosys-
tems comply with the law. There is currently an emerging trend to apply blockchain
technologies to business models that rely on data exchange, because the technology
promises to make a centralized data authority redundant. We have taken this as
the purpose for our efforts to provide insights that will help decision-makers select a
suitable blockchain configuration that complies with data privacy regulatory require-
ments. By applying design science, we created a morphological box along with a
grid, serving as a ‘data privacy assessment tool’ for the blockchain configuration
Hyperledger Sawtooth. The research results can potentially be generalized to assess
any other blockchain configuration.

Keywords Blockchain · Data privacy · Information security · Distributed ledger ·
Hyperledger Sawtooth · Information ecosystem (IES)

1 Introduction

There is a growing interest in the fields of blockchain technologies and data privacy,
which is reflected in an increasing number of publications. We analyzed rele-
vant databases (Scopus, Web of Science, and IEEE Xplore) with the result that

P. Moriggl (B) · P. M. Asprion · B. Schneider
School of , Institute for Information Systems, FHNW University of Applied Sciences and
Arts Northwestern Switzerland, Peter Merian-Strasse 86, 4002 Basel, Switzerland
e-mail: [email protected]

P. M. Asprion
e-mail: [email protected]

B. Schneider
e-mail: [email protected]

© Springer Nature Switzerland AG 2021
R. Dornberger (ed.), New Trends in Information Systems and Technology,
Studies in Systems, Decision and Control 294,
https://doi.org/10.1007/978-3-030-48332-6_20

299

http://crossmark.crossref.org/dialog/?doi=10.1007/978-3-030-48332-6_20&domain=pdf

mailto:[email protected]

mailto:[email protected]

mailto:[email protected]

https://doi.org/10.1007/978-3-030-48332-6_20

300 P. Moriggl et al.

in September 2019 Scopus showed 512 hits, Web of Science resulted in 398 hits and
in IEEE Xplore 54 hits were returned; in comparison, in 2015 the identical keyword
search in Scopus, Web of Science and IEEE Xplore led to only one hit.

Applicable since 2018, the European Union (EU) General Data Protection Regu-
lation (GDPR) is a strong driver for researchers and practitioners to evaluate the
impact of privacy regulations on an information ecosystem (IES) or on business
processes. Over the past decade, blockchain, as an emerging technology with various
configurations (e.g., Bitcoin, Ethereum, and Hyperledger) and with high disruptive
potential, has enabled new opportunities to design and execute business processes;
this is especially relevant for processes that involve a variety of IESs and associated
stakeholders.Althoughtherearesomeresearchactivitiesthatuseblockchainconfigu-
rations to ensure data privacy in IESs [1–3], there is no standardized assessment avail-
able that helps evaluate and compare different possible blockchain configurations for
their suitability regarding data privacy capabilities.

One explanation for this lack of research interest might be the circumstance that
under certain conditions, data privacy issues can be circumvented for blockchain
applications. First, the problem of data privacy can be “outsourced” and therefore
classified as not relevant because personal data could theoretically be encrypted and
pseudonymized outside the blockchain (off-chain); with this approach, personal data
processing risks and data privacy requirements can be by-passed for any blockchain-
based solution. Another way to avoid data privacy issues is to store only hashes or
checksums of the personal data on-chain. In addition, any personal data could be
encrypted in order to hinder other network participants without a valid private key to
seethecontent.However,withregardtoencryptioningeneral, itneedstobediscussed
whether it will withstand future advancements in technologies that potentially could
decrypt its content [4].

Despite these avoidance strategies, the storing and processing of private sensitive
data in blockchain configurations occurs in practice and we consider data privacy
as highly relevant for our society, driving us to advance this unresolved research
issue. Therefore, the goal of this study is to design a conceptual assessment—a
morphological box along with an assessment grid—that allows the comparison of
blockchainconfigurationsbasedontheirdataprivacycapabilities.Themorphological
box and particularly the grid provide a starting point for further discussions and
refinements that could lead to a standardized framework for assessing data privacy in
a blockchain-based IES. Target audiences are both researchers and decision-makers
in organizations that analyze or plan to establish blockchain-based solutions.

This study follows a design-based research approach [5]. First, according to [5]
the existing knowledge around data privacy and blockchain solutions is analyzed,
condensed, and used to scope this research. Second, the design process is outlined,
starting with elaborating blockchain- and privacy-related characteristics to include
in our morphological box. This leads to the foundational artifact, an assessment grid,
evaluated by applying it to a dedicated blockchain configuration. The artifact makes
use of the morphological analysis, a general method for non-quantified modeling [6].
The development of the morphological grid follows privacy audit criteria for IESs
[7, 8] adapted to be used for blockchain-based solutions dealing with private data.

Blockchain Technologies Towards Data Privacy—Hyperledger … 301

Fig. 1 Research domain resulting in a morphological box

Figure 1 shows (1) our research domain synthesis, a “Generic Distributed Ledger”
with its three abstraction layers, related characteristics/attributes (left box) and (2)
the elements from one “Detailed Blockchain Concept” (right box). We selected an
exemplary Hyperledger Sawtooth, and (3) in the center of Fig. 1, the specific elements
that are relevant to design our desired artifact—the morphological box (the triad
and related arrows). The characters marked in grey in the left box set the artifact
boundaries, whereas the ones marked in grey in the right box set its content.

The remainder of this contribution is structured as follows. The foundations of
our research—data privacy and blockchain—are elaborated in Sect. 2. In Sect. 3,
we discuss the characteristics forming the morphological box; as baseline, we use
blockchain and data privacy characteristics to discuss relevant attributes. These
include the application of the morphological box to highlight how Hyperledger
Sawtooth fulfills data privacy requirements at the technical level. The contribution
concludes in Sect. 4 with a short summary of the practicability and further research
opportunities in the field of technical data privacy characteristics.

2 Foundation

Thefoundationsectioncoversdataprivacyandblockchainascentralunitsofanalysis.
It elaborates firstly the concept of data privacy and highlights its increasing relevance
in digitalized IESs. Secondly, relevant essentials of blockchain will be introduced
that allow demarcating the boundaries of this research.

302 P. Moriggl et al.

2.1 Data Privacy

Historically, in the EU, privacy is regarded as a fundamental individual right and
a social value; it can be described as “the right to private life, to be autonomous,
in control of information about yourself, to be let alone” [9]. In an increasingly
digitalized world, it has become common that plenty of data about individuals are
created and processed electronically [10]. Therefore, privacy must be considered and
established with particular care. According to a study by the Swiss Federal Office
for , 87% of EU residents living in the most advanced countries in terms of
digitization provide personal data of various kinds via the Internet [11, 12]. Serious
data breaches—such as the scandal of Cambridge Analytica, a British company,
which had harvested data from up to 87 million Facebook users without their explicit
consent [13]—have revealed the importance of monitoring the processing of personal
data. The EU had anticipated this requirement and responded with GDPR, which
became applicable on 25 May 2018. This regulation, aiming towards protecting
natural persons and their data (GDPR, Article 1), unfolds extraterritorial effects;
it refers to any data processing related to individuals who are in an EU member
state—irrespective whether or not the data processing itself takes place in the EU
[14]. Consequently, this means every organization, across all industries and locations,
except non-EU countries without EU trade relationships, must verify whether it is
affected and is required to comply with GDPR [9]. As a very special case, non-EU
organizations, such as higher education institutions must also consider GDPR [15].
As the new regulation not only replaces but also updates the preceding EU Data
Protection Act (DPA) from 1998, several new elements have been introduced. An
example is the mandatory data protection impact assessment, “a process to manage
risks related to the processing of personal data by assessing and mitigating such
information” [16].

In addition, the GDPR leads to a close link between data protection and informa-
tion security. GDPR Article 32 explicitly obliges organizations to process personal
data securely using “appropriate technical and organizational measures”, such as
encryption and pseudonymization. The Information Commissioner’s Office (ICO),
a regulatory body used to protect information rights in the public interest, confirms
that concepts originally stemm from the field of information security [17], e.g. from
the CIA triad [18]—a widely used model for managing information security policies.
The abbreviation CIA comes from the attributes (1) Confidentiality as a set of rules
that limits access to information, (2) Integrity as the assurance that the information
is trustworthy and accurate, and (3) Availability as a guarantee of reliable access to
the information by authorized people [17].

The three attributes of the CIA triad are essential information security character-
istics and delineate the boundaries in which our research operates. The attributes of
the CIA triad will be referred to when building and testing the research results.

Blockchain Technologies Towards Data Privacy—Hyperledger … 303

2.2 Blockchain

The term blockchain first appeared in 2008 after Satoshi Nakamoto, a pseudonymous
person or group, published an essay about a peer-to-peer electronic cash system
using the terms blocks and chain [19]. Nowadays, blockchain is understood as a
concept with the umbrella term distributed ledger. According to Burkhardt et al.
[20], a distributed ledger can be defined by complementary principles, which focus
on mathematical and information technology-related aspects, such as cryptography,
stochastics, graph theory, and network structures. The principles themselves focus on
economic aspects: ‘crypto-economics’ exploiting the game theory [21, 22] and strate-
gies to build consensus in untrusted environments and issues of a ‘digital economy’,
e.g. double-spending digital money or dealing with cryptocurrencies [23].

The distributed ledger principles can be assembled in particular ways forming
three distinctive distributed ledger services (DLS) [24]: (1) tangle, (2) hashgraph,
and (3) blockchain. The three concepts differ in their architecture, where tangle and
hashgraph are based on a ‘directed acyclic graph’, and blockchain is based on its own
‘blockchain’-technology [20]. The latter became widely known among the public and
in the scientific community when in 2009 the first cryptocurrency whitepaper titled
as Bitcoin was released [19, 25]. Today, many implementations of the blockchain
concept are actively developed by researchers or leading commercial players (e.g.,
IBM, Intel, Ethereum Foundation).

For this study, Hyperledger is chosen as an analytical unit to test the applica-
bility of the developed assessment instrument, the morphological box. Hyperledger
is considered the most appropriate because it is an open-source collaborative effort
designed to advance cross-industry blockchain technologies. The underlying design
philosophy of Hyperledger fits perfectly with this research as it aims to keep ledgers
distributed and make smart contracts safe, in particular for enterprise applications. Its
distinctive architecture separates the core system from the application domain, which
aims on the one hand to simplify blockchain application development and on the other
hand allows developers to choose their preferred programming language [26]. Hyper-
ledger is based on a global collaboration including leaders of different industries. The
Linux Foundation, known as a worldwide acting non-profit technology consortium,
is hosting it [26]. The selected configuration for this study, Hyperledger Sawtooth, in
the following abbreviated as Sawtooth is a project under the Hyperledger umbrella.
It is a modular platform for creating, deploying, and running distributed ledgers [26].
For our desired artifact, an assessment tool in the form of a morphological box, the
fundamentals of blockchain set the boundaries. Table 1 consolidates the distributed
ledger characteristics, namely the principles, the DLS and the configuration along
withrespectivevalues(alphabeticallyordered).Wehighlightedthevaluesdelineating
the scope (italics formatting)—general distributed ledger characteristics, focusing on
blockchain such as DLS and Sawtooth as the exemplary unit of analysis.

304 P. Moriggl et al.

Table 1 Generic distributed ledger characteristics setting the scope of this study

Characteristics Values

Principle Cryptography Digital
Economy

Game
theory

Graph theory Networks Stochastic

Service Tangle Hashgraph Blockchain

Configuration Bitcoin Ethereum IOTA Hyperledger
Sawtooth

Ripple …

3 The Morphological Box

In the previous section, we introduced the basics of data privacy, information secu-
rity, and blockchain to demonstrate research boundaries. This section elaborates the
building blocks for the morphological box drawing on existing research work. It
starts with the blockchain-related characteristics followed by data privacy character-
istics. Currently, there is no conclusive research on blockchain configurations that
best correspond to data privacy requirements because of the difficulty of matching
technical features with data privacy requirements that do not necessarily dictate
configuration choices.

3.1 Blockchain Characteristics

Two relevant characteristics, the “Blockchain Design Elements” and the “Blockchain
Type” will be incorporated into the assessment tool. Table 2 shows both character-
istics and related values; values that apply to our unit of analysis, Sawtooth, are
highlighted (italics formatting).

3.1.1 Blockchain Types

When selecting the blockchain-related characteristics to build the morphological
box, we first draw on one of the blockchain principles described in Sect. 2.2,

Table 2 Blockchain-related characteristics of the morphological box

Characteristics Values

Blockchain design
elements

Charging and
rewarding

Consensus Identity
management

Tokenization

Codebase Extensibility Security/Privacy Transaction
capabilities

Blockchain type Consortium Private
permissioned

Public
permissioned

Public
permissionless

Blockchain Technologies Towards Data Privacy—Hyperledger … 305

namely the network structure principle that focuses on different participation modes;
this principle is used to classify a distributed ledger based on its centralization
degree and participation mode. The network principle differentiates between three
degrees: centralized, decentralized, or distributed, and two participation modes:
permissioned, or permissionless [27].

Blockchain as a concept aims to achieve a decentralized consensus on valid ledger
entries among untrusted participants. The blockchain concepts are compelling and
can be differentiated in two classes of blockchain types that are either “open or
closed”, as visualized in Table 3 where example configurations are outlined that are
currently used in several applications of the concept of blockchain. When it comes
to our unit of analysis, Sawtooth, it is considered an enterprise blockchain platform
and allows inherently to deploy different blockchain types, but for this project the
base is consortium.

AccordingtoBurkhardt et al. [20], ablockchainis composedof sixbuildingblocks
(1) transactions, (2) roles, (3) blocks, (4) verification and validation processes, (5)
algorithms, and (6) cryptography. In general, transactions (1) are transparent and
visible to each participant, depending on the two complementary blockchain types
(Table 3). Participants in a blockchain-based network have an identical copy of the
current ledger [20], depending on the permission settings and the blockchain design.

Blockchain participants have roles (2) with associated tasks to interact with each
other and find consensus. These roles work together and build a network that provides
an unalterable history of data exchange in form of transactions between the partici-
pants, whereas all transactions are stored in blocks. Roles, for example, are “smart
contracts”, “endorsers”, “committers”, “validators”, and “orderers” [29]. Blocks (3)
are cryptographically concatenated and always chained to the previous block. All

Table 3 Competing blockchain types [28]

Read Write Commit Examples

Blockchain
type

Open Public
permissionless

Open to
everyone

Everyone Everyone Ethereum,
Ethereum
classic

Public
permissioned

Open to
everyone

Authorised
participants

All or subset
of authorized
participants

Sovrin

closed Consortium Restricted to
an
authorised
set of
participants

Authorised
participants

All or subset
of authorized
participants

Multiple
banks
operating a
shared
ledger

Private
permissioned

Fully private
or restricted
to a limited
authorised
set of
participants

Network
operator
only

Network
operator only

Internal
bank ledger
shared
between
parent
companies

306 P. Moriggl et al.

blocks together form the blockchain (ledger) and depict a single point of truth to all
nodes that have access to it. In this context, a node can be either a full node or a light
node that participants use to access the network. A full node downloads and stores
the whole blockchain and is designed to verify and validate (4) transactions back to
the very first block (“genesis block”), whereas light nodes only download the block
header of the previous block. Light nodes rely on full nodes for operations requiring
the complete blockchain, thus, the data storage is less consuming/expensive for the
participant of light nodes [29]. Blockchain participants have an identical copy of
the current ledger [20], depending on permission settings and technical design,. The
participants agree on the current ledger state by relying on a (consensus) algorithm
(5), and today many different algorithms exist [30]. The encryption (6) as the last
building block additionally increases the difficulty for attempts that want to alter the
ledger state history and thus assures a high degree of immutability [31].

3.1.2 Core Design Elements

Tasca and Tessone [32] developed a taxonomy for blockchain which can be used as
a blockchain reference standard. The reference standard covers, among other things,
the smallest required technical elements that are part of a blockchain configuration;
they allow to differentiate the configurations at a technical level, which reflects the
different purposes they target. The taxonomy provides a clear structure to catego-
rize the relationships of the inherent blocks and is a sufficient tool, when applied
rigorously, to compare different, heterogeneous configurations [21].

The taxonomy encompasses the identification, description, nomenclature, and
hierarchical classification of blockchain components. In addition, it groups them in
a hierarchical structure that highlights functional relations and design patterns. The
taxonomy focuses on generic blockchain design choices and consists of eight core
design elements:

(1) Consensus: The consensus describes the validation and verification process that
leads to mutual trust among participants in a blockchain network. The consensus
directly affects the reliability, authenticity, and accuracy of the stored data
within the blockchain [30]. The consensus algorithms are different regarding
immutability and failure tolerance, latency, and finality and relate “to the set of
rules and mechanics that allows for the maintenance and updating of the ledger
and guarantees the trustworthiness of the records in it.” [32].

(2) Transaction Capabilities: Transaction capabilities determine transaction scala-
bility and transaction usability. In this context, a transaction initiates a ledger
state change. Transaction scalability relates to quantitative measures such as
transactions per second (TPS) that allow a performance comparison between a
blockchain and other solutions (e.g., MasterCard Payment Gateway) that serve
similar functionality, while transaction usability relates to the degree, to which
the transactions are suitable to be used in IESs [32].

Blockchain Technologies Towards Data Privacy—Hyperledger … 307

(3) Native Currency/Tokenization: The ‘digital economy’ (value in Table 1)
includes the so-called cryptonomics empowered through tokens. The Swiss
Financial Market Supervisory Authority (FINMA) classifies tokens as
blockchain-based units that can be categorized as either (1) payment tokens, (2)
utility tokens, or (3) asset tokens. The first, payment tokens, are native curren-
cies such as Bitcoin—they have no other functions aside from the currency.
The second, utility tokens, provide digital access to services or applications; the
third, asset tokens, represent ownership of an underlying asset, which can be
both physical or digital [33].

(4) Extensibility: Extensibility is the degree to which a blockchain network can be
extended to interact with elements outside the network. Extensibility stands for
interoperability, intraoperability, governance, and scripting language compo-
nents as part of a blockchain. As an example, the governance can be performed
through an open-source community (e.g. Hyperledger), through a technical
solution provider (e.g. Microsoft), or through an alliance (e.g. R3) [32].

(5) Security and Privacy: Security and privacy design differentiate between data
encryption and data privacy settings. Data encryption stands for the encryption
algorithms that are used in a blockchain to ensure (1) integrity, (2) authenticity
and (3) the correct order of events. (1) and (2) can be aligned with two of the
attributes from the CIA triad—integrity and confidentiality [32]. Data privacy
can either be an integral part of the blockchain network (‘by design’) or an
add-on relying on external solutions [32].

(6) Codebase: The coding language, code licensing, and software architecture
define the codebase. The latter can be described as a collection of source code
used to build a system, application, or one of its components. A blockchain
supports either single or multiple languages, open-source or closed-source
license and either a monolithic or a polythic software architecture design [32].

(7) Identity Management: The blockchain identity management builds on three
layers: (1) identity, (2) access, and (3) control. (1) and (2) can be aligned with
the attributes confidentiality and integrity from the CIA triad [32]. The access
and control layer refers to the blockchain type (Table 3) [32].

(8) Charging and Rewarding System: A blockchain depends on computing power
using hardware and electricity. A cost model that organizes resources and
rewards contributors is essential for a blockchain to ensure the ongoing service
and the availability—the third CIA triad attribute [32]. The incentives that root
in the charging and reward system do not apply to all blockchain architec-
tures, because such modalities could also be defined outside the blockchain
system. A simple solution would be a consortium with participating members
that contribute to the same amount of resources (e.g. a full node).

The eight core design characteristics and their outlined specifics are an excellent
theory-based foundation to map and compare complementary blockchain configura-
tions. However, the taxonomy does not provide guidance for comparison and, finally,
the selection of a specific blockchain configuration based on dedicated requirements,
such as data privacy to comply with a specific law such as GDPR. Consequently,

308 P. Moriggl et al.

Table 4 Data privacy-related characteristics of the morphological box

Characteristic Values

Data operation Store Transfer Use

Permissions, policies
and roles

Least privilege Logical access Segregation of duties

Encryption Data encryption

Security mechanism Monitoring and logging Third-party controls Transparent changes

we claim that it is necessary to add guiding factors that explicitly target the privacy
design attributes. This will lead to a more detailed taxonomy and a prioritization
scheme.

3.2 Data Privacy Characteristics

Four technically relevant audit characteristics, “Data Operation”, “Permissions, Poli-
cies, Roles”, “Encryption” and “Security Mechanism” will be incorporated to enrich
our morphological box. Similar to the previous section, these characteristics draw
on existing contributions and will be explained in more detail in the following
paragraphs. Table 4 summarizes the data privacy-related characteristics.

As a specific contribution to closing the derived research gap, we united the data
privacy-related characteristics of the morphological box into a novel assessment
matrix—we call it ‘morphological grid’ (Fig. 2). Instead of highlighting values in
Table 4, this time the newly developed morphological grid will be applied to our
Sawtooth analyses unit. The parameters are based on audit guidelines.

Fig. 2 Morphological grid for assessing blockchain-privacy applied to Sawtooth

Blockchain Technologies Towards Data Privacy—Hyperledger … 309

An audit is a sufficient procedure to review relevant activities in an organi-
zation that affects the IES and thus data privacy [34]. The IES and the related
information life cycle ranges from data creation/collection to deletion and can be
assessed regarding its data privacy maturity [35]. To conduct a data privacy audit, an
audit framework/standard should be used that enables organizations to assess their
IES in a structured and recommended way. The results should reflect an organi-
zation´s ability to comply with given privacy requirements. Some leading audit-
related institutions work on common privacy assessment standards that include
specific guidelines to audit IESs [34]. For example, the International Standard Orga-
nization (ISO) provides the “ISO 29100:2011 Information technology—Security
techniques—Privacy framework” [36], which includes essential elements of a data
privacy audit [37]. To apply ISO 29100:2011 for the assessment of blockchain-based
IESs, the standard needs to be adopted since it covers business logics, e.g., legal
requirements related to the business case and not to the enabling IES, and because it
handles data operations that are usually not part of blockchain configurations but of
‘classical’ (relational) databases. The ISO 29100:2011 provides privacy safeguarding
controls, which are techniques or practices that can be aligned with data operations
within IESs. The related controls are broadly categorized into (1) permissioning,
(2) policies and roles, (3) encryption, and (4) overall security mechanism, and are
adopted from an exemplary data privacy controls audit [38].

In order to judge the privacy capabilities of a blockchain configuration, the rele-
vant data privacy characteristics must first be established. When technical data
privacy attributes are defined, a blockchain configuration’s privacy capabilities can
be assessed by analyzing which defined privacy attributes it fulfills. The configura-
tion has these attributes that are built in either by default or as needed, or they do not
existent and cannot be implemented with this configuration.

Forourstudy,webuildontwoexistingworks:Firstly,thedataoperations[39]from
ISO 29100:2011 and secondly, detailed privacy safeguarding controls for a privacy
control audit based on [38]. Other ISO 29100:2011 privacy framework elements were
not considered because they are directly relevant for technical features and therefore
ignored.

The developed morphological grid to assess blockchain configurations is shown in
Fig. 2, …