Iot terminal access authentication and data security collaborative control method

Abstract

The present application relates to a method for the coordinated control of access authentication and data security of an Internet of Things terminal, and belongs to the technical field of Internet of Things security, comprising: an Internet of Things terminal sending an access authentication request to an access authentication node, the access authentication node generating an authentication context after the access authentication is passed, the Internet of Things terminal generating an authentication associated credential based on the authentication context, and carrying a channel number, a message sequence number, a data type, a data security level and the authentication associated credential in a security message header of a starting service data message; the access authentication node verifying the security message header according to the authentication context, opening a service data channel when the verification is passed, switching to a security restricted channel when the verification is not passed, and the subsequent service data message carrying a continuity credential generated from the previous message sequence number, the current message sequence number and the authentication context, so as to maintain the coordinated control of access authentication and data transmission, and reduce the data security risks caused by illegal access, message forgery, replay and sequence number abnormalities.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security technology, specifically to a method for collaborative control of IoT terminal access authentication and data security. Background Technology

[0002] In existing technologies, IoT terminal access authentication and business data transmission security are typically handled by authentication processes, encrypted transmission processes, or gateway access control processes, respectively. Once authentication is successful, the business link is opened, and subsequent data packets mostly rely on established sessions, keys, or channel states for protection. It is difficult to maintain the correlation control between access authentication results, data types, data security levels, and packet continuity as each business data packet enters the business data channel. For example, Chinese patent CN117061164B discloses an IoT system access security processing method, which realizes the security verification of IoT network elements by IoT terminals through access request response information, and realizes the security verification of IoT terminals by core network elements through authentication request information. At the same time, it also uses encryption keys and integrity keys to encrypt and protect the integrity of the data packets to be transmitted to prevent eavesdropping, tampering, and replay attacks.

[0003] Existing technologies also propose continuous access control for IoT terminals based on the zero-trust concept. For example, Chinese patent CN115150208B discloses a secure access method and system for IoT terminals based on zero trust. This method deploys an IoT secure access gateway at the IoT boundary, performs baseline checks on IoT terminals before data access operations, constructs access control based on identity authentication and security status assessment, and progressively performs real-time checks for anomalies during data access to promptly detect abnormal terminals and dynamically adjust access control permissions. While such solutions can improve terminal access security and operational status monitoring capabilities, their control focus is typically on terminal identity, baseline status, gateway policies, or network-side trust relationships. They have not yet fully addressed the collaborative constraints between access authentication results and the initial service data packets, subsequent service data packets, data types, data security levels, channel parameters, and packet sequence number continuity.

[0004] Therefore, in application environments with a large number of IoT terminals, diverse access scenarios, significant differences in data types, and varying security level requirements, if authentication is only performed once during the access phase, or if data transmission is protected solely by communication keys, gateway filtering policies, and terminal status monitoring, problems may arise such as a disconnect between the authentication status and the open state of the business data channel, a lack of unified verification of security attributes in the message header, abnormal messages still occupying the business channel, and the inability of continuity credentials to effectively constrain subsequent business messages. Especially in cases where terminals are counterfeited, the initial message is tampered with, message sequence numbers are missing, replay messages are mixed in, or high-security-level data is transmitted mixed with ordinary data, existing solutions struggle to provide fine-grained control of the business data channel based on the authentication context before the channel is opened, and also struggle to maintain the binding relationship between access authentication and secure data transmission based on message continuity after the channel is opened. Therefore, a collaborative control method is needed that can unify and integrate access authentication, channel opening, data type identification, data security level verification, and subsequent message continuity maintenance. Summary of the Invention

[0005] The purpose of this invention is to provide a method for collaborative control of IoT terminal access authentication and data security, thereby addressing some of the shortcomings and deficiencies pointed out in the background art.

[0006] The present invention adopts the following technical solution to solve the above-mentioned technical problems: The Internet of Things (IoT) terminal sends an access authentication request to the access authentication node. The access authentication request includes the terminal identifier, a random variable, and information about the data channel to be established. After successful access authentication, the access authentication node generates an authentication context, which includes a terminal identifier, a random variable, channel parameters generated based on the data channel information to be established, the allowed data types, and the data security level. The IoT terminal generates authentication associated credentials based on the authentication context and carries the channel number, message sequence number, data type, data security level, and authentication associated credentials in the security header of the initial business data message. The access authentication node verifies the security message header according to the authentication context. If the verification is successful, the service data channel corresponding to the channel parameters is opened. If the verification fails, the node switches to a security-restricted channel that allows the transmission of heartbeat, security log, or exception description messages. Subsequent service data messages after the service data channel is opened carry continuous credentials generated by the previous message sequence number, the current message sequence number, and the authentication context to maintain coordinated control of access authentication and data transmission.

[0007] Furthermore, the business data portion of the initial business data message carries a field identifier digest and field security level of the data to be transmitted before the business data channel is opened; after the access authentication node verifies the security message header, it returns a field release permission, and the IoT terminal uploads the data field corresponding to the field release permission.

[0008] Furthermore, after the IoT terminal is switched to the secure restricted channel, the exception description message carries the random quantity echo value, the channel parameter echo value, and a digest of the generated continuity credentials; the access authentication node generates new channel parameters based on the random quantity echo value, the channel parameter echo value, and the digest of the generated continuity credentials, and the IoT terminal re-initiates access authentication based on the new channel parameters.

[0009] Furthermore, the continuity credential is accepted once by the access authentication node within the verification period corresponding to the current message sequence number; when a subsequent service data message carries a used continuity credential, is missing a previous message sequence number, or the current message sequence number does not meet the preset continuity rule, the access authentication node prevents the subsequent service data message from entering the service data channel and updates the authentication context.

[0010] Furthermore, the field release permission carries the field release order and single release limit. The IoT terminal uploads data fields according to the field release order, and the number of data fields uploaded in a single session is less than or equal to the single release limit. After the uploaded data field matches the digest value of the field identifier digest, the access authentication node returns the next field release permission.

[0011] Furthermore, the field release permission is bound to the sequence number of the initial business data message, and the IoT terminal carries the sequence number when uploading the data field; when the data field does not carry the sequence number, or the sequence number carried is inconsistent with the sequence number of the initial business data message, the access authentication node prevents the data field from entering the business data channel.

[0012] Furthermore, the access authentication node returns field release permits with different usage counts, field ranges, or segment ranges based on the field security level; data fields with a security level lower than a preset level threshold correspond to a single release permit, while data fields with a security level reaching the preset level threshold correspond to segmented release permits. Before obtaining a subsequent segmented release permit, the IoT terminal does not upload the data field corresponding to the subsequent segment.

[0013] Furthermore, after receiving the continuity credential, the access authentication node generates a credential consumption record corresponding to the current message sequence number; when subsequent service data messages carry the continuity credential corresponding to the credential consumption record again, the access authentication node identifies the subsequent service data message as a replay message and updates the credential generation parameters in the authentication context based on the replay message.

[0014] Furthermore, when the current message sequence number does not meet the preset continuity rule, the access authentication node allows the IoT terminal to send a continuity repair message without carrying business data. The continuity repair message carries the previous message sequence number and the current message sequence number. The access authentication node updates the authentication context according to the continuity repair message and keeps the business data channel from receiving subsequent business data messages until the update is completed.

[0015] Furthermore, the access authentication node forms a sequence number gap interval based on the missing sequence number between the previous message sequence number and the current message sequence number, and returns a single repair challenge to the IoT terminal; the IoT terminal generates repair credentials based on the single repair challenge, the sequence number gap interval, and the authentication context, and the continuous repair message does not carry the service data corresponding to the sequence number gap interval; after the repair credentials match the authentication context, the access authentication node restores the service data channel to receive subsequent service data messages.

[0016] This invention enables IoT terminals to send access authentication requests, including terminal identifiers, random variables, and information about the data channel to be established, to access authentication nodes. Upon successful authentication, the access authentication node generates an authentication context containing terminal identifiers, random variables, channel parameters, allowed data types, and data security levels. This transforms the access authentication result from a static basis for determining access permission to a fundamental control mechanism for opening service data channels and securely verifying service data packets. The IoT terminal includes the channel number, packet sequence number, data type, data security level, and authentication credentials in the security header of the initial service data packet. The access authentication node verifies this information based on the authentication context, improving the consistency and verifiability between the initial service data packet and the already authenticated access status.

[0017] This invention opens the service data channel corresponding to the channel parameters when the security message header verification passes, and switches to a security-restricted channel that only allows the transmission of heartbeat, security log, or anomaly description messages when verification fails. This prevents service data with invalid authentication associations from directly entering the service data channel, reducing data security risks caused by unauthorized access, message forgery, or continued transmission of abnormal messages. Simultaneously, after the service data channel is opened, subsequent service data messages carry a continuity credential generated from the previous message sequence number, the current message sequence number, and the authentication context to maintain coordinated control of access authentication and data transmission. This ensures that subsequent data transmission is continuously constrained by the authentication context, improving the ability to identify and block scenarios such as message replay, abnormal sequence numbers, channel impersonation, and data security level mismatches. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the collaborative control process for IoT terminal access authentication and data security in this invention.

[0019] Figure 2 This is a timing diagram of access authentication and business data channel opening in Embodiment 1 of the present invention.

[0020] Figure 3 This is a diagram of the field release batch and license validity window in Embodiment 1 of the present invention.

[0021] Figure 4 This is a verification diagram showing the binding of field security level and message sequence number in Embodiment 1 of the present invention.

[0022] Figure 5 This is a timing diagram of continuous credential verification and replay identification in Embodiment 2 of the present invention.

[0023] Figure 6 This is a diagram showing the sequence number void interval and the actual sequence number to be repaired in Embodiment 2 of the present invention.

[0024] Figure 7 This is the effective boundary map of a single repair challenge in Embodiment 2 of the present invention. Detailed Implementation

[0025] As attached Figure 1As shown, in this embodiment, the IoT terminal access authentication and data security collaborative control method can be jointly executed by the IoT terminal and the access authentication node. Before accessing the network, the IoT terminal sends an access authentication request to the access authentication node. The access authentication request carries the terminal identifier, a random variable, and information about the data channel to be established. The information about the data channel to be established includes the channel type to be used, the data transmission direction, the data type of the service, the terminal-side channel capabilities, and the requested security control level. After receiving the access authentication request, the access authentication node performs access authentication on the IoT terminal based on the terminal identifier and the random variable, and generates an authentication context after successful authentication. The authentication context includes the terminal identifier, the random variable, the channel parameters generated based on the information about the data channel to be established, the allowed data types, and the data security level.

[0026] Channel parameters include channel number, channel open status, channel validity period, and credential generation parameters. The IoT terminal generates authentication-associated credentials based on the authentication context and writes the channel number, message sequence number, data type, data security level, and authentication-associated credentials into the security header of the initial service data packet. The authentication-associated credentials are generated by the IoT terminal based on the terminal identifier, random variable, channel number, data type, data security level, and credential generation parameters, and are used to characterize the correspondence between the initial service data packet and this access authentication process. After receiving the initial service data packet, the access authentication node verifies the security header based on the authentication context. The verification of the security header includes consistency checks on the channel number, message sequence number, data type, data security level, and authentication-associated credentials.

[0027] When verification is successful, the access authentication node opens the service data channel corresponding to the channel parameters, enabling the IoT terminal to transmit service data through the service data channel. When verification fails, the access authentication node switches the IoT terminal to a security-restricted channel, allowing the IoT terminal to transmit only heartbeat, security log, or exception description messages. After the service data channel is opened, subsequent service data packets sent by the IoT terminal carry continuity credentials. The continuity credentials are generated from the previous packet sequence number, the current packet sequence number, and the authentication context. By verifying the continuity credentials, the access authentication node confirms that subsequent service data packets remain associated with the completed access authentication process, thereby achieving coordinated control between the access authentication and data transmission processes.

[0028] In this embodiment, to reduce the risk of data exposure before the business data channel is opened, the IoT terminal does not directly upload the complete data to be transmitted when sending the initial business data message. Instead, it carries the field identifier digest and field security level of the data to be transmitted in the business data part of the initial business data message. The field identifier digest is used to characterize the identity information of each data field in the data to be transmitted, and the field security level is used to characterize the security control requirements corresponding to each data field. The field identifier digest is obtained by digesting at least one of the following: field name, field position, field length, data type of the field, or field version information. The field security level is determined by the field security policy preset by the access authentication node and corresponds to the data security level in the authentication context. After receiving the initial business data message, the access authentication node first verifies the security message header according to the authentication context. After the security message header verification is successful, the access authentication node generates a field release permit based on the field identifier digest and field security level and returns the field release permit to the IoT terminal. The field release permit includes a permit identifier, a permit validity status, and the range of data fields allowed to be uploaded. After receiving the field release permission, the IoT terminal only uploads the data field corresponding to the field release permission, so that the data to be transmitted can enter the business data channel under the joint constraints of the access authentication result and the field-level security control result.

[0029] In one implementation, the field release permission carries the field release order and a single release limit. The IoT terminal uploads data fields sequentially according to the field release order, controlling the number of data fields uploaded in a single batch to be less than or equal to the single release limit. After receiving the data fields uploaded by the IoT terminal, the access authentication node performs a digest value consistency check between the uploaded data fields and the field identifier digest carried in the initial business data message. The digest value consistency check includes reconstructing a verification digest based on the field name, field position, field length, data type, or field version information of the uploaded data fields, and comparing the verification digest with the field identifier digest carried in the initial business data message. If the check matches, the access authentication node returns the next field release permission, allowing the IoT terminal to continue uploading the next batch of data fields. If the check does not match, the access authentication node rejects the uploaded data fields from entering the business data channel and updates the field release status in the authentication context. In this way, the access authentication node can release business data upload permissions in batches according to field granularity, avoiding excessive data uploads by IoT terminals when the business data channel is first opened.

[0030] In another implementation, the field release permission is bound to the sequence number of the initial business data message. When the IoT terminal uploads a data field according to the field release permission, it includes the sequence number corresponding to the initial business data message in the data field upload message. After receiving the data field, the access authentication node determines whether the data field upload message carries a sequence number and whether the carried sequence number matches the sequence number of the initial business data message. If the data field upload message does not carry a sequence number, or if the carried sequence number does not match the sequence number of the initial business data message, the access authentication node prevents the data field from entering the business data channel. Thus, a binding relationship is formed between the field release permission, the initial business data message, and the subsequently uploaded data field, thereby preventing the field release permission from being reused by other messages.

[0031] In another implementation, the access authentication node returns field release permissions with different usage counts, field ranges, or segment ranges based on the field security level. Data fields with security levels below a preset threshold receive a single field release permission. This preset threshold is pre-set by the access authentication node based on the data security level and field security policy. After obtaining a single field release permission, the IoT terminal can upload the data field corresponding to that single field release permission. Data fields with security levels reaching the preset threshold receive segmented field release permissions. After obtaining a segmented field release permission, the IoT terminal only uploads the data fields corresponding to that segment. Before obtaining a subsequent segmented field release permission, the IoT terminal does not upload the data fields corresponding to that subsequent segment. Through this method, the access authentication node can perform differentiated release control of data fields based on their security levels, allowing low-security-level data fields and high-security-level data fields to have different upload constraints, thereby improving field-level security control capabilities during business data transmission.

[0032] In this embodiment, when the access authentication node fails to verify the security header of the initial service data packet, or detects an authentication association anomaly during subsequent service data transmission, the access authentication node switches the IoT terminal to the secure restricted channel. Authentication association anomalies include invalid authentication association credentials, mismatch between continuity credentials and authentication context, inconsistency between channel parameters and authentication context, or abnormal packet sequence number status. After entering the secure restricted channel, the IoT terminal no longer uploads service data through the service data channel, but instead sends an anomaly description message to the access authentication node. The anomaly description message carries a random quantity echo value, a channel parameter echo value, and a digest of the generated continuity credentials. The random quantity echo value is used to enable the access authentication node to confirm the association between this anomaly description message and the original access authentication request. The channel parameter echo value is used to enable the access authentication node to confirm the current channel parameter status held by the IoT terminal. The digest of the generated continuity credentials reflects the continuity control status formed by the IoT terminal before entering the secure restricted channel. Upon receiving the anomaly message, the access authentication node verifies and updates the channel state in the original authentication context based on the echoed random value, the echoed channel parameter value, and the digest of the generated continuity credentials, and generates new channel parameters. Subsequently, the access authentication node provides the new channel parameters to the IoT terminal. The IoT terminal re-initiates access authentication based on the new channel parameters, enabling the access process after the anomaly to re-establish a valid authentication context and avoiding the continued use of channel parameters from the abnormal state for business data transmission.

[0033] In this embodiment, after the service data channel is opened, subsequent service data packets sent by the IoT terminal need to carry continuity credentials. The continuity credential corresponds to the current packet sequence number and can only be accepted once by the access authentication node within the verification period corresponding to the current packet sequence number. The verification period is determined by the channel validity period recorded in the authentication context or the validity status of the credentials issued by the access authentication node. After receiving a subsequent service data packet, the access authentication node performs continuity verification on the subsequent service data packet based on the authentication context, the previous packet sequence number, the current packet sequence number, and the continuity credential. When a subsequent service data packet carries a used continuity credential, or is missing a previous packet sequence number, or the current packet sequence number does not meet the preset continuity rules, the access authentication node determines that the subsequent service data packet has a continuity anomaly and prevents the subsequent service data packet from entering the service data channel. The preset continuity rules include the current packet sequence number being within the acceptable sequence number range recorded in the authentication context, the current packet sequence number not being a duplicate of an accepted packet sequence number, and the current packet sequence number forming a continuous or repairable sequential relationship with the previous packet sequence number. At the same time, the access authentication node updates the authentication context, so that subsequent verification processes can continue to be executed based on the updated authentication status.

[0034] In one implementation, after receiving a continuity credential, the access authentication node generates a credential consumption record corresponding to the current message sequence number. The credential consumption record indicates that the continuity credential corresponding to the current message sequence number has been used. When subsequent service data packets carry the continuity credential corresponding to the credential consumption record again, the access authentication node identifies the subsequent service data packet as a replay packet and updates the credential generation parameters in the authentication context based on the replay packet. Updates may include marking the used continuity credential as unavailable, adjusting the status of the credential generation parameters, or requiring the IoT terminal to re-initiate access authentication. Through this processing method, the access authentication node can prevent the reuse of used continuity credentials, thereby reducing the risk of subsequent service data packets being replayed into the service data channel.

[0035] In another implementation, when the access authentication node determines that the current message sequence number does not meet the preset continuity rule, it allows the IoT terminal to send a continuity repair message without carrying service data. The continuity repair message carries the sequence number of the previous message and the current message sequence number. The access authentication node updates the authentication context based on the continuity repair message and keeps the service data channel from receiving subsequent service data messages until the update is complete. The access authentication node forms a sequence number gap interval based on the missing message sequence number between the previous and current message sequence numbers and returns a single repair challenge to the IoT terminal. The single repair challenge includes a challenge identifier, challenge validity status, and repair restriction information. The IoT terminal generates repair credentials based on the single repair challenge, the sequence number gap interval, and the authentication context, and the continuity repair message does not carry the service data corresponding to the sequence number gap interval. After the repair credentials match the authentication context, the access authentication node resumes the reception of subsequent service data messages through the service data channel. Example

[0036] In this embodiment, the IoT terminal access authentication and data security collaborative control method is jointly executed by the IoT terminal and the access authentication node. The IoT terminal can be an industrial sensor terminal deployed by an organization. Before accessing the network, the industrial sensor terminal sends an access authentication request to the access authentication node. The access authentication request includes a terminal identifier, a random variable, and information about the data channel to be established. The terminal identifier can be set to T-AC-017, the random variable is one-time data generated during the access authentication process, and the information about the data channel to be established includes the channel type to be used, the data transmission direction, the data type of the service, the terminal-side channel capabilities, and the requested data security level.

[0037] After receiving the access authentication request, the access authentication node performs access authentication on the IoT terminal based on the terminal identifier and a random variable. Upon successful authentication, the access authentication node generates an authentication context, which includes the terminal identifier, the random variable, channel parameters generated based on the data channel information to be established, the allowed data types to be transmitted, and the data security level. The channel parameters include the channel number, channel open status, channel validity period, and credential generation parameters. In a specific application example, the access authentication node assigns the IoT terminal the channel number CH-03, determines the allowed data types to be transmitted as sensor status data and operational monitoring data, and sets the data security level to L3.

[0038] The IoT terminal generates authentication credentials based on the authentication context and includes the channel number, message sequence number, data type, data security level, and authentication credentials in the security header of the initial business data message. In a specific application example, the message sequence number of the initial business data message is 1001. After receiving the initial business data message, the access authentication node verifies the security header according to the authentication context. The verification includes consistency checks on the channel number, message sequence number, data type, data security level, and authentication credentials. If the verification passes, the access authentication node opens the business data channel corresponding to the channel parameters; if the verification fails, the access authentication node switches the IoT terminal to a security-restricted channel, allowing the IoT terminal to only transmit heartbeat, security log, or exception description messages. Figure 2 The above process is illustrated by three execution links: IoT terminal, access authentication node, and channel status. The access authentication request, authentication processing, authentication context generation, initial business data message, security message header verification, field release permission, and permission field upload are sequentially linked. The path of successful verification leads to the opening of the business data channel, while the path of unsuccessful verification leads to the security-restricted channel, thus demonstrating the direct control relationship between the access authentication result and the subsequent business data channel status.

[0039] To mitigate the risk of data exposure before the business data channel is opened, IoT terminals do not directly upload the complete data to be transmitted when sending initial business data messages. Instead, they carry field identifier digests and field security levels of the data to be transmitted within the business data portion of the initial business data message. The field identifier digest characterizes the identity information of each data field in the data to be transmitted, and the field security level characterizes the security control requirements corresponding to each data field. The field identifier digest can be obtained by digesting at least one of the following: field name, field position, field length, data type, or field version information. The field security level is determined by the field security policy preset by the access authentication node and corresponds to the data security level in the authentication context.

[0040] After the access authentication node verifies the security message header, it generates a field release permit based on the field identifier digest and field security level, and returns the field release permit to the IoT terminal. The field release permit includes a permit identifier, permit validity status, the range of data fields allowed to be uploaded, the field release order, and the maximum release limit per instance. Upon receiving the field release permit, the IoT terminal only uploads the data fields corresponding to the permit, ensuring that the data to be transmitted enters the business data channel under the combined constraints of the access authentication result and the field-level security control result.

[0041] In a specific application example, the data to be transmitted includes 12 data fields, with security levels of L1, L2, and L3. The access authentication node sets the maximum number of fields released at one time to 4. To determine the number of field release batches required for the IoT terminal to complete this round of field upload, the following formula is used:

[0042] in, This field indicates the number of release batches. This indicates the total number of data fields to be released. Indicates the maximum release limit per instance. This indicates rounding up. The derivation of this formula is as follows: Since each field releases a maximum of [number] uploads... The total number of data fields to be released. Cannot be During integer division, the remaining data field still needs to occupy one field release process, therefore it is necessary to... and The ratio is rounded up. In this example, , ,but:

[0043] Therefore, it can be seen that IoT terminals need to upload data fields in three batches. The access authentication node first returns a release permission for the first field, allowing the IoT terminal to upload the first four data fields in the order of field release. After the uploaded data field matches the digest value of the field identifier digest, it returns a release permission for the next field, allowing the IoT terminal to continue uploading the next batch of data fields. If the digest values ​​do not match, the access authentication node rejects the data fields uploaded in this batch from entering the business data channel and updates the field release status in the authentication context. Figure 3 The 12 data fields are divided into 3 release batches of 4 fields each, and the release order of the fields is represented by three consecutive time intervals. This can intuitively reflect the constraint effect of the single release limit on the field upload rhythm.

[0044] To control the effective scope of field release permissions, the access authentication node also determines the required effective window for this round of field release based on the number of field release batches. The effective window is calculated using the following formula:

[0045] in, This indicates the valid window for the license required to complete this round of field release. This field indicates the number of release batches. This represents the preset validity period for a single batch of field release permissions. The derivation of this formula is as follows: the access authentication node releases fields in batches, and each batch of field release permissions occupies a preset validity period. ,Finish The required license validity window for batch field releases is the product of the number of field release batches and the preset validity period of a single batch field release license. In this example, , seconds, then:

[0046] Therefore, the access authentication node sets the validity window for this round of field release permission to 15 seconds. Within this validity window, IoT terminals upload data fields in the order they are released. After this validity window expires, the access authentication node will no longer accept data field upload requests associated with the corresponding field release permission and will require the IoT terminal to re-obtain the field release permission. Figure 3 The license validity window covers the release segments of the three fields, and the single batch validity boundary corresponds to the time boundary of the release license for each batch of fields, so that the correspondence between the number of field release batches and the license validity window can be consistent with the above calculation results.

[0047] In this embodiment, the field release permission is bound to the sequence number of the initial business data message. When the IoT terminal uploads a data field according to the field release permission, it carries the sequence number 1001 corresponding to the initial business data message in the data field upload message. After receiving the data field, the access authentication node determines whether the data field upload message carries the sequence number and whether the carried sequence number is consistent with the sequence number of the initial business data message. When the data field upload message does not carry the sequence number, or the carried sequence number is inconsistent with the sequence number of the initial business data message, the access authentication node prevents the data field from entering the business data channel. Figure 4 The field upload verification process is represented by the binding relationship between field sequence number, field security level, and message sequence number. The binding range of message sequence number 1001 covers all data fields to be transmitted. The access authentication node can use this to determine whether the field release permission has been reused by other messages.

[0048] In this embodiment, the access authentication node also returns field release permits with different usage counts, field ranges, or segment ranges based on the field security level. Data fields with security levels below a preset threshold correspond to single-use field release permits. After obtaining a single-use field release permit, the IoT terminal can upload the data field corresponding to that single-use field release permit. Data fields with security levels reaching the preset threshold correspond to segmented field release permits. After obtaining a previous segmented field release permit, the IoT terminal only uploads the data field corresponding to that segment; it does not upload the data field corresponding to the next segment until it obtains a subsequent segmented field release permit. Figure 4 The L1 and L2 level fields use a single field release permission, while the L3 level fields are above the preset level threshold and use a segmented field release permission, reflecting the process of the access authentication node implementing differentiated release control based on the field security level.

[0049] In a specific application example, the access authentication node sets the preset security level threshold to L3. When the security level of a data field is L1 or L2, the access authentication node returns a single field release permission, allowing the IoT terminal to upload the corresponding data field once within the valid permission state. When the security level of a data field is L3, the access authentication node returns a segmented field release permission, allowing the IoT terminal to first upload the data field corresponding to the first segment, and after the access authentication node completes the digest value consistency verification, it uploads the data field corresponding to the next segment according to the subsequent segment field release permission. Figure 4 The segmented upload range of the L3 level fields corresponding to segment 1 and segment 2 indicates that the high security level fields are not all entered into the channel at once after the business data channel is opened, but are subject to the continued constraint of the release permission of the subsequent segment field.

[0050] After the business data channel is opened, subsequent business data packets sent by the IoT terminal carry continuity credentials. These continuity credentials are generated from the previous packet sequence number, the current packet sequence number, and the authentication context. The access authentication node verifies these continuity credentials to confirm that subsequent business data packets remain associated with the completed access authentication process. Thus, the authentication association credentials of the initial business data packet, the field release permission, the packet sequence number, and the continuity credentials of subsequent business data packets together form a collaborative control relationship. Figure 2 The continuity maintenance status is linked to the business data channel open status, indicating that after the field upload is completed, subsequent business data packets still need to maintain the association with the original access authentication process through continuity credentials.

[0051] By using the above method, the access authentication node does not directly receive complete business data before the business data channel is opened. Instead, it releases data field upload permissions in batches based on the binding relationship between field identifier digest, field security level, field release order, single release limit, and message sequence number. For data fields that reach the preset level threshold, permission is released in segments, thereby reducing the risk of data exposure when the business data channel is first opened and improving field-level security control capabilities. Example

[0052] In this embodiment, the IoT terminal access authentication and data security collaborative control method is jointly executed by the IoT terminal and the access authentication node. The IoT terminal can be a gateway-type IoT terminal deployed by an organization. Before accessing the network, the IoT terminal sends an access authentication request to the access authentication node. The access authentication request includes a terminal identifier, a random variable, and information about the data channel to be established. The terminal identifier can be set to T-CN-032, and the information about the data channel to be established includes the proposed service data channel number, data transmission direction, service data type, and requested data security level.

[0053] After receiving the access authentication request, the access authentication node performs access authentication on the IoT terminal based on the terminal identifier and a random variable. Upon successful authentication, the access authentication node generates an authentication context, which includes the terminal identifier, the random variable, channel parameters generated based on the data channel information to be established, the allowed data types to be transmitted, and the data security level. The channel parameters include the service data channel number, channel open status, channel validity period, and credential generation parameters. In a specific application example, the access authentication node assigns the IoT terminal the service data channel number CH-06 and determines the allowed data types to be transmitted as device operation data and gateway status data.

[0054] The IoT terminal generates authentication credentials based on the authentication context and includes the channel number, message sequence number, data type, data security level, and authentication credentials in the security header of the initial business data message. The access authentication node verifies the security header according to the authentication context. If the verification is successful, the business data channel corresponding to the channel parameters is opened. If the verification fails, the IoT terminal is switched to a security-restricted channel, allowing the IoT terminal to transmit only heartbeat, security log, or exception description messages.

[0055] After the business data channel is opened, the IoT terminal sends subsequent business data messages. These subsequent business data messages carry the sequence number of the previous message, the sequence number of the current message, and a continuity credential. The continuity credential is generated from the sequence number of the previous message, the sequence number of the current message, and the authentication context, and corresponds to the current message sequence number. Upon receiving the subsequent business data message, the access authentication node verifies the continuity of the subsequent business data message based on the authentication context, the sequence number of the previous message, the sequence number of the current message, and the continuity credential. Combined with... Figure 5 As shown in the timing relationship, after the initial business data message triggers the opening of the business data channel, the subsequent business data messages corresponding to message sequence numbers 2049 and 2050 enter the continuity verification process in sequence. After receiving the corresponding continuity credentials, the access authentication node forms a credential consumption record, so that each current message sequence number and its continuity credentials form a one-time use relationship.

[0056] In this embodiment, the continuity credential is accepted by the access authentication node only once within the verification period corresponding to the current message sequence number. After accepting the continuity credential, the access authentication node generates a credential consumption record corresponding to the current message sequence number. This credential consumption record is used to indicate that the continuity credential corresponding to the current message sequence number has been used up. When subsequent service data packets carry the continuity credential corresponding to the credential consumption record again, the access authentication node identifies the subsequent service data packets as replay packets and updates the credential generation parameters in the authentication context based on the replay packets. Figure 5 When duplicate continuous credentials arrive at the access authentication node, they are directed to the replay message identification and authentication context update process. This indicates that the credential consumption record is not only used to record the accepted status, but also to provide a verification basis for the identification of subsequent duplicate credentials.

[0057] When a subsequent business data message carries already used continuity credentials, is missing the sequence number of a previous message, or the current message sequence number does not meet the preset continuity rules, the access authentication node determines that the subsequent business data message has a continuity anomaly and prevents the subsequent business data message from entering the business data channel. The preset continuity rules include that the current message sequence number is within the acceptable sequence number range of the authentication context record, the current message sequence number does not duplicate the sequence number of an accepted message, and the current message sequence number forms a continuous or repairable sequential relationship with the previous message sequence number.

[0058] In a specific application example, the sequence number of the previous valid message confirmed by the access authentication node is 2048, and the sequence number of the current message carried by the subsequent service data message is 2052. To determine the sequence number gap between the previous valid message number and the current message number, the following calculation formula can be used:

[0059] in, This indicates the number of missing message sequence numbers within the sequence number gap interval. Indicates the current message sequence number. Indicates the sequence number of the previous valid message confirmed by the access authentication node, symbol This indicates the calculation of the sequence number difference. The derivation of this formula is as follows: Current message sequence number The sequence number of the previous valid message The sequence number difference between the two includes the current message sequence number itself, so 1 needs to be subtracted to obtain the number of missing message sequence numbers between them. In this example, , ,but:

[0060] Therefore, the sequence number gaps include three theoretically missing sequence numbers: 2049, 2050, and 2051. If the access authentication node has already recorded the credential consumption records corresponding to message sequence numbers 2049 and 2050, it means that the continuous credentials corresponding to 2049 and 2050 have been used up, and the missing message sequence number that actually needs to be repaired is 2051. Figure 6 The message sequence number status, credential status, and repair judgment status from 2048 to 2052 are displayed accordingly. Among them, 2048 is the previous valid message sequence number, 2052 is the current message sequence number, 2049 and 2050 are located in the theoretical sequence number gap range but have credential consumption records, and 2051 is identified as the actual sequence number to be repaired, thus distinguishing between the theoretical missing number and the actual repair object.

[0061] At this time, the access authentication node maintains the business data channel and stops receiving subsequent business data packets, while allowing the IoT terminal to send a continuity repair message without carrying business data. The continuity repair message carries the sequence number of the previous packet and the sequence number of the current packet. After receiving the continuity repair message, the access authentication node forms a sequence number gap interval based on the missing sequence number between the previous and current packet numbers, and returns a single repair challenge to the IoT terminal. The IoT terminal generates repair credentials based on the single repair challenge, the sequence number gap interval, and the authentication context, and the continuity repair message does not carry the business data corresponding to the sequence number gap interval. Figure 6 The actual sequence number to be repaired, 2051, corresponds to the annotation that the continuity repair message does not carry business data, indicating that the repair process is used to restore the continuity of the sequence number, rather than to retransmit the business data content in the gap of the sequence number.

[0062] To limit the acceptance scope of a single repair challenge, the access authentication node determines the expiration time based on the start time and the valid duration of the single repair challenge, which can be calculated using the following formula:

[0063] in, This indicates the moment of failure for a single repair challenge. This indicates the start time of a single repair challenge returned by the access authentication node. Indicates the effective duration of a single repair challenge, symbol This represents the sum of time increments. The derivation of this formula is as follows: Single repair challenge from the return time... Start timing, within the valid duration It expires upon expiration, therefore the expiration time is... This is the sum of the start time and the effective duration. In this example, Second, seconds, then:

[0064] Therefore, the single repair challenge expires at 28 seconds. If the IoT terminal returns repair credentials before 28 seconds, the access authentication node matches and verifies the repair credentials based on the authentication context, the single repair challenge, and the sequence number gap range. If the IoT terminal returns repair credentials at or after 28 seconds, the access authentication node no longer accepts the repair credentials and keeps the business data channel from receiving subsequent business data packets. Figure 7 The effective range for a single repair challenge is set at 20 to 28 seconds, and the range after 28 seconds is set at the end of the challenge. At the same time, the channel status is kept at the point of stopping receiving subsequent business data packets. This means that the time boundary not only restricts whether the repair credentials are accepted, but also restricts the triggering conditions for the business data channel to resume receiving.

[0065] After repairing the mismatch between the repaired credentials and the authentication context, the access authentication node updates the continuity verification status in the authentication context and resumes the reception of subsequent business data packets through the business data channel. If the repaired credentials do not match the authentication context, the access authentication node continues to block subsequent business data packets from entering the business data channel and can switch the IoT terminal to a secure restricted channel. After entering the secure restricted channel, the IoT terminal sends an exception description message to the access authentication node. This exception description message carries a random variable echo value, a channel parameter echo value, and a digest of the generated continuity credentials. The access authentication node generates new channel parameters based on the random variable echo value, the channel parameter echo value, and the digest of the generated continuity credentials. The IoT terminal then re-initiates access authentication based on the new channel parameters.

[0066] Through the above methods, the access authentication node uses the one-time acceptance of continuity credentials, credential consumption records, replay message identification, sequence number gap intervals, and single repair challenges to perform continuity verification and anomaly repair on subsequent business data messages. This ensures that used continuity credentials cannot be reused and that the business data channel with abnormal message sequence numbers can resume orderly reception under the constraints of the authentication context.

Claims

1. A method for collaborative control of IoT terminal access authentication and data security, characterized in that, The Internet of Things (IoT) terminal sends an access authentication request to the access authentication node. The access authentication request includes the terminal identifier, a random variable, and information about the data channel to be established. After successful access authentication, the access authentication node generates an authentication context, which includes a terminal identifier, a random variable, channel parameters generated based on the data channel information to be established, the allowed data types, and the data security level. The IoT terminal generates authentication associated credentials based on the authentication context and carries the channel number, message sequence number, data type, data security level, and authentication associated credentials in the security header of the initial business data message. The access authentication node verifies the security message header according to the authentication context. If the verification is successful, the service data channel corresponding to the channel parameters is opened. If the verification fails, the node switches to a security-restricted channel that allows the transmission of heartbeat, security log, or exception description messages. Subsequent service data messages after the service data channel is opened carry continuous credentials generated by the previous message sequence number, the current message sequence number, and the authentication context to maintain coordinated control of access authentication and data transmission.

2. The method according to claim 1, characterized in that, The service data portion of the initial service data message carries the field identifier digest and field security level of the data to be transmitted before the service data channel is opened. After the access authentication node verifies the security message header, it returns a field to release the permission, and the IoT terminal uploads the data field corresponding to the field release permission.

3. The method according to claim 1, characterized in that, After the IoT terminal is switched to the secure restricted channel, the anomaly message carries the random quantity echo value, the channel parameter echo value, and a summary of the generated continuity credentials. The access authentication node generates new channel parameters based on the random quantity echo value, the channel parameter echo value, and the digest of the generated continuity credentials. The IoT terminal re-initiates access authentication based on the new channel parameters.

4. The method according to claim 1, characterized in that, The continuity credential is accepted once by the access authentication node within the verification period corresponding to the current message sequence number. When a subsequent service data message carries a used continuity credential, is missing a previous message sequence number, or the current message sequence number does not meet the preset continuity rule, the access authentication node prevents the subsequent service data message from entering the service data channel and updates the authentication context.

5. The method according to claim 2, characterized in that, The field release permission carries the field release order and single release limit. The IoT terminal uploads data fields according to the field release order, and the number of data fields uploaded in a single time is less than or equal to the single release limit. Once the access authentication node finds that the uploaded data field matches the digest value of the field identifier digest, it returns to the next field to release the permission.

6. The method according to claim 2, characterized in that, The field release permission is bound to the sequence number of the initial business data message. When the IoT terminal uploads the data field, it carries the sequence number of the message. When the data field does not carry the sequence number of the message, or the sequence number carried is inconsistent with the sequence number of the initial business data message, the access authentication node prevents the data field from entering the business data channel.

7. The method according to claim 2, characterized in that, The access authentication node returns field release permits with different usage counts, field ranges, or segment ranges based on the field security level. Data fields with a security level lower than a preset threshold correspond to a single release permit, while data fields with a security level reaching the preset threshold correspond to segmented release permits. Before obtaining a subsequent segmented release permit, the IoT terminal does not upload the data field corresponding to the next segment.

8. The method according to claim 4, characterized in that, After receiving the continuity credential, the access authentication node generates a credential consumption record corresponding to the current message sequence number. When a subsequent service data message carries the continuity credential corresponding to the credential consumption record again, the access authentication node identifies the subsequent service data message as a replay message and updates the credential generation parameters in the authentication context based on the replay message.

9. The method according to claim 4, characterized in that, When the current message sequence number does not meet the preset continuity rule, the access authentication node allows the IoT terminal to send a continuity repair message without carrying business data. The continuity repair message carries the previous message sequence number and the current message sequence number. The access authentication node updates the authentication context based on the continuity repair message and keeps the service data channel from receiving subsequent service data messages until the update is complete.

10. The method according to claim 9, characterized in that, The access authentication node forms a sequence number gap interval based on the missing sequence number between the previous message sequence number and the current message sequence number, and returns a single repair challenge to the IoT terminal; the IoT terminal generates repair credentials based on the single repair challenge, the sequence number gap interval and the authentication context, and the continuous repair message does not carry the business data corresponding to the sequence number gap interval. After the repair credentials match the authentication context, the access authentication node resumes the reception of subsequent business data packets through the business data channel.

Images