design and implementation of key exchange mechanisms for

Master of Science in Telecommunications EngineeringOctober 2020

Design and Implementation of KeyExchange Mechanisms for Software

Artifacts using Ocean ProtocolBhavith Patnam

Myadam Nishkal Gupta

Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology inpartial fulfilment of the requirements for the degree of Telecommunications engineering. Thethesis is equivalent to 20 weeks of full time studies.

The authors declare that they are the sole authors of this thesis and that they have not usedany sources other than those listed in the bibliography and identified as references. They furtherdeclare that they have not submitted this thesis at any other institution to obtain a degree.

Contact Information:Author(s):Bhavith PatnamE-mail: [email protected]

Myadam Nishkal GuptaE-mail: [email protected]

University advisor:Dr. Kurt TutschkuDepartment of Computer Science

Faculty of Computing Internet : www.bth.seBlekinge Institute of Technology Phone : +46 455 38 50 00SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57

Abstract

During the modern times, innovators and researchers developed a key technologyknown as Artificial Intelligence (AI) Marketplace which leverages the power of AI toefficiently utilize the data generated by millions of devices to create new and betterservices and software products. H2020 Bonseyes is one such project that provides usa collaborative cloud based model of the AI marketplace for the users who generallydon’t have access to large data sets, algorithms etc by allowing them to collaboratewhich each other and exchange the software artifacts. Collaboration leads to issuesrelated to authentication and authorization which are addressed by Public Key In-frastructure(PKI).The main component of the PKI is the Certificate Authority whichacts a anchor of trust, whose architecture is designed to be centralized. Centralizedarchitecture is prone to many attacks and also failures which makes it vulnerableand weak.The adverse effects of the CA based PKI can be avoided by implementinga distributed PKI.

This thesis focuses on a hybrid methodology consisting of Qualitative and Quanti-tative analysis by performing a literature review for accumulating knowledge from theOcean Protocol which is a decentralized AI marketplace.The thesis aims to designand implement the framework used in the ocean protocol and evaluate its perfor-mance.The thesis also aims to develop a reference framework to be compatible withthe Bonseyes Project. Moreover, our research also provides the reader with the con-cepts and technologies used in other implementations of distributed PKI.

Keywords: Bonseyes AI Marketplace, Ocean Protocol, Public Key Infrastructure,Distributed Public Key Infrastructure,Secret Store functionality.

Acknowledgments

The entire process of our Master Thesis has been an incredible learning experience forus where we accumulated knowledge on new technologies that provide solution to thereal world problems. We would start by thanking the almighty followed by our mentorand supervisor Dr.Kurt Tutschku for guiding us and providing insights from hisexperience throughout our research. We would also like to thank our supervisor forconstantly encouraging and supporting us through the days where our research wasnot going in accordance to our plan, lucky enough that having frequent sessions withhim helped us stay on track and complete our thesis. Next we would like to thankour university Blekinge Institute of Technology for providing us with the necessaryresources. Lastly we would like to thank our parents and friends for everything weare today.

iii

Contents

Abstract i

Acknowledgments iii

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Contribution to the thesis . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Related Work 72.1 Research Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Formal Experiment . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 A Blockchain-based PKI framework proposal . . . . . . . . . . 102.2.2 Smart Contract-assisted Public Key Infrastructure . . . . . . . 102.2.3 Cloud Blockchain-based Public Key Infrastructure . . . . . . . 102.2.4 Blockchain-based certificate Transparency and Revocation Trans-

parency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.5 Comparision of Blockchain-based PKI Implementations . . . . 112.2.6 Remme Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.7 Certcoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.8 Blockquick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.9 Blockchain enabled API marketplaces . . . . . . . . . . . . . . 122.2.10 Nubo virtual Marketplace . . . . . . . . . . . . . . . . . . . . 12

3 Key Technologies 133.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 133.2 The Bonseyes AI Marketplace and Secure Virtual Premise . . . . . . 15

3.2.1 Layered Architecture of Bonseyes . . . . . . . . . . . . . . . . 153.2.2 Bonseyes Marketplace . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Secure Virtual Premise . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Ocean Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.1 Why Ocean Protocol? . . . . . . . . . . . . . . . . . . . . . . 21

v

3.4.2 Parity ethereum and Secret Store Functionality . . . . . . . . 213.5 ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Solution 254.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Secret Store in Ocean Protocol . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.2 Architectural Design of Secret Store . . . . . . . . . . . . . . . 264.2.3 Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.1 Implementation and Analysis of the Secret Store . . . . . . . . 304.3.2 Platform for Testing . . . . . . . . . . . . . . . . . . . . . . . 304.3.3 Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . 324.3.4 Configuring Secret Store . . . . . . . . . . . . . . . . . . . . . 324.3.5 Document Encryption . . . . . . . . . . . . . . . . . . . . . . 344.3.6 Decryption of Document . . . . . . . . . . . . . . . . . . . . . 384.3.7 Permissioning Contract . . . . . . . . . . . . . . . . . . . . . . 414.3.8 Reference Secret Store Framework Implementation for Bonseyes 42

5 Discussion and Analysis 475.1 Research Questions and Answers . . . . . . . . . . . . . . . . . . . . 47

6 Conclusions and Future Work 536.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

References 55

A Appendix A 59A.1 Secret-Store framework scripts . . . . . . . . . . . . . . . . . . . . . . 59A.2 Scripts for redesigned framework . . . . . . . . . . . . . . . . . . . . 59

vi

List of Figures

1.1 Pie Chart of the contribution . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Layered Architecture of Bonseyes . . . . . . . . . . . . . . . . . . . . 153.3 Architecture of Secure Virtual Premise . . . . . . . . . . . . . . . . . 173.4 Architecture of Compute host . . . . . . . . . . . . . . . . . . . . . . 183.5 Structure of the blockchain . . . . . . . . . . . . . . . . . . . . . . . . 193.6 Ocean Protocol Network Architecture . . . . . . . . . . . . . . . . . . 203.7 elliptic curve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Architectural overview of the Framework . . . . . . . . . . . . . . . . 264.2 Architecture of the Secret Store . . . . . . . . . . . . . . . . . . . . . 274.3 Alice requesting the secret store for signing key . . . . . . . . . . . . 284.4 Communication between secret store nodes for generation of Keys . . 294.5 Azure Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.6 SSH login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.7 Specification of the Virtual Machine . . . . . . . . . . . . . . . . . . . 314.8 Specification of the Virtual Machine . . . . . . . . . . . . . . . . . . . 314.9 Users Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . 324.10 Secret Store Node 1 configuration file . . . . . . . . . . . . . . . . . . 334.11 Secret Store Node 1 configuration file . . . . . . . . . . . . . . . . . . 334.12 Alice’s Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.13 Document Key ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.14 Signed Document ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.15 Public portion of Secret Store Server Key . . . . . . . . . . . . . . . . 364.16 Document Key from Secret Store Key . . . . . . . . . . . . . . . . . . 364.17 Hex encoding of the document . . . . . . . . . . . . . . . . . . . . . . 374.18 Encrypting the document . . . . . . . . . . . . . . . . . . . . . . . . 374.19 Storing Document on Secret Store . . . . . . . . . . . . . . . . . . . . 384.20 Secret Store Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.21 Signing Document Key ID using Bob’s account . . . . . . . . . . . . 394.22 Retrieval when only 2 nodes are working . . . . . . . . . . . . . . . . 404.23 Decrypting the document . . . . . . . . . . . . . . . . . . . . . . . . . 414.24 Decoding the Document . . . . . . . . . . . . . . . . . . . . . . . . . 414.25 Bob requesting Alice for the data . . . . . . . . . . . . . . . . . . . . 434.26 Adding contract to the blockchain . . . . . . . . . . . . . . . . . . . . 43

vii

4.27 Obtaining the signing key . . . . . . . . . . . . . . . . . . . . . . . . 444.28 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.29 Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.30 Authentication using blockchain . . . . . . . . . . . . . . . . . . . . . 45

5.1 Disk space used in openethereum . . . . . . . . . . . . . . . . . . . . 505.2 CPU performance during encryption and decryption . . . . . . . . . . 50

A.1 Secret Store Framework Implementation and Evaluation Scripts . . . 59A.2 Scripts of Redesigned Framework . . . . . . . . . . . . . . . . . . . . 60

viii

List of Tables

1.1 Contribution to the Thesis . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Digital Libraries used for research papers . . . . . . . . . . . . . . . . 82.2 Data Extraction Form . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Specifications of the Computer . . . . . . . . . . . . . . . . . . . . . . 434.2 Time Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Performance analysis of secret store processes in different iterations . 495.2 Average performance analysis of the secret store from the ocean protocol 495.3 STRIDE Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . 50

ix

Acronyms

AI Artificial Intelligence.

API Application Progrmming Interface.

CA Certificate Authority.

CD Continuous Delivery.

CI Continuous Integration.

CRL Certification Revocation List.

CSP Credential Service Provider.

CT Continuous Testing.

DDO DID Descriptor Object.

DDoS Distributed Denial of Service.

DID Decentralized Identifier.

DNS Domain Name Service.

DoS Denial of Service.

DSA Digital Signature Algorithm.

ECC Elliptic Curve Cryptography.

ECDSA Elliptic Curve Digital Signature Algorithm.

HTTPS Hyper Text Transfer Protocol Secure.

IP Internet Protocol.

MITM Man In The Middle.

PaaS Platform as a service.

PKI Public Key Infrastructure.

xi

RA Registration Authority.

RDP Remote Desktop Protocol.

RFC Request For Comment.

RPC Remote Procedure Call.

SEA Service Execution Agreement.

SHA Secure Hash Algorithm.

SLA Service-Level Agreement.

SSH Secure Shell.

SSL Secure Socket Layer.

SVP Secure Virtual Premise.

TOML Toms Obvious Minimal Language.

TPM Trusted Platform Module.

TSS Time Stamping Service.

VA Verification Authority.

VM Virtual Machine.

WoT Web of Trust.

xii

Chapter 1

Introduction

1.1 Background

The massive amounts of data generated by millions of devices being added to theinternet is giving rise to new data-driven economies. The data that is generatedmust be efficiently utilized to improve technologies and provide better services. Ar-tificial Intelligence leverages this massive data generated and assists in optimizingthe services. To take advantage of the AI technology requires a huge amount of dataand efficient algorithm to train and evaluate the data. However not everyone hasaccess to such large sets of data, especially smaller organizations creating a datawalleffect. The H2020 Bonseyes project aims to address this datawall effect by creatinga collaborative cloud-based AI marketplace [1]. It allows various parties to collabo-rate and exchange their AI artifacts for creation of efficient AI models. The majorissues in such a collaboration are authentication and authorization. Public Key In-frastructure PKI is employed to address this issue. The public key infrastructurecomprises of trusted third-party called Certificate Authorities CA which act’s as ananchor of trust that is responsible for providing digital identity to an individual.However, such centralized architecture of trusted entities which are prone to attacksand failures opens opportunities for the attackers to perform Man-In-The-Middle(MITM) attack which includes DNS/IP spoofing, SSL hijacking, HTTPS spoofing,Man-In-The-Browser and many more which in practice may lead to compromisingthe CA. To overcome such adversities in CA-based PKI we move to a distributedimplementation of public key infrastructure.

Ocean protocol [2] explores one such possibility of a Distributed Public Key In-frastructure in its implementation. This thesis aims to explore the possibility ofimplementation of distributed key exchange mechanisms in the Bonseyes projectusing the ocean protocol.

Bonseyes project

Bonseyes project is Horizon 2020 project that aims to provide a Platform-as-a-service(PaaS) for collaborative cloud based AI Engineering.The project aims to addressthe datawall issue by implementing agile methods i.e.use of Continuous Integration(CI), Continuous Testing (CT) and continuous delivery (CD).The major conceptsinvolved in the design of marketplace are Component based software engineeringby AI artefacts,Use of containers for deployment,Use of AI pipelines for distributedengineering,Use of PaaS for executing AI pipelines.The key elements of the Bonseyes

1

2 Chapter 1. Introduction

project are the Bonseyes Marketplace and Secure Virtual Premise (SVP) [1].

Ocean Protocol

Ocean protocol is a decentralized data exchange protocol and network that incen-tivizes the publishing of AI artifacts on the network. The protocol aims to provide atokenized ecosystem for exchange of AI artifacts such as data and rewards the usersof network and users uploading data to commons for the use with ocean tokens.These ocean tokens act as a form of currency for the participants in the network.Thenetwork is designed in a way to address he issues of data escapes wherein the controlover the data is not last and incentivizing the data made available to commons.Thenetwork is also designed to self-sustain and improve over the course of time withimplementation of bounties for participation and improvisation of the network [2].

Research Problem

The driving technology being employed by organisations and corporations around theworld for optimising their services and improving their technologies is adaptation ofArtificial Intelligence.The other key part is the progress towards a cloud-based envi-ronment for the services.However the effective utilisation of AI requires huge amountsof data and efficient algorithms.The drive for these high data are giving rise to data-driven marketplaces.The major issue in these collaborative marketplaces is the trustamong parties.A popular solution is the use of Public Key Infrastructure[3] to ad-dress the authentication and authorization.However the popular CA based modelis centralized and consists of a potential single point of failure in case of maliciousattacks.This thesis aims to study the solutions employed in some of popular decen-tralized marketplace networks and evaluate their significance and implementation inmicro-service based architectures such as the Secure Virtual Premise (SVP) of theBonseyes project.

1.2 Aims and Objectives

The Aim of the thesis is to evaluate the implementation of key exchange mechanismsemployed in Ocean Protocol and the performance of the functionality.The thesisthen aims to address the possibilities of such an implementation in micro-servicearchitecture such as the Secure-Virtual Premise of the Bonseyes Project.

The Objective of the thesis is to:

• Investigate the ocean protocol for the key exchange mechanisms implementa-tion and the functionalities that can can be achieved through such an architec-ture.

• Investigate the implementation of the key exchange mechanisms in ocean pro-tocol to the SVP.

• Evaluate the performance of the functionality implemented.

1.3. Research Questions 3

1.3 Research Questions

The objectives described are used to define the research questions the thesis aims toaddress

• RQ1 : How are the key exchange mechanisms implemented in the Ocean pro-tocol network.

• RQ2 : Evaluate the possibility of implementation of such a functionality in theBonseyes SVP.

• RQ3 : Evaluate the performance of the Secret Store in the ocean protocol.

1.4 Outline

The thesis documentation consists of six parts.Chapter one provides a basic insightsinto the concepts involved in the research and problems of current key exchangemechanisms being implemented.It describes one of the use case of these key ex-change mechanisms and aims to provide a distributed solution for the key exchangemechanism in the particular use case. Chapter two describes the related work beingimplemented and researched in the field of distributed key exchange and exploresalternatives implemented in other implementation of marketplaces. Chapter threedescribes the key technologies involved in this study and the research method em-ployed to analyze and evaluate the solutions to the problems described. Chapter fourprovides the solution developed based on the study of the current implementationand the necessary tailoring to model the solution to the considered implementation.This chapter describes the architecture, working and the process of implementation ofthe solution designed to solve the research problem. Chapter five enables the readerto have a proper insight into the evaluation of the solution designed. By readingthis chapter one could gain analytical knowledge of the results obtained from im-plementation. We also provide the answers to the research questions framed in thechapter one. Chapter six provides conclusion to the entire research by highlightingthe important findings and summarizing the results obtained. This chapter also triesproviding the future work that can be carry forwarded for improving and makingnew findings in the topic.By the end of this chapter we expect that the reader hascomplete understand a working knowledge about our research.

1.5 Contribution to the thesis

The thesis includes a lot of work from theoretical research to experimental imple-mentation and analysis.This section depicts the amount of work contributed by eachauthor to the research. Below is the table which represents the various topics involvedin the research along with the author who contributed to it.

4 Chapter 1. Introduction

Topic of the research Author1 - Bhavith Author2 - NishkalBackground �Aims and Objectives �Research Questions and Outline �Research Method �Related Work �Key Technologies �(Public Key InfrastructureThe Bonseyes AI Market place)Key Technologies �(BlockchainOcean Protocol)Solution � �(ArchitectureWorkingImplementation of Secret Store)Discussion and AnalysisResearch questions(RQ1 �RQ2 � �RQ3) �Performance Analysis �Conclusion and Future Work � �

Table 1.1: Contribution to the Thesis

Figure 1.1: Pie Chart of the contribution

Above is the graphical representation of the amount of work contributed to the

1.5. Contribution to the thesis 5

thesis by each author individually. The work was divided by considering the strengthsand weakness of the authors moreover the work was assigned to each other in mannerthat all the major parts of the research was covered.

Chapter 2

Related Work

2.1 Research Method

The adapted research method for this thesis is a "Hybrid" research model whichis a combination of both Qualitative and Quantitative methodology which are usedfor providing solutions to the research questions mentioned in the above section.Qualitative methodology was used for answering the research questions related to theexplanation of the components and its working from the "Ocean Protocol" and the"Bonseyes SVP", where as the Quantitative methodology was used for obtaining themetric results from the framework built as part of the solution. The framework wasbuilt in accordance to the knowledge gained from the literature review performed onthe "Secret Store"[4] component from the "Ocean Protocol". The gained knowledgewas later modified to build a framework which is compatible to the "Bonseyes SVP".

Figure 2.1: Research Methodology

7

8 Chapter 2. Related Work

Below are the following methods depicted in Figure 2.1 that represent the researchmethodology of this thesis.

• Literature Review.

• Formal Experiment.

• Documentation.

Let us now discuss in detail the steps involved in these methods.

2.1.1 Literature Review

The main motive of the literature review is to gain knowledge and insight into theresearch problem defined in the thesis.

Search Strategy

This step helps us in accumulating the primary research papers that are related toour research topic. As the research area is vast we use search strategy for obtainingthe primary papers which try to provide solutions to the research questions. TheResearch involved extensive search on the topics including Public Key infrastruc-ture(PKI),the Blockchain technology as a replacement for PKI and existing imple-mentations of AI marketplaces.The literature search was structured mainly in threeareas:

• Distributed Public key Infrastructure

• Blockchain technologies to enable PKI

• AI and API marketplaces

The literature search involved searches in popular databases such as the IEEE Xploreand the ACM digital library as seen in table 2.1 below.The result for the searchesyielded various papers which were analysed,by their abstract and conclusion,regardingtheir relevance to the research topic and the selective criteria allowed to narrow downthe results.

Digital libraries

IEEE

ACM

Table 2.1: Digital Libraries used for research papers

2.1. Research Method 9

Inclusion-Exclusion Criteria

This step is further carried out to refine our search by limiting the selected researchpapers to our research problem. This is achieved by adding few inclusion/exclusioncriterion’s.Inclusion criteria

• Paper which are written in English.

• Papers based on decentralized Public Key Infrastructure.

• Papers based on distributed Public Key Infrastructure.

• Papers which emphasize on Artificial Intelligence Market Place.

• Papers focusing on Blockchain based Public Key Infrastructure.

Exclusion criteria

• Unpublished papers.

• Papers that doesn’t address the research questions.

• Papers that doesn’t focus on distributed key exchange mechanisms.

Data Extraction and Analysis This step involves in extraction and analysis of accu-mulated data from the final selected research papers. It’s aim is to provide solutionsand resolve the research questions.It uses a Qualitative approach by providing theo-retical knowledge about the problem we are dealing with.A data extraction form as seen below is used to fill different attributes from thefinal selected research papers. This helped us categorize and analyze the importantinformation which further guided us in obtaining answers to our research problems.

Paper.No Title Author Research Area

Table 2.2: Data Extraction Form

2.1.2 Formal Experiment

This method is where we get our hands dirty by implementing a framework fromthe knowledge obtained through the literature review. We design a framework thatprovides a distributed approach from exchanging keys for signing and verifying asoftware artifact. The literature review provided us with the knowledge about howthe Ocean protocol implemented their version of framework.We take insights fromthem and build our version of framework which is compatible with the BonseyesSecure Virtual Premise. This method is broken down into 3 steps:

• Architecture or Design of the Framework


• Implementation or Working of the Framework

• Analysis of the results obtained as the output of the Framework.

The architecture and working of the framework are described in the coming Chap-ter4 - Solution, Section 4.1 and 4.2 respectively, where as the data collectionand its analysis is discussed in the Chapter 5 - Discussions and Analysis.

2.1.3 Documentation

The last method involved in the methodology is documentation of the solutions tothe research questions which is done in the Chapter 5.

2.2 Related WorkThis section describes the related work done in the field of distributed key exchangeinfrastructure implementations and various use cases of AI marketplaces and theirimplementations. There are several works being researched in the field of distributedpublic key infrastructure.Some of these research works are listed below.

2.2.1 A Blockchain-based PKI framework proposal

[5] provides an interesting approach to address the issues in CA-based PKI.It pro-vides a blockchain based framework to address the issues of certificate revocation,elimination of single points-of-failure and CAs misbehavior.The framework provides aset of extensions to be added to the X.509v3 certificates to incorporate the additionaldetails on Blockchain used and information regarding the CA.

The framework however doesn’t address the issues that arise due to the strengthof the encryption scheme involved and the generation and distribution method ofkeys.

2.2.2 Smart Contract-assisted Public Key Infrastructure

[6] proposes a Smart Contract-assisted PKI (SCP) protocol to manage dynamic trustin the PKI ecosystems.It addresses the lack of certificate transparency (CT),which isrequired to keep check of mis-issued certificates by CA, and inadequacies in existingsystem to convey the dynamic trust in the issued certificate.A trust policy contract isimplemented among the participants which enforces the dynamic trust for a certifi-cate.This provides validation of trust in a certificate in transparent and automatedway.

2.2.3 Cloud Blockchain-based Public Key Infrastructure

[7] proposes integration of PKI with existing blockchain and cloud technologies toaddress the issue of trust in IoT devices.It protects the certificate authority (CA) byutilising the security measures implemented in cloud networks from attacks such asDenial of Service (DoS).The cetificate data is stored in the blockchain network to

2.2. Related Work 11

avoid caching issues and DoS attacks.The certificate data stored in smart contractsprovides a significant improvement in accessing and security over data stored in blockstorage however this also results in a increased operational cost.

2.2.4 Blockchain-based certificate Transparency and Revoca-tion Transparency

The use of global append-only blockchain for certificate and revocation status is pro-posed by [8].The certificates are published as transactions in the immutable ledgerthus providing a continuous history for the certificates.[8] provides a certificate valida-tion and delegation services for browsers and the key pairs used are controlled by CA’sand a group of trusted web servers.In case of attacks these servers are responsiblefor signing countermeasure transactions and recover their certificates.The cetificatesare signed by majority of nodes before appearing in the certificate blockchain.

2.2.5 Comparision of Blockchain-based PKI Implementations

A comparison of various blockchain based implementations of Public Key Infrastruc-ture are studied and compared based on various metrics in [9].The implementationsare compared based on type of blockchain,type of PKI,the storage type that indicateswhat data is stored on-chain and what data off-chain and various evaluation parame-ters such as use of Distributed hash tables,updatable keys,privacy,incentives,complexityand cost.The paper reports that no implementation explicitly consider privacy-enhancingtechnologies in their implementations.

2.2.6 Remme Protocol

One of the implementations of distributed public key infrastructure is the RemmeProtocol.The protocol is built on top of EOSIO blockchian,which powers one of thepopular cryptocurrency.The protocol employs Byzantine Fault-tolerant DelegatedProof of Stake(BFT-DPOS) as the consensus algorithm .Delegated proof-of-stakeis a robust consensus mechanism where the block producers are selected based onvoting system where a entity called guardian and other account holders vote.Theblock producers are responsible for creating blocks every 0.5 seconds[10].

The protocol proposes a public blockchain called REMchain that is powered byREM tokens which is responsible for storing the data such as the public keys,keymetadata,identity data and enables various distributed applications(dAPPs) for thefunctionalities and supporting tools [11].

DPOS ensures that there are no forks of the blockchain and there are no two blocksproduced at the same time thus providing a secure and disruption-free consensus [12].

However this protocol relies on tokens to select block producers and promotesthe accumulation of tokens for electing the guardian and the subsequent block pro-ducers.Such a selection process may lead to failure in network if a malicious entityis elected as a guardian and the network fails in case of a poor token distribu-tion.This protocol also doesn’t addresses the issues with encryption involved andkey-distribution.


2.2.7 Certcoin

Certcoin is another implementation of a distributed PKI.The method involves twomajor changes to the PKI infrastructure wherein they present the use of decen-tralized platform such as Namecoin [13],a fork of bitcoin and a blockchain basedcryptocurrency,and enchanced Web of Trust approach wherein a majority of usersare needed to sign a certificate to validate it.The project mainly focuses on the issueof Identity Retention and doesn’t clearly address the issue of problems in encryptionschemes.The protocol also employs Proof-of-work as its consensus algorithm whichmay not be suitable for all use cases [14].

2.2.8 Blockquick

Blockquick is a lightweight client protocol for implementation of PKI functionalitiesusing the ethereum blockchain majorly focusing on the IoT devices.The protocol isdesigned to run on devices with low power and RAM requirements [15].

2.2.9 Blockchain enabled API marketplaces

As the paper [16] suggests there have been significant implementations of cloud basedAPI marketplaces especially for AI development.The various cloud based AI mar-ketplaces implemented are [17],[18],[19].However these are monolithic marketplacesinvolving services constrained to their provisioning.Collaboration between variouscloud tenants in such a system is difficult and such marketplaces require completetrust in cloud provider for the services.The paper proposes a decentralized blockchainbased market place,similar to the ocean protocol network,for such api marketplaces.

2.2.10 Nubo virtual Marketplace

Nubo virtual marketplace [20] is a Ericsson developed blockchain-based market-place.It provides a trustworthy platform on which various service providers can offertheir services in a distributed manner.The implementation relies on single system im-age (SSI) [21] in cloud services.SSI is a globalized view of cluster of system resourcesas a single system to the user. The design features of nubo virtual marketplace are:

• Handle tenant and service identity authentication.

• Allow advertising of resources

• Provide proof of authorization of services to tenants

• collect service usage information from tenant for billing

• Allow cloud service providers to list their offerings on marketplace

The marketplace consists of nubo portal which provides a user interface for themarketplace,the saranyu dApp that provides a tenant and service management RESTAPI and communicates with the blockchain,Quoram blockchain microservice thatrecords the tenant resource offerings and their smart contracts ,Cassandra NoSQLdatabase for storing service usage data,Service manager for single tenant services.

Chapter 3Key Technologies

This section describes the Key technologies involved in the public key infrastructureand the functionalities of the ocean protocol.The key exchange mechanisms in theocean protocol are studied,evaluated and their possibility of implementation in theSVP is assessed.

3.1 Public Key InfrastructurePublic Key Infrastructure (PKI) is a technological implementation for securely au-thenticating the identities. It is an ecosystem for establishing trust in electronicworld.There are various technologies that are generally introduced and expire outbut public key infrastructure has undergone evolution and established itself as ade-facto as enabler for trust [22]. The Internet Engineering Task Force(IETF) isresponsible for designing and developing this widely used medium of trust.The IETFdefines the guidelines for such technologies in form of text documents called Re-quest For Comments(RFC) [23]. The major components comprising the public keyinfrastructure as defined in the RFC are:

• Certificate Authority(CA) responsible for issuing and revoking certificates.

• Registration Authority(RA) an optional entity to which CA can delegate someresponsibilities such as binding of public keys and certificate holder identity.

• Certificate Revocation List(CRL) issuer is the entity responsible for signingthe certificate revocation list which lists the malicious entities certificates asuntrustworthy.

• repository that stores certificates and certificate revocation list(CRL) and makesthem available.

• Client which is the end subject of a certificate.

Public Key Infrastructure involves asymmetric encryption wherein a cryptograph-ically linked public key to a private key is used to identify and authenticate anentity.The public key is bound to an entity by a digital certificate and RegistrationAuthority (RA) is responsible for accepting requests for digital certificate and au-thenticating the entity making the request to the certificate authority (CA).The CAthen issues a digital certificate binding the entity to the public key.A requester canverify the authenticity of the service by this digital certificate.A validation authority

13

14 Chapter 3. Key Technologies

(VA) can provide the information on behalf of CA. PKI defines policies and proce-dures to issue, manage,distribute and revoke digital certificates which is a documentcontaining the public key, the identity of key owner and the signature of the trustedthird-party entity, the certificate authority, verifying the contents of certificate. Themanagement of public keys is based of X.509 standard which verifies the ownershipby external entities by Certificate Authorities(CA) [3].

Figure 3.1: Public Key Infrastructure[24]

A SWOT analysis is performed by [22] for the PKI ecosystem which describes:

• Strength of a PKI ecosystem as the flexibility to accommodate and assimilatetechnologies

• Weakness as absence of globally anchored trust model and cross-nation certifi-cation issues

• Opportunities in the cloud and Internet of Things(IoT) technologies.

• Threats in cohesiveness among stakeholders and the exploitation of CA infras-tructure.

The issues that may arise in the traditional PKI infrastructure are the mathematicalhardness of problems based on which key is generated and the implementation of theCA-based architecture [25].

The CA model of PKI in use is vulnerable to attacks. The weakness of such amodel is the centralized architecture. It presents a single point of failure that couldleave the system vulnerable to attacks from external entities. If a CA is compromisedthe certificate issued by such entity authenticating fake keys could expose the user toattacks. The other issue concerning the CA model is the certificate revocation. The

3.2. The Bonseyes AI Marketplace and Secure Virtual Premise 15

current implementation for certificate revocation involves periodical revision of cer-tificate revocation lists during which there exist a period when untrusted certificatesare in use until they are published [3].

One of the solution proposed to resolve this issue in CA is the utilization of publiclogs to manage certificates where public-log servers monitor and publish certificatesissued by CAs. This improves transparency and resolves the issue of untrustedcertificates in use by utilizing publicly logged certificates to be accepted and trustedby end user. However, this model doesn’t solve the issue of certificate revocation [3].

Another solution proposed is the use of Web of Trust (WoT) approach whichis a decentralized where in users are able to designate others as trustworthy bysigning their public key certificates. However, this approach doesn’t address theissue of certificate revocation and user is restricted to choosing another user to be"designated revoker" when the private key is lost or compromised [3].

3.2 The Bonseyes AI Marketplace and Secure Vir-tual Premise

The Bonseyes is a European Horizon 2020 funded project that provides a decentral-ized platform for researchers and developers to collaborate in AI development.Theadvances in the field of AI has led to incorporating the it in various general pur-pose applications and assist the service providers.It helps in optimising services andthereby improve the user experience in the services they receive.It incorporates theagile methods of Continuous Integration,testing and delivery to reduce the time inAI development[1].

The project utilises AI pipelines to facilitate the AI development.The tools in-volved in these AI pipelines such as Data Extraction,training and deployment toolsare the AI artifacts which are deployed in container environments.

3.2.1 Layered Architecture of Bonseyes

The high level layout of the AI marketplace is as follows:

Figure 3.2: Layered Architecture of Bonseyes[26]


where

• The marketplace layer is the layer responsible for collaboration between in-novators and developers.The functionality of this layer is to provide an userinterface for searching and trading AI artifacts.

• The artifact layer consists of AI artifacts and Bonseyes Layer.This layer is re-sponsible for providing interfaces to marketplace and AI workflow.It is alsoresponsible for enforcing license and controlling storage and execution environ-ment.

• The Resource layer is responsible for providing a federated and safe executionenvironment for AI artifacts and safe storage for these AI artifacts.

• Staging pipe provides a cross-layer orchestration for AI pipeline.It providesinterfaces to interact with AI pipelines and artifacts.It manages access to theSecure Virtual Premise (SVP) and provides users with an interface to interactwith the artifacts through SVP.

The two major core elements in this project are the Bonseyes Marketplace and SecureVirtual Premise[1].

3.2.2 Bonseyes Marketplace

The Bonseyes Marketplace is user interface for the developers and researchers tocollaborate,find and agree on the terms and conditions for exchange of AI arti-facts.The marketplace is used to exchange artifacts and generate appropriate licensesfor them.The Marketplace interacts through the underlying Secure virtual Premise(SVP) to access these artifacts and use the AI pipelines based on consensus reachedamong the parties involved [26].

3.2.3 Secure Virtual Premise

Secure Virtual Premise (SVP) is the component responsible for securely executingan AI pipeline and storing the marketplace’s corresponding AI artifacts.It provides asecure Platform-as-a-Service (PaaS) by acting as a shield for the artifacts.The SVPis designed in such a way that the platform can handle the adversaries from outsideand also inside[1].

3.2. The Bonseyes AI Marketplace and Secure Virtual Premise 17

Figure 3.3: Architecture of Secure Virtual Premise[27]

The two major components of the SVP are:

• Controller Host which is responsible for establishing trust between users andtheir services.It is responsible for implementing the security manager and thepublic key infrastructure.

• Compute Host which provides a safe environment to run containeraized AIartifacts and AI pipelines and stores the artifacts safely

The architecture of CA is based on NIST guidelines for digital identities[27].Thearchitecture involves:

• Credential Service Provider (CSP) which is responsible for registering the userfor a digital identity thereby allowing him to utilise the platform and re-sources.Credential Service Provider consists of two functions which are Reg-istration Authority (RA) and Certificate Authority (CA).A claimant proveshis/her identity to the registration Authority.Upon successful validation ofclaimant,the Registration Authority requests the Certificate Authority func-tion to issue a digital certificate,in the X.509 format,for the user.

• Verifier which interacts with the user to ascertain whether a the user is a validsubscriber or not.It also contacts CSP to obtain additional information aboutthe subscriber.

• Relaying party (RP) which completes the authentication based on the infor-mation from verifier and completes the authorization for the request by thesubscriber based on the Role-Based Access Control (RBAC).There are two in-stances of relaying party in the SVP,one in the Controller API and the otherin the Bonseyes Layer API.

The architecture of Bonseyes utilises proxy based architecture to provide securityfor artifacts by providing separation [28].The architecture employs a reverse proxycalled Bonseyes Layer to provide the separation needed between user and the AIpipelines to provide better security.


Figure 3.4: Architecture of Compute host[27]

The Bonseyes layer is implemented next to artifacts as it is responsible for man-aging AI pipelines and it filters commands so that regular users cannot escalate theirprivilege and misuse the artifacts.

3.3 Blockchain

Blockchain is a distributed and continuously growing list of records, called blockswhich are chained and secured using cryptography. The initial idea of blockchainwas introduced in the year 1991 by Stuart Haber and W. Scott Stornetta due tothe issue raised on "how to certify the digital data based on it’s creation and lastmodification" which was solved by performing "Time-Stamping". The naive solutionwas a "digital safety-deposit box" that functions as follows. The digital data thatas to be time stamped is sent by the client to a time stamping service. The TimeStamping Service (TSS) stores a copy of the data and records the time and date ofthe received data. Whenever the integrity of the data is questioned or challenged, itis verified by the copy present in the TSS. Though this approach provides a solutionto our issue it raises few concerns such as Privacy (eavesdropping of a third partyduring the transmission of the data which may tamper the data that is kept underdirect control of the client as well at the TSS),Bandwidth and Storage (in case oflarge digital data the amount of time and space required for transmission and storageis huge and hence it may be expensive and exorbitant) and the main concern is theTrust (the above solution has a high probability of collision between TSS and clientfor claiming the time stamp of the data)[29].

Later a new version of the TSS was introduced which included trust in themwhich was named as Trusted Time Stamping Service. The Trusted TSS had 2 majorimprovements over the previous ones which where "Hashing" and "Digital Signa-tures". Hashing was performed to restrict third party from eavesdropping, where asDigital Signature was introduced to provide authenticity of the data. The above so-lution only provided time stamping the digital data but did not provide distributionof the ledger. Blockchain was Introduced in 2008 by a person or group of peopleusing the name Satoshi Nakamoto. He adapted and modified the concepts definedby Stuart Haber and W. Scott Stornett a for introducing a cryptocurrency knownas bitcoin which is a public transaction ledger[29][30].

3.3. Blockchain 19

Bitcoin is the first digital currency that solves potential flaw of double spendingi.e. same digital token can be duplicated and used again, hence blockchain is designedin such a manner that it is resistant towards modification of data. The architectureof blockchain is mainly peer to peer based on specific protocols. The main advantageof blockchain is that the data once recorded can not be modified by a single entity,rather requires a majority of consent from other peers in the network. In layman’sterms a blockchain is a group of blocks which are interconnected to each other andhave distributed ledgers among each other in the network. The first block of theblockchain is called as Genesis Block and once the chain is initialized it remains thefirst block forever[30].

Figure 3.5: Structure of the blockchain[31]

Types of BlockchainsBlockchain are broadly classified into three categories namely: - Public - Private -Hybrid

Public BlockchainAs the name suggests the public blockchain is available for everyone to participatein the role of developer, miner or user. All the members participating in the publicblockchain have complete access to examine the transactions i.e. the transactionsare made fully transparent. One should know that public blockchains are completelydecentralized and anyone is allowed to join it, which is what that makes it merelyimpossible to shut it down because of no control or authority given to an individual orgroup of people. This type of blockchains have tokens associated with them which areused for the purpose of rewarding the participants present in the network. Examplesof public blockchain are Ethereum and Bitcoin.[32]

Private BlockchainThe second type of system is the private blockchain which is also referred to aspermissioned blockchain which allows participants to join them only with a consentor permission unlike the public blockchain. They follow a more centralized approachwhen compared with public blockchain as it limited to enterprises, group of industriesor rather group of individuals which have complete control on the structure andparticipants in the network. Transactions in these type of blockchains are availableonly to the participants of the ecosystem. These type of systems adapt a collaborativemodel to share data amongst themselves by avoiding the information being availableto the outsiders. Hyperledger is one of the examples of private blockchain.[32]


Hybrid BlockchainLast category of the three main blockchains considered are hybrid blockchains. Thesetype of blockchains possess the features of both public blockchain as well as privateblockchain. They adapt the feature of privacy from private blockchain and trans-parency from public blockchains i.e. they have the advantage of which transactionto make public and which to private.[32]

3.4 Ocean ProtocolOcean protocol is a decentralized data exchange protocol and network that incen-tivizes the publishing of AI artifacts on the network. The protocol aims to provide atokenized ecosystem for exchange of AI artifacts such as data and rewards the usersof network and users uploading data to commons for the use with ocean tokens.These ocean tokens act as a form of currency for the participants in the network.Thenetwork is designed in a way to address he issues of data escapes wherein the controlover the data is not last and incentivizing the data made available to commons.Thenetwork is also designed to self-sustain and improve over the course of time withimplementation of bounties for participation and improvisation of the network [2].

The relation between end-user and service provider is defined by the service-levelagreement(SLA) which determines the service provided and quality of service.Oceanprotocol’s implementation of service-level agreements on blockchain is called Serviceexecution agreements(SEA).Service execution agreements are primarily responsiblefor decentralized access control,dispute resolution,provenance of service consumptionand network incentives.

Figure 3.6: Ocean Protocol Network Architecture[2]

The architecture of ocean protocol is a three-tier architecture consisting of ap-plication layer,protocol layer and decentralized Virtual Machine layer.Tier-3 is the

3.4. Ocean Protocol 21

application layer consisting of pleuston which is a front-end application that providesfunctionalities such as publishing and consuming of assets and provides the datamarketplaces and data science tools used by AI researchers and data scientists.Tier-2 is the protocol layer consisting of libraries to interact with ocean protocol andkeeper contracts. The libraries that make up the core ocean functionalities aresquild library,which is main Application Program Interface(API) to the ocean pro-tocol,aquarius library which deals with metadata management and brizo librarywhich provides capabilities for publishers/service providers to publish their assetsto the marketplace.Tier-1 is the decentralized VM layer that consist of keeper con-tracts.These are solidity smart contracts which ensure proper access-control to theAI assets of the publishers [2].

AN AI asset is registered on the ocean protocol network by the publisher usingthe squid library.A Decentralized identifier(DID) corresponding to that asset is gen-erated. DIDs are unique identifiers that provide verifiable and decentralized digitalidentity [2].The DID, URL and threshold are encrypted and stored with the helpof Secret Store Then a DID Descriptor Object(DDO) corresponding to the DID inquestion is created which consists of DID, asset’s metadata, public key, encryptedURL, and list of services. The publisher of the asset now holds the DID and DDOcorresponding to the asset. The publisher then publishes the DID and DDO pair tothe marketplace running aquarius and registers DID on Ocean Keeper network [2].

The consumer can utilize the asset published on the network by searching for theasset on markets metadata. The consumer then signs the service execution agree-ment(SEA) corresponding to the service and pays through the keeper-contract.Thepublisher then runs the contract on brizo allowing the consumer to utilize the assetpaid for [2].

3.4.1 Why Ocean Protocol?

This section gives insights into the reason of why Ocean protocol is used or ratherwhat are the advantages of using the Ocean protocol. The first and most importantpoint of the Ocean protocol is it provides access to data for the use of ArtificialIntelligence for everyone without losing the control over it i.e. it provides individualswith right to privacy over the data, this is done by using Service Execution Agree-ments (SEA). SEA’s are Ocean’s version of smart contracts used in ethereum basedblockchain. Further Ocean protocol tries to address the problem of providing gen-uine data by incentivizing the users for putting data into commons, this is done byadapting cryptographic proof of service as well as network rewards. Last but not theleast ocean uses on chain bounties to provide a self sustainable as well as improvingnetwork without any centralized entity. These points make Ocean protocol stand outfrom other decentralized solutions[2].

3.4.2 Parity ethereum and Secret Store Functionality

Ocean protocol implements parity ethereum as its client software implementation.ParityEthereum is an open-source client implementation for Ethereum platform.ParityEthereum is a rust-based implementation of client for Ethereum platform that was de-veloped by Parity Inc,now maintained under the name Openethereum [4]. Openethereum


provides optional features to run private development chain for developers trying tobuild decentralized applications.The development chain can run Proof-of-Authorityconsensus algorithm providing even greater flexibility in the Distributed Applica-tion(DApp) development.One of the additional features provided in the Openethereumis the implementation of secret-store functionality.This feature consist of a cluster ofnodes responsible for implementing the functionalities of authentication and autho-risation and this feature is utilized by the ocean protocol[4].

3.5 ECDSA

In order to verify the authenticity of digital data on the internet the use of digitalsignature algorithms(DSA) are adapted. DSA’s are mathematical algorithms thatprovide a digital signature which are used for signing the data that is to be trans-mitted via the internet. DSA is based on asymmetric key encryption which involvesthe use of both public and private keys. The private key is used to sign the digest ofthe digital asset where as the verification of the signature is done with the help of itscorresponding public key. The main advantage of the DSA is the size of signaturebeing small due to signing of the digest of the data rather than the data itself. Theelliptic curve digital signature algorithm is a branch of the digital signature algo-rithm which was introduced in the year 1992 by Scott Vanstone[33].The security ofthe ECDSA is based on the computational complexity of the elliptic curve discretelogarithmic problem (ECDLP) and Elliptic Curve Cryptography(ECC). Before go-ing any further let us define the elliptic curves. Elliptic curves are considered to bearithmetic curves which are represented by a cubic equation of two variables , thegeneric form of the curve equation is represented as y2 = x3 + ax + b . One of theinteresting features of the elliptic curve is the group law i.e. existing points on thecurve lead to generation of new points on the same curve. Below is the figure thatrepresents the elliptical curve known as secp256k1 used in bitcoin and ethereum ofthe equation y2 = x3 + 7.

Figure 3.7: elliptic curve[34]

The use of elliptic curves in public-key cryptography involves the parties to agree

3.5. ECDSA 23

upon the parameters for the curve such as the Galois field p,curve constants a andb,generator point G,the order of the generator point n and the cofactor h.The domainparameters that define a curve are (p,a,b,G,n,h) [34].

In Elliptic Curve Cryptography (ECC) the sender creates a private key,d,randomlyselected in the interval of [1,n-1] and a public key,p, selected as a point on the ellipticcurve based on the private key and the generator point.

To sign a message the sender initially calculates the hash of the message.The zleftmost bits of the hash is chosen such that the leftmost bits L is the group orderof n.A cryptographically secure random number k is selected between [1,n-1] and acurve point is generated such that (x,y) = k x G.Then the signature (r,v) is calculatedsuch that r=x mod n and v=k−1(z + rd) [35].

Chapter 4

Solution

4.1 Introduction

In this chapter, we provide a detailed working of the framework developed for “KeyExchange Mechanism for Software Artifacts” with the help of the knowledge ac-cumulated from the previous chapters.The Ocean protocol network requires theOpenethereum as the client software in the implementation.The secret store func-tionality is the proxy function responsible for secure communication between the userand the network.

This chapter aims to provide the secret store functionality of the Ocean proto-col,implement the functionality independently using the configuration files and designa framework based on the secret store to be compatible with the Bonseyes project.

4.2 Secret Store in Ocean Protocol

This section gives an insight to the reader regarding the characteristics, architecture,working and implementation of the secret store framework of the Ocean protocol.

The secret store is a functionality of the ocean protocol [2] used for generationand retrieval of the key pair using the elliptic curve digital signature algorithm that isused for authenticating software artifacts to the authorized users. It tends towards adistributed approach by utilizing the features of the blockchain. It uses an ethereumbased blockchain by leveraging the feature of smart contracts from it which is adigital data representation of the agreement between the clients. The secret store initself is a collection of nodes that are responsible for generation and retrieval of thekey pair individually making it distributed.[4]

4.2.1 Characteristics

• The main and important characteristic of the Secret Store is to be distributedwhich means there should be multiple nodes that are responsible for key gen-eration and retrieval.

• Secret Store uses Elliptic Curve Digital Key Generation Algorithm [36] where akey pair is generated by multiple nodes for signing and verifying the signatureof the artifact in a distributed manner.

25

26 Chapter 4. Solution

• Secret Store must not be involved in either encrypting or decrypting the “data”sent by the client which must be done on the client-side itself and the secretstore must only be responsible for exchanging the keys for digital signing andverifying the “data”.

• Secret Store must only store the asset’s/data’s access-control keys and not thedata itself which makes it more trustworthy.

• One of the important features of the Secret Store is to provide data privacy byallowing only authenticated users to access the data/asset. This is addressedby storing permissioning contracts provided by the client.

• Access of the data/asset by the clients is authenticated by the secret store byaccessing the permisioning contracts which are stored in the blockchain. Theframework uses a private blockchain.

• The most important feature of the secret store is it provides only authenticityof the data and not the authorization of the owner of the data.

Above are the important characteristics that are taken into account while designingthe framework.[2]

4.2.2 Architectural Design of Secret Store

The secret store is designed such that the key generation and authorized key retrievalinvolves multiple nodes to function thus avoiding a single point of failure. Figure 4.1an architectural overview of the framework.

Figure 4.1: Architectural overview of the Framework

4.2. Secret Store in Ocean Protocol 27

The framework designed consists of 3 main components which are the following:

• Secret-Store nodes

• Blockchain

• Client

The Architecture requires the user nodes to communicate with one of the nodes of thesecret store and the secret store allows only authorized users to access the resourcesby utilising the permissioning contract on the blockchains.

Figure 4.2: Architecture of the Secret Store[4]

The secret store as seen in the figure 4.2 is made up of multiple nodes that areconnected to form a cluster. In the implementation, there are 3 nodes in the secretstore namely Node1, Node2 & Node3 that communicate with each other for genera-tion and distribution of keys. The framework is designed to be distributed in such amanner that no single node has information about the part of the key generated byrest of the nodes, to achieve that each node as its own database connected to it forstoring their part of public and private key pair and also for storing other relevantdetails of the client. Any client that wishes to connect to the secret store for request-ing either a signing or verifying key requests using a Remote Procedure Call (RPC)which directs the request to the node in the secret store that has a port open forconnections, this node later communicates with the rest of the nodes to generate thekey. In addition to that every node as access to the blockchain where permisioningcontract is stored by the client, the nodes utilize them for authorized access of theresources.


4.2.3 Working

This section defines in detail the stepwise working of the framework. Let us consider ascenario where two clients,Alice and Bob, interact with the secret store for generatingand retrieving the signing-verifying key pair to securely exchange an artifact.

• Step 1:The first step involves Bob asking for a software artifact present withAlice.

• Step 2 : In this step, Alice generates and stores the hash and signature of thesoftware artifact requested by Bob. The algorithm used for signing the hash isan elliptic curve digital signature algorithm(ECDSA) [36].

• Step 3 : After the step2, Alice connects to the secret store requesting a publickey which will be later used by Alice to sign the encrypted resource that as tobe sent to Bob. Alice connects to the secret store via an API. After connectingto the secret store Alice sends hash and the signature of the hash. Alice addsa block to the blockchain whose data includes permisioning contract which hasthe list of nodes that are allowed to access the artifact, hence it enhances thesecurity by making it distributed.

Figure 4.3: Alice requesting the secret store for signing key

• Step 4 : Once the secret store receives the data sent by Alice it starts gener-ating the key pair required for encrypting and decrypting the encoded softwareartifact. The message for generating the key is received by one of the nodeswhose port is open for connections from the clients via the RPC. Later thenode generates its part of the key and connects with other nodes in the secret

4.3. Implementation 29

store informing them to create their part of the key. Data sent by the client isreceived and stored in the database of all the nodes.Once all the nodes generatetheir part of the public key, it is sent to Alice.

Figure 4.4: Communication between secret store nodes for generation of Keys

• Step 5 : After public and private keys are generated by all the nodes in thesecret store, parts of the public key are combined i.e. “Public Key = pubnode1+ pubnode2 + pubnode3” and sent to Alice via the RPC. Once the public keyis received by Alice she generates the encryption key from it. Next she hexencodes the artifact and encrypts it using the encryption key. The encryptedsoftware artifact along with it’s hash is sent to Bob.

• Step 6 : In this step, Bob receives the encrypted software artifact from Al-ice.Bob then signs the Document hash and connects to the secret store re-questing for the private key via the RPC, once the request is received by secretstore it verifies with the permissioning contract for the authorization from theBlockchain. If Bob is authorized then the secret store sends him verificationkeys.The private key required for decryption can be generated by the (n+1)nodes of the secret store where n is the threshold set by Alice.

• Step 7 :Once the private key is received by Bob from the secret store he usesthem to decrypt the artifact which is encoded. The encoded artifact is thendecoded by Bob.

This scenario provides a general working of secret store to exchange artifactssecurely between users.

4.3 Implementation

This section provides the implementation of the secret store framework of theocean protocol as well as the framework designed by us to be in compatiblewith the bonseyes project.


4.3.1 Implementation and Analysis of the Secret Store

The motive of this subsection is to describe the secret store functionality,interactionof various entities with the secret store and its internal functioning.

4.3.2 Platform for Testing

Microsoft AzureIn order to test the Secret Store and its functionality we designed a test bed bycreating virtual machines(VM) in Microsoft Azure. Microsoft Azure is a cloudbased service that provides compute, networking and storage power for cre-ating and deploying applications and services [37].The initial launch of Azurewas in the year 2010 on February 10th, since then Microsoft has made constantstrives in improving the platform by providing latest tools including Blockchainworkbench, Machine Learning, Internet of Things (IOT) and many more.Someof the important services provided by Azure are IaaS (Infrastructure as a Ser-vice), PaaS (Platform as a Service), FaaS (Function as a Service) etc.We used Azure mainly to access and boot its virtual machines to deploy ourframework and also to monitor them using the monitoring tool provided.

Figure 4.5: Azure Portal[18]

In order to use the portal we need to login into "http://www.portal.azure.com"with proper credentials.This then provides an interface with numerous capa-bilities for the virtual machines such as Starting and stopping virtual ma-chines,Monitoring of VM,Health checks for VMs,Logs in case of issues. Thevirtual machines can be remotely connected and used by remote access proto-cols such as SSH,RDP.Figure 4.6 shows the console of the VM after we ssh to it.


Figure 4.6: SSH login

The configurations and specifications of the virtual machines are provided infigure 4.7 and 4.8.

Figure 4.7: Specification of the Virtual Machine[18]

Figure 4.8: Specification of the Virtual Machine


The virtual machine is run on a Linux flavour i.e. Ubuntu 18.04 with 2 virtualCPU’s and 16GB of ram.

Once we login in to the VM, in the coming sections we define how to setup thesecret store and how to run the framework in order to perform our experiment.

The following sections describes the implementation of secret store functionalityused in the ocean protocol in an isolated environment to study the functioning andanalyze the performance of the framework.

4.3.3 Configuration Files

Configuration files are used to pass the necessary parameters and initialize thescripts.Openethereum uses Tom’s Obvious,Minimal Language(TOML) files to con-figure the secret store functionality parameters.

4.3.4 Configuring Secret Store

The first step in implementing the secret store functionality involves configuring var-ious entities involved using the TOML configuration files. The implementations isrun on a private blockchain and all the nodes are implemented on different portssuch that each configuration file executed acts as an individual node on that port.The private blockchain implemented requires the peers to be configured in bootn-odes.Bootnode is a lightweight application where peers are configured for discoveringother nodes using the Node Discovery Protocol [38].

The users are configured first using a users.toml configuration file.

Figure 4.9: Users Configuration File

The chain is configured to be a private development chain passed in by the "dev"parameter and the database to store the corresponding data is passed.The user nodesare configured to run on port 8545 and the API that shall be implemented in thistest case is the secret store.The secret store functionality is disabled for users as theusers don’t need to run the secret store nodes.

The Secret store nodes are the next elements to be configured.There are cur-rently 3 secret store nodes in our implementation.The nodes are configured usingss1.toml,ss2.toml and ss3.toml scripts.


Figure 4.10: Secret Store Node 1 configuration file

In the trail implementation we expose only one port of Secret store to the usersand in this case we expose port of Secret store 1 to the user.The user and the secretstore nodes communicate using only this port of secret store 1.Thus for secret storenodes 2 and 3 http is disabled allowing the secret store node 1 as only point forcommunication with the network.

After the secret store nodes are initially configured,it generates an address for theaccounts.The address and a password in a .pwd file are passed on the configurationfiles as parameters.The scripts are then configured again.This provides us with thebootnode ID used to identify the peer in the network and a public key correspondingto the address.

The users configuration file is reconfigured with the boot nodes of all the secretstore nodes.The secret store nodes are reconfigured such that all the bootnode addressof every other node is known.The public key of all the nodes with local host addressand port appended at the end is passed as parameter.The complete configurationfiles of user and secret store can be found in the Appendix. The secret store nodescan then be launched and run using the command : ./target/release/openethereum–config ss1.toml and likewise for the other configuration files.

Figure 4.11: Secret Store Node 1 configuration file


4.3.5 Document Encryption

The Document in this case is the generally the artifact to be transmitted.The Doc-ument encryption using the secret-store involves various steps:

• Choosing a Document Key Identifier

• Getting the secret store server key from this document

• Generating the Document Key from the Secret store key

• Encrypting the Document

• Storing the document on Secret Store

Document Key Identifier

Document key ID is generally used to identify the document.The generally chosendocument IDs can be either the hash of the document or a random number assignedto identify the document. In this work we choose a SHA-256 hash of the documentas the identifier for the document.In general in the ocean marketplace it is called thedecentralized identifier used to identify the artifact.

Figure 4.12: Alice’s Document

To generate a SHA-256 hash of the document we use the command:echo -n Document to be sent | sha256sum

Figure 4.13: Document Key ID

This generates the hash of the document which can be used to identify it.

Secret Store Server Key

To generate the the Public key from the secret store cluster

• The Document needs to be signed using the address of the sender,in this caseAlice.To sign the messages in openethereum it provides a functionality calledsecretstore_signRawHash.The Remote Procedure Call (RPC) call is made fromthe sender to its node to generate a signed copy of the document key ID.


A JSON-RPC is made from the user to its own node on port 8545 and theparameters required to use secretstore_signRawHash method are the addressof the user,password of the user account and the document key ID previouslygenerated.

The command using curl is:

curl –data-binary {"jsonrpc": "2.0", "method": "secretstore_signRawHash","params": [ Alice address, Alice account password, Document key ID ], "id":1}’ -H ’content-type: application/json’ http://127.0.0.1:8545/}

Figure 4.14: Signed Document ID

This generates a signed document key ID with Alice’s account.

• When the secret store nodes are configured and running a POST request ismade to the secret store for the public key from the secret store.A shadowretrieval is requested by the user from secret store.The Document Key ID andSigned Document key ID are passed as parameters in the URL to the secretstore which returns the public portion of the server key.The command is passedin a bash script.

The POST command is curl -X POST http://localhost:8010/shadow/Doc ID/SignedDocument ID


Figure 4.15: Public portion of Secret Store Server Key

This returns the public key generated by the secret store.

Document Key from Secret Store Server Key

A document key is generated by the user,Alice in this case,using the public portion ofsever key.A JSON-RPC call is made to the user node using the method secretstore_-generateDocumentKey where Alice’s address,Alice’s account password and publicportion of server key are passed as parameters.This returns an encrypted_key whichis used to encypt the document and a common_point and encrypted_point pair.

The command for the JSON-RPC call is: curl –data-binary ’{"jsonrpc": "2.0","method": "secretstore_generateDocumentKey", "params": [Alice account address,Alice account password,Secret store public key], "id":1 }’ -H ’content-type: applica-tion/json’ http://127.0.0.1:8545/

The command is passed through a bash script to analyse the time taken for thecommand.

Figure 4.16: Document Key from Secret Store Key


Document Encryption

To encrypt the document the document is initially hex-encoded using the command:xxd ps Document_name and the output is stored to another file.

Figure 4.17: Hex encoding of the document

The hex encoded document is then encrypted using the encrypted_key generatedpreviously.The encryption is done locally through the secretstore_encrypt JSON-RPC call.The parameters passed are Alice’s account,Alice account password,encryptedkey and the hex encoded document.

The command to encrypt the document is: curl –data-binary ’{"jsonrpc": "2.0","method": "secretstore_encrypt", "params": [Alice’s account, Alice account pass-word, encrypted_key, Hex encoded document], "id":1 }’ -H ’content-type: applica-tion/json’ http://127.0.0.1:8545/

Figure 4.18: Encrypting the document

Storing Document Key on Secret Store

The Document identified by the Document Key ID.The Document must be associatedwith the public key to ensure that the specific document can be decrypted using theprivate key.The association is done using the common_point and encrypted_pointpair generated when generating document key from the secret store public key.

The Document ID,signed Document ID,common_ponit and encrypted_point arepassed to the secret store.


curl -X POST http://localhost:8010/shadow/Document Key ID/Signed Docu-ment Key ID/common_point/encrypted_point

Figure 4.19: Storing Document on Secret Store

The secret store logs show that encryption of the document is complete.

Figure 4.20: Secret Store Log

4.3.6 Decryption of Document

The Decryption of document involves:

• Signing the Document Key ID by Bob

• Retrieving the document keys

• Decrypting the document and decoding it

The Decryption of the Document is done by Bob.Alice sends that Document Key IDand the encrypted document to Bob.To decrypt the document Alice set a threshold


of 1 node in secret store nodes count that implies that at least 2 secret store nodesare required to decrypt the document.

Signing of Document Key ID

The document key ID is initially signed with Bob’s account as done in Alice’s caseusing the secretstore_signRawHash method.A JSON-RPC call is made to the usernode to sign the document using Bob’s account. The command passed is passedusing a bash script:

curl –data-binary {"jsonrpc": "2.0", "method": "secretstore_signRawHash","params": [ Bob’s address, Bob’s account password, Document key ID ], "id":1}’ -H ’content-type: application/json’ http://127.0.0.1:8545/}

The request is passed through a shell script to analyze the performance.

Figure 4.21: Signing Document Key ID using Bob’s account

Retrieving Decryption keys

Bob then makes a request to the secret store using the Document Key ID and signedDocument Key Id to retrieve the decryption key corresponding to the document. Thethreshold set by Alice to retrieve the document is 1 node.Hence atleast two secretstore nodes are required to retrieve the decryption keys. In this case Node 3 of secretstore is shut down and the decryption keys are then requested from secret store.


Figure 4.22: Retrieval when only 2 nodes are working

The retrieval request provides the triplet of (decrypted_secret, common_point,decrypt_shadows) which are used to decrypt the document.

Decrypting the Document

Bob then makes a request locally to decrypt the document using the decryptionkeys obtained from secret store using secretstore_shadowDecrypt method.Bob’s ac-count,password and the triplet of decryption keys are passed as parameters to theJSON-RPC call.

The request is ade using the command:

curl –data-binary ’{"jsonrpc": "2.0", "method": "secretstore_shadowDecrypt","params": [Bob’s account,Bob’s account password,decrypted_secret,common_point,decrypted_-shadows,encrypted document from Alice], "id":1 }’ -H ’content-type: application/j-son’ http://127.0.0.1:8545/


Figure 4.23: Decrypting the document

This returns the Hex-encoded document from Alice which is then decoded.

Figure 4.24: Decoding the Document

4.3.7 Permissioning Contract

Permissioning contract are the solidity smart contracts which allow only the au-thorized users to access the decryption key.A solidity contract is made wherein theaddress of sender and receiver is provided such that only the authorized receivercan get the decryption keys.The user and secret store scripts are then reconfiguredsuch that the address of the contract is provided in the scripts and the nodes arere-configured.This results in only the particular entity with the address accessing thedecryption keys.


4.3.8 Reference Secret Store Framework Implementation forBonseyes

The Secret store implemented in the Ocean protocol relies on the currency of etherand ocean token to utilise the network and the blockchain.The implementation alsorequires various dependencies to function properly.The secret store in the ocean pro-tocol is implemented in rust and has various other requirements to operate.Thus were-design the secret store and implement a reference framework to make it compat-ible with the Bonseyes. In this subsection we provide the working implementationof our framework designed with the knowledge accumulated from the secret storeof the Ocean protocol and other research papers related to distributed public keyinfrastructure which is compatible with the Bonseyes AI market place. Below is thelist of the participators involved in the framework.

• Client1 (Alice)

• Client2 (Bob)

• Secret Store node 1



• Blockchain node

We analysed the implementation of our framework with two clients who interact witheach other for exchanging the software artifacts, secret store which consists of threenodes responsible for key generation and retrieval responsible for signing and verifyingthe software artifacts and the blockchain which is used to store the contracts or ratherthe information from the client sending the software artifact on who is allowed toaccess it. The blockchain implemented here is a bitcoin based blockchain where eachcontract between the clients is added as a transaction, unlike the ethereum basedblockchain we did not consider any transaction fee or rather the so called gas which isused to allocate resources in it. The main reason to add blockchain to our frameworkis to make the authentication of the software artifacts distributed, the contracts hereare json (javascript object notation) formatted data which consists of requestingcustomers details or metadata. Now coming to the important component of ourframework i.e. the secret store, it was designed keeping in mind the characteristicsof it obtained from the literature review which are mentioned above in this chapterin section 4.2.1. It uses elliptic curve discrete logarithmic algorithm for generationof the key pair for signing and verifying purposes, all the nodes involved in the secretstore are required for providing a signing key, but only "(n-1)" nodes are requiredfor verifying the signed artifact, here n is the no of nodes involved in signing adocument or rather producing the signing key. We implemented our framework ona single computer by enabling different ports for each node and hence we utilizedintercommunication process. Below is the table for specifications of our computer.


Resource Name SpecificationOperating System Ubuntu 20.04.1RAM 4GBType of memory DDR3ROM 250GBProcessor Intel i5Alice’s port 4000Bob’s port 3000Secret Store port’s 7000,7500 and 8000

Table 4.1: Specifications of the Computer

Few of the important services or functionalities provided by our framework forexchanging data between two clients namely Alice and Bob are :

• Service 1 :Bob requesting Alice for data by sending a request along his nameand artifact. Alice’s script is running on port 4000 where as Bob’s script isrunning on port 3000. Following is the figure which depicts it. With success-full request the response is a message stating ’request successfully processed’.

Figure 4.25: Bob requesting Alice for the data

• Service 2 :Creation and addition of contract consisting of Bob’s details andthe data requested to the blockchain running on port 6000.The figure shows usthe details of the new block mined in the blockchain. With each new contractbetween new clients a new block is mined and the transaction is added.

Figure 4.26: Adding contract to the blockchain

• service 3 :The next step for Alice is to request a signing key from the secretstore for signing the data that is to be sent to Bob. Point we must consideris that we are exposed to a single node of the secret store running on port


8000 for obtaining the keys though all the nodes are involved for generatingand reviving them. This is done to avoid ambiguous communication in thenetwork. In the backend all the nodes communicate securely with each other.

Figure 4.27: Obtaining the signing key

• Service 4 :After receiving the response from the secret key, Alice encrypts thedata and signs it using the signing key.

Figure 4.28: Encryption

Note the time taken to encrypt the document and sign it is recorded to be38.22 milliseconds.

• service 5 :Once the encrypted document along with the signature is received byBob, he tries to verify and decrypt it for which he relies again on secret store forkey retrieval of verifying key. In order to check whether Bob is authenticatedfor the data/artifact secret store uses the contract in the blockchain. Beloware the images which show the same.

Figure 4.29: Decryption


Figure 4.30: Authentication using blockchain

The first figure shows the decryption of the data where as the second figureshows the secret store checking the contract present in the blockchain for au-thentication of Bob. We may also note from fig 4.14 that the time take fordecryption is 48.203 milliseconds.

Application Programming Interface API was used for interaction between com-ponents of the framework for making the workflow between them easier and quicker.The framework was designed and implemented in "Python" programming language.The code of our framework can be obtained from the appendix.

Process Round1 Round2 Round3 Round4 Round5 Average TimeEncryption 38.22 ms 40.36ms 31.8ms 42.04 ms 35.1ms 37.504msDecryption 48.203 ms 53.4ms 39.0 ms 55.1ms 42.3ms 47.606ms

Table 4.2: Time Analysis

The above table shows the performance analysis for the encryption and decryptionprocess which was performed five times and the average was calculated, the metricconsidered for the analysis is the time which is measured in milliseconds. Focus canbe put on two main points from the above results, the first being the extra timetaken by the decryption process, which is due to the fact of verifying the token orrather the JSON data from the blockchain and second is the time taken for bothencryption and decryption being less in round 3 and round 5 when compared withothers as in these rounds the secret store nodes where rebooted and the previousdata was deleted. Also one has to keep in mind the parameters such as networking,computing and storage as the processing time for the services may vary based onthem.

Chapter 5

Discussion and Analysis

This chapter discusses the main goal of our thesis i.e. the evaluation of the frameworkdesigned for exchanging the keys which is used for encrypting and decrypting thesoftware artifacts in a distributed manner using the Ocean Protocol.This chapter alsoemphasizes on the results obtained from the implemented framework.The solutionchosen for solving our research problem as mentioned in chapter 1 and section 1.1was to adapt the Secret Store functionality from the Ocean protocol[2] for distributedkey-pair generation which replaces the standard Certificate Authority based PKIsystem which is meant to be centralized and prone to many attacks. A test bedwas set up using the virtual machines in the Azure cloud platform for setting up thesecret store and the client nodes whose evaluation was also done using the monitoringtool provided by Azure. Later after successful implementation of the secret store wemodified the solution as mentioned in chapter 4 section 4.3 and subsection4.3.8 to be compatible with the H2020 Bonseyes project. With all our efforts wetried providing a feasible solution that can be deployed as a full working model andalso handle multiple number of users, however testing was limited due unavailabilityof large number of resources.Below in the following sections we provide solutions tothe research question addressed in the chapter 1 section 1.3 and try showcasingthe results in the most accurate and precise manner.

5.1 Research Questions and Answers

In this section we discuss in detail the answers for our research questions from theknowledge accumulated from the literature review and the formal experiment per-formed above. Below are the research questions and their answers.

RQ1 : How are the key exchange mechanisms implemented in theOcean protocol network?Ans: The above research question is answered by performing a literature reviewon the Ocean Protocol and the papers related to it. The knowledge accumulatedfrom the literature review defines that the component Known as the "Secret Store"is responsible for implementing key exchange mechanisms in the Ocean protocolnetwork. Secret Store is a distributed protocol which is empowered with an ethereumbased blockchain where there is no centralized entity that controls the key exchangemechanism, multiple nodes/servers which have encrypted communication connectwith each other for generating a key pair. The Secret Store can be considered to bean alternative for the Public Key Infrastructure (PKI) in order to provide a solutionfor our research problem. PKI has a centralized entity known as Certificate Authority

47

48 Chapter 5. Discussion and Analysis

(CA) responsible for generating and exchanging the keys and attesting the identityof a user to a key using digital certificates. The reader can acquire more informationabout the Secret Store by referring to the section 4.1 on the architecture and thecharacteristics in the chapter 4.Below are the following functionalities that are involved when the clients connect tothe secret store for generating and exchanging the keys.

• Server Key Generation

• Document Key Generation

• Document Encryption

• Introducing Permissioning Contracts

• Storing the Document key in the Secret Store

• Document Key Shadow Retrieval

• Document Decryption [4]

In detail explanation of the steps mentioned above are mentioned are defined inchapter 4 section 4.3.

RQ2 : Evaluate the possibility of implementation of such a functional-ity in the Bonseyes Secure Virtual Premise?Ans: As we know from chapter 3 section 3.2 Bonseyes project is a collaborativeAI market place that allows industries, researchers and developers to collaborate witheach other The main issue with such type of architecture is enabling trust requiredfor a particular artifact to be accessed by the participants of the marketplace. Thecurrent model as Public Key Infrastructure’s (PKI’s) certificate authority (CA) in-corporated to handle the authorization and authentication. The main disadvantagewith such an approach is being centralized in architecture which is prone to singlepoint failures. In this thesis we rather adapt a distributed approach by consideringto replace the CA of the PKI with secret store from the ocean protocol. In Thisresearch question we try giving insights on how can we implement such a function-ality in the Bonseyes Secure Virtual Premise (SVP). Bonseyes architecture involvesSVP for securely implementing the AI pipelines.The SVP consists of Controller Hostand Compute Host. The controller Host is the trust anchor for users and services.Itconsists of a CA-based Public Key Infrastructure which binds the identities of usersand services to their claims and guarantees the trust.

This CA based architecture can be replaced by the functionality of Secret-storeimplemented in the ocean protocol.The secret-store is then redesigned to accommo-date the functionalities of Bonseyes architecture.The implementation can utilise aprivate general-purpose blockchain instead of the public blockchain such as ethereumused in the ocean protocol to unbind the use of currencies required on their blockchainsuch as Ether and Ocean token and to preserve the collaboration to only authorizedparties by the SVP provider.

The collaboration model could be extended so that the SVP provider can handlethe additional responsibilities of selecting the secret store nodes and block producers

5.1. Research Questions and Answers 49

for the private blockchain.The working of such an implementation can be referred from chapter 4.

RQ3 : Evaluate the performance of the Secret Store in the ocean pro-tocol?Ans: The performance analysis of the implemented framework is evaluated based onthe two parameters considered which are the the delay introduced in the functioningof such an architecture and the storage overhead required. The evaluation of the re-sults obtained due to the delay introduced in computation of various functionalitiesinvolved in the secret store are tabulated below.

Process Round1 Round1 Round1 Round1 Round5Signed Document KeyID 35ms 32ms 34ms 38ms 37ms

Public portion of server key 110ms 80ms 85ms 77ms 83msDocument Key from server key 40ms 40ms 35ms 31ms 38ms

Document Encryption 41ms 40ms 36ms 32ms 35msStoring Document Key in Secret Store 40ms 27ms 36ms 32ms 41ms

Retrieving Decryption Key 31ms 30ms 40ms 29ms 25msDecryption of the Document 58ms 50ms 41ms 47ms 55ms

Table 5.1: Performance analysis of secret store processes in different iterations

Process Computed Node Average Computation TimeSigned Document KeyID Client 35.2 millisecondsPublic portion of server key Secret Store 87 millisecondsDocument Key from server key Client 36.8 millisecondsDocument Encryption Client 36.8 millisecondsStoring Document Key in Secret Store Secret Store 35.2 millisecondsRetrieving Decryption Key Secret Store 31ms millisecondsDecryption of the Document Client 50.2 milliseconds

Table 5.2: Average performance analysis of the secret store from the ocean protocol

Table 5.1 depicts the delay introduced by each functionality of the secret storeframework for 5 iterations/rounds, further table 5.2 shows us the node on whichthe process is performed as well as the averaged value of the delay of each processcollected from table 5.1 . A slight lag was observed after rebooting the secret storenodes after the completion of each iteration.The metrics used here is the time inmilliseconds.

NOTE: Please refer to the chapter 4 section 4.3 for the detailed descriptionof the processes mentioned in the above table.

The Secret store functionality as implemented in the ocean protocol also requiresa significant storage space for various dependencies required to operate it.

50 Chapter 5. Discussion and Analysis

Figure 5.1: Disk space used in openethereum

Below is the pictorial representation of the CPU analysis of the encryption anddecryption functionalities involved in the secret store of the ocean protocol.

Figure 5.2: CPU performance during encryption and decryption

The CPU performance of the Virtual machine spiked at the instance when theuser node makes a request to the secret store and the performance remained rela-tively constant when operating within the user node.The performance of the CPUis relatively good for the computations performed during encryption and decryptionprocess and there is no sudden spike in the performance of the CPU during the courseof implementation.

A STRIDE approach [39] is used to define the threats addressed by the Frame-work.Each letter in the word corresponds to the security that can be provided againsta threat.The letter S corresponds to Spoofing against Authentication,letter T cor-responds to tampering against integrity,R corresponds to repudiation against non-repudiation,I corresponds to information disclosure against confidentiality,D corre-sponds to Denial of Service against availability and E corresponds to elevation ofprivilege against authorization.

S T R I D E� � � �

Table 5.3: STRIDE Security Analysis

The analysis based on the implementation of the secret store on the test bed showthat the functionality introduces significant overhead in terms of storage,validationof keys and verification of the keys. The analysis satisfies most of the points from theSTRIDE methodology except for Information disclosure against confidentiality and

5.1. Research Questions and Answers 51

denial of service against availability. Though the data present inside the softwareartifact is kept safe and undisclosed from the users who are not authenticated to usethem we lack in providing complete privacy i.e. the blockchain in our frameworkwhich is used for the purpose of storing the token or rather the JSON format of themeta data of the transaction of the software asset such as the owner of the asset, timeof request for the asset etc. is made available to everyone in the network, a smallcompromise is made for decentralizing the power of the secret store nodes. On thebigger picture by using a private blockchain we try to restrict the information of themetadata from being leaked outside of our network. Moreover our framework is alsonot quite capable enough for handling the Denial-of-Service(DoS)/Double-Denial-of-Service(DDoS) attacks which makes it a little vulnerable. To conclude, the designedframework is well equipped to handle most of the threats.

Chapter 6Conclusions and Future Work

6.1 ConclusionSince the time of the internet revolution millions of devices are being connectedwith each other. The amount of data being generated by them is abundant whoseaccess is restricted to only the companies or industries controlling them. Due to therecent advancements in AI, data is being considered as one of the most importantasset in modern times. Bonseyes AI marketplace provides a platform for industries,researcher’s, developers and other enthusiasts an opportunity to collaborate with eachother in order to exchange the resources needed to build AI and software applicationsby leveraging each others resources such as data,algorithm,computing platform etc.While providing such a platform the main point to consider is providing securityto both the users and the assets they possess. Currently Bonseyes project uses apublic key infrastructure which is responsible for authenticating and authorizing theusers and their software artifacts with the help of a component known as certificateauthority (CA) present in it. The problem with the CA is being centralized inarchitecture which leads to single point failures. This thesis includes analysing theimplementation of the secret store from the ocean protocol which can be consideredas an alternative distributed approach for the centralized CA.

The results from the study indicate that the secret store functionality can beextended to be implemented in the micro-service based architectures such as theBonseyes marketplace.The Secret store functionality introduces significant overheadand delay but the architecture is quite resistant to attacks and it can securely ex-change artifacts between users without any central point of failure.

The analysis from the study indicate that secret store functionality can act as aviable alternative to the centralized CA based PKI in the Bonseyes marketplace andit further enhances the purpose of the Secure Virtual Premise by eliminating all thecentral points of attack on the marketplace.

6.2 Future WorkThe secret store nodes are the trust anchors responsible of securely sending theartifacts between users.Securely operating these nodes is the major issue in sucharchitectures.The security of such devices can also be enhanced with the utilisationof hardware based trust mechanisms such as use of Trusted Platform Modules (TPM)which can be an interesting area to study.The further study of extending the scope ofsuch an architecture to act as a replacement for the Certificate Authority (CA) in the

53

54 Chapter 6. Conclusions and Future Work

Web-based PKIs and a implementation on much larger scale would be an interestingexperiment.

With the advancements in Quantum Computation,there exist a potential threatto break the Elliptic Curve cryptography.A good alternative is to study the use ofquantum-resistant computation algorithms in such a distributed architecture.

References

[1] Kurt Tutschku. Revised Bonseyes System - Secure Virtual Premise, Bon-seyes Deliverable D2.4, Nov,2019. Available on request at www.bonseyes.eu/outcomes/.

[2] Ocean protocol: A decentralized substrate for AI data & services-technicalwhitepaper. Technical report, Tech. Rep., 2018. International Journal ofAerospace Engineering Hindawi, 2018.

[3] Jiangshan Yu and Mark Ryan. Evaluating web pkis. In Software Architecturefor Big Data and the Cloud, pages 105–126. Elsevier, 2017.

[4] Secretstore, 2019. [Online]. Available at https://openethereum.github.io/wiki/Secret-Store.

[5] Alexander Yakubov, Wazen Shbair, Anders Wallbom, David Sanda, et al. Ablockchain-based pki management framework. In The First IEEE/IFIP In-ternational Workshop on Managing and Managed by Blockchain (Man2Block)colocated with IEEE/IFIP NOMS 2018, Tapei, Tawain 23-27 April 2018, 2018.

[6] Abu Shohel Ahmed and Tuomas Aura. Turning trust around: smart contract-assisted public key infrastructure. In 2018 17th IEEE International Confer-ence On Trust, Security And Privacy In Computing And Communications/12thIEEE International Conference On Big Data Science And Engineering (Trust-Com/BigDataSE), pages 104–111. IEEE, 2018.

[7] Brian Khieu and Melody Moh. Cbpki: cloud blockchain-based public key infras-tructure. In Proceedings of the 2019 ACM Southeast Conference, pages 58–63,2019.

[8] Ze Wang, Jingqiang Lin, Quanwei Cai, Qiongxiao Wang, Daren Zha, and JiwuJing. Blockchain-based certificate transparency and revocation transparency.IEEE Transactions on Dependable and Secure Computing, 2020.

[9] Clemens Brunner, Fabian Knirsch, Andreas Unterweger, and Dominik Engel. Acomparison of blockchain-based pki implementations. In ICISSP InternationalConference on Information Systems Security and Privacy, pages 333–340, 2020.

[10] Roman Cherednik. Remme protocol. Technical report, 2019. [On-line].Available at https://github.com/Remmeauth/Documentation/blob/master/RemmeProtocolTechPaper.md.

55

56 References

[11] Remchain, 2020. [Online].Available at https://support.remme.io/hc/en-us/articles/360010835540-What-is-REMChain.

[12] Delegated proof of stake, 2017. [Online].Available at https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper.

[13] Namecoin, 2020. Namecoin website [Online]. Available at https://www.namecoin.org/.

[14] Conner Fromknecht, Dragos Velicanu, and Sophia Yakoubov. A decentralizedpublic key infrastructure with identity retention. IACR Cryptol. ePrint Arch.,2014:803, 2014.

[15] Dominic Letz. Blockquick: Super-light client protocol for blockchain validationon constrained devices. IACR Cryptol. ePrint Arch., 2019:579, 2019.

[16] V. Arya, S. Sen, and P. Kodeswaran. Blockchain enabled trustless api market-place. In 2020 International Conference on COMmunication Systems NETworkS(COMSNETS), pages 731–735, 2020.

[17] Google cloud AI, 2018. Google Website. [Online].Marketplace website Availableat:https://cloud.google.com/products/ai/.

[18] Microsoft azure website, 2018. [Online] Marketplace website Available:https://azuremarketplace.microsoft.com.

[19] Cloudsight, 2012. CloudSight Website. [Online].Marketplace website Availableat:https://cloudsight.ai/.

[20] James Kempf, Sambit Nayak, Remi Robert, Jim Feng, Kunal Rajan Desh-mukh, Anshu Shukla, Aleksandra Obeso Duque, Nanjangud Narendra, andJohan Sjöberg. The nubo virtual services marketplace. arXiv preprintarXiv:1909.04934, 2019.

[21] Rajkumar Buyya, Toni Cortes, and Hai Jin. Single system image. The Inter-national Journal of High Performance Computing Applications, 15(2):124–135,2001.

[22] Balaji Rajendran. Evolution of pki ecosystem. In 2017 International Conferenceon Public Key Infrastructure and its Applications (PKIA), pages 9–10. IEEE,2017.

[23] Request for comment, 2020. Available at https://www.rfc-editor.org/about/.

[24] Public key infrastrcture. Available at https://networkencyclopedia.com/public-key-infrastructure-pki/.

[25] Michael Hartmann and Sönke Maseberg. Replacement of components in publickey infrastructures. In IECON’01. 27th Annual Conference of the IEEE Indus-trial Electronics Society (Cat. No. 37243), volume 3, pages 2012–2016. IEEE,2001.

References 57

[26] Kurt Tutschku. Revised Bonseyes System Architecture and Concepts, Bon-seyes Deliverable D1.3, Nov,2019. Available on request at www.bonseyes.eu/outcomes/.

[27] Kurt Tutschku Roman-Valentyn Tkachuk, Dragos Ilie. A secure paas for collab-orative AI engineering,draft version,available on personal request. 2020.

[28] Markus Schumacher, Eduardo Fernandez-Buglioni, Duane Hybertson, FrankBuschmann, and Peter Sommerlad. Security Patterns: Integrating security andsystems engineering. John Wiley & Sons, 2013.

[29] Stuart Haber and W Scott Stornetta. How to time-stamp a digital document.In Conference on the Theory and Application of Cryptography, pages 437–455.Springer, 1990.

[30] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Technicalreport, Manubot, 2019.

[31] Structure of blockchain. [Online].Available at https://www.c-sharpcorner.com/article/blockchain-basics-building-a-blockchain-in-net-core/.

[32] M Niranjanamurthy, BN Nithya, and S Jagannatha. Analysis of blockchaintechnology: pros, cons and swot. Cluster Computing, 22(6):14743–14757, 2019.

[33] Don Johnson, Alfred Menezes, and Scott Vanstone. The elliptic curve digitalsignature algorithm (ECDSA). International journal of information security,1(1):36–63, 2001.

[34] Elliptic curve cryptography. Available at https://en.wikipedia.org/wiki/Elliptic-curve_cryptography.

[35] Elliptic curve digital signature algorithm. Available at https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm.

[36] Caimu Tang. Ecdkg: A distributed key generation protocol based on ellipticcurve discrete logarithm. sE· CURECOMM Security and Privacy in Communi-cation Netowrks., pages 353–364, 2005.

[37] Microsoft. Microsoft azure documentation. [Online].Available at https://docs.microsoft.com/en-gb/azure.

[38] Bootnode. Documentation [Online].Available at https://geth.ethereum.org/getting-started/private-net.

[39] Adam Shostack. Threat modeling: Designing for security. John Wiley & Sons,2014.

Appendix AAppendix A

A.1 Secret-Store framework scriptsThis section provides the scripts involved in testing and implementing the secretsstore functionality of ocean protocol.

Figure A.1: Secret Store Framework Implementation and Evaluation Scripts

The bash scripts used in testing the framework and various scripts required torun the framework are present in the openethereum directory along with the descrip-tion from the framework providers on how to install and run the framework.Secretstore is a optional functionality that needs to be specified while cloning and build-ing the binaries of the framework.The specific version of the packages required torun the framework are provided in the READme description of openethereum.Thevalues obtained for the specific cases are documented in the documentation of Aliceand Bob.The url access to the implementation is:https://github.com/Bhavith7/Master-Thesis-Secret_store_functionality

You can also access the repository by clicking the bold text: Github repository

A.2 Scripts for redesigned frameworkThis section gives the reader an insight into the scripts involved in the redesignedreference framework in compatible with the Bonseyes Project. The figure A.1 depicts

59

60 Appendix A. Appendix A

the github repository.

Figure A.2: Scripts of Redesigned Framework

From the above figure SS1.py,SS2.py and SS3.py represents the three secret storenodes that are responsible for providing the authentication functionality by replacinga CA based PKI with private blockchain based PKI, further we define two clients onewhich is requesting and other which is providing the software asset. Thesis.pyproj isa build file if you want to execute the framework on Microsoft visual studio. Pleaseclick on the bold text below to be redirected to the github repository for accessingthe scripts and files of the redesigned framework.Github repository

Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden

design and implementation of key exchange mechanisms for

Documents