Modeling Multi-Layer Access Control Policies of a Hyperledger-Fabric-Based Agriculture Supply Chain
Download as PPTX, PDF0 likes254 views
The document discusses the modeling of multi-layer access control policies for a Hyperledger Fabric-based agriculture supply chain, emphasizing the need for business confidentiality and enhanced data traceability. It proposes a process to model, validate, and assess privacy implications of these policies, demonstrating their application in a real-world scenario. The study also identifies potential access control faults and highlights the importance of securely managing data visibility among supply chain participants.
![• Focus on safety properties
• Fundamental security requirements on whether a policy leaks access permission to
unauthorized or unintended subjects
• 3 types of safety property violations (aka., faults)
1. Privilege leakage – A subject can access objects prohibited by security requirements
2. Privilege blocking – A subject’s legitimate access to an object is blocked
3. Privilege conflict – Multiple access control rules result in conflicting decisions
• Many tools to validate access control policies against safety properties
• Li et al. [18] compared 8 tools under 11 metrics
• We chose NIST’s Access Control Rule Logic Circuit Simulation (ACRLCS) technique
• Models policies as a hierarchically-designed digital logic circuit
• Supports static, dynamic, & historical access control models; separation of duty
• Real-time detection of privilege leakage, blocking, & conflicts
Verification Tool Section
13 | A. Li et al., “Evaluating the capability and performance of access control policy verification tools,” in 2015 IEEE Military Communications Conf.
(MILCOM), 2015, pp. 366–371.](https://image.slidesharecdn.com/modelingmulti-layeraccesscontrolpoliciesofahf-basedagriculturesupplychain-211215001808/85/Modeling-Multi-Layer-Access-Control-Policies-of-a-Hyperledger-Fabric-Based-Agriculture-Supply-Chain-13-320.jpg)
Modeling Multi-Layer Access Control Policies of a Hyperledger-Fabric-Based Agriculture Supply Chain
- 1. Australia’s National Science Agency Modeling Multi-Layer Access Control Policies of a Hyperledger-Fabric-Based Agriculture Supply Chain rmat it correctly: Use the styles within this template H.M.N. Dilum Bandara, Shiping Chen, Mark Staples, and Yilin Sai Data61, CSIRO Sydney, Australia Dilum.Bandara@csiro.au
- 2. • Blockchains’ transparency & immutability Enhance traceability & trust in agriculture supply chains • Users worry about business confidentiality Prefer to keep data off-chain • Better clarity on “who can see what data” Encourage active data contribution • While blockchains are proposed for access control in other systems, no detailed study on blockchain platforms’ access control • Propose a process to model & verify such complex policies • A case study of an agriculture traceability platform based on Hyperledger Fabric • Model its 5 layers of multi-layered & multi-model access control policies • Model & validate safeness of those policies using NIST’s access control rule logic circuit simulator • Conduct a reflective privacy assessment to answer “which other participants can see my data?” • Enhance supply chain participants’ confidence in storing data on-chain Research Contribution 2 |
- 3. Q. Lu et al. (2021) • Many use cases • Provenance & traceability for food safety & biosecurity • Supporting farmer cooperatives, agriculture finance, & precision agriculture • Needs to ensure business confidentiality of data • Direct competitors – Farmers • Indirect competitors – Farmer & Distributor • Permissioned blockchains can partly address such concerns • Use multiple access control models spanning multiple layers • However, it’s nontrivial to determine “who can see what data” • Consequently, most data are kept off-chain • Limits automation, efficiency, & real-time compliance enforcement Blockchain in Agriculture 3 | Q. Lu et al., “Integrated model‐driven engineering of blockchain applications for business processes and asset management,” Software: Practice and Experience, 51(5), 2021, 1059-1079.
- 4. Supply Chain Scenario • Derived from a real blockchain- based traceability platform for an agriculture supply chain • Client • A keystone company in the ecosystem • Had the greatest exposure to regulatory compliance risks • Did the integration • A consortium governs the platform • Subset of parties hosted a blockchain node • Others connected via API • Build on-top of Hyperledger Fabric using cloud-native technologies 4 |
- 5. Hyper Ledger Fabric • A modular, permissioned, & open-source blockchain framework • Emphasizes data privacy & performance • Logical partitioning of the ledger 1. Channels – Hides transactions from non-members 2. Private Data Collections (PDCs) – Hides data on a transaction • Policy-driven access control • Process 100s to 1,000 TPS under varying conditions • Applied in multiple horizontally & vertically integrated supply chains 5 | ABAC - Attribute-Based Access Control ACL – Access Control List PBAC - Policy-Based Access Control RBAC - Role-Based Access Control RBAC-A - RBAC, attribute centric
- 6. Gain supply chain participants’ confidence to contribute data & actively engage in blockchain governance by answering: 1. How to model multi-model, multi-layer, & dynamic access control policies in the traceability platform? 2. Are those policies free of conflicts & effective in ensuring data safeness? 3. Which other parties can see my data? Goal 6 |
- 7. Modeling Access Control Policies 7 |
- 8. • Entities in a Fabric network have unique identities • X.509 certificate • An identity belongs to an organization & has a set of attributes • Organizational Unit (OU) – Node OU – special OU used to confer a role on an identity • Role 1. client – Invoke smart contracts 2. admin – Network management, Invoke smart contracts 3. peer – Maintain ledger, Endorse transactions by executing & signing their results 4. orderer – Order transactions into blocks • Union of identity & its attributes is called a principal • Farmer.client Subjects 8 | Source: https://hyperledger-fabric.readthedocs.io
- 9. • Users issue transactions that invoke chaincodes • Can also subscribe to blockchain events streams • These endpoints are resources requiring access control • Fabric lists 19 resources in configtx.yaml • Specified using component/resource format, e.g., • _lifecycle/CommitChaincodeDefinition • event/Block • Other resources that need protection • Data in a smart contract • Smart contract functions • API endpoints Objects 9 |
- 10. • Describe how an identity or role (aka., subject) may access a resource (aka., object) • Fabric defines 6 high-level actions 1. Readers – Read data 2. Writers – Write data 3. Admins – Administrative actions 4. Endorsement – Execute transactions & sign their results 5. LifecycleEndorsement – Endorsement related to lifecycle management actions of a chaincode 6. BlockValidation – Packaging transactions into a block & signing it • Only read & write actions are distinguished at chaincode & API layers Actions 10 |
- 11. • A set of rules that defines how decisions are made & specific outcomes are reached • Reflect business needs • Fabric evaluates signatures attached to a transaction & validates that they fulfill access control needs • 2 types of policies 1. Signature – Requires a transaction to include explicit sign-off from principals 2. ImplicitMeta – Aggregates result of policies deeper in a configuration tree Policies 11 | /Channel/Application/Endorsement: Type: Signature Rule: AND(Farmer.peer, Processor.peer) /Channel/Application/Admins: Type: ImplicitMeta Rule: MAJORITY Admins …/Farmer/Admins …/Processor/Admins …/Client/Admins (Any 2 organizations out of 3 can satisfy MAJORITY) /Channel/Application/Farmer/Admins: Type: Signature Rule: OR(Farmer.admin)
- 13. • Focus on safety properties • Fundamental security requirements on whether a policy leaks access permission to unauthorized or unintended subjects • 3 types of safety property violations (aka., faults) 1. Privilege leakage – A subject can access objects prohibited by security requirements 2. Privilege blocking – A subject’s legitimate access to an object is blocked 3. Privilege conflict – Multiple access control rules result in conflicting decisions • Many tools to validate access control policies against safety properties • Li et al. [18] compared 8 tools under 11 metrics • We chose NIST’s Access Control Rule Logic Circuit Simulation (ACRLCS) technique • Models policies as a hierarchically-designed digital logic circuit • Supports static, dynamic, & historical access control models; separation of duty • Real-time detection of privilege leakage, blocking, & conflicts Verification Tool Section 13 | A. Li et al., “Evaluating the capability and performance of access control policy verification tools,” in 2015 IEEE Military Communications Conf. (MILCOM), 2015, pp. 366–371.
- 14. • Channel & PDC membership as Boolean functions • Compliance Manager (CM), Framer (FR), Processor (PR), Transporter (TR), & Primary Consumer (PC) are in Post Harvest PDC • PDCPostHarvest = CM + FA + PR + TR + PC • Default set of action-related policies in Fabric for Compliance Manager organization • Readers = CM.client + CM.admin + CM.peer • Writers = CM.client + CM.admin • Admins = CM.admin • Endorsement = CM.peer Representing Policies with ACRLCS 14 |
- 15. Representing Policies with ACRLCS (Cont.) 15 | /Channel/Admins = MAJORITY Admins /Channel/Application/Admins = MAJORITY Admins /Channel/Orderer/Admins = MAJORITY Admins CM BR AC DR FA PR CO Admins = CM.admin Similarly, AND gate can be used to link hierarchical & multi-layer policies
- 16. • To detect faults, ACRLCS requires Grant & Deny circuits • There’s a conflict if both Grant & Deny circuits result in logical 1 • Grant – admin role can change channel configuration • Deny – client, peer, & orderer roles can’t change channel configuration • When it’s difficult to specify security properties either in a grant or deny circuit • To detect privilege leakage, look for outputs that result in 1 but should have been 0 • To detect privilege blocking, look for outputs that result in 0 but should have been 1 Access Control Evaluation 16 | _lifecycle/CommitChaincodeDefinition: /Channel/Application/Writers Writers = CM.admin + CM.client Grant Deny Even clients can install chaincode
- 17. • Which other participants can see my data? • Assume the position of a potential data accessor for the sake of assessing the privacy implications of access control policies • A farmer (FA) may want to know how the distributor (DR) sees their data • Distributor can only see farmers inputs not outputs Reflective Privacy Assessment 17 | PDCPreHarvest PDCPostHarvest Channel
- 18. • Enterprise blockchain-based applications adopt multi-layered & multi-model access control policies • Proposed a process to model & verify such policies to determine “who has access to what data?” • Demonstrated it using an agriculture tractability platform built on Hyperledger Fabric • Used NIST’s ACRLCS technique to verify polices • Identified 2 access control faults in Fabric’s default policies • Used ACRLCS circuits simulation for reflective privacy assessment • ACRLCS can capture a broader set of models Our process could be applied to other blockchain-based applications & frameworks • Future work • Model workflow access control as many business processes are enforced using smart contracts • Develop a test oracle to generate transactions to validate access control implementation of an entire blockchain-based application Summary 18 |
- 19. Australia’s National Science Agency Dilum.Bandara@csiro.au linkedin.com/in/dilumb/
Editor's Notes
- #3: transparency & immutability amplify business confidentiality concerns
- #7: Model policies Model & validate safeness of those policies reflective privacy assessment
- #14: Subjects, objects, actions, & their attributes are represented as Boolean variables
- #20: Architectural Trade-off Analysis Method (ATAM)