global permission derivation chain granting and …
TRANSCRIPT
The Pennsylvania State University
The Graduate School
GLOBAL PERMISSION DERIVATION CHAIN
GRANTING AND REVOKING PERMISSIONS USING A DISTRIBUTED LEDGER
A Thesis in
Computer Science and Engineering
by
Michael H Steward Jr.
Submitted in Partial Fulfillment
of the Requirements
for the Degree of
Master of Science
May 2020
The thesis of Michael H Steward Jr. was reviewed and approved* by the following:
Trent Jaeger
Professor of Computer Science and Engineering
Thesis Adviser
Gang Tan
Associate Professor of Computer Science and Engineering
Chitaranjan Das
Distinguished Professor of Computer Science and Engineering
Department Head of Computer Science and Engineering
iii
ABSTRACT
Our project seeks to design a globally scalable system to grant permissions, and to enable
prompt global revocation of those permissions. We use a blockchain to coordinate consensus on a
canonical representation of the permission, and Bloom Filters to broadcast early revocations.
Previous systems do not envision a global, compact, timely broadcast of the kind of information
necessary to enable fine-grained trust relationships to be built up between strangers (humans or
computers). Recent work on blockchains has shown the way to use distributed control to achieve
global consensus on a canonical, tamper-resistant database. We use a blockchain in our system as
a flexible and global root of trust, as a way for oracles to make broadly applicable and verifiable
statements that can be used to anchor other parts of our system, to limit the damage caused by
stolen private keys, and for an anti-spam function. We use Merkle Trees to achieve compact proofs
that a permission is registered in the blockchain at a particular point in time. We use Bloom Filters
to broadcast compact proofs that a particular permission has not been revoked at a given point in
time. For our blockchain framework, we have chosen Hyperledger Fabric and implemented a
network of peers residing on different computers and communicating using a peer-to-peer
protocol. We discuss strategies for expressing permissions in a language that is flexible and
actionable. Our system enables strangers meeting anywhere in the world to present a document
which proves through a chain of facts that they have some particular permission. These facts can
be verified by seeing that they have been digitally signed by a relevant authority, whose authority
can be established using the same system back to some suitable root of trust, and they have not
expired or been revoked. On this basis, the strangers can make a decision about whether or not
some action should be permitted with a higher level of confidence that would otherwise be
possible.
iv
Table of Contents List of Figures ................................................................................................................................ vi
List of Tables ............................................................................................................................... viii
Acknowledgements ........................................................................................................................ ix
Chapter 1 Motivation and Background ........................................................................................... 1
1.1 Motivation ............................................................................................................................. 1
1.2 Background ........................................................................................................................... 3
Chapter 2 Related Work .................................................................................................................. 6
Chapter 3 Methodology .................................................................................................................. 9
3.1 Benefits of Blockchain based PKI ...................................................................................... 10
3.2 Security Assumptions .......................................................................................................... 11
3.3 Security Guarantees ............................................................................................................. 12
3.4 Publishing Certificates and Revocations ............................................................................. 14
3.5 Global Scaling ..................................................................................................................... 16
3.6 The PCN File ....................................................................................................................... 18
Chapter 4 Implementation............................................................................................................. 22
4.1 Policy Evaluator .................................................................................................................. 22
4.2 Hyperledger Fabric .............................................................................................................. 24
4.3 Permission Marshal ............................................................................................................. 25
4.4 Relay .................................................................................................................................... 29
v
4.5 Validation and Signing Application .................................................................................... 32
4.6 Use Case Scenarios ............................................................................................................. 34
Chapter 5 Conclusion and Future Work ....................................................................................... 49
Bibliography ................................................................................................................................. 51
vi
List of Figures
Figure 1: Certificate / Revocation Publication Process ................................................................ 14
Figure 2: Block Merkle Tree ......................................................................................................... 17
Figure 3: Publishing PCN for Attribute Root.Attr1 ...................................................................... 20
Figure 4: Revoking PCN for Attribute Root.Attr1 ....................................................................... 21
Figure 5: System Overview .......................................................................................................... 22
Figure 6: Implementation Policy .................................................................................................. 23
Figure 7: Hyperledger Fabric Network Topology ........................................................................ 24
Figure 8: CSR Creation Form ....................................................................................................... 26
Figure 9: Merkle Tree Included in Block 5 .................................................................................. 28
Figure 10: Publish/Subscribe Protocol Example .......................................................................... 30
Figure 11: Relay Messages ........................................................................................................... 31
Figure 12: PM Landing Page ........................................................................................................ 35
Figure 13: Create CSR Modal ....................................................................................................... 36
Figure 14: Browser Generated Credentials ................................................................................... 37
Figure 15: Saving Private Key ...................................................................................................... 38
Figure 16: Permission to Grant ..................................................................................................... 39
Figure 17: Required PCN and Private Key ................................................................................... 39
Figure 18: Granting Permission .................................................................................................... 40
Figure 19: Invoking pubcc for Publication ................................................................................... 41
Figure 20: Relay Receives Block Update of Publication .............................................................. 41
Figure 21: Relay Broadcasts Using ActiveMQ Broker ................................................................ 42
Figure 22: ValSig Disconnected Blockchain after Publication .................................................... 42
vii
Figure 23: user1’s Certificate Publication Reflected in PM Web-App ........................................ 43
Figure 24: Saving PCN File .......................................................................................................... 43
Figure 25: Saving PCN to Revoke ................................................................................................ 44
Figure 26: Permission to Revoke .................................................................................................. 45
Figure 27: Invoking pubcc for Revocation ................................................................................... 46
Figure 28: Relay Receives Block Update of Revocation .............................................................. 46
Figure 29: Revocation Bloom Filter ............................................................................................. 47
Figure 30: ValSig Disconnected Blockchain after Revocation .................................................... 47
Figure 31: user2’s PCN Revocation Reflected in PM’s Web-App............................................... 48
viii
List of Tables
Table 1: Certificate D’s Proof of Publication ............................................................................... 28
ix
Acknowledgements
This thesis is based upon work supported by the Office of Naval Research BA under
Contract Number N00014-19-C-2033. The content of the information does not necessarily reflect
the position or policy of the Government, and no official endorsement should be inferred.
Chapter 1
Motivation and Background
1.1 Motivation
Computers are increasingly acting in the real world with minimal human supervision.
However, one area where human interaction is still required is during the setup phase of
relationships that require high confidence in authenticity and data integrity.
Currently, the X. 509 Public Key Infrastructure (PKI) profile is the standard for setting up
authenticated relationships. That being said, the X.509 profile is far from perfect, especially in
how it handles revocations [1].
The X. 509 PKI Certificate profile described in RFC 5280 [2], uses the following
components as the basis of its reusable PKI: (1) end entity, the user of PKI certificates and/or end
user that is the subject of a certificate, (2) certification authority (CA), entities that issue PKI
certificates, (3) registration authority (RA), and optional system which a CA delegates certain
management functions, (4) certificate revocation list (CRL) issuer, a system that generates and
signs CRLs, and (5) repository, a system or collection of distributed systems that store certificates
and CRLs.
Under this profile, each PKI certificate contains the public key of a user which can be used
to encrypt messages in an asymmetric cryptosystem. PKI certificates also contain various fields
specifying the identity of the user, the identity of the CA who signed the user’s certificate, and
when the certificate expires. In addition signing, or issuing, PKI certificates, CAs are responsible
for indicating the revocation status of the certificates they issue.
2
In addition to defining PKI certificates, RFC 5280 also describes a method for CAs to
publish the revocation status of the certificates they issue, CRLs. As mentioned CRL issuers are
responsible for issuing CRLs. The CRL issuer is either the issuing CA, or an entity authorized by
the issuing CA to issue CRLs. CRLs are scoped, where the CRL scope is the set of certificates that
could appear on a given CRL. A complete CRL lists all unexpired certificates within its scope that
have been revoked. If a certificate is revoked before its expiration date, its serial number is added
to signed and timestamped list. These lists are referred to CRLs. Under this profile, the end entity
trying to verify the authenticity of a certificate is required to periodically check the CA’s repository
for its most recent CRL.
Another protocol for determining the current status of a digital certificate, without the use
of CRLs, is given RFC 6960 [3]. The Online Certificate Status Protocol (OSCP) gives end entities
a timely way to determine the status of PKI certificates. There are two parties in the OSCP
protocol; the OSCP client, the end entity trying to authenticate a PKI certificate, and the OSCP
responder, a server typically run by the CA. Upon receiving a PKI certificate to authenticate, the
OSCP client issues a request to the certificate’s corresponding OSCP responder, suspending
acceptance of the certificate. OSCP clients can determine the correct OSCP responder to contact
by examining the extension fields of the PKI certificate used to issue the certificate in question.
On receipt of an OSCP request, the OSCP responder checks if the certificate in question has been
revoked and responds to the OSCP client with “good”, “revoked”, or “unknown”. Returning
unknown only where the OSCP responder is unable to determine the state of the certificate in
question (e.g. the certificate in question was issued by a CA that is not served by OSCP responder).
In addition to CRLs and OSCP, the Server-Based Certificate Validation Protocol (SCVP)
[4] can also be used to determine the revocation status of a PKI certificate. In the same vein of
3
OSCP, in SCVP end entities can delegate certification path validation to a server. In doing so,
SCVP simplifies the implementation of end entities and allows for the use of predefined validation
policies. However, unlike OSCP, SCVP has the notion of trusted and untrusted servers. Untrusted
SCVP servers construct and provide end entities with the certification path for the certificate they
are trying to authenticate as well as the CRLs/OSCP responses needed to validate the certification
path. By moving the certification path construction to untrusted SCVP servers, end entities do not
implement the protocols needed to find and download intermediate certificates, CRLs, and OCSP
responses. In contrast, trusted SCVP servers run the entire certification path construction and
certification path validation on behalf of the end entity.
While the three revocation techniques discussed above successfully convey the revocation
status of a given certificate, this revocation information is not always done in a timely manner. In
the case of CRLs, it is up to signing CA to update the CRL. In the best case, these lists are updated
once a day. While OSCP and SCVP address this by offering a protocol that allows end entities to
determine the real-time revocation status of a certificate, they require a two internet connection.
As such, they fall apart in disconnected environments where only downlinks are available. In
addition to requiring two-way links, all three protocols rely on CAs, OSCP servers, and SCVP
servers, which are all single points of failure in their respective protocols. The Global Permission
Derivation Chain presented in this paper was designed to address these pitfalls.
1.2 Background
In 2008 a group or individual under the name of pseudonym of Satoshi Nakamoto
published a white paper titled “Bitcoin: A Peer-to-Peer Electronic Cash System” which is widely
considered to be the origin of blockchain technology [22]. However, the first appearance of a
structure that would today be referred to as a blockchain was presented in “How to Time-Stamp a
4
Digital Document” by Haber et al. [31]. In their paper Nakamoto outlines a purely peer-to-peer
electronic cash system, named Bitcoin that allows parties to send online payments to one another
without the need for a financial institution (i.e. a trusted third party). Bitcoin, like many other coins
at the time, makes use of digital signatures to prove ownership of coins. However, since the Bitcoin
network is decentralized and does not make us of a TTP, Bitcoin needs some mechanism to prevent
double spending. To address the problem of double spending Bitcoin adapts Adam Back’s
Hashcash, a proof-of-work (PoW) system original created to limit email spam and denial of
services attacks [21]. Bitcoin’s PoW system takes the form of a computational hash puzzle. The
solution to this puzzle is a value that when hashed results in the first n bits of the hash being all 0s.
In Bitcoin a coin is defined as a chain of signatures. To transfer a coin from one party to another,
the current owner of the coin signs the hash of the previous transaction and the public key of the
next owner. This process of transferring a coin is referred to as a transaction. Transactions a
grouped into blocks. In addition to containing a group of transactions, blocks also contain the hash
of the previous block, and a nonce. The nonce included in each block is the value required so that
the hash of the block is the solution to the PoW puzzle. Since the work required to solve the PoW
puzzle is exponential in the size of n, producing a valid consumes a nontrivial amount of
computational power.
In the years since the emergence of Bitcoin various applications have adapted the Bitcoin
model. These various applications are referred to as decentralized applications (Dapps). Dapps as
defined by Johnston et al. [23] are applications that meet the following criteria: (1) The application
must be completely open-source, it must operate autonomously, and with no entity controlling the
majority of its tokens, (2) The application’s data and records must be cryptographically stored in
public, (3) The application must use a cryptographic token which is necessary for access to the
5
application, and (4) The application must generate tokens according to a cryptographic algorithm
acting as proof of the value nodes are contributing to the application. However, all Dapps are not
created equal. As stated by Ehmke et al. [24] there are three layers of Dapps. The first layer (Type
I Dapps) consists only of cryptocurrencies. The second layer (Type II Dapps) makes use of the
first layer but also supports the execution of smart contracts. Finally, the third layer (Type III
Dapps) encompass all other Dapps that can built on top of a blockchain but are not focused on
asset transactions.
Type II and Type III Dapps have been used in multiple industries for multiple purposes.
For example, Bartolucci et al. [25] introduce SHARVOT a secure and fair electronic voting system
based in blockchain. In SHARVOT, utilizes the Bitcoin blockchain and a protocol based on
Shamir’s secrete sharing to guarantee the de-linking of users from their vote submissions while
ensuring a permanent and immutable record of the ballot. Kshetri et al. [26] explore the pros and
cons of using Blockchain-based identity and access management systems to strengthen IoT
security. Abeyratne et al. [27] use blockchain as the foundation for a decentralized, transparent,
and auditable supply chain system. Treleaven et al. [28] have shown how blockchain can be used
in the banking and financial domain as a way to simplify business processes while creating a
trustworthy chain of agreements and transactions. Finally, Xu et al. [29] introduced a blockchain-
enabled social credit system. These are just a few of the many decentralized applications based in
blockchain.
6
Chapter 2
Related Work
Since decentralized applications based in blockchain are applicable in various domains, it
is not surprising that multiple access control frameworks based in blockchains and distributed
ledgers exist. However, most of the works discussed in this section of the paper are not capable of
scaling globally, since they require a two-way internet connection, which is not always available
in disconnected, intermittent and low bandwidth environments, or because of some other limitation
in their approach.
The approach proposed in [12] uses a smart contract-enabled blockchain to achieve
distributed access control in an Internet of Things (IoT) environment. In this system, Access
Control Contracts (ACC) define one access control method for a subject-object pair. A Register
Contract defines which ACC is required to run to gain access to a resource. Finally, a Judge
Contract (JC) implements a misbehavior-judging method to facilitate the dynamic validation done
by the ACCs. The JC receives misbehavior reports from the ACCs, judges the behavior of the
subject, and returns a corresponding penalty. To evaluate if an access control request should be
granted, the appropriate ACC is called by the entity evaluating the access control. The ACC is then
run on a majority of participants in the system to ensure trustworthiness of the access control. Since
the access evaluation portion of this system requires invoking a smart contract, the evaluating
entity must have a two-way connection to all peers in the network. As such, this approach cannot
be used in environments where only downlinks are available.
The next work reviewed is the FairAccess system described in [13]. FairAccess is a
blockchain-based access control framework for IoT. The main contribution of this paper is access
7
to a resources are expressed using tokens. These tokens can then be traded amongst network
participants. Each time a token is traded, the set of constraints on that token become more specific
such that a user can only give other users a subset of the permission they were given. These tokens
are created, consumed, and traded through blockchain transactions. A token is created when a
resource owner submits a GrantAccess transaction. This transaction defines an access policy and
generates a new access token. The GetAccess transaction is submitted by a participant requesting
access to a resource. The requestor sends a token to access resources identified within the token,
gaining access and spending the token. Finally, the DelegateAccess transactions allow for a
requestor to transfer access tokens it already owns to another user under new conditions. Similar
to the approach described in [12], FairAccess requires that a participant execute a smart contract
on the blockchain network to gain access to a resource. Because of this, FairAccess requires a two-
way internet connection and is not suitable for disconnected, intermittent and low bandwidth
environments.
The next work reviewed differs from the first two, since it is built upon the existing Bitcoin
blockchain. The Blockchain Based Access Control framework described in [14] is similar to the
framework described in FairAccess, since it allows for the transfer of access control rights. In this
framework, 0.0001BTC is the static amount used to define an access token. Each access token
represents the right to access a specific resource. The right to access the resource can be traded to
another user by sending the 0.0001BTC token to another user using the Bitcoin network. To prove
a user has access to a recourse, the user must prove they are currently in possession of the correct
0.0001BTC token. While this verification can be done with only a downlink, unlike the first two
works reviewed, this implementation is not scalable, since the creation of a new access token
8
requires purchasing 0.0001BTC. Additionally, trading the access token between parties requires
paying Bitcoin transaction fees. As such, this approach does not scale well.
The final work discussed is the MedRec [15]. MedRec uses blockchain for medical data
access and permission management. MedRec is implemented using the Etherum (ETH)
blockchain; therefore, it uses smart contracts to perform the application logic. Using smart
contracts and the ETH blockchain, patient-provider relationships that associate medical records
with viewing permissions and data retrieval methods can be logged. Providers can create new
medical records associated with a particular patient and patients can then authorize sharing of
records between providers. MedRec also has the ability to aggregate references to all of a user’s
patient-provider relationships to provide a single point of reference to check for any updates to
medical history. MedRec has three types of contracts. (1) Registrar Contract, RC, a global contract
that maps participant identification strings to ETH addresses. (2) Patient-Provider Relation
Contracts, PPR, are issued between two nodes in the system, where one node stores and manages
medical records for the other. (3) Summary Contracts, SC, allow participants in the system to
locate their medical history. Since this approach is based on the ETH blockchain, blockchain
consensus is done through mining. In MedRec, two incentivizing models are proposed. The first
is based on Ethereum’s incentivizing model where transactions require Ether, a network currency,
to be processed by the network. Ether can be earned by mining. Thus, care providers are
incentivized to participate in mining to fund the continuation of their activities. The second model
brings medical researchers and health care authorities to mine in the network. In this model,
providers and patients release access to aggregate, anonymized medical data as mining rewards.
However, as with all Proof-of-Work mining based consensus methods, they do not scale well.
9
Chapter 3
Methodology
In 2000 Ellison et al. published an essay titled “Ten Risks of PKI: What You’re not Being
Told about Public Key Infrastructure” [30]. In the essay the authors outlined the following risks
with PKI: (1) Who do we trust, and for what? (2) Who is using my key? (3) How secure is the
verifying computer? (4) Which John Robinson is he? (5) Is the CA an authority? (6) Is the user
part of the security design? (7) Was it on CA or a CA plus a RA? (8) How did the CA identify the
certificate holder? (9) How secure are the certificate practices? (10) Why are we using the CA
process, anyway? The solution proposed in this thesis addresses the following concerns: Risk 1,
Risk 5, Risk 9, and Risk 10. The concern of Risk 1 is that CAs are often trusted entities, but who
granted the CA such authority? Our system makes it so that issuing a certificate is not enough to
be considered valid. The certificate must also be published to our distributed ledger (blockchain)
by a decentralized group of peers. Since the ledger is public, it can audited by other nodes in the
network to ensure the validity of the certificates being published. Similar to Risk 1, Risk 5 is once
again concerned with the CA. Risk 5 expresses that while a CA may be an authority for making
certificates they may not be an authority on what the certificate contains. For example, SSL
certificates contain the corporate name, and the DNS name of an SSL server. However, there are
no SSL CAs who are also DNS or corporate name authorities. In our system, certificates attest to
a permission that an individual has within an access control policy. If a specific CA has the ability
to grant permissions to other users, this ability is authorized by the underlying access control
policy. The concern expressed in Risk 9 is the security of the certificate practices being used with
respect to key lifetime and how revocations are handled. While our system does not directly
address key lifetimes (i.e. we don’t determine key lifetime by computing the probability of key
10
loss with respect to time and usage), however, our system does make significant improvements to
how revocations are handled by pushing revocations to end users within minutes of them being
revoked. Finally Risk 10 poses the question of why is the CA model being used in the first place.
Our system builds permission chains from first principles. The goal is to put computers in contact
with evidence that is verifiable by software (suggests digital signatures based on asymmetric
cryptography) that they can use to decide whether to grant access to a requestor with whom they
have no previous relationship. The requestor must either demonstrate that they know something
that qualifies them for access (not that usable without any prior relationship) or some third party
“oracle” must vouch for the requestor. If you have this, you have a version of PKI, and our solution
seeks to make PKI secure and scalable as possible.
3.1 Benefits of Blockchain based PKI
Blockchains have recently gained attention as an interesting method for a set of peers to
alternate adding to an append-only ledger. With a blockchain, individual peers or “small” subsets
of peers cannot produce valid alternative histories of the ledger. It takes a majority of the peers to
construct a history that will be accepted as authoritative. As such, we have selected blockchain to
be the foundation on which to build a public key infrastructure.
Public key infrastructure built on top of blockchains have the following desirable
properties. (1) Distributed control – as mentioned, with blockchains, a single ledger is distributed
over several peers selected such that one would find it “difficult” to exert control over another.
Distributed methods, such as blockchains, are also advantageous when compared to centralized
methods (i.e. X.509 PKI profile), since control over the issuance of certificates could be given to
a group of independent peers. Thus, resolving concerns that certificate authorities are a single point
of failure. (2) Proof of publication – data cannot be inserted into the blockchain without first being
11
public. Due to the structure of blockchains, peers cannot build blocks on a chain that they have no
knowledge of because adding a record requires knowledge of the contents of the prior records.
This gives principles within the PKI assurance that certificates are being issued transparently. In
addition to certificate transparency, proof of publication also makes the fact that a certificate has
not been revoked more meaningful (e.g. we know that a certificate has not been revoked simply
because no one knows the certificate exists). (3) Timestamping – proof that a certificate existed at
a certain point in the past. Since certificates are not considered valid until they are published to the
blockchain and since individual peers cannot create alternative ledger histories, certificates cannot
be back dated as they can in the X.509 PKI profile. (4) Rationing Bandwidth – since there is a
single shared log and each peer is aware of the rate at which data is being added, peers can prevent
other peers from violating policies such as exceeding the bandwidth downstream system
consumers can handle. (5) Data integrity – blockchains are built on digital signatures and secure
hash functions with the goal that every transaction is authenticated with a digital signature and it
is “difficult” to modify old records undetected. (6) Proof of non-publication – a single shared log
is the unambiguous definition of what has or has not been published. Proof of non-publication
allows us to prove that a certificate has not been revoked. (7) Computer parse-able evidence –
blockchains put evidence in a self-proving format that computers can understand and use to gain
confidence that a certain set of events took place.
3.2 Security Assumptions
As various portions of our system rely on RSA for asymmetric encryption, we make the
standard Strong RSA assumption. That is, given a random variable N distributed over the set of
products of two primes (i.e. N = pq where p ≠ q and both p and q are primes), such that factoring
N is believed to be hard, given an a chosen uniformly at random from ZN and an e ∈ N \{1}. Let
12
1< τ ∈ ZN. The Strong-RSA assumption states that for a sufficiently large τ the described problem
(i.e. RSA problem) is intractable [19].
Similarly, we make the following three assumptions about secure hash functions. (1)
Preimage-resistance: for all pre-specified outputs, it is computationally infeasible to find any input
which hashes to that output (i.e. given y where h(x) = y, it is not feasible for an adversary to
compute x). (2) Second-preimage resistance: given input x, it is computationally infeasible to find
another input x’ such that x and x’ have the same hash (i.e. given x an adversary cannot find an x’
such that h(x) = h(x’)). (3) Collision resistance: it is computationally infeasible to find two unique
inputs x, and x’ such that h(x) = h(x’) [18].
In addition to the standard RSA assumption and standard secure hash function assumptions,
we also assume that the software applications written to implement our Global Permission
Derivation Chain cannot be compromised. This assumption only covers the applications that
interact with the peer-to-peer blockchain network, not the nodes in the peer-to-peer blockchain
network. The peer-to-peer blockchain network used is implemented using Hyperledger Fabric, a
modular and extensible open-source system for deploying and operating permissioned
blockchains, which considers any client as potentially malicious [5].
3.3 Security Guarantees
Our global permission derivation system implements a public key infrastructure, which
allows an interaction between two principals, Alice and Bob, with certain desired properties: (1)
when Bob presents a digital certificate to Alice, he can prove that it was reviewed and approved
by a decentralized group of validators. The system will periodically broadcast compact summaries
that can be received while offline and used to prove that the certificate is included in the set of
13
approved certificates. (2) If Bob’s certificate has been revoked by the validators, the system
guarantees Alice that she can detect the revocation by examining a compact summary, which the
validators periodically broadcast.
Our system ensures our first guarantee through the uses of a distributed ledger and a
program referred to as a Relay. In order for a certificate to be considered valid it must be a part of
a Merkle Tree that was approved by a decentralized group of peers. Therefore, if Alice can prove
Bob’s certificate is an included in a Merkle Tree attested to by the distributed ledger she can prove
that Bob’s certificate was also approved by a decentralized group of peers. It is the Relays job to
broadcast the Merkle Trees included in the distributed ledger to Alice. Our second guarantee is
ensured, once again, by the Relay. Similar to certificates, revocations are not considered valid
unless they are attested to by a decentralized group of peers. However, unlike certificates,
revocations are included in a Bloom Filter as opposed to a Merkle Tree (Section 3.5 describes in
detail why Merkle Trees were used for certificates and Bloom Filters were used for revocations).
In addition to broadcasting Merkle Trees contains certificates, the Relay also broadcasts Bloom
Filters containing revocations included in the distributed ledger to Alice. Because of the structure
of a Bloom Filter, if Bob’s certificate is included in the Bloom Filter Alice is guaranteed that when
she checks Bob’s certificate against the Bloom Filter she will get a positive result (i.e. Bob’s
certificate is included in the Bloom Filter). Thus, Alice can prove that Bob’s certificate was
revoked by a decentralized group of validators.
The use of a distributed ledger gives our system properties 1, 2, 3, and 5 of the 7 properties
discussed in section 3.1. The use of a Bloom Filter gives our system property 6, and the use of a
distributed ledger in conjunction with Merkle Trees and Bloom Filters gives our system property
7. Our system is given the final property described in section 3.1, property 4, through a program
14
referred to as a Permission Marshall which oversees the publication of certificates and their
inclusion in the distributed ledger.
3.4 Publishing Certificates and Revocations
Figure 1: Certificate / Revocation Publication Process
Within our public key infrastructure, certificates and revocations are not considered valid
until they have been included in a block on the blockchain. Since our blockchain is implemented
using Hyperledger Fabric [5], the blockchain uses the execute-order-validate architecture. As such,
committing transactions to the ledger is done in three phases. During the execute stage, clients sign
and send proposals to at least one endorser for execution. Since the required endorsers of the
proposed transactions are specific to the chaincode (i.e. smart contract) being executed, each
15
proposal includes a chaincode identifier. Endorsers then simulate the proposal by running the
specified chaincode. The proposal is simulated against the endorser’s local ledger state, without
synchronization with other peers. The simulation, if successful, results in a read-write set listing
all keys read during the simulation and their version number (i.e. the reads) and all modified keys
and their new values (i.e. the writes). This read-write set is then endorsed by the endorser through
a cryptographic signature (e.g. RSA signature), and is returned the proposing client. The client
collects endorsements until the endorsement policy for the executed chaincode is met. Finally, the
client creates a transaction and submits it to the ordering service [5].
During the second phase, all submitted transactions are batched into blocks, creating a total
execution order based on where the transactions are included in the block [5]. Consensus between
all ordering services is achieved using Raft, a consensus algorithm managing a replicated log that
is equivalent to (mulit-)Paxos [6]. The newly constructed block is then broadcasted to all peers.
The final phase occurs once a peer receives a new block. The peer validates all transactions
have been endorsed with respect to the endorsement policy for their specified chaincode. This is
done through the use of a validation system chaincode (VSCC) provided by Hyperledger Fabric.
Next, the peer checks for read-write conflicts. For each transaction, it compares the versions of the
keys in the read set field to those in the current state of the peer’s local ledger and ensures they are
still the same. If a transaction is not properly endorsed, or there is a read-write conflict, the
transaction is marked as invalid. Finally, the block is appended to the peer’s local ledger, updating
the state of the blockchain [5].
In our Global Permission Derivation Chain, the blockchain attests to what certificates have
been published and revoked. As such, this information must be included in the read-write set
produced by the endorser during the execute phase of publishing a transaction. Figure 1 illustrates
16
how a certificate or revocation is included in the blockchain. The application responsible for
submitting proposals to endorsers is referred to as a Permission Marshal.
3.5 Global Scaling
The system as described thus far is no more scalable than any of the current approaches.
To achieve the global scaling, we desire we introduce the notion of a Relay and Disconnected
Blockchain.
A Relay is an application that is responsible for summarizing the information included in
the Hyperledger Fabric blockchain and broadcasting this summary to listening clients. To ensure
Relay messages are as small as possible, the following question must be answered: what is the
minimum amount of information required to prove a user has the authority they claim they do?
The answer is: enough information to prove the following two statements. (1) The user has to
prove they were previously given the authority (i.e. the user has to prove their certificate is included
in the set of certificates reviewed and published by Hyperledger Fabric’s set of independent peers)
and (2) since being granted, the certificate has not been revoked (i.e. the user has to prove their
certificate is not included in the set of revocations reviewed and published by Hyperledger Fabric’s
set of independent peers).
Proving statement one above requires verification that a particular value is included in a
dataset. To accomplish this, we make use of a Merkle Tree (i.e. binary hash tree). A binary hash
tree is a binary tree in where every leaf node is labelled with the hash of a data block and every
non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. The Merkle
Tree used in our system can be broken down into two parts, the Transaction Merkle Trees and the
Block Merkle Trees. As described above, each block in the Hyperledger Fabric blockchain can
17
contain multiple transactions. In our case, each transaction contains the root of the Merkle Tree
(i.e. Merkle Root), where each leaf is a certificate being published. A Merkle Tree whose root is
included in a transaction is referred to as a Transaction Merkle Tree. A Block Merkle Tree
combines all the Transaction Merkle Trees included in the same block into a single tree whose
root can be published by the Relay. Each leaf in a Block Merkle Tree is the root of a Transaction
Merkle Tree included in said block. Figure 2 depicts an example Block Merkle Tree.
Figure 2: Block Merkle Tree
Merkle Trees were selected as a tool to prove statement one because, to prove that a leaf is included
in a given Merkle tree, all that is required is to compute and provide a number of hashes
proportional to the logarithm of the number of leaf nodes of the tree [9].
Bloom Filters were selected as the tool used to prove statement two. Bloom Filters were
first introduced in [10] as a means to verify that a specific message is not included in a set of
messages, allowing for false positives with a tunable probability. Bloom Filters can be thought of
18
as an n x n grid. Initially, the grid contains all 0s. To add a message, hash the message and arrange
the hash into an n x n grid. Take the cell-wise OR of the Bloom Filter and the hashed message, the
resulting grid is the updated Bloom Filter. To check if a specific message is included in the Bloom
Filter, hash the message and arrange the hash into an n x n grid. For every cell that contains a 1 in
the message hash, check if the corresponding cell in the Bloom Filter also contains a 1. If every
cell containing a 1 in the hash has a corresponding 1 in the Bloom Filter, the message may have
been included in the message set (this uncertainty is due to the fact that the accumulation of
messages in the Bloom Filter can make it appear as though a message has been added when it, in
fact, has not). However, if there is a cell containing a 1 in the hash that corresponds to a cell
containing a 0 in the Bloom Filter, we know for certain that the message in question was not part
of the message set. As such, using Bloom Filters as a way to prove a specific certificate has not
been included in the set of revoked certificates in natural.
Relay messages chain to previous Relay messages through hash chains and each message
is endorsed by the Relay through the use of cryptographic signatures. We refer to this chain of
endorsed Relay messages as a Disconnected Blockchain.
3.6 The PCN File
A Permission ChaiN (PCN) file is a new file type, created by us, that is used within our
system when publishing certificates, revoking certificates, and granting access requests. The PCN
has two sections: a Privacy Enhanced Mail (PEM) encoded section and a JavaScript Object
Notation (JSON) section.
PEM was first introduced in RFC 1421 on February of 1993 as a means of defining a
uniform encoding for electronic mail that is not dependent on the end users’ systems’ native
19
character sets. The encoding’s characteristics are such that the transformations anticipated between
the sending and receiving end users will not prevent an encoded message from being decoded
properly. In addition to its primary purpose of providing a uniform representation of in transits
mail text, RFC 1421 was also defined to be compatible with various key management approaches.
As such, PEM has become a standard way to represent X. 509 certificates [16]. We make use of
the PEM encoding in the PCN file as a way of representing X. 509 certificates published within
our system. Multiple PEM certificates can be concatenated together form a certificate chain.
JSON is a text syntax standardized by Ecma International that facilities structured data
interchange between programming languages. Based on a subset of the JavaScript Programming
Language Standard defined in ECMA-262, JSON is language independent but makes use of
conventions found in many C-style languages. JSON is used within the PCN file as a way to
represent all structured data aside from the PEM encoded certificates. JSON was chosen since it
is language independent, a requirement since our implementation makes use of JavaScript, Java,
and Golang, and because of its readability.
When used to publish new certificates, the PEM section of the PCN file contains a
certificate chain starting with the newly created certificate and terminating with the root certificate.
The JSON section contains the corresponding Merkle Proofs for all included certificates in the
same order. To prove they have been granted an attribute, a user simply has to provide a publication
PCN where the top certificate contains the attribute they are trying to prove they have been granted
and cryptographically sign a challenge using the certificates corresponding private key. Figure 3
contains an example publication PCN.
20
Figure 3: Publishing PCN for Attribute Root.Attr1
Similar to the publication use case, when used for revocations, the PEM section of the PCN
file contains a Certificate chain. However, the Certificate chain starts with the parent of the
certificate being revoked and terminates with the root cert. Like the publication PCN, the JSON
section of the revocation PCN contains the Merkle Proofs of the certificates included in the
Certificate chain. The JSON section on the other hand contains two fields not seen in the
publication PCN in addition to the list of Merkle Proofs. These two fields, cert and signature,
contain the string “REVOKE” followed by the PEM encoded certificate being revoked and a
cryptographic signature over the cert field respectively. Figure 4 show an example revocation
PCN.
21
Figure 4: Revoking PCN for Attribute Root.Attr1
22
Chapter 4
Implementation
Figure 5: System Overview
Figure 5, depicted above, illustrates how the various components described in this section
interact to publish and/or revoke certificates.
4.1 Policy Evaluator
The section above lays out the process for publishing certificates and revocations.
However, the published certificates are meaningless unless there is an interpretation of what
23
statements the certificates attest to. The Policy Evaluator is a Golang application that: (1) specifies
what attributes can be included in X. 509 certificates as extensions and (2) evaluates if a principal
has the authority to sign CSRs or a revocation.
To be considered a Policy Evaluator, an application must implement the three functions:
(1) Print Attributes, a function that lists all the distinct labels in an access control policy, (2) Sign,
a function that determines if a specified principal has the authority to sign the given CSR, and (3)
Revoke, a function that determines if a specified principal has the authority to revoke given
certificate.
Figure 6: Implementation Policy
For our development implementation, we created a trivial hierarchical access control
policy. In this policy, a label consists of an element from the hierarchy (i.e. an attribute) and a
Boolean. A principal can confer attributes to other principals if: (1) the Boolean portion of their
label is true, and (2) the attribute being conferred is a child of the attribute they possess. Similarly,
24
a principal has the authority to revoke an attribute if the revoking principal’s attribute is the parent
of the attribute being revoked. Figure 5 shows the hierarchy used.
Having the Policy Evaluator application separate from the other aspects of our
implementation allows our implementation to easily be modified to support canonical access
control methodologies such as attribute based access control and class based access control.
4.2 Hyperledger Fabric
As described above, Hyperledger Fabric is the framework used to implement our
blockchain. The Hyperledger Fabric portion of our development implmentation can be broken
down into two aspects: the network topology and the chaincode (i.e. smart contract) installed on
the network.
Figure 7: Hyperledger Fabric Network Topology
Our blockchain network consists of four nodes: two peers and two orderers. Nodes in
Hyperledger Fabric are grouped into organizations. Each organization is considered a trust domain
(i.e. peers within the same organization trust each other, but peers do not trust peers from other
organizations) [5]. The nodes in our network are grouped into three organizations: Organization 1
25
(org1.example.com), Organization 2 (org2.example.com), and Orderer. As the name implies, the
Orderer organization contains our two orderer nodes ordere0.example.com and
orderer1.example.com. Organization 1 and Organization 2 each have a single node
peer0.org1.example.com and peer0.org2.example.com respectively. Using Hyperledger Fabric’s
built-in access control Organization 1 and Organization 2 are both given read-write access the
Orderer Organization. This is necessary to allow for Organization 1 and Organization 2 peers to
submit transactions to and receive blocks from orderers. Figure 6 depicts the described network
topology.
A chaincode is program code that implements the application logic of Hyperledger Fabric
networks. For our development implementation, we have written a single chaincode, pubcc. As
stated, chaincodes run during the execution phase of the execute-order-validate architecture
described above. This chaincode, pubcc, is responsible for verifying that the payload submitted by
the Permission Marshal is formatted correctly and can be included in the blockchain. The following
properties are verified by pubcc: (1) the timestamp included in the payload is valid (i.e. occurred
within the last minute), (2) the root of the Merkle tree of certificates is not null, and (3) every
revocation corresponds to a published certificate. If the above properties are met, the peer will
endorse the payload submitted by the Permission Marshal.
4.3 Permission Marshal
The Permission Marshal (PM) is a decentralized application written in Golang that
manages the creation of certificate signing requests (CSRs), manages certificate revocations,
assembles signed certificates and revocations into payloads, submits payloads to peers for
endorsement, and listens for block publication events from the Hyperledger Fabric network. The
26
status of certificates and revocations within our system is synchronized between the various
Permission Marshal instances through the use of Hyperledger Fabric.
To assist users in the creation of CSRs, the Permission Marshal hosts an AngularJS web
application. The web application makes use of the Web Cryptography API (WebCryptoAPI) to
generate an RSA key pair and a corresponding X. 509 CSR. WebCryptoAPI describes a JavaScript
API for performing basic cryptographic operations produced by the Web Cryptography Working
Group of the World Wide Web Consortium [7]. In addition to the standard CSR fields, the “Create
CSR” form also allows users to specify the (Common) Name of the principal they are requesting
to sign their CSR and the attribute they are requesting (Note: The Permission Marshal makes a call
to the Policy Evaluator to get a full list of available attributes). After the “Create CSR” form is
submitted to the Permission Marshal, the Permission Marshal will route the CSR to the appropriate
principal for signing. Figure 7 depicts the Create CSR form.
Figure 8: CSR Creation Form
27
Upon receiving signed certificates (the exact process of how a CSR gets signed is described
in the Validation and Signing Application section), the Permission Marshal first verifies the
legitimacy of the certificates before adding them to a queue for publication. First, the Permission
Marshal verifies the signer had the authority to sign the CSR by making a call to the Policy
Evaluator. Next, the Permission Marshal checks its internal state to verify that the signer’s cert has
not been revoked before adding them to the publication queue. Permission Marshal’s receive block
publication events from the Hyperledger Fabric network for every published block. Upon receiving
these events, the Permission Marshal will parse the contents of the block adding any revocations
to its internal state (even revocations of certificates published by other Permission Marshals).
Because of this, Permission Marshals are aware of all certificate revocations. Periodically, the
Permission Marshal will construct a Merkle Tree using the contents of the publication queue. The
root of this Merkle Tree (along with a list of revocations) are then submitted to a peer for
endorsement (i.e. the Permission Marshal executes the pubcc chaincode).
When a new block publication event occurs, the Permission Marshal, in addition to parsing
revocations as described above, verifies that the transaction it submitted is included in the block.
If so, the Permission Marshal provides the signee with the proof they need to verify their certificate
is included in a published block, referred to as proof of publication. Proof of publication consists
of: (1) number of leaves in the Merkle Tree that the user’s certificate is a part of, (2) the position
of the user’s certificate in the Merkle Tree, (3) the root of the Merkle Tree, (4) the Merkle proof
corresponding to the user’s certificate, (5) the block number that the certificate was published in.
Having both the proof of publication and the signed certificate, both of which are included in a
PCN file, allows anyone with access to the Hyperledger Fabric network to verify the certificate
was published in a single blockchain query. For example, if the Merkle Tree depicted in Figure 9
28
represents a transaction submitted by a Permission Marshal, with L0 – L3 being the data for the
certificates it wishes to publish, certificate D’s proof of publication would the values in Table 1.
NumLeaves 4
LeafIndex 3
MerkleRoot H(Hash 0 + Hash 1)
Proof [ H(C), H(Hash 0,0 + Hash 0,1) ]
BlockNum 5
Table 1: Certificate D’s Proof of Publication
Figure 9: Merkle Tree Included in Block 5
Signed revocations follow a similar path through the Permission Marshal to the path signed
certificates follow. One difference, however, is that where the creation of a certificate is initiated
by the principal requesting the certificate (i.e. the signee), revocations are initiated by the principal
𝐻𝐻(𝐻𝐻𝐻𝐻𝐻𝐻𝐻 0+ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻 1)
Merkle Root
𝐻𝐻(𝐻𝐻𝐻𝐻𝐻𝐻𝐻 0,0+ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻 0,1)
Hash 0
𝐻𝐻(𝐴𝐴)Hash 0,0
AL0
𝐻𝐻(𝐵𝐵)Hash 0,1
BL1
𝐻𝐻(𝐻𝐻𝐻𝐻𝐻𝐻𝐻 1,0+ 𝐻𝐻𝐻𝐻𝐻𝐻𝐻 1,1)
Hash 1
𝐻𝐻(𝐶𝐶)Hash 1,0
CL2
𝐻𝐻(𝐷𝐷)Hash 1,1
DL3
29
that signed the certificate being revoked (i.e. the signer). The revoking principal accesses a
Permission Marshal where they can see a list of certificates published by the accessed Permission
Marshal on behalf of the revoking principal. From here, the revoking principal can indicate which
of the published certificates they wish to revoke. The certificates marked for revocation are made
available to the Validation and Signing Application, once again, the exact process of how
revocations are signed is described in the Validation and Signing Application section.
Once the Permission Marshal receives a signed revocation, it verifies that the revoking
principal has the authority to revoke the certificate in question and it verifies that the revoking
principal’s certificate has not been revoked. From there, the signed revocations are added to a
queue for publication. Upon receiving a block publication event from the Hyperledger Fabric
network, the Permission Marshal parses the block adding all revocations to its internal state.
4.4 Relay
The Relay is a Golang application designed to allow a certificate publication and revocation
system to scale globally. Hyperledger Fabric networks are not designed to handle large network
delays between peers. Nguyen et al. demonstrated that having network delays in excess of 3.5
seconds caused their system to “brutally halt” [8]. As such, Hyperledger Fabric networks are
unable to be used in disconnected, intermitted, and low-bandwidth (DIL) environments. The Relay
was designed to address this pitfall.
The Relay, much like the Permission Marshal, listens to the Hyperledger Fabric network
for block publication events. Upon receiving a block publication event, the Relay computes the
Block Merkle Tree and adds all published revocations to its Bloom Filter (as described in the
Global Scaling section of the Methodology chapter).
30
For broadcasting messages to listening clients the Relay implements a message queuing
telemetry transport (MQTT) publisher. MQTT is a publish/subscribe messaging protocol invented
by Dr Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech). MQTT is
designed for use in constrained devices operating on low-bandwidth, high-latency or unreliable
networks, making MQTT perfect for DIL environments [12]. As with a majority of
publish/subscribe messaging protocols, MQTT uses a broker. The broker is responsible for
ensuring that a client receives a message if, and only if, the message is published to a topic the
client is subscribed to. In our development implementation, a single broker is used and each relay
publishes to a pair of topics unique to the Relay. A simple publish/subscrip protocol exmaple is
given in Figure 10.
Figure 10: Publish/Subscribe Protocol Example
Relays publish two types of messages to listening clients: Relay block messages and Bloom
messages. The Relay block message contains the following fields: index (i.e. block number), the
31
root of the Block Merkle Tree, hash of current Bloom Filter, previous block hash, RSA signature
over the first four fields, and optionally, the hash of the current block. Bloom messages are simpler,
containing only the index of the Relay block committing to the Bloom Filter, and the contents of
the Bloom Filter. Relay block messages are published to name-relayblocks and bloom messages
are published name-bloomfilter where name is the common name found on Relay’s X. 509 public
key certificate (containing the corresponding public key to the private key the Relay used to sign
the relay block message). The Golang data structures used by the Relay when publishing messages
are given in Figure 11.
In the event a client misses a relay-block, the Relay makes available a REST API, allowing
clients to request specific blocks.
Figure 11: Relay Messages
32
4.5 Validation and Signing Application
The last component of our implementation is the Validation and Signing Application
(ValSig). ValSig is a Java Swing application in which users can directly interact with to sign CSRs,
sign certificate revocations, request access, and evaluate access requests.
The first step in gaining access to a resource in our development implementation is the
invitation step. In this step, a principal with the authority to grant the user their desired permission
creates an invitation. This invitation is a JSON object containing the desired permission and which
attribute this permission maps to (e.g. in our implementation Write access maps to Root.Attr1
attribute). This invitation is then sent to user requesting permission using out of band
communication.
Once the user receives the permission invitation, they can access a Permission Marshal and
create a CSR requesting the attribute included in the invitation and specifying the common name
of the inviter as the signing principal. After the CSR has been created, the signer’s ValSig
application can download the CSR from the Permission Marshal through a REST endpoint. The
ValSig application displays the contents of the CSR in a human readable format allowing the
signing principal to verify the contents of the CSR. The ValSig application also scans the contents
of a specified folder (e.g. ValidatorSigner/permission-files) to determine if the signing principal
has a X. 509 certificate with an attribute capable of conferring the requested attribute (i.e. does the
user have a publication PCN file where the top certificate contains the requested attributes parent)
using the Policy Evaluator. If yes, the ValSig application will ask the signing principal if they want
to “Deny Attribute” or “Grant Attribute”. If the singing principal chooses to deny the attribute, the
Permission Marshal will delete the CSR notifying the creator that their request has been denied. If
33
the signing principal decides to grant the attribute, the ValSig application will sign the CSR using
the X. 509’s corresponding private key.
From here, the ValSig application constructs a partial PCN by prepending the newly signed
certificate to PEM section of the signer’s PCN. This is only a partial PCN since the JSON section
will not contain the Merkle Proof for the newly added certificate since the Merkle Proof is not
generated until the certificate is published by the Permission Marshal. The ValSig application then
sends the partial PCN to the Permission Marshal for publication.
Revoking certificates follows a similar workflow. First, the ValSig application downloads
a pending revocations from a Permission Marshal through a REST API. The ValSig application
displays the contents of the certificate in a human readable format so the singing principal can
verify the contents of the certificate they are about to revoke. The ValSig application also scans a
specified folder for a X. 509 certificate capable of signing the pending revocation (i.e. does the
user have a publication PCN file where the top certificate is the parent of the certificate being
revoked) using the Policy Evaluator. If so, the ValSig application will ask the signing principal if
they wish to “Decline Revoke Request” or “Sign Revoke Request”. If the singing principal
declines the revoke request, the pending revocation is deleted from the Permission Marshal and no
other actions occur. If the signing principal signs the revocation request, the ValSign generates a
revocation PCN and sends it to the Permission Marshal to publish the revocation.
The validation portion of the ValSig application allows users to validate access control
requests. The principal evaluating an access control requess first translates the permission required
to access a resource to an attribute (e.g. in our implementation Write access maps to Root.Attr1
attribute) using their ValSig application. The ValSig application also generates a challenge. The
challenge and the attribute required for access are then given to the requesting principal. The
34
requesting principal selects a PCN file attesting the desired attribute, and cryptographically signs
the challenge using the corresponding private key. The PCN and signature are then sent back to
the evaluating principal. The evaluating principal then feeds both values into its ValSig
application, which validates the following properties: (1) the signature was generated by the top
certificate in the PCN’s corresponding private key, (2) the top certificate of the PCN has the correct
attribute, (3) all certificates in the PCN chain in terms of attribute chains and Certificate chains,
(4) all certificates were published in PCN, (5) none of the certificates in the PCN are expired and
(6) none of the certificates in the PCN are revoked. Properties 1 and 3 are validated using the
Policy Evaluator. If all six properties are validated, the access request is granted.
4.6 Use Case Scenarios
To demonstrate the functionality of our implementation, the following two scenarios are
presented: Scenario 1, publishing a permission, and Scenario 2, revoking a permission. In the first
scenario, user1 requires the attribute Root.Attr1 to complete some task. Since user1 does not have
this attribute, they will have to request it from user root, a user capable of granting them this
permission. To start this process, user1 will access a PM and provide proof of identity. From there,
user1 will be greeted with the PM’s web-app’s landing page seen in Figure 12.
35
Figure 12: PM Landing Page
Once the landing page has been accessed, user1 can start permission publication process by
clicking the “Create CSR” button to open the “Create CSR” modal. Once the modal is open, the
PM will make a call to the Policy Evaluator requesting the names of all attributes included in the
access control schema being used. The PM’s web-app will use this information to populate a
dropdown menu in the “Create CSR” modal. The “Create CSR” modal is shown in Figure 13.
36
Figure 13: Create CSR Modal
As stated, user1 requires the attribute Root.Attr1, as such they will select Root.Attr1 from the drop
down menu and submit the CSR to the PM. Once the “Submit CSR to CA” button is clicked, the
PM’s web-app will use the WebCrypto API to generate an RSA key pair, import the RSA public
key into a CSR, and sign the CSR with the RSA private key. All of which is done in user1’s
browser (i.e. the Golang Permission Marshal Application is never made aware of user1’s RSA key
pair). The “Create CSR” modal will then display the generated credentials (CSR and RSA key
pair) as PEM encoded strings and provide user1 with the option to save their private key. The
updated view of the “Create CSR” modal is depicted in Figure 14.
37
Figure 14: Browser Generated Credentials
When saving user1’s private key, the PM’s web-app will compute the SHA-1 hash user1’s public
key and use this as the name of the private key file being downloaded by user1’s browser. Using
this naming convention will allow ValSig to easily identify what key corresponds to what PCN
file. During this step, user1 must be sure to save their RSA private key in a directory managed by
their ValSig application. By default, ValSig expects PCN files to be located in the permission-files
directory and keys to be located in the permission-files/keys directory. The name and directory in
which the user1’s private key was saved is included in Figure 15.
38
Figure 15: Saving Private Key
After the CSR has been submitted to the PM, it will forward the CSR to the appropriate signing
entity. In this scenario, the entity is root. root will access their ValSig application and fetch all
CSR’s awaiting their signature. For each CSR, ValSig will display the subject information
included in the CSR as human-readable text, indicate what attribute the subject is requesting, and
if root has a corresponding PCN and RSA private key capable of granting the requested attribute.
Since root possess a PCN with the attribute Root_grants and its corresponding private key, ValSig
will notify root that they are capable of signing the CSR in question. Figure 16 shows that root has
39
permission to sign the user1’s CSR and Figure 17 shows the location of the required PCN and its
private key.
Figure 16: Permission to Grant
Figure 17: Required PCN and Private Key
40
Since ValSig indicates that root can sign user1’s CSR, root can sign the CSR and send the resulting
certificate to the PM by clicking the “Grant Attribute” button shown in Figure 18.
Figure 18: Granting Permission
Upon receiving the signed certificate from root, the PM will invoke the pubcc chaincode to publish
user1’s certificate (any other signed but not published certificate and/or revocations would also be
published at this time). Figure 19 contains the result of the PM invoking pubcc. In the figure, we
see a Merkle Root being published alongside an empty revocation. In this scenario, the revocation
list is empty since there were no unpublished revocations when the PM invoked pubcc.
41
Figure 19: Invoking pubcc for Publication
The pubcc invocation will result in a new block being published to the blockchain triggering a
block event. When the relay receives this block event, it will construct a Block Merkle Tree and
add any revocations to its Bloom Filter. The relay will then publish the root of the Block Merkle
Tree and the Bloom Filter to an ActiveMQ broker. Figure 20 show Relay 1 handling this block
event and Figure 21 depicts the ActiveMQ broker used by Relay 1.
Figure 20: Relay Receives Block Update of Publication
42
Figure 21: Relay Broadcasts Using ActiveMQ Broker
When ValSig receives the Relay 1’s broadcast, it will add the endorsed message to its local
Disconnected Blockchain. Figure 22 shows the contents of ValSig’s Disconnected Blockchain
after user1’s certificate has been published.
Figure 22: ValSig Disconnected Blockchain after Publication
Finally, user1 ends the publication process by accessing the PM’s web-app and saving their
Root.Attr1 PCN file. The PCN file should be saved in the permission-files directory and should
use the naming convention attributeName_firstSevenDigitsOfPubKeySHA1. Figure 23 shows the
PM’s web-app’s updated landing page and Figure 24 depicts saving the user1’s PCN and its value.
43
Figure 23: user1’s Certificate Publication Reflected in PM Web-App
Figure 24: Saving PCN File
44
The second scenario discussed in this section is revoking a permission. In this scenario, our
user root has determined that user2’s Root.Attr2 permission has been compromised. To start the
revocation process, root will access a PM’s web-app and provide proof of identity. From there,
root will be greeted with the PM’s web-app landing page, where root can see all the certificates it
has signed. root will then save a copy of user2’s Root.Attr2 PCN using the method shown in Figure
25.
Figure 25: Saving PCN to Revoke
Once root has a copy of the PCN file being revoked, it can import it into their ValSig application.
ValSig will display the subject information of the PCN file being revoked as human-readable text
and indicate if root has permission to revoke the imported PCN. Since root possess a PCN file with
the attribute Root_grants and its corresponding private key and since root signed user2’s
Root.Attr2 certificate, ValSig will indicate root has permission to revoke the user2’s PCN. This is
depicted in Figure 26.
45
Figure 26: Permission to Revoke
Once root has signed the revocation, it will be sent to the PM who will publish the revocation by
invoking the pubcc chaincode. The results of this chaincode invocation can be seen in Figure 27.
Similar to Figure 19, Figure 27 shows the Merkle Root and revocation list being published,
however, in the case of Figure 27, the revocation list being published is non-empty.
46
Figure 27: Invoking pubcc for Revocation
As in scenario 1, the invocation of pubcc will trigger a block event which the will be consumed by
Relay 1. Upon receiving the block event, Relay 1 will construct a Block Merkle Tree and add any
revocations to its Bloom Filter publishing both to ActiveMQ. Figure 28 shows Relay 1 handing
the block event triggered by publishing the revocation of user2’s Root.Attr2 PCN and publishing
its 9th message.
Figure 28: Relay Receives Block Update of Revocation
47
Upon receiving Relay1’s 9th message, ValSig will save the latest version of the Bloom Filter and
the number of the relay message it was published in. ValSig also saves the contents of the relay’s
message in its local Disconnected Blockchain. Figure 29 shows the hexadecimal representation of
the Bloom Filter, while Figure 30 shows ValSig’s Disconnected Blockchain after user2’s
Root.Attr2 PCN has been revoked.
Figure 29: Revocation Bloom Filter
Figure 30: ValSig Disconnected Blockchain after Revocation
48
Finally, user2 can access a PM’s web-app and see that their Root.Attr2 PCN file has been revoked.
This is depicted in Figure 31.
Figure 31: user2’s PCN Revocation Reflected in PM’s Web-App
49
Chapter 5
Conclusion and Future Work
The Global Permission Derivation Chain described was designed to address the pitfalls of
traditional PKI profiles and existing blockchain-based access control frameworks. Our system
removes single points of failure by giving control over the issuance of certificates to a
decentralized set of peers. This makes our system more robust than traditional PKIs since
compromising any single entity cannot harm the system (i.e. modifications require collaboration).
The Global Permission Derivation Chain provides timely revocations since new blocks are
published every five seconds. The system is also scalable since the Relay only publishes Merkle
Tree roots and Bloom Filters, allowing publication and revocation information to be sent to
principals in DIL environments.
The implementation described above is not consistent with our described methodology
since our broadcasting method is based in MQTT which requires a TCP/IP connection (i.e. a two-
way connection). One area of future work would be to re-implement our methodology using
MQTT Sensors Network (MQTT-SN). MQTT-SN is a variant of MQTT designed for use in
Wireless Sensor Networks (WSNs). As such, it can be used over a serial link or a UDP network
both of which allow for connectionless communications. One downside to MQTT-SN is that in
addition to a broker it also requires a gateway. The MQTT-SN gateway is responsible for
translating MQTT-SN traffic to MQTT traffic allowing the connectionless MQTT-SN devices to
communicate with TCP/IP based MQTT devices [20]. In this re-implementation, the ValSig
applications would make use of MQTT-SN while the Relays would use MQTT. Allowing ValSig
to function with only a one-way connection.
50
Another area of future work is to incorporate the concept of identity into our system. As it
stands, our system links a private key to an attribute. A user can multiple private keys
corresponding to multiple attributes, but from the systems perspective there is no way to determine
if a set of attributes have been granted to a single user, or to multiple users. Introducing the concept
of an identity eliminates this problem by linking sets of attributes to a particular user.
51
Bibliography
[1] Baldi, M., Chiaraluce, F., Frontoni, E., Gottardi, G., Sciarroni, D., & Spalazzi, L.
(2017). Certificate Validation Through Public Ledgers and Blockchains.
In ITASEC (pp. 156-165).
[2] Internet Engineering Task Force (IETF), “Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, 2008.
[3] Internet Engineering Task Force (IETF), “X.509 Internet Public Key Infrastructure -
Online Certificate Status Protocol - OCSP,” RFC 6960, 2013.
[4] Internet Engineering Task Force (IETF), “Server-Based Certificate Validation Protocol
(SCVP),” RFC 5055, 2007.
[5] Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., ... &
Muralidharan, S. (2018, April). Hyperledger fabric: a distributed operating system for
permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference (pp.
1-15).
[6] Ongaro, D., & Ousterhout, J. (2014). In search of an understandable consensus
algorithm. In 2014 {USENIX} Annual Technical Conference ({USENIX}{ATC}
14) (pp. 305-319).
[7] Halpin, H. (2014, April). The W3C web cryptography API: motivation and overview.
In Proceedings of the 23rd International Conference on World Wide Web (pp. 959-
964).
[8] Nguyen, T. S. L., Jourjon, G., Potop-Butucaru, M., & Thai, K. L. (2019, April). Impact
of network delays on Hyperledger Fabric. In IEEE INFOCOM 2019-IEEE Conference
52
on Computer Communications Workshops (INFOCOM WKSHPS) (pp. 222-227).
IEEE.
[9] Becker, G. (2008). Merkle signature schemes, merkle trees and their
cryptanalysis. Ruhr-University Bochum, Tech. Rep.
[10] Bloom, B. H. (1970). Space/time trade-offs in hash coding with allowable
errors. Communications of the ACM, 13(7), 422-426.
[11] MQTT Version 5.0. Edited by Andrew Banks, Ed Briggs, Ken Borgendale, and Rahul
Gupta. 07 March 2019. OASIS Standard.
[12] Zhang, Y., Kasahara, S., Shen, Y., Jiang, X., & Wan, J. (2018). Smart contract-based
access control for the internet of things. IEEE Internet of Things Journal, 6(2), 1594-
1605.
[13] Ouaddah, A., Abou Elkalam, A., & Ait Ouahman, A. (2016). FairAccess: a new
Blockchain‐based access control framework for the Internet of Things. Security and
Communication Networks, 9(18), 5943-5964.
[14] Maesa, D. D. F., Mori, P., & Ricci, L. (2017, June). Blockchain based access control.
In IFIP International Conference on Distributed Applications and Interoperable
Systems (pp. 206-220). Springer, Cham.
[15] Azaria, A., Ekblaw, A., Vieira, T., & Lippman, A. (2016, August). Medrec: Using
blockchain for medical data access and permission management. In 2016 2nd
International Conference on Open and Big Data (OBD) (pp. 25-30). IEEE.
[16] Internet Engineering Task Force (IETF), “Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication Procedures,” RFC 1421, 1993.
53
[17] European Computer Manufacturers Association (ECMA), “The JSON Data
Interchange Syntax”, ECMA-404 2nd Edition, 2017.
[18] Rogaway, P., & Shrimpton, T. (2004, February). Cryptographic hash-function basics:
Definitions, implications, and separations for preimage resistance, second-preimage
resistance, and collision resistance. In International workshop on fast software
encryption (pp. 371-388). Springer, Berlin, Heidelberg.
[19] Boneh D. (2011) Strong RSA Assumption. In: van Tilborg H.C.A., Jajodia S. (eds)
Encyclopedia of Cryptography and Security. Springer, Boston, MA.
[20] Stanford-Clark, A., & Truong, H. L. (2013). Mqtt for sensor networks (mqtt-sn)
protocol specification. International business machines (IBM) Corporation version, 1,
2.
[21] Back, A. (2002). Hashcash-a denial of service counter-measure.
[22] Nakamoto, S. (2008). A peer-to-peer electronic cash system. Bitcoin.–URL:
https://bitcoin. org/bitcoin. pdf.
[23] D. Johnston, S. O. Yilmaz, J. Kandah, N. Bentenitis, F. Hashemi, R. Gross, S.
Wilkinson, and S. Mason. DecentralizedApplications: Decentralized applications white
paper and spec. Visited on 2020- 03-19. [Online]. Available:
https://github.com/DavidJohnstonCEO.
[24] Ehmke, C., Blum, F., & Gruhn, V. (2019). Properties of Decentralized Consensus
Technology--Why not every Blockchain is a Blockchain. arXiv preprint
arXiv:1907.09289.
54
[25] Bartolucci, S., Bernat, P., & Joseph, D. (2018, May). SHARVOT: secret SHARe-based
VOTing on the blockchain. In Proceedings of the 1st International Workshop on
Emerging Trends in Software Engineering for Blockchain (pp. 30-34).
[26] Kshetri, N. (2017). Can blockchain strengthen the internet of things?. IT
professional, 19(4), 68-72.
[27] Abeyratne, S. A., & Monfared, R. P. (2016). Blockchain ready manufacturing supply
chain using distributed ledger. International Journal of Research in Engineering and
Technology, 5(9), 1-10.
[28] Treleaven, P., Brown, R. G., & Yang, D. (2017). Blockchain technology in
finance. Computer, 50(9), 14-17.
[29] Xu, R., Lin, X., Dong, Q., & Chen, Y. (2018, November). Constructing trustworthy
and safe communities on a blockchain-enabled social credits system. In Proceedings of
the 15th EAI International Conference on Mobile and Ubiquitous Systems: Computing,
Networking and Services (pp. 449-453).
[30] Ellison, C., & Schneier, B. (2000). Ten Risks of PKI: What you are not being told about
Public Key Infrastructure. Computer security journal, 16(1), 1-7.
[31] Haber, S., & Stornetta, W. S. (1990, August). How to time-stamp a digital document.
In Conference on the Theory and Application of Cryptography (pp. 437-455). Springer,
Berlin, Heidelberg.
Academic Vitae Michael Steward
Education The Pennsylvania State University, University Park, PA Master of Science in Computer Science and Engineering May 2020 Bachelor of Science in Computer Engineering May 2018 Experience Systems and Internet Infrastructure Security Laboratory / Penn State ARL Fall 2018 – Present Graduate Assistant • Designed permission publication and revocation system based in blockchain. Permissions are summarized using
Merkle Trees while revocations are summarized using Bloom Filters, allowing our system to scale globally. • Implemented blockchain network using Hyperledger Fabric, Docker, and Golang. • Presented system design and rudimentary implementation at SACMAT 2019. • Implemented Hyperledger Fabric SDK using Golang. The SDK is called by webserver allowing smart contracts
on the blockchain to be executed via HTTP calls. • Created a web-application using AngularJS allowing users to invoke smart contacts, and query the ledger
through a GUI. Penn State Applied Research Laboratory Summer 2016 – Summer 2018 Waged Undergraduate - Applied Enterprise Systems Department • Setup BuildRoot environment for automated cross-compilation, allowing embedded ARM devices to run
various services developed in house. • Developed and maintained ngBoltJS, an open-source web application framework developed by ARL R&D
Engineers. • Implemented SSL email client using OpenSSL and Boost. An automated Windows task made use of this client
to email application developers in the event the application encountered an error, severely reducing debugging time.
• Developed enterprise-level application for asset tracking using AngularJS, Spring, Groovy Grails, Apache Camel and PostgreSQL.
Academic Projects Survey of Programs Vulnerable to Data-Only Attacks Spring 2019 Graduate-Level Program Analysis • Wrote data-only payloads and a small test program using SPL, a high level language for writing payloads, and
C respectively. • Generated and analyzed control flow graphs using angr, a platform-agnostic binary analysis framework written
in Python. • Gathered a set of 323 programs. Each program was then compiled for x64 using GCC (optimization levels 0
and 1) and Clang (optimization levels 0 and 1). In total out dataset consisted of 1292 binaries. • Ran BOPC, a tool for automatically finding execution traces in a binary that execute a desired payload while
adhering to the binaries control flow graph. The payload used for testing executed an infinite loop. Code-Reuse Attacks Fall 2018 Graduate-Level Computer and Network Security • Produced code-reuse attacks my means of buffer-overflow, heap-overflow, and buffer-overread. • Used objdump to find the address of system@plt and strncpy@plt within the provided binary. • Constructed exploit payload to overflow a function pointer in a data structure allocated on the heap. The payload
redirects the function pointer to a system@plt and calls the function pointer with the parameter /bin/sh. • Exploited the fact that strncpy does not guarantee a null terminator to perform a buffer-overread, leaking the
address of a data structure. Using this leaked address I constructed a payload to overwrite the data at the leaked address using a buffer-overflow.