Summary:

  • Pritam Singhreviewed the cactus integration.  He showed how the Request Manager could lock Fabric data while transactions are being created on the Ethereum network.  The Request Manager is a separate chain code which will call the utility emissions chain code to execute the steps, and while it does so the Fabric emissions records are locked so they cannot be updated by another service.
  • Bertrand WILLIAMSRIOUX showed using Fabric with SoftHSM2 to enroll admin and users.  SoftHSM2 simulates a  Hardware Security Module.  It is configured with a label ("ForFabric") and a PIN, which is then used inside of Fabric to call the HSM.  However, this may not be the correct workflow of using an actual HSM.
  • At the end of the call, we decided to look at an actual HSM workflow to determine how to integrate with it.  Robin Klemenssuggested this Fabric HSM example and also this example on delegating cryptographic operations to Hashicorp Vault.
  • Elisabeth Greenmade a feature request at the end of the call:
    • Request for feature: Does the system record the time of emission? How does the system verify the parameters of the request? May the system be used to deny a request that is trying to offset freshly-extracted carbon? Say, keep the requester account locked until the code verifies that the carbon emissions are timestamped at an earlier date? Does it plan for a proposed policy to disqualify from offsetting new fossil fuel use? For example, the contract would refuse a request to offset fossil fuel extracted/used after Overshoot Day each year. Global Greens Ambassador and former Parliamentary Leader and Senator for Tasmania, Christine Milne spoke on a video a few days ago. She is planning to help negotiate policy at COP 26 and has the following need. We should distinguish between legacy carbon use, which is past emissions, which may be offset, and newly-extracted or burned carbon, which is prohibited from offsetting. There has to be a way to verify that sequestered carbon is staying in the ground or is not offset.
    • My response here is that:
      • The system does record the time of the emissions.
      • The current system is designed for a trusted auditor to record emissions on a Fabric ledger.  Therefore, it is up to the user, who is the trusted auditor, to verify the parameters of all the requests.  This could be modified to work in use cases where an independent verification is done as well.
      • The use case you describe, not allowing carbon emissions after a date to be offset, is not a standard one.  I would not recommend making that a feature of the open source code base, so that it is as flexible as possible to support a range of use cases.  Then individual groups could modify to support the use cases they need.

Recording:

zoom_0.mp4


Hyperledger is committed to creating a safe and welcoming

community for all. For more information

please visit the Hyperledger Code of Conduct.


Time:


Dial-In Information:  [ZOOM]

You can join either from your computer or from your phone:




  • No labels

34 Comments

  1. Si Chen

    Robin Klemens Kamlesh Nagware Pritam Singh Bertrand WILLIAMSRIOUXVatsal Mishra

    Thank you for all your time on the call today.

    I'd like to figure out a plan for how the client sided security should work.  We need to figure out what the application's user flows would be when signing as the client:

    1. On the 2021-06-21 Peer Programming Call, Bertrand WILLIAMSRIOUX  showed using a client X509 identity to sign a transaction.  Does this mean that if a client application generates an X509 identity certificate, it can be stored in the Fabric wallet and used to sign Fabric transactions?  If so what is required for the client application to generate the X509 identity to pass it to Fabric?
    2. Pritam Singhcould you explain more about the Vault transact service that you implemented.  Would this be the HSM for signing Fabric transactions?  Could you pls explain how it would work or post a link to it?

    1. Pritam Singh

       Vault provide multiple type of engine each can be enabled based on use case.  simplest one is KV engine which I am currently using via cactus-vault-keychain. KV is simple key-value  datastore with value encrypted with AES.

      Other Engine which I was talking was Transit Secrets Engine , this can viewed as `cryptography as a service` or `encryption as a service`.  With little bit change to fabric node sdk we can use this as HSM , I am saying this because ,  Transit Secrets engine provide following features :

      1. Private Key never leaves vault.
      2. For singing, data is sent to the engine , and data is singed at vault. (data is not stored with vault) . due to this private key will never have to leave vault

      This Blog by blockchain kompitech has implemented the logic of using vault's transit engine with fabric (in golang).


      I am advocating for using vault because, vault also provide identity management  just like AWS IAM.  (read also about Identity: Entities and Groups)


      This is a rough logic which an organisation should execute for identity and key management of their clients/employee

      1. Org runs a Vault server and nodeJS server (typescript_app)
      2. Create identity for each their client /employee inside vault
      3. every typescript_app's request will take tokenId(vault) of client/employee for executing fabric chaincode method. 

      In terms of implementation this approach and Bertrand Rioux approach of using HSM , majority of things are same  except :

      1. In this approach we will have to implement HSM like capabilities, using vault transit engine and  fabric-network node sdk. And for HSM's approach the logic is already implemented in fabric-network node sdk
      2. For HSM's we will have to implement some kind of identity management (for a organisations) . And for vault's approach identity management is already built-in with vault.


      Currently I am going thought the blog (mentioned above) and recording my progress here : https://github.com/Zzocker/vault-fabric


      NOTE : Every mentioned features of vault are open sources.


      Si Chen Peter Somogyvari

      1. Kamlesh Nagware

        Pritam Singh blockchain kompitech  blog is really good. I have read that before if you could implement in node sdk that will be great.

    2. Bertrand WILLIAMSRIOUX

      Si Chen The client X509 identity is an HSMX509 identity. What is different? The Fabric CA client uses the crypto suit of an HSM token (using its pin) to generate a certificat to register the admin or user of the client app. the client app (and fabric CA) never need to see the private key. When the client uses the identity to execute a transaction in fabric, again it accesses the crypto-suit of the HSM using the PIN, generating the necessary signature (again never exposing the private key).

      1. Bertrand WILLIAMSRIOUX

        Hi all. Thanks for the useful comments. I agree setting up a physical HSM will provide a more concret example. However for what we are trying to demonstrate, using a virtual HSM built within an isolated container that communicate with elements of the fabric network will be sufficient (and perhaps easier at first). We can show the overall setup without integrating a fully fledged service like Vault. I am putting together a schematic, will post soon. More comments below.

        First, the hosting of HSM PIN within a fabric CA client, peer, or orderer node config file, is common practice, and I believe necessary.  See the BCCSP config for this HSM setup: https://github.com/hyperledger/fabric-test/tree/main/regression/hsm/config

         For security benefits to be realized the HSM, and identities (from the fabric network) that can access it, should be managed separately. The identity provider (e.g. Vault) can, when needed (e.g. the node is found to compromised), block access by either changing the pin or disconnecting the HSM (virtual or real).

        In my example the issue was not exposing the PIN (please correct me if my thinking is wrong). Instead the issue was packaging the virtual softHSM in the same container as the client node app where the identities are registered, when they should be independent.

        I am now learning how to connect an external HSM to the pkcs11 configured node (client/peer/orderer). I will try and build a basic example using a docker container running a softHSM that is isolated from but can communicate with a pcks11 enable fabric component. 

      2. Si Chen

        Sorry Bertrand WILLIAMSRIOUX I don't understand this.  I'm going back to our 2021-06-21 Peer Programming Call, where you showed using a client X509 identity to sign a transaction following the  tutorial on signing Fabric with offline key.  That was an X509 identity which you used in the video.  How would you integrate that with a real client application?  How would it generate the X509 identity for use with Fabric?

        1. Bertrand WILLIAMSRIOUX

          Si Chenplease see the schematic I have added below. For the standard X.509 the Fabric CAclient creates a private key and certificate that are registered in the identity file. In the example schematic I provide below, instead the Fabric CAclient uses the HSM crypto suite and private key to get the certificate when enrolling the identity. I hope this helps

          1. Si Chen

            Thank you for uploading this.  Is there another way to create an X509 identity without an HSM?  

            1. Bertrand WILLIAMSRIOUX

              Yes the X509 could be created in different ways as long as it conforms to how the client app will interact with Fabric. Without HSM a private key is provided directly by the client.

              1. Si Chen

                Do you mean that the client would need to send a full pkcs12 with private key and x509 certificate to Fabric?  Is that what you implemented during the 2021-06-21 Peer Programming Call?

                1. Bertrand WILLIAMSRIOUX

                  Si Chen In the fabric client signer example I presented I was using the private key with the X.509 certificate only to connect the client's gateway. As I said, a complete solution would clearly not do this, and I now understand that the gateway connection can be setup without any X.509 ID private keys using the Interface: GatewayOptions. I have not tried this yet, since we shifted focus to HSM/PKCS11.

                  Recall in my fabric client (browser) signer demo all TX signing was done with an offline private key and static javascript function embedded in the clients browser (don't need the local X.509 identity private keys). This simulated (naively) how the Metamask browser extension is used to sign transactions. We can still setup a browser signer extension (something like Metamask) for the utility emissions app. My demo client signer would be packaged as a module for a new browser based identity, and somehow integrated with the Fabric client using the IdentityProvider interface. 

                  1. Si Chen

                    Bertrand WILLIAMSRIOUXOk so can you work with Pritam Singh to get the signing with HSM Vault working with Cactus while coming up with some more generic use cases that do not involve a particular HSM?

    3. Bertrand WILLIAMSRIOUX

      Si Chen to provide a more direct answer to your questions.
      1. Can it be stored in the fabric wallet? Yes the HSMX509 identity is stored in the client’s fabric wallet.
      2. What is required of the client app to pass the HSMX509 identity to fabric? The client has to call the cryptosuite of the HSM using the pin assigned to the token label. A certificate is generated by the fabric network using and HSM enables CA client. So first, the client informs Fabric that it is creating am HSMX509 identity. Second, the fabric CA client produces a certificate during the enroll process. Finally the client use the cert when storing its HSMX509 identity.

  2. Vatsal Mishra

    Hi Si Chen Bertrand Rioux

    Just now caught up with last night's call. The Progress made by Bertrand Rioux is appreciable. I also felt the HSM integration is missing well "hardware" piece to complete the full puzzle for integration with the Fabric network. I think if we just want to do a proof of concept using SoftHSM why don't we try deploying it on a https://www.raspberrypi.org/products/raspberry-pi-zero-w/ and sort of mimic it as any Hardware HSM module would do eventually. If the same docker container(SoftHSM) that was running on the Bertrand system can be deployed to the Raspberry Pi next thing to figure out will be the network configuration for reaching out from it to the Fabric network. Assuming the existing HSM also has some kind of standardized networking equipment built into it along with a firmware that is in some sense similar to SoftHSM we can build our own toy HSM to test out the integration. If everything goes well then it might be easily replaceable with the actual one.

    1. Si Chen

      Vatsal MishraWould it be OK to create a VM image or a small cloud VM instance and deploy Soft HSM on it, to test it out as a "virtual" hardware wallet?

      1. Vatsal Mishra

        Yes, that would also work but may not give the same close-to-user experience as using a hardware device.

  3. Bertrand WILLIAMSRIOUX

    Implementing this with real hardware would provide a more concrete example. However this is not necessary to illustrate the added security of this identity soln. If we run softHSM on an independent container, we can show that, as long as the container is not online (in the real world the HSM is not plugged in) the fabric component with the HSM pin can not generate any signatures (in addition to the private key never being exposed).

  4. Bertrand WILLIAMSRIOUX

    A rough schematic of Identity management for Fabric using HSM. provide some code snippets using Farbic nodeJS SDK for client app. Can also be implemented for Fabric peer, orderer ...



    1. Pritam Singh

      Since an organisation will be running the node server , that means they will also have to manage multiple HSM for each of their clients, right ? 

      1. Bertrand WILLIAMSRIOUX

        Pritam Singh Yes that is correct. A client could hold multiple identity credentials (private keys) in its HSM, but as a good security practice users shouldn't share their HSM.


  5. Bertrand WILLIAMSRIOUX

    Also posting here the discussion we had in private.

    Pritam Singh Questions:

    Since each auditor organization will be ruining a node application server (typescript_app)  , HSM of each of their clients will have to be managed by them (orgs). Vault will be used for identity management, this will be done by issuing a vault token to each client. HSM pins will be stored in the client's vault . Each time a client wants to interact with the application they will have to provide a Vault Token, at application level it will fetch a HSM pin  from the vault using the provided token, then the application can interact with peers , orderers. 


    Response:

    Thanks for your input and suggested modifications. I will revise to make the flow clearer. Note: the use of HSM by the peer/orderer nodes (no storage of private keys on the nodes local filesystem) can be left as a separate topic, since the focus here is on the interaction between the client and the application. 

    Yes the pin would be stored on the vault for security and accessed with a token issued to the client (to be added to the schematic). The identity files themselves do not need to be stored in the vault as they should not reveal sensitive information (to be revised). Identity files can be stored on the filesystem or an external database. 

    Yes the pin/label pair provide the client access to the HSM to use the application.

    I am currently investigating how to use HSM with the client app when not connected to the same container (e.g. softHSM run on a separate image). For example, here IBM discuss the use of a PKCS11 proxy pass-through to connect an HSM. I am not sure, but I think the proxy can be used to set up a new HSMprovider instance and pass this to the typescript application where it is added to the provider Registry of the identity holder's wallet. If so, the typescript application never has to see the pin.

    1. Pritam Singh

      Yes , use of HSM for fabric components (peer , orderer , cas) are definitely a separate topic , If you look into the docs for using HSM for fabric components you will have to rebuild the docker images from the fabric repo (images provided by default won't work).

      Got you, about your approach for storing only pins to vault. Also the HSM proxy you are talking about is the right way for providing HSM as service for the fabric client. 

      Last week I was reading fabric-network codebase and trying out vault APIs, and I will be happy to share my findings with you . And I think using the Vault Transit engine is the same as using PKCS11 specs both in terms of implementation and understanding. And I think Vault Transit engine can provide more flexibility to the client.

      Si, can we have a 30 min discussion on this tomorrow during CA SIG ?

    2. Bertrand WILLIAMSRIOUX

      Si Chen Pritam Singh

      Here is a revised schematic for HSM integration with identity service like Vault (and ordered steps). The Vault could also be replaced with request for user to input HSM pin through secure form.

      1. Pritam Singh

        I am adding some diagram of my understanding of HSM and HSM with PKCS#11 Proxy . Along with three approach (of which one is Bertrand WILLIAMSRIOUX 's) . 

  6. Peter Somogyvari

    Bertrand WILLIAMSRIOUX Si Chen  Pritam Singh


    I'm late for the party, apologies once again. I see two ideas emerging, one is to use Vault for secret management and HSM (e.g.the Vault-only option)  and another one is to use a dedicated HSM in conjunction with Vault (e.g. the HSM+Vault option).

    I'd like to chime in with some questions/thoughts below to ponder that will hopefully provide some structure that aids in the decision making. Happy to expand on all of these and also happy to engage in discussion about the answers.

    1. What are the cost differences for the core infrastructure between the different options (marked bold above)?
      1. Is running Vault has the same cost if we use it with the Transit Secrets Engine or is it a paid upgrade?
      2. How much is the dedicated HSM?
      3. Costs could be measured through the pricing of a specific cloud provider (if we have a preferred one) or we could take the average of prices from a set of cloud providers.
      4. Very important to remember that the cloud vendors automate a lot of things for us, but certainly not everything so likely there is a number of person hours associated with both option A and B for operations to keep things running smoothly so this also be a factor in the overall cost comparison. To instantiate this cost one would need to of course know who would perform out these duties in advance which is difficult at best, so that's why I recommend staying at the abstraction level of person hours instead of dollar figures for this one.
      5. Is there a difference between how costs are scaling for the core infrastructure with the number of auditor organizations?
        1. E.g., if doubling the number of auditor organizations also doubles the core infrastructure's cost, that's probably not good. (not saying that this is the case for any of the options presented, just that this is something we need to consider carefully and note down the results)
    2. Same question, but for the auditor organizations individually who wish to join, how much would be their cost to get up and running with option A vs. B?
      1. Thing of it this way: The auditor organizations will have to assess their upfront cost for joining in and also the fixed cost to be paid indefinitely into the future and if one or both of those are too high they may just decide not to join solely based on that if they cannot afford it, which would be a shame of course.
    3. What are the feature  gaps between the two options?
      1. Is one option provide something that the other does not?
        1. Are there different/"more secure" encryption algorithms?
        2. Is there support for some Cheaper/different/"more" secure deployment architecture?
        3. Is one option more complicated to deploy?
        4. Is one option more complicated to operate (after initial deployment)?
        5. Is one option more likely to suffer from any feature gaps in the future? (only say yes to this based on things that are already  on the roadmap otherwise it's a slippery slope down to the hell of premature optimization.
    4. What is the cloud vendor support out there for option A or B?
      1. The cost of adoption for an auditor organization can also increase from them having to expend additional resources for on-boarding/training themselves in a brand new cloud provider (which could become mandatory for them if option A or B has limited or no support by their cloud vendor)
      2. Ideally the options we consider would be supported by all three major cloud providers based on market share.

    1. Si Chen

      Peter SomogyvariYou make a good point.  I just checked the Amazon Cloud HSM is $1.45 per hour, so that's $1,044 per month.  This may not be necessary for most people's needs.

      What are your thoughts for Cactus?  Are you only implementing HSM security for the Ethereum key or will you have some other measures as well?

      1. Peter Somogyvari

        Si Chen HSM support is something we should definitely add, it's right up there with secure enclaves on the list of important security related features. With that said, we are not close to having HSM support  added because the implementation will have to be different for all ledgers (within each connector plugin) and on ledgers that do not support pre-signed transactions the HSM will anyway have to be configured on the ledger's side where Cactus cannot help with it.

        TLDR: It should be coming at some point but we are not there yet.

  7. Kamlesh Nagware

    @Bertrand Rioux Si Chen  Pritam Singh I think we can give a look to the old hyperledger lab, they have done some efforts to create metamask kind of wallet for fabric.

    https://labs.hyperledger.org/labs/archived/fabric-chrome-extension.html

     https://github.com/hyperledger-labs/fabric-chrome-extension



    1. Bertrand WILLIAMSRIOUX

      Si Chen Kamlesh Nagware

      Great points. I will keep the HSM integration as a separate option for higher security requirements (e.g. administrative access). 

      I will continue working on using offline private key stored only on the user's device, following the tutorial I started implementing in my demo. Will start going over the fabric chrome extension posted by Kamlesh to see how this work might be combined. Not yet clear how the chrome extension handles offline singing.

    2. Bertrand WILLIAMSRIOUX

      Si Chen Kamlesh Nagware Pritam Singh

      I managed to get the fabric chrome extension working with a couple adjustments. It provides a fabric connector for the clients browser, requesting a network url for the client app server and lists the available network endpoints (orderer/peers). Similar to how you can select a custom blockchain RPC in Metamask. See figure.

      When submitting a transaction request from the browser it requests transaction confirmation from the user (see next figure), however it appears to rely on the middleware (node.js server) to store and retrieve the private keys for signing. 

      We can use this extension as a connector between the user and the fabric network. But for it to work like a Metamask wallet need to implement the offline signing, for example following the logic I started developing in the offline signer demo.

      Question. Should I focus on 

      1. using the browser extension to implement a Metamask style wallet for the app user?
      2. implementing a cloud keystore (e.g. Vault transit engine) hosted by the organization for its users?

      The first is more inline with the initial project plan, but limits user access to the device where the private keys are stored in the extension.

      1. Si Chen

        Bertrand WILLIAMSRIOUXThis is good.  Could you also take a look at https://www.keycloak.org/ and see what features it offers?

        Then we can compare all the different options on our Monday's call.  Peter Somogyvarifrom Cactus will also be joining us, and I'd like to hear his thoughts, as he's been working with Pritam Singhon the security module for the Ethereum key in the Cactus plugin. 

      2. Kamlesh Nagware

        It's great it works because that was bit old code.


        If here offline signing key integrated then it can be same like metamask wallet. We can discuss this in next peer programming call and decide which is best way for client security.

      3. Robin Klemens

        Bertrand WILLIAMSRIOUX, many thanks for all your inputs. This makes it easy to follow your thoughts and great progress.

        I'd suggest continuing with (1) and focus on working with offline keys. From my view, working with offline keys is the fundamentals we have to do anyway. Once we know how to handle offline signing, we still can decide if we want to use HashiCorp Vault, HSM, HashiCorp Vault & HSM for the key management or if want to build a browser extension like Metamask for Hyperledger Fabric. 
        Looking forward to our discussions in 1-.5 hours.

  8. Si Chen

    I just asked Chainlink how they store private keys for accessing Ethereum, and the answer is "they are stored in the filesystem as well as the database encrypted with a passphrase..."