Controlled information sharing in organizations is essential to prevent unauthorized disclosure and malicious or accidental unauthorized changes to data, while ensuring accessibility by authorized users whenever needed: i.e., grant availability of data while ensuring its confidentiality and integrity. Given the diffusion and impact of insider attacks, and the constraints and guarantees introduced by privacy regulations (e.g. GDPR), we propose a framework that employs the Hyperledger Fabric Distributed Ledger Technology (DLT) to guarantee the strong integrity of the audit log, a single point of policy administration, and the efficient and distributed enforcement of policies with less trust in administrators.

More information about the framework, including a performance evaluation and a security assessment against insider attackers can be found on: U.Morelli, S.Ranise, D.Sartori, G.Sciarretta, A.Tomasi, "Audit-Based Access Control with a Distributed Ledger: Applications to Healthcare Organizations". In proceeding of the 15th International Workshop on Security and Trust Management (STM2019).

Our prototype implementation is available under license Apache-2.0 on GitHub.

Access request flow

  1. The user makes an access request through her appplication APP. Transparently to the user, the App first invokes a decision request chaincode (installed on peer nodes) on Hyperledger Fabric (HF).
  2. The Policy Decision Point (PDP) checks the Policy Information Point (PIP) for attributes: for instance, resource attributes from the HF database, principal attributes from their certificate, or environment attributes from the local host.
  3. The PDP evaluates the request against the policies.
  4. The HF network reaches consensus.
  5. The PDP's decision is committed to the immutable log of all peers.
  6. The decision is available to be referenced by the user's App.
  7. If the decision was to grant access, the App can establish an off-chain secure channel to request the Electronic Heath Record (EHR) from the Health Service Provider (HSP). The App creates a signed token referencing the transaction ID containing the decision, and signs this token with the same key used to request access in HF. Concretely, this can be achieved with a standard JSON web token.

8. The PEP of the HSP validates the signed token, composes an HF network query for a valid transaction with the correct id, and checks that the public key validating the token signature corresponds with the public key of the identity that created the transaction.

9. If the token is validated, the keys correspond, and the decision was to grant access, the PEP accesses the requested EHR.

10. Finally, the PEP releases the requested EHR to App.

Who we are

Damiano Sartori

Student@EIT Digital Master School, Trento, Italy damiano.sartori@studenti.unitn.it

Alessandro Tomasi

Researcher@Security&Trust - Fondazione Bruno Kessler, Trento, Italy umorelli@fbk.eu

Silvio Ranise

Head of Security&Trust @ Fondazione Bruno Kessler, Trento, Italy ranise@fbk.eu

Umberto Morelli

Collaborator@Security&Trust - Fondazione Bruno Kessler, Trento, Italy umorelli@fbk.eu

Giada Sciarretta

Researcher@Security&Trust - Fondazione Bruno Kessler, Trento, Italy giada.sciarretta@fbk.eu