Date   

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

Brian Behlendorf <bbehlendorf@...>
 

Lemons into lemonade. Thanks David and others who turned this from flame war kindling to a positive outcome.

Brian

On 10/22/19 8:28 AM, David Enyeart wrote:

Thanks again Ivan for pointing out the documentation hole - here's the doc update that describes how private data is secured:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-content


Dave Enyeart

"David Enyeart" ---10/21/2019 11:03:49 AM---Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fa

From: "David Enyeart" <enyeart@...>
To: "Senthil Nathan" <cendhu@...>
Cc: Ivan Ch <acizlan@...>, fabric@...
Date: 10/21/2019 11:03 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@...





Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fabric recommends that private data be salted to avoid dictionary attacks. As this thread makes clear not everybody knows about the private data solution design considerations. I've opened Jira issue https://jira.hyperledger.org/browse/FAB-16885 to enhance the documentation with these considerations.


Dave Enyeart

"Senthil Nathan" ---10/21/2019 09:58:56 AM---Hi Ivan, Thank you for bringing this. We have discussed about including salt in

From:
"Senthil Nathan" <cendhu@...>
To:
Ivan Ch <acizlan@...>
Cc:
fabric@...
Date:
10/21/2019 09:58 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@...




Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
"id": "file",
"value": "File",
"popup": {
  "menuitem": [
    {"value": "New", "onclick": "CreateNewDoc()"},
    {"value": "Open", "onclick": "OpenDoc()"},
    {"value": "Close", "onclick": "CloseDoc()"}
  ]
}

"salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589

}}


The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil

On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:
      PrivateData is marketed as a data privacy solution in Hyperledger Fabric. Unfortunately, this is just another serious security hole somehow went under the radar, and all projects using this function are at risk.  

      It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

      The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

      The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

      Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

      Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

      How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

      If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

      Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver









-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


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

David Enyeart
 

Thanks again Ivan for pointing out the documentation hole - here's the doc update that describes how private data is secured:
https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-content


Dave Enyeart

"David Enyeart" ---10/21/2019 11:03:49 AM---Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fa

From: "David Enyeart" <enyeart@...>
To: "Senthil Nathan" <cendhu@...>
Cc: Ivan Ch <acizlan@...>, fabric@...
Date: 10/21/2019 11:03 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@...





Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fabric recommends that private data be salted to avoid dictionary attacks. As this thread makes clear not everybody knows about the private data solution design considerations. I've opened Jira issue https://jira.hyperledger.org/browse/FAB-16885 to enhance the documentation with these considerations.


Dave Enyeart

"Senthil Nathan" ---10/21/2019 09:58:56 AM---Hi Ivan, Thank you for bringing this. We have discussed about including salt in

From:
"Senthil Nathan" <cendhu@...>
To:
Ivan Ch <acizlan@...>
Cc:
fabric@...
Date:
10/21/2019 09:58 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@...




Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
"id": "file",
"value": "File",
"popup": {
  "menuitem": [
    {"value": "New", "onclick": "CreateNewDoc()"},
    {"value": "Open", "onclick": "OpenDoc()"},
    {"value": "Close", "onclick": "CloseDoc()"}
  ]
}

"salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589

}}


The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil

On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:
      PrivateData is marketed as a data privacy solution in Hyperledger Fabric. Unfortunately, this is just another serious security hole somehow went under the radar, and all projects using this function are at risk.  

      It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

      The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

      The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

      Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

      Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

      How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

      If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

      Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver









Re: TCerts function in Fabric CA #fabric-ca

Gari Singh <garis@...>
 

We have an open task to remove all of that code from Fabric CA.
I'm planning to remove it in 2.0

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Jeehoon Lim"
Sent by: fabric@...
Date: 10/22/2019 12:04AM
Subject: [EXTERNAL] [Hyperledger Fabric] TCerts function in Fabric CA #fabric-ca

Hi all,


I've read some docs that Transaction Certificates(TCerts) are not supported - replaced by Idemix - from Fabric 1.x .

But there are still remain TCerts related codes in the latest release of fabric-ca.
( https://github.com/hyperledger/fabric-ca/blob/master/lib/servertcert.go )
And it also has some commit history in this year.

Is Fabric CA still support TCerts, or the code is something like wings of chicken?

Regards,
Jeehoon Lim


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

Yacov
 

Hey Ivan.

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.

I don't agree that point to point connections defeat the purpose of the Blockchain, as the all this point to point data that is kept off-chain can be easily and efficiently verified if needed since its value is bound to the public blocks.

- Yacov.



From:        "Ivan Ch" <acizlan@...>
To:        fabric@...
Date:        10/22/2019 12:23 PM
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@...




thanks for reply

but I think you guys are down playing the seriousness of this issue.

if u add salt then the salt must be passed to others so others can validate.

to avoid others to launch  dictionary attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole.

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain.

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible






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

Gari Singh <garis@...>
 

I think you might have missed one of the points on how you can actually pass in a salt value to all endorsing peers.
Proposal (endorsement) requests have a "transient" field which can be used. The value of this field can be extracted in chaincode and used to salt the data. It is never persisted in the actual ledger itself.

-----------------------------------------
Gari Singh
Distinguished Engineer, CTO - IBM Blockchain
IBM Middleware
550 King St
Littleton, MA 01460
Cell: 978-846-7499
garis@...
-----------------------------------------

-----fabric@... wrote: -----
To: fabric@...
From: "Ivan Ch"
Sent by: fabric@...
Date: 10/22/2019 05:23AM
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

thanks for reply

but I think you guys are down playing the seriousness of this issue.

if u add salt then the salt must be passed to others so others can validate.

to avoid others to launch dictionary attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole.

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain.

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible


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

Ivan Ch <acizlan@...>
 

thanks for reply

but I think you guys are down playing the seriousness of this issue. 

if u add salt then the salt must be passed to others so others can validate.

to avoid others to launch  dictionary attack, u must (in ur implementation)force peers to use private point2point connections to send the hash, otherwise u may create another security hole. 

plus, forcing p2p connection among participants would literally destroy the purpose of blockchain. 

this functionality need to change its name to something like "chain hash" to save others falsely believe this is a data privacy functionality. i know there must be marketing concerns calling it "private data", but u guys need to be responsible



Error while registering peer and client certs using LDAP server #fabric-ca #fabric-chaincode #raft

trinayanbhatt1@...
 

I am trying to setup fabric network using external-ca and so I have to register and enroll certs for all the peers and clients and for registration of certificates LDAP server is being used.

After generating everything and starting the network there is some issue with chaincode instantiation as although the chaincode container gets up but still while listing for the chaincode on the peers the result set is empty. After checking for the peer and orderer logs:

peer logs :

warning: isn't eligible for channel testchannel : implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied

error:  [blocksProvider] DeliverBlocks -> ERRO 4488e [testchannel] Got error &{FORBIDDEN}
           [blocksProvider] DeliverBlocks -> ERRO 4488f [testchannel] Wrong statuses threshold passed, stopping block provider

orderer logs:

[common.deliver] deliverBlocks -> WARN 263d [channel: testchannel] Client authorization revoked for deliver request from xx.xx.xx.xx:38880: implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied: permission denied

What I interpret from this is that the admin certificates and the peer certificates have some issue as they are being registered using LDAP where there is no option to define id-type for the identity.

Can anyone help to resolve this issue?


Re: kafka name change (fabric 1.1)

soumya nayak <soumyarjnnayak@...>
 

Hi Alok.

Check this JIRA 

https://jira.hyperledger.org/browse/FAB-7352

Regards,
Soumya


kafka name change (fabric 1.1)

Alok K Venugopal <alokkv@...>
 

Hi

 

Expecting you to help us in this R&D task.

 

4 Kafkas and 3 Zookeepers are distributed in 2 of our servers.  The kafkas' and zookeepers' names are changed. Then, we edited and updated the configurations of all existing channels and also, edited and updated the orderer configuration. After that, we brought up all the containers individually. But, after 5 minutes orderer1 is exiting. And, when we checked the orderer1 logs, we get the following error:



Cannot set up channel consumer = kafka server: The requested offset is outside the range of offsets maintained by the server for the given topic/partition.

 

Also, when we perform transactions using Fabric Client, the query function is successful but invoke is not working.



We appreciate your help in completing this task.

 

 

 

Thank You

Alok K Venugopal

 

    +91 9895052525

  +91 9895052525

   alokkv@...

 

#01-65, Block 81 Ayer Rajah Crescent,

 Singapore 139955

 

        

 

 

 

 


TCerts function in Fabric CA #fabric-ca

Jeehoon Lim
 

Hi all,

I've read some docs that Transaction Certificates(TCerts) are not supported - replaced by Idemix - from Fabric 1.x .
 
But there are still remain TCerts related codes in the latest release of fabric-ca.
( https://github.com/hyperledger/fabric-ca/blob/master/lib/servertcert.go )
And it also has some commit history in this year.
 
Is Fabric CA still support TCerts, or the code is something like wings of chicken?


Regards,
Jeehoon Lim 


Re: Stable version for Fabcoin

Brett T Logan <brett.t.logan@...>
 

FabToken was removed from Fabric. The reasoning surrounding that decision can be found here:
 
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-570-556-7619
 
 
 

----- Original message -----
From: "ming" <rg_ming@...>
Sent by: fabric@...
To: hyperledger-fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Stable version for Fabcoin
Date: Mon, Oct 21, 2019 10:47 PM
 
Hello everyone,
 
I noticed in Fabric Alpha release, Fabcoin functionality is added, however it is not recommended to be used in production.
 
There is a need for Fabcoin in my senario, is there any plan to make a stable release for that, if there is, when?
 
If anyone knows, please let me know,
 
many thanks,
 
Jiaying
 

 

 


Stable version for Fabcoin

rg_ming@...
 

Hello everyone,

I noticed in Fabric Alpha release, Fabcoin functionality is added, however it is not recommended to be used in production.

There is a need for Fabcoin in my senario, is there any plan to make a stable release for that, if there is, when?

If anyone knows, please let me know,

many thanks,

Jiaying


 


Re: Node SDK TLS Gateway Connect - Error: PEM encoded certificate is required.

Nicholas Leonardi
 

I managed to get past that error and go on to another. Instead of the path, I passed the certificate
and got:

Error: Unable to initialize channel. Attempted to contact 1 Peers. Last error was Error: access denied for [GetConfigBlock][examplechannel]: Failed evaluating policy on signed data during check policy on channel [ examplechannel] with policy [/Channel/Application/Readers]: [implicit policy evaluation failed - 0 sub-policies were satisfied, but this policy requires 1 of the 'Readers' sub-policies to be satisfied]

I checked the env variables and the CLI and Peer dockers match. I'm able to peer channel fetch config on both. Gonna investigate and get back to you

Em segunda-feira, 21 de outubro de 2019 15:42:59 BRT, Yacov Manevich <YACOVM@...> escreveu:


I have no clue in the gateway project, but - I think maybe you should also attach to the email you certificate that it claims to not be PEM encoded...



From:        "Nicholas Leonardi via Lists.Hyperledger.Org" <nlzanutim=yahoo.com@...>
To:        Hyperledger-fabric <hyperledger-fabric@...>
Cc:        fabric@...
Date:        10/21/2019 09:39 PM
Subject:        [EXTERNAL] [Hyperledger Fabric] Node SDK TLS Gateway Connect - Error: PEM encoded certificate is required.
Sent by:        fabric@...




Hey,
Having an issue with the node sdk gateway connect for about 4 days now.
This is the code that is attempting to connect with the peer with TLS enabled

         const connectionOptions: GatewayOptions = {
            wallet,
            identity: Admin@...',
            discovery: { enabled: false, asLocalhost: true }
        };

        const connectionProfile = safeLoad(fs.readFileSync('connection.json', 'utf8'));
        const gateway: Gateway = new Gateway();
        await gateway.connect(connectionProfile, connectionOptions);
        const network: Network = await gateway.getNetwork('channel');
        const contract: Contract = network.getContract('chaincode');

And this is the connection.json

{
    "name": "example-network",
    "version": "1.0.0",
    "client": {
        "organization": "Org1",
        "connection": {
            "timeout": {
                "peer": {
                    "endorser": "300"
                },
                "orderer": "300"
            }
        }
    },
    "channels": {
        "examplechannel": {
            "orderers": [
                "orderer.example.com"
            ],
            "peers": {
                "peer0.example.com": {
                    "endorsingPeer": true,
                    "chaincodeQuery": true,
                    "ledgerQuery": true
                }
            }
        }
    },
    "organizations": {
        "Org1": {
            "mspid": "N2miMSP",
            "peers": [
                "peer0.example.com"
            ],
            "certificateAuthorities": [
                "ca.example.com"
            ]
        }
    },
    "orderers": {
        "orderer.example.com": {
            "url": "grpcs://192.168.68.133:7050",
            "tls_cacerts": {
                "path": "/usr/src/app/orderer-tls-rca-example-com-7054.pem"
            }
        }
    },
    "peers": {
        "peer0.example.com": {
            "url": "grpcs://192.168.68.133:7051",
            "tls_cacerts": {
                "path": "/usr/src/app/tls-rca-example-com-7054.pem"
            }
        }
    },
    "certificateAuthorities": {
        "rca.example.com": {
            "url": "https://192.168.68.133:7054",
            "caName": "rca.example.com",
            "httpOptions": {
                "verify": false
            },
            "tlsCACerts": {
                "path": "/usr/src/app/tls-cert.pem"
            },
            "registrar": [
                {
                    "enrollId": "admin",
                    "enrollSecret": "adminpw"
                }
            ]
        }
    }
}
.
Please any help would be appreciated. I don't know what else to do and I've been at it for 4 days.
It seems he's not recognizing the PEM cert.








Node SDK TLS Gateway Connect - Error: PEM encoded certificate is required.

Nicholas Leonardi
 

Hey,
Having an issue with the node sdk gateway connect for about 4 days now. 
This is the code that is attempting to connect with the peer with TLS enabled

         const connectionOptions: GatewayOptions = {
            wallet,
            identity: Admin@...',
            discovery: { enabled: false, asLocalhost: true }
        };

        const connectionProfile = safeLoad(fs.readFileSync('connection.json', 'utf8'));
        const gateway: Gateway = new Gateway();
        await gateway.connect(connectionProfile, connectionOptions);
        const network: Network = await gateway.getNetwork('channel');
        const contract: Contract = network.getContract('chaincode');

And this is the connection.json 

{
    "name": "example-network",
    "version": "1.0.0",
    "client": {
        "organization": "Org1",
        "connection": {
            "timeout": {
                "peer": {
                    "endorser": "300"
                },
                "orderer": "300"
            }
        }
    },
    "channels": {
        "examplechannel": {
            "orderers": [
                "orderer.example.com"
            ],
            "peers": {
                "peer0.example.com": {
                    "endorsingPeer": true,
                    "chaincodeQuery": true,
                    "ledgerQuery": true
                }
            }
        }
    },
    "organizations": {
        "Org1": {
            "mspid": "N2miMSP",
            "peers": [
                "peer0.example.com"
            ],
            "certificateAuthorities": [
                "ca.example.com"
            ]
        }
    },
    "orderers": {
        "orderer.example.com": {
            "url": "grpcs://192.168.68.133:7050",
            "tls_cacerts": {
                "path": "/usr/src/app/orderer-tls-rca-example-com-7054.pem"
            }
        }
    },
    "peers": {
        "peer0.example.com": {
            "url": "grpcs://192.168.68.133:7051",
            "tls_cacerts": {
                "path": "/usr/src/app/tls-rca-example-com-7054.pem"
            }
        }
    },
    "certificateAuthorities": {
        "rca.example.com": {
            "url": "https://192.168.68.133:7054",
            "caName": "rca.example.com",
            "httpOptions": {
                "verify": false
            },
            "tlsCACerts": {
                "path": "/usr/src/app/tls-cert.pem"
            },
            "registrar": [
                {
                    "enrollId": "admin",
                    "enrollSecret": "adminpw"
                }
            ]
        }
    }
}
Please any help would be appreciated. I don't know what else to do and I've been at it for 4 days. 
It seems he's not recognizing the PEM cert. 




Re: Move to Github and Azure Pipelines - Chaincodes/SDKs

Baohua Yang
 

+1, and the Python SDK plans to migrate, too.

Thanks!

On Mon, Oct 21, 2019 at 8:54 AM Matthew White <whitemat@...> wrote:
Hello;
 
In recent weeks there have been discussions on the contributors' calls, and also in RocketChat, about the location of the Fabric repos, and the build pipelines. 
 
The fabric-samples repository has moved over to use the combination of Github for code, and Azure pipelines for CI.
 
fabric-chaincode-node, fabric-chaincode-java are planning to start the move within the next few days. The expectation is that Node will go first.  A prototype of the go contract programming model is already in GitHub.
 
The SDKs will also be moving very soon.
 
Please reach out via this list or on the RocketChat channels with any concerns/questions. 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



--
Best wishes!

Baohua Yang


Move to Github and Azure Pipelines - Chaincodes/SDKs

Matthew White
 

Hello;
 
In recent weeks there have been discussions on the contributors' calls, and also in RocketChat, about the location of the Fabric repos, and the build pipelines. 
 
The fabric-samples repository has moved over to use the combination of Github for code, and Azure pipelines for CI.
 
fabric-chaincode-node, fabric-chaincode-java are planning to start the move within the next few days. The expectation is that Node will go first.  A prototype of the go contract programming model is already in GitHub.
 
The SDKs will also be moving very soon.
 
Please reach out via this list or on the RocketChat channels with any concerns/questions. 
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

David Enyeart
 

Thanks for replying Yacov and Senthil. You're right that since the introduction of private data, Fabric recommends that private data be salted to avoid dictionary attacks. As this thread makes clear not everybody knows about the private data solution design considerations. I've opened Jira issue https://jira.hyperledger.org/browse/FAB-16885 to enhance the documentation with these considerations.


Dave Enyeart

"Senthil Nathan" ---10/21/2019 09:58:56 AM---Hi Ivan, Thank you for bringing this. We have discussed about including salt in

From: "Senthil Nathan" <cendhu@...>
To: Ivan Ch <acizlan@...>
Cc: fabric@...
Date: 10/21/2019 09:58 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@...





Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
 "id": "file",
 "value": "File",
 "popup": {
   "menuitem": [
     {"value": "New", "onclick": "CreateNewDoc()"},
     {"value": "Open", "onclick": "OpenDoc()"},
     {"value": "Close", "onclick": "CloseDoc()"}
   ]
 }

 "salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589

}}


The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil

On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:
    PrivateData is marketed as a data privacy solution in Hyperledger Fabric. Unfortunately, this is just another serious security hole somehow went under the radar, and all projects using this function are at risk.  

    It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

    The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

    The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

    Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

    Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

    How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

    If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

    Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver






Re: Instantiating the chaincode

Srinivasan Muralidharan
 

On blowing it up we see its a fabric-samples/fabcar screen shot showing "golang" and what appears to be an error during chaincode build process. Also interesting that this appears to run in virtualbox. Peer logs should give more information but likely a environment setup issue of some sort.

Murali


On Mon, Oct 21, 2019 at 4:00 AM Matthew White <whitemat@...> wrote:
Hi - Can't really see the details in the screen shot... is this Java chaincode?  If so check the rocketchat channel fabric-chaincode-java for discussion on what could be the issue
 
 
Regards, Matthew.
Matthew B White  IBM Blockchain Solutions Architect
 
Email me at WHITEMAT@...
Find me on StackOverflow, and generally at  calanais.me.uk
 
Note: restricted availability for meetings 14:30 to 17:00 UK Tuesday 
IBM United Kingdom Limited, Hursley Park, Winchester, Hampshire, SO21 2JN

"The wrong answers are the ones you go looking for when the right answers stare you in the face"
 
 
 
----- Original message -----
From: "Marina Wanis" <marinamaged1996@...>
Sent by: fabric@...
To: "hyperledger-fabric@..." <hyperledger-fabric@...>
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] Instantiating the chaincode
Date: Sun, Oct 20, 2019 6:24 PM
 

Hi,

 

I was running the command ./startFabric.sh  but I was getting the following error. I’m not able to Instantiate the chaincode..... any help?

 

 

 

Thanks,

Marina

 

 

Sent from Mail for Windows 10

 

 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup


Channel Update Giving Different Errors Everytime #fabric-questions #fabric

soumya nayak <soumyarjnnayak@...>
 

Hi All,
 
Fabric- v1.4.3 (RAFT Orderer Set UP)
Created a custom policy and added to the application policies , when am trying to do a channel update, every time a different error is coming up like as below --
 
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'legaldescriptionchannel': error authorizing update: error validating DeltaSet: attempt to set key [Policy] /Channel/Application/OrgB/Readers to version 0, but key is at version 0
 
Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'legaldescriptionchannel': error authorizing update: error validating DeltaSet: attempt to set key [Value]  /Channel/Application/OrgB/MSP to version 0, but key is at version 0
 
```Error: got unexpected status: BAD_REQUEST -- error applying config update to existing channel 'legaldescriptionchannel': error authorizing update: error validating DeltaSet: attempt to set key [Policy] /Channel/Application/Org1/Admins to version 0, but key is at version 0```

Regards,
Soumya


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

Senthil Nathan
 

Hi Ivan,

    Thank you for bringing this. We have discussed about including salt in the private data design document --
https://docs.google.com/document/d/1ShrgrYPWLznZSZrl5cnvmFq9LtLJ3tYUxjv9GN6rxuI/edit?usp=sharing
(please refer to section 2.6 Additional Consideration -- Salt Consideration).
We do have a JIRA for the same as well -- https://jira.hyperledger.org/browse/FAB-5101 but didn't implement
it as we have decided to leave it to the user for now (also for simplicity & flexibility).

    The salt to the data can always be added by the client which submits the transaction proposal. For example,
in the following JSON content, there can be an additional field called salt and the user can add any random data
to avoid a dictionary attack.
{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
"salt": 88d4266fd4e6338d13b845fcf289579d209c897823b9217da3e161936f031589
}}

The same can be done for the keys too, not just values. As far as I know, many developers who use private data
follow this approach. I agree that a few might be unaware of this. As Yacov mentioned, we should add this approach
to our doc.

Regards,
Senthil


On Mon, Oct 21, 2019 at 6:51 PM Ivan Ch <acizlan@...> wrote:

PrivateData is marketed as a data privacy solution in Hyperledger Fabric. Unfortunately, this is just another serious security hole somehow went under the radar, and all projects using this function are at risk.  

It amazes me that nobody had mentioned this before so I guess I better point this out now before more damages are being done.  

The logic behind Privated data is simple, it put data in a local embedded data store and put a hash of that data on blockchain.  

The issue is that cryptographic hash is not an encryption mechanism, same data hashed by anyone using the same hashing algorithm will always get you the same hash! This is exactly what hash functions are designed for, and that’s why we use hash in digital signature to allow anyone to validate signed data.   However, this also means that anyone can “decrypt” the data behind the hash by launching dictionary attack.  

Hashing is cheap, the cost of each hash on a normal laptop cpu core is about 3 microseconds, basically I can create 1 billion candidate result hashes within one hour on a single laptop cpu, and check if they match to the hashes on hyperledger fabric DLT.   And I am just talking about using a single cpu on my laptop, not even 50% of its processing power  

Why is it dangerous? Because if an attacker is connected to a blockchain system, the attacker likely know the range of the data being hashed (for example, hashed data could be trade ID, item name, bank name, address, cell phone number), so you can easily create dictionary attack to get the true data behind the hash.  

How about adding salt to each data to be hashed? Well, that’s one thing Hyperledger Fabric didn’t do.   To their defense, hyperledger didn’t implement salt because it is difficult to pass salts to counter parties. You can’t use DLT to pass salt value to counter parties because attackers would see it, so you have to create another p2p connection with counter party and send it over.

If you already have p2p connection with all the counter parties, what’s the point of using blockchain in the first place? just send your data over! It’s just scary that so many people are using this security hole and put their data in de facto clear text.  

Sure, if the hashed data is so big then it would harder to perform dictionary attack, but you better be very careful before using this feature because any mis-use will result in data leak, it is sad so many people actually believe this is a problem solver

4541 - 4560 of 11510