A zero-trust medical Internet of Things authentication method and system based on blockchain

By adopting a blockchain-based zero-trust architecture, identity registration, static and continuous authentication are achieved in medical IoT systems, solving the security and scalability issues in existing technologies, meeting real-time requirements, providing cross-domain authentication and password recovery, and improving the quality and efficiency of medical services.

CN119815333BActive Publication Date: 2025-10-28HUAZHONG NORMAL UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411955260.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-27
Publication Date
2025-10-28
Estimated Expiration
2044-12-27

AI Technical Summary

Technical Problem

Existing medical IoT systems suffer from problems such as over-reliance on boundary security models, scalability limitations due to centralized authentication, insufficient real-time performance, complex encryption methods with limited resistance, and a lack of cross-domain authentication and password recovery functions.

Method used

It adopts a blockchain-based zero-trust architecture, initializes and deploys smart contracts through a registry center to achieve identity registration and static authentication of fog nodes, users and sensors, and uses continuous authentication, tokens and channel fingerprints for continuous authentication, supporting cross-domain authentication and password retrieval.

Benefits of technology

It improves the security and scalability of medical IoT systems, meets real-time requirements, resists known attacks, provides cross-domain authentication and password recovery functions, integrates medical resources, lowers the threshold for medical services, and improves the quality and efficiency of medical services.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119815333B_ABST
    Figure CN119815333B_ABST
Patent Text Reader

Abstract

This invention belongs to the field of medical IoT authentication technology, and discloses a blockchain-based zero-trust medical IoT authentication method and system. This invention adopts a zero-trust security architecture, introducing continuous authentication on top of traditional single authentication, and classifying user-applied operation permissions into different levels, setting corresponding continuous authentication time intervals according to the level, effectively solving the over-trust problem in existing technologies. The technology of this invention constructs a private blockchain for data storage between the cloud, the registration center, and fog nodes, and deploys related smart contracts. When a fog node fails, other fog nodes can still obtain relevant data through smart contracts, thereby providing authentication services. Based on the cloud, this invention introduces fog computing to provide low-latency services.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of medical IoT authentication technology, and in particular relates to a blockchain-based zero-trust medical IoT authentication method and system. Background Technology

[0002] In a Medical Internet of Things (MIoT) environment, smart wearable devices and implantable sensors monitor patients' critical physical data in real time, such as blood pressure and heart rate, and also collect health-related environmental information such as temperature, humidity, and air quality in the patient's environment. In addition to this real-time data, the MIoT system centrally manages various patient health monitoring reports. Medical personnel can view this data anytime, anywhere using various terminal devices to provide diagnostic opinions and treatment plans, and even conduct remote surgery using technologies such as 5G and real-time video transmission. In emergencies, MIoT's real-time monitoring mechanism allows medical personnel to react promptly and prevent the patient's condition from worsening. Furthermore, MIoT can use AI technology to assist in diagnosis and monitoring, automating some medical services and further reducing the burden on hospitals. These intelligent medical approaches can significantly improve the quality and efficiency of medical services and lower the barriers for patients to access healthcare. However, data in MIoT is transmitted via wireless networks, which are insecure open channels, making the transmitted data vulnerable to eavesdropping, interception, and tampering by attackers. This data contains patients' private information, and if obtained by attackers, it will seriously infringe on patients' privacy. Furthermore, this data is a crucial reference for doctors' diagnoses. If it is tampered with by attackers, doctors may make incorrect diagnoses, thereby endangering patients' health. Therefore, a secure and efficient authentication scheme is needed to ensure the security of the medical Internet of Things (IoT).

[0003] Based on the above analysis, the problems and shortcomings of the existing technology are as follows:

[0004] (1) Existing solutions are all based on the boundary security model, which associates trust with location. It assumes that the network has a fixed boundary and divides the network into two parts: an internal trusted part and an external untrusted part. Users can freely access internal resources after completing authentication at the entry point. This solution over-trusts the internal network, and the system's security level depends on the weakest protected device, making it difficult to resist malicious internal nodes. Attackers can capture flawed devices, hijack authenticated sessions, or exploit security vulnerabilities to enter the network and access various resources, causing great harm to MIoT.

[0005] (2) Most existing technologies use centralized authentication methods, which limits the scalability of the Internet of Things in healthcare and is prone to single point of failure.

[0006] (3) Existing technologies that introduce cloud storage and analysis of data in the medical Internet of Things have significant delays and are not suitable for the real-time requirements of the medical Internet of Things.

[0007] (4) Existing technologies employ complex encryption methods and have limited resistance to known attacks.

[0008] (5) Existing technologies do not provide cross-domain authentication, password recovery and node revocation functions. Summary of the Invention

[0009] To address the problems existing in the prior art, this invention provides a blockchain-based zero-trust medical IoT authentication method and system.

[0010] This invention is implemented as follows: A blockchain-based zero-trust medical IoT authentication method includes:

[0011] Step 1, the initialization phase, involves the registry center generating the necessary parameters for the system, building the blockchain, and deploying smart contracts;

[0012] Step 2, the registration phase, involves the registration center registering the identities of fog nodes, remote users, and sensors;

[0013] Step 3, the static authentication phase completes the mutual authentication between the user, fog node and sensor, and negotiates a session key;

[0014] Step 4, Continuous Authentication Preparation Phase: Users and sensors generate tokens and channel fingerprints respectively for use in the continuous authentication phase;

[0015] Step 5, the continuous authentication phase is repeated at certain time intervals, in which users and sensors authenticate each other using channel fingerprints and tokens;

[0016] Step 6, the password recovery stage, is where users recover their passwords by answering password recovery questions;

[0017] Step 7, the cross-domain authentication phase, involves the user authenticating with sensors from other domains.

[0018] Furthermore, the initialization phase:

[0019] The RC selects the master key MK; then, the RC constructs the blockchain and deploys smart contracts for data storage, data retrieval, data updates, and reputation management.

[0020] Registration phase:

[0021] Fog node registration: Fog nodes register with the registration center. The registration steps are as follows:

[0022] Step 1.F k Select Identity ID (FID) kThen FID k Transmitted to the Registry Center (RC);

[0023] Step 2. After receiving the message, RC generates a random number r1 and calculates FK. k =h(r1‖MK) and FIC k =h(FID) k ‖FK k Then, RC calls the smart contract storeFogNode(FK); k FIC k Store {FID} in the data chain k FIC k Finally, RC will FK k Send to F k ;

[0024] Step 3. Receive FK k After that, F k Store {FID k FK k};

[0025] User registration: Users register with the registration center. The registration steps are as follows:

[0026] Step 1.U i Select Identity ID (UID) i Password PW i Input biological information B i Then, MD i Generate a random number r2 and a list of password recovery questions. p ={p1,p2,…,p n}, U i Set List p List of corresponding answers a ={a1,a2,…,a n}; After completion, MD i calculate (σ i ,τ i ) = Gen(B i ), PID i =h(r2‖UID) i ), PW * =h(r2‖PW i ||UID i ) and RID i =h(UID) i ‖σ i Finally, MD i PID i PW * RIDi List p Transmitted to RC;

[0027] Step 2. RC receives U i After obtaining the registration information, a random number r3 is generated, and the UK is calculated. i =h(r3‖MK), and Then, RC calls storeUser(TID) i HID i List p RID i Stored in the blockchain And transmit {UR} to U i ;

[0028] Step 3.U i After receiving the UR, calculate L3=h(PW i ‖σ i ||r2||UID i )and Then, MD i Store {L1,L2,L3,L4,h(V)} R ),τ i};

[0029] Sensor registration: Sensors also need to be registered with the registration center. The registration steps are as follows:

[0030] Step 1.S j Select Identity ID (SID) j Then SID j Transmitted to RC;

[0031] Step 2. RC receives SID j Then, choose to challenge C. j Then, RC will C j Send to S j ;

[0032] Step 3.S j Received C j Calculate R j =PUF(C j Then, S j R j Send to RC;

[0033] Step 4. RC receives R j Then, call storeSensor(SID) j ,C j,R j ), storing {SID} in the blockchain j ,C j ,R j};

[0034] Static authentication phase:

[0035] Users first need to log in using their mobile devices. After successful login, the user and the sensor authenticate each other.

[0036] Login: U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τ i ), and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Proceed to the next steps.

[0037] Mutual authentication: After successful user login, mutual authentication is performed with the sensor. The authentication steps are as follows:

[0038] Step 1.U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i =h(r'2‖UID') i ), and UM2=h(n1||TID) i ||UK'1‖T1‖A per After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per} Transmitted to F k ;

[0039] Step 2.F k Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F kCall getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i The corresponding HID i Then, F k calculate and UM'2=h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; F k Call getSensor(SID) j If SID' j F does not exist. k Terminate authentication, otherwise F k Get the corresponding C j and R j Then, F k Generate random number n2 and a new challenge calculate and Finally, F k Will Transmitted to SID' j The corresponding S j ;

[0040] Step 3.S j Received Then, calculate R' j =PUF(C j ), and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n”1‖n3‖R' j||SID j ) and SM2 = h(SK j ‖n”1‖n3); Finally, S j Transmit {SM1,SM2} to F k ;

[0041] Step 4.F k After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID' j ) and SM'2 = h(SK k ||n'1||n'3); then, F k Compare whether SM'2 is equal to SM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID'). j ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k Call renew and F k calculate and After the calculation is completed, F k Call renew And transmit {FM3,SM2} to U i ;

[0042] Step 5.U i After receiving {FM3,SM2}, calculate SK i =h(n1||n”3||R”) i ||SID j ) and SM”2=h(SK i ‖n1‖n”3); Then, U i Compare whether SM"2 is equal to SM2; if they are not equal, U i Terminate authentication and initiate a trust vote; after the vote, U i Call calculateReputation(FID) k ) Statistical results, perform corresponding operations; if equal, U i calculate renew

[0043] After the above steps are performed, the user can communicate with the sensor, but continuous authentication is still required during the communication process.

[0044] Furthermore, the continuous authentication preparation phase involves generating a token and channel fingerprint for formal continuous authentication, with the following specific steps:

[0045] Step 1.U i Generate a random number N1, and calculate Token = h(N1‖SK). and UP2 = h(Token‖SID) j Then, U i Transmit {UP1,UP2} to S j ;

[0046] Step 2.S j After receiving {UP1,UP2}, calculate the channel fingerprint CF. s , And Token' = h(N'1‖SK) and UP'2 = h(Token'‖SID) j Then, S j Check if UP'2 and UP2 are equal; if not, terminate the session; otherwise, S j Generate a random number N2, and calculate Token1 = h(Token'‖N'1‖N2). And SP2 = h(N'1‖N2‖Token1), update Token to Token1; finally, S j Send {SP1,SP2} to U i ;

[0047] Step 3.U i After receiving {SP1,SP2}, calculate the channel fingerprint CF. u , Token1 = h(Token‖N1‖N'2) and SP'2 = h(N1‖N'2‖Token1); then, U i Check if SP'2 and SP2 are equal; if not, U i Terminate the session; otherwise, U i Update Token = Token1.

[0048] Furthermore, in the continuous authentication phase: the user and the sensor perform continuous authentication at certain time intervals, and the steps of the i-th continuous authentication are as follows:

[0049] Step 1.U i Generate random number r u ,calculate and UC2=h(r u ‖Token i Then send {UC1,UC2} to S. j ;

[0050] Step 2.S j After receiving {UC1,UC2}, calculate the current channel fingerprint CF'. s S j Validation | CF' s -CF s |<ΔCF holds true; if not, S j Terminate the session; otherwise, S j calculate and UC'2=h(r' u ‖Token i Then, S j Check if UC'2 and UC2 are equal; if not, S j Terminate the session; otherwise, S j Generate random number r s ,calculate and SC2=h(r' u ||r s ‖Token i+1 Finally, S j Update Token i For Token i+1 And transmit {SC1,SC2} to U i ;

[0051] Step 3.U i After receiving {SC1,SC2}, calculate the current channel fingerprint CF'. u U i Validation | CF' u -CF u |<ΔCF holds true; if not, U i Terminate the session; otherwise, U i calculate and SC'2=h(r u ||r' s ‖Token i+1 Then, U i Check if SC'2 and SC2 are equal; if not, U i Terminate the session; otherwise, U i Update Token i For Token i+1 In T c Then begin the next continuous certification process.

[0052] Furthermore, in the password retrieval stage: the user retrieves the password through the following steps:

[0053] Step 1.U iEnter UID i and B' i Calculate σ' i =Rep(B' i ,τ), RID i =h(UID') i ‖σ' i Then, U i RID i Send to RC;

[0054] Step 2. RC receives RID i Then, call getUserByRID(RID) i Get List p Then, RC will list p Transmitted to U i ;

[0055] Step 3.U i Received List p Then, answer the List. p The problem is to obtain List' a Then, calculate If h(V') R ) and h(V R ), U i Password recovery Then, give U i Provide new password recovery questions U i Set a new answer calculate and make Finally, Transmitted to RC;

[0056] Step 4. RC received Then, call updateUserByRID(RID) i ), Update List p for

[0057] Furthermore, in the cross-domain authentication phase: the user authenticates with sensors in other domains through the following steps:

[0058] Step 1.U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τ i ), and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Continue with the following steps; U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i =h(r'2‖UID') i ), and UM2=h(n1||TID) i ||UK'1‖T1‖A per After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per} Transmitted to

[0059] Step 2. Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F k Call getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i The corresponding HID i Then, F k calculate and UM'2=h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; generate calculate and Then, Will Transmit to

[0060] Step 3. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'2 and FC2 are equal; if they are equal, F k Call getSensor(SID) j If SID' j F does not exist. k Terminate authentication, otherwise F k Get the corresponding C j and R j ;Then, Generate random number n2 and a new challenge calculate and at last, Will Transmitted to SID' j The corresponding S j ;

[0061] Step 4.S j Received Then, calculate R' j =PUF(C j ), and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n”1‖n3‖R' j ||SID j ) and SM2 = h(SK j ‖n”1‖n3); Finally, S j Transmit {SM1,SM2} to F k ;

[0062] Step 5. After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID' j ) and SM'2 = h(SK k ||n'1||n'3); then, Compare whether SM'2 is equal to SM2; if they are not equal, Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID'). j ) Analyze the statistical results and perform the corresponding operations; if they are equal, Call renew generate calculate and Then, Will Transmit to

[0063] Step 6. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'4 and FC4 are equal; if they are equal, calculate and After the calculation is completed, Call renew And transmit {FM3,SM2} to U i ;

[0064] Step 7.U i After receiving {FM3,SM2}, calculate SK i =h(n1||n”3||R”) i ||SID j ) and SM”2=h(SK i ‖n1‖n”3); Then, U i Compare whether SM"2 is equal to SM2; if they are not equal, U i Terminate authentication and initiate a trust vote; after the vote, Ui Call calculateReputation(FID) k ) Statistical results, perform corresponding operations; if equal, U i calculate and renew

[0065] Another objective of this invention is to provide a blockchain-based zero-trust medical IoT authentication system comprising:

[0066] The initialization module is used by the registry center to generate the necessary parameters for the system, build the blockchain, and deploy smart contracts.

[0067] The registration module is used by the registration center to register the identities of fog nodes, remote users, and sensors.

[0068] The static authentication module is used to complete mutual authentication between users, fog nodes, and sensors, and negotiate a session key;

[0069] The continuous authentication preparation module is used by the user and the sensor to generate tokens and channel fingerprints respectively, which are used in the formal continuous authentication phase.

[0070] The continuous authentication module is used to repeat the process at certain time intervals, with users and sensors authenticating each other using channel fingerprints and tokens.

[0071] The password recovery module allows users to recover their passwords by answering password recovery questions.

[0072] The cross-domain authentication module is used for users to authenticate sensors in other domains.

[0073] Another object of the present invention is to provide a computer device including a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method.

[0074] Another object of the present invention is to provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method.

[0075] Another objective of this invention is to provide an information data processing terminal for implementing the blockchain-based zero-trust medical IoT authentication system.

[0076] Based on the above technical solutions and the technical problems solved, please analyze the advantages and positive effects of the technical solution to be protected by this invention from the following aspects:

[0077] First, this invention employs a zero-trust security architecture, introducing continuous authentication on top of traditional single authentication. It categorizes user-requested permissions into different levels and sets corresponding continuous authentication intervals based on these levels, effectively addressing the over-trust problem in existing technologies. This invention constructs a private blockchain for data storage between the cloud, registration center, and fog nodes, and deploys related smart contracts. When one fog node fails, other fog nodes can still obtain relevant data through smart contracts to provide authentication services, effectively solving the single point of failure problem in existing technologies. This invention introduces fog computing on top of the cloud to provide services, meeting the requirements of the medical IoT for storage, computing, and low latency. This invention does not use complex asymmetric encryption during the authentication process and, through key updates and authentication process design, can resist most known attacks, making it more lightweight and secure compared to existing technologies. This invention achieves cross-domain authentication through authentication between different fog nodes, password recovery through password retrieval questions, and node revocation through a consortium blockchain for reputation management built among all members, providing more services compared to existing technologies. The specific working principle of this invention is as follows: The first stage is the system initialization stage, where the registration center sets system parameters, builds the blockchain, and deploys smart contracts. The second stage is the registration stage, where users, sensors, and fog nodes register their identities with the registration center and store relevant information on a private blockchain. The third stage is the static authentication stage, where users and sensors authenticate their identities with the help of fog nodes and negotiate a session key. The fourth stage is the continuous authentication preparation stage, where users and sensors calculate channel fingerprints and generate identity tokens based on the session key generated from static authentication. The fifth stage is the formal continuous authentication stage, where users and sensors use the channel fingerprint and identity token to repeatedly perform identity authentication at certain time intervals. In addition to the above five stages, this invention also includes a password retrieval stage and a cross-domain authentication stage for user convenience.

[0078] Secondly, the expected benefits and commercial value of the technical solution of this invention after its transformation are as follows: The Medical Internet of Things (IoT) enables interconnection and interoperability between medical devices and medical information through networks, unifying the management of medical images, electronic medical records, and medical data. This technology can effectively integrate medical resources, lower the threshold for medical services, and provide a variety of services, including real-time monitoring, remote diagnosis, and remote surgery. Therefore, the Medical IoT is considered a major development stage of IoT technology in the medical field, which will completely revolutionize the medical service model and drive the future medical system towards an unprecedented level of intelligence. It is predicted that the Medical IoT will create broad technological market opportunities in multiple medical application areas, covering technologies such as remote medical monitoring, surgical robot-assisted surgery, and health monitoring by smart wearable devices, aiming to solve complex problems in the field of human health. These applications will significantly improve the quality and efficiency of medical services, reduce medical costs, and bring patients a more personalized and precise medical experience. This invention mainly focuses on protecting the secure communication of the Medical IoT, which is one of the core conditions for the successful implementation of the Medical IoT. Therefore, the technical solution of this invention will generate huge expected benefits and commercial value after its transformation. Attached Figure Description

[0079] Figure 1 This is a flowchart of a blockchain-based zero-trust medical IoT authentication method provided in an embodiment of the present invention.

[0080] Figure 2 This is a block diagram of a blockchain-based zero-trust medical IoT authentication system provided in an embodiment of the present invention.

[0081] Figure 3 This is a system architecture diagram of the medical Internet of Things provided in the embodiments of the present invention.

[0082] Figure 4 This is an authentication architecture diagram of the system provided in the embodiments of the present invention.

[0083] Figure 5 This is a flowchart of the authentication process for users, fog nodes, and sensors provided in an embodiment of the present invention. Detailed Implementation

[0084] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0085] like Figure 1 As shown in the figure, the blockchain-based zero-trust medical IoT authentication method provided by this invention includes the following steps:

[0086] S101, the initialization phase, in which the registry center generates the necessary parameters for the system, builds the blockchain and deploys smart contracts;

[0087] S102, during the registration phase, the registration center registers fog nodes, remote users, and sensors;

[0088] S103, the static authentication phase completes the mutual authentication between the user, fog node and sensor, and negotiates a session key;

[0089] S104, Continuous authentication preparation phase: Users and sensors generate tokens and channel fingerprints respectively for the formal continuous authentication phase.

[0090] S105, the continuous authentication phase is repeated at certain time intervals, and users and sensors use channel fingerprints and tokens to authenticate each other.

[0091] S106, The password recovery stage is when the user recovers the password by answering password recovery questions;

[0092] S107, the cross-domain authentication phase, is when a user authenticates sensors from other domains.

[0093] The initialization stage provided in this embodiment of the invention:

[0094] The RC selects the master key MK; then, the RC constructs the blockchain and deploys smart contracts for data storage, data retrieval, data updates, and reputation management.

[0095] Registration phase:

[0096] Fog node registration: Fog nodes register with the registration center. The registration steps are as follows:

[0097] Step 1.F k Select Identity ID (FID) k Then FID k Transmitted to the Registry Center (RC);

[0098] Step 2. After receiving the message, RC generates a random number r1 and calculates FK. k =h(r1‖MK) and FIC k =h(FID) k ‖FK k Then, RC calls the smart contract storeFogNode(FK); k FIC k Store {FID} in the data chain k FIC k Finally, RC will FK k Send to F k ;

[0099] Step 3. Receive FK k After that, F k Store {FID k FK k};

[0100] User registration: Users register with the registration center. The registration steps are as follows:

[0101] Step 1.U i Select Identity ID (UID) i Password PW i Input biological information B i Then, MD i Generate a random number r2 and a list of password recovery questions. p ={p1,p2,…,p n}, U i Set List p List of corresponding answers a ={a1,a2,…,a n}; After completion, MD i calculate (σ i ,τ i ) = Gen(B i ), PID i =h(r2‖UID) i ), PW * =h(r2‖PW i ||UID i ) and RID i =h(UID) i ‖σ i Finally, MD i PID i PW * RID i List p Transmitted to RC;

[0102] Step 2. RC receives U i After obtaining the registration information, a random number r3 is generated, and the UK is calculated. i =h(r3‖MK), and Then, RC calls storeUser(TID) i HID i List p RID i Stored in the blockchain And transmit {UR} to U i ;

[0103] Step 3.U i After receiving the UR, calculate L3=h(PW i ‖σ i ||r2||UID i )and Then, MD i Store {L1,L2,L3,L4,h(V)} R ),τ i};

[0104] Sensor registration: Sensors also need to be registered with the registration center. The registration steps are as follows:

[0105] Step 1.S j Select Identity ID (SID) j Then SID j Transmitted to RC;

[0106] Step 2. RC receives SID j Then, choose to challenge C. j Then, RC will C j Send to S j ;

[0107] Step 3.S j Received C j Calculate R j =PUF(C j Then, S j R j Send to RC;

[0108] Step 4. RC receives R j Then, call storeSensor(SID) j ,C j ,R j ), storing {SID} in the blockchain j ,C j ,R j};

[0109] Static authentication phase:

[0110] Users first need to log in using their mobile devices. After successful login, the user and the sensor authenticate each other.

[0111] Login: U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τi ), and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Proceed to the next steps.

[0112] Mutual authentication: After successful user login, mutual authentication is performed with the sensor. The authentication steps are as follows:

[0113] Step 1.U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i =h(r'2‖UID') i ), and UM2=h(n1||TID) i ||UK'1‖T1‖A per After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per} Transmitted to F k ;

[0114] Step 2.F k Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F k Call getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i The corresponding HID i Then, F k calculate and UM'2=h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F kTerminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; F k Call getSensor(SID) j If SID' j F does not exist. k Terminate authentication, otherwise F k Get the corresponding C j and R j Then, F k Generate random number n2 and a new challenge calculate and Finally, F k Will Transmitted to SID' j The corresponding S j ;

[0115] Step 3.S j Received Then, calculate R' j =PUF(C j ), and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n”1‖n3‖R' j ||SID j ) and SM2 = h(SK j ‖n”1‖n3); Finally, S j Transmit {SM1,SM2} to F k ;

[0116] Step 4.F k After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID' j ) and SM'2 = h(SK k ||n'1||n'3); then, F kCompare whether SM'2 is equal to SM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID'). j ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k Call renew and F k calculate and After the calculation is completed, F k Call renew And transmit {FM3,SM2} to U i ;

[0117] Step 5.U i After receiving {FM3,SM2}, calculate SK i =h(n1‖n”3||R”) i ||SID j ) and SM”2=h(SK i ‖n1‖n”3); Then, U i Compare whether SM"2 is equal to SM2; if they are not equal, U i Terminate authentication and initiate a trust vote; after the vote, U i Call calculateReputation(FID) k ) Statistical results, perform corresponding operations; if equal, U i calculate and renew

[0118] After the above steps are performed, the user can communicate with the sensor, but continuous authentication is still required during the communication process.

[0119] The continuous authentication preparation stage provided in this embodiment of the invention involves generating a token and channel fingerprint for formal continuous authentication. The specific steps are as follows:

[0120] Step 1.U i Generate a random number N1, and calculate Token = h(N1‖SK). and UP2 = h(Token‖SID) j Then, U i Transmit {UP1,UP2} to S j ;

[0121] Step 2.S jAfter receiving {UP1,UP2}, calculate the channel fingerprint CF. s , And Token' = h(N'1‖SK) and UP'2 = h(Token'‖SID) j Then, S j Check if UP'2 and UP2 are equal; if not, terminate the session; otherwise, S j Generate a random number N2, and calculate Token1 = h(Token'‖N'1‖N2). And SP2 = h(N'1‖N2‖Token1), update Token to Token1; finally, S j Send {SP1,SP2} to U i ;

[0122] Step 3.U i After receiving {SP1,SP2}, calculate the channel fingerprint CF. u , Token1 = h(Token‖N1‖N'2) and SP'2 = h(N1‖N'2‖Token1); then, U i Check if SP'2 and SP2 are equal; if not, U i Terminate the session; otherwise, U i Update Token = Token1.

[0123] The continuous authentication phase provided in this embodiment of the invention involves the user and the sensor performing continuous authentication at certain time intervals. The steps for the i-th continuous authentication are as follows:

[0124] Step 1.U i Generate random number r u ,calculate and UC2=h(r u ‖Token i Then send {UC1,UC2} to S. j ;

[0125] Step 2.S j After receiving {UC1,UC2}, calculate the current channel fingerprint CF'. s S j Validation | CF' s -CF s |<ΔCF holds true; if not, S j Terminate the session; otherwise, S j calculate and UC'2=h(r' u ‖Token i Then, Sj Check if UC'2 and UC2 are equal; if not, S j Terminate the session; otherwise, S j Generate random number r s ,calculate and SC2=h(r' u ||r s ‖Token i+1 Finally, S j Update Token i For Token i+1 And transmit {SC1,SC2} to U i ;

[0126] Step 3.U i After receiving {SC1,SC2}, calculate the current channel fingerprint CF'. u U i Validation | CF' u -CF u |<ΔCF holds true; if not, U i Terminate the session; otherwise, U i calculate and SC'2=h(r u ||r' s ‖Token i+1 Then, U i Check if SC'2 and SC2 are equal; if not, U i Terminate the session; otherwise, U i Update Token i For Token i+1 In T c Then begin the next continuous certification process.

[0127] The password retrieval stage provided in this embodiment of the invention: Users retrieve their passwords through the following steps:

[0128] Step 1.U i Enter UID i and B' i Calculate σ' i =Rep(B' i ,τ), RID i =h(UID') i ‖σ' i Then, U i RID i Send to RC;

[0129] Step 2. RC receives RID i Then, call getUserByRID(RID)i Get List p Then, RC will list p Transmitted to U i ;

[0130] Step 3.U i Received List p Then, answer the List. p The problem is to obtain List' a Then, calculate If h(V') R ) and h(V R ), U i Password recovery Then, give U i Provide new password recovery questions U i Set a new answer calculate and make Finally, Transmitted to RC;

[0131] Step 4. RC received Then, call updateUserByRID(RID) i ), Update List p for

[0132] The cross-domain authentication stage provided in this embodiment of the invention involves the user authenticating with sensors in other domains through the following steps:

[0133] Step 1.U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τ i ), and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Continue with the following steps; U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i=h(r'2‖UID') i ), and UM2=h(n1||TID) i ||UK'1‖T1‖A per After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per} Transmitted to

[0134] Step 2. Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F k Call getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i The corresponding HID i Then, F k calculate and UM'2=h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; generate calculate and Then, Will Transmit to

[0135] Step 3. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'2 and FC2 are equal; if they are equal, F k Call getSensor(SID) j If SID' j F does not exist. k Terminate authentication, otherwise F k Get the corresponding C j and R j ;Then, Generate random number n2 and a new challenge calculate and at last, Will Transmitted to SID' j The corresponding S j ;

[0136] Step 4.S j Received Then, calculate R' j =PUF(C j ), and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n”1‖n3‖R' j ||SID j ) and SM2 = h(SK j ‖n”1‖n3); Finally, S j Transmit {SM1,SM2} to F k ;

[0137] Step 5. After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID' j ) and SM'2 = h(SK k ||n'1||n'3); then, Compare whether SM'2 is equal to SM2; if they are not equal, Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID'). j ) Analyze the statistical results and perform the corresponding operations; if they are equal, Call renew and generate calculate and Then, Will Transmit to

[0138] Step 6. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'4 and FC4 are equal; if they are equal, calculate and After the calculation is completed, Call renew And transmit {FM3,SM2} to U i ;

[0139] Step 7.U i After receiving {FM3,SM2}, calculate SK i =h(n1||n”3||R”) i ||SID j ) and SM”2=h(SK i ‖n1‖n”3); Then, U i Compare whether SM"2 is equal to SM2; if they are not equal, U i Terminate authentication and initiate a trust vote; after the vote, U i Call calculateReputation(FID) k ) Statistical results, perform corresponding operations; if equal, U i calculate and renew

[0140] like Figure 2 As shown in the figure, an embodiment of the present invention provides a blockchain-based zero-trust medical IoT authentication system, comprising:

[0141] The initialization module is used by the registry center to generate the necessary parameters for the system, build the blockchain, and deploy smart contracts.

[0142] The registration module is used by the registration center to register fog nodes, remote users, and sensors.

[0143] The static authentication module is used to complete mutual authentication between users, fog nodes, and sensors, and negotiate a session key;

[0144] The continuous authentication preparation module is used by the user and the sensor to generate tokens and channel fingerprints respectively, which are used in the formal continuous authentication phase.

[0145] The continuous authentication module is used to repeat the process at certain time intervals, with users and sensors authenticating each other using channel fingerprints and tokens.

[0146] The password recovery module allows users to recover their passwords by answering password recovery questions.

[0147] The cross-domain authentication module is used for users to authenticate sensors in other domains.

[0148] Another object of the present invention is to provide a computer device including a memory and a processor, the memory storing a computer program, which, when executed by the processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method.

[0149] Another object of the present invention is to provide a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method.

[0150] Another objective of this invention is to provide an information data processing terminal for implementing the blockchain-based zero-trust medical IoT authentication system.

[0151] 1. The system structure of this patent and the relationships between them:

[0152] The system of this patent includes 6 physical modules:

[0153] Cloud: The cloud has ample computing and storage resources, is responsible for long-term storage and in-depth analysis of data in the system, and is considered completely trustworthy.

[0154] Registry Center: The registry center is a fully trusted institution responsible for system initialization, such as setting necessary system parameters, building the blockchain, and deploying smart contracts. In addition, the registry center needs to provide registration services for users, sensors, and fog nodes, and store relevant data in the blockchain.

[0155] Fog Nodes: The system contains multiple fog nodes, which are primarily responsible for static authentication between users and sensors, and monitoring user behavior and network traffic during user operations. In addition to providing authentication services within their own network, fog nodes also provide cross-domain authentication services.

[0156] Users: Users are typically medical professionals such as doctors. In the MIoT system, doctors can view patients' physiological data, environmental information, and various examination reports anytime, anywhere through multiple network devices, enabling them to diagnose and design treatment plans. However, before performing these operations, doctors need to apply for permissions, complete static authentication to obtain authorization, and then undergo continuous authentication during the operation.

[0157] Sensors: MIoT systems utilize a variety of sensors, primarily including implantable sensors, wearable sensors, and environmental sensors. These sensors collect data related to user health, provide the data to the user after static authentication, and continuously authenticate the user during operation.

[0158] Blockchain: Two types of blockchains are constructed in the system. One is a private blockchain built between the cloud, the registry center, and fog nodes, which is used for data storage. The other is a consortium blockchain built among all members, which is used to manage the reputation information of all members.

[0159] Figure 3 Structure diagram of the Internet of Things in healthcare.

[0160] The working principle of this patent:

[0161] This patent primarily enables secure communication between remote users and sensors. Its working principle is as follows: The first stage is the system initialization stage, where the registration center generates necessary system parameters, builds the blockchain, and deploys smart contracts. The second stage is the registration stage, where fog nodes, remote users, and sensors register with the registration center. The third stage is the static authentication stage, where remote users, fog nodes, and sensors authenticate each other. After successful authentication, they negotiate a session key for communication. After successful registration, remote users store their registration information on their mobile devices. To perform a series of operations, users need to log in by entering their identity identifier, password, and fingerprint information on their mobile devices. After successful login, they send an authentication request to the fog node and complete mutual authentication. Upon successful verification, a session key is generated that is unique to the user, fog node, and sensor. The fourth stage is the preparation stage for continuous authentication, where users and sensors generate the same communication token using the session key and calculate the communication channel fingerprint. The fifth stage is the formal continuous authentication stage, where identity authentication is performed based on the communication token and channel fingerprint. The token is updated after each authentication and is repeatedly executed at regular time intervals throughout the user's operation. The sixth stage is the password recovery stage, where users recover their passwords using pre-set password recovery questions. The seventh stage is the cross-domain authentication stage, where users and sensors in different domains complete authentication with the help of fog nodes in their respective domains.

[0162] Its authentication architecture diagram is as follows Figure 4 As shown, the flowchart is as follows Figure 5 As shown, the detailed implementation process is as follows.

[0163] Figure 5 In the middle: ① When a user logs in using a mobile device, a static authentication request is sent to the fog node.

[0164] ② Fog node authenticated users, after successful authentication, initiate a static authentication request to the sensor.

[0165] ③ The sensor authenticates the fog node. After successful authentication, a session key is generated, and a static authentication request is sent to the fog node.

[0166] ④ The fog node authenticates the sensor. After successful authentication, a session key is generated, and a static authentication request is sent to the user.

[0167] ⑤ The user authenticates the fog node. After successful authentication, a session key is generated, a token is generated, and a continuous authentication preparation request is sent to the sensor.

[0168] ⑥ The sensor calculates the channel fingerprint, verifies message freshness, and authenticates the user. After successful authentication, the token is updated, and a continuous authentication preparation request is sent to the user.

[0169] ⑦ The user calculates the channel fingerprint, verifies message freshness, and authenticates the sensor. Upon successful authentication, the token is updated, and a continuous authentication request is initiated to the sensor.

[0170] ⑧ The sensor verifies message freshness and channel fingerprint to authenticate the user. After successful authentication, the token is updated, and a continuous authentication request is sent to the user.

[0171] 9. The user verifies message freshness and channel fingerprint, and authenticates the sensor. After successful authentication, the token is updated, and the user waits for the next continuous authentication.

[0172] 2. This patent achieves this objective through the following technical solution:

[0173] To achieve this objective, the technical solution of this invention includes an initialization phase, a registration phase, a static authentication phase, a continuous authentication preparation phase, a continuous authentication phase, a password retrieval phase, and a cross-domain authentication phase. In the initialization phase, the registration center generates the necessary system parameters, builds the blockchain, and deploys smart contracts. In the registration phase, the registration center registers fog nodes, remote users, and sensors. The static authentication phase completes mutual authentication between users, fog nodes, and sensors, and negotiates a session key. In the continuous authentication preparation phase, users and sensors generate tokens and channel fingerprints respectively, for use in the formal continuous authentication phase. The continuous authentication phase is repeated at certain time intervals, with users and sensors authenticating each other using channel fingerprints and tokens. In the password retrieval phase, users recover their passwords by answering password retrieval questions. The cross-domain authentication phase involves users authenticating with sensors from other domains.

[0174] The technical solution of this invention can be applied to medical IoT systems to effectively ensure communication security. The most typical application scenario is remote diagnosis. Through this system, doctors can view patients' physical data and examination reports, and, combined with remote video consultations, provide diagnostic results and formulate treatment plans. Remote diagnosis not only greatly benefits patients in other locations but also significantly shortens diagnosis time and reduces diagnostic costs. However, if the security of the medical IoT system is not effectively guaranteed, leading to data tampering within the system, doctors may make incorrect diagnoses, thereby posing a serious threat to the patient's life.

[0175] In terms of security, this invention can resist various known attacks, mainly including:

[0176] It resists man-in-the-middle attacks, impersonation attacks, replay attacks, privileged insider attacks, transient secret disclosure attacks, physical capture attacks, smart card theft attacks, offline password guessing attacks, desynchronization attacks, single points of failure, session hijacking attacks, and more. It also achieves user anonymity, untraceability, forward security, and zero-trust features.

[0177] Regarding communication costs, this invention requires relatively low costs. We assume that the identity identifier, PUF challenge, PUF response, auxiliary fields generated by the fuzzy extractor generation function, and key are 128 bits; the user password, system key, random number, hash output, and chaotic map output are 256 bits; the points on the elliptic curve are 512 bits; the timestamp is 64 bits; and the privilege identifier requested by the user is 8 bits. This invention requires the transmission of 4 messages, totaling 2120 bits. In other similar communication systems, the system invented by Soleymani et al. requires 5952 bits, the system invented by Miao et al. requires 2752 bits, and the system invented by Kosalya et al. requires 2752 bits.

[0178] In terms of computational cost, this invention has a significant advantage. To facilitate comparison of the computational costs of different systems, let T... h T puf T ecc T fr T D T cf and T cm These represent the time consumed by hashing, PUF response generation, elliptic curve scalar multiplication, the fuzzy extractor's reproducibility algorithm, symmetric decryption, channel fingerprint calculation, and chaotic mapping, respectively. The experimental measurement used is: T. h ≈0.00052ms, T puf ≈0.00052ms, T ecc ≈0.246ms, T fr ≈0.249ms, T D ≈0.0026ms, T cf ≈0.00052ms, T cm The computational cost required by this invention is approximately 0.195ms. In comparison, the lightweight system by Soleymani et al. requires 2.26496ms, the lightweight system by Miao et al. requires 1.822ms, and the lightweight system by Kousalya et al. requires 0.754ms.

[0179] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0180] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A blockchain-based zero-trust medical IoT authentication method, characterized in that, Includes the following steps: Step 1, the initialization phase, involves the registry center generating the necessary parameters for the system, building the blockchain, and deploying smart contracts; Step 2, the registration phase, involves the registration center registering fog nodes, remote users, and sensors; Step 3, the static authentication phase completes the mutual authentication between the user, fog node and sensor, and negotiates a session key; Step 4, Continuous Authentication Preparation Phase: Users and sensors generate tokens and channel fingerprints respectively for the formal continuous authentication phase. Step 5, the continuous authentication phase, is repeated at certain time intervals, where users and sensors authenticate each other using channel fingerprints and tokens. Step 6, the password retrieval stage, is where users recover their passwords by answering password retrieval questions; Step 7, the cross-domain authentication phase, involves the user authenticating with sensors from other domains.

2. The blockchain-based zero-trust medical IoT authentication method as described in claim 1, characterized in that, The initialization phase: The Registry Center (RC) selects the master key MK; then, the RC constructs the blockchain and deploys smart contracts related to data storage, data retrieval, data updates, and reputation management. Registration phase: Fog node registration: Fog nodes register with the registration center. The registration steps are as follows: Step 1. Fog Node F k Select Identity ID (FID) k Then FID k Transmitted to the Registry Center (RC); Step 2. After receiving the message, RC generates a random number r1 and calculates FK. k =h(r1‖MK) and FIC k =h(FID) k ‖FK k Then, RC calls the smart contract storeFogNode(FK); k FIC k Store {FID} in the data chain k FIC k Finally, RC will FK k Send to F k ; Step 3. Receive FK k After that, F k Store {FID k FK k }; User registration: Users register with the registration center. The registration steps are as follows: Step 1. User U i Select Identity ID (UID) i Password PW i Input biological information B i Then, MD i Generate a random number r2 and a list of password recovery questions. p ={p1,p2,…,p n }, U i Set List p List of corresponding answers a ={a1,a2,…,a n }; After completion, MD i Calculate V R =h(a1)⊕h(a2)⊕…⊕h(a n ), (σ i ,τ i ) = Gen(B i ), PID i =h(r2‖UID) i ), PW * =h(r2‖PW i ||UID i ) and RID i =h(UID) i ‖σ i Finally, MD i {PID i PW * RID i List p Transmitted to RC; Step 2. RC receives U i After obtaining the registration information, a random number r3 is generated, and the UK is calculated. i =h(r3‖MK), HID i =PID i ⊕r3, TID i =HID i ⊕UK i and UR=PW * ⊕(UK i ||r3); Then, RC calls storeUser(TID) i HID i List p RID i Stored in the blockchain And transmit {UR} to U i ; Step 3.U i After receiving the UR, calculate L1=(r2‖r3)⊕h(PW i ‖σ i L2 = UK i ⊕h(PW i ‖σ i ||r2), L3=h(PW i ‖σ i ||r2||UID i ) and L4=PW i ⊕σ i ⊕V R Then, MD i Store {L1,L2,L3,L4,h(V)} R ),τ i }; Sensor registration: Sensors also need to be registered with the registration center. The registration steps are as follows: Step 1. Sensor S j Select Identity ID (SID) j Then SID j Transmitted to RC; Step 2. RC receives SID j Then, choose to challenge C. j Then, RC will C j Send to S j ; Step 3.S j Received C j Calculate R j =PUF(C j Then, S j R j Send to RC; Step 4. RC receives R j Then, call storeSensor(SID) j C j ,R j ), storing {SID} in the blockchain j C j ,R j }; Static authentication phase: Users first need to log in using their mobile devices. After successful login, the user and the sensor authenticate each other. Login: U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τ i ), (r'2‖r'3)=L1⊕h(PW' i ‖σ' i ) and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Proceed to the next steps. Mutual authentication: After successful user login, mutual authentication is performed with the sensor. The authentication steps are as follows: Step 1.U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i =h(r′2‖UID′) i ), UK' i =L2⊕h(PW′) i ||σ′ i ||r′2), HID′ i =PID′ i ⊕r′3,TID i =HID′ i ⊕UK′ i UM1 = (n1 || SID) j )⊕h(TID i ||UK' i ) and UM2 = h(n1||TID i ||UK'1‖T1‖A per ); After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per } Transmitted to F k ; Step 2.F k Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F k Call getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i Corresponding HID″ i Then, F k Calculate UK″ i =TID i ⊕HID″ i ,(n'1‖SID j ')=UM1⊕h(TID i ||UK″ i ) and UM'2 = h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; F k Call getSensor(SID) j '); If SID j 'Does not exist, F' k Terminate authentication, otherwise F k Get the corresponding C j and R j Then, F k Generate random number n2 and a new challenge Calculate FM1 = (n'1 || n2) ⊕ h(SID) j '‖R j )and Finally, F k Will Transmitted to SID j 'Corresponding S j ; Step 3.S j Received Then, calculate R. j =PUF(C j ), (n″1‖n'2)=FM1⊕h(SID j ‖R j ')and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n″1‖n3‖R) j '‖SID j ) and SM2 = h(SK j ‖n″1‖n3); Finally, S j Transmit {SM1,SM2} to F k ; Step 4.F k After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID j ') and SM'2 = h(SK k ||n'1||n'3); then, F k Compare whether SM'2 is equal to SM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID). j ') Statistical results, perform corresponding operations; if equal, F k Call renew and F k Calculate FM3 = (R j ||n'3)⊕h(n'1|UK″ i ), and After the calculation is completed, F k Call renew And transmit {FM3,SM2} to U i ; Step 5.U i After receiving {FM3,SM2}, calculate (R″) i ||n″3)=FM3⊕h(n1‖UK' i ), SK i =h(n1‖n″3‖R″) i ||SID j ) and SM″2=h(SK i ‖n1‖n″3); Then, U i Compare whether SM″2 is equal to SM2; if not, U i Terminate authentication and initiate a trust vote; after the vote, U i Call calculateReputation(FID) k ) Analyze the statistical results and perform the corresponding operation; if they are equal, U i calculate and renew After the above steps are performed, the user can communicate with the sensor, but continuous authentication is still required during the communication process.

3. The blockchain-based zero-trust medical IoT authentication method as described in claim 2, characterized in that, The continuous authentication preparation phase involves generating a token and channel fingerprint for formal continuous authentication, with the following specific steps: Step 1.U i Generate a random number N1, calculate Token = h(N1‖SK), UP1 = N1⊕SK, and UP2 = h(Token‖SID). j Then, U i Transmit {UP1,UP2} to S j ; Step 2.S j After receiving {UP1,UP2}, calculate the channel fingerprint CF. s N'1 = UP1⊕SK and Token' = h(N'1‖SK) and UP'2 = h(Token'‖SID) j Then, S j Check if UP'2 and UP2 are equal; if not, terminate the session; otherwise, S j Generate a random number N2, calculate Token1 = h(Token'‖N'1‖N2), SP1 = N2⊕Token' and SP2 = h(N'1‖N2‖Token1), update Token to Token1; finally, S j Send {SP1,SP2} to U i ; Step 3.U i After receiving {SP1,SP2}, calculate the channel fingerprint CF. u N'2 = SP1 ⊕ Token, Token1 = h(Token‖N1‖N'2) and SP'2 = h(N1‖N'2‖Token1); then, U i Check if SP'2 and SP2 are equal; if not, U i Terminate the session; otherwise, U i Update Token = Token1.

4. The blockchain-based zero-trust medical IoT authentication method as described in claim 3, characterized in that, The continuous authentication phase involves the user and sensor performing continuous authentication at regular time intervals. The steps for the i-th continuous authentication are as follows: Step 1.U i Generate random number r u Calculate UC1 = r u ⊕Token i and UC2=h(r u Token i Then send {UC1,UC2} to S; j ; Step 2.S j After receiving {UC1,UC2}, calculate the current channel fingerprint CF'. s S j Validation | CF' s -CF s |<ΔCF holds true; if not, S j Terminate the session; otherwise, S j Calculate r' u =UC1⊕Token i and UC'2=h(r' u Token i Then, S j Check if UC'2 and UC2 are equal; if not, S j Terminate the session; otherwise, S j Generate random number r s Calculate Token i+1 =Token i ⊕r' u ⊕r s SC1 = r s ⊕Token i and SC2=h(r' u ||r s Token i+1 Finally, S j Update Token i For Token i+1 And transmit {SC1,SC2} to U i ; Step 3.U i After receiving {SC1,SC2}, calculate the current channel fingerprint CF'. u ;U i Validation | CF' u -CF u |<ΔCF holds true; if not, U i Terminate the session; otherwise, U i Calculate r' s =SC1⊕Token i Token i+1 =Token i ⊕r u ⊕r' s and SC'2=h(r u ||r' s Token i+1 Then, U i Check if SC'2 and SC2 are equal; if not, U i Terminate the session; otherwise U i Update Token i For Token i+1 In T c Then begin the next continuous certification process.

5. The blockchain-based zero-trust medical IoT authentication method as described in claim 2, characterized in that, The password retrieval stage involves the user retrieving their password through the following steps: Step 1.U i Enter UID i and B' i Calculate σ' i =Rep(B' i ,τ), RID i =h(UID') i ‖σ' i Then, U i RID i Send to RC; Step 2. RC receives RID i Then, call getUserByRID(RID) i Get List p Then, RC will list p Transmitted to U i ; Step 3.U i Received List p Then, answer the List. p The problem is to obtain List' a Then, calculate V' R =h(a'1)⊕h(a'2)⊕…⊕h(a' n If h(V') R ) and h(V R ), U i Recover password PW' i =L4⊕V' R ⊕σ' i Then, give U i Provide new password recovery questions U i Set a new answer calculate and make Finally, Transmitted to RC; Step 4. RC received Then, call updateUserByRID(RID) i ), Update List p for 6. The blockchain-based zero-trust medical IoT authentication method as described in claim 2, characterized in that, The cross-domain authentication phase involves the user authenticating with sensors in other domains through the following steps: Step 1.U i Enter UID i , PW' i and B' i Calculate σ' i =Rep(B' i ,τ i ), (r'2‖r'3)=L1⊕h(PW' i ‖σ' i ) and L'3=h(PW' i ||σ'||r'2||UID' i Then, U i Determine whether the equation L'3 = L3 is true; if the equation is false, U i Login failed; otherwise, U i Login successful. Continue with the following steps; U i Generate a random number n1 and a timestamp T1, and select the requested permission A. per Then, U i Calculate PID' i =h(r'2‖UID') i ), UK' i =L2⊕h(PW' i ‖σ' i ||r'2), HID' i =PID' i ⊕r'3,TID i =HID' i ⊕UK' i UM1 = (n1 || SID) j )⊕h(TID i ||UK' i ) and UM2 = h(n1||TID i ||UK'1‖T1‖A per ); After the calculation is completed, U i {TID i ,UM1,UM2,T1,A per } Transmitted to Step 2. Received {TID i ,UM1,UM2,T1,A per After that, generate timestamp T2, and determine whether |T2-T1|<ΔT holds true; if not, F k Terminate certification; otherwise, F k Call getUserByTID(TID) i If TID i F does not exist. k Terminate certification; otherwise, F k Get with TID i Corresponding HID″ i Then, F k Calculate UK″ i =TID i ⊕HID″ i ,(n'1‖SID j ')=UM1⊕h(TID i ||UK″ i ) and UM'2 = h(n'1‖TID i ||UK' i ‖T1‖A per Compare UM'2 with UM2; if they are not equal, F k Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(TID). i ) Calculate the statistical results and perform the corresponding operation; if they are equal, F k According to A per Set the corresponding continuous authentication time interval; generate calculate and Then, Will Transmit to Step 3. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'2 and FC2 are equal; if they are equal, F k Call getSensor(SID) j '); If SID j 'Does not exist, F' k Terminate authentication, otherwise F k Get the corresponding C j and R j ;Then, Generate random number n2 and a new challenge Calculate FM1 = (n'1 || n2) ⊕ h(SID) j ' ‖R j )and at last, Will Transmitted to SID j 'Corresponding S j ; Step 4.S j Received Then, calculate R. j =PUF(C j ), (n″1‖n'2)=FM1⊕h(SID j ‖R j ')and Compare whether FM'2 is equal to FM2; if not, S j Terminate authentication and initiate a trust vote; after the vote, S j Call calculateReputation(FID) k ) Calculate the statistical results and perform the corresponding operation; if they are equal, S j Generate random number n3, calculate SK j =h(n″1‖n3‖R) j '‖SID j ) and SM2 = h(SK j ‖n″1‖n3); Finally, S j Transmit {SM1,SM2} to F k ; Step 5. After receiving {SM1,SM2}, calculate SK k =h(n'1‖n'3‖R) j ||SID j ') and SM'2 = h(SK k ||n'1||n'3); then, Compare whether SM'2 is equal to SM2; if they are not equal, Terminate authentication and initiate a trust vote; after the vote ends, call calculateReputation(SID). j ') Calculate the statistical results and perform the corresponding operation; if they are equal, Call renew and generate calculate and Then, Will Transmit to Step 6. generate judge Is it true? If it is true, Call get Then, calculate and Verify that FC'4 and FC4 are equal; if they are equal, Calculate FM3 = (R j ||n'3)⊕h(n'1|UK″ i ), and After the calculation is completed, Call renew And transmit {FM3,SM2} to U i ; Step 7.U i After receiving {FM3,SM2}, calculate (R″) i ||n″3)=FM3⊕h(n1‖UK' i ), SK i =h(n1‖n″3‖R″) i ||SID j ) and SM″2=h(SK i ‖n1‖n″3); Then, U i Compare whether SM″2 is equal to SM2; if not, U i Terminate authentication and initiate a trust vote; after the vote, U i Call calculateReputation(FID) k ) Analyze the statistical results and perform the corresponding operation; if they are equal, U i calculate and renew 7. A blockchain-based zero-trust medical IoT authentication system implementing the blockchain-based zero-trust medical IoT authentication method as described in any one of claims 1-6, characterized in that, The blockchain-based zero-trust medical IoT authentication system includes: The initialization module is used by the registry center to generate the necessary parameters for the system, build the blockchain, and deploy smart contracts. The registration module is used by the registration center to register fog nodes, remote users, and sensors. The static authentication module is used to complete mutual authentication between users, fog nodes, and sensors, and negotiate a session key; The continuous authentication preparation module is used by the user and the sensor to generate tokens and channel fingerprints respectively, which are used in the formal continuous authentication phase. The continuous authentication module is used to repeat the process at certain time intervals, with users and sensors authenticating each other using channel fingerprints and tokens. The password recovery module allows users to recover their passwords by answering password recovery questions. The cross-domain authentication module is used for users to authenticate sensors in other domains.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the blockchain-based zero-trust medical IoT authentication method as described in any one of claims 1-6.