Keywords

1 Introduction

Controlled information sharing among the users of a system or a platform operated by an organization is key to achieve business objectives, prevent unauthorized disclosure (confidentiality) and malicious or accidental unauthorized changes (integrity), while ensuring accessibility by authorized users whenever needed (availability). The main security mechanism to achieve this is access control: the process of mediating every request to resources maintained by the organization and determining whether the request should be granted or denied. Defining, deploying, and enforcing the access control policies in complex organizations is a difficult task because of the following three main problems.

First, an organization wishes to define a reference set of policy rules through a single point of administration for uniformity and enforce them in a distributed way for efficiency. In large and geographically dispersed organizations, this requires placing trust in several policy administrators to align the local copy of evolving policy rules and maintain the integrity of the policy enforcement and decision points.

Second, a priori access control – i.e. granting or denying an action before it is performed – is not always possible or desirable. Predicting all possible circumstances under which access should be granted or denied is a daunting task, given the complexity of the workflows supported by modern organizations and the additional authorization conditions imposed for instance in compliance with privacy regulations, such as the General Data Protection Regulation (GDPR) [8]. Taking a permit-override approach may cause security issues, while a deny-override may cause unacceptable frictions in accessing data and ultimately safety issues; for example, frictionless accessibility to patient data is crucial to taking effective and timely clinical decisions.

Third, given the impossibility to adopt a purely a priori approach to access control, as observed in e.g. [5], the use of an audit log to record the evidence of each request and decision that has been made during access control enforcement is of paramount importance to enable the a posteriori verification of privilege abuses – e.g., doctors using patient data for clinical trials, even when consent had been granted for the purpose of treatment only. Integrity of the log is a mandatory requirement for auditing but is not trivial to guarantee; it requires technical measures – setting up an isolation boundary around the audit log so that it can only be accessed through a pre-defined set of functionalities – and requires additional trust to be placed on administrators that are assumed not to exploit their legitimate access rights to the audit log.

As a result of the difficulties of solving the three problems above, administrators and users with privileged accounts may abuse their rights, either inadvertently or maliciously, enabling insider attacks with severe impact. Recent reports show that insiders are involved in 23% of data breaches on average, and in 56% in healthcare organizations in particular [28, 29].

To address these problems and mitigate the risks related to privilege abuses, the main contribution of this paper is an Audit-Based Access Control Enforcement (AuBACE, Sect. 3): we leverage Distributed Ledger Technology (DLT) to provide (i) strong integrity of the audit log, (ii) a single point of administration to define a uniform policy for the entire organization, and (iii) efficient and distributed enforcement with less trust in administrators. Although our discussion and findings hold for arbitrary organizations, we consider a healthcare scenario (Sect. 1.1) for concreteness and because the three problems identified above are particularly severe for these organizations.

In addition, we provide the following two contributions: a security assessment against insider attackers (Sect. 4) and an experimental evaluation (Sect. 5) of a prototype implementation based on Hyperledger Fabric (HF), a widely used private and permissioned DLT. HF is particularly suited to our application, as it uses Public Key Infrastructure (PKI) for the enrolment and authentication of users without the need to define ad-hoc identity management contracts, all communications can be protected by TLS, and transactions are immediately final, i.e. if an authorization decision appears in an honest peer’s ledger, it will appear in every other honest peer’s ledger in the same position. This is critical because an access control enforcement in which decisions were not guaranteed to be final would always be subject to argument. We contrast some significant examples of previous uses of DLT and HF in Sect. 6.

1.1 Use Case and AuBACE: Discussion

The main goal of an Electronic Health Record (EHR) system is that of sharing health information among healthcare professionals to provide patients with effective and timely treatments. Of the many possible deployment models, we consider a centralized EHR system as our use case scenario. In this model, patients or staff at local Health Service Providers (HSP) – e.g. hospitals, laboratories, or Local health authorities – interact with one or more HSPs using a custom application to store and retrieve EHR, and for each interaction with the HSPs, a centralized Health Authority (HA) is obliged to authenticate the involved parties and authorize the interaction based on their credentials.

In the presence of insider attackers – which are the main problem in the healthcare sector – the integrity of the audit log itself may also be at risk. To overcome this problem, our approach is to have a single point of administration for access control policies managed uniquely by the HA and use a distributed ledger for the evaluation of policies that shall be performed by the HA and the local HSPs.

The main benefits of this approach are to increase the confidence of patients as well as officials in the assurances given by the system: in particular, that data will be handled according to the reference policy dictated by the HA, and that the access log is tamper-proof for auditing. Earning the trust of patients is particularly important, given the sensitive nature of the data stored in the EHR and the contrasting needs of controlling unauthorized access while enabling timely access of crucial information by healthcare professionals, especially in case of an emergency.

We assume that users can authenticate to the system by using credentials provided in different ways; these may include electronic identity cards for patients, which are becoming more and more widespread in many European countries, as well as credentials provided by local organizations for healthcare professionals when they are hired. The HA is responsible for specifying the access control policies that should be used for the evaluation of authorization requests by the nodes of the distributed ledger associated with the organizations.

In some legislations there may be a higher degree of centralization than others. For instance, in France there is a national authority in charge of providing access to a common EHR system, while Italy is in the process of migrating from regional authorities overseeing local providers to a national authority.

We also note that the use case described above is subject in Europe to the EU General Data Protection Regulation (GDPR). For instance, patients are considered Data Subjects and the centralized nature of the policy administration is a consequence of the need to clearly establish a Data Controller who is legally responsible for the treatment of subject data. Data subjects also have to expressly consent to the treatment.

For concreteness, two examples of the policies we implemented are: (P1) nursing staff can read or update a patient record for the purpose of provision of care; (P2) emergency medical technicians can read or update patient records for the purpose of emergency services, even without consent.

2 Background

We briefly recall the traditional architecture for implementing an access control mechanism and present the main components of the Hyperledger Fabric technology that will be used in our experiments.

2.1 Access Control

We adopt the Attribute-Based Access Control (ABAC) framework for its flexibility not only to simulate and combine a wide range of classical access control models – e.g. Role-based, Discretionary, or Mandatory Access Control – but also refine them so as to supplement rather than supplant the classical models; see, e.g. [18] for a discussion on these and related issues. We do not choose a particular language for expressing ABAC policies – any one of the available choices, e.g. eXtensible Access Control Markup Language (XACML, [23]) would do – but rather focus on policy evaluation and logging.

Fig. 1.
figure 1

ABAC framework with an audit log.

We recall the ABAC framework [9, 10, 14] in Fig. 1. The Policy Enforcement Point (PEP) intercepts every authorization request to access resources, such as Electronic Health Records, performed by users, e.g. patients or healthcare professionals, and then returns the requested resource based on the decision provided by the Policy Decision Point (PDP) after the evaluation of the rules specified in an access control policy. The expressive power of ABAC policies derives from the fact that rights are granted or denied depending on security-relevant features – called attributes – of users and resources, together with environment attributes, such as location, time, or the state of certain variables provided to PDP by the Policy Information Point (PIP).

Given this framework, an isolation boundary blocks all access to resources except over the channel that passes through the PEP. To determine the user’s attributes, the sender of an authorization request is identified based on credentials, e.g. digital certificates.

In addition to the ABAC framework we require an audit log (Step 6 of Fig. 1), i.e. a complete and integral record of the authorization decisions taken by the PEP. As highlighted by Lampson in [20], the audit log is a crucial, and sometimes overlooked, component of an access control system, and to ensure its integrity, an isolation boundary must protect the audit log from tampering even by those principals entitled to operate within the isolation boundary of the access control system, e.g. system admins; in other words, the only way to write to the access log must be through a channel connecting it to the PEP.

We would emphasize the importance of the two isolation boundaries in Fig. 1 for the security of the enforcement of access control policies. There are several possible ways to implement these depending on the particular technological scenarios in which policies must be enforced. Since the precise evaluation of risks related to the implementation of the outer isolation boundary in Fig. 1 depends on many implementation details, in the following we assume that an appropriate choice has been made for it and we focus on the part inside the outer box. In particular, our proposal (Sect. 3) involves avoiding the use of an isolation boundary around the audit log by using distributed ledger technology.

2.2 Hyperledger Fabric

Hyperledger Fabric (HF) is a private and permissioned distributed ledger providing an execution environment for smart contracts. We refer to reports by ENISA [7] and NIST [30] on blockchain and distributed ledgers in general, and to the official Fabric documentation [12] for details of HF as a whole. Here we focus on the features of HF that are most important to our case.

The HF components of main interest for our purpose are clients – applications to make function calls to smart contracts – and peers, who collectively enforce the access control policies to those functions and commit authorized changes to the shared database. Each organization participating in the consortium setting-up an HF network may run one or more peer nodes. The read and write requests issued by clients are known as transactions and are collected in a blockchain structure; valid transactions are used by peers to update the database.

Another essential component is a membership service provider (MSP). Every peer has an MSP, which is responsible for determining which principal has administrative or participatory rights within the scope of that MSP. Each MSP manages lists of X.509 certificates, including: a root CA and TLS root CA; certificates for itself, administrators, and a certificate revocation list; and a keystore with its own private key. Certificates issued by external CAs may be relied upon to authenticate users, or a built-in Fabric CA may be used.

In HF, smart contracts are referred to as chaincodes. These programs represent a shared operational logic among a group of organizations agreeing on common rules and establishing a private channel. The Fabric network is designed to enforce these common rules and policies, and maintains a shared database, ensuring its consistency among all participants.

Smart contracts are digitally signed by their owners at creation, and only their owners may update them. They also specify a policy of peer nodes that are required to participate in their execution, called endorsement policy. They need not be installed on every peer, but must be installed on peer nodes sufficient to satisfy the endorsement policy.

Lastly, HF is designed to guarantee a total ordering of the blocks [2]. In particular, it is designed to guarantee that correct submitted transactions eventually appear in every correct peer’s chain, and transactions always appear in the same order. These properties are particularly desirable for access control applications because one peer’s blockchain does not run the risk implicit in bitcoin-like solutions that a longer, equally valid chain will replace it, so decisions based on a transaction in a correct peer’s chain can always be audited with certainty.

3 AuBACE Proposal

We build Audit-Based Access Control Enforcement (AuBACE) on a private and permissioned DLT. We believe that it is the ideal choice to design and implement an access control enforcement mechanism capable of satisfying the following requirements: (R1) centralized policy definition and administration, (R2) distributed policy evaluation and enforcement, (R3) audit log integrity. Such requirements naturally stem from scenarios in which organizations are legally responsible for defining a reference set of security policies to protect the personal data of users, minimizing abuse by administrators, and identifying malicious behavior of privileged users. This is the case for instance under GDPR [8].

A private and permissioned DLT allows one to limit the capability of writing policies to a single peer of the network (satisfying R1) while smart contracts can be used, in combination with the consensus algorithm, to implement the distributed evaluation of access requests (satisfying R2). The strong integrity properties of the blockchain data structure underlying the DLT allows auditing of the access control history with a high level of assurance (satisfying R3).

A high-level representation of our proposal architecture can be seen in Fig. 2. Compared to the ABAC framework in Fig. 1, the main differences are the distributed evaluation of policies, and the use of a blockchain-based audit log not as information storage but as the basis for granting authorization to access resources. Only the information relevant to access control is recorded in the blockchain; resources are stored off-chain for efficiency and privacy.

We map the functional points defined by the ABAC standard to concrete entities in our specific solution in Sect. 3.1, summarize the proposed access request flow in Sect. 3.2, and discuss more in detail how policies and attributes are set and updated in Sect. 3.3.

Fig. 2.
figure 2

High-level architecture.

3.1 Functional Points

The HF network is created and administered by a central Health Authority (HA) with a data controller running a Policy Administration Point (PAP) managing the creation and update of the HF chaincode containing the policies themselves. The HA is also responsible for digital identity and access management (IAM).

The HA recognizes local Health Service Providers (HSPs) with their own HF peer nodes. The HSPs have been given permission to join the network and enroll new users with their MSP. Each principal has been assigned an X.509 certificate that is recognized by the network, with a corresponding private key. Users make requests to the network through their application (App), which acts as a client with respect to the HF peer node network. Keys are securely stored by each client and peer node in their local keystore. Each peer node, represented in Fig. 2 with the chain symbol, also has a local copy of the blockchain. Specifically, it is necessary for the Policy Enforcement Point (PEP) in each HSP to have a peer node in order to read the policy decision from the blockchain. Indeed, the PEP is the gateway to the medical records, stored off-chain to support user privacy: while the distributed ledger can decide whether to grant access and record that decision, the access itself must be granted by the service storing the record. In this proposal, we assume that the HSP has direct access to an HF peer node and grants access to resources based on HF transaction outcomes. More specifically, if a user making a request through an App has been granted access to a resource, then the decision will be written in the blockchain; the PEP can then authenticate the user based on the HF certificate in her App, check the network for the decision, and thus fulfil her request.

The Policy Decision Point (PDP) is distributed, in the sense that the decision is made by HF peers running their copy of the decision-making smart contract. The network consensus algorithm ensures that all peers run the same copy of chaincodes, prevents dishonest peers from influencing the final result that all peers commit, and ensures that the committed decisions are not subject to change in the future thanks to the design of HF.

The Policy Information Point (PIP) is distributed, in the sense that principal attributes are contained in their certificate, resource attributes are written in the HF database, and environment attributes are gathered from other sources.

Concretely, the decision request (Step 1 in Fig. 2) is made by the App using a HF SDK. The App has access to the user’s HF certificate and private key, limited by the client’s keystore. The final resource request (Step 7 in Fig. 2) is made to the PEP by the App on another channel and the access is granted based on the decision recorded in the audit-log (Step 8 in Fig. 2). In this way, the audit-log becomes the source of truth for authorization decisions (hence the name AuBACE) and differs from typical practice of putting the PEP in charge of translating access requests into a language the PDP will understand.

Finally, we note that environmental conditions are challenging to handle on a distributed ledger. In order to reach consensus on a transaction, participating nodes are usually required to execute completely deterministic code without external input, such as in Ethereum. While HF is capable of handling non-deterministic code, e.g. lists without a specific ordering (see [2]), it still requires a sufficient number of peers to return the same set of values. Alternatively, they must accept single points of trust, such as Corda oracles [4], which provide network participants with statements of external facts, such as timestamps. We discuss in Sect. 3.3 how specific attributes may be implemented in our proposal.

3.2 Processing Authorization Requests

As shown in Fig. 2, the following steps are taken by both patients (data subjects) and doctors (data processors) to request access to the EHRs handled by HSPs:

  1. 1.

    The user makes an access request through her App. Transparently to the user, the App first invokes a decision request chaincode on HF.

  2. 2.

    The PDP (chaincode installed on peer nodes) checks the PIP for attributes, e.g. resource attributes from the HF database, principal attributes from their certificate, or environment attributes from the local host.

  3. 3.

    The PDP evaluates the request against the policies.

  4. 4.

    The HF network reaches consensus.

  5. 5.

    The PDP’s decision is committed to the immutable log of all peers.

  6. 6.

    The decision is available to be referenced by the user’s App.

  7. 7.

    If the decision was to grant access, the App can establish an off-chain secure channel to request the EHR from the 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 (JWT) [16].

  8. 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. 9.

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

  10. 10.

    Finally, the PEP releases the requested EHR to App.

Step 1 is performed by the App to obtain an access decision through a HF channel; while Step 7 is performed for requesting access to a resource through an off-chain channel.

3.3 Attributes

User attributes are written in HF certificates. It is the responsibility of CA and MSP registrars – admins with the registrar attribute in their certificate – to ensure that attributes are correctly assigned to users when their certificates are issued, and to perform all associated duties such as maintain revocation lists and re-issue certificates as appropriate.

The PAP remains centralized in this proposal. Only users registered by the administrative organization (HA in Fig. 2) with an attribute of policy administrator are authorized to invoke the administration chaincode. Each policy is evaluated by a chaincode and assigned a unique identifier, so that it may be selected for update and deletion.

Resource attributes can be set by chaincode on resource creation, associated with a resource ID r. The EHR server (PEP) only knows r.

A resource attribute we consider is consent. Patients (data subjects) may invoke a consent chaincode to record their explicit consent to the treatment of their EHR for a given purpose, recorded on the ledger as a boolean value.

The purpose for data treatment is an environment attribute. Following [27], the notion of purpose is inherent to the whole sequence of actions needed to achieve a certain goal, and does not pertain to individual steps. Purpose should be declared at the outset; indeed, our access control requires the requesting principal to declare a purpose with each request. Only at the end of the whole sequence of actions is it possible to establish whether the purpose had been as declared in an a posteriori audit analysis step, which our proposal does not encompass.

The purpose attribute has a small set of possible values. Examples in our proof-of-concept are provision of care and emergency (see policy examples in Sect. 1.1). Access for the declared purpose is granted only if the policies are satisfied. In the special case of emergency access, the requesting principal must have the corresponding subject attribute in their certificate, and the consent resource attribute is ignored.

An environment attribute we may consider in future work is the time of access request - for instance, in case a policy were to specify a restriction on the time of the request to be within business hours. It would not be possible for all peers to agree on a synchronized time of arrival of a request, but we consider it feasible to ask each peer to return a boolean value in answer to whether their locally measured time falls within a sufficiently wide range.

4 Security Assessment Against Insider Attackers

We focus our security assessment on the properties that distinguish our proposal from other access control solutions, in particular how the distributed PDP and the strong guarantee on the integrity of audit logs prevent log erasure and mitigate legitimate privilege abuse.

Our analysis is based on the following trust and security assumptions: (A1) the HF distributed ledger is robust in the sense of [11], i.e. it guarantees the liveness and persistence of the committed transactions; and (A2) no means exist for admins of the PEP to disable the check against the log before granting an access request.

Following NIST [22], we define an insider as “an entity inside the security perimeter that is authorized to access system resources but uses them in a way not approved by those who granted the authorization”. Given the focus of our analysis, the threat model consists of two specific insiders:

  • Admin of PDP: maintainers of IT services, who will for instance have access to the HF peer nodes; these are the accounts with the highest level of security-critical access.

  • User with privileged accounts: medical staff at all levels; for instance, doctors and emergency staff may have a wider access to information if they declare that access is being requested for a specific purpose.

In the following, we argue how AuBACE mitigates threats from these insiders, based on assumptions A1 and A2.

Actively deleting a log entry from the network is made infeasible by the distributed ledger, even for admins of PDP. During the decision check performed by the PEP (Step 8 in Fig. 2), a network query is performed. Even if an admin of PDP locally modifies a log entry, given assumption A1, we are sure that the right log entry value is returned. This is an effective mitigation against collusion between admins of PDP and users with privileged accounts. The use of a Byzantine fault-tolerant consensus protocol for the DLT also mitigates against collusion between several admins of PDP.

In addition, compared to a classic ABAC system, in our proposal it is infeasible for admins of PDP to install a valid copy of the policies that differs from the one defined by the entitled peer (admin of PAP); policy tampering attempts are mitigated by digital signatures on the smart contract.

A user with privileged accounts in possession of a genuine certificate may abuse the trust that policies afford them. For instance, while emergency medical technicians are allowed to read any EHR without consent from the data subject (see policy P2 in Sect. 1.1), this policy is designed to support specific use cases in rare circumstances. Given assumption A2 and the strong integrity properties of the blockchain data structure underlying the DLT, our proposal allows auditing of the access control history with a high level of assurance. This, together with being forced to declare the specific purpose for which one is requesting that access, is an effective deterrent.

Finally, since AuBACE is based on classical ABAC and IAM solutions, we do need further trust and security assumptions to prevent common attacks, which we consider out-of-scope of this security assessment. For example, we assume admins of the PAP are trusted in writing the policies – i.e. no one is able to create a fake policy – and admins of the PEP are trusted in managing the resources – i.e. no one is able to access resources without the policy and decision validation. In addition, we assume the robustness of the PKI infrastructure underpinning the HF trust model itself. In particular, we assume registrars will not create fake identities. There are mitigation strategies to prevent malicious issuance of certificates – a robust standardized and automated procedure has recently been proposed in [17] – but they lie outside the scope of our current proposal. We do highlight this as an area of potential future work, particularly in regards to integration with existing identity providers, which we think is quite reasonable for the public healthcare sector use case.

5 Prototype and Experiments

Our sample implementation is concerned only with the distributed ledger part of the architecture, specifically a Fabric network with organizations, users, and policies defined to support the use case of EHR access control. We have not implemented any part beyond the DLT itself. What we have implemented is available in the github repositoryFootnote 1, and can be run as docker containers.

5.1 Policy and Data Structure

Principals i are identified by their HF X.509 certificate, which contains attributes associated with the principal – in particular their unique identifier, to which resources are associated.

The action requested can be one of the following: Add EHR, Get EHR, Update EHR, Update consent. The first three requests are for permission to interact with the PEP; in addition, Add EHR creates a new entry on the ledger, and Update Consent sets an associated variable on the ledger to true or false.

EHRs are created at patient enrolment. The data subject expresses their consent c to data treatment, and the policies specify for which purpose p consent may be granted. We take a deny-by-default approach and only specify the policies in which principals are explicitly granted access.

The HF database stores the following data for each EHR: (\(i_s\)) data subject, (r) a unique identifier linking the data subject to the data (EHR), (t) last request time, as declared by the client application in the transaction proposal, (\(i_q\)) requesting principal, and (c) data subject consent to the treatment of data.

Policies are evaluated by using HF smart contracts. Each access request Req is an HF transaction. We refer the reader to the online documentation [12] for the detailed HF transaction protocol, but each Req contains at least the following fields: (\(\texttt {Req}{}.i_q\)) the certificate of the requesting principal, (\(\texttt {Req}{}.action\)) the action requested, (\(\texttt {Req}{}.r\)) the resource identifier, and (\(\texttt {Req}{}.purpose\)) the declared purpose for access. The certificate \(i_q\) is an integral part of the HF transaction protocol; transactions could not be built without one. The remaining fields are parameters to be evaluated by the access control smart contract.

It is not difficult to devise a procedure capable of generating pseudo-code for any given finite set of attributes. We leave as future work the design and implementation of a translator that takes an ABAC policy expressed in some formal language (e.g. XACML) and automatically generates a set of equivalent smart contracts that can be deployed in HF for evaluation.

5.2 Fabric Set-Up

In our implementation, we used the HF SDK for node.js, with a client app to call the SDK and make transaction proposals to HF. Each peer node is run in its own docker container. The control interface is designed for test purposes to switch between identities and retrieve different views of the ledger, provided the local keystore contains the appropriate keys and certificates; this allows to test the correct execution of policies.

In our proposal, only the single policy administration node is the owner of the access control policy smart contract.

We deployed the architecture detailed in Sect. 3.1 by using 3 organizations, each with 2 peers and 1 admin user; 1 Certificate Authority and, as end-users: 100 patients, 10 doctors, 3 nurses and 1 user with the emergency attribute.

Users are registered by the admin with the CA and then enrolled at the MSP.

5.3 Experimental Evaluation

We deployed our prototype on a Linux testbedFootnote 2 and evaluated user requests for all actions listed in Sect. 5.1. We distinguish cases when the action is authorized (A), when it is denied (D) after policy evaluation; or when the policy is not evaluated (NE). To support NE operations, we specifically modified the smart contract.

We do not attempt to assess the entire HF architecture, which has been the focus of a thorough and recent study [26]. Rather, we report our measurements of the overhead introduced by the policy evaluation functions and the handling of concurrent requests. Platform-independent metrics to evaluate the performance of blockchain technologies have been proposed in [15]. We adapt the ones most suitable to our use case, namely Transaction Latency and Transaction Throughput, to investigate the performance of AuBACE in an HF-based prototype implementation. In particular, the speed in serving Get EHR requests is of interest to evaluate the use of AuBACE with a real-world EHR system: we believe requests for EHRs to be significantly more frequent than the remaining supported operations.

Transaction Latency is the amount of time taken for requests to produce visible results on the majority of nodes of the network. Figure 3 provides the distribution of latencies [ms] when performing 100 consecutive Add EHR and Get EHR requests.

Fig. 3.
figure 3

Transaction Latency [ms] of the Add EHR and Get EHR operations with authorized and Not Evaluated (NE) access requests, as boxplot. The distribution of times is shown as a boxplot: the box is bounded by lower and upper quartiles; the line indicates the median, and the cross indicates the average. Upper and lower whiskers are computed as the default – \(1.5\times \) upper and lower interquartile range; outliers have been omitted.

Fig. 4.
figure 4

Throughput of the authorized and NE Get EHR requests when simulating up to 10 concurrent users.

The results indicate that the policy evaluation mechanism itself has a small effect on the request latency, with the difference between authorized and not evaluated request times being approx. 50 ms. An additional, intrinsic delay is due to the creation time of each block in the chain, for which a channel-specific delay parameter is defined – which in our experiments was set to 100 ms.

To measure Throughput – the capacity to handle parallel requests – we configured our testbed to continuously perform requests for different resources over 15 s, and repeated this experiment by increasing the number of concurrent requesting users on different JMeter threads from 1 up to 10. Requests in this proof-of-concept set-up were addressed to the same Peer. Each thread waited for a reply before sending a new request. The results shown in Fig. 4 indicate that the policy evaluation mechanism slightly affects the Throughput: compared to not evaluated requests, the authorized ones had a Throughput of −5,6% requests/s with one user, and up to 20% with 9 concurrent users (162 authorized requests instead of the 135 not evaluated ones).

Finally, we can report the Access Latency of the HF prototype, measured as the time interval between an Add EHR request being sent from JMeter to the App and the HA Peer receiving an HF transaction request from the App; 15 ms on average over 100 requests. Additionally, the Propagation Latency, measured as the difference between the first and the last Peer on the channel committing a transaction to their local database: 45 ms averaged over 100 Add EHR requests.

Although the performance of our tests might be optimized by means of hardware or software, e.g. by load-balancing requests or upgrading the HF infrastructure and the smart contracts to support the latest 1.4 release, we believe the results to be satisfactory for our use case. Indeed, a medium-sized healthcare organization in Trento (Italy) serving a population of approximately 500,000 reported to us that their peak access request throughput is approx. 200 per minute.

6 Comparison with Related Work

The use of smart contracts for policy evaluation, and the exploitation of the strong integrity properties of blockchain for auditing, have been previously explored in the design and implementation of middleware for controlled information sharing or access control enforcement – see [13] for a recent review. The prevalent paradigm has been to fully decentralize access control to the highest degree to put individual users in complete control of policies, while keeping the data off-chain, going back at least to [32]. [6] proposes a similar approach, with a more specific reference to XACML [23] for attribute-based policy specification. See also e.g. [3, 24, 31].

Our work argues that private and permissioned DLT solutions are better suited than public and permisionless blockchains – used in, e.g. [6, 31, 32] – precisely characterizes the use case scenarios in which such an approach is useful, and conducts a security assessment showing that access right abuses by privileged users or administrators are effectively mitigated. As reported in [28, 29], such threats affect specific sectors disproportionately and clearly demonstrate the relevance of AuBACE. Another advantage of using a private and permissioned DLT is the possibility to more easily comply with existing regulations (such as the GDPR) recognizing that the responsibility for the safekeeping and processing of personal data lies with a single entity, referred to as data controller in the GDPR, while supporting the distributed deployment of the system. This was already observed in [24].

A specific advantage in using HF to build our prototype implementation, to our knowledge not previously exploited, is the immediate finality of transactions, as noted in Sect. 1. This is a benefit for an access control mechanism over using public and permissionless blockchains adopted in previous work (e.g. [6, 31]) in which availability and partition tolerance are usually preferred over consistency, as is the case e.g. for Bitcoin. Additionally, the reliance on a well-established PKI avoids the need to define ad-hoc identity management contracts as in e.g. [3].

One previous proposal of interest in particular [21] integrates mobile devices and a HF service. It is unclear whether their implementation uses the distributed ledger as more than a log since they provide no examples of their policy rules or an indication of where these are evaluated, and their only experimental evidence is a measure of the efficiency with which proofs of integrity of the medical data are generated. A major difference with respect to our work is that it also appears as though the only Fabric client they use to send transactions is present on a cloud server, while it is left unspecified how requesting principals are enrolled and authenticated.

7 Conclusion

We have presented AuBACE an access control architecture built in a private and permissioned DLT (HF) designed to increase accountability and decentralize the authorization decision process. This allows us to decrease the trust in administrators, mitigate insider attacks by privileged users, and make the a posteriori verification of access events more reliable while maintaining a reasonable overhead for access control enforcement. The main differences between AuBACE and a standard architecture (cf. Fig. 1) are the following:

  • policy administration is performed through a single point while access control decisions are performed by smart contract on the DLT;

  • an access request is made to be granted access as a matter of policy, and one is made to be granted access to the resource itself (a separate channel is required to communicate with the distributed PDP and the PEP);

  • the audit log is not a black-box information storage, but rather it is the fundamental evidence of security assertions on which the PEP bases its enforcement: no resource access is granted without prior evidence of the decision in the log;

  • security is based on the assumption that an attacker will not be able to compromise a sufficiently large number of nodes at once in the DLT.

The distributed evaluation of policies and the distributed storage of logs on a DLT increase an auditor’s confidence that the log could not have been manipulated, either at the initial write stage or by subsequent tampering.

We recall that auditing is composed of two phases [25]: (i) the collection and storage of audit data, and (ii) their analysis to detect security violations. Our work offers a solution for step (i) and can be combined with available techniques for (ii), such as [1, 5]. An interesting line of future work is to investigate how to combine one of these techniques with AuBACE while complying with data protection regulations such as the GDPR.

Another line of future work is to improve consent management, in particular concerning its update, and the presentation to users of the policies they are asked to consent to.