In Chapter 2, it was presented several approaches in order to secure data in a cloud repository, not necessarily using blockchain. This section provides an approach which was not implemented, using Gnu Privacy Guard as a method of privacy and security. [gnu] Gnu Privacy Guard enables multi-key encryption, which works by encrypt a symmetric key with asymmetric keys. The primary issue with this approach is that it the owner of the data would be the only one performing updates on the data because of the re-encryption.
Client Setup for Secure Data Upload
In order to send data to the storage providers, it must be encrypted first by the user. This is the objective, but is not enforced and the cloud provider can still add some security. Any of the two options still allows the owner to control access to his data by other users in the network. Data encryption is not implemented, merely it was merely research. Nonetheless for data encryption a setup is needed.
Using Gnu Privacy Guard the user must generate a key using the identityidentifierprovided by the Hyper- ledger Fabric network, which can be obtained by querying the blockchain for a specific function of thecid
6.5. STORAGE PROVIDERS AND DATA HOSTING 77
package,GetID(). This will would make re-uploading data an easier task for the user. This action, makes the sharing of public keys an easier task for the owner and the client application automating the process. An ideal scenario would be: at time of upload, checks the existence of valid share agreements and returns the users id, assuming the owner still has valid keys, and encryption follows.
6.5.1 Data Upload
Data upload is done in two parts, as described in Section 6.3.4. In the client side, data is encrypted using asym- metric key encryption and uploaded to the repository, where the repository flags the request asACCEPTED. Data can be re-encrypted, before being sent, with a shared secret if the owner chooses it.
Assuming a single copy of the data, any time a new user needed access, re encryption with the public keys of every user would be required. This can all be automated with the blockchain, due to the setup and share agreement automatic validation at request creation and request validation.
6.5.2 Optimal Scenario for Sharing
When it comes to sharing of files, with this method, the best case scenario is uploading the encrypted data with Gnu Privacy Guard with all the users who need access, using multi-key encryption. This would require every party to be in the network before hand, and knowledge of every user requiring access.
Data in the repository
If the data is already hosted in the repository and a group of users require access to the data, the owner will follow the same procedure explained previously. The next step is to re-encrypt the data using the client appli- cation with the target recipient public keys, which may require to download the data once again. Since its just one copy, the client application queries the contracts with byFILE ID, returning every user’s identity, so the client application can re-encrypt with all the recipient keys and re-upload.
Increased Protection
The first encryption uses GNU Privacy Guardian to encrypt the data. This encryption method allows for multi- key encryption, and was ideal for data sharing for multiple users and groups of users that do not interact with each other. This allows for data to be secure between users and the untrusted repository with the addition of the blockchain eco-system.
Additionally, the storage provider should provide its own encryption method as expected from cloud storage providers in order to ensure increased privacy and confidentiality. This pre-upload encryption is to ensure the owner has more control over the security and confidentiality of the data in case of untrusted repositories. Additionally the cloud storage provider could perform a shared secret encryption, which would be generated by the Share Agreements and applied by the storage provider. This system would work at time of an access request validation by repositories, instead of just returning theFILE IDof the data. It would also return the shared secret, and the cloud storage provider would re-encrypt with the shared secret.
7
Experimental Evaluation
In this chapter we present some experimental test cases with the test setup. This chapter provides detail on the test environment setup and the test cases detailing the flow of permissions and file asset registration and malicious test cases.
7.1 Test Environment
The test environment is built on top of a Hyperledger Fabric Samples tutorial, Write Your First Application Tu- torial [hfw], that is composed of the essentials to run an application on the network, and make the network function. The components are the following:
• A single organization.
• An ordering service with one Orderer peer. • Consensus Mechanism:solo.
• A single Certificate Authority.
80 CHAPTER 7. EXPERIMENTAL EVALUATION
Request Fields Request Values
Chaincode Identifier Target Chaincode
Function Target Function
Function Arguments [arg0, arg1, ..., argN] Channel Identifier Target Channel
Transaction Identifier txId
Table 7.1: Request Payload Fields and Values
• A single channel. • Three Smart Contracts.
• Three users. One of these acts as a repository. • One administrator.
Peers and Certificate Authority are Docker containers from various Hyperledger Fabric Docker images. Peers and Certificate Authority are part of a Docker network in order to communicate.
The network is booted up by running a script that runs thedocker-compose.yamland a bash script to setup up the network. This includes setting up channel configuration, joining the peers into the channel, install and instantiates the smart contracts. When smart contracts are instantiated, it also boots up an individual docker container that is connected to peers who have installed and instantiated the smart contract for all the peers in the channel. After the script is finishing running, an administrator must be registered first before other users are allowed to join.