Page History

...

Communication channel: Email + Github 

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

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). While TrustID offers interesting features, it implements a proxy contract that can be used to connect an external DID with a fabric network using its own Admin (or user) IDs. Instead of creating a new set of admin proxy identities to access the Fabric app using exernal keys, we want to create an integrated client side identity management solution for the actual Fabric crednetials registered with the utility emission channel (i.e. private key associated with the identity crednetial are not stored on the fabric app). To achieve this we set up a custom WsX509 identity provider using the fabric node.jd sdk, that uses a ws-identity proxy server that connects a fabric app (e.g. Utility Emissions Channel) to a clients secure external ws-wallet where private keys are stored. See methodology below for more details.

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 into Blockchain carbon accounting using Cactus as fabric identity/security package -  
•  4 Web-socket - client wallet application that handles the actually actual private keys and signing (Node. (CLI app and work on basic browser extension)js/CLI server application) + implementation docs and use case justification decision tree

Links

• WsX509 identity provider in Cactus PR 1333
• Add WsX509 support in blockchain carbon accounting project PR 293
• restAPI to reach external ws-wallet (node.js server) from blockchain carbon accounting app - PR 361
• Other PRs for carbon accounting app
• Secure identities directory with documentation and subdirectories for
  • ws-identity server
  • ws-wallet client side key management
• ws-identity docker image (github package)
• Peer programming sessions highlighting progress on  WSX509 implementation
  • 2021-08-16 Peer Programming Call
  • 2021-09-27 Peer Programming Call
  • 2021-11-08 Peer Programming Call

Report (Presented Nov. 17, 2021)

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
• Create WebSocket identity server
•  d WebSocket client wallet

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. Demo full cycle of generating security keys at client, registering and enrolling users, and invoking and querying on Fabric chain code.
•  h. Documentation of  identity solutions to access Fabric application with third party key management toolsEstablish authentication protocol to connect client application (e.g., mobile app and cyrpto wallet) to Fabric application.

Timeline

Tasks

Github issues macro
query labels=mentorship-trustid repo blockchain-carbon-accounting user hyperledger-labs token 4

...

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.

...

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

...

...

Image Removed

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

1. 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. 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). 

1. A better approach to achieve off-line signing is to create a custom identity provider that implements the fabric-network IdentityProvider class.
2. In this project we developed a web-socket based identity provider for WsX509 identity credential types. A secure web-socket connection handles the sending of digests from a fabric network server/application to be signed by an external client. The components fo the web-socket identity provider can be found here. The include:
   1. A ws-identity server that relays signature requests made to fabric network as digest to the external client
   2. A ws-wallet that signs digests using a key-file stored on the clients external device (e.g. encrypted keyfile or HSM). The wallet handles the generation and management of key files. The ws-wallet can also be configured to store certificates (i.e. CSR pem files) signed by the external client when enrolling with the Fabric application. 
   3. The fabric application that requests signatures from the external ws-wallet client. It requres API keys to access the session tickets opened on the ws-identity server with an external client
   4. A custom identity provider that setups the connection between the Fabric app, the ws-identity server and the external clients ws-wallet. An identity provider has been setup in using the cactus fabric connector in cactus PR 293.
   5. A dedicated ws-identity-client is used to handle html requests between the identity provider of the Fabric app or the ws-wallet instance and the ws-identity server. However, this could be replaced by promise based http client like axios 
3. A web-socket based identity provider is being built with typescript as an extension of the IdentityProvider interface of the Fabric network nodes.js SDK
4. The identity provider can be used to connect to any external client, such as a browser, mobile app, client wallet operating on a dedicated server or IoT devicep.

Entity-control-boundary for ws-identity sessions

• control WsClient : web-socket client of the external User
• boundary WsWallet : crypto wallet of the User
• actor User : External user of the Fabric App
• boundary FabricApp : The Fabric app
• control WsIdentityServer : web-socket identity server
• control WsClientServer : User's web-socket client on the identity server

Image Added

Another effort in this project is to integrate a Hardware Security Module (HSM) using the HSMX509Provider class, however at the time of writting this did not support asynchronous requests to an external client. A secure proxy server, similar to the ws-identity server described above, is needed to relay requests between the Fabric app and the external HSM. Infact, ws-wallet could be setup to use an HSM for local key storage and signing when handling requests from ws-identity. A pin should be provided to access the HSM singing algorithm.

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