integrate trustid into fabric utility emissions channel

[sichen1234]

Get TrustId to work with Fabric utility emissions channel. You can take a look at https://github.com/hyperledger-labs/blockchain-carbon-accounting/pull/50 as well.

[brioux]

facing an issue when starting up fabric utility emissions channel with docker-compose-setup (Mac). Auditor organization and peer containers are running, but the orderer service keeps failing on the following cmd in /scripts/startAndConnectNetwork.sh

docker-compose -f ./docker/nodes/node-one/docker-compose-couch.yaml -f ./docker/nodes/node-one/docker-compose-carbonAccounting.yaml -f ./docker/nodes/node-two/docker-compose-couch.yaml -f ./docker/nodes/node-two/docker-compose-carbonAccounting.yaml up -d

ERROR: for orderer1.auditor2.carbonAccounting.com Cannot start service orderer1.auditor2.carbonAccounting.com: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: rootfs_linux.go:60: mounting "/Users/bertrandrioux/github.com/brioux/blockchain-carbon-accounting/utility-emissions-channel/docker-compose-setup/system-genesis-block/genesis.block" to rootfs at "/var/lib/docker/overlay2/28217b964a02e0aac257c0db9cbfffabd8cea2940f486b8330828be1a5791416/merged/var/hyperledger/orderer/orderer.genesis.block" caused: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)?

[sichen1234]

Try the ./start.sh script in the docker-compose-setup directory. That has worked better for me. There are still a few issues with the startup scripts that I'm working through.

---

Si Chen Open Source Strategies, Inc.

Video: Fighting Climate Change with Blockchain and Open Source https://youtu.be/NgxNWXa_IjE

On Thu, Jun 10, 2021 at 3:50 AM brioux @.***> wrote:

Hey still facing an issue when starting up fabric utility emissions channel with docker-compose-setup (Mac). Auditor organization and peer containers are running, but the orderer service keeps failing on the following cmd in /scripts/startAndConnectNetwork.sh

docker-compose -f ./docker/nodes/node-one/docker-compose-couch.yaml -f ./docker/nodes/node-one/docker-compose-carbonAccounting.yaml -f ./docker/nodes/node-two/docker-compose-couch.yaml -f ./docker/nodes/node-two/docker-compose-carbonAccounting.yaml up -d

ERROR: for orderer1.auditor2.carbonAccounting.com Cannot start service orderer1.auditor2.carbonAccounting.com: OCI runtime create failed: container_linux.go:367: starting container process caused: process_linux.go:495: container init caused: rootfs_linux.go:60: mounting "/Users/bertrandrioux/ github.com/brioux/blockchain-carbon-accounting/utility-emissions-channel/docker-compose-setup/system-genesis-block/genesis.block" to rootfs at "/var/lib/docker/overlay2/28217b964a02e0aac257c0db9cbfffabd8cea2940f486b8330828be1a5791416/merged/var/hyperledger/orderer/orderer.genesis.block" caused: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/166#issuecomment-858519766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4NAEVOCDZW6R52SHLDTSCKJDANCNFSM46BD7KCA .

[brioux]

Hi

(1) The tutorial for working with with offline private keys taught me the following - Fabric CA does not support secp256k1 EC keys used by Ethereum/Bitcoin. Therefore this approach to integration with Metamask will not work (unless Farbic CA is extended to use secp256k1).

(2) I will continue working with TrustID, as it allows for enrolling DIDs with custom cryptography to a Fabric CA. Trust ID provides a secp521r1 ("P-521") keyGeneration() option in src/core/did. Will extend this to secp256k1.

[sichen1234]

OK. Is it possible to extend the Fabric CA to work with secp256k1 EC keys, for example by adding some new libraries? We can ask on the main fabric list about it too.

---

Si Chen Open Source Strategies, Inc.

New Video: Creating Climate Solutions with Blockchain and Open Source https://youtu.be/gtO3COq8crQ

On Wed, Jun 23, 2021 at 10:06 PM brioux @.***> wrote:

Hi

(1) The tutorial for working with with offline private keys taught me the following - Fabric CA does not support secp256k1 EC keys used by Ethereum/Bitcoin. Therefore this approach to integration with Metamask will not work (unless Farbic CA is extended to use secp256k1).

(2) I will continue working with TrustID, as it allows for enrolling DIDs with custom cryptography to a Fabric CA. Trust ID provides a secp521r1 ("P-521") keyGeneration() option in src/core/did. Will extend this to secp256k1.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/166#issuecomment-867338453, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4LDOLL67DFQRT3GDUDTUK4LVANCNFSM46BD7KCA .

[brioux]

So this is what I have found. secp256k1 is not an approved ECDSA by the NIST, and therefore does not qualify for Federal compliance (see this article)

This might explain the choice made by Fabric developers, however we can still inquire into supporting it.

TrustID SDK could bypass this issue by accepting the registrationof DIDs that use secp256k1. The Fabric CAs (NIST compliant) is used to deploy trustID chain code delivering the requested transaction payload from the authenticated DID (the original plan for the mentorship)

[sichen1234]

That's interesting. How is the client signing for Fabric done then -- where is the private key stored on the client?

Yes please try TrustId next.

---

Si Chen Open Source Strategies, Inc.

New Video: Creating Climate Solutions with Blockchain and Open Source https://youtu.be/gtO3COq8crQ

On Fri, Jun 25, 2021 at 6:37 AM brioux @.***> wrote:

So this is what I have found. secp256k1 is not an approved ECDSA by the NIST, and therefore does not qualify for Federal compliance (see this article https://poseidon01.ssrn.com/delivery.php?ID=896065081123021023081002127103112026058072085007048023105100087072106124090114025102107053023122008037061119074000001064109005048008022044047068086023014084121005093046094112117019108066083111009102125114064066109095082007091124094105022111122068099&EXT=pdf&INDEX=TRUE )

This might explain the choice made by Fabric developers, however we can still inquire into supporting it.

TrustID SDK could bypass this issue by accepting the registrationof DIDs that use secp256k1. The Fabric CAs (NIST compliant) is used to deploy trustID chain code delivering the requested transaction payload from the authenticated DID (the original plan for the mentorship)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/166#issuecomment-868505570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4MPPUK6HV7FIFVU6ALTUSBADANCNFSM46BD7KCA .

[brioux]

My understanding is TrustID chaincode allows for the registration of any DID (with desired PKI infrastructure). The TrustID proxy function verifies payload signatures by the DID and delivers this to the TrustID configured HF network (e.g. carbon accounting) using the accepted Fabric CA. In other words the TrustID chaincode is designed to process signatures that the FabricCA (used to deploy it) may not accept.

The proxy uses a go implementation of JOSE, which, to my knowledge can process secp256k1 signatures. We just need to configure the TrustID sdk DID keyGeneration() function to use EC secp256k1. I have a general understanding of what needs to be done (and will update the project plan later today), however, might be worth checking my logic quickly with Maria before I start modifying the SDK.

I have been working tirelessly to get the TrustID chaincode deployed to the carbon accounting network on my current branch. There were many changes since Vatsal presented this back in December, but I have finally succeeded after several attempts. I am using the original lifecycle methodology (slightly modified DeployCC.sh script using the localhost). However, I am also learning how on to deploy chaincode as an external service inline with how utilityemissions is now managed (independently from the peers). This will take more time as it is a new concept for me, but for now I can proceed with modifying and debugging the SDK.

[sichen1234]

Please first make a demo video of the offline signing, including:

1. Creating the security key
2. Running fabric transaction with security key

Then please find out what types of security keys are supported by Fabric, and if any wallets support those types of security keys.

---

Si Chen Open Source Strategies, Inc.

New Video: Creating Climate Solutions with Blockchain and Open Source https://youtu.be/gtO3COq8crQ

On Sun, Jun 27, 2021 at 9:08 AM brioux @.***> wrote:

My understanding is TrustID chaincode allows for the registration of any DID (with desired PKI infrastructure). The TrustID proxy function verifies payload signatures by the DID and delivers this to the TrustID configured HF network (e.g. carbon accounting) using the accepted Fabric CA. In other words the TrustID chaincode is designed to process signatures that the FabricCA (used to deploy it) may not accept. The proxy uses a go implementation of JOSE, which, to my knowledge can process secp256k1 signatures. We just need to configure the TrustID sdk DID keyGeneration() function to use EC secp256k1. I have a general understanding of what needs to be done (and will update the project plan later today), however, might be worth checking my logic quickly with Maria, before I start modifying the SDK.

I have been working tirelessly to get the TrustID chaincode deployed to the carbon accounting network on my current branch. There were many changes since Vatsal presented this back in December, but I have finally succeeded after several crash courses and messing around. I am using the original lifecycle methodology (DeployCC.sh script on the localhost). However, I am also learning how on to use chain-code as an external service inline with how utilityemissions is now managed (independently from the peers).

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/blockchain-carbon-accounting/issues/166#issuecomment-869187427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANAS4LH7I2QXUAJBGDSZRTTU5EHNANCNFSM46BD7KCA .

[brioux]

First I setup the following demo where each step in the transaction submission process is handled by the private key stored by the client. github: https://github.com/brioux/fabric-client-signer youtube: https://youtu.be/W_jGc_UpuoQ However the initial gateway connection provided by the (node) app is still setup with the X.509 identity stored on the local filesystem when the user is registered. The role of the client in this demo is to sign the outgoing endorsement/commit requests (or single query request) using the locally stored private key (off the app server).

However, I am now wondering if what we are trying to achieve (storing private keys offline) can be achieved in another way. The gateway connection by the node SDK requires the following inputs

• An identity file (x.509 or other)
• The connectionProfile

The identity file could be configured as a HSMX.509 supported by the node SDK. I.e. a Hardware Security Model (HSM):

• Hashicorp offers Vaul Enterprise support
• Microsoft azure has a key vaul cloud solutino

There are definitely others. As long as they are PKCS_11 compatible they should integrate with the Fabric Node sdk HSMX.509 interface. When the user wants to instantiate a gateway connection, i think the HSM requests the user to generate a new credentials.certificate using its offline private key, and sends it to the node app. What I understand from the gateway class is that it uses this to generate a new identity context used to process transactions from the app without asking the client to sign off each request (e.g.: endorsement, commit, query.

When the gateway is closed the identityContext is removed and cannot be used again (i.e. another session has to be opened by the user HSM). If this is correct, would this be sufficient? If we use this approach, then the working with offline private keys tutorial that I followed for the demo may not be necessary. Getting it running would require modifying how the Gateway class works.

[brioux]

Regarding supported certificates/private keys in fabric, core requirement is that they are generated by elliptical curve cryptography.The supported ECs by fabric are: prime256v1, secp384r1 and secp521r1.

[brioux]

@knagware9 @sichen1234 I have closed the TrustID integration issue. The mentorship project tasked with this took a very different approach than original defined, as describe here. TrustID is not used to setup an external wallet and key files (e.g. Ethereum compatible secp256k1 keys stored in Metamask), to enroll and access contract functions within the Fabric utility emissions channel.

Please find below a description with justification for the solution submitted in PR 293. I will transform this post into a blog with illustrations to explain the problem and solution developed during this mentorship, Will use this in my final presentation.

The solution I have developed setups a new WS-X.509 Identity provider type that is compatible with the Fabric nodejs SDK release 2.2 that certifies enrollment to Fabric, without storing the underlying private keys. Private keys are stored in an offline external wallet owned by the admin or user enrolled to the Fabric network. This could be an auditor or an IoT device. Justification for why they would use such a wallet are provided below.

Note: Using TrustId to provide secure access to a Fabric with external keys/DIDs (like an ethereum wallet) would require setting up admin or other user with separate private keys enrolled with the Fabric CA. This requires installing a trustID proxy contract on top of the application and addtional signing procedure, without solving the underlying problem - STORING PRIVATE KEYS USED TO ACCESS FABRIC OFFLINE.

The solution introduce above creates a secure web-socket connection between a ws-wallet instance and the fabric application and its CA via a ws-identity server. The serve can either be hosted as part of the Fabric application or as a standalone endpoint that bridges Fabric and the ws-wallet. The server does not store or access internally the users private keys, ever. It enables the users to create a WS-X.509 identity credential as proof of enrollment in Fabric using a secure connection with ws-wallet for signing. In this case both ownership and control over keys reside with the external client. See the repo for a description of the security protocol...

A similar solution developed by @Zzocker uses a cloud based key store with Hashicorp's Vault . It operates a Vault-X.509 identity provider to interact with Fabric. However, when a Vault-X.509 Identity connection is closed, private keys still reside in the Vault server. In this case the user has control over, under the Vault key policy implemented by an admin and key encryption, but does not maintain physical ownership of the private keys. For most cases this is sufficient, and can provide key management solutions for multiple users of an organization that is part of a larger Fabric network.

However, in the spirit of decentralized infrastructure, and in some strict cases, physical ownership of keys may be proffered. First for security/access reasons:

• Vault admin control over access to private keys is not acceptable
• Vault server could be compromised exposing encrypted key files of multiple users. Brute force decryption could expose private keys, or corrupt storage (without a backup).

Physical ownership may also satisfy regulatory, governance or personal needs. For exmaple:

• users demands full key ownership
• security protocols set by a company or government require actual keys (not just the passwords that encrypt them) to be owned by the identity holder.

Finally, a physical IoT device may be enrolled with a network Its private keys could be physically stored within an Hardware Security Module that can not be extracted/stored on a remote server. A WS.X509 identity provider offers a secure proxy connection for such a device.