Home Business & Finance
Confidentiality of Transactions
Transaction confidentiality requires that the plaintext of a chaincode (i.e., code or description) is not accessible or inferable (assuming a computationally bounded attacker) by any unauthorized entities (i.e., user or peer not authorized by the developer). It is thus important here that the chaincodes of both deploy and invoke transactions that remain concealed whenever confidentiality is required. In the same spirit, nonauthorized parties should not be able to associate invocations (invoke transactions) of a chaincode to the chaincode itself (deploy transaction) or associate these invocations to each other.
Confidentiality mechanisms in Open Blockchain allow the deployer of a chaincode to grant (or restrict) access of an entity to any subset of the following parts of a chaincode:
Note that this design offers to the application the capability to leverage the membership service infrastructure and its public key infrastructure to build their own access control policies and enforcement mechanisms.
At the time of the writing, the confidentiality features of Open Blockchain are restricted to ensuring confidentiality against nonauthorized users of the system. As such, validating entities are currently considered trusted to access the plaintext of all chaincode resources and not to share it with nonauthorized entities.
To support read-access control of the plaintext of a chaincode, Open Blockchain transaction confidentiality protocols leverage the public encryption keys bound to user identities at enrollment time, as well as a chain-specific encryption public key. That is, for confidentiality purposes, a chain is bound to a single long-term encryption key-pair (pkchain, skchain). This key-pair is generated and maintained within the premises of the membership service infrastructure.
At the deploy time of a confidential chaincode, the payload of the transaction (i.e., chaincode code) as well as the associated metadata are encrypted using a freshly generated chaincode-specific key. The key is passed to the authorized users and validators through messages encrypted with the authorized entities associated with the public encryption key. In addition, the chaincode creator specifies at deployment time the key to be used for the encryption of the chaincode's state each time that chaincode is invoked. Again, access to this key is given to authorized entities using their public keys.
Subsequent invocations of a confidential chaincode are forced to encrypt their payload using the key-material defined at deployment time.
Open Blockchain offers auditability in two layers: (1) at the system level, where auditors are able to monitor all transactions a certain validator is involved in and (2) at chaincode level to allow an auditor to read and access all transactions associated to a specific chaincode. At the same time, an auditor who is authorized to query and get responses back from membership service on a certain user’s transactions is able to get proof of a certain user’s involvement in the chain. Proper key-hierarchies allow for different keys to be used in each transaction while minimizing the number of keys managed at the client-side.
Open Blockchain was recently renamed Hyperledger/fabric as soon as it was shortlisted as one of the candidates of becoming Linux Foundation’s Hyperledger.
There are currently a number of discussions within the Hyperledger community on the best ways to evolve Open Blockchain according to the consortium’s
Current proposals for extending Open Blockchain discussions include the decentralization of membership services, the separation of the consensus (agreement on the total order of transactions and execution of the included chaincodes), as well as extending the confidentiality guarantees to the endorsing entities.