Query permissions do not apply to validators and validators can choose to leak data arbitrarily if they are evil or compromised.

Iroha2 trying to follow permission ideology for ISI execution and queries.

Execution of every ISI passes through consensus and it ensures expected permissions execution while consensus is not broked.

Queries do not pass through consensus. It makes it possible to change Iroha2 codebase on one node and makes it possible to execute queries with unexpected rights for other network nodes. Other network nodes will just not know about such executions. 

The motivation for such an attack:

  1. It is possible to reduce trust and discredits the network security performing such an attack because any user will have the possibility to get previously permission data.
  2. This attack makes it possible to get private data secured by-laws that may cause the penalty for the company responsible for the network.
  • No labels

14 Comments

  1. Nikita Puzankov

    Iurii Vinogradov by the following:

    Queries do not pass through consensus. It makes it possible to change Iroha2 codebase on one node and makes it possible to execute queries with unexpected rights for other network nodes.

    you mean that if we have malicious Peer which has another codebase it will provide an ability to get data from the blockchain without checking permissions? If so - than yes, any modifications in the code of the Trusted peer will provide an ability to get the whole blockchain stored information.

    1. To secure data it should be end to end encrypted and even trusted peers should not have an ability to decrypt it.
    2. Consensus does not relate to Iroha Special Instructions or Iroha Queries - it is about voting on the block addition to the ledger's blockchain. Modifications to the trusted Peer code can provide an ability to execute illegal instructions on behalf of that peer, changing it's local blockchain state and attempting to vote for these changes in consensus. Even more - if someone will deploy a lot of such a peers and make "non malicious" peers struggle from network problems it can place illegal data on the chain.

    So I do not see any Query specific flaws here. Correct me if I'm wrong.

    1. Iurii Vinogradov

      ISI I think the situation is clear and it is clear while we are protected here with consensus and where consensus protection meets its limits. So only one malicious node cannot create a big problem for the network with well-designed consensus.

      With queries situation currently is different. Only one malicious node is enough to disclosure private data. And it does not feet with our ideology to enclose data by permissions, so it is vulnerability. 

    2. Iurii Vinogradov

      Not only total encryption can be a solution for this vulnerability. We also can try to think about some partial disclosure.

      1. Vladislav Markushin

        Even with consensus, when a malicious node gets this information, it can disclose this information without any restrictions

        1. Iurii Vinogradov

          Yep, you are right. A malicious node can not participate in consensus normally.

  2. Salakhiev Kamil

    Indeed such vulnerability exists.

    Iroha1 does not handle it, but Iroha1 is private blockchain and executed in secure environment.

    As Iroha2 is planned to be a public blockchain we should think how to handle such vulnerability. Right now I don't have good suggestions. Will think about it

    1. Nikita Puzankov

      I don't think that it is a vulnerability - it's a feature of public data storage such as open blockchain.

      1. Iurii Vinogradov

        It can break permission model, and it is vulnerability in this case. You are very careful trying to protect block data in queries not to be accessible by everyone, but this case can break any protection by permission easier than with ISI which changes state. 

        1. Nikita Puzankov

          I think there are couple of nuances:

          1. Permissions protect Blockchain from unauthorized access (read and write) on the border between trusted parties (peers) and not trusted (clients). 
          2. Usage of Blockchain technology itself in pair with `Sumeragi` consensus guarantee that "virtual" Blockchain (chain version that is approved by the 2f + 1 peers) can be treated as a truth, if we trust these 2f + 1 peers.
          3. Neither permissions nor consensus guarantee that information stored in "plain" format (unencrypted) could not be obtained by malicious parties (peers with hacked code or clients with stolen keys). The only way to protect such data is to use end to end encryption and storing assets values in ecnrypted format, working with plain data only on trusted hard and software, keeping encryption keys in safe place outside of the blockchain.
            1. Problem of peer's trust addressed in Hijiri - with target release in Iroha 2.1.
            2.  Sensitive and any other information with security requirements should not be stored in the plain form on the blockchain.

          1. Iurii Vinogradov

            Yes, there is also another nuance, that developers might expect that our permissions work at least while consensus not broken. I think they should be at least informed about the situation and as you wrote - not store any sensitive information on blockchain.

  3. Makoto Takemiya

    This is by design as Iroha is a blockchain that does full validation on transaction data, instead of just ordering of hashes (as in Fabric). This means that all validators know the data and can leak it if they are evil. For public networks like Sora, this is not a problem. For private networks, the network participants much be selected carefully so that only trusted peers join.

    A possible future solution is to use something like RSA Accumulators and make a solution that is encrypted so no validators knows the contents.

    1. Nikita Puzankov

      Asset's content can be encrypted in Iroha2 to protect sensitive information.

      1. Makoto Takemiya

        Sure, but the validators all have to see the core content to do stateful validation.

        1. Nikita Puzankov

          Sure - all Instructions and Asset/Account/Domain Ids should be available for peers.