Content uploaded by Hugo Martins
Author content
All content in this area was uploaded by Hugo Martins on Sep 02, 2020
Content may be subject to copyright.
Exploring Permissioned Blockchains for Decentralizing
Access Control
Application to an Educational Certificates Use Case
Hugo Figueiredo Caramelo Santos Martins
Thesis to obtain the Master of Science Degree in
Information and Enterprise Systems
Supervisor: Sérgio Luís Proença Duarte Guerreiro
Examination Committee
Chairperson: Miguel Leitão Bignolas Mira da Silva
Supervisor: Sérgio Luís Proença Duarte Guerreiro
Member of the Committee: Miguel Nuno Dias Alves Pupo Correia
October 2018
Acknowledgments
I am grateful to Prof. S ´
ergio Guerreiro, my supervisor, for his guidance, patient and support, through
the course of this thesis. I am grateful to Filipe Apolin´
ario, Jo˜
ao Pereira and Andreia Silva for fruitful
discussions that kept me motivated and focused on doing more and better. I am grateful to Andrew
Rundle and Nick Humphries, for allowing me the much-needed flexibility to complete this thesis. I am
grateful to my parents, for the help and discussions provided during this thesis, for the opportunities and
upbringing they provided me with, that enabled this achievement. I am grateful to Mariana Sequeira
for her support, patience and essentially not allowing me to give up. This thesis would not have been
completed without her.
i
ii
Resumo
Proteger informac¸ ˜
oes confidenciais ou privadas ´
e de extrema import ˆ
ancia. Perdas de informac¸ ˜
ao e
partilha de informac¸ ˜
ao confidencial podem ter impactos legais, de reputac¸ ˜
ao e financeiros s´
erios, para
indiv´
ıduos e organizac¸ ˜
oes. Ao mesmo tempo, o nosso panorama tecnol´
ogico ´
e cada vez mais complexo
e distribu´
ıdo, sendo cada vez mais dif´
ıcil proteger o acesso `
a informac¸ ˜
ao. Uma demonstrac¸ ˜
ao particular
dessa situac¸ ˜
ao pode ser encontrada em instituic¸ ˜
oes que fornecem certificados de qualificac¸ ˜
oes, como
as Universidades, que, ao longo do tempo, t ˆ
em vindo a aumentar esforc¸os, para desativar produtores de
certificados falsos, existentes online. As Universidades trabalham num ambiente onde a validac¸ ˜
ao de
credenciais ´
e essencial, mas esporadicamente acontece e, quando ocorre, s˜
ao necess´
arias interacc¸ ˜
oes
entre v´
arias partes. Existe, por isso, uma lacuna, entre as necessidades de ambientes tecnol ´
ogicos
modernos, distribu´
ıdos e complexos, no que diz respeito ao controlo do acesso `
a informac¸ ˜
ao, e o n´
ıvel
ao qual as soluc¸ ˜
oes cl´
assicas de controlo de acesso podem atender a essas necessidades. Esta tese
explora a utilizac¸ ˜
ao de blockchains privadas, como ve´
ıculos tecnol´
ogicos para a descentralizac¸ ˜
ao do
controlo de acessos, aplicado neste caso de uso espec´
ıfico. Esta tese prop˜
oe Blocked, um sistema
que permite o controlo de acesso descentralizado, atrav´
es de uma blockchain privada, para emiss˜
ao,
partilha e gest ˜
ao de certificados educacionais. Uma avaliac¸ ˜
ao deste sistema demonstra que o mesmo
pode ser considerado um sistema de controlo de acessos adequado e funcional, com melhorias sobre
as soluc¸ ˜
oes descentralizadas existentes para o mesmo problema.
Palavras-Chave: Controlo de Acessos, Seguranc¸a, Privacidade, Blockchain, Sistemas Descentraliza-
dos
iii
iv
Abstract
Protecting sensitive or private information is of the utmost importance. Information breaches, and shar-
ing of sensitive information can have serious legal, reputation and financial impacts for individuals and
organizations. At the same time, our technological landscape is getting more and more complex and dis-
tributed, being increasingly hard to protect information. A particular demonstration of this situation can
be found in institutions providing certificates of accomplishment, such as Universities, who have been
increasing efforts to shut down fake certificate generators online, while working in an environment where
validation of credentials is essential, yet, done sporadically and requiring interactions between several
parties. This situation exposes a gap between the needs of modern, complex distributed environments,
in regards to control of access to information, and the level to which classic access control solutions
can fulfill those needs. This thesis explores permissioned blockchains as technological vehicles for de-
centralizing access control, applied to this specific use case. This thesis proposes Blocked, a system
that allows decentralized access control, through a permissioned blockchain, for issuing, sharing and
managing educational certificates. An evaluation of this system demonstrates that it can be considered
a suitable access control system, with improvements over the existing decentralized solutions for the
same problem.
Keywords: Access Control, Security, Privacy, Blockchain, Decentralized Systems
v
vi
Contents
List of Tables ix
List of Figures xi
List of Listings xiii
Glossary xv
1 Introduction 1
1.1 Motivation............................................. 1
1.2 ProblemStatement........................................ 4
1.3 Contributions ........................................... 4
1.4 DocumentOutline ........................................ 4
2 Related Work 7
2.1 AccessControl .......................................... 7
2.2 Blockchain ............................................ 13
2.3 EducationalCertificates ..................................... 16
3 Methodology 19
4 Assessing User’s Perceptions of Blockchain 23
4.1 StudyDesign ........................................... 24
4.2 Results .............................................. 27
5 Design and Architecture 35
5.1 Stakeholders ........................................... 35
5.2 Overview ............................................. 36
5.3 TechnologicalArchitecture.................................... 36
5.4 FunctionalArchitecture ..................................... 39
6 Implementation 43
6.1 SelectedTechnologies...................................... 43
6.2 Implementation.......................................... 44
vii
6.3 Proof-of-Concept......................................... 47
7 Evaluation 53
7.1 Discussion of Blocked ...................................... 53
7.2 StudyTakeaways......................................... 55
7.3 AccessControlEvaluation.................................... 56
7.4 ResearchLimitations....................................... 60
8 Conclusions 63
8.1 Contributions ........................................... 64
8.2 FutureResearch ......................................... 64
Bibliography 67
viii
List of Tables
4.1 IndustryFrequency........................................ 28
4.2 RoleFrequency.......................................... 28
4.3 Reported Knowledge Using the Scale 0 (Lowest) to 4 (Highest) . . . . . . . . . . . . . . . 28
4.4 Most Secure Scenario (Total Amount of Responses) . . . . . . . . . . . . . . . . . . . . . 29
4.5 Perceived Security / Scenario Using the Scale 0 (Lowest) to 4 (Highest) . . . . . . . . . . 29
4.6 Perceived Interaction Security / Scenario Using the Scale 0 (Lowest) to 4 (Highest) . . . . 30
4.7 Perceived Complexity / Scenario Using the Scale 0 (Lowest) to 4 (Highest) . . . . . . . . 31
5.1 StateProperties ......................................... 38
7.1 Quality Metrics for Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
ix
x
List of Figures
4.1 Interactions presented to Respondents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Probability Density of Perceived Interaction Security (Version 1) . . . . . . . . . . . . . . . 30
4.3 Probability Density of Perceived Interaction Security (Version 2) . . . . . . . . . . . . . . . 31
4.4 Probability Density of Perceived Interaction Complexity (Version 1) . . . . . . . . . . . . . 32
4.5 Probability Density of Perceived Interaction Complexity (Version 2) . . . . . . . . . . . . . 33
6.1 StatusofTransaction#1. .................................... 48
6.2 StatusofTransaction#2. .................................... 49
6.3 StatusofTransaction#3. .................................... 51
6.4 StatusofTransaction#4. .................................... 52
xi
xii
List of Listings
1 Results of Executing cert-issuer................................ 48
2 Results of Executing cert-viewer #1. ............................. 48
3 Results of Granting Access with access-manager. ...................... 49
4 Results of Executing cert-viewer #2. ............................. 50
5 Results of Revoking Access with access-manager....................... 50
6 Results of Executing cert-viewer #2. ............................. 51
7 Results of Executing cert-revoker. .............................. 51
8 Results of Executing cert-viewer #3. ............................. 52
xiii
xiv
Glossary
ABAC Attribute-Based Access Control. 2, 10–12, 15, 54
AC Access Control. 2, 7, 8, 58, 59
ACL Access Control Lists. 9, 54
ACMSAC’19 The 34th ACM/SIGAPP Symposium On Applied Computing. 22
BPMN Business Process Model and Notation. 25, 26, 28, 29
BS Behavioral Science. 19
CAC Cryptographic Access Control. 11, 12
CP-ABE Cyphertext-Policy Attribute-Based Encryption. 12
DAC Discretionary Access Control. 2, 8–11
DS Design Science. 19, 20
DSA Digital Signature Algorithm. 40
DSR Design Science Research. 19, 20
DSRM Design Science Research Methodology. 20, 22, 35, 63
ERBAC Enterprise Role-based Access Control. 10
GEO-RBAC Spatially Aware Role-based Access Control. 10
GRBAC Generalized Role-based Access Control. 10
GUI Graphical User Interface. 16, 60, 65
HICSS-52 The 52nd Hawaii International Conference on System Sciences. 4
HRU Harrison-Ruzzo-Ullman. 9
IoT Internet of Things. 2, 3, 10, 13
xv
IS Information Systems. 19, 20
KP-ABE Key-Policy Attribute-Based Encryption. 12
LRBAC Location-aware Role-based Access Control. 10
MAC Mandatory Access Control. 2, 8–11
MITM man-in-the-middle attack. 39
PKI Public Key Infrastructure. 63
PoET Proof of Elapsed Time. 14, 37, 43, 47, 61, 64
PoS Proof-of-Stake. 14
PoW Proof-of-Work. 14
RBAC Role-Based Access Control. 2, 9–13
SDK Software Development Kit. 43
SoD Separation of Duty. 59
TMAC Team-based Access Control. 10
TRBAC Temporal Role-based Access Control. 10
UUID Universally Unique Identifier. 38
xvi
Chapter 1
Introduction
1.1 Motivation
Our society is built on centralized institutions and systems, which act as authorities of governance,
such as banks and governments. We share our personal information on a daily basis, either voluntarily
by sharing it with trusted entities, such as banks and governments, or involuntarily, by making use of
applications, or visiting websites, that collect our personal information [1]–[3]. These institutions that form
the webs of trust have sadly failed short of their responsibilities, on numerous occasions [4]–[6]. Three
interesting challenges emerge from this situation: (i) are individuals, on their own, or as a collective,
capable of enhancing their own privacy, through the use of technology (ii) are there enhanced ways of
sharing personal information, in a private and secure fashion, and (iii) could breaking this centralization
(e.g., decentralization) be a solution for improving the current status quo? These are vast problems that
are attacking diverse areas of our society.
At the same time, the quantity of information humans have to process on a daily basis is enormous
[7], [8]. There is also a perception that the amount of information stored is increasing very rapidly. This
situation has created an environment in which it is becoming increasingly difficult for people to validate
whether a piece of information is truthful or a falsehood. An example of this, exposed through media
outlets, is the ”misinformation war” going on, at the moment, throughout social media platforms. It is
also a topic of interest for researchers who have gone through lengths to study the problem of how news
spread online [9]. To provide another example, institutions that provide certifications of accomplishment,
such as Universities, are also starting to become affected by this epidemic spreading of falsehoods [10].
There’s an increasing effort to shut down fake certificate websites [11] such as RealisticDiplomas [12]
or DiplomaCompany [13], among others, going as far as faking PhD credentials [14]. This example
comes from a completely different perspective than the previous examples - alleged fake news - but
shares some of the same consequences: (i) it affects the credibility of trusted institutions, (ii) it impacts
the outcome of particular situations due to a falsehood and (iii) it can have serious legal and financial
impacts for society.
To add insult to injury, as well as complexity to this ecosystem, the information created is being
1
offloaded, ever more rapidly, to third-party systems and entities, in the form of cloud storage, which
requires users to manage access to it more thoroughly. Users are also getting more perceptive about
the importance of being able to control access. One of the reasons, apart from privacy, for messaging
applications to have embedded end-to-end encryption on their systems [15], is that it prevents third-
parties from being able to read the information. It is a feature, while at the same time, being a security
enhancement for the providers and consumers of the service. This means that sensitive data cannot be
read by a third party but, perhaps most importantly, that only the sender and recipient of a message can
read its contents. Similarly, continuous data breaches [16], both of sensitive personal data but also of
sensitive documents, have increased the awareness of the public to the importance of this problem.
We have presented three independent topics that are becoming increasingly relevant: privacy,infor-
mation verification and access control. These are societal issues with growing relevance in the public
sphere but they are also, at the same time, organizational issues, in the way by which corporations can
adapt and improve, in order to overcome these problems. On one hand, the impacts on society, indi-
viduals and society as a whole, are startling albeit less tangible. On the other hand, for organizations,
the impacts of these problems can be financially, reputationally and legally hindering to an organiza-
tion’s well-being. For these reasons, research concerning these topics is of extreme importance and
increasingly so.
Access Control (AC) has been deeply researched but challenges to the existing models and so-
lutions for AC are emerging rapidly - some of those described above. Increasingly complex and dis-
tributed technological ecosystems, with increasing numbers of users, demand different approaches to
access control and its management. Nonetheless, it is a subject with endless research opportunities
due to the continuous advances offered by the industry. Research over AC was initially supported by
government-funded institutions [17]–[19] and directed towards specific systems [20]–[22], with military
purposes [23], [24]. We have watched research gradually shifting from Mandatory Access Control (MAC)
[23]–[26] and Discretionary Access Control (DAC) [17]–[21], [27] approaches to more organizational per-
spectives, specially with the introduction of Role-Based Access Control (RBAC) [28], [29], with a variety
of supporting models [30]–[34] that suit differences in organizations and use cases [35]–[38]. Different
models continued to be developed with different aims [39]–[41], with particular emphasis on the concept
of Attribute-Based Access Control (ABAC) [42]–[47]. For each new situation, AC research has been able
to provide a new solution to the emerging challenge. Recent examples of applications to modern prob-
lems include cloud computing [45], [46], [48]–[50], Internet of Things (IoT) [51], [52] and decentralization
of access control [53]–[55]. Some of these works have been more successful, and are more mature
than others.
By now, it might appear that all research problems in access control have been solved. Focusing
on the decentralization of access control we can argue that is not the case. A survey over existing
decentralized access control solutions [55], for distributed filesystems has found issues with ease of use,
scalability, and management difficulties, especially over permission revocation. Existing access control
solutions for cloud services are either centralized [49], [50], [56] or rely heavily on complex Public Key
Infrastructure and Key Distribution Centers [57]–[59]. A review of the state of art over access control in
2
IoT [51] has suggested a modern approach to access control should be concerned with providing ”many
and diverse approaches” [51, p. 242] rather than a ”one-size-fits-all approach” [51, p. 242]. Research
[51] suggests that current IoT access control solutions face two main challenges: developing improved
access control mechanisms over the classical ones and developing decentralized approaches to access
control in IoT, in an effort to improve security and ensure privacy. Access control for the Internet has
also been researched by using smart certificates over a centralized architecture [60]. Other efforts,
in researching decentralized access control, are either outdated for modern applications [22], [61] or
are purely theoretical [62]. Much of the existing research has been found to be centralized, lacking in
implementations, for current systems and use cases, lacking in scalability capacities and traceability, or
purely focused on IoT or cloud services. Recent literature has proposed alternatives for decentralized
access control through the usage of blockchain-based solutions but this is still an understudied problem,
as those solutions are either too specific or too theoretical, without having matching implementations.
Nonetheless, those applications rely on permissionless blockchains [63], which are less suitable for
organizational purposes, or narrow applications, such as IoT protection [64].
Going back to one of the problems briefly described previously, institutions providing education to
students, apprentices or trainees, by completion of a specific amount of learning hours, credits or prac-
tical assignments, or all of those combined, provide an achievement certificate. A certificate validates
that someone has reached a level of understanding, mastery or capability that is expected by the end of
the course. At the same time, these certificates are also proof, from a learner’s perspective, that these
activities have been successfully completed, either to share with a recruiter, as requirements for further
education or simply as a certification of completion. Given this, guaranteeing validity and integrity of
these certificates is important. These situations highlight that preventing certificate forgery is relevant,
not purely as a theoretical problem but as a practical, recurring issue that hasn’t been solved. At the
same time, apart from preventing the forgery of educational certificates, there’s also an overlooked im-
portance on being able to guarantee the integrity of a given issued certificate, which is not possible
currently - e.g. guaranteeing that the information of the certificate has not been modified. When we
start considering the fact that MOOC-based courses have been improving in contents, credibility and
acceptance, this problem starts to emerge as having the potential to be explored hastily, with few tools
to prevent this. With the rise of MOOCs and online education, this research problem of issuing, storing
and sharing educational certificates, in a digital format, while maintaining an ease of use, improving
security and privacy, will only become increasingly relevant. Furthermore, issuing, storing and sharing
educational certificates emerges as an interesting and relevant challenge to solve for the modern digital
age: (i) due to the amount of business actors involved, such as Students,Educational Institutions and
Recruiters, or any other entity requiring validation of a given certificate; (ii) due to the security consider-
ations that need to be understood and asserted; (iii) due to privacy concerns; (iv) due to the increasing
need of educational certificates, from the rise of MOOC-based learning; (v) and due to the fact that it
has yet to be solved. There has been some recent research aiming at solving this problem ([65], [66]),
with aspects to improve.
This problem intersects with the three aspects we have mentioned at the beginning of this section. It
3
intersects with privacy, as we have described, because a Student, or any given recipient of a credential,
might not want that information, or its personal information, to be described publicly. Currently, there are
few solutions to that problem. It intersects with the concept of information verification because verifying
that a certificate is legitimate is getting increasingly relevant, and increasingly difficult at the same time.
It intersects controlling access to information because, as we have seen, most current solutions are
either centralized or focus the responsibility of managing access control on the institutions rather than
the individuals.
1.2 Problem Statement
With this thesis, we perform research in order to be able to answer the following question: Can per-
missioned blockchains be a solution for decentralizing access control, in the context of educational
certificate issuance, sharing and verification? In order to achieve that, in alignment with what has been
described in the previous section, it is important to analyze the technological aspects of the problem, as
well as human aspects. The main objective of this thesis is to design, develop and evaluate a proof-of-
concept system that answers this research question, by exploring both aspects mentioned previously,
that can serve as a base for enhanced solutions of access control decentralization, in this use case.
1.3 Contributions
This thesis contributions are focused on three topics. We perform an exploratory statistical study and
analysis of a specific edge case of the human aspects, provide a design and architecture in which future
research can be implemented on, as well as a proof-of-concept prototype that implements a blockchain-
based solution to this problem, based on the proposed design and architecture.
Concretely, this thesis makes the following contributions: an exploratory statistical study of user’s
perception of blockchain, in terms of security and complexity; the design and architecture of a system
for decentralization of access control, with a permissioned blockchain, for our use case; a proof-of-
concept implementation for issuing, sharing and managing Educational Certificates; and an evaluation
on permissioned blockchains as a solution for decentralizing access control, particularly in our use case.
As a related achievement, due to the work conducted during this thesis, the author has been invited
to peer-review research for The 52nd Hawaii International Conference on System Sciences, on the topic
of the Transformational Impact of Blockchain. It is also worth mentioning that all code necessary and
presented in this thesis is available on Github (https://www.github.com/caramelomartins/blocked)
and is open-source.
1.4 Document Outline
This document is structured throughout 8 chapters. After this chapter, we have Chapter 2. That chap-
ter outlines some of the necessary background to this thesis, surveys the existing research and further
4
motivates this thesis by pointing a research gap in the existing research. Chapter 3 describes and moti-
vates the methodology of the research while exposing an intersection, between the chosen methodology
and the chapters in this thesis. Chapter 4 presents a study, based on data collected through an online
questionnaire with the aim of exploring the perception of users about the security and complexity of
blockchains, a component used in the design of the solution presented in this thesis. Chapter 5 dis-
cusses the conceptual design and architecture that underlie the implementation of the solution that has
been developed. Chapter 6 describes the implementation of the prototype developed, including the ac-
cess control framework, selected technologies, design and architectural decisions. Chapter 7 presents
the evaluations of our prototype and discusses the utility of our artifacts through a series of analytical,
simulations and descriptive methods, while also discussing limitations. Finally, Chapter 8 analyzes what
has been achieved in this thesis and where future research should focus on, by discussing unexplored
paths of research.
5
6
Chapter 2
Related Work
In this chapter, we present some relevant background and work that is related to this thesis. Due to the
broad nature of our research problem, as described in the previous chapter, there’s a need to review
several distinct areas of interest. We start by reviewing, in Section 2.1, existing literature on AC models
and applications, discussing how they relate to this research. Section 2.2 reviews different blockchain
approaches, dissecting their components, and describes existing literature on blockchain applications.
Finally, Section 2.3 reviews some of the work done on the topic of Educational Certificates - the use case
of focus in this thesis. By the end of this chapter, it should be possible to realize how these concepts, and
existing literature, relate to the core contributions of the thesis. It should also be possible to contextualize
our core research within the existing literature and, at the same time, lay out the necessary concepts to
understand the forthcoming chapters.
2.1 Access Control
Access Control has been a core component in every technology evolution and continues to be as rele-
vant today. It has always played a central role in technology because information is a valuable asset that
must be protected from prying eyes. Due to that fact, both governments and corporations have spent
considerable resources on developing AC models and instantiations, while academia produced a broad
spectrum of literature on the topic. Said literature has been produced with all sorts of approaches, from
the purely theoretical to implementation-based approaches. Nonetheless, no matter what has been pro-
duced and developed previously, there are always new challenges to face and, with every new evolution,
a new challenge emerges, which has led the field to be one of extensive study ever since the beginnings
of the computer age. As more sensitive data is shared and stored by third-parties, the relevance of
AC is only increasing, rather than decreasing, creating an optimal context for researchers to be able to
develop interesting new research that solves important problems.
7
2.1.1 Mandatory Access Control
Mandatory Access Control is a keystone AC approach characterized by embedding access control poli-
cies inside systems, a central authority, rather than in external sources, for example, a single subject,
transforming the policy into an unchangeable entity, from the perspective of an individual [23, p. 23]. This
indicates that policy decisions are independent of the object’s owner and its owner has no control over
what access rights an object has [67, p. 7]. This approach emerged in the early stages of AC research,
in the 1970s, when research on this topic was very focused military applications [26]. A classic example
is, therefore, the military setup. A user (subject) can only access documents (objects) that have the
same clearance level, or lower, as the user’s clearance level. [67] describes this situation:
(...) for example, a user who is running a process at the Secret classification should not be
allowed to read a file with a label of Top Secret. [67, p. 7]
Sandhu [26] provides an overview of the existing fundamental models following this approach: the
Bell-LaPadula model [24] and the Biba model [23], as well as Denning’s axioms for information flow
policies [25]. These access models are commonly known as the collection of Lattice-based Access
Control models, due to the fact that the sets of security classes for the objects and subjects form what
can be described as a lattice. Denning’s axioms coined the concept of security classes, which can be
seen as the labels described above (Secret and Top Secret), that define the rules that guide the logic
behind the previous example. Essentially, that a subject may only access objects that are of a lower
or equal security class than the subject’s security class [26, pp. 1-4]. These axioms aren’t an access
control model but rather a set of guidelines that enforce security of information. The Bell-LaPadula
model is essentially an access matrix (see Section 2.1.2), which subjects are able to modify, enforced
with unmodifiable mandatory policies. This specifies a more flexible use of mandatory access control
while maintaining a strict core of mandatory policies [26, pp. 9-11]. Biba’s model functions in a similar
way to the Bell-LaPadula model albeit with a focus on integrity levels of the objects, rather than focusing
on the level of confidentiality that they should possess [26, pp. 11-13].
2.1.2 Discretionary Access Control
A more flexible approach, albeit potentially less secure, in a strict situation, is Discretionary Access
Control. Sandhu refers to DAC as ”inadequate to enforce information flow” [26, p. 8], due to its lack of
constraints on copying information. DAC is characterized by allowing policies to be defined dynamically,
by object owners, contrary to the inherently static policies provided with MAC [23, p. 23]. With DAC,
policy enforcement is achieved by comparing a subject and its associated groups with the resources’
permissions and group permissions. In other words, validation is performed to answer the following
question: is the subject, or a group the subject belongs to, allowed access to a specific resource? As an
example, this is an activity performed frequently by users in organizations when they share specific files,
with specific people, with a particular collection of permissions - e.g. read but not write. In this case, the
owner of the document, or an authorized subject, is dynamically modifying the existing access control
policy.
8
Most DAC models are intrinsically related to the concept of an access matrix [17], [18]. Access ma-
trices consist of a matrix composed of objects and subjects that define a system’s access control policy
– subjects can be replaced by access domains or groups, in this instance. During policy enforcement,
access to an object is allowed if the intersection between a subject and an object bears a policy that
allows access to the object at the level it is being requested. Along with the models proposed by Graham
et al. [18] and Lampson [17], there’s another fundamental model that implements this concept, known as
the Harrison-Ruzzo-Ullman (HRU) model [19]. More recent models have been proposed to overcome a
set of undecidable cases when performing policy enforcement, with HRU, which left it vulnerable as an
access control model [27], [68].
Apart from access matrices, DAC offers other mechanisms for access control such as Access Control
Lists (ACL) and Capabilities. ACL, as the name suggests, can be thought out as a list of subject permis-
sions, and their types, associated with an object. This model corresponds to a single row of an access
matrix with all the information for each subject inside that column [69]. The Capabilities mechanism can
be understood as being an inverse mechanism to the access matrix and ACL, where permissions are
stored from the perspective of the subjects and which access they have to what objects [69].
2.1.3 Role-Based Access Control
Role-Based Access Control emerges as a commercially focused approach to access control, contrary
to DAC and MAC, which were predominantly focused on government and military applications [28].
RBAC introduced the concept of roles as an intermediary abstraction between the object and subjects,
in access control. With RBAC, policy definition was composed of three elements: subjects, objects,
and roles [28]. In this sense, RBAC is already different from the solutions described above, whose
focus was solely on subjects and objects. With RBAC, roles are defined as a function of, for example,
employee’s job titles. Each subject is assigned a role and each object is allowed access by a set of roles.
During policy enforcement, the validation performed is if the subject is a member of the defined roles
to which the object allows access. RBAC made policy management easier and it was better suited for
application systems that were commercially-focused instead of the military-based applications for which
access control had been developed thus far [70]. The reason for this suitability is due to the manner in
which organizations are usually structured. Organizations, unlike the military, have employees assigned
specific business roles and functions. Those roles carry with them a set of tasks and permissions that
every employee, assigned to that role, must possess. Organizations can easily have dozens, hundreds
or thousands of employees which makes managing policy at an individual level, painstakingly difficult
through matrices or access classes. By abstracting individual employees into sets of roles, the quantity
of policy definitions that are needed decreases dramatically.
Apart from the fundamental model [28], proposed by Ferraiolo et al., in 1992, other models soon
emerged such that a family of RBAC reference models was specified, known as RBAC96 [29]. Aside
from providing a formal definition of 4 models, with the base model being the one defined previously [28],
this work also added the ability for roles to have hierarchy and constraints attached to them, indepen-
9
dently or at the same time. A wide array of variations to RBAC exist with temporal constraints [71], [72]
and periodic constraints [73]. Other variations have evolved into independent concepts that rely on the
RBAC foundations such as Temporal Role-based Access Control (TRBAC) [30], Enterprise Role-based
Access Control (ERBAC) [74], Generalized Role-based Access Control (GRBAC) [75], Team-based Ac-
cess Control (TMAC) [34], Location-aware Role-based Access Control (LRBAC) [33] and Spatially Aware
Role-based Access Control (GEO-RBAC) [76]. A lot more variants of the RBAC model exist with these
being but a few examples. Apart from variations on the model, research has been performed on proving
that RBAC constructs are sufficiently expressive to replace mechanisms based on DAC and MAC [77].
This research is important because it shows how to perform modifications on legacy systems, using
DAC or MAC, to more modern, potentially more suitable, access control models.
2.1.4 Attribute-Based Access Control
There’s one challenge the proliferation of RBAC variations uncovers which is that the world is getting
increasingly more diverse in the necessities of access control, with small variations to access control
being dependent either on the context of the problem domain, or the context of the system in which it
is being implemented. This challenge has motivated the development of a different approach: Attribute-
Based Access Control. In ABAC, different from what has been described previously, access control
policies can be defined with a different component, apart from subjects, objects and roles – attributes.
ABAC utilizes subject and object attributes (or environment attributes) in policy definition as well as in
policy enforcement [47]. The usage of attributes increases the expressiveness of policies and allows
policy enforcement to be more dependent on dynamic data - increasing the effectiveness of access
control. Apart from increasing the expressiveness, ABAC also empowers organizations to define their
access control policies independently from subjects, which allows for subjects not to be provisioned
previously to requiring access to objects.
Given the flexible and case-by-case nature of ABAC, formally defining a generalized model is not
as trivial as for DAC, MAC and RBAC. Hu et al. [47] have attempted a generic formal definition from
previous definitions [42], [43], [78]. Hu et al. [47] define ABAC:
An access control method where subject requests to perform operations on objects are
granted or denied based on assigned attributes of the subject, assigned attributes of the
object, environment conditions, and a set of policies that are specified in terms of those
attributes and conditions.
Models for a variety of use cases have been proposed such as: an attribute-based access matrix [79],
ABAC for web services [43], attribute-based encryption [44], [45], grid computing [80], ABAC applications
on RBAC [81], cloud computing [48], [82], IoT [51], [83] and data sharing [46]. There’s been an attempt
at unifying ABAC into a model that could replace the previous models [77], much like we have described
for RBAC. This proliferation of models, for different problem domains, demonstrates the flexibility of
this approach but, at the same time, the difficulty in finding a model, within the approach, that will be
10
transferable between problems domains, as attributes’ definition is highly specialized on a given problem
domain.
Cloud storage is a perfect example of the suitability of this approach. Imagine a setup where a cloud
stores information that is accessible by a diverse collection of users, representing different institutions
and with different configurations. In this situation, applying any of the previously described approaches
is unsuitable. MAC and DAC would be cumbersome to configure while RBAC is unsuitable because the
concept of roles does not apply. A policy manager would be able to use ABAC by configuring policies
such as allowing a user from a specific institution, from a specific department, to have access to a given
object, while other users that didn’t have those attributes would not be allowed access.
2.1.5 Cryptographic Access Control
Cryptographic Access Control (CAC) differs from the approaches we have seen until now due to the
fact that it relies on, either independently or together with other approaches, cryptography to enforce
access control and, in particular cases, doing so while also ensuring the privacy of information and
access policies. Apart from the usual dimensions of access control, such as subjects and objects, CAC
relies on cryptography schemes, either associated with subjects, objects or policies, to enforce control
of access to information.
A simple example is the encryption of information. Encrypting information stops anyone, without
an appropriate decryption key, from having access to the information, while guaranteeing that whoever
has access to the decryption keys will be able to fully access the information. Different research has
proposed different schemes and models, for different problem domains.
One of the early problems domains was the application of cryptographic access control on hierarchi-
cally structured organizations. Research on this problem was mostly based on the concept of deriving
public keys from other keys in a hierarchy [84]. Based on this concept, solutions for controlling access
in hierarchically structured organizations emerged [85], [86]. This research allows subjects to hold keys
that represent their level of access, and then be able to derive the keys for the levels of access that
are below them, effectively allowing access management with cryptography. Initially [85], this research
required that when a new policy was added, in this case, a new security class, all keys had to be re-
computed and all information re-encrypted. This was a significant disadvantage that later models [86]
corrected. Chick et al. [87] presented a solution, with greater flexibility, to use master cryptographic keys
in access control, evolving these initial works.
More recent research has turned to cryptographic elements to enhance security and privacy of ac-
cess control models. There has been research on applying digital certificates to identity [88] and RBAC
on the Internet [37]. Miklau et al. [89] demonstrate an interesting implementation that uses cryptogra-
phy to control access to XML documents. This research proposes a cryptography-based access control
mechanism, in which, owners of information protect that information through encryption and then use
key distribution to enforce access control policies when sharing the information. Another solution to
encryption and control of potentially exposed information provides a two-layer approach, in which infor-
11
mation is initially encrypted by its owner and then re-encrypted by a storage server, to account for policy
evolution [90]. This solution also uses the concept of key derivation in order to be able to control access
through cryptography.
With the appearance of ABAC, research has started to overlap between ABAC and CAC, with
researchers finding new ways to enhance security and privacy, through cryptography, while keeping
expressiveness and flexibility with ABAC. These solutions rely on new concepts, such as Key-Policy
Attribute-Based Encryption (KP-ABE) [44] and Cyphertext-Policy Attribute-Based Encryption (CP-ABE)
[91], in order to use cryptography for control of access to information at a fine-grain [45], [48], [57].
2.1.6 Decentralized Access Control
The study of access control in distributed systems has spanned several decades since the early de-
velopments of distributed systems through grid and cloud computing and cloud systems. In very early
research, Karger [61] presents the challenges in distributed systems when applying MAC to a decentral-
ized system. It recognizes that not all algorithms that guarantee access control in centralized systems
can be easily mapped to a decentralized system, thus presenting a new way to work with lattice-based
access control models (see Section 2.1.1) that can be used in decentralized systems.
Moffett et al. [92] proposed a specification for the implementation of discretionary access control
in distributed systems. In this research, the concept of domains, groups of objects and access rules
were introduced as a way of helping structure the way access control is managed in a highly distributed
and complex system. This work evolved from Satyanarayanan [22] on security in complex distributed
systems. Research over the Andrew system [22] explored how to introduce access control in complex
distributed systems. Sandhu et al. [93], presented enhancements over Sandhu’s [27] Typed Access
Matrix model. This research proposes a simpler TAM, called SO-TAM, that made it easier to imple-
ment a Typed Access Matrix, in distributed environments, as well as demonstrates the usage of digital
certificates in AC.
Johnston et al. [94] present a mechanism for access control in distributed systems. The system de-
scribed leverages the research and capacity of digital certificates to allow access control in distributed
systems. Sandhu et al. [54] present the decentralization of access control management in RBAC mod-
els, in web-based systems. This research presents a way to try and decentralize the management of
access control, but it still does not decentralize the policy engine behind the access control. It was an
enhancement over a previous specification [35]. The research presented [54] evolved through the use
of X.509 certificates [60] and Park et al. [95] return to examine this research.
Harrington et al. [96] present a proposal for a cryptographic access control system, which is in-
herently distributed but not completely decentralized. This research evolves what has been presented
earlier [22]. Park et al. [38] demonstrate the application of the RBAC model in peer-to-peer environ-
ments, which is an evolution towards a more complete decentralization of access control. Abiteboul et
al. [97] present the implementation of a distributed system of access to confidential patient data, in a
distributed way, through XML data that presents an evolution over the research produced earlier [98].
12
Bhatti et al. [99] present a system - X-GTRBAC - for access control management, in GTRBAC model
[32], over decentralized environments. Chakraborty et al. [31] present a new access control model,
called TrustBAC [31], to address a problem identified in RBAC: difficulty in assigning roles to subjects in
decentralized systems, due to the fact that, in this type of systems, identities are often not known a priori
and the “user population is dynamic”.
With the proliferation of decentralized systems, developments in the area of access control continue
to emerge. Ruj et al. [49] present a new algorithm and model for the access control [49] in clouds by
expanding on the cryptographic research previously published. Calero et al. [50] propose a system for
the same effect based on the RBAC model [50]. This model intends to describe a suitable architecture
for an access control system for cloud computing. Yu et al. [56] present their model for access control
in cloud computing, which is related to previous research [50]. Recently, a number of attribute-based
access control models have been developed. Ruj et al. [58] present research on access control in
decentralized systems in which the identity of the principal is unknown [58]. The research presented in
[58] extends what had already been done by Ruj et al. [57].
Recent literature has proposed alternatives for decentralized access control through the usage of
blockchain-based solutions but this is still an understudied problem, as those solutions are either too
specific or too theoretical, without having matching implementations. Nonetheless, those applications
rely on permissionless blockchains [63], which are less suitable for organizational purposes, or narrow
applications, such as IoT protection [64].
2.2 Blockchain
2.2.1 Primer on Blockchain Technology
Blockchain technologies emerged as a supporting technology for the cryptocurrency Bitcoin, although
under a different name [100]. Nakamoto’s contribution was to solve the double spending problem without
using a trusted central authority. For this, time stamping servers were used, which use the concept of
blocks of hashes, with each hash having a reference to the previous block, and a modification of an
existing proof-of-work algorithm [101], initially developed to mitigate Denial of Service attacks [101, p. 1].
Consequently, the name for what we now call blockchains comes from the fact that, simply put, they can
be represented as chains of blocks, with references to previous blocks.
In essence, a blockchain can be perceived as a decentralized transaction ledger, with no central
authority and no single point of failure. This ledger consists of a chain of blocks, that represent the
transactions, and the creation of new blocks is managed through consensus’ protocols. Until now, the
concept of a blockchain doesn’t have a formal definition but several definitions have been presented
through new research. Buterin [102] suggests, appropriately, that one of the most revolutionizing as-
pects of the Bitcoin experiment is not the decentralized cryptocurrency, and the financial implications
it might have, but rather the fact that this new blockchain concept can be ”a tool of distributed con-
sensus” [102] and presents Ethereum as a platform for building decentralized applications, and not only
13
cryptocurrencies. As predicted by Buterin [102], and later described by Pilkington [103], blockchain tech-
nology, while still being at the very core of cryptocurrencies, started moving away and dwelling further
into other applications. Blockchain’s adoption started moving from Bitcoin [100], Ethereum [102], or Rip-
ple [104], towards more practical applications such as identity providers, voting systems, supply chain
alternatives for enhanced transparency or banking applications [103]. At the same time, other research
has pointed towards different possible applications of blockchain technology, other than cryptocurrencies
[105]–[108], which we will discuss, in more detail, in Section 2.2.
Blockchains can be loosely categorized into two types: permissioned and permissionless [103],
[109]. Permissionless blockchains are the initial category of blockchains in which access to a blockchain
is open to any participant, with no imposition of restrictions. In this type of blockchain, any user is allowed
to participate in the network, read data and submit modifications. These types of blockchains are suitable
for sharing of public non-sensitive information because they are fully transparent [109]. Permissioned
blockchains are a more recent category of blockchains that impose restrictions on the participants of
a network and what operations they are able to perform. While still being decentralized, this type of
blockchains might be more suitable for enterprise-grade blockchains, especially in industries where data
may not be entirely public [109]. Pilkington [103] points out that permissioned blockchains allow for a
configuration that can be considered a hybrid between both categories by allowing every participant to
read information but only a handful of participants to write to it.
A consensus about the state of the blockchain between participants in the network is achieved
through consensus algorithms, as described previously. Some known algorithms adopted in blockchains
are Proof-of-Work (PoW) and Proof-of-Stake (PoS), with some recent platforms using Proof of Elapsed
Time (PoET). Using the PoW algorithm requires a participant to solve a computationally intensive op-
eration[100], [109] in order to be able to submit a block on the blockchain. The fact that this operation
is computationally intensive effectively proves that a participant has performed the work necessary to
submit a block. The remaining participants validate the work performed, which is computationally less
expensive, in order for the block to be accepted. Using a PoS algorithm, more suitable for cryptocurren-
cies, requires a participant to provide proof that it owns a stake in the system and submitting is limited
to those that can provide that proof. This algorithm doesn’t need intensive computational as PoW does
[109]. Finally, PoET relies on participants waiting a specific amount of randomly defined time before
submitting a new block. Once that time has passed, participants are able to submit a new block and the
process starts again by attributing every participating a new waiting time. Since this algorithm relies on
the random attribution of periods of time and guaranteeing that every participant waits the designated at-
tribution, it requires particular hardware capabilities to ensure a safe environment, on which applications
using this algorithm would run. An implementation of PoW can be found in Bitcoin, an implementation of
PoS can be found in Ethereum and an implementation of PoET can be found in Hyperledger Sawtooth
[109].
Apart from the already mentioned cryptocurrency platforms, such as Bitcoin, Ethereum or Ripple,
there’s an existing group of projects, commonly called Hyperledger [110] by The Linux Foundation [111],
that provides a collection of open-source blockchain-based resources for organizations and individuals
14
to build applications on top of. From these projects, two platforms stand out for their maturity: Hyper-
ledger Sawtooth [112] and Hyperledger Fabric [113]. Both platforms offer a platform to configure, deploy
and execute permissioned blockchains. At the same time, they also offer tools to facilitate the develop-
ment of applications to be used with those platforms. The crucial difference between those projects is
that Hyperledger Sawtooth is a platform mostly focused on building, deploying and running a distributed
ledger, with much of the auxiliary tools focusing on the traditional transactional workflow, while Hyper-
ledger Fabric is a modular platform, focusing on providing flexibility and extensibility, with applications
running smart-contracts to interact with the blockchain.
2.2.2 Applications
While the technology itself keeps evolving and under analysis [114]–[117], and the entire concept of
Bitcoin is already heavily based on previous academic literature [118], we are only now starting to apply
this technology to practical problems of our society, albeit slowly and cautiously. One of those issues,
and one that has currently been the focus of major media attention, as well as in the academic envi-
ronment, is the area of Information Security. Given its decentralized nature, as well as its cryptographic
background, blockchains have started to gather attention for their potential applications at the level of
access control, privacy and security in general. This happens due to the increasingly distributed and
federated environments in which we now live, such as the Internet of Things, which call for different
approaches and concepts, when considering how to more effectively to secure them, as motivated in
Section 1.1.
Research over using blockchain to resolve problems with data ownership and privacy has been
conducted in [119], [120] and [121]. These works have explored how using blockchains can enhance
the security and privacy of information, in different problem domains. Particularly, Zyskind et al. [119]
propose a decentralized personal data management system that allows users to share their information
with services without disclosing the contents of the information. Liang et al. [120] propose a system
for the storage of metadata, corresponding to cloud data, in a tamper-proof blockchain. Blockchain has
also been researched as a way to enhance security and decentralization in content distribution [122].
At the same time, blockchain has also been researched as a technology for enhanced security of IoT
infrastructure - theoretically [51], [123] and in practice [52], [64]. Furthermore, on the aspects of access
control and identity management, there’s been some research developed by Augot et al. [124], Yasin et
al. [125], as well as Maesa et al. [63], whose system allows for the use of the Bitcoin blockchain to store
ABAC policies. In [64], an overlap between access control and IoT was researched, in which blockchain
enhanced access control on IoT infrastructure. Finally, there’s been research on applying blockchain
technology into securing smart cities [126], decentralized private voting systems [127], securing credit
reporting [128], healthcare [129] and cloud computing payment systems [130].
We demonstrate with the previous paragraph that we have crossed a moment where blockchains
are researched purely in a theoretical fashion and are now being seriously considered as practical
components of solutions in diverse domains. On top of the presented research, more research is rapidly
15
emerging with new applications and better solutions for existing applications.
2.3 Educational Certificates
MIT’s Media Lab Learning Initiative [131], along with Learning Machine [132], has conducted research,
Digital Certificates Project [65], in 2015, on this subject. This research developed the initial proto-
type that allowed to create an ecosystem for issuing and sharing educational certificates, based on
blockchains. Some certificates generated based on this prototype are still accessible [133]. Digital
Certificates Project, initially focused on issuing digital certifications for educational purposes, later spun
BlockCerts [66], which expanded the issuing of certificates from educational certificates to more general
use cases. BlockCerts claims to be ”The Open Standard For Blockchain Credentials” and, contrary to
what had been developed for Digital Certificates Project, it includes a more robust ecosystem, based on
the open-sourced code of the initial prototype. BlockCerts now includes libraries and tools to allow the
development of decentralized applications for issuing and sharing digital (educational) certificates.
Although BlockCerts is an effort to standardize the development of decentralized applications for
these purposes, it currently lacks some functionality - some of it defined in its Roadmap - such as: (i) only
works with Bitcoin and Ethereum, which means there’s a lack of support for additional public blockchains
or hybrid blockchains; (ii) revocation is highly dependent on the issuer; (iii) there’s a lack of access
control capabilities for the recipient of the certificate; (iv) uses the same approach as cryptocurrencies -
the wallet concept - to manage the issuing and sharing of the certificates. As with any new technology,
there’s a lot of innovation space. BlockCerts has a growing, strong open-source community and an
ecosystem that enables some of the existing gaps to be closed. It also helps to state the relevance of the
issue this thesis explores. The fact that it BlockCerts only works with permissionless blockchains is an
issue in an organizational world. For use cases, where data should not be publicly accessible or where
institutions want to offer flexibility but retain a low-level degree of control, permissioned blockchains are
the suitable alternative. Being unable to revoke a certificate, being the recipient, prevents the owner of
the certificate of controlling the existing information. Lack of access control capabilities is a crucial gap,
in the sense, that the public nature of a permissionless blockchain allows anyone to read information
from the blockchain thus accessing information, potentially sensitive, in an unwanted fashion. Finally,
the wallet concept seems unsuitable for this use case since it forces certificates to be issued for the
same address when associated with a particular user.
Other research has been developed on this topic with BSCW [134]. BSCW is based on the Ethereum
blockchain and also allows for the issuance and management of education certificates, in complex sce-
narios. BSCW is based on a permissionless blockchain, Ethereum, and relies on the Mozilla Open
Badges specification, similar to BlockCerts.BSCW supports the specification of smart contracts. Al-
though the research is mature, with a platform implemented that allows for all operations to be performed,
with a Graphical User Interface (GUI), and identity management, there are a few limitations. Revoca-
tion in BSCW disables the possibility of viewing a certificate, which is cumbersome as it prevents users
from viewing that a certificate has been revoked. It still relies on using JSON or PDF files to share the
16
certificates both with the recipients, and the recipients with any other third-party. The system can only
verify certificates that are inserted as files in the platform. Another limitation is that the system requires
monetary costs to be run, given that it runs on Ethereum, which is similar to what happens in BlockCerts.
Lastly, one of the suggested improvements on the existing systems, by [134], is developing a mechanism
that would store personal information, with cryptography mechanisms, on an append-only ledger - albeit
a public one - to improve on the security and privacy of the platform.
We demonstrate with the previous paragraph the relevance of the selected use case. Together
with what has been described in Chapter 1, we are describing how there are few existing solutions
to the problem of falsified educational certificates. This use case fits perfectly with our exploration of
decentralizing access control to information.
17
18
Chapter 3
Methodology
In previous sections (Chapter 1 and Chapter 2) we motivate our thesis, by analyzing the existing litera-
ture, defining and motivating a specific research problem, setting out the objectives and describing the
contributions made by this research. It is now relevant to explain the methodology used in our research
and the factors that contributed to choosing it. We will also describe how the various sections of this the-
sis intersect and fit into the chosen methodology, through the adoption of the same presentation model
described by the methodology’s authors.
Information Systems (IS) has devoted considerable effort to studying methods and frameworks for
IS research. Currently, two main paradigms characterize IS research: Behavioral Science (BS) and
Design Science (DS) [135, p. 76]. After carefully evaluating existing reference literature, such as [135],
[136], [137] or [138], a suitable research methodology would be to conduct our research based on the
guidelines for Design Science Research (DSR), as it is a common and accepted practice in IS research.
In their seminal paper, March et al. [136] define a DS research framework by applying natural science
methodologies to the study of IS, with the purpose of maximizing research utility, contrasting with the
natural sciences’ view of research for truth ([135, p. 80], [136, p. 253]). They achieve that by creating a
framework consisting of a two-dimensional matrix: research outputs and research activities [136, p. 255].
Research outputs are composed of constructs,models,methods and instantiations. Research activities
are composed of processes such as build and evaluate. Research outputs, also known as artifacts,
are created with the purpose of solving a specific problem that has yet to be solved [135, p. 78], while
research activities are the processes by which those artifacts are designed to meet a criterion [135,
pp. 79–80]. Hevner et al. [135] argued that, in fact, truth and utility are inseparable [135, p. 80]. This
statement is the basis for their approach, which extends the original DSR framework [136] presented by
March et al. [136], by setting the following practical guidelines: (i) Design as an Artifact, (ii) Problem Rel-
evance, (iii) Design Evaluation, (iv) Research Contribution, (v) Research Rigor, (vi) Design as a Search
Process and (vii) Communication of Research. Summarizing, DSR requires the creation of a novel,
innovative, purposeful artifact, that is formally defined, for application on a specific problem domain, cre-
ated through a search process to find an effective solution and, finally, communicated effectively to the
community [135, p. 82].
19
Peffers et al. [138] present a Design Science Research Methodology (DSRM), extending previous
research [135], [136], ”for the production and presentation of DS research in IS” [138, p. 3]. This re-
search expanded on previous concepts by proposing a missing procedure [138, p. 7] that would connect
both the principles and practical guidelines existing in DS to create a formal research methodology. With
that in mind, they have proposed a series of activities that form a process by which to conduct DSR: (i)
Problem Identification and Motivation, (ii) Define the Objectives for a Solution, (iii) Design and Develop-
ment, (iv) Demonstration, (v) Evaluation and (vi) Communication. This set of activities aligns well with
the practical rules proposed by Hevner et al. [135] and, as Peffers et al. argue, with most of the literature
conducted thus far. Although the procedure is presented sequentially, the authors point out that ”there
is no expectation that researchers would always proceed in sequential order from activity one through
activity six” [138, p. 14], which provides flexibility while conducting research while, at the same time,
providing a rigorous process to follow. The importance of this work is that it takes the practical guide-
lines and theoretical principles established previously, turning them into a process for direct application
on research.
We have aimed, while conducting the research presented in this thesis, to follow what has been
proposed by Peffers et al. [138] while, at the same time, keeping in mind the practical guidelines laid out
by Hevner et al. [135]. Both papers are widely cited contributions to the body of knowledge, with case
studies that exemplify applicability to conducting DSR. They have matured through years of refinement
and have been wildly used by the IS research community, making them a suitable choice for a method-
ology to follow. To exemplify the usage breadth of these approaches, we can verify that they have been
used or suggested, and cited, in IS research on supply chain on the internet of things [139], quality of
business processes [140], modeling of resources and resource management [141] and service systems
engineering [142].
To demonstrate the application of the chosen methodology throughout this thesis, we will take the
same approach as Peffers et al. [138] by describing how we have fulfilled each of the designated ac-
tivities. In each of these paragraphs, we aim at mentioning the respective DSR guidelines behind the
DSRM activity, where appropriate. Although the authors have argued that this methodology of research
need not be conducted sequentially, most of what has been described in this thesis has, indeed, been
done in a sequential fashion. Wherever appropriate, we also relate each chapter back to the procedure
described here.
Problem Identification and Motivation. In Chapter 1, we have introduced our thesis by motivating
the existence of a specific problem while, at the same time, describing, and justifying, why a solution
to this problem is needed. We have exposed a knowledge gap and the relevance of this problem. We
justified the solution to the problem by using examples from the past and by connecting this problem
domain with future trends, both technological and societal, showing how the problem will be aggravated
by the trends in IS we have been witnessing. We have taken this perspective a step further, by dissecting
in Chapter 2 where that knowledge gap is, in relation to the existing literature. This approach also relates
correctly with what has been proposed by Hevner et al. [135] by justifying the Problem Relevance of this
type of research. In Chapter 1, we also explicitly define our problem statement, to make it as clear as
20
possible.
Define the Objectives for a Solution. This is, also, achieved in Chapter 1, where we discuss the
objectives for this thesis. In this case, we define what a solution should accomplish in order to be relevant
to our research question and our identified problem. According to what Peffers et al. [138] proposed,
we define qualitative objectives [138, p. 13], in the sense that we provide a description of new artifacts
and how they should solve the identified problem. By now, we are already abiding by the Design as an
Artifact guideline [135] due to the fact that we propose artifacts, focused on a given problem domain, to
address an existing problem [135, p. 82].
Design and Development. This section of the process can be found throughout Chapter 4 to Chap-
ter 6. Initially, high-level artifacts were designed, both as models and methods, of what a possible
solution to the problem should accomplish. Those artifacts were then used in a conducted study, in or-
der to assess what would be the perceptions of users to our new artifacts. Would this idea be feasible?
Would it make an understandable and reasonable solution for the problem at hand? Was the identified
problem recognized by users? These were the questions we were after, to validate our initial hypothesis.
This study is also a property of social and informational resource [138, p. 6], as defined by Peffers et al.
[138], to further reinforce the research conducted. After that, we took the feedback into consideration, by
designing lower-level artifacts, in the form of models, which we used to define methods and then an in-
stantiation, in the form of a prototype. These are the artifacts created during our research, following this
methodology, in order to evolve from the stage of objectives to creating an actual artifact that represents
a solution. Our approach was mindful of: (i) the definition that ”a design research artifact can be any
designed object in which a research contribution is embedded in the design” [138, p. 13] and (ii) of the
Research Contributions guidelines [135, p. 87], such that all our actions have been towards generating
artifacts, ”new and interesting contributions” [135, p. 87], with a purpose that suits our problem domain.
Demonstration & Evaluation. We have decided to justify both of these sections together because,
in all truthfulness, a demonstration is, in itself, an aspect of evaluating a given artifact. Peffers et al.
[138] explain exactly that duality by saying that ”solutions vary from a single act of demonstration (...) to
prove that the idea works, to a more formal evaluation (...) of the developed artifact.” [138, p. 13], when
presenting both sections. The solution has been demonstrated by describing a simulation of the problem,
applying the solution to it, running the instantiation and further analyzing how the solution resolves the
problem, as described in the simulation. This method - the simulation - is an approved method of
evaluating as per Hevner et al. [135, p. 13]. Furthermore, besides the experimental simulation, we
applied analytical methods by evaluating the solution through a collection of guidelines [143], specific
to the problem domain of access control solutions, and descriptive methods, by way of an informed
argument [138, p. 86]. Due to the fact that this research finds itself at the intersection of several different
domains, and is, at the same time, in a recent research field, it becomes difficult to achieve a quantitative
evaluation (e.g. performance evaluation) of each of the artifacts. We provide an exploratory qualitative
analysis, based on the collection of guidelines mentioned previously. A more thorough quantitative
analysis can, nonetheless, be achieved or planned, as outlined in Chapter 8.
Communication. Throughout the development of this research, communication has been one of the
21
established priorities. The research described in this thesis has been communicated, for the most part,
with researchers, and less with practitioners. Peffers et al. [138] suggest that all aspects of the research
should be communicated, from ”the problem and its importance” [138, p. 14], all the way to the remain
aspects of the artifact, such as design, novelty, utility and evaluation. While communication was weaker
when it comes to practitioners, we have focused our efforts on publishing our research, in scientific
conferences and chapters in edited books. These publications focus on communicating most of what we
outline and describe in this thesis, from problem identification and motivation to artifact evaluation. The
chapter described access control challenges in enterprise ecosystems and possible solutions through
blockchain-based technologies [144], whose main content was derived from the extensive analysis of the
state-of-art presented in this thesis (Chapter 2), description and motivation of the problem. Apart from
this chapter, components of the research presented in this thesis have been submitted as conference
research papers for (i) The 34th ACM/SIGAPP Symposium On Applied Computing (ACMSAC’19). The
submission for ACMSAC’19 focused on the work conducted throughout Chapter 4. We would like to
make another submission to share the work described throughout Chapter 5 and Chapter 6.
By now, it should be clear what is the chosen methodology - Design Science Research Methodology
[138] - for the research presented in this thesis. It was also described how the contents of this thesis, in
each chapter, intersect with the chosen methodology, both in theory and practice.
22
Chapter 4
Assessing User’s Perceptions of
Blockchain
In this chapter, we present the results of research conducted through an online questionnaire focused
on the problem of assessing a user’s perceptions of blockchain-based technologies. We describe the
design that underlies our questionnaire, present the results of the questionnaire and perform an in-
depth analysis of those results, in which we explore what trends we are able to infer. Our objectives
with this are to assess how users perceive blockchain-based technologies, both in terms of security and
complexity, and understand how the adoption of such technologies, specifically in our use case, might
vary positively, or negatively, comparing to other technologies.
We have highlighted, previously, potential applications of blockchains [103], [105], [106], as well as
some research that has already been conducted thus far [64], [122], [126]. It starts to be clearer that
blockchain technology has far more potential, than exclusively as a means to register transactions of
decentralized cryptocurrencies. Nonetheless, there’s few or nonexistent research in regards as to how
humans perceive blockchain technology, much less in our specific use case. Although there’s increasing
research focused on using blockchain technology, for solving security, privacy and access control issues,
such as [51], [52], [63], [121], in an increasingly decentralized and complex society, there’s little research
over how humans perceive that disruption.
Important factors for the adoption of a given technology, or technique, are the perceived relevance,
complexity and suitability for the task at hand: How can we understand how humans will embrace the
blockchain disruption if we don’t understand how they perceive the underlying technology? It is a fact
that end-users are increasing their blockchain-based cryptocurrencies adoption [145] [146] [147], along
with the market value increase of several cryptocurrencies. Yet, the understanding of how humans
embrace these new decentralized applications built on top of blockchains, not only Bitcoin’s blockchain
but other blockchains as well, is still largely unknown. This is an enormous gap in our knowledge, in the
sense that we have been funding millions of dollars for startups with the promise of building technologies
on top of blockchain technologies, yet we cannot even grasp how humans will react to that disruption.
If users’ perspective is not accounted in the design of new blockchain applications, they would be more
23
likely to fail.
Furthermore, we have yet to understand how users perceive blockchain’s complexity or inherent
security. We have yet to understand if they understand the technology and concepts, or whether such
a technology would appeal to them. Do users perceive blockchain as having the same potential as
the academic literature suggests? Do users perceive blockchains as solutions to the problems we are,
collectively, aiming to solve? These questions are our starting point for the forthcoming statistical study.
The aim of our research is to start filling in that gap by studying how users perceive blockchain-
based technology, regarding its security and complexity. This has been done by conducting a statistical
study, based on an online questionnaire, that attempts to get insights on these matters. In this study, we
focused on two design questions:
•DQ1 - What is the perceived level of security in blockchain-based solutions, compared to other
solutions, specifically centralized solutions?
•DQ2 - What is the perceived complexity introduced by blockchain-based solutions?
The aims of this statistical study are two-fold: (i) filling a gap in current knowledge regarding blockchain-
based technologies, namely the user perception, and (ii) focus on the perceived value of blockchain-
based solutions for the challenge of educational certificate issuance, sharing and validation. Specifically,
we aim at understanding how users perceive blockchain-based solutions, in the context of educational
certificates, in terms of security and complexity. The online questionnaire was conducted with 46 re-
spondents.
4.1 Study Design
In Chapter 2, we described the importance of educational certificates to validate the achievements and
capabilities that a specific individual possesses, to a third-party entity. We also described how, with the
growing trend in MOOC-based education, issuing, storing, sharing and validating educational certificates
is starting to become an interesting challenge to overcome. Moreover, we have also described how some
research has been attempting to solve this challenge by using blockchain technologies. At the same
time, we have reviewed how research into security, privacy and access control has been increasingly
studying the usage of blockchain technologies to overcome the challenges of those fields. With that, we
have motivated how a lack of research over users’ perception of the blockchain technologies can pose
further challenges in the adoption and usage of blockchain technologies, in deeper research.
4.1.1 Business Actors and Interactions
An initial set of business actors was established for the processes we described in the questionnaire:
Student,Educational Institution and Recruiter. In this situation we are using a third-party actor - Re-
cruiter - for a specific use case, of trying to share a digital certificate with a recruiter for the purpose
of, for example, validating that a Student has the educational background it claims. The Student is the
24
requester of the certificate that needs to be issued or is going to be shared. It is the individual that is the
rightful owner of the certificate and should determine who has access to it. The Educational Institution
is the one that is able to generate new certificates, requested by the Requester. It has the capability to
validate all requests as well as issue the certificates. Finally, the Recruiter serves the purpose of being
an individual, with which a certificate might be shared and might want to validate its authenticity.
(a) Interactions in Scenario 1 (b) Interactions in Scenario 2 (c) Interactions in Scenario 3
Figure 4.1: Interactions presented to Respondents.
We used these actors as the basis to develop more complex scenarios and interactions, which we
then used in our questionnaire. Respondents were presented with 3 interactions between these actors,
as Business Process Model and Notation (BPMN) [148] models, presented, respectively in Figure 4.1a,
Figure 4.1b and Figure 4.1c. The context in which these interactions were presented is explained, in
detail, in the forthcoming section. The three scenarios the respondents had to analyze described: (a) a
typical scenario of issuing, sharing and validating an educational certificate, (b) a typical scenario, using
an undisclosed storage mechanism, such as a database, with added access control functionality, and
(c) a typical scenario, using a blockchain, with added access control functionality.
4.1.2 Methodology
This section discusses the methodology, used throughout the questionnaire, specifically the design of the
questionnaire and its contents, and afterwards, the presentation and distribution methods are explained.
Questionnaire Layout
The questionnaire was designed to target professionals in multiple industries with different backgrounds
and knowledge levels. It had 28 questions, of which 21 were mandatory questions and 7 were optional.
There were 5 sections on the questionnaire: Introduction,Background,Exercise 1,Exercise 2 and
Final Survey. There was no time limit nor were the respondents’ participation offered any incentives.
Participation was completely voluntary.
25
Section Detail and Questions
Introduction explained the research objectives, the context in which it was inserted and it stated that all
answers were anonymous and would only be used, and shared, for academic purposes. Background
had four questions, with the aim of assessing respondents’ professional and academic background, as
well as their perceived knowledge of specific technologies and concepts. Those questions were:
1. Do you have any academic or professional background related with Information Security?
2. Which industry best fits with your professional experience?
3. Which professional role best fits your experience?
4. How do you classify your knowledge of the following concepts?
In Exercise 1 and Exercise 2, respondents were asked to answer specific questions. In Exercise 1
there were two separate scenarios to analyze. In Exercise 2 there was only one scenario to analyze.
In each scenario, there was a simple BPMN [148] model followed by a description of the interactions
between the actors. All three scenarios had exactly the same 7 questions:
1. Which level of security do you perceive in each interaction?
2. Which level of security do you perceive in the entire process?
3. What could make it more secure?
4. Select any interactions you perceive as allowing unauthorized access to information being shared.
5. If you were a Student, what would be your willingness to share information, in this context, with a
Recruiter?
6. If you were a Student, what would be your confidence that the information you share is secure and
no one, except the Recruiter, will access it?
7. Which level of complexity do you perceive in each interaction?
In the last section, Final Survey, the respondents were asked two additional questions and a place-
holder for some comments, if necessary:
1. Do you think any of the previous 3 scenarios was more secure than the others?
2. Do you believe knowledge of Information Security, its applications and concepts, is at an adequate
level in your professional environment?
Out of the 7 questions, in Exercise 1 and in Exercise 2, 5 were based on Likert scales from 0 to 4,
where 0 was the lowest possible value and 4 was the highest possible value. 1 question was an open-
ended question - and 1 was a checkbox question. These questions, from each scenario - 21 questions
in total - were the core of our study. The respondents were never asked to compare any scenario but
only asked to answer the same questions for each scenario.
26
Distribution Methods
Two versions were made out of the same questionnaire. The first version had the following sequence:
Typical scenario →Storage Mechanism scenario →Blockchain scenario. The second version had
the following sequence: Storage Mechanism scenario →Typical scenario →Blockchain scenario.
The questionnaire was made available online at a specific URL 1and, upon clicking on it, respondents
were redirected to one of the versions without knowing which version and without knowing that several
versions existed. The aim of this separation was to try and mitigate the learning effect bias that might
arise when analyzing the results of a questionnaire answered on a given sequence
The questionnaire was pretested with 1 respondent to validate there were no problems, before distri-
bution and, after necessary corrections, was distributed. Distribution took place, initially, over email to a
controlled group of 5 people to ensure the randomization system was working properly and that no errors
occurred with submission, this was in order mitigate further problems before sending the questionnaire
to more people. After that, it was sent, via email, to a group of 50 people, mainly professionals. That
group grew to approximately 150 people. After that, the questionnaire was also posted on HackerNews
2, as a LinkedIn post 3and in Reddit: in /r/Assistance 4and /r/SampleSize 5. The questionnaire was
open for submission from May 9, 2018, until May 20, 2018. Overall, we were able to reach 82 views, of
which 46 answered the questionnaire completely.
4.2 Results
This section presents the results of the questionnaire. We have analyzed both versions of the question-
naire separately, Version 1 and Version 2, and performed a combined analysis, with both versions’ data
sets. This helps when discussing what it is possible to conclude from the results by taking into account
possible learning effects’ bias, as well as define the limitations that can be overcome in future work,
discussed in Chapter 8.
This section is structured in direct relation to the design questions outlined, at the beginning of this
chapter, by looking at the data that relates to each of them.
As described previously, 46 respondents answered the questionnaire, with 24 respondents answer-
ing Version 1 (52%) and 22 respondents answering Version 2 (48%). There was a balance between
respondents with backgrounds related to Information Security - with 52% of the respondents saying they
do have a background related to Information Security. Nonetheless, in Version 1, 62.5% of the respon-
dents said they did not have a background related to Information Security. Industries and Roles (see
Table 4.1 and Table 4.2) tended to be in the area of Software Development.
For simplicity of our analysis, we have corrected the switch made between Version 1 and Version
2, when reporting the results, in order to allow a direct comparison between both data sets, instead of
1https://hugomartins.io/human-perception-infosec/
2https://news.ycombinator.com/item?id=17064032
3https://www.linkedin.com/feed/update/urn:li:activity:6401809377023533056
4https://www.reddit.com/r/Assistance/comments/8jk3hf/human perception of information security for
5https://www.reddit.com/r/SampleSize/comments/8jk5ej/academic human perception of information security
27
having to mentally compare them, using the sequence used in Version 1.
Table 4.1: Industry Frequency
Industry Version 1 Version 2 Both
Consultancy 5 1 6
Telecom. 1 1 2
Software Dev. 9 15 24
R&D 1 1 2
Academic 4 3 7
Other 2 1 3
N.A. 1 0 1
Health 1 0 1
Table 4.2: Role Frequency
Role Version 1 Version 2 Both
Software Dev. 13 12 25
Researcher 2 2 4
Professor 1 15 24
Business Manager 5 1 6
Project Manager 1 4 5
Other 1 1 2
N.A. 1 0 1
Respondent’s perceived knowledge of specific concepts, from 0 (lowest) to 4 (highest), slightly var-
ied between versions, with Version 2 presenting a more knowledgeable set of respondents, in most
concepts (see Table 4.3), with the concepts being: (i) Access Control; (ii) Encryption; (iiii) blockchain;
(iv) Data Integrity; (v) Malware; (vi) Phishing; (vii) Data Confidentiality; (viii) BPMN; (ix) Data Storage;
(x) Unauthorized Access.
Table 4.3: Reported Knowledge Using the Scale 0 (Lowest) to 4 (Highest)
Concept Version 1 Version 2 Both
˜x σx˜x σx˜x σx
1 1.92 0.97 2.36 1.18 2.13 1.09
2 1.67 1.05 2.14 1.13 1.89 1.10
3 1.33 0.87 1.05 0.84 1.20 0.86
4 1.83 1.09 2.14 1.21 1.98 1.15
5 1.71 0.91 1.82 0.96 1.76 0.92
6 1.96 0.91 2.14 0.94 2.04 0.92
7 2.46 1.02 2.46 1.01 2.46 1.01
8 0.83 1.01 1.36 1.36 1.09 1.21
9 2.29 1.00 2.36 1.33 2.32 1.16
10 2.00 1.02 2.09 1.27 2.04 1.13
Regarding our background results, we can conclude that our sample tends towards Software De-
velopment, followed by professionals from Academia. This means that our sample is potentially more
knowledgeable about common technology topics than a more mixed sample would. Version 1 respon-
dents reported a below-average knowledge of the presented concepts, with a lower standard deviation,
while Version 2 respondents reported a higher than average knowledge of the presented concepts, with
a less concentrated set of answers. All coefficients of variation, in the compound analysis, are lower
28
than 1 (between Cv= 0.41 and Cv= 0.72), except for BPMN (Cv= 1.11). The same happens for each
separate version, with different boundaries.
4.2.1 Design Question 1
What is the perceived level of security in blockchain-based solutions, compared to other
solutions?
To answer this question, we took special attention to questions 1, 2 and 4 of each of the scenarios.
In questions 1 and 2, respondents were asked to evaluate the perceived security of a given scenario.
The evaluations were for the process in its entirety and for each interaction in the scenario. Question
4 asked respondents to select the interactions they perceived as allowing unauthorized questions. We
have also taken into consideration the answers given in the final question, in which respondents were
forced to choose which scenario was the most secure.
Starting from the last question, an overwhelming majority of the respondents answered that they
perceived the scenario using blockchain to be the most secure (see Table 4.4) - when forced to choose.
Table 4.4: Most Secure Scenario (Total Amount of Responses)
Answer Version 1 Version 2 Both
None 1 1 2
Scenario 1 1 4 5
Scenario 2 3 3 6
Scenario 3 19 14 33
This suggests that there’s a tendency to believe that blockchain-based solutions are perceived as
being more secure than other solutions. The fact that users were forced to choose one or none of
the scenarios makes it more clear that, although we cannot claim any justification for it, respondents
had a tendency to claim that blockchain-based solutions are more secure than other solutions. Even
more interesting is that not only did respondents choose blockchain-based solutions against the typical
scenario but the same occurred for the scenario that used a basic Storage Mechanism, instead of the
blockchain-based one.
For the first question, which asked for the perceived level of security in each scenario (see Table 4.5),
we witness similar results. We witness the same effect, in Version 2, as we had previously, although the
data is more spread (σx= 1.23).
Table 4.5: Perceived Security / Scenario Using the Scale 0 (Lowest) to 4 (Highest)
Scenario Version 1 Version 2 Both
˜x σx˜x σx˜x σx
1 2.13 0.99 2.50 1.23 2.30 1.11
2 2.83 0.96 2.36 0.95 2.61 0.98
3 3.00 0.89 2.91 0.87 2.96 0.87
We can understand, by studying the coefficients of variation (Version 1: Scenario 1 (Cv= 0.47),
Scenario 2 (Cv= 0.34), Scenario 3 (Cv= 0.29); Version 2: Scenario 1 (Cv= 0.48), Scenario 2 (Cv=
29
0.40), Scenario 3 (Cv= 0.30) that respondents’ answers became more concentrated when it comes to
blockchain-based solutions (Scenario 3), while being more dispersed in Storage Mechanism (Scenario
2) and even more in the typical process (Scenario 1). This further reinforces the appearing tendency.
By studying the results of the evaluation by interaction, in each scenario, and with the scenario as a
whole, the data is less clear than previous answers. Results, seen in Table 4.6, have shown an increase
in the dispersion of the data which impacts mean-based analysis. It is interesting that, contrary to what
had happened when asked about the security of the entire process, in this case, in Version 1, we cannot
see a major difference between the results of Scenario 2 and Scenario 3. Nonetheless, we still see the
same patterns as in the previous results, in Version 2 and when considering the data sets combined.
Table 4.6: Perceived Interaction Security / Scenario Using the Scale 0 (Lowest) to 4 (Highest)
Scenario Version 1 Version 2 Both
˜x σx˜x σx˜x σx
1 2.26 1.30 2.58 1.21 2.42 1.26
2 2.71 1.13 2.27 1.43 2.50 1.30
3 2.68 1.12 2.72 1.19 2.70 1.15
In Figure 4.2 we expose the data used to generate Table 4.6’s Version 1, with line charts, in which
the data sets for each scenario have been run through a probability density function. This allows us to
see that the mean, for Scenario 2, is highly influenced by more skewed distributions and, at the same
time, it confirms, visually, the data about the process as a whole. Scenario 3 is visually more secure and
concentrated - the interactions perceived as more secure, individually.
Figure 4.2: Probability Density of Perceived Interaction Security (Version 1)
30
At the same time, in Figure 4.3 we expose the data used to generate Table 4.6’s Version 2. The
visualizations closely resemble the one presented in Figure 4.2. This is relevant due to the fact that
the aggregate numbers, shown in Table 4.6, only allow us to have a high-level understanding, of the
respondents’ perception. The visualizations help to understand that, even in more detail, the data is
similarly distributed, although, somehow skewed to the left, in Scenario 1, and skewed to the right.
Figure 4.3: Probability Density of Perceived Interaction Security (Version 2)
Finally, respondents also perceived that sharing the certificate, under a blockchain-based solution,
had fewer interactions with the possibility of allowing unauthorized access to data, than with the typical
purpose. The same is true for blockchain-based solutions over the Storage Mechanism.
4.2.2 Design Question 2
What is the perceived complexity introduced by blockchain-based solutions?
Table 4.7: Perceived Complexity / Scenario Using the Scale 0 (Lowest) to 4 (Highest)
Scenario Version 1 Version 2 Both
˜x σx˜x σx˜x σx
1 1.56 1.51 1.47 1.13 1.51 1.14
2 1.96 1.21 1.71 1.25 1.82 1.23
3 2.25 1.26 1.97 2.00 2.12 1.24
For this question, we have analyzed the answers to question 7 of each scenario, which asked re-
spondents to grade each interaction they were shown, in terms of its complexity. We present the mean
31
for all interactions’ evaluation and also the standard deviation, per scenario (see Table 4.5). The results
show that there’s an increase in the perceived complexity of blockchain-based solutions. In this case,
contrary to what happened with the previous design question, we do not see a pronounced learning
bias as, regardless of the order of the questions, the tendency remained the same - and the compound
analysis reflected that situation. It is also interesting to notice that, when asked about the concept of
complexity, the dispersion of data increases, especially when compared to the concept of security.
Figure 4.4: Probability Density of Perceived Interaction Complexity (Version 1)
Figure 4.4 and Figure 4.5 allow us to perform the same visual comparison, such as in the previous
section. What we see indicates what has been shown in the high-level picture, both in terms of mean
and standard deviation. For example, in the blockchain-based solutions (Scenario 3), in Version 2 , the
data is very spread when compared inter-interaction but it seems to be much more concentrated for
each interaction than in Version 1.
32
Figure 4.5: Probability Density of Perceived Interaction Complexity (Version 2)
33
34
Chapter 5
Design and Architecture
We expose, in Chapter 1, that the purpose of this dissertation is to assess whether permissioned
blockchains can be a solution for decentralizing access control in the context of educational certificate
issuance, sharing and verification. We have taken a very small step towards that objective, by studying
how users perceive blockchain, both in terms of security and complexity. To build upon that, we design
and architect a system, which we implement in Chapter 6, to prove our hypothesis. After all, it will be
impossible to evaluate our initial research question if there are no artifacts, as per the DSRM, that we
can use to evaluate our proposed approach. We’ve envisioned this system being applied to an educa-
tional context, in which Universities, or Educational Institutions, are able to initially deploy a network of
nodes, as the blockchain genesis, that will be maintained and run by other nodes - Students - that join
and leave the network as time passes.
In this chapter, we describe the conceptual design and architecture behind our proposed system
-Blocked. Initially, we review the stakeholders that will interact with the system, in Section 5.1. Section
?? provides an overview of the solution. Section 5.3 explains the system’s technological architecture
that guided the implementation of the system and it relates to the context in which we are working.
This section establishes how the network, state and transaction architecture operate, as well as how to
perform control of access to information. Finally, Section 5.4 explains the functional architecture of the
system, by describing operations permitted in the system and how users are expected to interact with it.
5.1 Stakeholders
Blocked is designed to be used by the following stakeholders: students,institutions and a third entity
which we establish as being verifiers. According to the essence of our study, presented in Chapter 4,
where we present the same high-level stakeholders, with a verifier being the Recruiter. In this case,
students are stakeholders that will be issued certificates and that control access to those certificates.
Students are also expected to be an active part of the network, maintaining one node participating in
the network - e.g. being a peer. Ultimately, Students will also share the certificates for verification by
another entity - in our previous study the Recruiter.Institutions are the entities responsible for issuing
35
the certificates and, if needed, dealing with revocations of certificates. They are expected to only need to
interact with the students. At the same time, institutions are also participants in the existing network, as
we describe in Section 5.3.1. Finally, verifiers are the entities with which certificates are shared, by the
students, and whose role in the system is that they want to verify a given certificate, shared by another
stakeholder, exists and is truthful. These stakeholders are not required to participate in the validation
network since their role is fetching and visualizing information, but they are required to connect to the
network in order to perform verification.
5.2 Overview
Blocked has been designed to be a decentralized system for issuing, sharing and managing digital
education certificates thus decentralizing control of access to the information. The system relies on
a network of nodes (detailed in Section 5.3.1), which maintains the information coherent in every node
through consensus algorithms. Blocked relies on the nodes communicating between each other through
peer-to-peer mechanisms.
With Blocked, users are able to create new certificates and issue them on a permissioned blockchain.
After issuing a certificate, users are able to read information about those certificates, provided they have
the appropriate permissions. A certificate’s recipient is able to manage access to its own certificate,
through cryptography, so that it can share the certificate with third-parties. Those third-parties are then
able to view the certificate’s information until the access is revoked by the certificate’s owner. Both the
certificate’s owner and issuer are able to revoke the certificate but the certificate is forever stored, even
if revoked. Users viewing a certificate, after it has been revoked, will be able to clearly see that the
certificate is revoked.
The system can be summed up in 3 components: network, blockchain platform and clients. The
network is the layer responsible for the interaction between the several nodes, detailed further in Sec-
tion 5.3.1. The blockchain platform is the layer in which the information is stored. As we will see in
Section 5.3.2, Section 5.3.3 and Section 5.3.4, it is shared between the existing nodes participating
in the network, stores the state of the system, allows the modification of the system’s state and en-
forces embedded access control policies. The clients, in Blocked, are responsible for interacting with
the blockchain platform and are the component that users will interact with. These have been developed
following the interaction guidelines established in Section 5.4.
The components described previously are mapped into two architectural layers: (i) a technological
architecture, in which we cover networking and the blockchain platform; (ii) and a functional layer, in
which we cover the interaction guidelines respected by the implementation (detailed in Chapter 6).
5.3 Technological Architecture
In order to understand the technological architecture of the system, we explain the inner workings of the
network (Section 5.3.1), how state is maintained throughout the network (Section 5.3.2), how transac-
36
tions are defined, processed and validated (Section 5.3.3), and, finally, how the management of access
to information is performed (Section 5.3.4).
5.3.1 Network
In Blocked, each stakeholder is expected to be a node in the network, apart from the verifier, for a given
period of time. There are two reasons for this: (i) each node maintains its own copy of the global state of
the network, which means, at least, two nodes must exist at any given time; and (ii) in order to manage
certificates, one must be connected to the network. At the same time, each peer is both a producer -
issuing new transactions - and a validator - because it is a component of the validation network. The
network consists of a collection of nodes. The nodes interact with each other through a peer-to-peer
network and maintain the global state by using a consensus algorithm - namely, PoET [149].
Given that Blocked’s backbone is a blockchain, and given blockchain’s inherent decentralization, the
appropriate way for a stakeholder to access information on the blockchain is effectively to consult a copy
of the global state. There are two possible ways of doing this: either by consulting a copy through a
proxy (such as REST API pointing to a copy, on another node) or possessing a local copy of the global
state of the network on a stakeholder’s own node. The latter is the approach designed in Blocked. When
a stakeholder needs to access information on the network, it should connect a node to the network and
download a local copy of the state.
At the same time, considering that managing a certificate requires submitting transactions and
batches to the blockchain, to be processed by the validator nodes, a stakeholder that needs to mod-
ify the existing state of the network needs to be connected to the network. This justifies our second
statement that ”in order to manage certificates, one must be connected to the network”.
There are two levels to our network. Each node is necessarily a peer in the network but, due to
permissioning capabilities of the blockchain (detailed in Section 5.3.4), not necessarily a validator node
in the network. One might be able to connect to the network as a node, and read information from it, and
not be able to validate new blocks because it is not a participant on the validation network. The network
allows for information to be shared between all nodes and, at the same time, for nodes to validate on
new blocks universally.
5.3.2 State
We define state as the information stored in a particular address of the blockchain. The global state of
the system is the collection of all addresses currently maintained, with information, in the blockchain. The
global state in Blocked is represented through a Radix Merkle tree. It can be modified by the validator
nodes and each node maintains its own copy of the global state. Validator nodes are responsible for
ensuring that the global state is the same for all participants in the network. In Blocked, a state entry -
an address - consists of the properties listed in Table 5.1.
A state entry is stored at a particular address. An address uniquely identifies where information is
stored in the global state - i.e. in the Radix Merkle tree. By fetching for a particular address, a client is
37
Table 5.1: State Properties
Property Description
id Represents the identifier of a given educational certificate. A version 4 Univer-
sally Unique Identifier (UUID) generated for each certificate issuance.
certificate Represents an encrypted issued certificate and should include issuer,
recipient,issued at and active.
owners List of public keys that identify both the issuer and recipient of the certificate.
permissions List of subjects that are allowed access to read the information.
able to fetch a particular piece of information stored in the global state thus being able to read the bytes,
we will see in Section 5.3.4 how reading bytes is different from accessing the information. Addressing
then, in our use case, is the process of determining the address of a particular certificate - where its
information is stored. Addressing is done through a process that is deterministic and must respect the
following rules:
•An address consists of an hex-encoded string of 70 characters.
•An address must always start with ”49cb48”. This value represents the first 6 characters of an
SHA-512 hash of the string ”blocked” - the lowercase name of our system.
•Remaining 64 characters of an address must be the first 64 characters of an SHA-512 hash of the
certificate property id.
This addressing scheme enables a client node, and validator nodes, to always generate the correct
address for a given certificate, thus being able to access blockchain’s state at that address. Following
these rules is the only way of accessing the correct information for any given certificate.
5.3.3 Transactions and Batches
Transactions allow nodes to modify the global state of the system. These are submitted to the validator
nodes and processed. If valid, the state is modified. If invalid, the new blocks will be rejected. Trans-
actions are created by the clients in each node. In Blocked, transactions are wrapped in batches, with
each batch assumed to have one and only one transaction. Transactions in Blocked allow clients to
issue, share and revoke educational certificates. The structure of the transaction when it is being sub-
mitted is different from what has been presented in the global state, it is dependent on the operations,
presented in Section 5.4. Each transaction payload should include the operation it is trying to perform.
Allowed operations are issue,revoke,grant access and revoke access. Each transaction payload
should also include a data property, varying from operation to operation. When performing an issue,
a client should send the data with the same structure as the global state structure. When performing
revoke, a client should send an id and certificate inside data. When performing either grant access
or revoke access, a client should send the permission object to append or the identifier of the subject
whose permissions are to be removed.
38
5.3.4 Access Control
Controlling access to the information, in Blocked can be achieved in two separate layers. Due to the
permissioning nature of the system, we can configure which validator nodes are allowed to modify state
in the network. At the same time, there’s an access control mechanism above the network layer that
is used to guarantee that, even though each node has its own copy of the information, data cannot be
correctly read without the relevant permissions.
Network Permissioning
On validator nodes, we can define two separate levels of controlling modification to state: transactor-
level and validator-level. At the transactor-level, it is possible to control what public keys are allowed
to submit batches and transactions. This type of permissioning, allows control over what identities are
allowed to modify the state of the network, which can be relevant, for example, if a malicious node tries
to submit new malicious information to the system. The latter level of permissioning, at the validator-
level, allows the configuration of public keys as the only keys that are able to participate in the validation
network, therefore controlling the subjects that are able to perform consensus and validate blocks thus
modifying state. These permissioning capabilities are one of the key features of using a permissioned
blockchain, instead of a permissionless blockchain.
Cryptography-based Permissions
Apart from the network-based access control, the system supports some safeguards with regards to
protection of the information being stored in the network. Initially, when a certificate is submitted for
issuance, the certificate information is encrypted with a symmetric key. A new key is generated each
time a certificate is submitted and consists of 32 random bytes. This guarantees that the certificate is
already submitted in an encrypted state to the blockchain, avoiding a potential man-in-the-middle attack
(MITM), that would allow a third-party to read the information. At the same time, permissions to read
the information, stored in the blockchain, are created through encrypting the symmetric key with an
asymmetric public key, corresponding to the subject that shall be allowed access. A list of permissions
of this type is kept in the blockchain together with the encrypted information. This method effectively
avoids any access by any subject that is unable to decrypt the symmetric key and, therefore, unable to
decrypt the encrypted information, while at the same time avoiding that anyone with a copy of the state
reads the information.
5.4 Functional Architecture
In order to be able to use Blocked, a subject needs to comply with the minimum requirements for setting
up a node (Section 5.4.1) and be part of the network. The remaining sections describe the actions that
can be performed with Blocked.
39
5.4.1 Setting Up
For a user to use Blocked, it needs to have an identity. Identities are defined in two ways, both with
asymmetric cryptography: a DSA-based identity and an RSA-based identity. Digital Signature Algorithm
(DSA) [150] is used for signing the batches and transactions while RSA [151] is used for encryption of the
symmetric key. While RSA [151] can be used for both encryption and signing, DSA-based signatures
are supported by most blockchain platforms (such as Bitcoin and Ethereum) for signing batches and
transactions, which makes it easier for system implementation.
Users should generate their own keys before trying to join the network. They should generate an
ECDSA [152] key pair with secp256k1 [153], as the parameters of the elliptic curve, and store a hex-
adecimal representation of those keys, in order for them to be used with Blocked. The same should be
done for the RSA keys [151]. The users should generate an RSA [151] key pair according to PKCS#1
OAEP [154] and store those keys for future use in Blocked. After these steps are complete, users are
able to identify themselves within the system thus are in a position to start using it.
In order to run a network, one of the nodes, and only one should generate a genesis block for the
blockchain, as described at the beginning of this chapter. This means that, in broad terms, one of the
nodes would have to be responsible for starting the actual network. From that moment on, after other
nodes connect, that node will have the same relevance as the remaining nodes.
5.4.2 Issuing a Certificate
In Blocked, any user with permission is able to generate a new certificate. For the sake of simplicity, let
us call that user an issuer. The following steps should be executed:
1. The issuer should ask for, or the recipient should share, the public keys for both the RSA-based and
DSA-based identities. This will be needed to encrypt the information and identify who’s receiving
the certificate, and who’s issuing it.
2. The issuer should then proceed to generate and submit a transaction, wrapped in a batch, and
submit it to the network. The transaction should represent the issue operation.
3. The transaction is processed and one of the following outcomes should happen: (i) the transaction
is accepted and the state is updated or (ii) the transaction is rejected and the state remains the
same.
4. After that, the issuer should either communicate the identifier of the newly generated certificate to
the recipient. If the transaction was rejected, and the issuance cannot be completed, the recipient
should also be advised of that.
It is important to mention that the certificate, and consequently the state’s address, can solely be
identified through the identifier. If that information is lost, it will not be possible to recover the information,
unless through iterating all transactions and trying to decrypt all certificates, until the correct one is found.
40
5.4.3 Revoking a Certificate
Revoking a certificate can be accomplished by both the issuer or recipient of a certificate. Both have
control to revoke a given certificate. The following steps should be accomplished:
1. A transaction should be submitted to the network with the identifier of the certificate to revoke. The
transaction should represent the revoke operation.
2. The network validates that the transaction has been submitted by either the issuer or receiver of the
certificate and modifies the state, revoking the certificate. Otherwise, it will reject the transaction.
5.4.4 Granting/Revoking Access
One of the main purposes of Blocked is to enable the control of access to the certificates stored in
the network. Only the recipient of the certificate has the ability to control the access to certificates and
change it. To do that, the following steps should be executed.
Granting
1. The recipient should request, and the subject, to be granted access, should provide, both public
keys for the DSA-based and RSA-based identity.
2. The recipient will submit a new transaction to the network, containing the symmetric key encrypted
with the RSA public key shared by the subject. The transaction should represent the grant access
operation.
3. The network validates that the transaction is valid, including validating the transaction signer as
being the recipient, and modifies the state, appending the permission to existing permissions.
Otherwise, it will reject the transaction.
Revoking
1. The recipient will submit a new transaction to the network, with the DSA-based identity shared by
the subject, when the access was granted. The transaction should represent the revoke access
operation.
2. The network validates that the transaction is valid, including validating the transaction signer as
being the recipient, and modifies the state, removing the permission from existing permissions.
Otherwise, it will reject the transaction.
5.4.5 Viewing a Certificate
Contrary to what has been presented thus far, viewing a certificate does not require the submission
of a new transaction to the network. It is not enough to just look at the current state either because
the information is encrypted. For an actor to view information pertaining to a given certificate, it should
41
identify which address in the network stores the data for that certificate (through the certificate’s iden-
tifier). It should then proceed to decrypt the existing permissions’ list until it can decrypt one of those
permissions and obtain the symmetric key. With the symmetric key decrypted, the actor should decrypt
the certificate’s information and will be able to view the certificate. This operation will only be available
if access has been granted to that specific actor and is independent on the certificate being active or
revoked.
42
Chapter 6
Implementation
After introducing the conceptual design and architecture of Blocked, this chapter introduces an im-
plementation of the system. Section 6.1 discusses the main technological components used for the
implementation. Section 6.2 presents the internals of the implementation of Blocked. Finally, Section
6.3 shows how to perform the activities needed for this implementation.
6.1 Selected Technologies
6.1.1 Hyperledger Sawtooth
The basis of the implementation is Hyperledger Sawtooth. Hyperledger Sawtooth is an open-source
effort from The Linux Foundation [111], that introduces a modular platform for implementation of appli-
cations on top of permissioned distributed ledgers. We use it as the backbone of our implementation.
As explained earlier, our approach needs to have a permissioned blockchain, which needs to be cus-
tomized, to be suitable for our purposes. Hyperledger Sawtooth offers a complete set of tools to build
applications on top of a distributed ledger that include: REST API, a validation network infrastructure,
permissioning capabilities, events, a consensus protocol - PoET [149] - and, of course, a blockchain. To
connect all the pieces together it offers Software Development Kit (SDK), in a variety of languages such
as Go, Python or JavaScript, easing the development of the implementation.
6.1.2 Python
The implementation of Blocked has been developed with the Python [155] programming language.
Specifically, the implementation only supports Python 3. Python is a dynamically typed, general-purpose
programming language widely popular in software development. It has an established and mature com-
munity, with a lot of resources available. Furthermore, Hyperledger Sawtooth provides 3 mature SDK
- Python, Go [156] and JavaScript [157]. From those 3, only Python and Go had a mature Transaction
Processor API. With that in mind, Python gives us more flexibility during development, being interpreted
rather than compiled, while also providing us with a mature standard library, given it has almost 20 more
43
years of development when compared with Go.
6.1.3 Docker
Docker is a platform for container execution. Setting up all the components that are needed to run the
system can be complex. Hyperledger Sawtooth supports Docker files to help with configuration and
execution of all the components at the same time. We used Docker in order to run containers of the
Hyperledger Sawtooth infrastructure, in which we could execute our implementation against. This also
eases setting up because it doesn’t modify any part of the user’s system.
6.2 Implementation
We briefly describe the key components of our implementation. All code can be found on GitHub [158].
The several pieces of this implementation, together, fully implement what we propose with the Blocked
system, described previously.
Our implementation consists of two main Python packages: processor and blocked. Both are Python
packages, with several modules inside. Apart from that, a collection of executable scripts are provided,
with which one could use the packages thus interacting with the blockchain. The Transaction Processor
(Section 6.2.1) is the component executed together with the validation nodes. This component pro-
cesses and validates transactions and modifies the state of the network. Remaining sections cover the
several Python modules developed to perform the activities described in Chapter 5.
6.2.1 Transaction Processor
As previously explained, the Transaction Processor component connects to the validator running on the
user’s machine or running somewhere else. The component has two modules: main and handler.main
acts as an interface to start and stop the actual Transaction Processor, whose business logic is written in
handler. When running, Transaction Processor will start by verifying an operation has been submitted,
followed by determining the certificate address and fetching the existing certificate from state. It will then
process the transaction according to what operation has been requested and modify state accordingly,
if needed.
6.2.2 Certificate Issuer
The Certificate Issuer component is responsible for submitting a new transaction to the validator network.
This component can be found in cert issuer and can be executed by running the Python script in
bin/cert-issuer. To perform its responsibilities, the script receives the following parameters:
•Recipient: Recipient’s DSA Public Key.
•Secret: Issuer’s DSA Private key.
44
•Recipient RSA: Path to Recipient’s RSA Public Key.
•Issuer RSA: Path to Issuer’s RSA Public Key.
With these parameters, the Certificate Issuer will start by generating a new symmetric key to encrypt
the data, as well as a new certificate identifier. It will then proceed by generating the payload that will be
embedded in the transaction, and batch, to be submitted. It will submit the new transaction and print out
both the certificate’s identifier and where to check for the status of the transaction submission. A user
can now validate if the transaction has been accepted. After this point, a certificate with the provided
identifier has been generated.
6.2.3 Certificate Revoker
The Certificate Revoker component is responsible for executing the revocation protocol mentioned in
Chapter 5. This component is implemented in module cert revoker and can be executed by running
the script bin/cert-revoker. It can be executed by passing the following parameters, referencing the
actor who is executing it:
•Certificate: Identifier of the certificate to revoke.
•Secret DSA: DSA Private Key to validate blockchain identity.
•Secret RSA: RSA Private Key to decrypt the information.
The component starts its execution by fetching the relevant certificate from the blockchain. After
fetching the certificate, it attempts to decrypt the symmetric key, in order to be able to access the in-
formation. If the decryption fails, the component exits with an error. If the decryption is successful, the
component creates a payload with the same information but with the property active modified to False
- this indicates the certificate is revoked. After generating the new payload, a transaction, and batch, are
generated and submitted with the new information. Similarly to what happens with the Certificate Issuer,
it will print out where to check for the status of the transaction submission.
6.2.4 Certificate Access Manager
The Certificate Access Manager component is responsible for performing the activities of granting and
revoking access to a certificate by a particular subject. It can be executed by any user but the trans-
actions will solely be approved if signed by the certificate’s recipient. This component can be found in
access-manager and can be executed by running the Python script in bin/access-manager. To perform
its responsibilities, the script receives the following parameters:
•Certificate: Identifier of the certificate to revoke.
•Subject DSA: DSA Public Key of Subject.
•Subject RSA: RSA Public Key of Subject.
45
•Secret DSA: DSA Private Key to validate identity.
•Secret RSA: RSA Private Key to decrypt the information.
•Remove: If the action to perform is revoking access, instead of granting.
The component starts its execution by fetching the relevant certificate from the blockchain. After
fetching the certificate, it attempts to decrypt the symmetric key, in order to be able to access the in-
formation. If the decryption fails, the component exits with an error. If the decryption is successful, it
creates a payload with the access modification operation, submits a new transaction and batch, and
prints out where to check for the status of the transaction submission. If the transaction is accepted, the
permissions are updated, otherwise, they will stay the same.
6.2.5 Certificate Viewer
The Certificate Viewer component is responsible solely for displaying certificate information to the user,
depending on the correct decryption of the data. This component can be found in cert viewer and can
be executed by running the Python script in bin/cert-viewer. To perform its responsibilities, the script
receives the following parameters:
•Certificate: Identifier of the certificate to revoke.
•Secret DSA: DSA Private Key to validate identity.
•Secret RSA: RSA Private Key to decrypt the information.
The script works by determining the certificate’s address and fetching the certificate information,
followed by decrypting the symmetric key, through the RSA private key. If decryption fails, it will exit with
an error. If the decryption succeeds, it will proceed with decrypting the certificate information and print
out the following information:
•ID - Identifier of the Certificate;
•Issuer - DSA Public Key of Issuer;
•Recipient - DSA Public Key of Recipient;
•Issuance Date;
•Status - Whether the certificate is active or revoked.
6.2.6 Other Utilities
Apart from the core components, described above, we’ve implemented other utilities that are necessary
in order for the system to be functional. The package addressing, with its module addresser, is shared
throughout the other components and contains information about the transaction definition (see Chapter
5), such as: (i) family name to use with Hyperledger Sawtooth, (ii) family version that is currently being
46
used and (iii) prefix of the addressing scheme. It also contains a shared method for address generation,
which is used across components to determine the address for a given certificate. Furthermore, in the
module utils, we can find auxiliary methods for:
•submitting a batch (submit batch(data));
•fetching certificate information (fetch state(certificate address));
•creating batches (make batch(txn, signer));
•creating transactions (make transaction(payload, signer, inputs, outputs));
•encrypting and decrypting, with both AES and RSA.
6.3 Proof-of-Concept
We have described the design and architecture of Blocked (Chapter 5) and a matching implementation.
This section provides a proof-of-concept, that uses our implementation of the system to demonstrate its
applicability, in a real-world scenario. We review issuing a certificate (Section 6.3.1), viewing an existing
certificate (Section 6.3.2), revoking an existing certificate (Section 6.3.5) and managing permissions
for an existing certificate (Section 6.3.3 and Section 6.3.4). With this section, we aim at providing a
concrete example of the working Blocked implementation, as well as realize the initial idea proposed
by this thesis. All examples on this section have been run with a two-node network, running a PoET
algorithm on an SGX simulation.
6.3.1 Issuing a Certificate
As explained in Section 5.4, issuing a certificate can be achieved by completing 4 steps. Let us assume
that: (i) a network is already set up and (ii) public keys have been exchanged, such that the issuer knows
the public keys of the recipient.
We then proceed by executing the cert-issuer script in the Blocked system. This activity is repre-
sented in Listing 1. In this example, we submit a new transactions to the network to generate a certifi-
cate, with ID ”2136718e-d4cb-4cb2-b324-936444cf33bd”. The ”Status” element in the results refers to
an URL, where the user is able to check out whether the transaction has been accepted or rejected.
By accessing the URL that has been returned by running the script, we are able to confirm that the
transaction has been COMMITTED, which represents that the network accepted the transaction and the
new certificate has successfully been issued. We demonstrate this in Figure 6.1.
6.3.2 Viewing a Certificate
Furthermore, now that our certificate has been issued, we want to be able to see the contents of it. Let’s
assume we are now impersonating the recipient of the certificate. We would run the cert-viewer script
47
1$ ./cert-viewer --certificate 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
fff1224e60ee00f6580c3b303b7682f2af601b5180097216aeb18e15eff2e72c --sec,→
2ret-rsa ../keys/recipient.keys/rsa/recipient
3Generating Addresses...[OK]
4Fetching Data...[OK]
5Attempt 1...[Error]
6Attempt 2...[OK]
7
8ID: 2136718e-d4cb-4cb2-b324-936444cf33bd
9Issuer: 03112e85ea835a6f445c8195f99e64f9677127d12dabcdf43422c9f3cb52aeeb8f
10 Recipient: 03a1b6863f84cd6b17597e99a09d818a6cd992007136fceed9d3ad93fa7180d32c
11 Issued @ 2018-10-01 19:32:07.554541
12 Status: Active
Listing 1: Results of Executing cert-issuer.
Figure 6.1: Status of Transaction #1.
with our secret keys, in order to be able to view the certificate’s contents. We demonstrate this in Listing
2.
1$ ./cert-viewer --certificate 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
fff1224e60ee00f6580c3b303b7682f2af601b5180097216aeb18e15eff2e72c --secret-rsa
../keys/recipient.keys/rsa/recipient
,→
,→
2Generating Addresses...[OK]
3Fetching Data...[OK]
4Attempt 1...[Error]
5Attempt 2...[OK]
6
7ID: 2136718e-d4cb-4cb2-b324-936444cf33bd
8Issuer: 03112e85ea835a6f445c8195f99e64f9677127d12dabcdf43422c9f3cb52aeeb8f
9Recipient: 03a1b6863f84cd6b17597e99a09d818a6cd992007136fceed9d3ad93fa7180d32c
10 Issued @ 2018-10-01 19:32:07.554541
11 Status: Active
Listing 2: Results of Executing cert-viewer #1.
As we demonstrate in Listing 2, and present in Chapter 5, a user of Blocked, with the appropriate
permissions is able to see in full the contents of the certificate. In this case, since we are impersonating
the recipient of the certificate it only makes sense that we are able to view its contents. In the results,
Attempt 1 and Attempt 2 represent the attempts at decrypting the symmetric key with the RSA secret
key. No transaction is submitted in this activity such that there’s no need to make any validation within
the blockchain.
48
6.3.3 Granting Access
Let us now assume the following scenario: a recruiter approaches the recipient of the certificate, in the
hopes of hiring the recipient. The recruiter wishes to verify the qualifications that the recipient claims to
have. In that context, the recruiter will share the public keys, both for RSA and DSA, so that the recipient
can provide the recruiter with access to the certificate stored in the blockchain. We demonstrate the
results of this in Listing 3. We achieve the desired results by running the bin/access-manager script
with the appropriate parameters.
1$ ./access-manager -c 2136718e-d4cb-4cb2-b324-936444cf33bd --subject-dsa
036933186998989510747d4f75860e163f7e00454a33bef557ec0c96bd4b4ce389 --subject-rsa
../keys/recruiter.keys/rsa/recruiter.pub --secret-dsa
fff1224e60ee00f6580c3b303b7682f2af601b5180097216aeb18e15eff2e72c --secret-rsa
../keys/recipient.keys/rsa/recipient
,→
,→
,→
,→
2
3Generating Addresses...[OK]
4Fetching Data...[OK]
5Attempt 1...[Error]
6Attempt 2...[OK]
7Generating Payload...[OK]
8Creating Transaction...[OK]
9Creating Batch...[OK]
10 Submitting Request...[OK]
11
12 Status:
13 http://localhost:8008/batch_statuses?id=046d0e13fb5bacafbeed3b8b353e44d6b6a9f1c4a6e9210d934870dee6c5c228474
14 7fd62cb8035317bc98eb3a9b3067a8eb00558b5d6e69de7360494357a8bf3
Listing 3: Results of Granting Access with access-manager.
Similarly to what happens when issuing a certificate, the user must confirm that the transaction has
been accepted. We demonstrate this in Figure 6.2.
Figure 6.2: Status of Transaction #2.
After confirming that the permission has been granted, the recipient can now inform the recruiter
what certificate address it should query for - in this case, ”2136718e-d4cb-4cb2-b324-936444cf33bd”.
We demonstrate this in Listing 4, which uses the same components of the previous example, where we
viewed the contents of the certificate. It is interesting to confirm that the certificate in question has, now,
an additional iteration at decrypting the certificate - Attempt 3.
6.3.4 Revoking Access
Let us now assume that, for some reason, the recruiter shall no longer have access to this certificate.
The recipient is able to remove such permission from the certificate’s permission list. To do this, it must
49
1$ ./cert-viewer --certificate 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
964fb14dad3764286e0620710d02eaea59aa04529bde19447f6ad3d6485a773c --secret-rsa
../keys/recruiter.keys/rsa/recruiter
,→
,→
2Generating Addresses...[OK]
3Fetching Data...[OK]
4Attempt 1...[Error]
5Attempt 2...[Error]
6Attempt 3...[OK]
7
8ID: 2136718e-d4cb-4cb2-b324-936444cf33bd
9Issuer: 03112e85ea835a6f445c8195f99e64f9677127d12dabcdf43422c9f3cb52aeeb8f
10 Recipient: 03a1b6863f84cd6b17597e99a09d818a6cd992007136fceed9d3ad93fa7180d32c
11 Issued @ 2018-10-01 19:32:07.554541
12 Status: Active
Listing 4: Results of Executing cert-viewer #2.
submit a transaction through Blocked in order to remove the permission. We demonstrate this activity
in Listing 5, in which we run access-manager with the appropriate -r flag.
1$ ./access-manager -r -c 2136718e-d4cb-4cb2-b324-936444cf33bd --subject-dsa
036933186998989510747d4f75860e163f7e00454a33bef557ec0c96bd4b4ce389 --subject-rsa
../keys/recruiter.keys/rsa/recruiter.pub --secret-dsa
fff1224e60ee00f6580c3b303b7682f2af601b5180097216aeb18e15eff2e72c --secret-rsa ../keys/recipient
,→
,→
,→
2.keys/rsa/recipient
3
4Generating Addresses...[OK]
5Fetching Data...[OK]
6Attempt 1...[Error]
7Attempt 2...[OK]
8Generating Payload...[OK]
9Creating Transaction...[OK]
10 Creating Batch...[OK]
11 Submitting Request...[OK]
12
13 Status:
14 http://localhost:8008/batch_statuses?id=230706d8ad7897c563166ef3bf3853018bb4cf6f3e73dc5d681cbb227cf3644224d
15 e247aee8c8173126aa9bef1dc56e1abbbd0174d56d1080bc412f0573be4dc
Listing 5: Results of Revoking Access with access-manager.
As previously, the recipient can confirm the revocation of the access by checking, through a browser
that the transaction has been committed. We demonstrate this in Figure 6.3.
In this case, contrary to what occurs in Listing 4, if the recruiter tries to access the data after access
has been revoked, he will be met with an error. We demonstrate this in Listing 6. It is interesting to
note, once again, that the number of permissions has decreased, due to the revocation of the recruiter’s
permission.
50
Figure 6.3: Status of Transaction #3.
1$ ./cert-viewer --certificate 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
964fb14dad3764286e0620710d02eaea59aa04529bde19447f6ad3d6485a773c --secret-rsa
../keys/recruiter.keys/rsa/recruiter
,→
,→
2Generating Addresses...[OK]
3Fetching Data...[OK]
4Attempt 1...[Error]
5Attempt 2...[Error]
6error: you do not have permission to access this certificate
Listing 6: Results of Executing cert-viewer #2.
6.3.5 Revoking a Certificate
Finally, to conclude our proof-of-concept, let us imagine that the issuer wishes to revoke the certificate it
has granted to the recipient, due to, for example, a misconduct condemnation. The issuer would do this
by executing the cert-revoker script which would submit a transaction to the blockchain, revoking the
certificate. We demonstrate this in Listing 7.
1$ ./cert-revoker -c 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
396b644103a8fbdebcd17aff319e7b7fc60d879282b54a7a56d8ca53c61d3876 --secret-rsa
../keys/issuer.keys/rsa/issuer
,→
,→
2
3Generating Addresses...[OK]
4Fetching Data...[OK]
5Attempt 1...[OK]
6Generating Payload...[OK]
7Creating Transaction...[OK]
8Creating Batch...[OK]
9Submitting Request...[OK]
10
11 Status:
12 http://localhost:8008/batch_statuses?id=cbec918ba2b42601e8d8b25158bde676150ce4e0553897b5c21324f34200200b4c4
13 2f74c2a1833d96eae1401330f3406766b41eb950e61bc1aeb6e852c11d28b
Listing 7: Results of Executing cert-revoker.
As with the previous submission of transactions, the user should confirm that the transaction has
been committed, by accessing the returned URL. We demonstrate this in Figure 6.4.
Nonetheless, as explained previously, the certificate is not deleted. If the recipient wishes to view
the certificate’s contents, it would be able to. The only difference is that the certificate is now irrevo-
cably revoked and will display as such. We demonstrate this in Listing 8, produced by executing the
cert-viewer script, which displays the Status as ”Revoked”.
51
Figure 6.4: Status of Transaction #4.
1$ ./cert-viewer --certificate 2136718e-d4cb-4cb2-b324-936444cf33bd --secret-dsa
fff1224e60ee00f6580c3b303b7682f2af601b5180097216aeb18e15eff2e72c --secret-rsa
../keys/recipient.keys/rsa/recipient
,→
,→
2Generating Addresses...[OK]
3Fetching Data...[OK]
4Attempt 1...[Error]
5Attempt 2...[OK]
6
7ID: 2136718e-d4cb-4cb2-b324-936444cf33bd
8Issuer: 03112e85ea835a6f445c8195f99e64f9677127d12dabcdf43422c9f3cb52aeeb8f
9Recipient: 03a1b6863f84cd6b17597e99a09d818a6cd992007136fceed9d3ad93fa7180d32c
10 Issued @ 2018-10-01 19:32:07.554541
11 Status: Revoked
Listing 8: Results of Executing cert-viewer #3.
52
Chapter 7
Evaluation
This chapter provides an evaluation of the work developed in this thesis. Section 7.1 offers a discussion
of Blocked and compares it to existing systems, described in Chapter 2. Section 7.2 provides an analysis
of the outcomes of the study conducted throughout Chapter 4. Section 7.3 analyzes Blocked, as an
access control system, through the guidelines proposed by Hu et al. [143] for evaluation of access control
systems. Finally, Section 7.4 describes existing limitations on the research that has been conducted.
7.1 Discussion of Blocked
Blocked has been developed with the objective of being used for a single use case. Due to this fact,
some of its properties are specific to that use case. One such example is the way information is stored
inside the blockchain. Although it could easily be adapted and extended, at the moment, Blocked is
focused on the specific use case of issuing, sharing and managing access to educational certificates.
The single use case that has been tested, and described in Chapter 6, is that of issuing a certificate
to a recipient and that recipient sharing the certificate with a third-party. This differs slightly with what
has been proposed in BSCW, focusing on archiving the certificate in a tamper-proof fashion, rather than
on the sharing of those certificates, which is less clear and relies on the sharing of folders with PDF
documents, that can later be verified. It also differs from what is proposed with BlockCerts, which relies
on storing a hash of the certificate on the blockchain, rather than the certificate itself. With the certificate
having to be shared for verification against the hash that is stored in the Blockchain. At the same time,
BSCW also stores only a hash of the certificate with only a handful of properties on the blockchain. Both
these solutions end up coming short of storing the entire contents of the certificates on the blockchain
thus still relying on potentially centralized components for storage. In the end, both solutions end up
having to share documents with third-parties for verification, due to the fact that only a few properties
are stored in the blockchain, contrary to Blocked, potentially compromising the control of access to that
information.
Another aspect of both BlockCerts and BSCW that differs from Blocked is the supported blockchain
category. Both systems rely on permissionless blockchains - Bitcoin for BlockCerts and BSCW.Blocked
53
relies on a permissioned blockchain - Hyperledger Sawtooth, which is a crucial difference from those
projects. Permissioned blockchains are more suitable for organizational environments, such as our use
case. They offer the following advantages: (i) more flexibility in configuration; (ii) enhanced control
over the participants of the network - particularly, those with write permissions - enabling, for example,
that only students be allowed to write to the blockchain, while third-parties are only able to read; (iii)
monetary costs are reduced because, contrary to existing permissionless blockchains, there’s no cost
associated with issuing a certificate on the blockchain. Research on blockchain-based access control
[63] also relies on permissionless blockchains, suffering from the same issues. Existing systems do
not write sensible data on the blockchain but the fact that they don’t doesn’t enhance the security of
the information because a document will still need to be shared with the information, for third-parties.
Blocked overcomes this by encrypting the certificate information before storing it in the blockchain,
avoiding writing sensitive information. This can potentially be applied on permissionless blockchains as
well to allow storage of sensitive information in blockchains.
In terms of revocation capabilities, Blocked offers enhanced features, when compared with Block-
Certs and BSCW, by allowing for revocation to be initiated by both the issuer or the recipient and still
displaying the certificate information, even when revoked. BlockCerts only supports issuer-based revo-
cation while BSCW supports revocation but can’t display or use revoked certificates after revocation.
In terms of access control, Blocked achieves decentralized access control through cryptography and
ACLs. Certificate information is encrypted with symmetric encryption and then a list of permissions is
stored on the blockchain, through the form of an encrypted symmetric key. Whoever is on the list and
can decrypt the symmetric key, will have access to the certificate’s information. This solution is less
scalable than other access control mechanisms but solves the existing use case, for information that is
not meant to be shared with potentially hundreds of users and with policies that will not be changed with
high-frequency. Compared to Maesa et al. [63], our system is very unsophisticated because it does not
support ABAC or any of its standards, as pointed out in Section 7.3. This is potentially hindering in future
iterations of the concept. At the same time, BlockCerts does not provide any access control functionality,
while BSCW supports a degree of access control, through its document management system and smart
contracts, though it is unclear which mechanisms it uses - most of its information is publicly readable on
the blockchain and read-only. It is possible to control access of third-parties to verify a specific certificate
if a user has not shared that certificate but the information in the blockchain is still readable.
One aspect in which Blocked is weaker than its counterparts is in the structure of the information.
Although other systems don’t store much information on the blockchain, both handle certificates through
the Mozilla Open Badges specification [159]. This is a strength due to the fact that standardization is rel-
evant for the well-being of a decentralized ecosystem. Blocked’s structure has been created specifically
for this thesis.
In conclusion, while Blocked is still at a very early stage in its development, especially when com-
pared to BlockCerts and BSCW, which are more mature, it demonstrates a potential for a different
solution for decentralizing access control, on the case of issuing, sharing and managing educational
certificates. This exploration demonstrates that permissionless blockchains, with embedded access
54
control mechanisms, have the potential to provide a solution that will enable users to complete their
activities, with fewer monetary costs, enhanced privacy and security.
7.2 Study Takeaways
In Chapter 4, we present the results of research conducted through an online questionnaire focused on
the problem of assessing user’s perceptions of blockchain-based technologies. We have, in Chapter 4,
made an initial evaluation of the results, while answering the design questions that had been stated. It
is relevant, at this moment, that we evaluate the results of that component of this research as a whole
and integrated with the rest of the thesis. We discuss some of the research limitations in Section 7.4.
Throughout Chapter 4, we have focused on answering the questions that had been proposed as design
questions, ignoring how the results can be globally interpreted and effect a larger picture.
Our results allow us to infer that blockchain knowledge, at large, is still at a primitive stage. This situ-
ation is concerning for many of the potential applications of blockchain-based technologies (see Section
2.2), particularly due to the fact that most of our sample consisted of subjects integrated with technolog-
ical industries or roles. There’s an educational aspect, of users, that seems to be creating a knowledge
gap between those that work with blockchain-based technologies and those that will potentially use it.
From the standpoint of application developers, this knowledge gap might represent increased overhead
with user support and difficulty marketing application’s core functionality, apart from the fact that they
are based on blockchain-based technologies. After all, a blockchain is nothing but a single technolog-
ical component of a system, similar to how a database would be a component of a complete system.
Blockchains offer different features that must be understood in order to be used correctly and in order
to be usable. This aspect is also relevant when considering the development of systems relying on
blockchains because it suggests that, apart from supporting users in the usage of an application, users
must also be supported and educated into matters relevant to blockchains, in particular.
In terms of security, we have presented results that allow us to infer that users perceive applications
based on blockchains as more secure, when compared with other alternatives, such as databases. The
fact that users perceive blockchain-based technologies in this manner allows us to argue that they would
adopt applications and systems built for security or enhancing existing security systems, with blockchain.
Users considered a system with a blockchain more secure than other systems, considered, on average,
each interaction between entities more secure using a blockchain-based system than another system
and, finally, considered that the most secure scenario was the one where a blockchain-based system
was used. This represents a notion, from users, unequivocally for this sample, that blockchain-based
systems are more secure. Nonetheless, as some respondents outlined in questions that were open-
ended, the specifics of a solution, the context and the use case might not be particularly suitable for
using blockchain. Due to that fact, there will be cases in which, although potentially more secure,
blockchain usage might not be justified. In our research, we understand that the usage is justified.
Some of the respondents, in their open-ended questions, suggested that encrypting the information
would improve security, as well as allow for data to not be stored in plain text. We have included some
55
of those suggestions in our final artifact but there are still aspects to improve in terms of usability.
With any technology, there’s always a possibility that it will be perceived as complex, at an initial
stage. We have seen, from the responses to our questionnaire, that users perceive blockchain to be a
complex technology. This relates, possibly, to the education argument we have laid out in a previous
paragraph. If users have less knowledge of the technology, that will increase the potential of them
perceiving it as more complex. Nonetheless, this result represents a statement: that applications built
on top of blockchains should focus their efforts on explaining and marketing the application and not
the underlying technology. At the same time, it is remarkably important that developers consider this
situation to improve on the usability of their products, by removing as much complexity from it as possible.
A perception of complexity can be a hurdle in the adoption of a technology, or application, which means
it should be considered while developing those applications. We have tried to do that by removing as
much blockchain-related information from the applications users execute in Blocked, focusing instead
on the information related to the use case of the application. An example of that is removing the concept
of a user being associated with a specific blockchain address.
We have used this questionnaire throughout the design of our artifact. We have concluded that users
perceive applications based on blockchains as potentially more secure but more complex as well. This
has consequences for application development. It means that those applications must be tailored to be
particularly simple, possibly bypassing the mention of the underlying technology used, similar to what
we usually do with other application backbones, such as databases. We have aimed at focusing the
artifact’s scripts on the task at hand, not relying on having to explain blockchain technology to users but
rather using it solely as a technological component in our toolbox.
This study presents an overlap between several areas of research: Information Security, Blockchain,
Educational Certificates and Human Perception. We sought to explore how those interact by conduct-
ing an online questionnaire followed by a study that would shed some light over how users perceive
blockchain technology, in terms of security and complexity, in an Educational Certificate use case. The
results have indicated a tendency for users to perceive blockchain technology as more secure but, alas,
more complex too - at least in this particular domain. This research is a starting point to better under-
stand how humans perceive blockchain technology.
7.3 Access Control Evaluation
In this section, we evaluate our system through the metrics proposed in [143] which is a continuation
of what has been presented in [67]. Leveraging these metrics allows us to have an understanding of
what the access control system is capable of executing, against some known organizational metrics. An
example of the usage of these metrics in other research pertaining to access control exists [160], which
further supports our usage of these metrics to evaluate the access control system. As Hu et al. [143]
establish, ”the quality metric should be evaluated based on the specific needs for the AC policy” [143,
p. 25]. In our context, what this means is that rather than evaluating every single metric, with several
of them being clearly inadequate, we should evaluate the subset of policies that seem adequate to our
56
use case. We have provided a summary of all the metrics we are evaluating in Table 7.1. Questions in
4.1.7 and 4.1.9, in Table 7.1, have been rephrased to aggregate the existing section’s questions into one
question.
Table 7.1: Quality Metrics for Evaluation
Section Metric Items
Administration Properties
4.1.1 •Does the AC system log denied access requests?
•Does the AC system log granted access requests?
4.1.2 •Does the system provide query/display for privileges discovery?
•Does the system provide graphic display?
4.1.3 •How many steps are required for assigning a privilege?
•How many steps are required for removing a privilege?
4.1.4 •Is the AC system capable of logical expression for rule specification?
4.1.5 •Does the AC system allow policy expiration assignment?
•Does the AC system provide policy deployment or activation verification?
•Does the AC system allow runtime policy rule change?
4.1.7 •How is the AC enforced?
4.1.8 •Does the AC system support multiple hosts via network?
4.1.9 •What is the scope of data control?
Enforcement Properties
4.2.2 •Is the AC system capable of bypassing policy rules for critical AC decisions?
4.2.3 •Is the AC system capable of enforcing the least privilege principle?
4.2.4 •Is the AC system capable of specifying Static SoD rules?
4.2.5 •Does the AC system provide safety check capabilities to prevent leaking of permissions?
4.2.6 •Does the AC system allow configuring the granularity of controlled objects?
4.2.7 •Does the AC system support existing AC standards?
Performance Properties
4.3.1 •Does the response time of granting an access request meet the organization’s requirement?
4.3.2 •Does the AC policy retrieval and deposit meet the organization’s requirements?
4.3.3 •Does the AC system provide an AC policy distribution mechanism?
4.3.4 •Can the AC system be integrated with or support identification authentication systems?
Support Properties
4.4.2 •Is the AC system capable of supporting a different OS beside the one used by the intended host(s)?
4.4.4 •Does the AC system provide a GUI or an API for AC policy management and authoring?
7.3.1 Administration Properties
Blocked audits the granting of access through the processing that happens inside the Transaction Pro-
cessor. If the transactions submitted are approved, these are then stored in the blockchain. If, in turn,
the transactions are rejected, the nodes will have a log that a given transaction has been rejected, along
57
with the reason. This occurs because each node will process the transaction thus storing whether the
transaction has been rejected. At the same time, each client performs the needed validations for ac-
cessing a certificate, which means that denied read accesses won’t be logged anywhere, except on the
client node’s system.
The auditing that gets stored is only per transaction, apart from all the information that can be stored
in a transaction (such as allowing or revoking a given access), there are no more logs available. In terms
of permissions’ querying, users can query permissions only by iterating the blockchain. The system
does not provide a way of querying permissions, neither from a terminal or GUI. Users may only iterate
the transaction log, through the REST API, and reconstruct what permissions have been granted and
revoked, reaching a final state of what permissions exist at a given point in time.
Assigning or removing a privilege is possible by executing the respective Python script, as described
in Chapter 6. In both cases - assigning and removing - it takes only one step to execute, apart from
knowing the public identity of whoever is related to the permission. Nonetheless, updating a permission
is impossible.
The system does not support the specification of AC rules nor can’t it handle any rule specification
logic - such as AND and OR. Nonetheless, this situation doesn’t appear as a weakness, due to the fact
that, in the context we have described, the system has been designed, and implemented, to be used
in a 1-to-1 basis. What this means is the system is implemented to deal with a given subject allowing
another subject access to reading specific information. In this situation, not being able to support the
specification of rules or handle any rule specification logic, doesn’t seem to be something that is relevant.
Blocked does not for policy expiration assignment, by which a subject would cease to have permis-
sions to a given object by the expiration of the policy. This feature would be useful in our context which
makes it relevant enough to be considered a weakness, that could be improved in future time. It does
allow for target assignments, given that the default policy is directly assigned to a given target - although
there’s no other way of executing policy assignment unless targeting a specific subject. Blocked al-
lows for runtime policy changes, in the sense that it allows a permission to be revoked during runtime.
For example, policies can change interactively while the nodes are running the validation network and,
immediately before, a user queries for the information on a certificate.
In Blocked, the access control is enforced via a combination of application logic, consensus protocols
and cryptography - as described in Chapter 5. For viewing a certificate, a subject will need to possess the
appropriate RSA secret key, otherwise, it won’t be able to decrypt the data. For granting a permission, a
subject also needs to have appropriate secret keys but, at the same time, needs to be either the issuer
or recipient of a given certificate, otherwise, the transaction will be rejected by the Transaction Processor
running in the nodes. Given that we are decentralizing access control, it makes sense to not have all
enforcement as application logic. The reliance on consensus protocols is crucial, in order to maintain
the integrity of the access. If all access control were to be enforced at the application logic, there would
be no authority to validate a node’s claim of being granted access to a specific subject.
The system supports an array of hosts, theoretically with a high dimension of availability, each running
its own Transaction Processor, that will connect via the network. Each node will have a copy of the entire
58
blockchain, which makes it functional when the node is a party to validation of transactions and when it
is not a party to that.
The system covers application data that is stored inside a blockchain. In a way, the system protects
structured or unstructured information that is stored, encrypted, on a blockchain. The use case is that
of educational certificates but it would not be hard to extend or adapt, that information to being related
to a different use case.
7.3.2 Enforcement Properties
In Blocked, it is currently theoretically possible to bypass the system by changing the code of the Trans-
action Processor and running a changed version on the network. Nonetheless, it would still have to
bypass the consensus of the network because it would need to emit new policies - there’s no way of by-
passing the existing policies. This is difficult because several Transaction Processors running different
versions of the code would result in rejected transactions. So, in practice, it is not possible to bypass the
AC system for crucial decisions. On the viewer, it would be extremely hard to bypass the system due to
the fact that all the data is encrypted and secret keys, only known to the subjects, would be needed to
decrypt that information. Nonetheless, possessing those keys would allow a user to bypass the system.
Every subject is considered as having no access unless it can decrypt one of the permissions, which
means they have been granted access to that certificate. Granting access to a certificate grants access
to only that certificate and no other on the system. At the same time, decryption of a certificate’s sym-
metric key will prove useless when decrypting any other certificate, due to the fact that every certificate
is encrypted with a different, randomly generated, key. The same argument can be made for Separation
of Duty (SoD). Given that, in our model, subjects are given access only to certificates they are working
with, in this case, verifying, confirming that ”object accesses are only permitted to the subjects that are
duty -related to the objects” [143, p. 17].
There’s a universal constraint on the system that enforces that only subjects that have the secret
keys, corresponding to the public keys, that were granted access to can access the information. This
prevents leakage of permissions. In case a secret key is compromised, that permission should be
revoked during runtime. At the same time, in the blockchain, no information is stored in plain-text which
prevents the leakage of information through inspecting the blockchain.
The system granularity is statically configured to the certificate object, it doesn’t support any other
granularity. It would be a strength if, for example, recipients of several certificates were able to configure
permissions for those certificate at a different granularity level.
Since the system was designed and implemented, for a very specific use case, and is still at a
prototype stage, there’s no support for existing access control standards. These would have introduced
complexity throughout the design and development that would have diverged those activities from their
initial goals, as well as implementation overhead.
59
7.3.3 Performance Properties
We have not assessed response times, policy retrieval and deposit, experimentally. In Blocked, policies
are distributed through a peer-to-peer communication between the nodes. After each node has validated
the transaction, and the transaction is deemed valid, the data is updated accordingly in its copy of the
blockchain. Lastly, authentication is performed on the basis of public key cryptography, through the use
of public keys as identities. Currently, Blocked doesn’t integrate or support any other authentication
systems.
7.3.4 Support Properties
The system supports only Ubuntu 18.04 LTS. Given that the system relies on the usage of Docker and
Python - tools compatible with other operating systems - it seems trivial to extend support for those sys-
tems. Nonetheless, extensive OS compatibility tests have not been conducted thus support is not guar-
anteed. It would be important to perform this testing and needed modifications as it would strengthen
the artifact.
In Blocked, usage is performed through command-line interfaces, for each of the existing scripts.
Hyperledger Sawtooth also provides us with a REST API that can be used to query the underlying
blockchain. Nonetheless, there’s no GUI or API to perform policy management. These would be relevant
improvements to consider in Blocked. It would also be interesting to consider developing a GUI to
perform other activities, such as viewing information pertaining to a certificate.
7.4 Research Limitations
In this section, we discuss relevant research limitations in the work presented. We discuss those lim-
itations on 3 specific topics: limitations of the study, described in Chapter 4; limitations of the design
and architecture of Blocked, described in Chapter 5; and limitations of the implementation of Blocked,
described in Chapter 6.
7.4.1 Limitations of Study
It is important to note that this is a small sample, less than 50 respondents. This situation can give rise
to erroneous results due to a biased sampling. At the same time, although we have some diversity, we
would like to decrease the volume of one specific field when compared to others and gather a more
diverse collection of respondents. This limitation can be overcome by reproducing the questionnaire on
larger, more diverse samples. The fact that the subjects we are studying eschew heavily towards a more
technically-driven professional area is also a reason for concern because it doesn’t allow for analyzing
conclusive tendencies without future studies. We aimed at reaching a bigger, more diverse sample, by
speaking with subjects from different backgrounds, and publicizing the questionnaire in non-technical
60
venues, alas we weren’t as successful. At the same time, this is an exploratory study on the subject and
we see this sample as being strong enough to validate the potential for further studies in this area.
We would also like to leave a note regarding the possibility of a learning bias. Although we have
shuffled our scenarios, we have only done that with 2 out of the 3 scenarios. In the questionnaires that
were presented, the Blockchain scenario always appeared as the last scenario to be analyzed. This
creates a situation in which the results are not sustainable without future studies. In order to be able to
get more conclusive data, it would be important to perform different studies where more shuffling was
involved, particularly with anything involving blockchain - which we have kept in the last position, in both
versions. More shuffling can either mean: (i) more options with a randomized sequence; (ii) repeating
this questionnaire with just varying the last scenario and using it at the beginning, for example. It is
worth noting, nonetheless, that this situation was an attempt at an equilibrium. Given that the study
consisted of 3 scenarios, we had 6 possible permutations to decide on a sequence. With 2 versions only
we were maximizing the distribution by allowing for a greater number of respondents to answer each
version. Had we used 6 different versions, with the same number of respondents, we would have had
less 8 respondents for each version, which is definitively low. This way we were able to gather a more
significant number of answers for each version.
Finally, the platform used for the questionnaire had two limitations: (i) a back button, which allowed
respondents to rewrite their answers; (ii) the impossibility to present the images of the interactions along
with the questions - which might increase the confusion in respondents, by having to memorize the
images. This isn’t necessarily an issue with the study itself but it is rather a technological limitation we
faced that we would rather correct in future studies.
7.4.2 Limitations of Design and Architecture
The technological architecture, presented in Chapter 5, is highly coupled with the existing implementa-
tion, presented in Chapter 6, based on Hyperledger Sawtooth. We have extensively used the term peer
when representing a node in the network, have never mentioned the term mining, which is common in
other blockchain-based designs, relying on different platforms, and we have used the concept of state, in
the network, in a similar way to what Hyperledger Sawtooth presents. The chosen addressing schemes
and cryptographic schemes are also tightly coupled with what Hyperledger Sawtooth currently supports.
This presents a limitation because it might prevent the implementation of the system under different
platforms, losing flexibility.
The underlying consensus algorithm - PoET - needs deeper evaluation and can be a limitation for
the entire system. PoET is a fairly recent consensus protocol, which has been in development by Intel
since 2015 and is currently only used on a reduced amount of projects. An early evaluation of the
algorithm has found some vulnerabilities that can be mitigated [161] but further studies need to be
conducted. PoET is designed to achieve consensus efficiently, consuming less electricity, ”using new
secure CPU instructions which are becoming widely available in consumer and enterprise processors”
[149]. In theory, this consensus mechanism would be more suitable for organizational environments.
61
Nonetheless, if the algorithm is found to be irrevocably insecure or inefficient, with further evaluation, it
won’t be able to support the systems relying on it.
In the system’s state, a property named owners has the public identities of both the issuer and recip-
ient of a certificate. This property allows anyone, looking at the information directly on the blockchain, to
know who is the issuer and recipient, albeit not knowing which is which. This component exists to allow
the validator nodes to process requests for access control management, identifying whom the recipi-
ent is and validating it can submit those operations. Since validation nodes do not have access to the
encrypted information, inside the certificate, this component provides that information without encryp-
tion. This is a limitation because it exposes some information, instead of having every bit of information
concealed, which would be the ideal situation.
7.4.3 Limitations of Implementation
At this moment, the implementation doesn’t provide a complete package that a user can execute in one
step. Users need to set up the Docker environment, as well as have Python installed on their machine, so
they can run a node and interact with the network. At the same time, existing Docker configurations don’t
allow users to point at specific peers which would force users to modify the images for each network they
want to participate in. This is a usability issue for users. A more integrated environment, that requires
less technical operations to be able to use the system would help increase adoption. Since it is still an
exploratory implementation, the activities described are still being performed through a command-line
Python script, visualization of the blockchain, results of the operations and current state are all still very
rudimentary, with potential improvements both in user experience, as well as performance. Another
limitation is the management of key pairings. At the moment, there’s a need to use two sets of keys, a
DSA-based key pair and an RSA-based key pair. This is cumbersome to do, especially since there are
no auxiliary tools that would help a user achieve this.
62
Chapter 8
Conclusions
We explored whether usage of permissioned blockchain would provide a solution for decentralization
of access control, in the context of issuing, sharing and managing digital Educational Certificates. This
problem emerges from the intersection of an increasingly distributed technological landscape, an in-
crease in the quantity of digital information produced, the increase in the adoption of MOOC-based
learning and the lack of tools for practical issuance and verification of those learning certificates. Pre-
vious research had provided options that are either not entirely decentralized, required complex Public
Key Infrastructure (PKI) to use, lack integration with permissioned blockchains or are missing access
control functionality, that allows users to control who accesses what information. We have sought, with
this research, to explore whether building a system on top of a permissioned blockchain would allow us
to provide those guarantees of decentralization.
We have started by performing a statistical study in order to assess how users perceive blockchain-
based technologies, in terms of security and complexity, and applications built on top of those, in order to
assess the adoption that our proposed approach could potentially have. At the same time, we used that
questionnaire to try and guide the design and architecture of the system that has been proposed. This
initial step, guided by our choice of using DSRM, as our research methodology, allowed us to cautiously
conclude that our proposed solution has potential in terms of user’s adoption and is a small step towards
resolving the presented issues.
With that in mind, we designed a system Blocked, based on the concept of permissioned blockchains,
to issue, share and manage Educational Certificates. This system relies on a permissioned blockchain
platform, specifically Hyperledger Sawtooth, and cryptography-based permissions to allow decentraliza-
tion of policy distribution, maintaining integrity and privacy of information stored inside the blockchain.
Blocked has been developed to be used on a peer-to-peer network, where each node might be re-
sponsible for validating the current state of the blockchain. Apart from cryptography-based permissions,
Blocked also allows for configuration of permissions at the network level, based on the identities of the
nodes participating in the network, which is especially suitable from an organizational perspective.
Finally, we have proved our concept by implementing the proposed design and running a simulation.
We have also described how the implemented system fits in with the responsibilities of an access control
63
system. This system is not meant to be a replacement for existing solutions (such as BlockCerts) but
rather it is meant to show an alternative way of solving the decentralization system, that is more suitable
for specific use cases. We have also evaluated how the results of our exploratory statistical study
describe potential impacts on the future study of blockchain-based research.
8.1 Contributions
According to what has been described previously, our stated goal of exploring decentralization of ac-
cess control through the usage of permissioned blockchains, this thesis produced an artifact in order to
resolve that issue.
Our main contribution is the Blocked system design, architecture and implementation, along with a
proof-of-concept. This contribution, along with its evaluation, demonstrates that there’s a real potential
in using permissioned blockchains for decentralizing access control, in the context of issuing, sharing
and managing Educational Certificates.
A minor contribution, that was intrinsically connected with our major contribution, was the statistical
study performed, in order to assess users’ perceptions of blockchain-based technologies, in terms of
security and complexity. The results have indicated a tendency for users to perceive blockchain technol-
ogy as more secure but, alas, more complex too. We have evaluated the potential of these findings, in
developing future applications relying on blockchains, during this thesis.
8.2 Future Research
The contributions described in this thesis can be extended, or adapted, in different directions through
future research. We have explored some of the limitations of this thesis, in a previous chapter, and
those limitations are a guide to some of the directions in which this research could be extended. All of
these extensions should, nonetheless, be focused on improving the applicability of these contributions
to real-world scenarios and applications, rather than simulations.
It would be interesting to expand on the results of the statistical study described in this thesis. This
extensions should have 3 major focuses: increasing the number and diversity of participants; exper-
imenting with different versions of questionnaires, to rule out a learning bias in the results; and use
different platforms and methodologies (such as interviews instead of questionnaires) to (i) reproduce the
results and (ii) gain a deeper understanding of user’s perceptions on these topics. This would allow us
to improve on the development workflows used to build blockchain-based applications.
Another interesting extension would be to refine the design and architecture of Blocked. This should
be done in different ways, overcoming the limitations described previously: further evaluating the PoET
consensus algorithm; developing a more generalized system that would be decoupled from Hyperledger
Sawtooth, being able to support other permissioned blockchain platforms; and improving on some of the
aspects of privacy mentioned in the limitations.
64
Finally, improving the overall implementation provided in this thesis. This can be done by providing
packaged solutions for ease of use, providing a GUI and improving the usability of the artifact. At the
same time, more experiments need to be done with different network configuration, different testbeds
and real-world simulations, in order to continuously assess the performance of the system.
These suggestions of extensions are meant to focus future research on improving the existing proto-
type proof-of-concept implementation and design into a real-world production application that can have
a practical impact on the problem we set out to explore.
65
66
Bibliography
[1] B. Debatin, J. P. Lovejoy, A.-K. Horn, and B. N. Hughes, “Facebook and Online Privacy: Attitudes,
Behaviors, and Unintended Consequences”, en, Journal of Computer-Mediated Communication,
vol. 15, no. 1, pp. 83–108, 2009, ISSN: 10836101, 10836101. DOI:10.1111/j.1083-6101.2009.
01494.x.
[2] B. C. F. Choi, Z. Jiang, B. Xiao, and S. S. Kim, “Embarrassing Exposures in Online Social Net-
works: An Integrated Perspective of Privacy Invasion and Relationship Bonding”, en, Informa-
tion Systems Research, vol. 26, no. 4, pp. 675–694, 2015, ISSN: 1047-7047, 1526-5536. DOI:
10.1287/isre.2015.0602.
[3] K. Shilton, “Four Billion Little Brothers?: Privacy, Mobile Phones, and Ubiquitous Data Collection”,
Queue, vol. 7, no. 7, 40:40–40:47, 2009, ISSN: 1542-7730. DOI:10.1145/1594204.1597790.
[4] S. Gibbs. (Jul. 2014). Facebook apologises for psychological experiments on users, [Online].
Available: https://www.theguardian.com/technology/2014/jul/02/facebook-apologises-
psychological-experiments-on-users (visited on 10/04/2018).
[5] V. Ivashina and D. Scharfstein, “Bank lending during the financial crisis of 2008”, Journal of
Financial Economics, vol. 97, no. 3, pp. 319–338, 2010, IS SN: 0304-405X. DOI:https:// doi.
org/10.1016/j.jfineco.2009.12.001.
[6] A. Marthews and C. E. Tucker, “Government Surveillance and Internet Search Behavior”, en,
Social Science Research Network, Rochester, NY, SSRN Scholarly Paper ID 2412564, Feb.
2017.
[7] M. Hilbert and P. Lopez, “The World’s Technological Capacity to Store, Communicate, and Com-
pute Information”, en, Science, vol. 332, no. 6025, pp. 60–65, Apr. 2011, ISS N: 0036-8075, 1095-
9203. DOI:10.1126/science.1200970.
[8] A. R. Lee, S.-M. Son, and K. K. Kim, “Information and communication technology overload and
social networking service fatigue: A stress perspective”, Computers in Human Behavior, vol. 55,
pp. 51–61, 2016. DOI:10.1016/j.chb.2015.08.011.
[9] S. Vosoughi, D. Roy, and S. Aral, “The spread of true and false news online”, Science, vol. 359,
no. 6380, pp. 1146–1151, 2018, ISS N: 0036-8075. DOI:10.1126/science.aap9559.
67
[10] S. Lam. (Oct. 2017). How blockchain can stamp out china’s fake diplomas, [Online]. Available:
https://www.forbes.com/sites/lamsharon/2017/10/08/how-blockchain-can- stamp- out-
chinas-fake-diplomas/#76a036746854 (visited on 10/12/2018).
[11] C. Turner. (Apr. 2017). Dozens of fake degree certificate websites shut down amid crack down
on bogus awards, [Online]. Available: https://www. telegraph .co.uk/education / 2017 /01/
03 / dozens - fake - degree - certificate - websites - shut - amid - crack - bogus/ (visited on
09/22/2018).
[12] RealisticDiplomas. (2018), [Online]. Available: http://www.realisticdiplomas.com/.
[13] DiplomaCompany. (2017), [Online]. Available: https://www.diplomacompany.com/.
[14] T. Doctoroff. (Aug. 2010). Tang jun’s drama: A chinese business tragedy, [Online]. Available:
https://www.huffingtonpost.com/tom-doctoroff/tang-juns-drama-a-quintes_b_682093.
html.
[15] P. R ¨
osler, C. Mainka, and J. Schwenk, “More is Less: On the End-to-End Security of Group Chats
in Signal, WhatsApp, and Threema”, Tech. Rep. 713, 2017.
[16] B. Edwards, S. Hofmeyr, and S. Forrest, “Hype and heavy tails: A closer look at data breaches”,
en, Journal of Cybersecurity, vol. 2, no. 1, pp. 3–14, 2016, ISSN: 2057-2085, 2057-2093. DOI:
10.1093/cybsec/tyw003.
[17] B. W. Lampson, “Protection”, SIGOPS Oper. Syst. Rev., vol. 8, no. 1, pp. 18–24, 1974, ISSN:
0163-5980. DOI:10.1145/775265.775268.
[18] G. S. Graham and P. J. Denning, “Protection: Principles and Practice”, in Proceedings of the May
16-18, 1972, Spring Joint Computer Conference, ser. AFIPS ’72 (Spring), New York, NY, USA:
ACM, 1972, pp. 417–429. DOI:10.1145/1478873.1478928.
[19] M. A. Harrison, W. L. Ruzzo, and J. D. Ullman, “Protection in Operating Systems”, Commun.
ACM, vol. 19, no. 8, pp. 461–471, 1976, ISSN: 0001-0782. DOI:10.1145/360303.360333.
[20] C. Weissman, “Security Controls in the ADEPT-50 Time-sharing System”, in Proceedings of the
November 18-20, 1969, Fall Joint Computer Conference, ser. AFIPS ’69 (Fall), New York, NY,
USA: ACM, 1969, pp. 119–133. DOI:10.1145/1478559.1478574.
[21] E. I. Organick, The Multics System: An Examination of Its Structure. Cambridge, MA, USA: MIT
Press, 1972, ISBN: 0-262-15012-3.
[22] M. Satyanarayanan, “Integrating Security in a Large Distributed System”, ACM Trans. Comput.
Syst., vol. 7, no. 3, pp. 247–280, 1989, I SS N: 0734-2071. DOI:10.1145/65000.65002.
[23] K. J. Biba, “Integrity Considerations for Secure Computer Systems”, Mitre Corporation, Bedford,
Massachusetts, Tech. Rep. 3153, 1977.
[24] D. E. Bell and L. J. LaPadula, “Secure Computer Systems: Mathematical Foundations”, Mitre
Corporation, Bedford, Massachusetts, Tech. Rep. 2547, 1973.
68
[25] D. E. Denning, “A Lattice Model of Secure Information Flow”, Commun. ACM, vol. 19, no. 5,
pp. 236–243, 1976, ISSN: 0001-0782. DOI:10.1145/360051.360056.
[26] R. S. Sandhu, “Lattice-Based Access Control Models”, Computer, vol. 26, no. 11, pp. 9–19, 1993,
ISSN: 0018-9162. DOI:10.1109/2.241422.
[27] ——, “The Typed Access Matrix Model”, in Proceedings of the 1992 IEEE Symposium on Security
and Privacy, ser. SP ’92, Washington, DC, USA: IEEE Computer Society, 1992, pp. 122–, ISBN:
0-8186-2825-1.
[28] D. Ferraiolo and R. Kuhn, “Role-based Access Controls”, in Proceedings of 15th NIST-NCSC
national Computer Security Conference, Baltimore, Maryland, United States, 1992, pp. 554–563.
[29] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman, “Role-Based Access Control
Models”, Computer, vol. 29, no. 2, pp. 38–47, 1996, ISSN: 0018-9162. DOI:10.1109/2.485845.
[30] E. Bertino, P. A. Bonatti, and E. Ferrari, “TRBAC: A Temporal Role-based Access Control Model”,
in Proceedings of the Fifth ACM Workshop on Role-based Access Control, ser. RBAC ’00, New
York, NY, USA: ACM, 2000, pp. 21–30, ISBN: 1-58113-259-X. DOI:10.1145/344287.344298.
[31] S. Chakraborty and I. Ray, “TrustBAC: Integrating Trust Relationships into the RBAC Model for
Access Control in Open Systems”, in Proceedings of the Eleventh ACM Symposium on Access
Control Models and Technologies, ser. SACMAT ’06, New York, NY, USA: ACM, 2006, pp. 49–58,
IS BN: 1-59593-353-0. DOI:10.1145/1133058.1133067.
[32] J. B. D. Joshi, E. Bertino, U. Latif, and A. Ghafoor, “A Generalized Temporal Role-Based Access
Control Model”, IEEE Trans. on Knowl. and Data Eng., vol. 17, no. 1, pp. 4–23, 2005, ISSN:
1041-4347. DOI:10.1109/TKDE.2005.1.
[33] I. Ray, M. Kumar, and L. Yu, “LRBAC: A Location-Aware Role-Based Access Control Model”, in
Information Systems Security, A. Bagchi and V. Atluri, Eds., Berlin, Heidelberg: Springer Berlin
Heidelberg, 2006, pp. 147–161, ISBN: 978-3-540-68963-8.
[34] R. K. Thomas, “Team-based Access Control (TMAC): A Primitive for Applying Role-based Ac-
cess Controls in Collaborative Environments”, in Proceedings of the Second ACM Workshop on
Role-based Access Control, ser. RBAC ’97, New York, NY, USA: ACM, 1997, pp. 13–19, IS BN:
0-89791-985-8. DOI:10.1145/266741.266748.
[35] J. Barkley, A. Cincotta, D. Ferraiolo, S. Gavrila, and D. R. Kuhn, “Role based access control for
the world wide web”, in 20th National Computer Security Conference, 1997, pp. 331–340.
[36] S. I. Gavrila and J. F. Barkley, “Formal specification for role based access control user/role and
role/role relationship management”, en, ACM Press, 1998, pp. 81–90, ISB N: 978-1-58113-113-0.
DOI:10.1145/286884.286902.
[37] J. S. Park and R. Sandhu, “RBAC on the Web by Smart Certificates”, in Proceedings of the Fourth
ACM Workshop on Role-based Access Control, ser. RBAC ’99, New York, NY, USA: ACM, 1999,
pp. 1–9, ISBN: 1-58113-180-1. DOI:10.1145/319171.319172.
69