Re: Major security hole in Hyperledger Fabric - Private Data is not private #fabric-chaincode #ssl #fabric #fabric-questions #fabric-dstorage


Hi Ivan,

I think I understand your concern. Let me try to include some comments based on the ongoing discussion:

Semantics of data
Your example: “my national ID is "1234567", but I am a bad guy and want others to believe that my national ID number is "7654321". so I put the false hash(salt, "7654321") on chain, and then send pre-images (salt, "7654321")  to whoever I want to convince. Since nobody can verify the hash(salt, "7654321")  when the hash was put on chain without prior knowledge of the data, an adversary can use the claims about private data functionality to trick people to believe forged data.”

Please take into account that the fact of storing something in Blockchain and being able to demonstrate it was stored would not certify the semantics of your data, at least, no more than the certification the business logic of the smart-contract would guarantee. So, if a client application is sending just a digest, there wouldn’t be a way for the smart-contract alone to execute a meaningful validation.

In the example above, if peers do not have a way to validate your national ID, peers may never claim the provided or stored data is valid. This scenario is not limited to HF or Blockchain but to any procedure.

Dictionary attacks
As you pointed out and already explained along the thread, by sending not only the digest but also a SALT as transient data, only selected peers will receive your SALT so preventing dictionary attacks.

Revealing data
As you mentioned, just one corrupted or compromised peer is enough to reveal its data. That is a very general problem and in such case, you would need to prevent a single peer from gathering entire pieces of your data or use homomorphic encryption.


On Fri, Oct 25, 2019 at 1:42 AM Jay Guo <guojiannan1101@...> wrote:
Hi Ivan,

There's a distinction between protecting data from being seen by others and proving the data is legit. Fabric Private Data is designed for the former, and the later is an application design problem (i.e. you need to have multiple parties to endorse original data before putting that on chain, ,while keeping it private from others).

Basically the semantics of your pre-image are not something Fabric could/should care.

- J

On Fri, Oct 25, 2019 at 12:30 PM Ivan Ch <acizlan@...> wrote:
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.
Hi Dave,

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.

Join to automatically receive all group messages.