Ivan, I now understand your confusion. Your statement:
"Private data is only known to the party sending the data hash and no one else (including members)."
The chaincode can require that the transaction submitter include the private data in the transient field when invoking the chaincode. Any party that endorses the chaincode execution will have the private data, and it will also be disseminated to all other collection members. If the transaction submitter does not provide the private data at chaincode invocation time, they will not be able to gather sufficient endorsements, and the transaction will not be validated.
As we have been saying, it is up to the chaincode to enforce any such data validations and agreements.
"Ivan Ch" ---10/25/2019 12:31:02 AM---> > You are essentially suggesting to add a warning that private data content
From: "Ivan Ch" <acizlan@...>
Date: 10/25/2019 12:31 AM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Major security hole in Hyperledger Fabric - Private Data is not private #fabric #fabric-questions #fabric-dstorage #database #dstorage #dstorage-fabric #fabric-chaincode #ssl
Sent by: fabric@...
You are essentially suggesting to add a warning that private data content can't be known by non-members of the collection. That is the whole point of private data and anybody considering an implementation will already know this. The non-members only validate against a hash of the data. The members can later share the private data content with non-members if a need-to-know arises, and the non-member can then validate the pre-image content against the hash on chain, with an understanding that only the group of transactors may have come to agreement on the data. This is the fundamental design of private data.
that is not true. Private data is only known to the party sending the data hash and no one else (including members). that's where the security flaw comes because an adversary can use the chain hash to trick others to believe that's the data is legit.
this is a methodology problem and many projects (including ones I am involved with) are required to use it by customers in the application design (because fabric claims this protect data) and it become obvious that there are security gaps almost impossible to overcome, unless all participants are honest (not a good assumption)
since Fabric is by far the most influential DLT platform, it should promote best practices and not tools that can be easily used to create security flaw.