Although managing resources at the edge, particularly in the context of highly dynamic IoMT environments, remains a significant limitation, such as scalability and optimization, edge computing can reduce the computational burden on centralized systems14. To ensure effective use of edge nodes and reduce latency in authentication procedures, we assess alternative paradigms in terms of research that is required on resource allocation strategies that adjust to real-time workloads15. IoMT devices, however, are made by different manufacturers and may employ different data formats and communication protocols. Achieving smooth device interoperability, edge node connectivity, and consortium blockchain network management are important research challenges. Another area that makes development as open standards and protocols for interoperability across different IoMT systems, which is edge computing platform integration with blockchain implementation that is count a crucial for widespread adoption16.

Blockchain edge-based authentication techniques and hybrid authentication techniques are two categories into which the derivation of related review analysis is divided:

Blockchain edge based authentication methods

In recent years, the field of blockchain edge-based authentication has attracted a lot of attention, primarily due to the need to manage device hierarchy and secure distributed networks, especially in the context of edge computing and the Internet of Things17. As an alternative to relying on centralized authorities, Decentralized Identity (DID) systems have been investigated as a way to enable entities to retain control over their own identities. Blockchain integration as a trust layer for DID management and related cryptographic credentials has been suggested by experts. For example, studies18 have shown how permissioned blockchains, such as Hyperledger Indy, can be used to register and validate DIDs. These blockchains are especially useful in IoT environments with limited resources. This technology is used for secure device-to-device communication on IoT edge nodes. In order to accommodate devices with constrained computational capabilities, some studies have investigated incorporating lightweight cryptographic algorithms into DID systems, guaranteeing that blockchain-based authentication is possible even for low-power devices19.

As independent, programmable entities for implementing authentication policies at the edge, chaincode has been the subject of much research. Using Ethereum and related platforms, experts have created protocols that allow edge devices to communicate with chaincode to authenticate themselves15. The automation of multi-factor authentication techniques, where chaincode verifies credentials like public keys, biometric tokens, and session-specific OTPs, is a noteworthy contribution in this field. Conversely, blockchain-based edge authentication systems have been investigated to address privacy concerns in the context of secure multi-authentications, which includes Zero-Knowledge Proofs for Authentication16,18. Without disclosing the underlying data, the technology enables an entity to demonstrate its identity and qualities. The capability is especially important in situations like healthcare IoT and financial systems where sensitive data needs to be protected. By reducing data exposure, experts have demonstrated that Zero-Knowledge Proofs for Authentication-based protocols can improve authentication in edge systems. For example, the blockchain-based technology for wearable health device authentication was proposed in the study14,18.

However, the further evaluation is categorized and discussed as follows (as highlighted in Table 1):

Table 1 Review analysis of current proposals regarding blockchain edge based authentication methods.Hybrid authentication methods

Multiple authentication techniques, such as biometrics, public key infrastructure, token-based hierarchies, and classic password-based systems, are used in hybrid authentication methods to provide a layered environment that is both flexible and safe25. These techniques seek to integrate the advantages of standalone mechanisms in order to lessen their drawbacks, which makes them especially appropriate for a variety of complex and varied contexts, such as enterprise infrastructures, edge networks, and Internet of Things systems26. One approach that connects over an Internet of Things network, which is characterized by devices with limited resources and extensive deployments, is hybrid authentication, which has garnered a lot of attention in this recent proposal27. Combining behavioural data for device and user authentication with lightweight cryptographic approaches has been investigated in a number of publications28. For instance, professionals have created hybrid systems in which biometric factors, like fingerprints, are used to maintain session continuation while Public Key Infrastructure (PKI) is used for initial authentication29.

Conversely, in edge computing environments, where security constraints result from decentralized systems and the requirement for low-latency operations, hybrid authentication techniques are especially pertinent25,28,29. Technology experts have emphasized the usage of device-based IDs in conjunction with federated authentication for edge systems. For example, a hardware token verification controlled locally by an edge server may be performed after an edge device has first authenticated using a conventional username-password combination. Maintaining a hybrid system that combines blockchain technology and attributed-based encryption for safe access control is a further option. This approach offers a secondary security layer by requiring users to authenticate using blockchain-verified credentials and ensuring that only individuals with the appropriate qualities can decrypt data at the edge.

Preliminaries

Unlike other cutting-edge comparisons, this section starts with a critical assessment of the data and related hierarchy that are used to demonstrate this novel hybrid design. Five well-known state-of-the-art datasets are used to train and assess the proposed work using alternative methodologies. The dataset (which is fully open source and freely accessible on the aforementioned websites) and its iteration cycle are explained as follows:

  1. 1.

    “IoT-Blockchain Data” was suggested by Kaggle (Link: https://www.kaggle.com/datasets/palwashakhanzadi/iot-blockchain-data).

    1. a.

      Over 100 cycles per file, the total iteration cycle depends on the 10 columns.

  2. 2.

    The “Support Datasets for Blockchain” proposal from Data.gov and Google can be found at https://cloud.google.com/blockchain-analytics/docs/supported-datasets.

    1. a.

      Ten tables or columns (2*1) determine the overall iteration cycle, which is more than 200 iterations or cycles.

  3. 3.

    The Library of Research Guide suggested a “Healthcare Blockchain Dataset.”

    1. a.

      The entire integration cycle depends on 100 columns/tables (2*1), which equates to more than 10,000 iterations/cycles.

Blockchain hyperledger with NuCypher threshold re-encryption mechanism

As a hybrid blockchain framework, the Hyperledger Indy-enabled consortium blockchain facilitates safe and effective data management for authorized users. Nonetheless, the following is a mathematical explanation of its main design and implementation procedures, particularly as they relate to the suggested IoMT authentication framework:

The authorized stakeholders in the designed network, such as

$$S = \left\{ {S1, \, S2, \, \ldots , \, Sn} \right\}$$

(1)

‘S’ includes patients, consultants, healthcare providers, IoMT device manufacturing facilities, and regulatory agencies. A distinct proxy pair (as shown in Fig. 2), such as.

$$Proxy \, 1 \, = \, \left\{ {Pki} \right\} – > plaintext – to – proxy$$

Fig. 2figure 2

Blockchain hyperledger indy-enabled block-based IoMT transactions management.

and so,

$$Proxy \, 2 \, = \, \left\{ {Piki} \right\} – > re – proxy$$

This is used to identify each stakeholder “Si”. Additionally, a reliable certificate authority (CA) verifies the identity of every stakeholder.

Nonetheless, the framework employs a hybrid strategy for stakeholder registration and device authentication: for devices with limited resources, authentication is carried out via a shared proxy “Pki” between the devices and the edge node (as shown in Fig. 2):

$$Resource – Constrained \, \left( {RC} \right) \, = \, Pdata\left( {Pk, \, AM} \right)$$

(2)

where Pdata = proxy-enabled data and M = authentication message.

In order to manage critical data exchange, this NuCypher Threshold Proxy Encryption is used as:

$$Resource – Constrained\;\left( {RC} \right) = Pcdata\left( {Pik, \, I, \, AM} \right)$$

(3)

where Pcdata = proxy critical data.

Advanced Practical Byzantine Fault Tolerance (APBFT) is employed by Hyperledger Indy to reach an agreement among network participants. The following is the definition of the APBFT process: To all other stakeholders, a lead node “Li” suggests a block “b” that contains the transactions “T,” which are:

$$T \, = \, \left\{ {T1, \, T2, \, \ldots , \, Tn} \right\}$$

(4)

Each stakeholder “Li” confirms and validates “b” in this way, and if “b” is legitimate, they broadcast a prepared message. Whereas verification function is elaborated as follows (as shown in Fig. 2):

$$Verification\;Function\;\left( {V\left( f \right)} \right) = \left\{ {1\;if\;b\;is\;valid,\;\;\;0\;otherwise} \right\}$$

(5)

In addition, a block ‘b’ is committed if at least 2/3 stakeholders agree in its validity:

$$Committed\;\left( C \right) = Sum \, \left( {i = 1 – > n \, \left( {V\left( f \right) > = \left( {2/3} \right)} \right)} \right)$$

(6)

Blockchain hyperledger-enabled chaincode

Chaincode is deployed on the Hyperledger Indy network to automate authentication and data exchange. In this manner, each designed contract/code is balanced in a deterministic function:

$$chaincode\;\left( {cc} \right) = \left( {input\;data\;\left( I \right) – > \;output\;information\;\left( O \right)} \right)$$

(7)

Throughout the authentication process (as illustrated in Fig. 3),

$$\begin{aligned} & S\left( {Login} \right) – > \left( {Li, \, S} \right) = Access\;Granted \\ & \quad – > \left\{ {if\;Li\;and\;S\;meet\;policy\;requirements\;\left( 1 \right)|else\;otherwise\;\left( 0 \right)} \right\} \\ \end{aligned}$$

(8)

Fig. 3figure 3

Sequence of stakeholders registration and authentication validation.

Here, Li represents an IoMT device and S represents a healthcare provider this time.

Edge-cloud connectivity

In this context, we suppose edge ‘e’ which is equal to:

$$e = \left\{ {e1,e2, \ldots ,en} \right\}$$

(9)

Equation (9) represent the send of edge which are ready to integrates with the data processing and dispatch to cloud. Each edge performs lightweight computation for IoMT devices ‘d’, which is:

$$D = \left\{ {d1,d2, \ldots ,dn} \right\}$$

(10)

The computational latency ‘L’ for authentication at an edge node is given by:

$$L \, = Time – to – Process\;\left( {TP} \right)\; + \;Communication\;Delay\;\left( {CD} \right)$$

(11)

In addition, the immutability of transactions ‘ts’ in the Hyperledger Blockchain is guaranteed by the NuCypher Proxy ‘NP’, which generate proxy based on threshold re-encryption-enabled hierarchy as follows (as illustrated in Figure 3):

$$NP\left( b \right) = NP\left( {ts1\left| { \, ts2} \right| \, \ldots .| \, tsn} \right)*NP\left( {b – 1} \right)$$

(12)

At the end, the decentralized nature ensures that the failure of a single stakeholder “Si” done not compromise the network.