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
- 2 Use Metamask to sign Fabric transactions through TrustId
- 3
- 4
Milestones
Eval 1:
- a Integrate TrustID with Fabric
- b Get Metamask to sign transactions through TrustId
Eval 2:
- c
- d
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. Understand why REST-API for connecting to utilityemissionschannel is returning error when sending endorsement proposal to peers. This is happening with both self-signed (offlie private key) and Fabric generated certificates. Error: No valid responses from any peers. Errors:\n peer=peer1.auditor1.carbonAccounting.com:7051, status=500, message=error in simulation: transaction returned with failur | |
| July 5 - July 9 | In | |
| July 12 - July 23 | ||
| July 26 - August 6 | ||
| August 9 - August 13 | ||
| August 16 - August 27 | Eval 2 | |
| August 30 - Sept 3 | ||
| Sept 6 - Sept 17 | ||
| Sept 20 - 24 | ||
| Sept 27 - Oct 1 | Eval 3 | |
| Oct 4 - Oct 15 | ||
| Oct 18 - Oct 29 | ||
| Nov 1 - Nov 5 | ||
| Nov 8 - Nov 12 | Eval 4 Final evaluation and presentation of project |
Tasks
Github issues macro query labels=mentorship-trustid repo blockchain-carbon-accounting user hyperledger-labs token 4
| query | labels=mentorship-trustid |
|---|---|
| repo | blockchain-carbon-accounting |
| user | hyperledger-labs |
| token | 4 |
Explanation
This project will offer tools for the signing of transactions/contracts in a distributed network using trusted identity credentials that are fully controlled by private keys held by the client rather and not hosted in a password protected key-store.
Methodology
The project will enable users of the fabric utility emissions channel to use offline private key to sing transaction proposals. This includes standard crypto keys used by the Ethereum/BTC networks and as used by the Net Emissions Token network.
Note: 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 into utility emissions channel, Fabric CA does not support secp256k1 keys used by Ethereum/Bitcoin. TrustID on the other hand can be used to register DIDs with customized private keys infrastructure on a Fabric CA to provide secure access to a Fabric network.
Offline signing will be integrated into the javascript REST API using the Metamask plugin.
The first step in this project is to setup offline signing following this tutorial. 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 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.?