Hyperledger Fabric and Composer privacy support - the full scenario

Question

Hi everyone and thanks in advance for your help, i'm trying to understand hyperledger fabric (and composer) privacy capabilities.

The application scenario sees different sellers and deliverers in the same network (e.g. i brought a package from Amazon (placed an order), chosen to be delivered by the A courier that, for costs reason, decided to cooperate (sub-delegate) with the courier B for a single stop in the multi-stop delivery path planned for the package to arrive to the customer). For this order, I want Amazon, courier A and B to see delivery plans details, but i don't want other sellers or deliverers to see it.

Now, the above mentioned requirement may be enforced using Composer ACLs (or, similarly, writing a chaincode with the same constraints in Go in Fabric). The only issue is that other deliverer or seller peers would have full access to the world state and ledger history on the disk, so that they can circumvent ACL enforcement and access all the data related to other organizations' agreements.

ABAC (Attribute Based Access Control) enforcement, using enrolling certificate attributes to conditionally discriminate access and transaction execution in the chaincode, have the same limits: I think it may be useful mainly to assess different roles in an organization (e.g. an admin from a normal user).

Then we have the option to keep "private data" (prices, etc) out of the ledger, using a different system to store them out-of-band. This is ok, but other organizations will be able, if we don't use channels, to understand with whom we're doing business with and the approximate number of orders and deliveries. This private information can be even be inserted inside the blockchain network using, starting from Fabric 1.2, Private Data Collections (PDC), avoiding using a different external system, since we can just specify which data must be stored by which organization peers only. Anyway, PDC configuratin data are just shared JSON files, so every organization can understand with whom you're doing business with.

Finally, we have the Channels: we could instantiate a channel for the Amazon-Courier A - Courier B group, to be used for this order and orders in the future that have them as actors. This seems ok, since order data is now disseminated only between channel peers. Considering the administrative burden to configure and maintain a channel, a huge scenario like ours, in which we have thousand of sellers and couriers, may require potentially NxM2 channels, with N number of resellers and M the couriers, which seems not feasible.

Did I get it all right? there are other consideration to be made, in your opinion? Thank you very much

Answer 1

Thanks you for your kind answer, very appreciated.

Let's dive into a more detailed scenario and sorry if i'm wrong: i'm just learning. Let's suppose that I write one chaincode to create and save an order on the ledger, that could be used by every reseller for its own orders (so, installed on each reseller endoring peer). Both Amazon and Walmart would use this chaincode, because it's ok for the same functions and goals. Also the creation and updating of the delivery process are standardized chaincodes to be invoked by each courier, so they are installed on each courier organization.

In this simplified scenario, we would have the same chaincode potentially to be installed on an endorsing node depending only on the organization type (reseller or courier) and not by the specific organization "name" (identifier). Having PDC (e.g. for the delivery fee data only) in this case would still be feasible? As far as I understood, collection configuration JSON is binded to the chaincode and you have to specify the specific org peers identifiers in it: would you then need different "order create" chaincodes for each reseller and different "delivery process create" chaincodes for each courier to use PDC, keeping JSON shared only on authorized peers and, at the same time, specifying the peers id?

If I'm not completely wrong with the previous statements, seems to me that ACL mechanism (which is the same as conditional clauses if\then in a chaincode, if you are not familiar with composer), that allows only specified organizations to access transaction and ledger data according to their role in the transaction or with the data, is the best way to protect data privacy between competing (but, in a subsequent transaction, potentially cooperating) actors in a single channel. The only problem is that the ledger is shared between all organization peers, than it can be directly read on the peer disk, circumventing ACL data access control. Maybe only with a private data encryption mechanism, with keys available only to specific transaction\data stakeholder, this can be solved (or with different channels, but combinations between Resellers and Couriers can make it very hard).

Let me known if you agree or if you spot where I'm wrong and how this problem is actually tackled in hyperledger. Thanks a lot! A

Answer 2

I think you are partially right, according to your scenario where you want two org (Amazon and Courier) and in that say 3 peers (1 from Amazon and 2 from courier A and courier B ) to share data in that case Private Data Collection will be the best option(i have worked on HL fabric, can't comment on ACL). Why?

1. You don't want the entire business logic to be different, just some part of data to be private. Thus if you create a new channel you have to install a new chaincode(or same one again).
2. PDC allows for use cases in which you want all channel participants to see a transaction while keeping a portion of the data private.

refer When to use a collection within a channel vs. a separate channel

And another thing that you mentioned, "Anyway, PDC data are shared JSON configuration files, so organization can understand with whom you're doing business with." Thats not true , only the org/peer instantiating the chaincode has the access to the collections-config.json file as we dont instantiate the chaincode on each and every org/peer, so you can think of only Amazon having access to the json file and thus the info about "whom you're doing business with"