Project Plan - Implement Client Side Security for Climate SIG Fabric Application

Abstract

Implement client side security for the Climate SIG's Hyperledger Fabric application, so that transactions could be signed using Metamask through TrustId.

Mentor and Mentee

Communication channel: Email + Github 

Project repo: https://github.com/hyperledger-labs/blockchain-carbon-accounting/tree/mentorship-trustid

Deliverables

• 1 Integrate TrustID with Fabric utility emissions channel (dropped)
• 2 Web socket based identity provider for fabric network
• 3 Integration of web-socket identity provider into Blockchain carbon accounting using Cactus as fabric identity/security package
• 4 Web-socket-client application that handles the actually private keys and signing. (CLI app and work on basic browser extension)

Milestones

Eval 1:

• a Integrate TrustID with Fabric
• b Demonstrate how to sign transactions with offline private key stored in clients browser session

Eval 2:

• c Integrate HSM into utility emissions channel for register/enrol users and invoke transactions
• d 

Eval 3:

• e. Integrate web socket into blockchain carbon accounting
• f. Command line scripts to generate keys, register and enroll users, invoke, and query Fabric chain code

Eval 4:

• g.
• h.

Timeline

Tasks

An error occured while executinng macro:

Access token 4 not found

Icon

Explanation

This project originally targeted using TrustID to registed ID credentials used to access the fabric utility emissions channel, and storing private keys for these ID's in a clientwallet (e.g. Metamask). The project has since changed track. While TrustID offers interesting features, it implements a proxy contract that can be used to connect an external DID with a fabric network (e.g. utility emission channel) using its own Farbic Admin (or user) IDs. Instead of creating a new set of proxy identities, we want to create an identity management solution for the actual Fabric IDs registered with the utility emission channel. Two strategies are being explored as described in the methodology.

Methodology: offline signing of transactions using private keys stored in the client browser.  

1. See the simple demo hosted here: https://github.com/brioux/fabric-client-signer. It simulates how a browser based wallet like Metamask would work
   
   1. Note: Metamask supports elleptic curve signatures using the secp256k1 algorithm, which, is not supported by Fabric. Fabric has a tutorial using offline private keys and CSR files provided by the client. While this was investigated as a quick solution to integrating Metamask with utility emissions channel, Fabric CA does not support secp256k1 keys used by Ethereum/Bitcoin. A

2. This demo illustrates the process for offline signing and could be extended to implement a browser signer extension (something like Metamask) for a Fabric network.

   1. generate a csr using some client provided private key / encryption algorithm. (e.g. ECDSA prime256v1);
   2. include the self-signed csr generated from the private key when enrolling new user with the fabric CA client;
   3. build endorsement proposal with transaction payload and sign using the private keys encryption algorithm;
   4. send signed proposal to required peers and check responses;
   5. if valid build a new commit with the endorsement from (2), sign commit with the private key encryption and send to peers;
3. A better approach to achieve off-line signing is to create a custom identity provider that extends (implements?) the fabric-network IdentityProvider class.
4. This project is developing a Web-Socket based identity provider that communicates with an external client. The web-socket connection handles the sending of digests from a fabric network server/application to be signed by the external client. This requires:
   1. A server side client that receives relives requests made to fabric network as digest to be signed by the external client
   2. A server side key file to handles thy crypto logic needed to register users. This includes generating a CSR and requesting the external client to sign it
   3. A custom identity provider that operates a web socket server, waits for incoming connections from the external client and manages the web-socket client instance that will communicate with the extenral server
   4. Finally, the external client application that must establish the web-socket connection with the identity providers web-socket-server. Signature requests by the fabric server can not be made until the client opens a web-socket, and provides temporary exposure to its signing functionality. It is up tot he client application to manage exposure of the signing function, and ensure the connection to the fabric network middle-wear is authentic.
5. A web-socket based identity provider is being built with typescript as an extension of the IdentityProvider class/ IdentityProvider interface of the Fabric network nodes.js SDK
6. The identity providee can be integrated with a browser or other client-side application. For example, something similar to this fabric based chrome extension but with the singing part actually handeled by the external client app. In this project the fabric middle-wear still handles the private key storage and singing, with the extension just telling the user what fabric network they are interacting with, and buttons to submit transactions.

Another effort in this project it Integrate a Hardware Security Module (HSM) using the HSMX509Provider class. A first attempt using the Utility Emissions Channel was attempted  here: https://github.com/brioux/blockchain-carbon-accounting. It uses softHSM2 as a virtual HSM. The HSM is accessed by the Fabric client app using a token label and pin to initialize the HSMprovider. However, in the original implementation the HSM lives on the same server as the fabric application, so this is does not support the singing of transactions by an external client application.

1. In reality the HSM should be accessible from an external client through an asynchronous request. This should be possible using node.js fabric sdk after pull request by zzocker to implement the fabric getCryptoSuite response an asynchronous Promise.
2. Access to the pin used to lock the HSM will be secured by an identity management system like Vault. The diagram below illustrates how the HSM is integrated into a Fabric client app.