I would like to know how either Fabric or composer can enforce Access Control Logic (ACL). As I read through the documents, ACL is a way to control permission to peers within a channel. When I, as a peer, have a local copy of the ledger, what would prevent me from reading the data that I locally have, although in ACL I am denied to have access? In this case I am talking only about ACL without using the new feature private data collections.
I appreciate any help.
Thank you very much.
Nothing can prevent you from reading the data that you have locally, if you have access to that data.
ACL enforcement in Hyperledger Fabric works via policy evaluation - an ACL is just a policy, and for every action that a network node (peer or orderer) performs - it consults the policy to determine if the requester of the data is eligible according to the policy.
Note, that any data segregation mechanism may be not enough by its own, if the data may be obtained via other actions that have permissive policies. A good example for that is if you have a chaincode that checks that the client originates from a certain organization, but that client's certificate satisfies the "channel readers" policy - then the client can just request the block from the ordering service itself - and just compute the data that the client wants on its own after reading the data blocks.
Every peer can read from his local data but when it comes to data that is stored on ledger peers can't read that data without permission. Actually you as a peer only can access and store some part of ledger that is available not the whole of that.
Related
I would like to use roles to identify what an organization can do in my hyperledger fabric blockchain, so, if org1 is an distributor it can call the contract1 and the contract2 but org2 that has an auditor role can only call contract2.
I am planning of doing it, by storing the msp roles in the blockchain and querying them in the contract to do the validation, and this roles can be stored in the blockchain on the instantiate method.
Something like this:
public async contract1(ctx: context) {
const cid = ctx.clientIdentity;
const role = await ctx.stub.getState(cid);
if (role === 'auditor') {
throw new Error('An Auditor can not issue a transference');
}
....
return response;
}
Is there a better way to associate a role to an mspid? Like directly on the certificate? But if the organization manages the CA, how can I warranty that they don't give themselves super powers and super roles? Or should I check directly on my code for each mspId?
Thanks
I am planning of doing it, by storing the msp roles in the blockchain
and querying them in the contract to do the validation, and this roles
can be stored in the blockchain on the instantiate method.
I think your approach is reasonable. It's open to changes and extensions later on.
Is there a better way to associate a role to an mspid? Like directly
on the certificate?
Embedding Attributes in Certs: As you mentioned, we cannot trust attributes on certificates on organization-wise roles. Our system knows about the root certificate of organizations, so only these can be our reference for such solution. Since client certificates are sighed with these root certificates, we can reach these certificate's issuer certificate as well. If we enforce organizations to put some attributes there, this would bring us a solution. This enforcement occurs during on-boarding time and validated manually by admins. Obviously this is a bad approach. Because it's static and we enforce some certificate actions for our custom solution, etc.
Here is a quick and dirty solution method I used before:
Embedding roles on MSP IDs: This is really a quick and dirty solution. i.e. MSP ID will be set as Org1_xyz where x, y and z are the different roles. You can easily get client's MSP ID and extract the organization's roles from here. It's a safe method since MSP ID is assigned to an organization by the admins during introducing the organization to the system channel. Afterwards it's not changeable at all and also this is information is very dependent on a chaincode logic, where MSP IDs are on higher level definition.
Relying on the contents of an enrollment certificate does indeed introduce a lot of trust on the CA issuing the cert. I know this is the idea behind attribute based access control (ABAC), and in some cases will work, but the trust issues are significant as any CA can issue a certificate with arbitrary "roles". I think the only real way to handle this is to maintain in chaincode a list of identities that you want to grant access to certain functions. Basically create your own access control lists that are maintained onchain.
I am setting up a Fabric application where fragments of symmetric encryption keys need to be stored on peers. Private Data is ideally suited to handle this. However, I am concerned whether network administrators of the peer nodes can access plain-text private data. Does anyone know whether this is possible and if so is there anything that could be done to prevent this?
It is assumed that a peer administrator has access to the file system where the peer stores data. In the case of private data, the private data is made available only to certain organization's peers and saved on the file system of these peers. The system administrator of these peers would therefore be able to access any plaintext private data.
That being said, some vendors that host Hyperledger Fabric as a service have protections in place such that the vendor is unable to access the peer's file system data.
I want to use Access control functionality in Fabric (like permission.acl in Hyperledger Composer), so how to achieve this in Fabric? and how to specify the user while accessing chaincode to test the Access controls provided for that user from node SDK.
eg:(like Tuna-network example in Composer) I want to give different CRUD access to chaincode functions to different participants/users.
There is no direct equivalent in hyperledger fabric for the Composer ACL functionality.
First you should look at access control lists in fabric to ensure that your fabric network has the correct level of security
https://hyperledger-fabric.readthedocs.io/en/release-1.3/access_control.html
(You would have to have done this anyway as even if you used composer ACLs to ensure a participant could not read something, if that pariticpant had the ability to query the ledger or is able to listen for block events they could still infer the data, unless encrypted, regardless of the Composer ACL denying read access).
The other fabric capability you could look at is what's termed "Attribute Based Access Control". This is where attributes with values are associated with a certificate and the fabric shims for each language provide a utility library to allow chaincode to extract those attribute values and then the chaincode implementation can make a decision on whether the identity making the request has the appropriate authority to perform whatever it has requested.
More details can be found here
https://hyperledger-fabric.readthedocs.io/en/release-1.3/chaincode4ade.html?highlight=client%20identity#chaincode-api
What role am I operating from in the logic.js file composer? If I've defined permissions.acl such that two certain types of participant don't have any access to each other, may I still be able to, in my transaction handler (where both participants are involved by reference in the transaction body) inside logic.js, read/write any party's member variables arbitrarily?
Perhaps in other words, how is the "currentParticipant" determined by a transaction? Say I'm using the following started code for my app https://github.com/IBM/customer-loyalty-program/blob/master/web-app/app.js
The transactions are called by the nodejs runtime and not by a specific participant as far as I understand...
To interact with a hyperledger fabric network you will do as using an identity (certificate + private key). The composer runtime in the chaincode accesses that identity and then looks for the participant that it is mapped to. All identities must be mapped to a participant or you get a message saying the <common name> with identifier <unique id for the cert> has not been registered
Commands like composer network start, composer identity issue will bind an identity to a participant for you.
composer identity bind takes an existing identity and binds it to an existing participant.
Looking at securing confidential information in Hyperledger Composer
If assets and transactions in a business network have ACL's to prevent a competitor participant (non-owner) from viewing confidential information, what access can the competitor have to assets and transactions owned by another participant?
Can the competitor access the underlying Fabric ledger to view assets/transactions?
Can the competitor view the transaction processing function?
Can the competitor view the logs of the transaction processing function?
How secure are ACLs?
I don't know if there is some documentation covering this already, or how much is about the security of Fabric rather than Composer.
Dan Selman suggested on RocketChat to ask here.
Thanks
Andrew
Composer's Access Control Engine prevents transaction processor functions written in Javascript from accessing the data in the ledger, based on the type of access requested, the current participant, and the transaction being processed.
The ACL engine does not encrypt the data on the ledger, or attempt to filter the chaincode container logs to remove information.
So, I would say in its current incarnation it is not a suitable mechanism to prevent someone who has physical access to a peer (world state, or the blockchain itself) from viewing information they should not have access to. Modifications are obviously much harder, due to the immutable nature of the blockchain.
In many ways this is similar to access control logic for a relational database. Someone who has physical access to the database files on disk can likely circumvent all access control rules on tables/views etc.
I do believe that we need to go further than this, but first I think we need more detail on the requirements.