1. Messages
  2. Major security hole in Hyperledger Fabric - Private Data is not private

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

Alexandre Pauwels
 

Hey Ivan,
Correct me if I'm wrong, but it seems you are thinking that the private data as implemented is flawed, and that the requirement to salt the data to secure it defeats the purpose of having the blockchain in the middle; again, let me know if this is a bad assumption of your thinking. However, the private-data store (which I'll call the pre-image store) and the chain of hashes (which I'll call the block store) exist for parallel but complementary reasons.

The block store cannot exist on its own as it stores no useful data which can be acted upon, this is obvious. It is simply a list of updates to salted hashes.

The pre-image store cannot exist on its own as, when you receive new information, you have no idea if the person giving you the information is giving you the same information that everyone else has. The purpose of the chain of hashes is to ensure that the plain-text information you have is the same copy of the plain-text information that everybody else has.

The role of ensuring that the data initially placed on the chain is accurate is NOT something that is determined by either data storage methods, it's something that's determined by the logic in your chaincode, e.g. in your example, you would be unable to send an update claiming your national ID is "7654321" in the first place, as the government which wrote the chaincode that you are calling would not allow you to do so. A better example would be to say that you are a bad actor and you would like to fool someone into thinking you are individual with ID "7654321". You would give them your public cert and your claimed ID along with a salt, and they would be unable to verify it as when they query for the national ID by the cert and then hashed it with the salt you gave, the hashes would not match.

Hope that makes sense,
Alex


On Tue, Oct 22, 2019 at 10:59 PM Ivan Ch <acizlan@...> wrote:
Hi Yacov, 

thanks for your reply, let me clarify the jargon here so more people can understand

pre-image: data itself and its salt
"Private data is disseminated in a point to point manner among peers even now.The peers that posses the private data, send the peers that don't (but are eligible of receiving it) the hash pre-images, and the receiving peers validate the hash pre-images indeed correspond to the hashes on the public block.

I don't see any technical obstacle that prevents you to add a salt per collection name for a given transaction, that will be concatenated to the computation of the hash of the key and the value for the said collection.The salt can be part of the data element that is generated at the time of chaincode invocation, and will be passed along with the private data itself."
first of all, I appreciate you agree that another point 2 point connection must be established between orgs to pass the salt and the image itself, anything on chain can be used to launch pre-image/dictionary attack

of course there is no technical obstacle to create salt, but the issue here is that it creates a false sense that data is private and can be validated. let me explain:

you try to argue that the salted hash on the public chain is a proof that some data is "valid". this itself is a terrible argument because hashes (unlike digital signature, homomorphic encryption) is not something that others can verify when the data (hash) it put on public chain.

here is an 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.

my point is that the claims about private data mislead people to believe this feature will either help to orgs to protect data or validate a pre-existing data, but neither is true and can be easily used by an adversary to decode data (if there is no salt or salt is known) or to trick people believe in wrong data like the sample above.
Join fabric@lists.hyperledger.org to automatically receive all group messages.