Fire-fighting internet of things heterogeneous terminal lightweight authentication and on-chain evidence storage method

Abstract

This invention relates to a lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the Internet of Things (IoT) for fire protection. It pertains to the field of IoT identity authentication and includes unified device registration, selection of hierarchical authentication paths based on device type, execution of device authentication and session key negotiation, on-chain evidence storage of authentication results, and runtime adaptive authentication management based on trust thresholds and random checks. This invention addresses the challenge of simultaneously achieving security, lightweightness, and auditability in resource-constrained heterogeneous terminal scenarios through a hierarchical collaborative authentication mechanism for heterogeneous terminals, a dual-random index sharding key derivation mechanism, gateway local proxy authentication, a trust-triggered random verification authentication mechanism, and blockchain-based evidence storage of authentication behavior.

Description

Technical Field

[0001] This invention relates to the field of identity authentication technology for fire protection IoT, and in particular to a lightweight authentication and on-chain evidence storage method for heterogeneous terminals in fire protection IoT. Background Technology

[0002] With the development of smart fire protection, fire protection IoT devices are gradually being deployed in various buildings, communities, and key protection areas. The numerous fire protection IoT terminal devices deployed in the system, such as stand-alone smoke detectors, electrical fire monitoring devices, and edge processing gateways, collectively constitute a heterogeneous and widely distributed fire sensing and early warning system. These devices differ significantly in communication methods, computing power, power supply conditions, deployment locations, and network accessibility, and are therefore categorized into Type A devices, Type B devices, and gateway devices. Type A devices have the ability to directly connect to the fire protection IoT platform, while Type B devices can only connect to the platform through on-site gateway devices. The gateway devices simultaneously handle edge aggregation, protocol conversion, and local management functions. Therefore, device authentication in fire protection IoT typically needs to adapt to multiple types of objects, including Type A devices (directly connected terminals), Type B devices (gateway access terminals), and gateway devices.

[0003] Existing IoT device authentication solutions mostly employ digital certificates, asymmetric cryptography, pre-shared keys, or centralized passwords to authenticate device access. For resource-constrained fire protection IoT devices, certificate-based or complex asymmetric cryptography authentication methods incur high computational, storage, and communication overhead, while authentication methods based solely on static keys or passwords face security risks such as key leakage, copying and spoofing, and long-term credential reuse. Especially in fire protection IoT scenarios, with a large number of terminals, long deployment cycles, and low maintenance frequency, if device identities / credentials are copied or leaked, it can lead to problems such as unauthorized device access, false status reports, or difficulty in tracing authentication records.

[0004] Physically unclonable functions (PUFs) can generate device-specific responses by leveraging physical random differences in the chip manufacturing process, thus being used for lightweight identification and authentication of IoT terminals. Existing PUF authentication schemes typically require storing challenge response information during the registration phase and completing identity verification based on the PUF response during the authentication phase. However, directly using the complete response or information strongly correlated with the response during authentication may increase the risk of the response information being analyzed, replayed, or inferred. Furthermore, different types of fire protection IoT devices have different communication paths and security boundaries; uniformly adopting the same PUF authentication process makes it difficult to simultaneously address the public network exposure risks of directly connected devices and the resource-constrained characteristics of gateway access devices.

[0005] On the other hand, existing device authentication schemes typically treat identity authentication, authorization validity management, and session key negotiation as relatively independent processes. Before completing identity authentication, devices often need to rely on a pre-established secure channel, or perform an additional key negotiation process after authentication. This increases the number of interaction rounds and system complexity, hindering the access of low-power, low-computing-power devices. Furthermore, the authorization validity period after successful device authentication often employs a fixed strategy, failing to dynamically adjust based on device history, authentication success rate, anomalies, and operational status. This leads to frequent re-authentication for highly trusted devices, making it difficult to strike a balance between security and communication overhead.

[0006] Furthermore, the certification results of fire protection IoT devices typically have regulatory and auditing value. Traditional centralized certification logs rely on platform databases for storage, which are susceptible to tampering, deletion, or difficulty in proving wrongdoing afterward. Blockchain technology offers immutable and traceable recording capabilities, making it suitable for storing critical records such as device registration, certification, deregistration, and certification information updates. However, there is still room for improvement in how to combine heterogeneous device certification processes with on-chain evidence storage mechanisms without increasing the burden on devices, while also considering centralized platform management, identity authentication, and lightweight device access. Summary of the Invention

[0007] (a) Technical problems to be solved In view of the above-mentioned shortcomings and deficiencies of the existing technology, the present invention provides a lightweight authentication and on-chain evidence storage method for heterogeneous terminals of fire protection IoT. Through a heterogeneous terminal layered collaborative authentication mechanism, a dual random index sharding key derivation mechanism, a gateway local agent authentication, a trust-triggered random verification authentication mechanism, and blockchain-based authentication behavior evidence storage, the present invention solves the problem that the existing technology is difficult to balance security, lightweightness and auditability in resource-constrained heterogeneous terminal scenarios.

[0008] (II) Technical Solution To achieve the above objectives, the main technical solution adopted by this invention is a lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT, comprising the following steps: S1. Unified Device Registration: On the fire protection IoT platform, identity records are established for gateway devices, Type A devices and Type B devices respectively, and different registration information is written according to the device type. After registration is completed, the device registration information is written to the private blockchain to form on-chain registration records. S2. Select a tiered authentication path based on device type: The authentication entity selects the corresponding access authentication path based on the device type, access path, and ownership relationship of the object to be authenticated, and incorporates the three types of heterogeneous fire protection IoT terminals into the same identity management framework, so that devices with different access capabilities and resource conditions adopt differentiated authentication paths, while maintaining unified identity management and traceability of authentication results on the fire protection IoT platform side. S3. Perform device authentication and session key negotiation: After selecting the authentication path, the authentication subject and the device execute the corresponding authentication process. During the generation and verification of authentication credentials, the authentication and session key are derived from the same source through the authentication and session key derivation mechanism, so that the session key is generated at the same time as the device authentication is completed. The session key is derived from the same round of dynamic response value and authentication context. The session key is used for subsequent secure communication after successful authentication. Identity authentication and session key derivation are completed in the same authentication process. S4. On-chain storage of authentication results: The authentication subject generates authentication result records. The authentication results of gateway devices and Type A devices are written to the private blockchain by the platform, while the authentication results of Type B devices are directly written to the private blockchain by the host gateway device. When the blockchain is temporarily unavailable, the authentication entity caches the device authentication result and rewrites the on-chain evidence after communication is restored. S5. Runtime adaptive authentication management based on trust threshold and random sampling: When the device authentication is about to expire, the authentication subject compares the device trust value with the trust threshold value. If the device trust value is higher than the trust threshold value and passes the random sampling, simple renewal can be performed without performing full authentication; otherwise, the device triggers full authentication. When the authentication subject performs a simple renewal, it calculates and updates the authentication expiration time, sends a renewal success credential message consisting of the authentication expiration time, timestamp, and digest to the device through a channel protected by the session key, and writes the on-chain authentication renewal record to the private blockchain after the renewal.

[0009] In step S1, for the gateway device, the platform registers the serial number SN, gateway signature public key, gateway authentication public key and trusted boot metric hash, and generates a gateway identifier. The gateway signature public key is used to confirm the signature identity when submitting the evidence record to the private blockchain, the gateway authentication public key is used to verify whether the gateway holds the gateway authentication secret, and the trusted boot metric hash is used to bind the gateway trusted boot and firmware integrity metric. For Type A and Type B devices, the platform registers the device type, the stabilized PUF response, and generates a device identifier. For Type A devices, the platform also registers the number of shards, and both the platform and Type A devices have built-in pseudo-random perturbation functions for shard indexes. For Type B devices, the platform also registers the home gateway identifier and records the gateway binding relationship. After registration, the platform synchronizes the device identifier hash and PUF response information required for local agent authentication of Type B devices to the home gateway. The platform writes device registration information into a private blockchain, forming a traceable on-chain registration record.

[0010] In step S2, for gateway devices and Type A devices, the platform executes the authentication process, and the device directly completes the authentication interaction with the platform; for Type B devices, the home gateway executes the gateway proxy authentication process, and Type B devices do not directly interact with the platform for authentication, but the gateway completes the authentication locally.

[0011] In step S3, for the gateway device, the gateway device authentication consists of three elements: trusted measurement, PUF response, and non-interactive zero-knowledge proof, and is performed in conjunction with session key negotiation. After the gateway starts, the bootloader and firmware are remeasured, and the measurement results are combined with the local stable PUF response to reconstruct the authentication secret; the platform side pre-registers the gateway authentication public key generated by this authentication secret; During authentication, the gateway generates a one-time random number and calculates an authentication commitment value. This commitment value serves as both the commitment for the non-interactive zero-knowledge proof and the gateway's temporary public key in key negotiation. The gateway device sends a message to the platform consisting of a device identifier, the commitment value, and a timestamp. After verifying that the timestamp has not expired, the platform generates a random number, calculates a temporary public key, and returns a message consisting of the temporary public key, the platform signature, and a timestamp. After verifying the platform signature, the gateway uses the authentication context hash, including the gateway identifier, the gateway authentication public key, and the temporary public keys of both parties, to generate a challenge, calculates the zero-knowledge proof response, and derives a session key and authentication digest based on the gateway random number and the platform temporary key. It then sends an authentication message to the platform consisting of the proof response and the digest. The platform uses the registered gateway authentication public key to verify the non-interactive zero-knowledge proof and derives the same session key and verification digest based on the platform random number and the gateway temporary key. After successful authentication, the gateway is issued authentication success credentials consisting of authentication expiration time, timestamp, and digest; thus, gateway identity verification, firmware integrity verification, and session key derivation are completed within the same authentication branch.

[0012] In step S3, for type A devices, type A device authentication consists of three elements: PUF stable response fragmentation, fragmentation index pseudo-random perturbation, and trust value-driven authentication strength adjustment, which are combined and executed in conjunction with session key negotiation. During authentication, Type A devices first send an authentication request to the platform consisting of a device identifier hash, a device random number, and a timestamp. After verifying that the timestamp has not expired, the platform generates a platform random number and determines the number of fragments to be selected based on the device's trust value. This ensures that the number of fragments participating in authentication dynamically changes with the device's risk. The platform randomly selects a set of fragments indexed by a certain number from the device's response fragments and sends it to the device. After receiving the message from the platform, the device locally restores a stable PUF response, calculates the perturbed sequence number set using a fragment perturbation pseudo-random perturbation function, and concatenates the dynamic response value. Subsequently, the device generates a session key based on the dynamic response value and sends an authentication message consisting of a device identifier hash, a timestamp, and a digest to the platform. The platform derives the same session key, reproduces the dynamic response value and verifies the digest according to the same rules, and sends authentication success credentials information consisting of the authentication expiration time, a timestamp, and an authentication digest to the device. Therefore, Type A device authentication and session key negotiation are completed within the same authentication round.

[0013] In step S3, for Type B devices, Type B device authentication is handled by the local agent of the home gateway; the gateway periodically broadcasts beacon information containing the gateway identifier, gateway random number, and timestamp. During authentication, the Type B device recovers its local stable PUF response and generates a device random number. It then calculates the HMAC authentication code using the stable response, the gateway random number, and the device random number, and sends a message to the gateway consisting of the device identifier hash, authentication code, device random number, and timestamp. The home gateway device queries its local mapping table based on the device identifier hash to obtain the corresponding stable PUF response and verifies the authentication code. Upon successful verification, both the gateway device and the Type B device derive a session key based on the stable response, the gateway random number, the device random number, and the device identifier hash, respectively. The gateway then sends an authentication success credential message to the Type B device, consisting of the authentication expiration time, timestamp, and digest. Therefore, Type B devices can complete authentication and session key negotiation without direct connection to the platform.

[0014] The authentication result record in step S4 includes at least the device identifier summary, authentication process information, timestamp, authentication expiration time, and signature; the private blockchain saves on-chain registration records and on-chain deregistration records in step S1, on-chain authentication records in step S4, and on-chain authentication renewal records in step S5, to provide an immutable and traceable audit basis.

[0015] In step S5, for type A devices, the platform dynamically adjusts the number of segments selected based on the trust value, thereby enabling highly trusted devices to use lower authentication strength and low-trust or abnormal devices to use higher authentication strength during full authentication; the platform and gateway devices adjust the trust threshold value based on the device authentication status.

[0016] (III) Beneficial Effects The beneficial effects of this invention are: 1. The present invention integrates the gateway, Type A direct-connected device, and Type B low-power edge device into a unified identity management framework, and designs a layered authentication path based on the device's computing power and network capabilities: the gateway integrates trusted firmware measurement and zero-knowledge proof to ensure the security of edge nodes, Type A devices adopt PUF fragmentation perturbation mechanism to reduce the risk of data leakage, and Type B devices are authenticated locally by the gateway without the need for direct connection to the platform, which greatly reduces the computing and communication overhead of the low-power fire sensing terminal and adapts to the characteristics of limited fire equipment resources and complex deployment environment; 2. This invention abandons the traditional model of step-by-step execution of identity authentication and key negotiation. It generates session keys based on the same context of random numbers and PUF dynamic responses in the same round of authentication interaction. Identity verification and encrypted channel establishment can be completed in a single communication, reducing the number of device interaction rounds and transmission latency. Moreover, each authentication generates a brand new dynamic key, avoiding the risk of leakage and impersonation caused by long-term reuse of static pre-shared keys. 3. This invention establishes an on-chain evidence storage system covering the entire lifecycle of equipment registration, authentication, renewal, and cancellation. It records the attached device hash, timestamp, and subject signature, and has the characteristics of being tamper-proof and fully traceable. It adopts a platform and gateway hierarchical on-chain mechanism, and the massive B-type device authentication records are aggregated and stored by the gateway, which distributes the platform's computing power pressure. At the same time, it supports caching when the network is disconnected and rewriting records after communication is restored. It is suitable for fire-fighting locations with unstable networks, such as underground pipe corridors and closed computer rooms, and facilitates traceability and evidence collection by regulatory agencies. 4. Based on the Sigmoid model, the device trust value is calculated by integrating multi-dimensional data such as authentication success rate, abnormal behavior, and communication latency. Combined with trust threshold and random sampling mechanism, high-trust devices only need lightweight renewal upon expiration, without having to perform a full and complex authentication process, reducing the overhead of repeated authentication; abnormal low-trust devices are subject to full authentication to tighten security verification, and the scoring model can automatically adapt to the risk characteristics of different fire protection scenarios by iterating weights based on historical samples, reducing manual operation and maintenance costs. 5. Using PUF (Physical Unique Function) identifiers to prevent device copying and counterfeiting at the hardware level, a sharding random disturbance mechanism to prevent PUF features from being stolen by traffic analysis, gateway trust metrics to intercept illegal edge nodes after firmware tampering, dynamic session keys to resist replay and man-in-the-middle attacks, blockchain evidence storage to eliminate log tampering and post-event repudiation issues, and dynamic monitoring of trust values ​​to promptly identify abnormal access behavior, comprehensively avoiding security risks such as illegal access to fire protection IoT. Attached Figure Description

[0017] Figure 1 This is a system architecture diagram of the fire protection IoT heterogeneous terminal lightweight authentication and on-chain evidence storage method of the present invention. Detailed Implementation

[0018] To better explain and facilitate understanding of this invention, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, is provided. An embodiment of this invention proposes a lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT system. like Figure 1 The system architecture diagram shown illustrates the specific implementation of a lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT system. It consists of a platform layer, an edge layer, and a sensing device layer. The platform layer includes a fire protection IoT platform and a private blockchain. The fire protection IoT platform implements device registration and management for gateway devices / Type A devices / Type B devices, heterogeneous device identity authentication, device trust value assessment, and on-chain evidence storage via the private blockchain. The private blockchain stores device registration records, authentication records, deregistration records, and authentication information update records. The edge layer mainly consists of gateway devices, which have the functions of performing gateway device authentication, Type B device proxy authentication, session key derivation, and writing Type B device authentication records to the private blockchain for on-chain evidence storage. The sensing device layer includes Type A devices and Type B devices. Type A devices perform direct authentication through the platform and synchronously derive session keys, while Type B devices perform proxy authentication through the gateway and synchronously derive session keys.

[0019] S1. Unified Device Registration: On the fire protection IoT platform (hereinafter referred to as the platform), identity records are established for gateway devices, Type A devices and Type B devices respectively, and different registration information is written according to the device type. After registration is completed, the device registration information is written to the private blockchain to form on-chain registration records. (1) Gateway device registration: The gateway generates a gateway signature key pair locally. ,challenge Based on this challenge, a stable PUF response is generated. Gateway device saves Combined with PUF stabilization auxiliary data. The gateway device's TPM module calculates the trusted startup metric. ,in , Bootloader for gateway For gateway firmware. Gateway authentication secrets. and gateway authentication key pair ,in , , To select the base point of the ECC elliptic curve.

[0020] The platform registers the gateway device's serial number (SN) and gateway signature public key. Gateway authentication public key and trusted startup metric hash Generate gateway identifier (i.e., the home gateway registered for the Type B device below) Among them, the gateway signing public key. The gateway authentication public key is used for signature and identity verification when subsequently submitting evidence records to the private blockchain. Used for subsequent verification of whether the gateway holds the gateway authentication secret; After registration is completed, the platform will write the registration information into a private blockchain to form an on-chain registration record: ; The transaction type of this record is That is, gateway device registration, in the records. For equipment type, For platform timestamps, Sign up for the platform.

[0021] (2) Registration of Type A equipment Type A Equipment Generation Challenge And collect stable PUF responses Equipment storage PUF stabilization auxiliary data.

[0022] Platform registration device type A, PUF response after stabilization. and fragmentation parameters Generate device identifier ,Will Evenly divided into A response fragment The platform and equipment are pre-configured with the same pseudo-random perturbation function. .

[0023] After registration is completed, the platform will write the registration information into a private blockchain to form an on-chain registration record: ; The transaction type recorded is That is, Type A device registration, in the records For equipment type, For Type A equipment certification mode, To stabilize the PUF response hash, For platform timestamps, Sign up for the platform.

[0024] (3) Registration of Type B equipment Type B Equipment Generation Challenge And collect stable PUF responses ,save PUF stabilization auxiliary data.

[0025] The platform registers the device serial number (SN), device type, and gateway identifier of the gateway to which it belongs. and Generate B-type equipment identifier Establish a binding relationship between the device and its home gateway.

[0026] After registration is completed, the platform will write the registration information into a private blockchain to form an on-chain registration record: ; Transaction type is This refers to the registration of Type B equipment, as recorded in the records. For equipment type, For the certification mode of Type B equipment, For the gateway identifier, To stabilize the PUF response hash, For platform timestamps, Sign up for the platform.

[0027] After the Type B device is registered, the platform transmits the identifier hash and PUF response information of the gateway and the downstream Type B device through a secure channel established with the gateway device. Synchronize to the home gateway. The gateway device maintains a mapping table in the trusted storage area. .

[0028] (4) Equipment deregistration When equipment is scrapped or replaced, the platform verifies the submitted cancellation request and writes it to the private blockchain, forming an on-chain cancellation record: ; Transaction type is This means the device has been deregistered. The platform marks the device as deregistered and refuses subsequent authentication; for Type B devices, the home gateway is notified to delete them. The corresponding entry.

[0029] S2. Select a tiered authentication path based on device type: The authentication entity selects the corresponding access authentication path based on the device type, access path, and ownership relationship of the object to be authenticated, and incorporates the three types of heterogeneous fire protection IoT terminals into the same identity management framework, so that devices with different access capabilities and resource conditions adopt differentiated authentication paths, while maintaining unified identity management and traceability of authentication results on the fire protection IoT platform side. For gateway devices and Type A devices, the platform executes the authentication process, and the device directly interacts with the platform to complete the authentication process. For Type B devices, the home gateway executes the gateway proxy authentication process, and the Type B device does not directly interact with the platform to complete the authentication process; the gateway completes the authentication locally.

[0030] S3. Perform device authentication and session key negotiation: After selecting the authentication path, the authentication subject and the device execute the corresponding authentication process. During the generation and verification of authentication credentials, the authentication and session key are derived from the same source through the authentication and session key derivation mechanism, so that the session key is generated at the same time as the device authentication is completed. The session key is derived from the same round of dynamic response value and authentication context. The session key is used for subsequent secure communication after successful authentication. Identity authentication and session key derivation are completed in the same authentication process. (1) Gateway device authentication and session key negotiation For gateway devices, gateway device authentication consists of three elements: trusted metrics, PUF response, and non-interactive zero-knowledge proof, and is performed in conjunction with session key negotiation. After the gateway starts up, the bootloader and firmware are re-measured, and the measurement results are calculated. and restore a stable PUF response. The authentication secret is reconstructed by combining the measurement results with the locally stable PUF response. The platform pre-registers the gateway authentication public key generated from this authentication secret. ; If the firmware or bootloader of the gateway device is tampered with, then Change, leading to The one corresponding to the registration The connection failed, and subsequent proof was unsuccessful. This design binds the gateway identity to the current firmware state, preventing attackers from exploiting firmware metric changes to bypass the connection. The proof.

[0031] During authentication, the gateway generates a one-time random number. And calculate the certification commitment value. This commitment value serves as both a commitment in the non-interactive zero-knowledge proof and a temporary public key for the gateway in key negotiation. The gateway device sends a message to the platform consisting of the device identifier, the commitment value, and a timestamp. ; Platform verification timestamp Generate random numbers before timeout Calculate the temporary public key It returns a message consisting of a temporary public key, a platform signature, and a timestamp. ; After the gateway verifies the platform's signature, it uses the authentication context hash, including the gateway identifier, the gateway authentication public key, and the temporary public keys of both parties, to generate a challenge. Calculate the zero-knowledge proof response Generate session key The gateway device calculates the digest based on the session key. Send a message consisting of a proof response and a digest to the platform. ; The platform uses the registered gateway authentication public key to verify this non-interactive zero-knowledge proof, i.e. After successful verification, the platform generates the same session key. and based on the session key verification digest .

[0032] After authentication is approved, the platform calculates the authentication expiration time. ,in, Based on the duration of the authorization, For the current time, This is the trust value for the gateway device. The platform... The protected channel sends an authentication success credential message to the gateway, consisting of the authentication expiration time, timestamp, and digest. ; in, For the certification expiration time, For platform timestamps, For abstract and ; After successful authentication, the gateway is issued authentication success credentials consisting of authentication expiration time, timestamp, and authentication digest; thus, gateway identity verification, firmware integrity verification, and session key negotiation are completed within the same authentication branch.

[0033] (2) Type A device authentication and session key negotiation For Type A devices, Type A device authentication consists of three elements: PUF stable response fragmentation, fragmentation index pseudo-random perturbation, and trust value-driven authentication strength adjustment, which are combined and executed in conjunction with session key negotiation. Specific implementation of the shard index pseudo-random perturbation function: Type A devices and platforms have a built-in fragmented index pseudo-random perturbation function. Pseudo-random perturbation function for slice indexing The input is a set of fragment indices. Random number combinations And the device identifier hash, the output is a set of perturbation permutation indices. .

[0034] Pseudo-random perturbation function for slice index The implementation method is as follows: for those with A set of fragment indices Index of each fragment Calculate separately: ; Forming a perturbation permutation index set .

[0035] The perturbation seed of the fragment index pseudo-random perturbation function contains both platform random numbers and device random numbers, making it difficult for either party to predetermine the final fragment combination order. Furthermore, the device identifier hash participates in the perturbation, which can prevent the fragment index combination between different devices from being directly reused.

[0036] During authentication, Type A devices first send an authentication request to the platform, consisting of a device identifier hash, a device random number, and a timestamp. ; Platform verification timestamp Generate platform random number before timeout And based on the trust value Determine the number of segments to select , ,in and These are the maximum and minimum values ​​for the number of fragments, thus causing the number of fragments participating in certification to change dynamically with the equipment risk. Platform and on the device A certain number of random selections from each response fragment The collection formed by fragment indices The message is then sent to the device; upon receiving the message from the platform, the device calculates the sequence set using a sharded perturbation pseudo-random perturbation function. ,recover Divided into Each response fragment is concatenated with a dynamic response value based on a set of sequence numbers. Subsequently, the device generates a session key based on the dynamic response value. Send an authentication message to the platform consisting of a device identifier hash, a timestamp, and a digest. , among which, abstract .

[0037] The platform reproduces the dynamic response value, verification digest, and derives the same session key according to the same rules, that is, it concatenates the dynamic response value according to the same rules. and calculate and Verification is performed. Once the verification is successful, the platform generates a session key. Calculate the certification expiration time Platform The protected channel sends an authentication success credential message to the device, consisting of the authentication expiration time, timestamp, and digest. ; in, For the certification expiration time, For platform timestamps, For abstract and ; Therefore, Type A device authentication and session key negotiation are completed within the same authentication round.

[0038] (3) Type B device authentication and session key negotiation Type B device authentication is performed locally by the home gateway agent; the gateway periodically broadcasts information including the gateway identifier. Gateway random number and timestamp beacon information ; During authentication, the Type B device restores a stable local PUF response. And generate device random numbers To calculate the authentication code based on the gateway random number and the device random number in a stable response. The device sends a message to the gateway consisting of a device identifier hash, an authentication code, a device random number, and a timestamp. ; The home gateway device queries its local mapping table based on the device identifier hash to obtain the corresponding stable PUF response. and compare and The authentication code is checked for equality. After successful verification, the gateway device and the Type B device derive the session key based on the stable response, the gateway random number, the device random number, and the device identifier hash, respectively. ; Gateway calculates authentication expiration time and through The protected channel sends an authentication success credential message consisting of authentication expiration time, timestamp, and digest to the Type B device. Abstract ; Therefore, Type B devices can complete identity authentication and session key negotiation without direct connection to the platform.

[0039] S4 Authentication Result On-Chain Storage: The authentication subject generates authentication result records. The authentication results of gateway devices and Type A devices are written to the private blockchain by the platform, while the authentication results of Type B devices are directly written to the private blockchain by the host gateway device. (1) On-chain storage of gateway device authentication results After successful authentication, the platform writes the authentication information to a private blockchain, creating an on-chain authentication record. ; Transaction type is This refers to gateway device authentication. In the records, Hash for gateway identifier, For certification commitment value, Zero-knowledge proof response, For platform timestamps, For certification expiration time, Sign up for the platform.

[0040] (2) On-chain storage of certification results for Type A equipment After successful authentication, the platform writes the authentication information to a private blockchain, creating an on-chain authentication record. ; Transaction type is This refers to Type A equipment certification. The record shows... For Type A device identifier hash, For platform random numbers, For device random numbers, For dynamic response value, For platform timestamps, For certification expiration time, Sign up for the platform.

[0041] (3) On-chain storage of certification results for Type B equipment After successful authentication, the gateway device writes the authentication information to the private blockchain, forming an on-chain authentication record: ; Transaction type is This refers to Type B equipment certification. The record shows... Identify hash for Type B devices, For gateway timestamp, For certification expiration time, Sign the gateway. When the amount of authentication result data for Type B devices exceeds a certain scale, the gateway device can aggregate the authentication results of Type B devices and store them as evidence.

[0042] When the private blockchain is temporarily unavailable, the authentication entity caches the device authentication result and rewrites the on-chain evidence record after communication is restored.

[0043] S5 runtime adaptive authentication management based on trust thresholds and random sampling When a device's certification is nearing its expiration date, the certification body will transfer the device's trust value. With trust threshold In comparison, when the device's trust value is higher than the trust threshold, i.e. Random checks are conducted, and the authentication entity generates a random check value ranging from 0 to 1. ,like By randomly selecting customers, a simple renewal can be performed without performing full authentication; otherwise, the device will trigger full authentication. When performing a simple renewal, the certified entity calculates the certification expiration time. ,Right now via session key The protected channel sends a renewal success credential message to the device, consisting of the authentication expiration time, the authentication subject timestamp, and the renewal digest. ,in .

[0044] After the simple renewal is approved, the certified entity writes the renewal information to the private blockchain, forming an on-chain certified renewal record: ; Transaction type is This refers to certification renewal. The record shows... For device identifier hash, For random check values, For the authentication subject's timestamp, For certification expiration time, For signature.

[0045] For complete identity authentication, the authentication subject re-executes the S3 step authentication process according to the corresponding device type.

[0046] For the trust value of a device, the certification body periodically updates the device trust value according to the Sigmoid scoring model, and updates the scoring model weights based on the accumulated positive and negative samples of device certification.

[0047] The certification body uses the Sigmoid scoring model to calculate the device trust value: ; in, , , , All are scoring weights. To increase the success rate of authentication, For authentication anomaly rate, This is a delayed item for the authentication response.

[0048] Authentication success rate , For the number of successful authentications, Number of authentication failures; Authentication anomaly rate , This is the authentication anomaly count, determined by the authenticating entity based on behaviors such as abnormal timestamps, failed authentication codes or zero-knowledge proofs, duplicate random numbers, abnormal authentication frequency, non-home gateway origination, and continued access after authorization expires; authentication response delay item. ,in Average authentication response time (in milliseconds). The attenuation coefficient is set based on experience.

[0049] Weight table for scoring model: ; The scoring model weights are updated based on historical authentication data accumulated over the evaluation cycle. In each evaluation cycle, feature samples are constructed using the authentication success rate, abnormal behavior rate, and response latency of each device for that cycle, and these samples are labeled. When labeling samples, those with high success rates, low abnormal behavior rates, and fast responses are considered trustworthy samples; those with significantly low success rates, high abnormal behavior rates, or excessive latency are considered abnormal samples; and ambiguous samples falling between these two categories are not included in the current training round. Subsequently, using these labeled samples as the training set, the scoring model is trained under supervision using lightweight gradient descent. The weights are adjusted to ensure that the model's output trust score aligns with the sample labels. After training, the new weights replace the old weights and serve as the scoring weights for the next cycle.

[0050] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make modifications, alterations, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT, characterized in that, Includes the following steps: S1. Unified Device Registration: On the fire protection IoT platform, identity records are established for gateway devices, Type A devices and Type B devices respectively, and different registration information is written according to the device type. After registration is completed, the device registration information is written to the private blockchain to form on-chain registration records. S2. Select a tiered authentication path based on device type: The authentication entity selects the corresponding access authentication path based on the device type, access path, and ownership relationship of the object to be authenticated, and incorporates the three types of heterogeneous fire protection IoT terminals into the same identity management framework, so that devices with different access capabilities and resource conditions adopt differentiated authentication paths, while maintaining unified identity management and traceability of authentication results on the fire protection IoT platform side. S3. Perform device authentication and session key negotiation: After selecting the authentication path, the authentication subject and the device execute the corresponding authentication process. During the generation and verification of authentication credentials, the authentication and session key are derived from the same source through the authentication and session key derivation mechanism, so that the session key is generated at the same time as the device authentication is completed. The session key is derived from the same round of dynamic response value and authentication context. The session key is used for subsequent secure communication after the authentication is successful. Identity authentication and session key derivation are completed within the same authentication process; S4 Authentication Result On-Chain Storage: The authentication subject generates authentication result records. The authentication results of gateway devices and Type A devices are written to the private blockchain by the platform, while the authentication results of Type B devices are directly written to the private blockchain by the host gateway device. When the blockchain is temporarily unavailable, the authentication entity caches the device authentication result and rewrites the on-chain evidence after communication is restored. S5 runtime adaptive authentication management based on trust threshold and random sampling: When the device authentication is about to expire, the authentication subject compares the device trust value with the trust threshold value. If the device trust value is higher than the trust threshold value and passes the random sampling, simple renewal can be performed without performing full authentication; otherwise, the device triggers full authentication. When the authentication subject performs a simple renewal, it calculates and updates the authentication expiration time, sends a renewal success credential message consisting of the authentication expiration time, timestamp, and digest to the device through a channel protected by the session key, and writes the on-chain authentication renewal record to the private blockchain after the renewal.

2. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S1 For gateway devices, the platform registers the serial number SN, gateway signature public key, gateway authentication public key and trusted boot metric hash, and generates a gateway identifier. The gateway signature public key is used to confirm the signature identity when submitting evidence records to the private blockchain, the gateway authentication public key is used to verify whether the gateway holds the gateway authentication secret, and the trusted boot metric hash is used to bind the gateway's trusted boot and firmware integrity metric. For Type A and Type B devices, the platform registers the device type, the stabilized PUF response, and generates a device identifier. For Type A devices, the platform also registers the number of shards, and both the platform and Type A devices have built-in pseudo-random perturbation functions for shard indexes. For Type B devices, the platform also registers the home gateway identifier and records the gateway binding relationship. After registration, the platform synchronizes the device identifier hash and PUF response information required for local agent authentication of Type B devices to the home gateway. The platform writes device registration information into a private blockchain, forming a traceable on-chain registration record.

3. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S2 For gateway devices and Type A devices, the platform executes the authentication process, and the device directly interacts with the platform to complete the authentication process. For Type B devices, the home gateway executes the gateway proxy authentication process, and the Type B device does not directly interact with the platform to complete the authentication process; the gateway completes the authentication locally.

4. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S3, for the gateway device, the gateway device authentication consists of three elements: trusted measurement, PUF response, and non-interactive zero-knowledge proof, and is performed in conjunction with session key negotiation. After the gateway starts, the bootloader and firmware are remeasured, and the measurement results are combined with the local stable PUF response to reconstruct the authentication secret; the platform side pre-registers the gateway authentication public key generated by this authentication secret; During authentication, the gateway generates a one-time random number and calculates the authentication commitment value. This commitment value serves as both the commitment for the non-interactive zero-knowledge proof and the gateway's temporary public key in key negotiation. The gateway device sends a message to the platform consisting of the device identifier, the commitment value, and a timestamp. After verifying that the timestamp has not expired, the platform generates a random number, calculates the temporary public key, and returns a message consisting of the temporary public key, the platform signature, and a timestamp. After the gateway verifies the platform signature, it uses the gateway identifier, the gateway authentication public key, and the temporary public keys of both parties to generate a challenge using the authentication context hash, calculates the zero-knowledge proof response, and derives the session key and authentication digest based on the gateway random number and the platform temporary key, and sends an authentication message consisting of the proof response and the digest to the platform. The platform uses the registered gateway authentication public key to verify the non-interactive zero-knowledge proof, and derives the same session key and verification digest based on the platform's random number and the gateway's temporary key; After successful authentication, the gateway is issued authentication success credentials consisting of authentication expiration time, timestamp, and digest. Therefore, gateway identity verification, firmware integrity verification, and session key derivation are completed within the same authentication branch.

5. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S3, for type A devices, type A device authentication consists of three elements: PUF stable response fragmentation, fragmentation index pseudo-random perturbation, and trust value-driven authentication strength adjustment, which are combined and executed in conjunction with session key negotiation. During authentication, Type A devices first send an authentication request to the platform consisting of a device identifier hash, a device random number, and a timestamp; After verifying that the timestamp has not expired, the platform generates a random number and determines the number of fragments to be selected based on the device's trust value. This ensures that the number of fragments participating in authentication dynamically changes with the device's risk. The platform randomly selects a set of fragments indexed by a predetermined number from the device's response fragments and sends it to the device. Upon receiving the message from the platform, the device locally restores a stable PUF response, calculates the perturbed sequence number set using a fragment perturbation pseudo-random perturbation function, and concatenates it with the dynamic response value. Subsequently, the device generates a session key based on the dynamic response value and sends an authentication message to the platform consisting of a device identifier hash, a timestamp, and a digest. The platform derives the same session key, reproduces the dynamic response value and verification digest according to the same rules, and sends the authentication success credential information consisting of authentication expiration time, timestamp, and authentication digest to the device; Therefore, Type A device authentication and session key negotiation are completed within the same authentication round.

6. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S3, for Type B devices, Type B device authentication is handled by the local agent of the home gateway; the gateway periodically broadcasts beacon information containing the gateway identifier, gateway random number, and timestamp. During authentication, the Type B device restores a local stable PUF response and generates a device random number. It then calculates the HMAC authentication code based on the gateway random number and the device random number using the stable response, and sends a message to the gateway consisting of the device identifier hash, authentication code, device random number, and timestamp. The home gateway device queries the local mapping table based on the device identifier hash to obtain the corresponding stable PUF response and verifies the authentication code. After successful verification, the gateway device and the type B device derive the session key based on the stable response, the gateway random number, the device random number, and the device identifier hash, respectively. The gateway sends an authentication success credential message consisting of authentication expiration time, timestamp, and digest to the type B device. Therefore, Type B devices can complete authentication and session key negotiation without direct connection to the platform.

7. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: The authentication result record in step S4 includes at least the device identifier summary, authentication process information, timestamp, authentication expiration time, and signature; the private blockchain saves on-chain registration records and on-chain deregistration records in step S1, on-chain authentication records in step S4, and on-chain authentication renewal records in step S5, to provide an immutable and traceable audit basis.

8. The lightweight authentication and on-chain evidence storage method for heterogeneous terminals in the fire protection IoT as described in claim 1, characterized in that: In step S5, for type A devices, the platform dynamically adjusts the number of segments selected based on the trust value, thereby enabling highly trusted devices to use lower authentication strength and low-trust or abnormal devices to use higher authentication strength when performing full authentication. The platform and gateway devices adjust the trust threshold based on the device authentication status.

Images