A self-adaptive security policy generation method and system for a zero trust architecture

Abstract

The application provides a kind of adaptive security policy generation method and system for zero trust architecture, the initial zero trust risk value is calculated by the physical environment data of the collected internet of things equipment;Based on the application policy adjustment factor corresponding to the sensitive level identifier of the internet of things equipment in the zero trust architecture, the initial zero trust risk value is adjusted to obtain the comprehensive environment risk index;When the comprehensive environment risk index exceeds the first critical value, the resource access control instruction of only opening the basic application program interface is generated, when the comprehensive environment risk index does not exceed the first critical value, the resource access control instruction authorized according to the preset minimum authority range is generated;The resource access control instruction is converted into the adaptive security policy executable by target device;The application realizes the adaptive response of adaptive security policy under zero trust architecture to physical environment change, improves the accuracy, real-time performance and security of adaptive security policy.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to an adaptive security policy generation method and system for zero-trust architecture. Background Technology

[0002] With the widespread application of IoT technology, an increasing number of smart devices are connecting to enterprise networks, driving the rapid development of zero-trust architecture. In the zero-trust security model, any access request must undergo rigorous verification, regardless of its origin (internal or external). However, facing dynamically changing physical environments and device states, achieving real-time risk assessment and security policy adjustments for IoT devices has become a key technical challenge. Especially in complex and ever-changing scenarios such as Industrial IoT and smart cities, the physical state of devices directly affects their security; therefore, a mechanism capable of automatically adjusting access control policies based on environmental changes is urgently needed.

[0003] Current research has proposed dynamic access control methods based on device behavior pattern recognition. These methods collect historical behavior data from devices, utilize machine learning models to identify normal behavior patterns, and dynamically adjust access permissions when abnormal behavior is detected. However, existing solutions primarily rely on digital behavior data from devices, lacking effective perception and quantitative assessment of physical environmental factors. This results in the system's inability to promptly detect and respond to physical tampering or abnormal environments. Furthermore, these methods typically employ fixed evaluation models, making it difficult to differentiate based on the sensitivity levels of devices in different scenarios, thus affecting the accuracy and adaptability of security policies. Summary of the Invention

[0004] This invention provides an adaptive security policy generation method and system for zero-trust architecture, which solves the problems in the prior art such as the inability to detect abnormal environments in a timely manner and respond accordingly; the difficulty in differentiating the processing of security policies according to the sensitivity level of devices in different scenarios; and the insufficient accuracy and adaptability of security policies.

[0005] In a first aspect, the present invention provides an adaptive security policy generation method for zero-trust architecture, comprising:

[0006] Collect physical environment data of IoT devices, including device displacement distance, ambient temperature value, and geographic location coordinates;

[0007] Based on the device displacement distance, ambient temperature value, and geographical coordinates, an initial zero-trust risk value is calculated;

[0008] Based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, the initial zero-trust risk value is adjusted to obtain the comprehensive environmental risk index.

[0009] When the comprehensive environmental risk index exceeds the first threshold, a resource access control instruction that only opens the basic application programming interface is generated; when the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction that authorizes access within a preset minimum permission range is generated.

[0010] The resource access control instructions are converted into an adaptive security policy that can be executed by the target device.

[0011] Optionally, when the comprehensive environmental risk index exceeds a first threshold, a resource access control instruction that only opens the basic application programming interface is generated; when the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction authorized according to a preset minimum permission range is generated, including:

[0012] The comprehensive environmental risk index is compared with the first threshold value to generate a first permission level identifier or a second permission level identifier.

[0013] If a first permission level identifier is generated, then a list of interface names of a subset of basic application interfaces is extracted from the pre-stored permission level set.

[0014] If a second permission level identifier is generated, then the list of interface types and the upper limit of call frequency of the minimum permission range interface set are extracted from the pre-stored permission level set.

[0015] When the comprehensive environmental risk index exceeds the first threshold, the first permission level identifier and the list of interface names are written into the initial structured instruction data body, and a resource access control instruction that only opens the basic application interface is generated. The initial structured instruction data body embeds the instruction generation time and the device authentication code.

[0016] When the comprehensive environmental risk index does not exceed the first threshold, the second permission level identifier, the interface type list, and the upper limit of the call frequency are written into the initial structured instruction data body to generate a resource access control instruction authorized according to the preset minimum permission range.

[0017] Optionally, the resource access control instructions are converted into an adaptive security policy executable by the target device, including:

[0018] Create the initial strategy carrier;

[0019] The permission level identifier in the resource access control instruction is converted into the target device policy type code, and the target device policy type code is written into the header field of the initial policy carrier to obtain the first intermediate policy carrier.

[0020] Write the interface call identifier registered by the target device kernel into the interface permission field of the first intermediate policy carrier to obtain the second intermediate policy carrier;

[0021] The call constraint rules in the resource access control instructions are compiled into a restriction parameter structure that can be recognized by the target device, and the restriction parameter structure is written into the constraint rule field of the second intermediate policy carrier to obtain the third intermediate policy carrier.

[0022] Write the policy effective start time and effective duration into the control field of the third intermediate policy carrier, and add the identity binding code derived from the target device certificate to the tail field of the third intermediate policy carrier to obtain the fourth intermediate policy carrier.

[0023] The fourth intermediate policy carrier is verified to generate a verified policy carrier, which is then encrypted to generate an adaptive security policy executable by the target device.

[0024] Optionally, the fourth intermediate policy carrier is verified to generate a verified policy carrier, and the verified policy carrier is encrypted to generate an adaptive security policy executable by the target device, including:

[0025] Extract a byte sequence of a preset length from the tail field of the fourth intermediate strategy carrier, and use the byte sequence as a plaintext copy of the identity binding code;

[0026] The total number of bytes in the fourth intermediate strategy carrier is counted, and the total number of bytes is compared with a preset length value to obtain a length verification status identifier;

[0027] The binary sequence of the plaintext copy of the identity binding code is compared bit by bit with the binary sequence of the certificate feature value pre-stored in the secure storage unit of the target device to obtain the binding verification status identifier.

[0028] Based on the length verification status identifier and the binding verification status identifier, the fourth intermediate strategy carrier that has passed the verification is determined as the post-verification strategy carrier.

[0029] Each byte of the verified policy carrier is subjected to numerical transformation and positional permutation operations to generate an encrypted data block;

[0030] Based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, an adaptive security policy executable by the target device is generated.

[0031] Optionally, based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, an adaptive security policy executable by the target device is generated, including:

[0032] When the length verification status is verified as passed and the binding verification status is verified as passed, a preset policy validity flag field is inserted into the header field of the encrypted data block to generate an adaptive security policy.

[0033] When the length verification status is marked as verification failed, a policy invalid alarm data block is created. A policy exception flag field is added to the header field of the policy invalid alarm data block to generate an adaptive security policy. The policy invalid alarm data block includes an error type code, total number of bytes, and a timestamp.

[0034] When the length verification status is verified as passed and the binding verification status is verified as failed, a device binding failure data block is created. A policy exception flag field is added to the header field of the device binding failure data block to generate an adaptive security policy. The device binding failure data block includes an error type code, a certificate feature value copy, and a plaintext copy of the identity binding code.

[0035] Optionally, based on the device displacement distance, ambient temperature value, and geographical coordinates, an initial zero-trust risk value is calculated, including:

[0036] Based on the minimum physical movement range allowed by the device functions of the IoT device, a displacement authorization threshold is determined, and the cumulative value of the time window in which the device displacement distance exceeds the displacement authorization threshold is calculated to generate a zero-trust displacement deviation.

[0037] Based on the minimum temperature tolerance range allowed for the safe operation of IoT devices, the temperature authorization boundary is determined, and the instantaneous out-of-bounds amount when the ambient temperature value exceeds the temperature authorization boundary is extracted to generate a zero-trust temperature anomaly.

[0038] Based on the minimum safe zone allowed for the operation of IoT devices, determine the location authorization range, calculate the real-time shortest distance from the geographic location coordinates to the location authorization range, and generate a zero-trust location offset.

[0039] According to the zero-trust risk weight allocation rule, the zero-trust displacement deviation, zero-trust temperature anomaly and zero-trust position offset are weighted and summed to obtain the initial zero-trust risk value.

[0040] Optionally, based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, the initial zero-trust risk value is adjusted to obtain a comprehensive environmental risk index, including:

[0041] The byte encoding structure of the sensitivity level identifier of the IoT device in the zero-trust architecture is parsed to separate the device type encoding field and the risk level value;

[0042] Based on the device type coding field, query the preset adjustment factor benchmark table to obtain the basic adjustment coefficient corresponding to the IoT device, and set the scaling ratio value based on the risk level value.

[0043] The dynamic adjustment factor is obtained by multiplying the basic adjustment coefficient and the scaling ratio. Combined with the initial zero-trust risk value and the equipment environment baseline value, a preliminary environmental risk index is calculated. The equipment environment baseline value is a preset equipment inherent risk constant.

[0044] Based on the preset maximum risk threshold, the preliminary environmental risk index is truncated to obtain the truncated risk index, which is then used as the comprehensive environmental risk index.

[0045] Secondly, the present invention provides an adaptive security policy generation system for zero-trust architecture, comprising:

[0046] The data acquisition module is used to collect physical environment data of IoT devices, including device displacement distance, ambient temperature value, and geographic location coordinates.

[0047] The calculation module is used to calculate the initial zero-trust risk value based on the device displacement distance, ambient temperature value, and geographical coordinates;

[0048] The adjustment module is used to adjust the initial zero-trust risk value based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, so as to obtain a comprehensive environmental risk index.

[0049] The generation module is used to generate resource access control instructions that only open the basic application programming interface when the comprehensive environmental risk index exceeds the first threshold, and to generate resource access control instructions that are authorized according to the preset minimum permission range when the comprehensive environmental risk index does not exceed the first threshold.

[0050] The conversion module is used to convert the resource access control instructions into an adaptive security policy that can be executed by the target device.

[0051] Thirdly, the present invention provides a computing device, including a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement an adaptive security policy generation method for a zero-trust architecture as described in the first aspect above.

[0052] Fourthly, the present invention provides a computer storage medium storing a computer program, which, when executed by a computer, implements an adaptive security policy generation method for a zero-trust architecture as described in the first aspect.

[0053] In this invention, physical environment data of IoT devices is collected, including device displacement distance, ambient temperature value, and geographic location coordinates. Based on the device displacement distance, ambient temperature value, and geographic location coordinates, an initial zero-trust risk value is calculated. Based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, the initial zero-trust risk value is adjusted to obtain a comprehensive environmental risk index. When the comprehensive environmental risk index exceeds a first threshold, a resource access control instruction that only opens the basic application programming interface is generated. When the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction that authorizes access within a preset minimum permission range is generated. The resource access control instruction is then converted into an adaptive security policy executable by the target device. The technical solution provided by this invention enables real-time perception of the physical operating status of equipment, breaking through the limitations of traditional solutions that rely solely on digital behavioral data. It provides direct monitoring capabilities for physical tampering (such as displacement anomalies) and environmental anomalies (such as drastic temperature changes). It transforms physical quantities such as displacement, temperature, and position into quantifiable risk indicators, addressing the deficiency of effective perception of physical environmental factors. By dynamically correcting risk values ​​through equipment sensitivity levels, it achieves differentiated processing for different scenarios, overcoming the shortcomings of insufficient adaptability of fixed assessment models. Physical risk drives dynamic adjustment of permissions, with a response speed far exceeding that of traditional historical behavior analysis models. It realizes a closed loop from decision-making to execution, ensuring that policies can be directly enforced at the equipment kernel level, avoiding the problem of policy and execution being disconnected. Furthermore, by creating a four-level policy carrier chain (initial carrier, first intermediate carrier, second intermediate carrier, third intermediate carrier, and fourth intermediate carrier), permission instructions are gradually transformed into device-executable policies. Specifically, by adding an identity binding code derived from the device certificate to the tail field, the policy is strongly associated with the device's physical identity, preventing unauthorized devices from stealing policies and overcoming the vulnerability of undetectable physical tampering. Through kernel-level interface identifier registration and restricted parameter compilation, the principle of least privilege is transformed into device-executable instructions, breaking through the bottleneck of policy and execution being disconnected. The time-sensitivity control mechanism of the control field allows policies to take effect / lapse in real time based on the risk index, enabling the solution to automatically adjust to environmental changes.

[0054] These or other aspects of the invention will become more apparent from the following description of the embodiments. Attached Figure Description

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

[0056] Figure 1 A flowchart illustrating an adaptive security policy generation method for zero-trust architecture provided by this invention;

[0057] Figure 2 A schematic diagram of the structure of an adaptive security policy generation system for a zero-trust architecture provided by the present invention;

[0058] Figure 3 This is a schematic diagram of the structure of a computing device provided by the present invention. Detailed Implementation

[0059] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0060] In some of the processes described in the specification, claims, and accompanying drawings of this invention, multiple operations appearing in a specific order are included. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first," "second," etc., in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

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

[0062] In complex and dynamic scenarios such as the Industrial Internet of Things (IIoT) and smart cities, the physical environment in which IoT devices reside has a significant impact on their security. However, existing dynamic access control methods based on device digital behavior mainly rely on historical behavior data, lacking effective perception and quantitative assessment of the physical environment status of devices. This results in the inability to promptly identify potential threats and adjust security strategies when devices experience physical displacement, environmental anomalies, or changes in geographical location. Furthermore, traditional solutions use fixed assessment models, making it difficult to differentiate based on the sensitivity levels of different devices, affecting the flexibility and accuracy of security strategies. To address these issues, this invention collects physical environment data of devices (such as displacement distance, ambient temperature, and geographical coordinates), combines it with application strategy adjustment factors corresponding to device sensitivity level identifiers, dynamically calculates a comprehensive environmental risk index, and automatically generates access control policies matching the current risk level based on this index. This enables refined and real-time security management of IoT devices in complex environments. Figure 1 This invention provides a flowchart of an adaptive security policy generation method for a zero-trust architecture, as shown in the following embodiment. Figure 1 As shown, the method includes:

[0063] Step 101: Collect physical environment data of IoT devices, including device displacement distance, ambient temperature value, and geographic location coordinates;

[0064] In this step, physical environment data refers to real-time monitoring datasets reflecting the physical spatial state of the IoT device. Device displacement distance refers to the cumulative three-dimensional linear displacement of the device relative to its initial position within a specific time window (e.g., 5 minutes), calculated through integration using a triaxial accelerometer, used to quantify the risk of the device being moved or stolen. Ambient temperature refers to the instantaneous measurement of the air temperature in the environment where the IoT device is located, acquired through a digital temperature sensor; exceeding the device's safe operating temperature zone triggers high-temperature melting or low-temperature freezing alarms. Geographic location coordinates refer to the longitude and latitude positioning data of the IoT device on the Earth's surface, obtained through analysis of satellite signals received by a Global Positioning System / BeiDou module, combined with electronic fence technology to determine whether the device has left the authorized area.

[0065] In this embodiment of the invention, physical environment data is acquired in real time through a miniature sensing device deployed on an IoT device: an accelerometer continuously measures the device's position change in three-dimensional space and records the device's displacement distance in millimeters; a temperature sensor periodically detects the air temperature value of the environment in which the device is located; and a GPS module receives the device's current longitude and latitude values. The above three types of data—displacement distance, ambient temperature value, and geographic location coordinates—are updated synchronously at a frequency of once per second to form physical environment data containing timestamps.

[0066] Step 102: Calculate the initial zero-trust risk value based on the device displacement distance, ambient temperature value, and geographical coordinates;

[0067] In this embodiment of the invention, a displacement authorization threshold is determined based on the minimum physical movement range allowed by the IoT device's functions, and the cumulative value of the time window exceeding the displacement authorization threshold is calculated to generate a zero-trust displacement deviation. A temperature authorization boundary is determined based on the minimum temperature tolerance range allowed for the safe operation of the IoT device, and the instantaneous out-of-bounds amount of the ambient temperature value exceeding the temperature authorization boundary is extracted to generate a zero-trust temperature anomaly. A location authorization range is determined based on the minimum safe area allowed for the operation of the IoT device, and the real-time shortest distance from the geographic location coordinates to the location authorization range is calculated to generate a zero-trust location offset. According to the zero-trust risk weight allocation rule, the zero-trust displacement deviation, zero-trust temperature anomaly, and zero-trust location offset are weighted and summed to obtain an initial zero-trust risk value.

[0068] Step 103: Based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, adjust the initial zero-trust risk value to obtain the comprehensive environmental risk index;

[0069] In this embodiment of the invention, the byte encoding structure of the sensitivity level identifier of the IoT device in the zero-trust architecture is parsed to separate the device type encoding field and the risk level value; based on the device type encoding field, a preset adjustment factor benchmark table is queried to obtain the basic adjustment coefficient corresponding to the IoT device; based on the risk level value, a scaling ratio value is set; the basic adjustment coefficient and the scaling ratio value are multiplied to obtain the dynamic adjustment factor; combined with the initial zero-trust risk value and the device environment baseline value, a preliminary environmental risk index is calculated; based on a preset maximum risk threshold, the preliminary environmental risk index is truncated to obtain the comprehensive environmental risk index.

[0070] Step 104: When the comprehensive environmental risk index exceeds the first threshold, generate a resource access control instruction that only opens the basic application programming interface; when the comprehensive environmental risk index does not exceed the first threshold, generate a resource access control instruction that authorizes access within a preset minimum permission range.

[0071] In this embodiment of the invention, the comprehensive environmental risk index is compared with a first threshold value to generate a first permission level identifier or a second permission level identifier. If a first permission level identifier is generated, a list of interface names for a subset of basic application interfaces is extracted from the pre-stored permission level set. If a second permission level identifier is generated, a list of interface types and a maximum call frequency for the minimum permission range interface set are extracted from the pre-stored permission level set. When the comprehensive environmental risk index exceeds the first threshold value, the first permission level identifier and the list of interface names are written into the initial structured instruction data body to generate a resource access control instruction that only opens the basic application interfaces. When the comprehensive environmental risk index exceeds the first threshold value, the second permission level identifier, the list of interface types, and the maximum call frequency are written into the initial structured instruction data body to generate a resource access control instruction authorized according to a preset minimum permission range.

[0072] Step 105: Convert the resource access control command into an adaptive security policy executable by the target device;

[0073] In this embodiment of the invention, an initial policy carrier is created; the permission level identifier in the resource access control instruction is converted into the target device policy type code, and the target device policy type code is written into the header field of the initial policy carrier to obtain a first intermediate policy carrier; the interface call identifier registered by the target device kernel is written into the interface permission field of the first intermediate policy carrier to obtain a second intermediate policy carrier; the call constraint rules in the resource access control instruction are compiled into a restriction parameter structure recognizable by the target device, and the restriction parameter structure is written into the constraint rule field of the second intermediate policy carrier to obtain a third intermediate policy carrier; the policy effective start time and effective duration are written into the control field of the third intermediate policy carrier, and an identity binding code derived from the target device certificate is added to the tail field of the third intermediate policy carrier to obtain a fourth intermediate policy carrier, and encryption and verification processing are performed on it to generate an adaptive security policy executable by the target device.

[0074] This invention achieves real-time quantitative assessment of physical threats such as equipment theft, environmental damage, and out-of-bounds operation by monitoring three physical quantities: cumulative displacement distance, instantaneous temperature exceedance, and location boundary distance.

[0075] This invention provides a specific embodiment. Step 102 involves calculating an initial zero-trust risk value based on the device displacement distance, ambient temperature value, and geographical coordinates. This specifically includes the following steps:

[0076] Step 201: Determine the displacement authorization threshold based on the minimum physical movement range allowed by the device function of the IoT device, and calculate the cumulative value of the time window in which the device displacement distance exceeds the displacement authorization threshold to generate a zero-trust displacement deviation.

[0077] In this step, the minimum physical movement range refers to the maximum permissible displacement range required for normal operation of the equipment (e.g., ±5cm for industrial sensors, 0cm for server equipment), based on the mechanical structure parameters set in the equipment's manufacturer's technical manual. The displacement authorization threshold is a critical value derived from the minimum physical movement range (e.g., 5cm); exceeding this threshold triggers an anomaly log. The cumulative time window value refers to the total duration (in seconds) of displacement exceeding the threshold within a fixed 10-minute period, used to distinguish between momentary jitter and sustained anomalies. The zero-trust displacement deviation is a risk index (0-100) standardized from the cumulative value, calculated as: (cumulative excess time / 600 seconds) × 100; a higher value indicates a higher risk of physical tampering.

[0078] In this embodiment of the invention, a displacement authorization threshold is determined based on the minimum physical movement range required for the function of the IoT device. Within a set time window (e.g., 5 minutes), the portion of the device displacement distance exceeding the displacement authorization threshold is accumulated to generate a zero-trust displacement deviation. The specific process is as follows: displacement data is read in real time, and when the device displacement distance exceeds the displacement authorization threshold in a single instance, the excess amount is recorded. At the end of the window, all excess amounts are added together to obtain a cumulative value in millimeters as the zero-trust displacement deviation.

[0079] Step 202: Based on the minimum temperature tolerance range allowed for the safe operation of IoT devices, determine the temperature authorization boundary, extract the instantaneous out-of-bounds amount when the ambient temperature value exceeds the temperature authorization boundary, and generate a zero-trust temperature anomaly.

[0080] In this step, the minimum temperature tolerance range refers to the lowest / highest temperature range that the equipment can safely withstand (e.g., -10℃ to 50℃), set based on the temperature resistance characteristics of the equipment components. The temperature authorization boundary refers to the upper or lower limit of the minimum temperature tolerance range, used to determine whether the ambient temperature exceeds the limit. The instantaneous exceedance refers to the instantaneous difference in ambient temperature value exceeding the temperature authorization boundary within a single detection cycle. The zero-confidence temperature anomaly is a temperature risk indicator quantified by the instantaneous exceedance, reflecting the instantaneous threat of environmental overheating / overcooling to the equipment.

[0081] In this embodiment of the invention, the temperature authorization boundary is determined based on the minimum temperature tolerance range necessary for the safe operation of the equipment, and the maximum instantaneous difference in ambient temperature values ​​exceeding the temperature authorization boundary within the detection cycle (e.g., 1 second) is extracted. The specific process is as follows: the absolute value of the ambient temperature value exceeding the temperature authorization boundary per second is detected to obtain the instantaneous over-limit amount, and the cumulative number of seconds (i.e., the duration of continuous over-limit) of the ambient temperature value exceeding the temperature authorization boundary within the cycle is counted. The zero-trust temperature anomaly degree is calculated as follows: (instantaneous over-limit amount × weighting coefficient + duration of continuous over-limit ÷ total cycle duration × maximum allowable over-limit amount × weighting coefficient) ÷ 50℃ × 100, where the total cycle duration is determined based on the response delay characteristics of the equipment temperature change, the maximum allowable over-limit amount is determined based on the difference between the equipment's limit temperature resistance value and the normal range, and the weighting coefficient is determined by fitting 100 sets of equipment fault data, with the weight of continuous anomaly being higher than that of instantaneous anomaly.

[0082] Step 203: Determine the location authorization range based on the minimum safe area allowed for device operation of the IoT device, and calculate the real-time shortest distance from the geographic location coordinates to the location authorization range to generate a zero-trust location offset.

[0083] In this step, the minimum safe zone refers to the minimum geographical area necessary for equipment operation (e.g., the coordinate fence of area A in the factory), set based on the equipment's signal coverage capability. The authorized location range refers to the set of geographical boundary coordinates of the minimum safe zone, used to generate the electronic fence. The real-time shortest distance refers to the shortest straight-line distance from the equipment's current location coordinates to the boundary of the authorized location range, updated every second. The zero-trust location offset is a location risk indicator quantified by the real-time shortest distance; a higher value indicates a higher risk of the equipment crossing the boundary.

[0084] In this embodiment of the invention, the location authorization range is determined based on the minimum safe area required for device operation, and the shortest Euclidean distance from the device coordinates to the boundary of the location authorization range is calculated in real time. The specific process is as follows: the device coordinates are refreshed every second, and the shortest straight-line distance from the device to the boundary of the electronic fence is calculated using a geometric algorithm to generate a zero-trust location offset in meters.

[0085] Step 204: According to the zero-trust risk weight allocation rule, the zero-trust displacement deviation, zero-trust temperature anomaly and zero-trust position offset are weighted and summed to obtain the initial zero-trust risk value;

[0086] In this step, the zero-trust risk weight allocation rule refers to setting the risk weight ratio (e.g., 0.6:0.1:0.3) for zero-trust displacement deviation, zero-trust temperature anomaly, and zero-trust location offset based on the degree of risk impact, reflecting the priority of different physical risks. The initial zero-trust risk value refers to the initial comprehensive risk value generated after weighted summation, ranging from 0 to 100, providing input for subsequent sensitivity level adjustments.

[0087] In this embodiment of the invention, preset displacement weight value, temperature weight value and position weight value are loaded, each value is normalized, and a weighted operation is performed according to the preset weight to obtain an initial zero-trust risk value.

[0088] The embodiments of the present invention overcome the shortcomings of relying solely on digital behavioral data and lacking the ability to respond to dynamic changes in the physical environment. They improve the accuracy of identifying real threats such as physical tampering of equipment, environmental anomalies, or illegal movement, and enhance the adaptability and security of the zero-trust architecture in complex industrial IoT and smart city scenarios.

[0089] This invention provides a specific embodiment. Step 103 involves adjusting the initial zero-trust risk value based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, to obtain a comprehensive environmental risk index. This specifically includes the following steps:

[0090] Step 301: Parse the byte encoding structure of the sensitivity level identifier of the IoT device in the zero-trust architecture to separate the device type encoding field and the risk level value;

[0091] In this step, Zero Trust Architecture refers to a security model that requires strict verification of all access requests, regardless of internal or external network environments, and dynamically adjusts the trust level based on the physical environment data of this invention. The Sensitivity Level Identifier is a 3-byte data structure consisting of a device type encoding field (2 bytes) and a risk level value (1 byte), used to identify the security sensitivity of a device in the Zero Trust Architecture. The byte encoding structure refers to the physical storage format of the Sensitivity Level Identifier; the first 2 bytes store the device type encoding, and the third byte stores the risk level value. The device type encoding field is an encoding that identifies the device classification, based on a preset functional hazard level. The risk level value is a numerical value representing the device's risk level (1 = low risk, 2 = medium risk, 3 = high risk), configured by the system administrator.

[0092] In this embodiment of the invention, the sensitivity level identifier of IoT devices in a zero-trust architecture is parsed at the byte level: by segmenting the fixed-length byte sequence of the identifier, the first 2 bytes are extracted as the device type encoding field, and the third byte is used as the risk level value; specifically, the identifier memory storage area is read, and the corresponding byte segment is copied according to a preset offset to ensure that the device type information and risk level information are separated.

[0093] Step 302: Based on the device type coding field, query the preset adjustment factor benchmark table to obtain the basic adjustment coefficient corresponding to the IoT device, and set the scaling ratio value according to the risk level value;

[0094] In this step, the preset adjustment factor benchmark table refers to a data table that maps storage device type codes to basic adjustment coefficients. The basic adjustment coefficient refers to a risk correction base preset according to the device type, reflecting the inherent risk attributes of that type of device. The scaling ratio value refers to a scaling parameter converted from the risk level value, used to amplify the threat assessment of high-risk devices.

[0095] In this embodiment of the invention, a preset adjustment factor benchmark table is queried based on the equipment type code field: the table is retrieved using the equipment type code as the index, such as 0x01 corresponding to medical equipment with a corresponding basic adjustment coefficient of 1.5, and 0x02 corresponding to industrial control equipment with a corresponding basic adjustment coefficient of 1.2; at the same time, the risk level value is converted into a scaling ratio value (risk level value 1 corresponds to 1.0, risk level 2 corresponds to 1.5, and risk level 3 corresponds to 2.0), and the mapping from risk level to scaling parameter is realized through value lookup and conversion.

[0096] Step 303: Multiply the basic adjustment coefficient and the scaling ratio to obtain the dynamic adjustment factor. Combine the initial zero-trust risk value and the equipment environment baseline value to calculate the preliminary environmental risk index. The equipment environment baseline value is a preset equipment inherent risk constant.

[0097] In this step, the dynamic adjustment factor refers to the product of the base adjustment coefficient and the scaling factor, which constitutes the final risk correction coefficient. The equipment environmental baseline value refers to the preset inherent risk constant of the equipment installation location, compensating for environmental hazards. The preliminary environmental risk index refers to the intermediate calculation result of the initial zero-confidence risk value × dynamic adjustment factor + equipment environmental baseline value. The inherent risk constant of the equipment refers to a fixed value preset based on the environmental hazard of the equipment deployment (high-risk environment > safe environment).

[0098] In this embodiment of the invention, the basic adjustment coefficient is multiplied by the scaling factor to obtain the dynamic adjustment factor; then the initial zero-trust risk value is multiplied by the dynamic adjustment factor, and a preset equipment environment baseline value is added to perform arithmetic operations to generate a preliminary environmental risk index; the calculation process is completed by an embedded arithmetic logic unit to avoid floating-point operation bottlenecks.

[0099] Step 304: Based on the preset maximum risk threshold, perform upper limit truncation on the preliminary environmental risk index to obtain the truncated risk index, and use the truncated risk index as the comprehensive environmental risk index.

[0100] In this step, the preset maximum risk threshold refers to the upper limit of the comprehensive environmental risk index (fixed at 100) to prevent risk overflow. The truncated risk index refers to the final risk value after upper limit truncation, ranging from 0 to 100. The comprehensive environmental risk index refers to the risk quantification result output to the permission decision-making stage, directly driving the generation of security policies.

[0101] In this embodiment of the invention, the preliminary environmental risk index is compared with a preset maximum risk threshold (fixed at 100): when the preliminary environmental risk index exceeds 100, the comprehensive environmental risk index is forcibly set to 100; otherwise, the original value is directly used as the comprehensive environmental risk index; this truncation operation is implemented through a comparator circuit to ensure that the output value is always within the effective risk range.

[0102] The embodiments of the present invention realize the perception of physical environmental factors and can perform differentiated processing for devices with different sensitivity levels, making the security policy more accurate and flexible. This improves the system's ability to identify potential threats and its response speed in complex and ever-changing environments, ensuring that access control policies can be adjusted in a timely manner even when devices are physically tampered with or in abnormal environments, thereby enhancing the level of security protection.

[0103] This invention provides a specific embodiment, step 104, where when the comprehensive environmental risk index exceeds a first threshold, a resource access control instruction that only opens the basic application programming interface is generated; when the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction that authorizes access according to a preset minimum permission range is generated. Specifically, this includes the following steps:

[0104] Step 401: Compare the comprehensive environmental risk index with the first threshold value to generate a first permission level identifier or a second permission level identifier;

[0105] In this step, the first threshold refers to a preset risk level boundary determined based on the relationship between risk value and successful intrusion rate in attack simulation experiments. Exceeding this threshold activates a high-risk control mode. The first permission level identifier refers to the set high-risk mode identifier code (0x01), which, when triggered, only opens the basic application programming interface. The second permission level identifier refers to the set low-risk mode identifier code (0x02), which, when triggered, enables the preset minimum permission range.

[0106] In this embodiment of the invention, the comprehensive environmental risk index and a first threshold value (e.g., 60) are input into the comparison unit: when the comprehensive environmental risk index is greater than 60, the first permission level identifier (i.e., hexadecimal value 0x01) is output; when it is less than or equal to 60, the second permission level identifier (i.e., 0x02) is output. Specifically, the embedded comparator circuit performs numerical comparison and writes the result into the register for storage.

[0107] Step 402: If a first permission level identifier is generated, extract the list of interface names of the basic application interface subset from the pre-stored permission level set;

[0108] In this step, the pre-stored permission level set refers to the pre-configured permission database, which contains two types of permission packages: a list of basic interface subset names and a minimum permission set of parameters. The basic application interface subset refers to the simplest set of interfaces necessary for device survival (such as status reading and alarm reporting), with a maximum of three. The interface name list refers to the list of specific name strings for the basic interface subset.

[0109] In this embodiment of the invention, the pre-stored permission level set is accessed according to the type of the generated permission identifier: if it is the first permission level identifier (0x01), the list of interface names of the basic application interface subset (containing only status reading interface and alarm reporting interface) is copied.

[0110] Step 403: If a second permission level identifier is generated, extract the list of interface types and the upper limit of call frequency of the minimum permission range interface set from the pre-stored permission level set;

[0111] In this step, the minimum permission range interface set refers to the set of interfaces allowed within the security threshold (such as start / stop control and data query), including call frequency limits. The interface type list refers to the list of interface names in the minimum permission set. The maximum call frequency limit refers to the maximum number of times a single interface is allowed to be called per minute (e.g., 5 times), to prevent high-frequency malicious operations.

[0112] In this embodiment of the invention, if it is the second permission level identifier (0x02), copy the list of interface types and the upper limit of call frequency (integer 5) of the interface set with the minimum permission range.

[0113] Step 404: When the comprehensive environmental risk index exceeds the first threshold, the first permission level identifier and the interface name list are written into the initial structured instruction data body, and a resource access control instruction that only opens the basic application interface is generated. The initial structured instruction data body embeds the instruction generation time and the device authentication code.

[0114] In this step, the initial structured instruction data body refers to a blank data structure used to carry policy information, containing three parts: a header field (permission identifier), a middle field (interface parameters), and a tail field (verification information). Resource access control instructions refer to commands that drive the device to execute permission control, divided into basic interface instructions and least privilege instructions. The instruction generation time refers to the system time value at the moment the instruction is created, used to prevent replay attacks. The device authentication code refers to an 8-byte hash value generated based on the device hardware certificate, binding the instruction to a specific device.

[0115] In this embodiment of the invention, when the comprehensive environmental risk index exceeds the first threshold: the first permission level identifier (0x01) and the interface name list are written into the header of the initial structured instruction data body; the current system clock time is embedded in the middle of the initial structured instruction data body as the instruction generation time (a 14-bit binary encoded decimal number); the first 8 bytes of the device certificate's secure hash algorithm 256 hash value are appended to the tail field as the device authentication code; finally, a resource access control instruction that only opens the basic application interface is generated.

[0116] Step 405: When the comprehensive environmental risk index does not exceed the first critical value, the second permission level identifier, the interface type list, and the upper limit value of the call frequency are written into the initial structured instruction data body to generate a resource access control instruction authorized according to the preset minimum permission range;

[0117] In this step, the preset minimum permission range refers to the minimum necessary operation permissions granted under low-risk conditions (such as allowing data queries but limiting the frequency of control).

[0118] In this embodiment of the invention, when the comprehensive environmental risk index does not exceed the first critical value: the second permission level identifier (0x02), the interface type list and the upper limit value of the call frequency (e.g., 5) are written into the initial structured instruction data body; the instruction generation time and device authentication code are embedded synchronously; and a resource access control instruction authorized according to the preset minimum permission range (allowing calls to the start / stop control interface but limiting them to 5 times / minute) is generated.

[0119] The embodiments of the present invention ensure the timeliness and tamper-proof nature of control commands, and also enhance the traceability of commands and the authenticity of device identity. This enables the rapid convergence of permissions to basic services when the physical environment risk increases, and the implementation of minimal and precise authorization when the risk is low, thereby improving the adaptability, security and execution reliability of IoT device security policies under the zero-trust architecture.

[0120] This invention provides a specific embodiment, step 105, which involves converting the resource access control command into an adaptive security policy executable by the target device, specifically including the following steps:

[0121] Step 501: Create the initial strategy carrier;

[0122] In this embodiment of the invention, a blank storage area is allocated in the memory of the target device as an initial policy carrier. This carrier contains a predefined field structure: header field (16 bytes), interface permission field (64 bytes), constraint rule field (32 bytes), control field (8 bytes), and tail field (8 bytes). All field values ​​are initialized to 0.

[0123] Step 502: Convert the permission level identifier in the resource access control instruction into the target device policy type code, and write the target device policy type code into the header field of the initial policy carrier to obtain the first intermediate policy carrier;

[0124] In this step, the permission level identifier refers to the permission identifier in the resource access control instruction (0x01 = high risk, 0x02 = low risk). The target device policy type encoding refers to the policy classification code identified by the device kernel (0xA001 = basic interface policy, 0xA002 = least privilege policy). The first intermediate policy carrier refers to the carrier form after the policy type encoding is written, and the header fields have been initialized.

[0125] In this embodiment of the invention, the permission level identifier (0x01 or 0x02) in the resource access control instruction is read and mapped to the target device policy type code through a preset conversion table (for example, permission level identifier 0x01 is converted to target device policy type 0xA001, permission level identifier 0x02 is converted to target device policy type 0xA002). The code is written to the beginning position of the header field of the initial policy carrier to generate the first intermediate policy carrier.

[0126] Step 503: Write the interface call identifier registered by the target device kernel into the interface permission field of the first intermediate policy carrier to obtain the second intermediate policy carrier;

[0127] In this step, the interface call identifier refers to the hexadecimal address allocated by the device kernel for the interface function (e.g., status read function = 0x10DF). The interface permission field refers to the contiguous memory region (maximum 8 interfaces) in the carrier that stores the interface call identifier. The second intermediate policy carrier refers to the carrier form after the interface permission field has been written.

[0128] In this embodiment of the invention, based on the list of interface names or the list of interface types in the resource access control instruction, the kernel interface registry of the target device is queried, and the corresponding interface call identifiers are written sequentially into the interface permission field of the first intermediate policy carrier, with one identifier stored every 8 bytes, to generate the second intermediate policy carrier.

[0129] Step 504: Compile the calling constraint rules in the resource access control instruction into a restriction parameter structure that can be recognized by the target device, and write the restriction parameter structure into the constraint rule field of the second intermediate policy carrier to obtain the third intermediate policy carrier;

[0130] In this step, the invoke constraint rule refers to the operation restriction parameters in the resource access control instruction (e.g., call frequency ≤ 5 times / minute). The constraint parameter structure refers to the constraint encoding triple (type code + value + unit code) that the device can recognize. The constraint rule field refers to the 32-byte area in the carrier that stores the constraint parameter structure. The third intermediate policy carrier refers to the carrier form after the constraint rule field is written.

[0131] In this embodiment of the invention, the call constraint rules (such as 5 times / minute) in the resource access control instruction are extracted and compiled into a device-recognizable triple structure: constraint type code (0xF1 represents frequency limit) + value (5) + unit code (0x02 represents minutes). This triple structure is written into the constraint rule field of the second intermediate policy carrier to generate the third intermediate policy carrier.

[0132] Step 505: Write the policy effective start time and effective duration into the control field of the third intermediate policy carrier, and add the identity binding code derived from the target device certificate to the tail field of the third intermediate policy carrier to obtain the fourth intermediate policy carrier;

[0133] In this step, the control field refers to the 8-byte area storing the policy's effective start time (4 bytes) and effective duration (4 bytes). The policy effective start time refers to the initial moment the policy is activated, with a 1-second delay to prevent replay attacks. This is based on replay attack test data and verifies the policy through timestamps (effective time must be ≥ current time + 1 second) to prevent replay attacks. The effective duration refers to the total number of seconds the policy is valid. The target device certificate refers to the device's factory-installed asymmetric encryption certificate used for authentication. The identity binding code refers to the first 8 bytes of the certificate hash value, binding the policy to the physical device. The fourth intermediate policy carrier refers to the encrypted carrier after the control field and tail field are written.

[0134] In this embodiment of the invention, the policy effective start time (the decimal number of the binary code of the current time + 1 second) and the effective duration (such as 0xFFFFFFFF indicating permanent validity) are written into the control field of the third intermediate policy carrier; the first 8 bytes of the security hash value of the target device certificate are appended to the tail field as the identity binding code to generate the fourth intermediate policy carrier.

[0135] Step 506: Validate the fourth intermediate policy carrier, generate a validated policy carrier, encrypt the validated policy carrier, and generate an adaptive security policy executable by the target device.

[0136] In this step, the adaptive security policy refers to the permission control rules that the device kernel can directly parse and execute. It needs to go through processes such as structure conversion, identity binding, and encryption verification to ensure the security and uniqueness of the policy.

[0137] This invention, through the construction of a structured and verifiable policy generation process, accurately transforms abstract resource access control instructions into adaptive security policies that can be directly parsed and executed by target IoT devices. This not only achieves standardized encoding and mapping of permission levels, interface permissions, and call constraints, ensuring the integrity and consistency of policy semantics during transmission, but also enhances the timeliness, tamper resistance, and device identity binding capabilities of the policies, preventing policy replay or impersonation. It also guarantees the confidentiality and integrity of the policies during transmission and loading, achieving fine-grained, highly reliable, end-to-end dynamic control of IoT device security policies under a zero-trust architecture, thus improving the overall security of the system in complex environments against physical risks and unauthorized access.

[0138] This invention provides a specific embodiment. Step 506 involves verifying the fourth intermediate policy carrier to generate a verified policy carrier, encrypting the verified policy carrier, and generating an adaptive security policy executable by the target device. This specifically includes the following steps:

[0139] Step 511: Extract a byte sequence of a preset length from the tail field of the fourth intermediate strategy carrier, and use the byte sequence as a plaintext copy of the identity binding code;

[0140] In this step, the byte sequence refers to the consecutive 8-byte data segment extracted from the tail of the fourth intermediate policy carrier, serving as the original comparison sample for authentication. The plaintext copy of the identity binding code refers to the 8 bytes of data (unencrypted) directly copied from the tail of the fourth intermediate policy carrier, used to verify the binding relationship between the policy and the device.

[0141] In this embodiment of the invention, the starting offset of the tail field of the fourth intermediate strategy carrier (i.e., the total length of the carrier minus 8 bytes) is located, and 8 consecutive bytes of data are copied as a plaintext copy of the identity binding code; this copy is completely consistent with the tail field data before encryption.

[0142] Step 512: Count the total number of bytes of the fourth intermediate strategy carrier, and compare the total number of bytes with the preset length value to obtain the length verification status identifier;

[0143] In this step, the length verification status flag refers to the binary status of the length comparison result (1 = valid, 0 = failed).

[0144] In this embodiment of the invention, the total number of bytes is compared with a preset length value (e.g., 128 bytes): if the number of bytes is equal to 128 bytes, the length verification status flag is set to 1 (passed), otherwise it is set to 0 (failed); if it fails, an exception handling process is triggered (e.g., discarding the data block and recording the log).

[0145] Step 513: Compare the binary sequence of the plaintext copy of the identity binding code with the binary sequence of the certificate feature value pre-stored in the secure storage unit of the target device bit by bit to obtain the binding verification status identifier;

[0146] In this step, the binary sequence of the plaintext copy of the identity binding code refers to converting the 8-byte copy data into a 64-bit binary bitstream. The secure storage unit refers to a tamper-proof storage area in the device hardware, allowing only the reading of pre-set certificate signature values. The certificate signature value refers to the first 8 bytes of the target device certificate's 256-bit secure hash value. Before the device leaves the factory, the certificate signature value (the first 8 bytes of the device's public key's 256-bit secure hash) is written into the fuse secure storage unit (which cannot be tampered with) using a secure programming tool. The update mechanism is an over-the-air (OTA) update triggered by the administrator through hardware key authorization. The binary sequence of the certificate signature value refers to the 64-bit binary representation of the certificate signature value, used for bit-by-bit comparison and verification. The binding verification status identifier refers to the binary status of the binding code comparison result (1 = match, 0 = mismatch), determining whether the policy allows execution on this device.

[0147] In this embodiment of the invention, the pre-stored certificate feature value (8 bytes) is read from the read-only area of ​​the target device's secure storage unit, and the binary sequence of the plaintext copy of the identity binding code is compared bit by bit with the certificate feature value: if all bits are the same, the binding verification status identifier is set to 1 (match), otherwise it is set to 0 (mismatch).

[0148] Step 514: Based on the length verification status identifier and the binding verification status identifier, determine the fourth intermediate strategy carrier that has passed verification as the post-verification strategy carrier;

[0149] In this step, the verified policy carrier refers to the fourth intermediate policy carrier that has passed both length verification and binding verification. It is the sole input source for subsequent encryption operations, ensuring the legitimacy of the encrypted object.

[0150] In this embodiment of the invention, when the length verification status flag is 1 and the binding verification status flag is 1, it is determined that the fourth intermediate strategy carrier has passed the verification and is completely copied into the verified strategy carrier; if either flag is 0, the verified strategy carrier is not generated and the exception handling process is directly entered.

[0151] In this embodiment of the invention, the pre-stored certificate feature value (8 bytes) is read from the read-only area of ​​the target device's secure storage unit, and the binary sequence of the plaintext copy of the identity binding code is compared bit by bit with the certificate feature value: if all bits are the same, the binding verification status identifier is set to 1 (match), otherwise it is set to 0 (mismatch).

[0152] Step 515: Perform numerical transformation and position permutation operations on each byte of the verified policy carrier to generate an encrypted data block;

[0153] In this step, the encrypted data block refers to the ciphertext data block after the verified policy carrier has undergone numerical transformation (i.e., circular left shift + XOR) and position permutation (i.e., parity rearrangement), which is used to prevent the policy content from being leaked.

[0154] In this embodiment of the invention, each byte of the verified strategy carrier undergoes a numerical transformation and positional permutation operation: the numerical transformation employs a 3-bit left circular shift followed by an XOR operation with the device's unique key, where the key is generated at the factory based on a hardware universal unique identifier (e.g., a 256-bit hash value from the first 8 bytes of the universal unique identifier), replacing the fixed key 0xB5, thus conforming to cryptographic security principles; after the numerical transformation, the order of all bytes is rearranged according to the rule of odd-numbered bytes first and even-numbered bytes last, generating an encrypted data block; the memory space occupied by the encrypted data block is traversed, and the total number of bytes is calculated from the starting address to the ending address: the exact total number of bytes is obtained by subtracting the starting address from the ending address and then adding 1.

[0155] Step 516: Based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, generate an adaptive security policy executable by the target device;

[0156] In this embodiment of the invention, when both the length verification status and the binding verification status are verified, a preset policy validity flag field is inserted into the header field of the encrypted data block to generate an adaptive security policy; when the length verification status is verified, a policy invalid alarm data block is created, and a policy exception flag field is added to the header field of the policy invalid alarm data block to generate an adaptive security policy. The policy invalid alarm data block includes an error type code, total number of bytes, and a timestamp; when both the length verification status and the binding verification status are verified, a device binding failure data block is created, and a policy exception flag field is added to the header field of the device binding failure data block to generate an adaptive security policy. The device binding failure data block includes an error type code, a copy of the certificate feature value, and a plaintext copy of the identity binding code.

[0157] The embodiments of this invention enhance the confidentiality and tamper-proof capability of policy data during transmission or storage; achieve strong binding between security policies and specific device identities to prevent policies from being illegally copied or replayed to unauthorized devices; combine with the length verification mechanism of encrypted data blocks to ensure the integrity and format compliance of the policy carrier and avoid security vulnerabilities caused by data truncation or injection; improve the device authentication reliability, data integrity and execution security of adaptive security policies under a zero-trust architecture, and ensure that dynamic access control in the Internet of Things environment is more trustworthy and controllable.

[0158] This invention provides a specific embodiment, step 516, which generates an adaptive security policy executable by the target device based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, specifically including the following steps:

[0159] Step 521: When the length verification status indicator is verified as passed and the binding verification status indicator is verified as passed, insert a preset policy validity flag field into the header field of the encrypted data block to generate an adaptive security policy.

[0160] In this step, the policy validity flag field refers to the 2-byte identifier code in the policy header (a fixed value of 0xAA55), indicating that the policy has been verified and can be directly loaded and executed by the device kernel.

[0161] In this embodiment of the invention, when both the length verification status flag and the binding verification status flag are 1: a 2-byte policy validity flag field is inserted at the starting address of the encrypted data block to form a complete policy data body; the data body is transmitted to the execution unit through the device policy bus to generate an adaptive security policy executable by the target device.

[0162] Step 522: When the length verification status is marked as verification failed, create a policy invalid alarm data block, add a policy exception flag field to the header field of the policy invalid alarm data block, and generate an adaptive security policy. The policy invalid alarm data block includes an error type code, total number of bytes, and a timestamp.

[0163] In this step, the policy anomaly flag field refers to the 2-byte identifier in the alarm policy header, which the device kernel recognizes and triggers the alarm process. The policy invalid alarm data block refers to the 32-byte data structure generated when the length is abnormal, including: the policy anomaly flag field in the header, the error type code, the actual number of bytes, and the timestamp (i.e., the time when the anomaly occurred). The error type code refers to a 1-byte error classification identifier, where 0xF001 indicates an abnormal policy length and 0xF002 indicates a device certificate binding failure.

[0164] In this embodiment of the invention, when the length verification status is 0 (i.e., failed): a 32-byte policy invalid alarm data block is created, and a policy exception flag field (i.e., fixed value 0xEE11) is written to its header; and the error type code (0xF001 indicates length exception), total number of bytes, and current timestamp (binary encoded decimal number format) are written sequentially in the middle of the data block; the alarm data body is encapsulated as an adaptive security policy output.

[0165] Step 523: When the length verification status is verified as passed and the binding verification status is verified as failed, create a device binding failure data block, add a policy exception flag field to the header field of the device binding failure data block, and generate an adaptive security policy. The device binding failure data block includes an error type code, a certificate feature value copy, and a plaintext copy of the identity binding code.

[0166] In this step, the device binding failure data block refers to the 40-byte data structure generated when the devices do not match. It includes: a policy exception flag field in the header, an error type code, a copy of the certificate signature value (pre-stored value on the device), and a plaintext copy of the identity binding code (policy-carried value). The copy of the certificate signature value refers to the 8-byte certificate hash value copied from the device's secure storage unit, used for comparison and verification with the policy binding code.

[0167] In this embodiment of the invention, when the length verification status is 1 (i.e., verification passed) but the binding verification status is 0 (i.e., mismatch): a 40-byte device binding failure data block is created, and a policy exception flag field (i.e., fixed value 0xEE22) is added to the header; an error type code, a copy of the certificate feature value, and a plaintext copy of the identity binding code are written in the middle; finally, it is encapsulated into an adaptive security policy output.

[0168] This invention provides dual protection for the integrity and legitimacy of security policies before execution; facilitates fault tracing and security auditing; generates a failure data block carrying certificate feature values ​​and identity binding codes in plaintext when only binding verification fails, which helps to accurately locate device identity authentication problems; improves the anti-tampering capability and device identity credibility of the policy distribution process; and enhances the maintainability and accuracy of security response of the system through fine-grained anomaly feedback, supporting the dynamic and trusted policy deployment in IoT environments under a zero-trust architecture.

[0169] Figure 2 This invention provides a schematic diagram of the structure of an adaptive security policy generation system for a zero-trust architecture, as shown in the embodiment of the invention. Figure 2 As shown, the system includes:

[0170] The acquisition module 21 is used to acquire physical environment data of IoT devices, including device displacement distance, ambient temperature value and geographic location coordinates;

[0171] Calculation module 22 is used to calculate the initial zero-trust risk value based on the device displacement distance, ambient temperature value and geographical coordinates;

[0172] Adjustment module 23 is used to adjust the initial zero-trust risk value based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, so as to obtain a comprehensive environmental risk index.

[0173] The generation module 24 is used to generate resource access control instructions that only open the basic application interface when the comprehensive environmental risk index exceeds the first threshold, and to generate resource access control instructions that are authorized according to the preset minimum permission range when the comprehensive environmental risk index does not exceed the first threshold.

[0174] The conversion module 25 is used to convert the resource access control instructions into an adaptive security policy that can be executed by the target device.

[0175] Figure 2 The aforementioned adaptive security policy generation system for zero-trust architecture can execute... Figure 1 The implementation principle and technical effects of the adaptive security policy generation method for zero-trust architecture described in the illustrated embodiment will not be repeated here. The specific methods by which each module and unit performs operations in the adaptive security policy generation system for zero-trust architecture described in the above embodiments have been described in detail in the embodiments related to this method, and will not be elaborated upon here.

[0176] In one possible design, Figure 2 An adaptive security policy generation system for a zero-trust architecture, as illustrated in the embodiment, can be implemented as a computing device, such as... Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32;

[0177] The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are invoked and executed by the processing component 32.

[0178] The processing component 32 is used for the above Figure 1 The embodiment describes an adaptive security policy generation method for a zero-trust architecture.

[0179] The processing component 32 may include one or more processors to execute computer instructions to complete all or part of the steps in the above-described method. Alternatively, the processing component may be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above-described method.

[0180] Storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0181] Of course, computing devices may also include other components, such as input / output interfaces, display components, communication components, etc.

[0182] Input / output interfaces provide interfaces between processing components and peripheral interface modules, which can be output devices, input devices, etc.

[0183] The communication components are configured to facilitate wired or wireless communication between computing devices and other devices.

[0184] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform. In this case, the computing device can refer to a cloud server, and the aforementioned processing components, storage components, etc., can be basic server resources rented or purchased from the cloud computing platform.

[0185] This invention also provides a computer storage medium storing a computer program, which, when executed by a computer, can perform the above-described functions. Figure 1 The illustrated embodiment presents an adaptive security policy generation method for a zero-trust architecture.

[0186] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0187] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0188] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

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

Claims

1. An adaptive security policy generation method for zero-trust architecture, characterized in that, include: Collect physical environment data of IoT devices, including device displacement distance, ambient temperature value, and geographic location coordinates; Based on the device displacement distance, ambient temperature value, and geographical coordinates, an initial zero-trust risk value is calculated; Based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, the initial zero-trust risk value is adjusted to obtain the comprehensive environmental risk index. When the comprehensive environmental risk index exceeds the first threshold, a resource access control instruction that only opens the basic application programming interface is generated; when the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction that authorizes access within a preset minimum permission range is generated. The resource access control instructions are converted into an adaptive security policy executable by the target device; Transforming the resource access control instructions into an adaptive security policy executable by the target device includes: Create the initial strategy carrier; The permission level identifier in the resource access control instruction is converted into the target device policy type code, and the target device policy type code is written into the header field of the initial policy carrier to obtain the first intermediate policy carrier. Write the interface call identifier registered by the target device kernel into the interface permission field of the first intermediate policy carrier to obtain the second intermediate policy carrier; The call constraint rules in the resource access control instructions are compiled into a restriction parameter structure that can be recognized by the target device, and the restriction parameter structure is written into the constraint rule field of the second intermediate policy carrier to obtain the third intermediate policy carrier. Write the policy effective start time and effective duration into the control field of the third intermediate policy carrier, and add the identity binding code derived from the target device certificate to the tail field of the third intermediate policy carrier to obtain the fourth intermediate policy carrier. The fourth intermediate policy carrier is verified to generate a verified policy carrier, which is then encrypted to generate an adaptive security policy executable by the target device.

2. The method according to claim 1, characterized in that, When the comprehensive environmental risk index exceeds a first threshold, a resource access control instruction that only opens the basic application programming interface is generated. When the comprehensive environmental risk index does not exceed the first threshold, a resource access control instruction authorized according to a preset minimum permission range is generated, including: The comprehensive environmental risk index is compared with the first threshold value to generate a first permission level identifier or a second permission level identifier. If a first permission level identifier is generated, then a list of interface names of a subset of basic application interfaces is extracted from the pre-stored permission level set. If a second permission level identifier is generated, then the list of interface types and the upper limit of call frequency of the minimum permission range interface set are extracted from the pre-stored permission level set. When the comprehensive environmental risk index exceeds the first threshold, the first permission level identifier and the list of interface names are written into the initial structured instruction data body, and a resource access control instruction that only opens the basic application interface is generated. The initial structured instruction data body embeds the instruction generation time and the device authentication code. When the comprehensive environmental risk index does not exceed the first threshold, the second permission level identifier, the interface type list, and the upper limit of the call frequency are written into the initial structured instruction data body to generate a resource access control instruction authorized according to the preset minimum permission range.

3. The method according to claim 1, characterized in that, The fourth intermediate policy carrier is verified to generate a verified policy carrier, which is then encrypted to generate an adaptive security policy executable by the target device, including: Extract a byte sequence of a preset length from the tail field of the fourth intermediate strategy carrier, and use the byte sequence as a plaintext copy of the identity binding code; The total number of bytes in the fourth intermediate strategy carrier is counted, and the total number of bytes is compared with a preset length value to obtain a length verification status identifier; The binary sequence of the plaintext copy of the identity binding code is compared bit by bit with the binary sequence of the certificate feature value pre-stored in the secure storage unit of the target device to obtain the binding verification status identifier. Based on the length verification status identifier and the binding verification status identifier, the fourth intermediate strategy carrier that has passed the verification is determined as the post-verification strategy carrier. Each byte of the verified policy carrier is subjected to numerical transformation and positional permutation operations to generate an encrypted data block; Based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, an adaptive security policy executable by the target device is generated.

4. The method according to claim 3, characterized in that, Based on the encrypted data block, the length verification status identifier, and the binding verification status identifier, an adaptive security policy executable by the target device is generated, including: When the length verification status is verified as passed and the binding verification status is verified as passed, a preset policy validity flag field is inserted into the header field of the encrypted data block to generate an adaptive security policy. When the length verification status is marked as verification failed, a policy invalid alarm data block is created. A policy exception flag field is added to the header field of the policy invalid alarm data block to generate an adaptive security policy. The policy invalid alarm data block includes an error type code, total number of bytes, and a timestamp. When the length verification status is verified as passed and the binding verification status is verified as failed, a device binding failure data block is created. A policy exception flag field is added to the header field of the device binding failure data block to generate an adaptive security policy. The device binding failure data block includes an error type code, a certificate feature value copy, and a plaintext copy of the identity binding code.

5. The method according to claim 1, characterized in that, Based on the device displacement distance, ambient temperature value, and geographical coordinates, an initial zero-trust risk value is calculated, including: Based on the minimum physical movement range allowed by the device functions of the IoT device, a displacement authorization threshold is determined, and the cumulative value of the time window in which the device displacement distance exceeds the displacement authorization threshold is calculated to generate a zero-trust displacement deviation. Based on the minimum temperature tolerance range allowed for the safe operation of IoT devices, the temperature authorization boundary is determined, and the instantaneous out-of-bounds amount when the ambient temperature value exceeds the temperature authorization boundary is extracted to generate a zero-trust temperature anomaly. Based on the minimum safe zone allowed for the operation of IoT devices, determine the location authorization range, calculate the real-time shortest distance from the geographic location coordinates to the location authorization range, and generate a zero-trust location offset. According to the zero-trust risk weight allocation rule, the zero-trust displacement deviation, zero-trust temperature anomaly and zero-trust position offset are weighted and summed to obtain the initial zero-trust risk value.

6. The method according to claim 1, characterized in that, Based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, the initial zero-trust risk value is adjusted to obtain a comprehensive environmental risk index, including: The byte encoding structure of the sensitivity level identifier of the IoT device in the zero-trust architecture is parsed to separate the device type encoding field and the risk level value; Based on the device type coding field, query the preset adjustment factor benchmark table to obtain the basic adjustment coefficient corresponding to the IoT device, and set the scaling ratio value based on the risk level value. The dynamic adjustment factor is obtained by multiplying the basic adjustment coefficient and the scaling ratio. Combined with the initial zero-trust risk value and the equipment environment baseline value, a preliminary environmental risk index is calculated. The equipment environment baseline value is a preset equipment inherent risk constant. Based on the preset maximum risk threshold, the preliminary environmental risk index is truncated to obtain the truncated risk index, which is then used as the comprehensive environmental risk index.

7. An adaptive security policy generation system for zero-trust architecture, used in the adaptive security policy generation method for zero-trust architecture as described in any one of claims 1 to 6, characterized in that, include: The data acquisition module is used to collect physical environment data of IoT devices, including device displacement distance, ambient temperature value, and geographic location coordinates. The calculation module is used to calculate the initial zero-trust risk value based on the device displacement distance, ambient temperature value, and geographical coordinates. The adjustment module is used to adjust the initial zero-trust risk value based on the application policy adjustment factor corresponding to the sensitivity level identifier of the IoT device in the zero-trust architecture, so as to obtain a comprehensive environmental risk index. The generation module is used to generate resource access control instructions that only open the basic application programming interface when the comprehensive environmental risk index exceeds the first threshold, and to generate resource access control instructions that are authorized according to the preset minimum permission range when the comprehensive environmental risk index does not exceed the first threshold. The conversion module is used to convert the resource access control instructions into an adaptive security policy that can be executed by the target device.

8. A computing device, characterized in that, It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are invoked and executed by the processing component to implement an adaptive security policy generation method for a zero-trust architecture as described in any one of claims 1 to 6.

9. A computer storage medium, characterized in that, The system contains a computer program that, when executed by a computer, implements an adaptive security policy generation method for a zero-trust architecture as described in any one of claims 1 to 6.

Images