Distributed medical equipment management platform and method based on zero-trust network

Abstract

The embodiment of the invention provides a distributed medical equipment management platform and method based on a zero-trust network. In the distributed medical equipment management platform based on the zero-trust network, an edge trusted access module adopts a hardware root of trust mechanism, so that equipment accessed for the first time is connected to a temporary supply network isolated from a medical core network, and a zero-trust security normal form is followed; the distributed trust anchor point cluster constructs a distributed identity verification network based on federated learning, and the access pre-authorization authority is verified through a device distributed identity identification (DID); the dynamic permission arrangement engine injects an attribute-based access control strategy, generates a permission token in combination with network micro-segmentation, and realizes two-way encryption communication between the equipment and a target service; the intelligent isolation gateway cuts off temporary connection through a software defined network technology and sends a network access state proof through a block chain mechanism, and edge module initialization is executed by a trusted node outside the medical cloud.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of network technology, and in particular to a distributed medical device management platform and method based on a zero-trust network. Background Art

[0002] In the field of medical information technology, the widespread use of distributed medical devices (such as smart infusion equipment, ventilators, and IoT medicine cabinets) has led to significant challenges in the security and management efficiency of device access to medical institution networks. Currently, network access for distributed medical devices typically utilizes a traditional perimeter protection architecture, which establishes a network perimeter through devices such as firewalls and performs unified identity authentication and permission configuration for first-time devices. However, this architecture relies on the security assumption of "trusting all devices within the perimeter," making it difficult to address the dynamic security risks inherent in distributed medical device deployments, such as device identity forgery, unauthorized network penetration, and permission abuse.

[0003] Traditional solutions suffer from significant technical flaws during implementation: First, the authentication mechanism for initial device access lacks hardware-level root of trust support, making it difficult to defend against firmware tampering or unauthorized access by counterfeit devices. Second, the centralized permission management model cannot adapt to the micro-segmentation requirements of medical networks, resulting in extensive device permission allocation and the risk of unauthorized access. Third, network isolation measures rely on static routing configurations, making it impossible to dynamically switch device access status and provide security verification, making it difficult to meet the high security requirements of medical data. Furthermore, traditional solutions lack a unified trust anchor for devices deployed across distributed regions, resulting in inefficient authentication and the risk of single points of failure.

[0004] Therefore, how to build a distributed medical device management architecture with hardware-level trusted access, dynamic permission management and adaptive network isolation capabilities has become the key to solving the problems of device access security and management efficiency in existing technologies. Summary of the Invention

[0005] In view of this, an embodiment of the present invention provides a distributed medical device management platform and method based on a zero-trust network to at least partially solve the above problems.

[0006] According to a first aspect of an embodiment of the present invention, a distributed medical device trusted management platform based on a zero-trust architecture is provided, which includes: an edge trusted access module, a distributed trust anchor cluster, a dynamic permission orchestration engine, and an intelligent isolation gateway. Each component works together through a decentralized trust chain:

[0007] The edge trusted access module uses a hardware root of trust mechanism. When distributed medical devices are first connected to a medical institution, it automatically activates the preset zero-trust edge network access component, connecting the device to the temporary supply network. This network serves as a trusted execution environment independent of the medical core network. It uses hardware-level isolation technology to achieve physical channel separation and adheres to the zero-trust security paradigm of "continuous authentication and real-time verification."

[0008] A distributed trust anchor cluster is deployed on distributed cloud nodes across regions. A distributed authentication network is built using a federated learning architecture. This network is used to obtain the device's distributed identity (DID) and access request from the temporary supply network. Based on the device's identity chain, it verifies whether it has pre-authorized access to the microservice cluster within the medical network.

[0009] After authentication is passed, the dynamic permission orchestration engine dynamically injects attribute-based access control (ABAC) policies into the device through the trusted execution environment. Combined with network micro-segmentation technology, it generates fine-grained permission tokens, enabling the device to establish bidirectional authenticated communication with the target service unit in the medical network through an encrypted channel.

[0010] The intelligent isolation gateway is deployed with software-defined network (SDN) components. After the device completes the permission configuration, it automatically cuts off the temporary supply network connection and sends an unalterable proof of the device's network access status to the management node through the blockchain consensus mechanism. The initialization configuration of the edge access module is performed by a trusted production node deployed outside the medical cloud. This node is interconnected with the management node through a quantum encryption channel.

[0011] Optionally, in a specific embodiment, the distributed trust anchor cluster integrates a cross-domain certificate alliance component, and based on the unique key pair generated by the device hardware security module (HSM), distributes a dynamic permission certificate to the device through zero-knowledge proof technology before identity authentication. The certificate adopts a constructed attribute-based encryption (ABE) mechanism to limit the device to access only the management service interface containing the corresponding permission tag.

[0012] Optionally, in a specific embodiment, the temporary supply network adopts a self-organizing network (SON) architecture, and broadcasts a dynamic SSID bound to the trusted platform module (TPM) burned into the device before leaving the factory through a trusted boot program. When the device is powered on for the first time, it automatically matches and accesses through the hardware trust root, triggering a zero-trust authentication process based on remote attestation (RA).

[0013] Optionally, in a specific embodiment, the distributed management microservice cluster receives the binding relationship between the device DID and the authority certificate through a security interface built by a trusted computing base (TCB), and synchronizes the certificate status to an external supply node through a federal identity gateway when the device is connected, and adopts a continuous verification (PAV) mechanism to realize real-time identity verification for each communication.

[0014] Optionally, in a specific embodiment, the dynamic permission orchestration engine supports a micro-segmentation strategy based on the digital twin model of the medical institution, and binds the device DID, permission certificate and physical location tag in the digital twin through a secure interface, so that the device can only access the management service through the smart access point in the corresponding area, and the permission certificate contains a dynamic access validity period based on a timestamp.

[0015] Optionally, in a specific embodiment, the device distributed identity (DID) adopts a blockchain-federated learning hybrid structure, which includes the device hardware fingerprint, encryption public key and integrity measurement value of the trusted execution environment (TEE), and ensures the unforgeability and distributed verification capability of the identity through a cross-chain consensus mechanism.

[0016] Optionally, in a specific embodiment, the medical device includes a distributed terminal equipped with an edge intelligent unit, such as an intelligent infusion workstation, non-invasive ventilation equipment, blockchain medicine cabinet and other IoT devices, and its access request is transmitted to the trust anchor cluster through a heterogeneous network proxy component, following the three-dimensional authentication mechanism of "device identity + behavioral characteristics + environmental parameters".

[0017] Optionally, the process of configuring the device access management service follows the Trusted Startup Chain (TCC) mechanism: the authority certificate is received through the temporary provisioning network and stored in the device's secure enclave. After the TEE verifies the validity of the certificate, it sends a hardware-signed runtime environment certificate to the trust anchor cluster. This certificate is ensured to comply with the zero-trust security baseline through the remote verification component (RVP).

[0018] Optionally, in a specific embodiment, the intelligent isolation gateway integrates a software-defined boundary (SDP) component, which, after receiving the device trust certificate, dynamically generates a network access control list (ACL) through a policy decision point (PDP), cuts off temporary network connections and activates a micro-segmented communication channel based on a service mesh (Service Mesh), thereby achieving "continuous authentication and dynamic authorization" adaptive access control.

[0019] According to a first aspect of an embodiment of the present invention, there is provided a method for trusted management of distributed medical devices based on the management platform described in any one of the present applications, comprising:

[0020] When the device is powered on for the first time, it connects to the zero-trust edge network through the hardware root of trust, triggering a distributed identity-based authentication request;

[0021] In a cross-region trust anchor cluster, device identity and pre-authorization permissions are verified through a federated learning model;

[0022] Utilize attribute-based encryption technology to distribute dynamic permission certificates and combine it with micro-segmentation strategies to establish secure communication channels;

[0023] Network isolation switching is completed through the blockchain consensus mechanism, realizing adaptive management of device access rights.

[0024] The solution of the embodiment of the present invention has the following technical advantages:

[0025] ① This solution utilizes a hardware root of trust mechanism through an edge trusted access module. Upon initial device access, the zero-trust edge network component is activated, connecting the device to a physically isolated temporary provisioning network. This mechanism utilizes hardware-level isolation technology to achieve channel separation. Compared to traditional solutions that lack hardware-based authentication, this physically resists firmware tampering and device impersonation, resolving the technical shortcomings of "device identity forgery" and "illegal access."

[0026] ② The distributed trust anchor cluster builds a distributed authentication network through a federated learning architecture. This combines attribute-based access control (ABAC) policies injected by a dynamic permission orchestration engine with network micro-segmentation technology to achieve dynamic generation of fine-grained permission tokens. This breaks through the limitations of the crude permission allocation under the traditional centralized management model, allowing devices to access corresponding microservice clusters based only on pre-authorized attributes, directly addressing the risks of unauthorized access and the inability to adapt to micro-segmentation requirements.

[0027] ③ The intelligent isolation gateway uses software-defined networking (SDN) components to automatically disconnect temporary network connections and leverages blockchain consensus to generate tamper-proof proof of network access. This mechanism replaces traditional static routing configurations, enabling dynamic switching of device access status and secure proof, meeting the high security requirements of medical data and resolving the technical flaw of "unable to achieve dynamic isolation and security proof."

[0028] ④ A distributed trust anchor cluster is deployed across distributed cloud nodes across regions. This uses a federated learning architecture to build a decentralized trust chain, replacing the single trust anchor in traditional solutions. This not only eliminates the risk of single points of failure but also improves authentication efficiency across devices across regions through a distributed authentication network, resolving the issues of inefficient authentication and single points of failure.

[0029] ⑤ This application adheres to the zero-trust security paradigm of "continuous authentication and real-time verification." Compared to traditional perimeter protection architectures that rely on the assumption of "trusting devices within the perimeter," it fundamentally abandons the static trust model. Through the collaborative work of hardware-level isolation, distributed authentication, dynamic permission orchestration, and adaptive network isolation, a security management system covering the entire lifecycle of device access has been established, systematically addressing the dynamic security risks of distributed medical devices in identity authentication, permission control, network isolation, and other aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in the embodiments of the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0031] Figure 1 This is a schematic diagram of a distributed medical device management system based on a zero-trust network according to an embodiment of the present application.

[0032] Figure 2 This is a flow chart of a method for establishing an intracranial hematoma model provided in this embodiment. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be clearly and detailedly described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments in the embodiments of the present invention should fall within the scope of protection of the embodiments of the present invention.

[0034] It should be understood that the terms "first," "second," and "third," etc. in the claims, specification, and drawings of this disclosure are used to distinguish different objects rather than to describe a specific order. The terms "include" and "comprising" used in the specification and claims of this disclosure indicate the presence of the described features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or combinations thereof.

[0035] It should also be understood that the terminology used in this disclosure is for the purpose of describing specific embodiments only and is not intended to limit the disclosure. As used in this disclosure and the claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It should be further understood that the term "and / or" as used in this disclosure and the claims refers to any and all possible combinations of one or more of the associated listed items, including and including these combinations.

[0036] The core idea of this application is to provide a distributed medical device trusted management platform based on a zero-trust architecture. It is characterized by including: an edge trusted access module, a distributed trust anchor cluster, a dynamic permission orchestration engine, and an intelligent isolation gateway. Each component works together through a decentralized trust chain:

[0037] The edge trusted access module uses a hardware root of trust mechanism to connect first-time devices to a temporary supply network isolated from the core medical network, following the zero-trust security paradigm;

[0038] The distributed trust anchor cluster builds a distributed authentication network based on federated learning, and verifies access pre-authorization permissions through device distributed identity identification (DID);

[0039] The dynamic permission orchestration engine injects attribute-based access control policies and generates permission tokens in combination with network micro-segmentation to achieve two-way encrypted communication between devices and target services.

[0040] The intelligent isolation gateway cuts off temporary connections through software-defined networking technology and sends proof of network access through the blockchain mechanism, where the edge module initialization is performed by a trusted node outside the medical cloud.

[0041] For ease of understanding, the above core ideas are exemplified below through specific embodiments. However, it should be noted that the following description is not exclusive and limiting.

[0042] For ease of understanding, the English abbreviations used in the embodiments of this application are explained as follows:

[0043] DID: Distributed Identity

[0044] ABAC: Attribute-Based Access Control

[0045] SDN: Software Defined Network

[0046] HSM: Hardware Security Module

[0047] ABE: Attribute-Based Encryption

[0048] SON: Self-Organizing Network

[0049] TPM: Trusted Platform Module

[0050] RA: Remote Attestation

[0051] TCB: Trusted Computing Base

[0052] PAV: Persistent Authentication and Validation

[0053] TEE: Trusted Execution Environment

[0054] TCC: Trusted Computing Chain

[0055] RVP: Remote Verification Protocol

[0056] SDP: Software Defined Perimeter

[0057] PDP: Policy Decision Point

[0058] ACL: Access Control List

[0059] Figure 1 This is a schematic diagram of a distributed medical device management system based on a zero-trust network according to an embodiment of the present application. Figure 1 As shown,

[0060] It includes: edge trusted access module, distributed trust anchor cluster, dynamic permission orchestration engine and intelligent isolation gateway. Each component works together through a decentralized trust chain:

[0061] The edge trusted access module specifically uses a hardware root of trust mechanism. When a distributed medical device is first connected to a medical institution, it automatically activates the preset zero-trust edge network access component, connecting the device to the temporary supply network. This network serves as a trusted execution environment independent of the medical core network. It achieves physical channel separation through hardware-level isolation technology and adheres to the zero-trust security paradigm of "continuous authentication and real-time verification."

[0062] The distributed trust anchor cluster is deployed in distributed cloud nodes across regions. A distributed authentication network is built through a federated learning architecture. This network is used to obtain the distributed identity (DID) and access request of the device from the temporary supply network. Based on the device identity chain, it verifies whether the device has pre-authorized access to the microservice cluster within the medical network.

[0063] After authentication is passed, the dynamic permission orchestration engine dynamically injects attribute-based access control (ABAC) policies into the device through the trusted execution environment. Combined with network micro-segmentation technology, it generates fine-grained permission tokens, enabling the device to establish bidirectional authenticated communication with the target service unit in the medical network through an encrypted channel.

[0064] The intelligent isolation gateway is specifically deployed with software-defined network (SDN) components. After the device completes the permission configuration, it automatically cuts off the temporary supply network connection and sends an unalterable proof of the device's network access status to the management node through the blockchain consensus mechanism. The initialization configuration of the edge access module is performed by a trusted production node deployed outside the medical cloud. This node is interconnected with the management node through a quantum encryption channel.

[0065] From the above, it can be seen that this application constructs a security paradigm of "never trust, continuous verification". The edge trusted access module uses a hardware trust root mechanism to force the device to connect to a temporary supply network independent of the medical core network when it is first connected, thereby achieving physical channel separation. This design abandons the assumption of "trusting internal devices" in traditional boundary protection. All devices (including internal devices) must be authenticated through a temporary network when they are first connected, following the zero-trust "initial distrust" principle. At the same time, the temporary network follows the "continuous authentication, real-time verification" rule. During the access process, the device must continuously verify its identity through a distributed trust anchor cluster to ensure that each communication is subject to permission verification to avoid permission abuse caused by static trust.

[0066] In addition, based on dynamic permissions and least privilege allocation, the dynamic permissions orchestration engine generates fine-grained permission tokens after device identity verification is passed, using attribute-based access control policies (ABAC) and network micro-segmentation technology. The ABAC mechanism dynamically allocates permissions based on device attributes (such as type, location, and function), rather than based on fixed network locations, in line with the zero-trust "principle of least privilege." Micro-segmentation technology divides the medical network into multiple security domains, allowing devices to access only authorized target service units to prevent lateral penetration. This dynamic permission management model replaces the extensive permission allocation of traditional centralized architectures, achieving the zero-trust requirement of "one-time authorization."

[0067] Moreover, in this application, based on adaptive network isolation and trusted proof, the intelligent isolation gateway uses software-defined networking (SDN) technology to automatically cut off the temporary network connection after the device completes the permission configuration, and generates an unalterable network access status certificate through the blockchain consensus mechanism. This process realizes the dynamic switching from the temporary verification network to the target medical network, and each switch is accompanied by trusted proof, ensuring the real-time and verifiability of the network isolation status, avoiding the risk of isolation failure under traditional static routing configuration, and reflecting the core requirement of zero trust "continuous verification of isolation status".

[0068] In this application, distributed authentication and trust anchors are configured. The distributed trust anchor cluster is deployed on cross-regional cloud nodes, and a distributed authentication network is built through a federated learning architecture to replace the traditional single-point trust center. The device's distributed identity identification (DID) adopts a blockchain-federated learning hybrid architecture, which contains information such as hardware fingerprints and encrypted public keys, and achieves distributed verification through a cross-chain consensus mechanism. This design makes authentication independent of a single node, and can still ensure verification validity even if some nodes fail, which conforms to the fault-tolerant characteristics of the distributed architecture. At the same time, it supports the "unforgeable identity" requirement of zero trust through a distributed trust chain.

[0069] Moreover, this application can achieve cross-regional collaboration and decentralized management. The initialization configuration of the edge access module is performed by a trusted production node outside the medical cloud. This node is interconnected with the management node through a quantum encryption channel to form a decentralized management architecture. When distributed medical equipment (such as smart infusion equipment deployed across regions and blockchain medicine cabinets) is connected, identity authentication can be completed through the nearest trust anchor cluster, avoiding delays and single-point bottlenecks in cross-regional communications under the traditional centralized architecture. At the same time, the dynamic permission orchestration engine supports micro-segmentation strategies based on the digital twin model of medical institutions, binds the device DID to the physical location tag, and realizes regionalized permission management in a distributed environment, ensuring that devices in different regions can only access locally authorized services, reflecting the distributed architecture's support for zero-trust "least authority".

[0070] In this application, the intelligent isolation gateway sends proof of device access status through a blockchain consensus mechanism, leveraging the immutability of distributed ledgers to ensure network-wide consensus on the device's security status. This mechanism replaces the single point of status recording in traditional centralized management, eliminating the risk of data tampering. At the same time, the dynamic permission orchestration engine and the distributed trust anchor cluster collaborate through a decentralized trust chain, enabling real-time synchronization of permission policy distribution and verification across distributed nodes. This adapts to the dynamic permission adjustment requirements in distributed medical device deployment scenarios, achieving the goal of "real-time policy updates" for zero-trust implementation.

[0071] In summary, the core essence of this application is to support the "dynamic verification, least privilege, and continuous trust" of zero-trust networks through the "decentralization, fault tolerance, and scalability" of a distributed architecture. For example, a distributed trust anchor cluster frees authentication from single-point reliance, meeting the premise of zero trust's "independence from static trust." Dynamic permission orchestration and micro-segmentation technologies enable dynamic binding of "device identity, permissions, and location" in distributed networks, ensuring zero-trust least privilege control. The combination of blockchain and SDN enables trusted consensus and adaptive adjustment of network isolation status in a distributed environment, meeting the dual requirements of zero trust for real-time performance and security.

[0072] This collaboration enables the system to not only meet the cross-regional management needs of distributed medical equipment, but also solve security risks such as identity forgery and unauthorized access in traditional architecture through the zero-trust mechanism, forming a technology of "distributed architecture supporting zero-trust implementation, and zero-trust security paradigm ensuring the trustworthiness of distributed management."

[0073] Optionally, in a specific embodiment, the distributed trust anchor cluster integrates a cross-domain certificate alliance component, and based on the unique key pair generated by the device hardware security module (HSM), distributes a dynamic permission certificate to the device through zero-knowledge proof technology before identity authentication. The certificate adopts a constructed attribute-based encryption (ABE) mechanism to limit the device to access only the management service interface containing the corresponding permission tag.

[0074] To this end, the deep coupling of distributed architecture and zero-trust mechanism is used to build a processing logic of "hardware-level trusted access + distributed authentication + dynamic permission control + adaptive isolation", which has the following technical features:

[0075] 1. Hardware-level "initial distrust" access verification

[0076] The Edge Trusted Access Module utilizes a hardware root of trust mechanism to force first-time devices to connect to a temporary provisioning network physically isolated from the core medical network. This design breaks the traditional assumption of "trusting internal devices"—regardless of whether the device belongs to a medical institution or not, authentication must be performed through an independent temporary network, implementing the "never trust" principle of zero trust. The physical isolation of the hardware root of trust from the temporary network ensures that the device identity is bound to the hardware fingerprint (e.g., through a unique key pair generated by an HSM), preventing counterfeit devices from accessing and severing unauthorized access paths at the bottom level.

[0077] 2. Precise control of dynamic permissions and minimum permissions

[0078] The dynamic permission orchestration engine injects attribute-based access control policies (ABAC) and combines them with network micro-segmentation technology to generate permission tokens. The ABAC mechanism dynamically assigns permissions based on device attributes (such as type and department location). For example, infusion devices are only allowed to access the infusion management service interface, which meets the "least privilege" requirement of zero trust. Micro-segmentation technology divides the medical network into security domains. Devices can only decrypt and access service interfaces containing corresponding permission tags through dynamic permission certificates using attribute-based encryption (ABE). This "permissions change dynamically with attributes" mechanism replaces traditional static permission allocation and implements the core requirement of zero trust that "every access must be authorized."

[0079] 3. Adaptive Isolation and Trusted State Consensus

[0080] The intelligent isolation gateway automatically disconnects temporary network connections using software-defined networking (SDN) technology and sends proof of network access via blockchain. Once the device completes its permissions configuration, the SDN dynamically adjusts routing to switch from the verification network to the target network. The immutability of blockchain ensures that network access is verified through distributed consensus. For example, the validity of the device's permission certificate is verified by a cross-domain certificate consortium component using zero-knowledge proof technology, eliminating the risk of single-point forgery and meeting the zero-trust requirement for "continuous verification of isolation status."

[0081] 2. Distributed Architecture Supports Zero Trust

[0082] 1. Distributed authentication and decentralization of trust anchors

[0083] The distributed trust anchor cluster builds a distributed authentication network based on federated learning, verifying permissions through the device's distributed identity identifier (DID). Federated learning enables cross-regional nodes to collaboratively participate in authentication (for example, trust anchors in Beijing and Shanghai jointly verify a device's DID), avoiding single points of failure. DID is built using blockchain technology and includes hardware fingerprints and HSM key pair information, ensuring that identity cannot be tampered with through cross-chain consensus. For example, distributed ventilator equipment can access the nearest local trust anchor to complete verification without relying on a central node, which not only improves efficiency but also provides distributed support for zero-trust "identity trustworthiness."

[0084] 2. Cross-domain certificate alliance and dynamic permission collaboration

[0085] The cross-domain certificate alliance component integrated in the distributed trust anchor cluster distributes dynamic permission certificates through attribute-based encryption (ABE) technology. The ABE mechanism embeds permission tags (such as "ICU equipment" and "pharmacy access") into the certificate. The device can only access the service interface that matches the tag, and the validity of the certificate is jointly verified by multiple trust anchors through zero-knowledge proof (the legitimacy of the permission can be proved without exposing the true identity of the device). This distributed certificate management model enables the principle of least privilege of zero trust to be implemented in cross-regional medical networks. For example, when a device moves from Department A to Department B, its permission certificate is dynamically updated with the location tag and re-verified by the trust anchor of the corresponding area to ensure that the permission is bound to the physical location in real time.

[0086] 3. Blockchain consensus ensures the credibility of the isolation state

[0087] The intelligent isolation gateway transmits proof of network access status via a blockchain mechanism, leveraging a distributed ledger to ensure consensus among all trust anchors on the device's security status. For example, once a device has completed a temporary network disconnection and reconnected to the target network, its status proof is broadcast to all nodes via the blockchain, mitigating the risk of status records being tampered with in centralized management. Initial configuration of the edge module is performed by a trusted node outside the medical cloud, which connects to the management node via an encrypted channel, forming a decentralized configuration chain. This ensures the trustworthiness of the distributed device access process and supports the zero-trust requirement for "tamper-proof configuration."

[0088] In summary, the core of the above solution lies in the technical complementarity formed by the "decentralization and fault tolerance" of the distributed architecture and the "dynamic verification and attribute authorization" of the zero-trust mechanism: the distributed trust anchor point and DID mechanism enable zero-trust identity authentication to break away from the dependence on a single trust center and adapt to the distributed deployment of medical equipment across regions and multiple nodes; cross-domain certificate alliance and ABE encryption realize precise control of permissions based on device attributes in distributed networks, ensuring that the minimum permission management of zero trust does not become invalid as the network scale expands; the combination of blockchain and SDN realizes real-time synchronization and trusted proof of network isolation status through distributed consensus, meeting the zero-trust requirement of "continuous verification when the environment changes."

[0089] This collaboration enables the system to not only solve the management efficiency issues of large-scale medical equipment through a distributed architecture, but also to use the zero-trust mechanism to prevent risks such as identity forgery and unauthorized access under traditional boundary protection, ultimately forming a technical closed loop of "distributed architecture supports the expansion of management scale, and the zero-trust security paradigm ensures trusted device access."

[0090] Optionally, in a specific embodiment, the temporary supply network adopts a self-organizing network (SON) architecture, and broadcasts a dynamic SSID bound to the trusted platform module (TPM) burned into the device before leaving the factory through a trusted boot program. When the device is powered on for the first time, it automatically matches and accesses through the hardware trust root, triggering a zero-trust authentication process based on remote attestation (RA).

[0091] This solution builds a zero-trust closed loop of "dynamic discovery-trusted access-continuous verification" through deep collaboration between self-organizing network architecture and hardware-level trust root mechanism, while relying on distributed architecture to achieve unified security management of cross-regional devices.

[0092] The specific logic is as follows:

[0093] 1. Active discovery and isolation of “initial distrust”

[0094] The temporary supply network uses a self-organizing network (SON) architecture and broadcasts a dynamic SSID bound to the device's Trusted Platform Module (TPM) through a trusted boot program. This design implements the "initial distrust" principle of zero trust: when the device is first powered on, the dynamic SSID of the temporary network is automatically matched based on the hardware trust root (such as the TPM built-in key), triggering the access process without manual configuration. Because the SSID is bound to the TPM hardware fingerprint, counterfeit devices cannot obtain the correct network identification, preventing illegal access at the physical level. At the same time, the temporary network is physically isolated from the core medical network, forming an independent verification sandbox to ensure that unverified devices cannot access sensitive medical data.

[0095] 2. Hardware-level authentication and remote attestation

[0096] After the device accesses the temporary network, it proves its identity to the distributed trust anchor cluster through the remote attestation (RA) mechanism. The TPM generates integrity measurements that include hardware configuration and firmware version, and combines the encryption capabilities of the hardware trust root to ensure that the measurements cannot be tampered with. The distributed trust anchor verifies the proof based on the federated learning architecture and allows further access only when the device identity chain (such as DID) matches the pre-authorized permissions. This dual verification of "hardware fingerprint + dynamic attestation" realizes the "continuous authentication and real-time verification" of zero trust, preventing the device from accessing the network after the firmware has been tampered with.

[0097] 3. Dynamic permissions and minimized access control

[0098] After RA verification, the dynamic permission orchestration engine generates micro-segmented permission tokens based on device attributes (such as type and department). Because the temporary network utilizes the SON architecture, its topology can be dynamically adjusted based on device access. Combined with software-defined networking (SDN) technology, devices are isolated in specific security domains. For example, infusion devices can only access the "Medical Device Management - Infusion Service" microservice, and the communication link is protected by two-way encryption, complying with the zero-trust "principle of least privilege."

[0099] 2. Distributed Architecture Supports Zero Trust

[0100] 1. Decentralized Trust Anchors and Cross-Region Verification

[0101] A distributed trust anchor cluster is deployed across cloud nodes across regions, collaboratively verifying device identities through federated learning. When devices are connected in different locations (e.g., devices at a Beijing hospital communicating with a trust anchor at a Shanghai branch), each node trains and verifies a model based on local data. By encrypting and aggregating shared parameters rather than raw data, this approach protects privacy while achieving distributed consensus. For example, a Beijing node verifies the legitimacy of a device's DID, while a Shanghai node verifies its authorization certificate. Both nodes confirm the results through a blockchain consensus mechanism, avoiding trust crises caused by single points of failure.

[0102] 2. Distributed collaboration in self-organizing networks

[0103] The SON architecture enables temporary provisioning networks to autonomously configure and optimize without manual intervention. When a new device connects, the network automatically assigns a dynamic SSID bound to the TPM and guides the device through the RA process using a trusted bootstrap program. This self-organizing capability is particularly critical in distributed healthcare scenarios: devices deployed across regions (such as those in community clinics and tertiary hospitals) can access the local temporary network through the same mechanism, with their identities verified by the nearest trust anchor point, achieving distributed management with "local access and global trust."

[0104] 3. Combination of dynamic SSID and blockchain

[0105] The generation and update of dynamic SSIDs is controlled by blockchain smart contracts, ensuring that the lifecycle of each SSID is traceable and tamper-proof. Once a device completes authentication and switches to the core network, the temporary network's SSID automatically expires, preventing the reuse of old credentials. Furthermore, the intelligent isolation gateway records the device's network switching status through a blockchain mechanism. All trust anchors synchronize device status updates, forming a distributed security status ledger that supports the "continuous verification" requirement of zero trust.

[0106] In summary, the core of this application solution lies in realizing the zero-trust security paradigm in a distributed environment through the self-organizing capability of the SON architecture and the tamper-proof nature of the hardware trust root: SON dynamic SSID is bound to TPM to ensure the authenticity of the identity of the device when it is accessed, solving the problem of "who accesses" in distributed scenarios; RA mechanism and federated learning verification solve the problem of "whether it is trustworthy" through hardware-level proof and distributed consensus; SDN micro-segmentation and blockchain status recording realize dynamic permission control and distributed synchronization of security status, solving the problems of "what can be accessed" and "whether the access status changes".

[0107] This collaboration enables the system to manage large-scale, cross-regional medical equipment through a distributed architecture, and to prevent the risk of breaching traditional network boundaries with the help of a zero-trust mechanism, ultimately forming a technical closed loop of "self-organizing discovery to ensure access security and distributed architecture to support management efficiency."

[0108] Optionally, in a specific embodiment, the distributed management microservice cluster receives the binding relationship between the device DID and the authority certificate through a security interface built by a trusted computing base (TCB), and synchronizes the certificate status to an external supply node through a federal identity gateway when the device is connected, and adopts a continuous verification (PAV) mechanism to realize real-time identity verification for each communication.

[0109] As can be seen, this application builds a technical closed loop of "hardware-level trusted interface + distributed state synchronization + continuous dynamic verification" through the deep coupling of trusted computing base and distributed identity authentication, and implements the core paradigm of zero trust "never trust, continuous verification" in a distributed architecture. The specific logic is as follows:

[0110] 1. “Initial Distrust” Trusted Interface Isolation

[0111] The distributed management microservice cluster builds a secure interface through the Trusted Computing Base (TCB), which runs on a hardware-level Trusted Execution Environment (TEE) to ensure that the binding process between the device DID and the authority certificate cannot be tampered with. In the zero-trust architecture, this design breaks the traditional assumption of "trust interface interaction" - all interactions between devices and management services must be verified by the TCB. Even if the interface is maliciously attacked, the core logic within the TEE can still ensure the authenticity of the binding relationship. For example, when a device is first connected, the security interface only allows DIDs and authority certificates that have passed TCB verification to enter the binding process. Unverified requests are directly blocked, achieving "initial distrust" interface layer isolation.

[0112] 2. Continuous Authentication (PAV) and Least Privilege Control

[0113] The system adopts a continuous verification (PAV) mechanism to synchronize the certificate status through the federal identity gateway every time the device communicates. The attribute-based access control policy (ABAC) injected by the dynamic permission orchestration engine is combined with network micro-segmentation technology to enable the permission token to contain real-time updated certificate status labels (such as "valid" and "expired"). When the device accesses the management service interface, the security interface first verifies the certificate status through the TCB, and only allows access when the certificate is valid and the permission label matches. For example, if the permission certificate of an infusion device is marked as "expired", even if it has been connected to the network, the PAV mechanism will block communication in real time, realizing zero-trust "verification for each connection" dynamic permission control, avoiding the risk of permission abuse under traditional static authentication.

[0114] 3. Adaptive Trust State Synchronization

[0115] The proof of network access sent by the intelligent isolation gateway through the blockchain mechanism is synchronized with the certificate status of the federal identity gateway to form a closed loop: after the device completes the permission configuration and switches to the core network, its certificate status is synchronized in real time to the external supply node and each distributed trust anchor point through the federal identity gateway. If the status of the device certificate changes (such as the expiration or revocation of permissions), the security interface will immediately perceive it based on the real-time verification mechanism of TCB, and update the permission token through the dynamic permission orchestration engine, while triggering the SDN to cut off the abnormal connection. This adaptive mechanism of "status synchronization-permission update-network isolation" ensures that the "continuous trust assessment" of zero trust is implemented in a distributed environment.

[0116] 2. Distributed Architecture Supports Zero Trust

[0117] 1. Consensus mechanism for distributed identity and certificate status

[0118] The distributed trust anchor cluster, built on a distributed authentication network based on federated learning, collaborates with the federated identity gateway to achieve distributed synchronization of certificate status. For example, after verifying a device's DID in Beijing, the trust anchor synchronizes the certificate status to nodes in Shanghai and Guangzhou via the federated identity gateway. Each node then confirms state consistency based on a blockchain consensus mechanism, preventing single-point state record tampering. This distributed consensus ensures that zero-trust "identity trust" is independent of a single node. Even if some nodes fail, other nodes can still obtain the correct certificate status through the consensus mechanism, supporting unified verification of medical devices across regions.

[0119] 2. Distributed permission collaboration in microservice clusters

[0120] The distributed management microservice cluster receives the binding relationship between the device DID and the authorization certificate through a secure interface. Each microservice node independently verifies the legitimacy of the interface request based on the local TCB, and shares the certificate status through the federal identity gateway. For example, when a device accesses the "Infusion Management Service", the TCB of the service node verifies its authorization certificate and queries the federal identity gateway for the latest status of the certificate to ensure the validity of the authorization. This distributed collaboration enables the "principle of least privilege" of zero trust to be implemented in large-scale microservice architectures - each service node only processes requests that match its own authorization label, and the verification logic is dispersed in the TCB of each node to prevent the single point risk of centralized authorization management.

[0121] 3. Decentralized Continuous Verification Architecture

[0122] The continuous verification (PAV) mechanism relies on the collaboration of distributed trust anchors and federated identity gateways to achieve "decentralized verification logic": the identity verification of each device communication no longer relies on a central server, but is performed by the TCB of the nearest trust anchor or microservice node, and the verification results are synchronized between distributed nodes through the federated identity gateway. For example, when a device accesses the management service of a Wuhan hospital, the local trust anchor in Wuhan performs real-time verification, and the verification results are synchronized to the cloud blockchain to ensure the consistency of the status of nodes across the country. This architecture enables zero-trust "continuous verification" to adapt to the high concurrency and low latency requirements of distributed deployment of medical equipment, avoiding the performance bottleneck of centralized verification.

[0123] In summary, the core of this embodiment lies in building a zero-trust foundation of "trusted execution environment + dynamic state synchronization" in a distributed medical network through the combination of TCB's hardware trustworthiness and distributed consensus mechanism: the security interface built by TCB provides hardware-level support for zero-trust "initial verification", ensuring the tamper-proofness of the identity and permission binding process; the federated identity gateway and blockchain achieve distributed synchronization of certificate status, enabling zero-trust "continuous verification" to transcend geographical boundaries and adapt to the management needs of distributed devices; the microservice cluster and PAV mechanism disperse zero-trust permission control to each service node, and through the "local verification + global consensus" model, it ensures both security and improved distributed management efficiency.

[0124] This kind of collaboration enables the system to solve the problem of large-scale management of cross-regional medical equipment through a distributed architecture, and to use the zero-trust mechanism to prevent single-point risks and static permission loopholes in traditional centralized verification, ultimately forming a technical closed loop of "distributed architecture supports verification efficiency, and zero-trust mechanism ensures security bottom line."

[0125] Optionally, in a specific embodiment, the dynamic permission orchestration engine supports a micro-segmentation strategy based on the digital twin model of the medical institution, and binds the device DID, permission certificate and physical location tag in the digital twin through a secure interface, so that the device can only access the management service through the smart access point in the corresponding area, and the permission certificate contains a dynamic access validity period based on a timestamp.

[0126] This shows that this embodiment builds a zero-trust control system with three dimensions of "space-authority-time" through the deep coupling of the digital twin model and dynamic permission orchestration, while relying on the distributed architecture to achieve the coordinated mapping of physical space and virtual management. The specific logic is as follows:

[0127] 1. The principle of minimizing access based on “location as permission”

[0128] The dynamic permission orchestration engine builds micro-segmentation strategies based on the digital twin model of a medical institution, binding device DIDs and permission certificates to the physical location tags in the digital twin. For example, an infusion device is labeled "ICU-Bed 3" in the digital twin, and its permission certificate only allows access to the ICU-specific management service interface through smart access points in that area. This "location equals permission" design implements the zero-trust principle of least privilege. Device permissions are no longer based on fixed network addresses, but are dynamically adjusted based on physical location, avoiding the risk of "permissions not being reclaimed promptly after device movement" in traditional architectures.

[0129] 2. Timestamp-driven permission validity management

[0130] The permission certificate includes a dynamic access validity period based on a timestamp, which, combined with the zero-trust "continuous authentication" requirement, enables time-based control of permissions. For example, if the location tag of a device in a digital twin exceeds a preset time (such as a nursing shift switch), the permission certificate automatically expires, and the identity and location legitimacy must be re-verified through a distributed trust anchor cluster. This dual constraint of "time + location" ensures that even if a device is maliciously moved to another area, it cannot access services with expired permissions, solving the security vulnerability of "long-term validity of permissions" in traditional static permission management.

[0131] 3. Trusted mapping of physical and virtual spaces

[0132] The smart isolation gateway sends proof of network access via the blockchain mechanism, which is synchronized with the location tag in the digital twin model. After the device completes permission configuration, its physical location information is collected and mapped to the digital twin by the edge trusted access module. Software-defined networking (SDN) technology also forcibly directs device traffic to the smart access point in the corresponding area. For example, when a device moves from the emergency room to a general ward, the digital twin model updates the location tag in real time, the dynamic permission orchestration engine simultaneously updates the permission certificate, and the SDN automatically switches the network path, ensuring that the device can only access authorized services in the new area, fulfilling the zero trust requirement of "continuously verifying permissions as the environment changes."

[0133] 2. Distributed Architecture Supports Zero Trust Space Management

[0134] 1. Distributed collaboration of digital twin models

[0135] Digital twin models for medical institutions are built using a distributed architecture. Sub-models for each region (e.g., outpatient and inpatient departments) are maintained by a local trust anchor cluster, with global model parameters synchronized through federated learning. For example, the digital twin of a hospital in Beijing and the model of its Shanghai branch share device location tagging rules via an encrypted channel, ensuring consistent permission policies when devices move across regions. This distributed modeling approach enables zero-trust "location-permission" control to adapt to the distributed deployment of medical systems across multiple campuses and regions, avoiding update delays and single points of failure associated with centralized models.

[0136] 2. Distributed Binding of DID and Digital Twins

[0137] The distributed device identity (DID) utilizes a hybrid blockchain-federated learning architecture, binding the hardware fingerprint to the digital twin's location tag. When a distributed trust anchor cluster verifies the DID based on federated learning, it also verifies the legitimacy of its location tag. For example, if a device's DID is labeled "Shanghai Branch ICU," when it connects to the Beijing General Hospital, the local trust anchor verifies the validity of its location tag through cross-regional federated learning. Temporary permission is granted only when it matches the actual location in the digital twin model. This distributed binding mechanism ensures zero-trust "location trust" is independent of a single central node, adapting to the cross-regional mobility of distributed medical equipment.

[0138] 3. Distributed Permission Enforcement for Smart Access Points

[0139] Smart access points in each area serve as distributed permission enforcement nodes, filtering device traffic based on the digital twin's location tags. For example, access points in the ICU area only allow access to certificates with the "ICU" location tag; certificates from other areas are automatically blocked. This distributed enforcement model extends zero-trust permission control to the network edge, reducing reliance on central servers and improving permission management efficiency in large-scale distributed medical networks. It also prevents global permission loss caused by attacks on centralized permission nodes.

[0140] In summary, the core of this embodiment lies in building a trusted association of "physical device-virtual identity-spatial authority" under the zero-trust framework through the spatial mapping capability of digital twins and the collaborative mechanism of distributed architecture: the digital twin model and physical location tag extend the "principle of least privilege" of zero trust from logical authority to physical space, realizing "where the device is, there the authority boundary is"; the combination of DID and timestamp ensures that the "continuous verification" of zero trust covers the entire life cycle of device access through the immutability of distributed identity and the dynamic nature of time authority; distributed intelligent access points and SDN enable spatial authority control to take effect in real time in distributed medical networks, and balance security and management efficiency through the "local policy execution + global model synchronization" model.

[0141] As a result, this collaboration enables the system to not only solve the spatial management problems of cross-regional equipment through distributed digital twin models, but also use the zero-trust mechanism to prevent risks such as unauthorized access to equipment and location forgery, ultimately forming a technical closed loop of "digital twins define authority boundaries, distributed architecture supports dynamic collaboration, and zero trust ensures spatial security."

[0142] Optionally, in a specific embodiment, the device distributed identity (DID) adopts a blockchain-federated learning hybrid structure, which includes the device hardware fingerprint, encryption public key and integrity measurement value of the trusted execution environment (TEE), and ensures the unforgeability and distributed verification capability of the identity through a cross-chain consensus mechanism.

[0143] This embodiment uses a distributed identity (DID) system based on a blockchain-federated learning hybrid architecture to build a zero-trust foundation of "hardware-level identity anchoring + distributed consensus verification + dynamic trust assessment." At the same time, it relies on a distributed architecture to achieve unified trusted management of cross-regional device identities. The specific logic is as follows:

[0144] 1. “Never Trust” Hardware-Level Identity Anchoring

[0145] The Distributed Device Identity (DID) adopts a blockchain-federated learning hybrid structure, integrating the device hardware fingerprint, encryption public key and the integrity measurement value of the Trusted Execution Environment (TEE). The hardware fingerprint is generated by the chip-level characteristics of the device (such as MAC address, processor ID) and bound to the integrity measurement value of the TEE to ensure the unique correspondence between the identity and the physical device. In the zero-trust architecture, this design breaks the traditional assumption of "trusting the software identity of the device" - even if the device firmware is tampered with, the measurement value in the TEE will change in real time, causing the DID verification to fail, and achieving "initial distrust" identity layer isolation. For example, due to the lack of real hardware fingerprints, the DID of counterfeit devices cannot pass the verification of the distributed trust anchor cluster, blocking illegal access at the source.

[0146] 2. Continuous authentication supported by distributed consensus

[0147] Through a cross-chain consensus mechanism, the generation, update, and verification of DIDs are completed within a distributed trust anchor cluster. When a device is first connected, the edge trusted access module sends the DID to each trust anchor, which collaboratively verifies its legitimacy based on a federated learning architecture: blockchain ensures that identity identification cannot be tampered with, and federated learning enables each node to reach consensus without sharing the original data. This "distributed verification + continuous consensus" mechanism implements the zero-trust requirement of "authentication for every connection"—if a device's TEE metric is abnormal during communication (indicating a possible attack), the cross-chain consensus will update its DID status in real time, triggering the intelligent isolation gateway to cut off the connection, thus avoiding the risk of identity forgery under traditional single-point verification.

[0148] 3. Trusted Binding of Dynamic Permissions and Identity

[0149] The dynamic permission orchestration engine generates permission tokens based on the attribute information in the DID (such as device type and department), and combines network micro-segmentation technology to achieve minimum permission control. Since the DID contains an encrypted public key, the permission token is bound to the DID through attribute-based encryption (ABE), ensuring that only the corresponding device can be decrypted and used. For example, the DID of a ventilator device is marked as "ICU only", and its permission token can only access the management service interface of the ICU area, and each access requires two-way authentication through the DID's encrypted public key, which complies with the zero-trust principle of "permissions dynamically adjusted with identity" to prevent abuse of permissions.

[0150] 2. Distributed Architecture Supports Zero Trust Identity Management

[0151] 1. Decentralized identity anchors and cross-regional verification

[0152] The distributed trust anchor cluster builds a distributed authentication network based on federated learning. Each node (such as cloud nodes in Beijing, Shanghai, and Guangzhou) collaboratively maintains the distributed ledger for the DID. When devices are connected in different regions, the nearest trust anchor verifies their DID through a cross-chain consensus mechanism. For example, the DID of a device in Shenzhen is initially verified by a Shenzhen node and then synchronized to national nodes for confirmation via a cross-chain mechanism, ensuring that the legitimacy of the identity is not dependent on a single center. This distributed verification architecture enables zero-trust "identity trust" to adapt to cross-regional deployment scenarios for medical devices, avoiding the single point of failure and cross-regional communication delays of centralized identity centers.

[0153] 2. Identity privacy protection under hybrid architecture

[0154] DID's hybrid blockchain-federated learning architecture balances security and privacy: blockchain ensures the immutability of identity, while federated learning enables collaborative verification among trust anchors without leaking the device's original data. For example, the device's hardware fingerprint and TEE measurements are encrypted and transmitted within the federated learning network. Each node only shares model parameters, not actual data. This design not only meets the zero-trust requirement for identity authenticity but also complies with healthcare data privacy regulations (such as HIPAA). This design enables distributed medical device identity management to achieve global trust while protecting local data security.

[0155] 3. Dynamic identity updates driven by cross-chain consensus

[0156] When the device status changes (such as hardware repairs or permission updates), the DID is updated in real time through a cross-chain consensus mechanism. The intelligent isolation gateway receives proof of the DID's status change through the blockchain, triggering the dynamic permission orchestration engine to adjust the permission token. For example, if the TEE measurement value of a device changes after repair, its DID status on the blockchain will be marked as "pending re-verification." At this time, the device access request will be temporarily blocked until the new hardware fingerprint is verified through federated learning to match the permissions, achieving the zero-trust "dynamic assessment of identity status" requirement. This distributed identity update mechanism ensures the trustworthiness of the identity throughout the device's life cycle and avoids the lag risks associated with traditional static identity management.

[0157] In summary, the core of this embodiment lies in the deep integration of the "trusted identity" requirement of zero trust and the "decentralized consensus" feature of the distributed architecture through the hybrid architecture design of DID: hardware fingerprint and TEE measurement values provide hardware-level identity anchors for zero trust, solving the problem of "is the device itself?"; blockchain and cross-chain consensus ensure the unforgeability and distributed verification of identity identification, solving the problem of "how to trust identity in a distributed environment"; federated learning and dynamic permission orchestration enable identity authentication and permission control to be coordinated across regions without leaking privacy, solving the problem of "identity management efficiency of large-scale distributed devices."

[0158] As a result, this collaboration enables the system to manage cross-regional and multi-type medical devices through a distributed DID architecture, and to prevent risks such as identity forgery and authority misuse with the help of a zero-trust mechanism, ultimately forming a technical closed loop of "distributed identity supporting large-scale management and zero-trust verification ensuring identity credibility."

[0159] Optionally, in a specific embodiment, the medical device includes a distributed terminal equipped with an edge intelligent unit, such as an intelligent infusion workstation, non-invasive ventilation equipment, blockchain medicine cabinet and other IoT devices, and its access request is transmitted to the trust anchor cluster through a heterogeneous network proxy component, following the three-dimensional authentication mechanism of "device identity + behavioral characteristics + environmental parameters".

[0160] The essential principle of this embodiment in implementing distributed medical device management based on a zero-trust network is to build a zero-trust verification system of "device identity-behavioral characteristics-environmental dynamics" through the collaboration of edge intelligent units and three-dimensional authentication mechanisms, while relying on a distributed architecture to achieve unified security management of heterogeneous devices. The specific logic is as follows:

[0161] 1. “Never Trust” Three-Dimensional Identity Anchoring

[0162] The edge intelligence unit equipped in medical equipment integrates a hardware root of trust, and combines the three-dimensional authentication mechanism of "device identity + behavioral characteristics + environmental parameters" to break the trust assumption of traditional "single identity authentication". The device identity is bound to the hardware fingerprint through a distributed identity identifier (DID). The behavioral characteristics are collected by the edge intelligence unit to collect the operating mode of the device during operation (such as the flow rate adjustment frequency of the infusion pump). The environmental parameters include the network access location, timestamp and the relationship between peripheral devices. For example, when a smart infusion workstation is connected, the edge intelligence unit synchronously sends the DID, recent operation logs and the environmental parameters of the department where it is located to the distributed trust anchor cluster. All three must be verified at the same time before access is allowed, realizing the multi-dimensional identity verification of zero trust "initial distrust".

[0163] 2. Dynamic Trust Assessment with Continuous Verification

[0164] The three-dimensional authentication mechanism follows the zero-trust principle of "continuous authentication and real-time verification": during device communication, the edge intelligent unit continuously collects behavioral characteristics (such as changes in the ventilation mode of the ventilator) and environmental parameters (such as the network signal strength of the ward), and transmits them to the trust anchor cluster through the heterogeneous network proxy component. If the behavioral characteristics are abnormal (such as the flow rate adjustment frequency of the infusion pump exceeds the historical baseline) or the environmental parameters do not match (such as the device suddenly appears in an unauthorized department), the trust anchor immediately updates the trust score of the device and triggers the dynamic permission orchestration engine to reclaim or adjust permissions. This "dynamic data + real-time evaluation" mechanism avoids the risk of continued access to the device after being hijacked under traditional static authentication.

[0165] 3. Binding of least privilege and environmental awareness

[0166] The dynamic permission orchestration engine generates fine-grained permission tokens based on the results of three-dimensional authentication: device identity determines basic permissions (e.g., infusion devices can only access infusion management services), behavioral characteristics influence temporary permissions (e.g., parameter adjustment permissions are restricted during abnormal operations), and environmental parameters define spatial permissions (e.g., network access is limited to the department). For example, a blockchain medicine cabinet has drug dispensing permissions when used within a normal department. If it is moved to another department, changes in environmental parameters will cause the permission token to become invalid, requiring re-authentication through three-dimensional authentication, implementing the zero-trust principle of "minimum permissions dynamically adjusted with the environment."

[0167] 2. Distributed Architecture Supports Zero Trust Multi-Dimensional Management

[0168] 1. Heterogeneous network proxy and distributed authentication collaboration

[0169] The heterogeneous network proxy component supports device access using different network protocols (such as 5G, Wi-Fi, and LoRa), converting multi-source access requests into a format recognizable by the distributed trust anchor cluster. For example, a community clinic's IoT medicine cabinet accesses the 4G network, while a tertiary hospital's ventilator accesses the hospital's Wi-Fi. Both access requests are standardized by the heterogeneous network proxy component and sent to the nearest trust anchor cluster for verification. This distributed access architecture enables zero-trust three-dimensional authentication to cover medical devices across regions and types, avoiding the protocol adaptation bottlenecks of centralized proxies.

[0170] 2. Distributed feature extraction of edge intelligence units

[0171] The edge intelligence unit is deployed locally on the device and is responsible for collecting behavioral characteristics and environmental parameters in real time, reducing the centralized transmission of data to the central node. For example, the edge intelligence unit of a non-invasive ventilation device analyzes ventilation pattern data locally and only sends abnormal features (such as frequency mutations) to the trust anchor cluster, while normal data is stored locally. This distributed feature extraction mode not only meets the zero-trust "continuous data collection" requirement, but also reduces the bandwidth pressure of distributed medical networks and improves the efficiency of large-scale equipment management.

[0172] 3. Distributed consensus mechanism for three-dimensional authentication

[0173] A distributed trust anchor cluster collaboratively processes three-dimensional authentication data based on a federated learning architecture: Nodes in each region (such as Beijing, Shanghai, and Guangzhou) independently analyze the device's behavioral characteristics and environmental parameters, sharing the authentication results through a cross-chain blockchain consensus mechanism. For example, when a device is connected in Shenzhen, the Shenzhen node verifies its identity and local environmental parameters, while the Shanghai node analyzes whether its behavioral characteristics conform to historical models. Both nodes then confirm the authentication results through consensus, ensuring the accuracy and consistency of three-dimensional authentication. This distributed consensus mechanism enables zero-trust multi-dimensional authentication without relying on a single node, adapting to the management needs of cross-regional medical device flows.

[0174] Therefore, the core of the solution of this embodiment is to build a "device autonomy-edge collaboration-global trust" management system under the zero trust framework through the local processing capabilities of the edge intelligent unit and the distributed consensus of three-dimensional authentication: the edge intelligent unit and the heterogeneous network agent solve the management problems of "protocol heterogeneity and location dispersion" of distributed medical equipment, and provide the hardware foundation for multi-source data collection for zero trust; the three-dimensional authentication mechanism and federated learning realize the dynamic and accuracy of zero trust "continuous trust assessment" through multi-dimensional verification and distributed feature analysis of "identity + behavior + environment"; blockchain consensus and dynamic permission orchestration ensure the trusted synchronization of three-dimensional authentication results in the distributed network, so that the minimum permission control of zero trust can be adjusted in real time with the device status and environment.

[0175] In summary, this collaboration enables the system to manage massive heterogeneous medical devices through a distributed architecture, and to prevent risks such as device identity forgery and abnormal behavior with the help of a zero-trust mechanism, ultimately forming a technical closed loop of "edge intelligence supporting local security, distributed collaboration achieving global trust, and a zero-trust paradigm ensuring security throughout the entire life cycle."

[0176] Optionally, in a specific embodiment, the process of configuring the access management service of the device follows the Trusted Startup Chain (TCC) mechanism: the authority certificate is received through the temporary provisioning network and stored in the device secure enclave (Secure Enclave), and after the TEE verifies the validity of the certificate, the operating environment certificate containing the hardware signature is sent to the trust anchor cluster. The certificate is ensured to comply with the zero-trust security baseline through the remote verification component (RVP).

[0177] This embodiment builds a full-process zero-trust verification system "from device startup to service access" through the collaboration of the Trusted Startup Chain (TCC) mechanism and hardware-level security components, while relying on a distributed architecture to achieve cross-node trusted state consensus. The specific logic is as follows:

[0178] 1. “Initial Distrust” Hardware-Level Boot Verification

[0179] When configuring access management services, devices follow the Trusted Boot Chain (TCC) mechanism, implementing zero-trust verification from the power-on stage. When the device is first powered on, the hardware root of trust triggers the TCC, which receives the authorization certificate through a temporary provisioning network and stores it in the Secure Enclave—a hardware-isolated space built by the Trusted Execution Environment (TEE). This ensures that the certificate is tamper-proof during storage and verification. The "initial distrust" principle of zero trust is reflected here: even if the device operating system is maliciously tampered with, the Secure Enclave within the TEE can still independently verify the validity of the certificate, preventing malicious code from forging authorization credentials.

[0180] 2. Continuously verified operating environment proof

[0181] After the TEE locally verifies the validity of the permission certificate, it sends a hardware-signed runtime environment certificate to the distributed trust anchor cluster through the remote verification component (RVP). The certificate contains integrity measurements such as the device firmware version and configuration parameters, and is signed by the hardware security module (HSM) to ensure that it cannot be tampered with. The distributed trust anchor verifies the certificate based on the federated learning architecture, and only allows the device to access the management service when the operating environment meets the zero-trust security baseline (such as no abnormal process is detected). This continuous mechanism of "boot verification + runtime proof" implements the zero-trust "continuous authentication, real-time verification" requirements and avoids the risk of trust solidification after traditional boot.

[0182] 3. Binding of Least Permission and Trusted State

[0183] The dynamic permission orchestration engine generates fine-grained permission tokens based on TEE-verified permission certificates, combined with network micro-segmentation technology. Because the certificates are stored in a secure enclave and the operating environment is verified by RVP, the permission tokens are deeply tied to the device's trusted state. For example, if the device's operating environment is tampered with, resulting in abnormal measurement values, RVP will detect this in real time and trigger the intelligent isolation gateway to disconnect and reclaim the permission token, achieving zero-trust minimum privilege control where permissions dynamically adjust to trusted state.

[0184] 2. Distributed Architecture Supports Zero Trust Trusted Processes

[0185] 1. Distributed trust anchors and remote verification collaboration

[0186] A distributed trust anchor cluster builds a remote verification network based on federated learning. Each node collaborates to verify the device's operating environment. For example, a trust anchor in Beijing verifies the legitimacy of a certificate, while a node in Shanghai verifies that operating environment metrics adhere to a security baseline. The consistency of these results is confirmed through a cross-chain blockchain consensus mechanism. This distributed verification architecture ensures that the zero-trust trusted boot chain is independent of a single node. Even if some nodes are attacked, the consensus mechanism ensures the accuracy of verification results among other nodes, making it suitable for distributed medical device deployments across multiple regions.

[0187] 2. Synchronize the secure enclave with the trusted state of the blockchain

[0188] The status of the permission certificates stored in the device's secure enclave is synchronized with the blockchain ledger in real time. When a certificate expires or is revoked, the distributed trust anchor broadcasts the status change via the blockchain, triggering the device's TEE to revalidate the certificate's validity. For example, if a device's permission certificate is marked "expired," its copy in the secure enclave automatically becomes invalid. The TCC mechanism will force reauthentication upon the next access, ensuring that Zero Trust's "permission timeliness" is uniformly enforced across the distributed network and avoiding synchronization delays associated with centralized certificate management.

[0189] 3. Distributed consensus record of trusted startup chain

[0190] The network access status certificate sent by the intelligent isolation gateway via the blockchain mechanism forms a closed loop with the verification record of the TCC mechanism: after the device completes trusted boot and passes RVP verification, its operating environment certificate and permission certificate status are recorded in the blockchain distributed ledger, and all trust anchors simultaneously update the device's trusted status. This distributed recording mechanism ensures that the entire process from device boot to access is traceable and tamper-proof, providing support for zero-trust "trusted process auditing." For example, in the event of a security incident, the blockchain ledger can be used to trace back the environmental status at device boot time and locate the source of the risk.

[0191] As can be seen, the core of this embodiment lies in combining the full-process trusted verification of the TCC mechanism with distributed consensus technology to build a trusted closed loop of "hardware startup - remote attestation - dynamic permissions" under the zero-trust framework: the secure enclave and TEE provide a hardware-level certificate storage and verification environment for zero trust, solving the problem of "trust anchoring during the startup phase"; RVP and distributed trust anchors achieve distributed consensus on the device operating environment through remote verification and federated learning, solving the problem of "how to trust device status in a distributed network"; blockchain and intelligent isolation gateways ensure distributed synchronization of trusted status and real-time network isolation, solving the problem of "how to dynamically adjust permissions when trusted status changes."

[0192] This collaboration enables the system to manage the trusted startup process of cross-regional medical devices through a distributed architecture, and to use the zero-trust mechanism to prevent risks such as device hijacking and authority misuse after startup, ultimately forming a technical closed loop of "hardware trusted startup supporting the zero-trust baseline, distributed consensus ensuring full-process trust, and the zero-trust paradigm covering the entire life cycle of device access."

[0193] Optionally, in a specific embodiment, the intelligent isolation gateway integrates a software-defined boundary (SDP) component, which, after receiving the device trust certificate, dynamically generates a network access control list (ACL) through a policy decision point (PDP), cuts off temporary network connections and activates a micro-segmented communication channel based on a service mesh (Service Mesh), thereby achieving "continuous authentication and dynamic authorization" adaptive access control.

[0194] This embodiment uses the collaborative architecture of software-defined perimeter (SDP) and service grid to build a zero-trust execution closed loop of "dynamic isolation - permission fine-tuning - continuous verification", while relying on distributed components to achieve cross-node access control consensus. The specific logic is as follows:

[0195] 1. “Never Trust” Dynamic Network Isolation

[0196] The intelligent isolation gateway integrates a software-defined perimeter (SDP) component, and after the device completes identity authentication, it dynamically generates a network access control list (ACL) through a policy decision point (PDP). This design breaks the traditional assumption of "fixed network perimeter trust": when the device is first connected, it is forced to pass temporary provisioning network verification. After receiving the trusted proof from the distributed trust anchor cluster, the SDP component cuts off the temporary network connection based on the ACL and activates a micro-segmented communication channel based on the service mesh. For example, after a smart infusion device passes the verification, the SDP only allows its traffic to access the infusion management service through the specified micro-segmented channel. Other unauthorized service interfaces are blocked by the ACL, achieving zero-trust "initial distrust" network layer isolation.

[0197] 2. Collaboration between Continuous Authentication and Dynamic Authorization

[0198] The service mesh architecture supports real-time monitoring of communication traffic and fine-tuning of permissions: every communication between the device and the management service must pass through the service mesh's sidecar agent (Sidecar) to verify the permission token, combined with the ACL rules dynamically generated by the PDP to achieve "continuous authentication and dynamic authorization." For example, if a device exhibits abnormal behavior during communication (such as frequent requests for unauthorized interfaces), the service mesh sidecar agent will intercept the traffic in real time and trigger the PDP to update the ACL, temporarily revoking some permissions, and then re-authorizing them after the device behavior returns to normal. This "access-verification-adjustment" cycle implements the core requirements of zero trust: "every connection must be verified, and permissions are dynamically adjusted according to behavior," avoiding the risk of permission abuse under traditional static ACLs.

[0199] 3. Deep integration of least privilege and micro-segmentation

[0200] The attribute-based access control (ABAC) policy injected by the dynamic permission orchestration engine is combined with the service mesh micro-segmentation technology to enable the permission token to contain micro-segmentation tags (such as "ICU equipment" and "pharmacy service"). The service mesh divides the medical network into multiple security domains based on the tags, and the device can only access the target service through the communication channel of the corresponding domain. For example, the permission token of the blockchain medicine cabinet contains the "pharmacy service" tag. The service mesh only allows its traffic to enter the pharmacy micro-segmentation channel and communicate with the medicine cabinet management service, preventing unauthorized access to data from other departments and realizing the precise implementation of the zero-trust "principle of least privilege."

[0201] 2. Distributed Architecture Supports Zero Trust Access Control

[0202] 1. Distributed strategy decision-making and consensus mechanism

[0203] The Policy Decision Point (PDP) constructs a distributed decision-making network based on a federated learning architecture. Regional nodes (such as medical cloud nodes in Beijing and Shanghai) collaborate to generate ACL rules. For example, when a device is connected to a hospital in Shenzhen, the local PDP node generates an initial ACL based on the device's DID and permission certificate. This is then synchronized to national nodes through a cross-chain blockchain consensus mechanism to ensure the consistency of ACL rules across all nodes. This distributed decision-making architecture ensures that zero-trust access control policies are independent of a single node. Even if some PDP nodes are attacked, other nodes can still generate the correct ACL through a consensus mechanism, adapting to the cross-regional management needs of distributed medical networks.

[0204] 2. Distributed Traffic Control in Service Meshes

[0205] The service mesh utilizes a distributed sidecar proxy architecture, where the sidecar proxy for each micro-segmentation channel independently executes ACL rules while synchronizing policy updates via the blockchain. For example, when a device moves from the emergency room to a general ward, the distributed trust anchor cluster updates its permission tag. The service mesh sidecar proxy obtains the new tag via the blockchain and automatically adjusts the ACL rules for the micro-segmentation channel, directing device traffic to the general ward's service domain. This distributed traffic control model enables zero-trust micro-segmentation policies to respond to device location changes in real time, avoiding update delays in centralized policy centers and improving access control efficiency in large-scale distributed medical networks.

[0206] 3. Synchronize the trusted state of SDP and blockchain

[0207] The proof of access sent by the intelligent isolation gateway via the blockchain mechanism forms a closed loop with the ACL generation process of the SDP component: After the device completes permission configuration, its trusted proof is broadcast to all service mesh nodes via the blockchain. The sidecar agent on each node then generates the corresponding ACL rules based on the proof. For example, if the trusted proof of a device includes the label "Authorized to access ICU services," the service mesh sidecar agent automatically generates an ACL that allows the device to access the ICU micro-segmentation channel while denying access to other channels. This distributed state synchronization mechanism ensures that zero-trust access control policies are uniformly enforced across the entire network, preventing permission vulnerabilities caused by asynchronous node states.

[0208] In summary, the core of this embodiment lies in building a technical closed loop of "policy decision-making-traffic execution-state consensus" under the zero trust framework through the dynamic isolation capability of SDP and the distributed traffic control of the service grid: SDP and PDP provide the hardware foundation for dynamic network isolation and policy generation for zero trust, solving the problem of "how to block unauthorized access"; service grid and micro-segmentation perform fine-grained access control through distributed sidecar agents, solving the problem of "how to accurately control traffic in a distributed network"; blockchain and ACL dynamic generation ensure distributed consensus and real-time updates of access control policies, solving the problem of "how to synchronize all nodes when policies change".

[0209] This collaboration enables the system to manage access control of cross-regional medical equipment through a distributed architecture, and to prevent risks such as network penetration and unauthorized access with the help of a zero-trust mechanism, ultimately forming a technical closed loop of "distributed policy decision-making to support management efficiency and zero-trust access control to ensure network security."

[0210] like Figure 2 As shown, according to a first aspect of an embodiment of the present invention, a distributed medical device trusted management method based on the management platform described in any one of the present applications is provided, comprising:

[0211] When the device is powered on for the first time, it connects to the zero-trust edge network through the hardware root of trust, triggering a distributed identity-based authentication request;

[0212] In a cross-region trust anchor cluster, device identity and pre-authorization permissions are verified through a federated learning model;

[0213] Utilize attribute-based encryption technology to distribute dynamic permission certificates and combine it with micro-segmentation strategies to establish secure communication channels;

[0214] Network isolation switching is completed through the blockchain consensus mechanism, realizing adaptive management of device access rights.

[0215] above Figure 2 The technical essence of this method lies in building a closed-loop management process of "hardware trusted access - distributed identity authentication - dynamic permission control - adaptive network isolation" through deep collaboration with a distributed zero-trust management platform. This integrates the zero-trust security paradigm of "never trust, continuous verification" and the "decentralized, fault-tolerant and scalable" features of a distributed architecture into the entire device management lifecycle. This is specifically reflected as follows:

[0216] 1. Hardware Trusted Access Triggers Zero Trust Verification Process

[0217] When the device is powered on for the first time, it accesses the zero-trust edge network through the hardware trust root, triggering an authentication request based on a distributed identity. This process is based on the hardware-level trust root mechanism to achieve the zero-trust "initial distrust" security baseline. The hardware trust root is bound to the device's distributed identity identifier (DID) to ensure that the access request originates from a real physical device rather than a counterfeit terminal. At the same time, the zero-trust edge network, as a temporary supply network independent of the medical core network, uses hardware-level isolation technology to achieve physical channel separation, blocking unauthorized devices from directly accessing the core network from the access layer. This step relies on the edge trusted access module of the management platform to transform the traditional "device access is trust" model into a dual zero-trust verification mode of "hardware verification + isolation verification", so that the device must pass distributed identity authentication before obtaining further access rights.

[0218] 2. Distributed authentication supports zero-trust continuous authentication

[0219] In a cross-regional trust anchor cluster, a federated learning model is used to verify device identity and pre-authorized permissions, leveraging the decentralized nature of the distributed architecture to implement the zero-trust "continuous authentication" principle. The distributed trust anchor cluster builds a distributed identity authentication network based on the federated learning architecture. The device DID uses a blockchain-federated learning hybrid architecture, containing tamper-proof information such as hardware fingerprints and encrypted public keys. Trust anchors in each region collaborate to verify the legitimacy of the device identity chain through a cross-chain consensus mechanism. This distributed verification model replaces the traditional single-point authentication center. Even if some nodes fail, the validity of the verification can still be guaranteed through a consensus mechanism. At the same time, each device communication requires re-authentication to avoid the abuse of permissions caused by static trust, thus achieving the core requirement of zero trust: "authentication for every connection."

[0220] 3. Dynamic Permission Control to Achieve Zero Trust Least Privilege

[0221] Attribute-based encryption technology is used to distribute dynamic permission certificates, and a secure communication channel is established in combination with micro-segmentation strategies. The zero-trust "least privilege principle" is achieved through "attribute authorization + micro-segmentation isolation". The dynamic permission orchestration engine generates fine-grained permission tokens based on device attributes (such as type, location, and function). Attribute-based encryption (ABE) technology allows permission certificates to be decrypted only by the corresponding device, ensuring the unique binding of permissions to device identities; network micro-segmentation technology divides the medical network into multiple security domains, and devices can only access authorized target service units through permission tokens to prevent lateral penetration. This step relies on the dynamic permission orchestration engine of the management platform to transform traditional centralized and extensive permission management into "one-time authorization" dynamic control in a distributed environment, so that device permissions can be adjusted in real time as attributes change, and the minimum permission access state is always maintained.

[0222] 4. Blockchain consensus drives adaptive network isolation

[0223] Network isolation switching is accomplished through a blockchain consensus mechanism, enabling adaptive management of device access rights. Distributed consensus technology ensures the credibility and real-time nature of zero-trust network isolation. After automatically severing temporary network connections using software-defined networking (SDN) technology, the intelligent isolation gateway leverages the blockchain consensus mechanism to send an unalterable proof of network access to the management node. Trust anchors across the entire network then synchronize device status updates. When device permissions or location change, the blockchain smart contract triggers the dynamic permissions orchestration engine to update the permission token, and the SDN adjusts network routing in real time, forming an adaptive "status consensus - permissions update - isolation switching" mechanism. This process replaces traditional static routing configuration, ensuring that network isolation status is verifiable and traceable, meeting the zero-trust requirement of "continuous verification of isolation status."

[0224] This collaborative approach can not only address the management challenges of cross-regional and large-scale deployment of medical equipment through a distributed architecture, but also use the zero-trust mechanism to prevent security risks such as identity forgery and unauthorized access in traditional architectures. Ultimately, it forms a technical closed loop of "using distributed architecture to support management efficiency and using zero-trust mechanism to ensure security bottom line", realizing trusted management of medical equipment throughout its entire life cycle from entry to exit.

[0225] The above embodiments are only used to illustrate the embodiments of the present invention, and are not intended to limit the embodiments of the present invention. Ordinary technicians in the relevant technical field can make various changes and modifications without departing from the spirit and scope of the embodiments of the present invention. Therefore, all equivalent technical solutions also fall within the scope of the embodiments of the present invention, and the scope of patent protection of the embodiments of the present invention should be defined by the claims. The systems, devices, modules or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions.

Claims

1. A distributed medical device trusted management platform based on zero trust architecture, characterized by: include: The edge trusted access module, distributed trust anchor cluster, dynamic permission orchestration engine, and intelligent isolation gateway all work together through a decentralized trust chain: The edge trusted access module uses a hardware root of trust mechanism to connect first-time devices to a temporary supply network isolated from the core medical network, following the zero-trust security paradigm; The distributed trust anchor cluster builds a distributed authentication network based on federated learning, and verifies access pre-authorization permissions through device distributed identity identification (DID); The dynamic permission orchestration engine injects attribute-based access control policies and generates permission tokens in combination with network micro-segmentation to achieve two-way encrypted communication between devices and target services. The intelligent isolation gateway cuts off temporary connections through software-defined networking technology and sends proof of network access through the blockchain mechanism, where the edge module initialization is performed by a trusted node outside the medical cloud.

2. The management platform according to claim 1, characterized in that: The distributed trust anchor cluster integrates a cross-domain certificate alliance component, and based on the unique key pair generated by the device hardware security module (HSM), distributes dynamic permission certificates to the device through zero-knowledge proof technology before identity authentication. The certificate uses the constructed attribute-based encryption (ABE) mechanism to limit the device to access only the management service interface containing the corresponding permission tag.

3. The management platform according to claim 1, characterized in that: The temporary supply network adopts a self-organizing network (SON) architecture, and broadcasts a dynamic SSID bound to the trusted platform module (TPM) burned into the device before leaving the factory through a trusted boot program. When the device is powered on for the first time, it automatically matches and connects through the hardware trust root, triggering a zero-trust authentication process based on remote attestation (RA).

4. The management platform according to claim 2, characterized in that: The distributed management microservice cluster receives the binding relationship between the device DID and the authority certificate through the security interface built by the trusted computing base (TCB), and synchronizes the certificate status to the external supply node through the federal identity gateway when the device is connected, and adopts the continuous verification (PAV) mechanism to realize real-time identity verification for each communication.

5. The management platform according to claim 4, characterized in that: The dynamic permission orchestration engine supports micro-segmentation strategies based on the digital twin model of medical institutions. It binds the device DID, permission certificate and physical location tag in the digital twin through a secure interface, so that the device can only access management services through the smart access point in the corresponding area, and the permission certificate contains a dynamic access validity period based on a timestamp.

6. The management platform according to claim 1, characterized in that: The device distributed identity (DID) adopts a blockchain-federated learning hybrid structure, which includes the device hardware fingerprint, encryption public key and integrity measurement value of the trusted execution environment (TEE), and ensures the unforgeability and distributed verification capability of the identity through a cross-chain consensus mechanism.

7. The management platform according to claim 1, characterized in that: The medical devices include distributed terminals equipped with edge intelligent units, such as smart infusion workstations, non-invasive ventilation equipment, blockchain medicine cabinets and other IoT devices. Their access requests are transmitted to the trust anchor cluster through heterogeneous network proxy components, following the three-dimensional authentication mechanism of "device identity + behavioral characteristics + environmental parameters".

8. The management platform according to claim 2, characterized in that: The process of configuring device access management services follows the Trusted Startup Chain (TCC) mechanism: the authority certificate is received through the temporary provisioning network and stored in the device's secure enclave (Secure Enclave). After the TEE verifies the validity of the certificate, it sends a hardware-signed runtime environment certificate to the trust anchor cluster. This certificate is ensured to comply with the zero-trust security baseline through the remote verification component (RVP).

9. The management platform according to claim 1, characterized in that: The intelligent isolation gateway integrates a software-defined perimeter (SDP) component. After receiving the device's trusted proof, it dynamically generates a network access control list (ACL) through a policy decision point (PDP), cuts off temporary network connections, and activates a micro-segmented communication channel based on a service mesh (Service Mesh), achieving adaptive access control with "continuous authentication and dynamic authorization." 10. A distributed medical device trusted management method based on the management platform according to any one of claims 1 to 9, characterized in that: include: When the device is powered on for the first time, it connects to the zero-trust edge network through the hardware root of trust, triggering a distributed identity-based authentication request; In a cross-region trust anchor cluster, device identity and pre-authorization permissions are verified through a federated learning model; Utilize attribute-based encryption technology to distribute dynamic permission certificates and combine it with micro-segmentation strategies to establish secure communication channels; Network isolation switching is completed through the blockchain consensus mechanism, realizing adaptive management of device access rights.

Images