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
| Mentor | Mentor | Mentor | Mentor | Mentee |
|---|---|---|---|---|
Si Chen US PST | Vatsal Mishra IST | Maria Teresa Nieto CEST | Kamlesh Nagware IST | Bertrand Rioux AST (UTC +3) |
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
| Week | Task/Plan | Status |
|---|---|---|
| May 24 - May 28 | Set up project plan. | |
| May 31 - June 11 | Review TrustID from our previous call. Develop plan for integrating Fabric, TrustID, and Metamask. Integrate TrustID with Fabric. | |
| June 14 - June 25 | Finish integration of TrustID with Fabric. Integrate Metamask into TrustID to sign Fabric transactions. This Task has been revised as these weeks I have simply been understanding how to sign transactions on Fabric with private key and csr generated by the client offline (not the Fabrik SDK). The key only needs to be stored on the client wallet ( metamask), as singing can be done off the server. We could also share the pKey generated by the Fabric (TrustID app) with the client to upload to their wallet. However, the key generator must be compatible with the client Wallet. In the case of Ethreum (e.g. Metamask) we need to generate secp256k1 key, however fabric certificate signer does not support this EC. Trust ID is a good solution as it can register a public key (DID) generated from custom private key that is authorized by Fabric CA to commit endorsements to the chaincode. Note, Trust ID currently only supports infra EC P-521, but this should be easy to update. | Based on discussion with the mentors, the first task was reframed as completing the offline signing of transactions on Fabric using a private key (secp256k1 for ethereum compatibility) generated by the client and store on their wallet (not on the server). The next task Next we want to use the private key to establish a DID (e.g. using TrustID) that can be used to access other networks |
| June 28 - July 2 | Get ready for first Evaluation. Return to TrustID integration to register secp256k1 DID to execute transactions on Fabric. | |
| July 5 - July 9 | Integrate Hardware Security Module (HSM) into utility emission channel client app using softHSM. Include softHSM libraries when building API docker image. Initialize softHSm token to be used when enrolling new users. Update register and enrol typescript to save HSMX.509 identity to local filesystem. | Complete |
| July 12 - July 23 | Prepare schematic for HSM integration with fabric node. Research HSM cloud integration. Understand how to create a proxy pod that connects the client app/service to the HSM device. I.e., the HSM device (e.g. softHSM) is not part of the same container image as the hyper-ledger Fabric node. E.g., see https://developer.ibm.com/articles/leverage-ibm-cloud-hsm-in-your-ibp-network/ | Complete |
| July 26 - August 6 | Implement proxy to link external HSM device (e.g., softHSM) to fabric client app. Understand how to configure HSMoptions to setup and add external HSMprovider to a wallet with HSMX509 types. | |
| August 9 - August 13 | Shift focus from HSM to implementing web-socket based identity provider for fabric client security. Review web-socket functionality. Understand how to run test with web-socket. | |
| August 16 - August 27 | Set-up severs side logic for web-socket identity provider. Client that handles communication with the external key client (e.g. browser extension). Server key file that handles crypto logic like generating CSR files and requesting client signature Identity provider logic that establishes the web socket server and wait for incoming connection from external client that will handle the signing. | |
| August 30 - Sept 13 |
|
|
| Sept 13 - Sept 27 | Eval 3 on October 1 | |
| Sept 27 - Oct 11 | ||
| Oct 11 - Oct 25 | ||
| Oct 25 - Nov 8 | ||
| Nov 8 - Nov 12 | Wrap up of the project Final evaluation and presentation of project on November 12 |
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.
- 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.
- 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:
- generate a csr using some client provided private key / encryption algorithm. (e.g. ECDSA prime256v1);
- include the self-signed csr generated from the private key when enrolling new user with the fabric CA client;
- build endorsement proposal with transaction payload and sign using the private keys encryption algorithm;
- send signed proposal to required peers and check responses;
- 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.?