Iot-oriented permission code multi-verification method and system

Abstract

The application is suitable for the field of Internet of Things security and access control, and provides a permission code multiple verification method and system for Internet of Things. The method generates a permission code containing permission content, a timestamp, a serial number and a message authentication code, and distributes a device fingerprint; a first integrity verification is completed through the device fingerprint, and a first confidence is output; timeliness and sequence freshness verification are completed through a dynamic time window and a counter, and a second confidence is output; a behavior baseline comparison is performed through a distributed consensus node cluster, and a third confidence is output; a conflict trust label is generated based on the three verification states, the confidences are corrected, and a final confidence is obtained by weighted summation, and a hierarchical decision is made according to a threshold. The application can improve the anti-cracking, anti-replay, abnormal identification and boundary state handling capabilities of the permission code on the resource-limited Internet of Things device.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security and access control technology, specifically to a multi-factor authentication method and system for IoT access codes. Background Technology

[0002] With the rapid development of IoT technology, numerous resource-constrained devices in smart homes, industrial sensing, and other scenarios provide data and services through open network interfaces. To ensure access security, these devices typically use access codes as authentication credentials. However, due to limitations in device computing power, storage space, and power consumption, it is difficult to deploy a complete public key infrastructure or robust encryption protocols. Access code verification often relies on simple symmetric encryption or fixed password verification. Some improved solutions have introduced device fingerprint binding or timestamp mechanisms to enhance security, but significant security vulnerabilities still exist overall.

[0003] The main shortcomings of existing technologies are as follows: First, the integrity protection of permission codes is insufficient. Once a single symmetric encryption or fixed password is leaked or brute-forced, attackers can directly forge legitimate requests; device fingerprint binding schemes only perform static comparisons and lack integrity protection against dynamic changes in permission codes, allowing attackers to tamper with the content of permission codes during transmission without being detected. Second, there is a lack of effective timeliness and freshness verification. Fixed validity period schemes cannot defend against replay attacks within the valid window, and intercepted legitimate permission codes can be used repeatedly within the validity period; schemes that introduce timestamps, if not combined with counters, cannot resist out-of-order replays within the window, and the clocks of resource-constrained devices may drift, leading to the false rejection of legitimate requests if relying solely on timestamps. Third, high-frequency abnormal access is difficult to identify. Existing verification usually only focuses on whether the permission code is correct, not whether the access behavior is normal, allowing attackers to use legitimate permission codes to launch high-frequency scans or batch control requests undetected; centralized behavior analysis suffers from single points of failure and performance bottlenecks. Fourth, some systems have attempted to introduce multiple verifications, but the verification steps are executed serially and use simple "AND" logic for hard judgment. If any step fails, the entire system is rejected, resulting in legitimate requests being mistakenly rejected due to momentary jitter. Behavioral baseline comparisons mostly use local single-point statistics, lacking distributed collaboration and having poor scalability.

[0004] Existing permission code verification schemes, when faced with inconsistent results from multiple verifications, often directly use the output of a single verification as a fixed confidence level in the fusion process, lacking differentiation between the sources of integrity failure, time window deviations, sequence backtracking, and consensus voting disagreements. Legitimate requests are prone to false rejection due to clock drift, network latency, or short-term disagreements among consensus nodes, while malicious requests can easily achieve inflated fusion results when some verifications pass. In resource-constrained scenarios with concurrent device access, the fixed fusion process struggles to constrain the sources of anomalies, and subsequent weight adjustments and behavior baseline updates lack consistent state input, leading to a mismatch between the handling results and actual risks in the verification closed loop. Therefore, there is an urgent need to provide a multi-factor verification method and system for permission codes for the Internet of Things (IoT) to overcome the shortcomings in current practical applications. Summary of the Invention

[0005] As a constraint on the conflict trust mark, when the first verification passes, the time window deviation state exceeds the dynamic time window, the sequence rollback state is not rolled back, and the consensus voting divergence state does not meet the divergence condition, the second confidence level is marked as a drift pending confirmation state, and maintenance correction or decay correction is performed on the second confidence level according to the historical clock drift rate; when the integrity failure source is an incorrect message authentication code, suppression correction is performed on the first confidence level; when the sequence rollback state is rolled back, suppression correction is performed on the second confidence level. Through the above settings, time drift, replay risk, integrity failure, and consensus divergence are distinguished and processed before entering the final weighted fusion, providing correction inputs corresponding to the source of anomalies for hierarchical decision-making. This invention is implemented as follows: a multi-verification method for authorization codes for the Internet of Things, including the following steps:

[0006] Step 1: Generate and distribute permission codes and device fingerprints; the permission code includes permission content, timestamp, serial number, and message authentication code generated based on the device's exclusive key;

[0007] Step 2: Perform the first layer of verification, which is an integrity verification based on device fingerprint, including: verifying whether the device fingerprint of the request source device is consistent with the device fingerprint stored locally, and verifying whether the message authentication code in the permission code is correct, and outputting the first confidence level;

[0008] Step 3: Perform the second verification, which is a timeliness and sequence freshness verification, including: verifying whether the timestamp of the permission code is valid based on a dynamic time window, and verifying whether the sequence number in the permission code satisfies the monotonically increasing condition, and outputting the second confidence level;

[0009] Step four, perform the third verification, which is a distributed consensus behavior baseline comparison, including: the distributed consensus node cluster obtains the access behavior characteristics of the current request, compares the access behavior characteristics with the pre-stored behavior baseline of the request source device, and outputs the third confidence level through majority voting;

[0010] Step 5, perform weighted fusion decision, including: weighted summation of the first confidence level, the second confidence level and the third confidence level to obtain the final confidence level, and determine the final decision on the current access request based on the comparison result of the final confidence level and the preset threshold.

[0011] As a further aspect of the present invention: in step two, the device fingerprint is generated by collecting the unique hardware identifier of the IoT device and using a lightweight hash function;

[0012] The message authentication code is calculated based on a device-specific symmetric key, which is generated by the permission management server using a key derivation function based on the device fingerprint and the server master key.

[0013] As a further aspect of the present invention: in step three, the effective length of the dynamic time window is adaptively adjusted based on the historical clock drift rate of the device, and the calculation method is as follows:

[0014] W_valid=W_base+ρ_drift×Δt_hist;

[0015] Where W_base is the effective window, ρ_drift is the drift rate estimate, and Δt_hist is the historical maximum drift.

[0016] As a further aspect of the present invention: in step four, the behavior baseline includes the device's normal access frequency, access time distribution, and resource access mode characteristics, and the access behavior characteristics of the current request include the corresponding request frequency, request time distribution, and resource access mode.

[0017] The comparison of access behavior characteristics with a behavioral baseline specifically includes:

[0018] The access behavior features are constructed into feature vectors, and the behavior baseline is constructed into a corresponding baseline feature vector. The cosine similarity between the feature vector and the baseline feature vector is calculated. If the cosine similarity is lower than a preset abnormal threshold, it is determined to be an abnormal request.

[0019] As a further aspect of the present invention: in step four, the distributed consensus node cluster uses a lightweight variant of the PBFT or Raft protocol for majority voting to achieve a consistent determination of whether the access behavior is abnormal.

[0020] As a further aspect of the present invention: in step five, the sum of the first weight, the second weight, and the third weight used in the weighted summation is equal to 1.

[0021] As a further aspect of the present invention: in step five, the preset threshold includes a pass threshold and an alarm threshold;

[0022] If the final confidence level is greater than or equal to the threshold, the current access request is allowed.

[0023] If the final confidence level is less than the pass threshold but greater than or equal to the alarm threshold, then a second confirmation or downgraded access is performed on the current access request;

[0024] If the final confidence level is less than the alarm threshold, the current access request will be rejected and a security alarm will be triggered.

[0025] As a further aspect of the present invention: in step five, the first weight, the second weight, and the third weight are dynamically adjusted based on the current security level of the device and / or historical attack records;

[0026] When an increase in replay attacks is detected, the weight corresponding to the second confidence level is increased.

[0027] When an increase in brute-force attacks is detected, the weight corresponding to the first confidence level is increased.

[0028] As a further aspect of the present invention: after step four, the distributed consensus node cluster asynchronously updates the behavior baseline for normal access behavior that has passed verification.

[0029] This invention also provides a multi-factor authentication system for authorization codes for the Internet of Things, comprising:

[0030] The permission management server module is used to generate and distribute device fingerprints and permission codes; the permission code includes permission content, timestamp, serial number and message authentication code generated based on the device's unique symmetric key;

[0031] The device-side verification module, deployed on the IoT device, is used to perform the first and second verifications and output the first and second confidence levels; the first verification is an integrity verification based on the device fingerprint, and the second verification is a timeliness and sequence freshness verification.

[0032] The distributed consensus node cluster module is used to perform the third verification and output the third confidence level. The third verification is to compare the access behavior characteristics of the current request with the pre-stored behavior baseline of the device and output the third confidence level through majority voting.

[0033] The weighted fusion decision module is used to perform a weighted summation of the first confidence level, the second confidence level, and the third confidence level to obtain the final confidence level, and to determine the final decision on the current access request based on the comparison result of the final confidence level and the preset threshold.

[0034] As a constraint on the credibility of conflict markers, when the first verification passes, the time window deviation exceeds the dynamic time window, the sequence rollback status is not rolled back, and the consensus voting divergence status does not meet the divergence condition, the second confidence level is marked as drifting and awaiting confirmation. Based on the historical clock drift rate, a maintenance correction or attenuation correction is applied to the second confidence level. When the integrity failure originates from an incorrect message authentication code, a suppression correction is applied to the first confidence level. When the sequence rollback status is already rolled back, a suppression correction is applied to the second confidence level. Through these settings, time drift, replay risk, integrity failure, and consensus divergence are differentiated and processed before entering the final weighted fusion, providing corrective inputs corresponding to the sources of anomalies for hierarchical decision-making.

[0035] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0036] This invention, building upon existing device fingerprint integrity verification, dynamic time window and sequence freshness verification, and distributed consensus behavior baseline comparison, introduces conflict trust marking and trust correction processing. This allows the first, second, and third confidence levels to be differentiated and corrected according to the source of anomalies before entering weighted fusion. By associating integrity failure sources, time window deviation states, sequence rollback states, and consensus voting divergence states with the marking, the system can separate boundary anomalies caused by clock drift from security risks such as message authentication code errors and sequence rollback, reducing the likelihood of legitimate requests being mistakenly rejected due to fluctuations in a single verification boundary. Suppression correction is performed for message authentication code errors and sequence rollback states, ensuring that the corresponding risks are consistently reflected in the final confidence level, preventing partial verification from causing the fusion result to deviate from the actual risk. Conflict trust marking also provides a unified state input for subsequent dynamic weight adjustment and behavior baseline updates, creating a closed loop between multiple verifications, trust correction, and hierarchical decision-making.

[0037] By binding device fingerprints and using lightweight symmetric passwords for integrity verification, the permission code is strongly bound to the device. Even if an attacker intercepts the permission code, they cannot use it on other devices, effectively resisting brute-force attacks and permission code forgery. Furthermore, the computational cost of a single verification is controlled in milliseconds, making it suitable for resource-constrained devices.

[0038] The mechanism combining dynamic time windows and counters can intercept replay requests both inside and outside the effective window. The adaptive window design tolerates device clock drift, avoiding the false rejection of legitimate requests due to clock deviations, thus achieving a balance between security and availability.

[0039] Distributed consensus nodes collaborate to perform behavioral baseline comparisons, overcoming the limitations of single-point analysis. This enables the identification of coordinated attacks and high-frequency scanning behaviors targeting single devices, and the adaptive baseline update effectively reduces the false alarm rate.

[0040] Weighted fusion hierarchical decision-making replaces simple AND logic hard judgment, which can distinguish between mild anomalies and malicious attacks, avoids the wrong rejection of legitimate requests due to momentary jitter in a single link, and significantly improves verification efficiency and system availability.

[0041] Each verification algorithm employs a lightweight variant of a distributed consensus mechanism, with controllable computational and communication overhead. This makes it suitable for resource-constrained IoT systems such as smart homes and industrial sensors. The dynamic weight adjustment mechanism enables the system to have good adaptability and scalability. Attached Figure Description

[0042] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0043] Figure 1 This is the overall flowchart of the multi-factor authentication method for the permission code of this invention.

[0044] Figure 2 This is a flowchart of the first level of verification in this invention—integrity verification.

[0045] Figure 3 This is a flowchart of the second verification step of the present invention—timeliness and freshness verification.

[0046] Figure 4 This is a flowchart of the third verification step of the present invention—distributed consensus behavior baseline comparison.

[0047] Figure 5 This is a schematic diagram of the triple verification weighted fusion decision-making method of the present invention.

[0048] Figure 6 This is an architectural diagram of an embodiment of the present invention in a smart home scenario.

[0049] Figure 7 This is an architectural diagram of an embodiment of the present invention in an industrial sensing scenario. Detailed Implementation

[0050] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] The present invention will be further explained below with reference to specific embodiments.

[0052] Please see Figure 1 The permission code multi-verification method for the Internet of Things provided in this invention adopts a "triple verification - weighted fusion decision" architecture. The overall process includes four core steps: permission code integrity verification (first verification), timeliness and sequence freshness verification (second verification), distributed consensus behavior baseline comparison (third verification), and weighted fusion decision. Specifically, it includes the following steps:

[0053] Step 1: Generation and Distribution of Permission Codes and Device Fingerprints

[0054] (1) Device fingerprint generation: When the device leaves the factory or is first connected to the network, the device's unique hardware identifier (such as MAC address, chip serial number, manufacturing batch number, etc.) is collected, and a fixed-length device fingerprint FP_dev is generated by a lightweight hash function (such as BLAKE2s or Truncated SHA-256). The device fingerprint is stored in the device's local secure storage area (such as TPM or protected Flash area) and registered with the permission management server.

[0055] (2) Permission Code Generation: The permission management server issues permission codes (PCs) to devices, and its structure is as follows:

[0056] PC={payload,ts,seq,MAC_Kdev}.

[0057] In this structure, payload contains the permission information (such as the accessible resource identifier and permission level), ts is the issuance timestamp, seq is the monotonically increasing sequence number, and MAC_Kdev is the message authentication code calculated based on the device-specific symmetric key K_dev. K_dev is derived from FP_dev by the permission management server and is held only by the server and the corresponding device.

[0058] (3) Key derivation: K_dev = KDF(FP_dev, server_secret), where KDF is the key derivation function (such as HKDF), and server_secret is the master key of the access control server. This mechanism ensures that different devices hold different symmetric keys, so that even if the key of a single device is leaked, it will not affect other devices.

[0059] Step Two: First Level of Verification – Lightweight Symmetric Cryptographic Integrity Verification Based on Device Fingerprint

[0060] After receiving an access request from a PC carrying an authorization code, the device performs the first level of verification, such as... Figure 2 As shown:

[0061] (1) Device fingerprint binding verification: Extract the device identifier from the request, recalculate the device fingerprint FP_dev', compare it with the FP_dev stored locally, and confirm that the device from which the request originated is legitimate.

[0062] (2) Message authentication code verification: Using the locally stored symmetric key K_dev, recalculate the message authentication code MAC_Kdev' for {payload,ts,seq} and compare it with the MAC_Kdev carried in the PC. If they match, it is confirmed that the authentication code has not been tampered with and the source is trustworthy.

[0063] (3) Lightweight symmetric cryptography selection: Lightweight symmetric cryptography algorithms optimized for resource-constrained devices (such as the truncated mode of AES-128-GCM or the ASCON algorithm) are adopted to ensure the strength of integrity verification while controlling the computational cost of a single verification to the millisecond level.

[0064] The first layer of verification outputs an integrity confidence level c1, which is 1 if the verification passes and 0 if it fails.

[0065] Step 3: Second verification – Timeliness and sequence freshness verification using a combination of dynamic time windows and counters

[0066] After the first verification passes, the second verification is performed, such as... Figure 3 As shown:

[0067] (1) Dynamic time window verification: The estimated offset Δ_offset between the device's local clock T_local and the server clock. Calculate the difference between the request time and the issuance time:

[0068] Δt = T_local - Δ_offset - ts.

[0069] If Δt∈[0,W_valid] (W_valid is the dynamic valid window), then the timeliness check passes.

[0070] To tolerate clock drift, W_valid adaptively adjusts based on the device's historical clock drift rate:

[0071] W_valid = W_base + ρ_drift × Δt_hist, where ρ_drift is the drift rate estimate, Δt_hist is the historical maximum drift, and W_base is the base valid window (default 30 seconds).

[0072] (2) Freshness check of counter sequence: The device locally maintains the maximum sequence number of the received permission code, seq_max. If seq > seq_max, the sequence is fresh, seq_max is updated to seq, and the check passes; if seq ≤ seq_max, it is determined to be a replay request, and the check fails.

[0073] (3) In-window out-of-order protection: For requests within the same time window, the counter and timestamp are used for joint judgment. Even if the attacker replays the old permission code within the valid window, it will be blocked because the sequence number does not satisfy monotonically increasing.

[0074] The second layer of verification outputs the timeliness and freshness confidence level c2, with 1 for passing the verification and 0 for failing.

[0075] Step Four: Third Verification – Baseline Comparison of Distributed Consensus Node Behavior

[0076] To address high-frequency access and abnormal behavior identification, a distributed consensus node collaborative verification method is introduced, such as... Figure 4 As shown:

[0077] (1) Establishment of behavioral baseline: The distributed consensus node cluster maintains an access behavior baseline B_dev for each device, which includes features such as normal access frequency f_normal, access time distribution, and resource access patterns. The baseline is dynamically updated by statistically analyzing historical legitimate access behaviors through a sliding window.

[0078] (2) High-frequency access detection: When the frequency of access requests initiated by the device in a short period of time exceeds α×f_normal (α is the sensitivity coefficient, which is 3 by default), a behavior baseline comparison is triggered. The consensus node calculates the similarity between the access behavior feature vector v_req of the current permission code and the baseline B_dev: sim=cos(v_req,B_dev). If sim<θ_abnormal (abnormal threshold, which is 0.5 by default), it is determined to be an abnormal request.

[0079] (3) Distributed consensus voting: Multiple consensus nodes independently compare behavioral baselines and reach a consensus through majority voting (such as a lightweight variant of the PBFT or Raft consensus protocol). The consensus result c3 represents the confidence level of normal behavior, and its value is the majority node judgment result.

[0080] (4) Baseline adaptive update: For normal access behavior that passes the verification, the consensus node asynchronously updates the behavior baseline, so that the baseline can adapt to reasonable changes in device usage patterns and reduce false alarm rate.

[0081] The third verification outputs a confidence level c3, where 1 indicates normal behavior and 0 indicates abnormal behavior.

[0082] Step 5: Weighted Fusion Decision

[0083] The results of the triple verification are weighted and fused to output the final decision, such as... Figure 5 As shown:

[0084] (1) Weighted fusion calculation: C_final=w1×c1+w2×c2+w3×c3. Where w1, w2, and w3 are the weights of each verification, satisfying w1+w2+w3=1. The default weights are configured according to security requirements, for example, w1=0.4, w2=0.3, w3=0.3, with integrity verification having the highest weight.

[0085] (2) Hierarchical decision-making: Set the pass threshold θ_pass (default 0.8) and the alarm threshold θ_alert (default 0.5). If C_final≥θ_pass, the request is allowed; if θ_alert≤C_final<θ_pass, the request enters the secondary manual confirmation or downgraded access mode; if C_final<θ_alert, the request is rejected and a security alarm is triggered.

[0086] (3) Dynamic weight adjustment: The weights are dynamically adjusted based on the security level of the device and historical attack records. For example, when an increase in recent replay attacks is detected, w2 is automatically increased and w1 and w3 are correspondingly decreased (e.g., adjusted to w1=0.3, w2=0.5, w3=0.2); when an increase in brute-force attacks is detected, w1 is increased and w2 and w3 are correspondingly decreased. The constraint w1+w2+w3=1 is still satisfied after adjustment.

[0087] After the first layer of verification outputs the first confidence level, it simultaneously provides the integrity verification status to the weighted fusion decision module. The integrity verification status is used to distinguish between device fingerprint matching failure and message authentication code matching failure. After the second layer of verification outputs the second confidence level, it simultaneously provides the time window deviation status and sequence rollback status to the weighted fusion decision module. The time window deviation status comes from the dynamic time window verification result, and the sequence rollback status comes from the comparison result between the sequence number in the current permission code and the maximum sequence number recorded locally on the device. After the third layer of verification outputs the third confidence level, it simultaneously provides the consensus voting divergence status to the weighted fusion decision module. The consensus voting divergence status is formed by comparing the behavioral baselines of each node in the distributed consensus node cluster.

[0088] After receiving the first confidence level, second confidence level, third confidence level, and corresponding verification status, the weighted fusion decision module first generates a conflict trust flag. The conflict trust flag does not replace the triple verification result, but rather serves as a state constraint input before weighted fusion, indicating whether there are boundary conflicts between the triple verification results. The integrity failure source characterizes whether the integrity verification failure occurred during the device fingerprint comparison stage or the message authentication code comparison stage; the time window deviation state characterizes the deviation relationship between the authorization code timestamp and the dynamic time window; the sequence rollback state characterizes whether the authorization code sequence number has rolled back relative to the device's local record; and the consensus voting divergence state characterizes whether a divergence has occurred in the behavior judgment within the distributed consensus node cluster.

[0089] When the first verification passes, the time window deviation status shows the permission code timestamp exceeds the dynamic time window, the sequence rollback status shows no rollback, and the consensus voting divergence status does not meet the divergence condition, the weighted fusion decision module marks the second confidence level as a drift pending confirmation state. The second confidence level in the drift pending confirmation state does not directly enter the weighted fusion as a failure state, but instead undergoes a reliability correction based on the device's historical clock drift rate. If the time window deviation can be explained by the historical clock drift status, a hold correction is performed on the second confidence level; if the time window deviation cannot be explained by the historical clock drift status, a decay correction is performed on the second confidence level. The results of both hold and decay corrections are used as the updated result of the second confidence level in subsequent weighted summations.

[0090] When the integrity failure originates from an incorrect message authentication code, the weighted fusion decision module applies suppression correction to the first confidence level and inputs the suppressed and corrected first confidence level into the weighted fusion decision. An incorrect message authentication code corresponds to an abnormality in the integrity of the authorization code content or the credibility of its source. Suppression correction is used to prevent the final confidence level from deviating from the authorization code integrity risk due to a normal behavioral baseline or an effective time window. When the sequence rollback status is "rollback complete," the weighted fusion decision module applies suppression correction to the second confidence level and inputs the suppressed and corrected second confidence level into the weighted fusion decision. The sequence rollback status corresponds to replay risk, and suppression correction is used to constrain the replay risk in the final confidence level.

[0091] After completing the trust correction, the weighted fusion decision module performs a weighted summation using the updated first, second, and third confidence levels to generate the final confidence level. It then continues to determine whether to grant access, conduct secondary confirmation, downgrade access, deny access, or issue a security alarm based on the pass threshold and alarm threshold. The conflict trust tag, after the decision on this round of access requests is completed, can be provided as a status input to the dynamic weight adjustment and behavior baseline update stages. When an access request is denied or a security alarm is triggered, the conflict trust tag is recorded as an anomaly source and enters the security alarm chain. When an access request enters secondary confirmation or downgrade access, the conflict trust tag is used as a boundary state description and enters the subsequent confirmation process. Through the above supplementary processes, a continuous processing chain of verification status, trust correction, and hierarchical decision-making is formed between the original triple verification output and the weighted fusion decision.

[0092] This weighted fusion decision replaces the simple AND logic hard decision in the existing scheme, which can distinguish between mild anomalies and malicious attacks, improve security while reducing false alarm rate, and ensure verification efficiency and system availability.

[0093] The multi-factor authentication system for Internet of Things (IoT) provided in this invention includes:

[0094] (1) Permission Management Server Module: Responsible for device fingerprint registration, permission code generation and issuance, symmetric key derivation and distribution.

[0095] (2) Device verification module: Deployed on resource-constrained IoT devices, it performs the first layer of integrity verification and the second layer of timeliness and freshness verification, and outputs c1 and c2.

[0096] (3) Distributed consensus node cluster module: Deployed on edge gateway or cloud, it performs third-level behavior baseline comparison and majority voting, and outputs c3.

[0097] (4) Weighted fusion decision module: Receives c1, c2, and c3, performs weighted fusion calculation and hierarchical decision, and outputs the final release / downgrade / rejection judgment.

[0098] Example 1: Smart Home Scene

[0099] like Figure 6 As shown, in a smart home system, terminal devices such as smart locks and smart cameras have limited computing resources. Device fingerprints are generated and registered with the home gateway at the factory, which also serves as the access control server.

[0100] When a user issues an "unlock" control command via the app, the home gateway issues an authorization code PC to the command, which includes unlocking authorization information, the current timestamp, and an incrementing sequence number. It then uses the lock's proprietary symmetric key K_dev to calculate the message authentication code. Upon receiving the control command, the smart lock performs triple verification.

[0101] In the first layer of verification, the smart lock extracts the device identifier from the request and recalculates the device fingerprint, comparing it with the locally stored device fingerprint to confirm that the request originates from a registered device. Simultaneously, it uses the locally stored symmetric key K_dev to recalculate the message authentication code based on the permission content, timestamp, and serial number, comparing it with the message authentication code carried in the permission code to verify the integrity of the permission code. If any comparison fails, the integrity confidence level c1 is 0.

[0102] After the first verification passes, the second verification is executed. The smart lock maintains an estimated offset between its local clock and the home gateway clock, with a base effective window W_base set to 30 seconds, tolerating a clock drift of ±2 seconds. The difference between the request time and the issuance time is calculated to determine if it falls within the dynamic time window. Simultaneously, the smart lock locally maintains the maximum sequence number seq_max of the received authorization codes and verifies whether the sequence number in the current authorization code is greater than seq_max. If the timestamp is within the dynamic time window and the sequence number monotonically increases, the timeliness and freshness confidence level c2 is 1. If an attacker intercepts the unlocking command in the communication link and replays it within the effective window, the replay request will be successfully intercepted because the sequence number of the replay command is not greater than the maximum sequence number recorded by the lock.

[0103] After the second verification passes, the third verification is performed. The home gateway, acting as a distributed consensus node, performs a behavioral baseline comparison of the door lock's unlocking frequency. The behavioral baseline for this smart door lock is a normal unlocking frequency of approximately 1 time per minute, with a sensitivity coefficient α set to 3. When the number of unlocking requests exceeds 5 within 1 minute, a behavioral baseline comparison is triggered. The cosine similarity between the current request behavior feature vector and the baseline feature vector is calculated. If the similarity is lower than the abnormal threshold θ_abnormal, the request is considered abnormal.

[0104] Finally, the triple verification results are sent to the weighted fusion decision module. The weights of integrity confidence c1, timeliness and freshness confidence c2, and behavior confidence c3 are set to 0.4, 0.3, and 0.3 respectively, and the weighted sum is used to obtain the final confidence C_final. If C_final is greater than or equal to the passing threshold θ_pass, the unlocking command is allowed; if it is lower than the passing threshold θ_pass but higher than the alarm threshold θ_alert, a second confirmation is required; if it is lower than the alarm threshold θ_alert, the unlocking is rejected and a security alarm is triggered. Through the above mechanism, the smart lock can effectively prevent brute-force attacks and replay attacks.

[0105] Example 2: Industrial Sensing Scenarios

[0106] like Figure 7As shown, in the Industrial Internet of Things (IIoT), temperature sensor nodes periodically report data. An access control server issues access codes to each sensor node, and a distributed consensus node cluster is deployed at the edge gateway to maintain a baseline of data reporting behavior for each node, including characteristics such as normal reporting frequency, reporting time distribution, and data format.

[0107] Under normal operating conditions, the temperature sensing node reports temperature data to the gateway every 10 minutes. The access request carries the permission code and passes the first and second verifications in sequence. In the third verification, the request frequency does not exceed α times the baseline frequency, and the behavior confidence level c3 is 1. After the triple weighted fusion, the final confidence level C_final is higher than the passing threshold θ_pass, and the data reporting request is allowed to pass normally.

[0108] When the sensor node is hijacked by an attacker, the attacker attempts to send forged data reporting requests to the gateway at a high frequency of once per second, triggering the high-frequency access detection of the third layer of verification. The distributed consensus nodes calculate the similarity between the access behavior feature vector of the current request and the behavior baseline. The actual reporting frequency far exceeds the normal baseline frequency, and the similarity is lower than the anomaly threshold θ_abnormal. After independent judgment by each distributed consensus node, the access behavior is confirmed as abnormal by majority vote, and the behavior confidence c3 is output as 0.

[0109] After the weighted fusion decision module integrates the triple verification results, the data reporting request of this sensor node is rejected because the third reset confidence level c3 is 0 and the weighted fusion score is lower than the alarm threshold θ_alert. Simultaneously, a security alarm is triggered to notify maintenance personnel to intervene. Data reporting by other normal sensor nodes is unaffected, ensuring the overall availability of the system.

[0110] In summary, this invention uses device fingerprint binding and lightweight symmetric password integrity verification to strongly bind the permission code to the device. Even if an attacker intercepts the permission code, they cannot use it on other devices, effectively resisting brute-force attacks and permission code forgery. Furthermore, the computational cost of a single verification is controlled at the millisecond level, making it suitable for resource-constrained devices.

[0111] The mechanism combining dynamic time windows and counters can intercept replay requests both inside and outside the valid window. The adaptive window design tolerates device clock drift, preventing legitimate requests from being mistakenly rejected due to clock deviations, thus achieving a balance between security and availability.

[0112] Distributed consensus nodes collaborate to perform behavioral baseline comparisons, overcoming the limitations of single-point analysis. This enables the identification of coordinated attacks and high-frequency scanning behaviors targeting single devices, and adaptive baseline updates reduce the false alarm rate.

[0113] Weighted fusion hierarchical decision-making replaces simple AND logic hard judgment, which can distinguish between mild anomalies and malicious attacks, avoids the wrong rejection of legitimate requests due to momentary jitter in a single link, and significantly improves verification efficiency and system availability.

[0114] Each verification algorithm employs a lightweight variant of a distributed consensus mechanism, with controllable computational and communication overhead. It is suitable for resource-constrained IoT systems such as smart homes and industrial sensors. The dynamic weight adjustment mechanism enables the system to have good adaptability and scalability.

[0115] The following is an explanation of some of the terms used in the embodiments of this invention:

[0116] Permission Code: An authentication credential carried by IoT devices when accessing system resources, which includes permission content, timestamp, serial number, and message authentication code.

[0117] Device fingerprint: A fixed-length identifier generated based on the unique hardware identifier of a device (such as MAC address, chip serial number, etc.), used for device identity binding and anti-counterfeiting.

[0118] Lightweight symmetric ciphers are symmetric encryption algorithms optimized for resource-constrained devices, such as AES-128-GCM truncated mode or ASCON algorithm, which have low computational overhead and integrity protection capabilities.

[0119] Behavior Baseline: A statistical model of normal access behavior characteristics maintained by distributed consensus nodes for each device, including features such as access frequency, time distribution, and resource access patterns.

[0120] Distributed Consensus Node: A cluster node that participates in behavioral baseline comparison and majority voting to reach a consensus decision through PBFT or a lightweight variant of Raft.

[0121] Weighted Fusion Decision: A decision-making mechanism that combines multiple verification results with weights and then makes hierarchical judgments, replacing the simple "AND" logic hard decision.

[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A multi-factor authentication method for authorization codes for the Internet of Things, characterized in that, Includes the following steps: Step 1: Generate and distribute permission codes and device fingerprints; the permission code includes permission content, timestamp, serial number, and message authentication code generated based on the device's exclusive key; Step two, perform the first verification, which is an integrity verification based on the device fingerprint, including: verifying whether the device fingerprint of the request source device is consistent with the device fingerprint stored locally, and verifying whether the message authentication code in the permission code is correct, and outputting the first confidence level; Step 3: Perform the second verification, which is a timeliness and sequence freshness verification, including: verifying whether the timestamp of the permission code is valid based on a dynamic time window, and verifying whether the sequence number in the permission code satisfies the monotonically increasing condition, and outputting the second confidence level; Step four, perform the third verification, which is a distributed consensus behavior baseline comparison, including: the distributed consensus node cluster obtains the access behavior characteristics of the current request, compares the access behavior characteristics with the pre-stored behavior baseline of the request source device, and outputs the third confidence level through majority voting; Step 5, performing weighted fusion decision-making, includes: generating conflict trust markers based on the verification states of the first, second, and third verifications, wherein the conflict trust markers include at least one of integrity failure source, time window deviation state, sequence rollback state, and consensus voting divergence state; performing trust correction on the first, second, and third confidence levels according to the conflict trust markers, and updating the first, second, and third confidence levels with the trust correction results; performing a weighted summation on the first, second, and third confidence levels to obtain a final confidence level, and determining the final decision for the current access request based on the comparison result of the final confidence level and a preset threshold.

2. The method according to claim 1, characterized in that, In step two, the device fingerprint is generated by collecting the unique hardware identifier of the IoT device and using a lightweight hash function; The message authentication code is calculated based on a device-specific symmetric key, which is generated by the permission management server using a key derivation function based on the device fingerprint and the server master key.

3. The method according to claim 1, characterized in that, In step three, the effective length of the dynamic time window is adaptively adjusted according to the historical clock drift rate of the device. The effective length of the dynamic time window is the sum of the product of the basic effective window, the drift rate estimate, and the historical maximum drift amount. Wherein, the basic effective window is a pre-configured basic effective duration, the drift rate estimate is a drift rate obtained based on the historical clock offset changes of the device, and the historical maximum drift amount is the maximum clock drift amount in the historical record.

4. The method according to claim 1, characterized in that, In step four, the behavior baseline includes the device's normal access frequency, access time distribution, and resource access pattern characteristics, and the access behavior characteristics of the current request include the corresponding request frequency, request time distribution, and resource access pattern. The comparison between the access behavior features and the behavior baseline specifically involves: constructing the access behavior features into a feature vector, constructing the behavior baseline into a corresponding baseline feature vector, calculating the cosine similarity between the feature vector and the baseline feature vector, and determining an abnormal request if the cosine similarity is lower than a preset abnormal threshold.

5. The method according to claim 1, characterized in that, In step four, the distributed consensus node cluster uses a lightweight variant of the PBFT or Raft protocol for majority voting to reach a consistent determination of whether the access behavior is abnormal.

6. The method according to claim 1, characterized in that, Step five, the generation and correction of the conflict trust marker, includes: When the first verification passes, the time window deviation state exceeds the dynamic time window, the sequence rollback state is not rolled back, and the consensus voting divergence state does not meet the divergence condition, the second confidence is marked as a drift pending confirmation state, and the second confidence is subjected to maintenance correction or decay correction based on the historical clock drift rate. When the integrity failure is caused by an incorrect message authentication code, the first confidence level will be subject to suppression correction. When the sequence rollback state is rolled back, the second confidence level is subjected to suppression correction, and the result of the confidence correction is used as the input to the weighted fusion decision.

7. The method according to claim 1, characterized in that, In step five, the sum of the first weight, the second weight, and the third weight used in the weighted summation is equal to 1; The first weight, the second weight, and the third weight are dynamically adjusted based on the current security level of the device and / or historical attack records; When an increase in replay attacks is detected, the second weight corresponding to the second confidence level is increased; When an increase in brute-force attacks is detected, the first weight corresponding to the first confidence level is increased.

8. The method according to claim 1, characterized in that, In step five, the preset thresholds include a pass threshold and an alarm threshold; If the final confidence level is greater than or equal to the pass threshold, then the current access request is allowed; If the final confidence level is less than the pass threshold and greater than or equal to the alarm threshold, then a second confirmation or downgraded access is performed on the current access request; If the final confidence level is less than the alarm threshold, the current access request is rejected and a security alarm is triggered.

9. The method according to claim 1, characterized in that, Step four is followed by: for normal access behavior that passes verification, the distributed consensus node cluster asynchronously updates the behavior baseline.

10. A multi-factor authentication system for authorization codes for the Internet of Things, characterized in that, include: The access control server module is used to generate and distribute device fingerprints and access codes; The permission code includes permission content, timestamp, serial number, and message authentication code generated based on the device-specific symmetric key; The device-side verification module, deployed on the IoT device, is used to perform the first and second verifications and output the first and second confidence levels; the first verification is an integrity verification based on the device fingerprint, and the second verification is a timeliness and sequence freshness verification. The distributed consensus node cluster module is used to perform the third verification and output the third confidence level. The third verification is to compare the access behavior characteristics of the current request with the pre-stored behavior baseline of the request source device, and output the third confidence level through majority voting. The weighted fusion decision module is used to generate conflict trust tags based on the verification status of the first verification, the second verification, and the third verification; perform trust correction on the first confidence, the second confidence, and the third confidence based on the conflict trust tags; perform weighted summation on the trust-corrected first confidence, the second confidence, and the third confidence to obtain the final confidence; and determine the final decision on the current access request based on the comparison result of the final confidence with a preset threshold.

Images