Modeling and validating multi-layered and multi-model access control policies of a Hyperledger Fabric based agriculture supply chain Citation: H.M.N. Dilum Bandara, Shiping Chen, Mark Staples, and Yilin Sai, “Modeling Multi-Layer Access Control Policies of a Hyperledger-Fabric-Based Agriculture Supply Chain,” in Proc. 3rd IEEE Int. Conf. on Trust, Privacy, and Security in Intelligent Systems, and Applications (TPS 2021) Special Session on Agriculture Cybersecurity, Dec. 2021.

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)

12. Access Control Verification
12 |

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/