Constant-Time Risk-Aware Authorization for Blockchain-Secured Electronic Health Record Systems

RABAC brings together four research streams: blockchain integrity verification, on-chain healthcare access control, risk-aware authorization and hybrid off-chain storage. Blockchain-integrity-related research has focused on compactness: four-branch trees and ranked sampling [8, 9] for cloud data integrity, keyword search on similar data sets [10], constant-sized proofs [11], on-chain EHR verification using an oracle [12] and group signatures stored via IPFS [13]. All the methods result in a binary answer which isn't further used for authorization.

Access control has been achieved for the healthcare chain by subject, controller and requester policies in Ethereum smart contracts [6], optimized Fabric chaincode [14], attribute policies with zero-knowledge proofs [15], hybrid hashing [16], privacy-preserving data sharing [17, 18], full on-chain authorization [19] and discretionary-mandatory rule orchestration [20] and surveys indicate the tendency toward a multi-layered RBAC-ABAC hybrid [21, 22]. They all have one thing in common: both the request tonight and in the morning are allowed by the same policy - there is no modulation done in the authorization decision based on the risk.

Although a newer concept, risk-aware authorization has also been utilized in other contexts prior to the blockchain, such as role and attribute policies and multi-layer risk scores [23], environment-aware deep learning access control [24], fuzzy AHP approach for cloud security posture analysis [25] and multilevel risk-aware authentication for mobile devices [26]. From on-chain perspective, Pu et al. have been able to put risk-conditioned authorization in the contract code with physicians' behavior scored in a time decay method [27]; Mohajan and Jahan have incorporated the zero-trust blockchain structure into the security awareness score [28]; Pandit and Chatterjee have obtained authorization signals from patients' physiological conditions by using IoMT devices [29]. None of the approaches are based on 4D context taxonomies to detect misuse on a small scale, and only a few approaches use the chain as an auxiliary tool, while the rest calculate the risk in a single centralized trust box or apply the risk to enhance the accessibility detection.

The fourth stream is related to the location of the bytes: hybrid approaches store the ciphertext in other places and anchor only digest data [7], while the fourth stream concerns the location of the bytes; raw records should not be stored on the ledger. The design space contains two IPFS-based designs for healthcare IoT [30], off-chain IPFS storage to overcome the throughput limit of Fabric [31], measurements of healthcare Fabric networks [32, 33], HealthBlock [34] and consortium exchange architectures [35]. In all of them, the risk context of a request that has stored the data or retrieved it is not known to the storage layer.

Table 1 summarizes a comparison of ten recent systems on four capabilities of an effective design: semantic integrity verification (SIV), multi-stakeholder policy-based access control (MS-PBAC), four-dimensional contextual risk assessment (4D-CRA), and hybrid off-chain storage (HOCS). The surveyed systems do not support all four, but RABAC integrates them into one pipeline, integrity metadata verification based on the risk level of the requester, and risk-based control over static policy predicates. Criteria: Native if this is the ability that the system uses on its decision path for each request; Partial if this is the ability that can be successfully performed using optional or external components; None if this is not mentioned in the source paper.

Table 1. Capability positioning of recent blockchain–cloud healthcare security frameworks against risk-aware blockchain access control (RABAC)

Note: Present, but not native (partial); absent (none). No full 4D taxonomy is used in hybrid RBAC–ABAC scoring. Physiological risk dimension applies only in the ICU setting. The SIV (semantic integrity verification), MS-PBAC (multi-stakeholder policy-based access control), 4D-CRA (four-dimensional contextual risk assessment), HOCS (hybrid off-chain storage), RBAC (role-based access control), and ABAC (attribute-based access control) are all terms used for access control. Access control is referred to as SIV (semantic integrity verification), MS-PBAC (multi-stakeholder policy-based access control), 4D-CRA (four-dimensional contextual risk assessment), HOCS (hybrid off-chain storage), RBAC (role-based access control), and ABAC (attribute-based access control). Testbed evaluations are reported in studies [6, 12, 14], prototypes on clinical datasets are reported in studies [21, 22], simulations are reported in studies [23, 27], and the setting of study [29] is not reported; RABAC is evaluated on a permissioned blockchain testbed using a public dataset (Section 4).

4.1 Dataset and testbed configuration

The deployment is the same as described in Section 3.5: 5 VMs, Hyperledger Fabric 2.5, IPFS Kubo 0.20 and Go chaincode.

We use the chronic kidney disease (CKD) dataset from the UCI Machine Learning Repository [38] (250 records, 150 NotCKD), which was collected at Enam Medical College, Savar, Dhaka, Bangladesh, for experiments. After filtering out 140 records with more than a fifth or 20% of missing attributes, 260 records were used from the dataset to ensure that in each record, more than a fifth or 20% of the attributes were missing. Categorical attributes were filled with the mode and numeric attributes were filled with median, without any data leakage, on the calibration split set. Categorical attributes were encoded and numeric attributes were min-max normalized to [0, 1]. The statistics were computed on the calibration split and normalization and imputation were carried out based on these statistics. Each raw record was encapsulated in a clinical document with synthetic attachments (sizes' generation procedure, uniformly distributed in range of 50 KB to 5 MB, without any patient data in them); stored objects range in size from 50 KB to 5 MB, otherwise, they would not have been able to execute the pipeline of the stored records. The distributed feature table is a set of clinical and laboratory characteristics that does not include any direct identifiers such as name, address, telephone number or national identifier. The data is licensed with CC BY 4.0 [38]. As the present study performed secondary analysis of publicly available datasets and did not involve any new participant recruitment and data collection, no human-subject data were collected here. The replication package (see Data Availability) contains the record-selection procedure and the list of record IDs so that filtering can be ensured to be replicable.

The access-event workload consisted of subsets of calibration, validation, and test workloads that totaled 60%, 20%, and 20%, respectively. Such splitting is done group-aware both at the synthetic requester and at the record levels, i.e., all access events related to the same requester or record ID were assigned to one single subset so as to avoid requester or record leakage between calibration, validation and test (Table 3). Stratification according to the class label (CKD/NotCKD) was kept in these constraints and uniformity of stratification was checked with Kolmogorov–Smirnov tests at the 0.05 significance level. All parameters (weights and thresholds) were chosen on the validation split, and the test split was used only once for each set of parameters to prevent overfitting of test split on the headline metrics. There were 30 rules (12 subject, 8 controller and 10 requester rules) in the policy base.

The following checks were done before each run: Zero-overlap constraints. The distribution of the patients in the CKD/NotCKD class was maintained as close as possible to the group constraints through stratification. All the risk-model parameters were selected based on calibration and validation data only and the test partition was used only at the final configuration reporting stage for synthetic generation of workload and threat scenarios.

4.2 Workload and threat-scenario synthesis

As tabular data contained information about specific patients and not about accesses, it was also necessary to develop a workload model around which the other measures were calculated. Four types of requesters (physician, nurse, administrator and researcher) were instantiated, with each having a corresponding activity template (schedule of working days and hours, average request rate, mix of sensitivities, session volume). Requests were generated through the Markov-modulated Poisson process so that each behaviourally-historical requester is included for the risk engine to learn from. The partition composition and leakage control are summarized in Table 3.

Four types of malicious activities that were introduced in the workload: (i) tamper attempt – change the ciphertext that is being committed; (ii) unauthorized accesses – policy violating accesses (inter-departmental access and bulk export) that go directly through the policy enforcement path, credential-compromised accesses: stolen credentials satisfy the policy predicates, the responsibility for detection is assumed by the risk engine; (iii) policy compliant but risky accesses (e.g. out of schedule access by authorized requester) – should be flagged by the risk engine; (iv) behavioral drift – modeled as a 1.5σ perturbation for each session. A special simulation analysis dedicated to CLIPPED-EWMA protection against SLBP is carried out, which is mentioned later in this section.

Risk engine weights and decision thresholds were not considered when generating attacks. Threat prior data was taken from the sectoral incident reports [39, 40]. Malicious activities had a fixed value of 12% and were used in all experiments as an experimental hypothesis. The ground truth label (not the risk engine) generated a label for every request, and this was the only available ground truth to use to calculate accuracy, false positives and false negatives. For each experiment, we ran 20,000 access requests, with 500 concurrent requesters, for five random seed workloads.

Metrics definition. If the request is malicious, as the generator ground truth identifies it, it is a positive (also known as a tamper attempt); if it is an access policy violation, a credential compromise, a context violation (that is, it is authorized by the access policy, but the context does not support it), or a behavioral drift, it is a positive; if it is an authorized access policy and the context is supported, then it is a negative (legitimate request). The following is a definition of the terms true positive (TP), false positive (FP), false negative (FN), and true negative (TN): TP is a malicious request that has been denied/challenged. FN is a malicious request that has been granted. FP is a legitimate request that has been denied/challenged. TN is a legitimate request that has been granted. In the case of the three-outcome risk engine decision rule (Section 3.2), we refer to the accuracy as risk-screening accuracy, since the challenge issued against a malicious request is considered as detection at the screening phase, while the challenge issued against a legitimate request is regarded as false alarm, and the challenges and outright denial verdicts are summarized and reported as TPs/FPs in the metrics report, as future reporting will be carried out separately. The false-positive rate is FPR = FP/(FP + TN) and the false-negative rate is FNR = FN/(FN + TP). Successful tampering refers to an instance where a modified ciphertext has been accepted without any integrity warning; on the other hand, unauthorized access implies that a malicious access request was granted because, in cases where the policy enforcement is carried out successfully (G2), requests that violate the policy are denied. Therefore, for RABAC, the unauthorized access instances are the ones where the policy predicate was fulfilled, and the risk was not screened, while in the baselines there is also acceptance of the requests that violate the policy. The two measures are measured on a per 1,000 requests basis: accuracy = 0.88 × (1 − FPR) + 0.12 × (1 − FNR); All the accuracy data reported in Tables 4 and 5 satisfy this equation. Protective simulation of SLBP. While the reference algorithm was applied, two poisoning attacks were applied to the safeguarded EWMA algorithm given in Eq. (7) (supplementary materials). In a direct poisoning case, the vector v = (20, 50, 15) was provided for the behavioral profile μ = (4, 9, 2)—the projections of the 8D behavioral space of Eq. (2) on three features, which is illustrated—having the raw deviation of (16, 41, 13), the Mahalanobis distance ≈ 45.9; the request was given the score of R = 0.85 > 0.7, thus the profile remained unchanged (drift 0). If this were not for the safeguard mechanism, then the profile shift resulting from an accepted EWMA update would be (0.80, 2.05, 0.65). If the request is not above the escalation threshold, in a stealthy poisoning case, the clipping bound δ_cap = 0.1 limits the per-feature drift to at most γ·δ_cap = 0.005 per accepted update; shifting any profile feature by 0.5 therefore requires at least 100 consecutive accepted poisoned updates (200 updates for a shift of 1.0). They must each be below the escalation level, one by one. This way, one session's poison attack is now a long-term one, and the attack is serious, detectable by an immutable attack decision log as described in Section 3.4, G3. Future work includes a longitudinal study of adaptive SLBP attacks on our audit data (Section 5).

The results will be statistically treated and compared with the baseline.

4.3 Statistical treatment and baseline comparison

Five-fold cross-validation was used only for the calibration and validation sets. System-level statistics (Table 4) were derived from five test partition runs for each of which a different workload seed was used, and in which 20,000 requests were applied per partition (5 × 20,000 for each configuration). The means, standard deviations and 95% confidence interval estimates (t-distribution, four degrees of freedom) for RABAC and two hardware-similar baselines: cloud-based with no blockchain, using a static PBAC model, and centralized database (DB) system with application-level access control, are reported in Table 4. The difference between the cloud-only baseline and the complete RABAC stack is an ablation study of static PBAC and the full RABAC stack, because the same static PBAC policies are used without the contextual risk layer. Both baseline comparisons to paired t-tests were statistically significant (p < 0.001; Figure 3). As for the baseline without cloud, the number of tampering events dropped from 18.0 to 4.0 per 1,000 requests and from 22.0 to 3.0 per 1,000 accesses (without rounding), which is a 77.7% and 86.3% reduction, respectively (see unrounded numbers in Table 4); the rest of the tampering and accesses were due to off-channel substitution and credential compromise (Section 4.2). There was an experimental arm for Fabric-level deployment for the RBAC/ABAC that was not added for two reasons. First is the attribution: this arm would be similar to RABAC in that it contains the risk layer and the decision log that are being anchored at the same time, but it would be different because the cloud-only and centralized-DB baselines would each isolate one of those. Second, metric definability: the metrics are defined based on a per-request risk score and an anchored decision log, which is not generated by the classical RBAC and ABAC framework. Instead, it's the new design of those frameworks that's needed to assess them. Section 4.6, however, reports a simulation-level benchmarking of the decision logic of RBAC, ABAC, PBAC, and RABAC in a common runtime environment (Section 4.6.2) for policy evaluation and the presence of contextual violations, but not for the equivalence of the testbed. The comparison is asymptotic for the latency measure. Theorem 1 proves that the complexity of RABAC evaluation in terms of the number of application-level operations is the same as that of deterministic rule matching.

Table 4. Security performance over five independent runs

Note: Mean ± SD for five independent trials of 20,000 requests each; 95% CI in brackets; p values obtained by applying paired t-test between RABAC and each individual baseline system. CO: cloud-only baseline; DB: centralized database baseline.

3.png

Figure 3. Security performance of risk-aware blockchain access control (RABAC) against the two same-testbed baselines; error bars denote 95% confidence intervals over five runs

4.4 Parameter sensitivity

Weights and threshold values were chosen based solely on the validation partition. The validation risk-screening accuracy for the five weight configurations is illustrated in Figure 4. The sensitivity analysis is described in Table 5 for five weight combinations and two pairs of thresholds, with the nominal being (0.3, 0.7), and the results in the table are from the validation partition and not from the testing partition (no confusion). The parameters chosen were fixed before the test partition was seen, and the test accuracy of the model (99.38%, see Table 4) was only calculated after the parameters were chosen. The worst-case drop in accuracy because of re-weighting is 0.31%, suggesting that the classifier is not on a lucky local maximum. The (0.3, 0.7) version is the best trade-off between false positives and false negatives.

4.png

Figure 4. Validation risk-screening accuracy for the five risk-weight configurations in Table 5. The uniform-weight configuration achieved the highest validation accuracy (99.35%), while the maximum decrease across alternative profiles was 0.31 percentage points

4.5 Throughput, latency and scaling

A synthetic load of 10,000 access transactions was created from a set of 260 records, and the transaction throughput was measured. With a steady-state load of 150–300 TPS sustained by 500 concurrent client sessions, the average processing time on the server side is 33 ms (p50 = 29 ms, p95 = 48 ms, p99 = 63 ms), of which 2.3 ms is spent on the risk evaluation portion, and the remainder is spent on endorsement and peer-side transaction processing. Does not include client-side queuing and orderer block creation delay; this is a measure of endorsement, risk evaluation and peer-side transaction processing time. Thus, it is not to be considered as end-to-end transaction confirmation latency. Orderer queuing and block creation delay is also captured in the client-side end-to-end latency. The creation of a block will start once either condition is met: a batch creation timeout of 2 seconds, or a maximum batch size of 500 messages (Section 3.5). The observed observations were 312–500 transactions. With the provided 150–300 TPS range, this delay for block creation would be estimated to be approximately 1.67–2.00 seconds before any network transfer, peer validation and client event delivery delay. Therefore, it is expected that the end-to-end client latency will be greater than the reported server-side processing time. The distribution of the measured sustained throughput and the measured server processing time distribution is summarized in Figure 5. The measured operating point of the deployed RABAC prototype is summarized in Table 6.

5.png

Figure 5. Measured sustained throughput and server-side processing-time distribution of the risk-aware blockchain access control (RABAC) prototype under the 10,000-transaction workload at 150–300 TPS offered load

The scope of each reported performance metric, including the processing stages measured and those excluded, is summarized in Table 7. The measured amount of state per active user is ≈3 KB, and for reproducing an instance on 500 users, the total state of the risk engine is ≈150 MB for 50,000 users (≈300 MB for 100,000 users). This is a theoretical estimation of state size extrapolated per user, not considering the overhead of replication or runtime and not measured as node consumption. The scaling of the risk engine is tied to the peers' scaling, and not to the ledger's scaling separately: a linear increase of world state size with the number of active users, and a linear increase of evaluation capacity with the number of peers. The operating point measured is shown in Table 6. There are no cluster-wide projections: analytical projections were not possible based on measurements made with the five-node testbed. For large deployments, latency growth should be queueing-related, as evaluation does a fixed number of application-level operations per request (Theorem 1). The storage requirements and maximum power usage for the prototype are shown in Table 8. EHR – electronic health record; AES-256-GCM – Advanced Encryption Standard with 256-bit key and GCM mode; CID – Content Identifier. Data is provided by the Section 4.5 testbed experiments. The CPU and memory data are collected through the Docker container statistics API (cgroup accounting) at 5-s intervals during the steady-state period of each 20,000-request test with the 150–300 TPS load and 500 concurrent clients; CPU usage is reported as the percentage of total VM CPU resources (4 vCPUs), while the memory numbers refer to peak resident size. The ≈150 MB estimate for 50,000 users is an estimated theoretical extrapolation of the state size based on the individual user data, not an observed node consumption; the 500 concurrent user testbed needs ≈1.5 MB.

4.6 Component ablation, policy-model benchmark and SOTA comparison

4.6.1 Component ablation: semantic integrity verification

In order to measure the impact of SIV in an experimental way, the component ablation was repeated between two variants: RABAC-Full, which evaluates the integrity events within the context of the trigger request and only issues an alarm if the accumulated risk exceeds the threshold (R ≥ 0.30); RABAC-No-SIV, which issues a raw alarm for every integrity event, without context evaluation. If the context of the integrity event is evaluated to have a risk greater than the deny threshold, then the write is rolled back (the new CID is unanchored, and the old CID is the valid pointer). The differences between the FPR of RABAC-Full and RABAC-No-SIV manifest only in the presence of SIV, because both make identical policy evaluations and risk assessment for all other types of requests. There were semantic anomalies in the workload: structurally and policy-compliant requests that, however, contain semantic anomalies (e.g., an off-hour change by a clinician from a different department of a restricted record of a pediatrics psychiatric service). Five runs were made with 5 different seeds. Absolute FPR values of the SIV are not directly comparable to the FPR in Table 4 because the workload has a number of modifications to test the SIV component.

All authorized changes to the ciphertext cause a false alarm, resulting in the FPR rising from 3.66% ± 0.14% to 15.06% ± 0.26% when SIV is not present, as shown in Table 9 below. The difference between the two FPRs is statistically significant (p < 0.05) using a paired t-test analysis. However, even when using a No-SIV variant, it is able to detect 98.60% ± 0.42% of all tampering attempts, which means that the FPR reduction is not a trade-off for not detecting tampering attempts.

Table 8. Storage allocation and peak-load resource consumption of the deployed prototype

4.6.2 Policy-model benchmark

In addition to the same-testbed baselines in Table 4, simplified decision models for RBAC, ABAC, and PBAC have been created and tested against the RABAC decision model using a common environment (Python 3.12, one thread, same host), each evaluating a stream of 20,000 requests that comply with policies over five tests. This is a simulation-based benchmarking of the decision logic where we isolate the cost of evaluating policies and detecting violations; the latencies are not from any testbed of Hyperledger Fabric. The simulation-level performance comparison of the RBAC, ABAC, PBAC, and RABAC decision models is presented in Table 10. Table 11 compares the proposed RABAC framework with representative recent frameworks in terms of platform, storage architecture, risk scoring, permission granularity, and privacy-related considerations.

To give perspective on the cost of constant operation, the cost of constant operation is compared to the decision logic performance in Table 10. The cost of risk assessment in RABAC is 8.23 µs/decision, which is approximately 4.9 times the cost of scanning rules in PBAC and 41 times the cost of the pure RBAC check. However, it is about 4,000 times (≈3.6 orders of magnitude) less expensive than processing a request on the server-side, using the ledger path (Table 6). The computational cost of risk assessment by RABAC is not likely to dominate in this prototype in comparison to the cost of server-side processing. The difference in functionality is that the 2,000 replayed policy-compliant contextual attacks are identified by RABAC with 97.0% accuracy and are not identified by passing through RBAC or ABAC and passing through PBAC.

4.6.3 Comparison with recent frameworks

Under the above assumed prototype conditions, including GDPR/HIPAA compliance discussion (Section 4.8), RABAC offers a hybrid on-chain/IPFS storage scheme and provides a four-dimensional contextual risk mechanism at the application level out of the systems surveyed. In none of the papers compared are quantitative complexity and compliance postures reported, so as a result, estimation is not given, but instead “Not reported.”

4.7 Discussion and limitations

The experiment demonstrates that static policy rules provide an acceptable baseline, while a contextual risk score reduces how easy it is to make authorization decisions and immutable logging makes it difficult to perform and difficult to hide. A measured 0.8% false negative rate contains attacks that are not much different from normal user behavior. Mostly, the 33 ms time spent in the server-side processing is required for peer-side endorsement and transaction processing. The metric does not account for orderer queueing and block forming delays, so it cannot be used as a client-observable end-to-end access latency metric and should be considered in conjunction with ordering parameters and service-level latency requirements.

There are six restrictions that need to be mentioned with the findings. The first is that the performance evaluation was conducted based on analysis of 260 records with a single institution in a single country; additional testing in other institutions has yet to be done before deployment claims. Secondly, the attack traffic comprises of documented threat priors rather than traffic collected from the production hospital and the ground truth labels were manually assigned to synthetic access events that were conducted on top of real medical records; therefore, the accuracy measured is the accuracy of both the documentation and the detector. Finally, the equal-weight configuration is only a "fact" from this data set. Fourthly, semantic discrimination is only validated for the crash faults (Section 3.4) on the production alert streams longitudinally. Fourthly, the bounded drift validation in Section 4.2 is the only way to validate the validity of the clipped-EWMA mechanism. Finally, although the generating process for the threats is independent of the weights or thresholds in the risk engine, the separation of these two processes does not preclude any dependence between the synthetic workload and the feature space of the detector; the results of the detection metrics reported should be viewed accordingly. Seventhly, the reported 33 ms metric is a server-side processing metric, rather than the client-observable end-to-end confirmation latency. Although the ordering delay is analytically bounded by the block-cut configuration under the tested load, there is no end-to-end latency distribution collected, and this should be the focus of future work.

4.8 Privacy and compliance considerations

Since the design works with electronic health records, its positioning concerning the GDPR and HIPAA is explained below. The data minimization design is architectural: only SHA-256 digests, integrity metadata, and authorization verdicts are anchored on-chain (Section 3.1), the payload remains encrypted off-chain using AES-256-GCM (Table 8); and the schema of the anchored record contains only pseudonyms, risk score, the decision, a timestamp, and the IPFS CID. Residual metadata linkability risks remain and need to be mitigated during deployment. Immutability and append-only make the decision log accountable by delivering the necessary auditing trail for accessing health data, as required by GDPR and HIPAA [3]. The anonymous publicly available dataset (Section 4.1) was used for the evaluation; no additional human subject data was collected (see Ethical Approval). The deployment-related risks include other risks such as consent management, conflict between erasure rights and immutable ledgers, and risk of re-identification in risk profiles (Section 5).

Conceptualization, H.M.; methodology, H.M., E.F.A. and R.J.A.; software, H.M.; formal analysis, H.M.; writing—original draft preparation, H.M., E.F.A., and R.J.A.; supervision, E.F.A.; validation, E.F.A. and R.J.A.; resources, E.F.A.; writing—review and editing, E.F.A. and R.J.A. All authors have read and agreed to the published version of the manuscript.