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 with 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 Setup softHSM in external container and setup proxy to connect with fabric client app

Eval 3:

• e.
• f.

Eval 4:

• g.
• h.

Timeline

Tasks

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

The project has taken two paths.

1. Explore offline signing of transactions using private keys stored in the client browser.  See the simple demo hosted here: https://github.com/brioux/fabric-client-signer. It simulates (naively) how a browser based wallet like Metamask would work. 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. 
2. Integrate a Hardware Security Module (HSM) using the HSMX509Provider class. A first attempt using the Utility Emissions Channel isprovided 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. 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.

For the first point above follow this tutorial for signing Fabric transactions with offline private key. This includes several steps:

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;

The demo illustrates this process and could be extended to implement a browser signer extension (something like Metamask) for the Utility Emissions App. The code should be packaged as a module for a new browser based identity, and integrated with the fabric-network client using the IdentityProvider interface. 

TODO: Revise/delete below text.

The above process can be used for offline signing directly onto the utility emissions channels, or we can configure offline signing on TrustID. Trust ID acts as a security layer for linking DID/key pairs to a desired network where the payload is delivered. The offline signing is delegated to TrustID so that the same DID/key pairs can be used to interact with different networks. 

This will require over-ridding the key-store management in the trustID-SDK. One could also do this directly in the SDK of the targeted Fabric network. Using TrustID instead means the offline signing logic is managed through TrustID, and we don't have to worry about setting up offline signing within each target network.

TrustID-sdk currently provides drivers for delivering payloads from the same DID to different (potentially multiple) Hyper-ledger networks. However, new drivers may be developed to use the same DID for access to other networks requiring the security provided by TrustID (e.g., besu)

Questions?: TrustID security and decentralization 

The admin.(?) of the TrusID chain-code authenticates and delivers the payload to the registered network as the admin (not the registered user).

As I understand this mean the TrustID admin has to be an organization registered to the Fabric network as a proxy for the registered trustID credentials? Payload approvals need to be registered somewhere,  should this occur on the TrustID nework?.  

Do we care about TrustID network structure - i.e. how many peers do we need. I guess for development 1 is enough but a real use case would benefit from multiple both from a performance but also to represent different interest (i.e., more than one organization that operate the TrustId chaincode) ...

During the video I recall a conversation about how to use TrustID to perform the authentication only and send the signed payload as the authenticated user, f. From the Video call with Maria I understood that this is not straightforward, but could be done by implementing TrustId as system chain-code at the lower level (e.g., like fabric validation, endorsement chain-code). 

I guess this is outside the scope of this mentorship, but maybe seomthing to look into.?