Network security early warning method and system based on supply chain

Abstract

The invention relates to the technical field of Internet of Things security, in particular to a network security early warning method and system based on a supply chain, and the method comprises the following steps: when Internet of Things security terminal equipment is started, extracting a unique identifier of each software component in a self software material list, and obtaining a public key of a vulnerability information publishing center; and encrypting the unique identifier of the software component. According to the method, early warning of potential attack behaviors is realized, two different security states of only existence of vulnerabilities and utilization of the vulnerabilities can be distinguished, a drift value is combined with a timestamp and a random number, digital signature is performed by a trusted execution environment, and an unforgeable signature certification result is generated. According to the invention, a high-credibility decision basis is provided for the management platform, so that the management platform can automatically execute mitigation measures based on the confirmed equipment end evidence, the timeliness of threat response is improved, and the risk of service interruption caused by misjudgment is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things security, and in particular to a method and system for network security early warning based on a supply chain. BACKGROUND

[0002] The technical field of network security is committed to providing security protection for the Internet of Things ecosystem, protecting the perception layer, network layer and application layer that constitute the Internet of Things from various network threats.

[0003] Existing security protection measures for the Internet of Things rely on periodic scanning of device firmware by an external management platform or passive reception of broadcasts of vulnerability information libraries, and can only identify software components in the device that contain known vulnerabilities, but it is difficult to determine whether the vulnerability can be exploited in a specific running environment, and it is even more difficult to perceive in the early stage of exploitation of the vulnerability by an attacker. At the same time, the traditional security alarm mechanism lacks a reliable trust root, and the security status report at the device end can be tampered with or forged by malicious software, and the authenticity of the information received by the management platform is questionable. This uncertainty makes it difficult for the platform to implement automated and decisive mitigation strategies. Therefore, improvements are needed. SUMMARY

[0004] The purpose of the present application is to solve the shortcomings in the prior art, and a method and system for network security early warning based on a supply chain are proposed.

[0005] In order to achieve the above-mentioned purpose, the present application adopts the following technical solution, a method for network security early warning based on a supply chain, comprising the following steps: When the Internet of Things security terminal device starts, the unique identifier of each software component in the software bill of materials is extracted, the public key of the vulnerability information publishing center is obtained, the software component unique identifier is encrypted, the encrypted component subscription list is generated, and the standard control flow graph of the firmware key security function is loaded into the trusted execution environment together with the encrypted component subscription list to establish a trusted execution environment baseline; According to the trusted execution environment baseline, the Internet of Things security terminal device receives a structured risk notification message from the vulnerability information publishing center, decrypts and verifies the digital signature by calling the public key stored in the trusted execution environment baseline, obtains the verified risk notification, and matches the component identifier in the verified risk notification with the software bill of materials of the device one by one to generate a component-associated risk vector; According to the trusted execution environment baseline and the component-associated risk vector, the basic block ID sequence passed through by the affected key security function runtime is recorded in the trusted execution environment to form a real-time execution trajectory sequence, and the standard control flow graph in the trusted execution environment baseline is called to compare the real-time execution trajectory sequence with the standard control flow graph to calculate a deterministic drift value; According to the deterministic drift value and the component-associated risk vector, a deterministic drift value, a current timestamp, and a random number provided by a management platform are combined, a private key pair is called by a trusted execution environment to perform a signature operation on the combined data to generate a signature proof result, the signature proof result and the component-associated risk vector are sent to the management platform, after verification of the signature proof result, it is determined whether to trigger a mitigation measure according to a preset strategy, and a device-side mitigation instruction is obtained.

[0006] Preferably, the obtaining step of the trusted execution environment baseline is: When the Internet of Things security terminal device is started, a software bill of materials is read, component records are parsed by rows, component name fields, version fields, and supplier fields are extracted, and a single software component unique identifier is spliced in a fixed order to obtain a software component unique identifier sequence; According to the software component unique identifier sequence, a public key of a vulnerability information publishing center is requested, an encoding format, a fingerprint digest, and a validity period label are verified, a software component unique identifier is encrypted and a corresponding ciphertext entry is generated, the entry list is compiled according to the original sequence number and written into a source label and a time label, and an encrypted component subscription list is generated; According to the encrypted component subscription list, a standard control flow graph of a firmware key security function is located from a firmware image, node numbers, edge sets, and entry and exit identifications are checked, a protected loading entry of a trusted execution environment is called, the standard control flow graph and the encrypted component subscription list are written into the same security area, a loading batch label, a loading time label, and a verification digest are recorded, and a trusted execution environment baseline is established.

[0007] Preferably, the obtaining step of the verified risk notification is: According to the trusted execution environment baseline, a structured risk notification message is received, a source identification, a time label, and a content encoding of a message header are verified, field boundaries of a message body are parsed and a digital signature field and a message body field are located, an encoding byte sequence of the digital signature is extracted, structured key-value pairs of the message body are extracted, and a structured risk notification message parsing result is generated; According to the structured risk notification message parsing result, a public key fingerprint and a public key content saved in the trusted execution environment baseline are read, it is verified that the public key fingerprint is consistent with the source identification in the structured risk notification message parsing result, the digital signature in the structured risk notification message parsing result is decrypted and compared using the public key, and a verification state label is recorded, records with a failed verification state label are filtered out, and a verified risk notification is obtained.

[0008] Preferably, the obtaining step of the component-associated risk vector is: Based on the verified risk notices, the component identifier list of the device's own software bill of materials is read, and the component identifiers in the verified risk notices are compared with the component identifier list of the software bill of materials one by one. The successfully matched component identifiers are extracted, and the vulnerability details and risk levels are read from the verified risk notices. The components are then concatenated in a fixed order of component identifier, vulnerability details, and risk level to form an entry sequence, thereby generating a component-associated risk vector.

[0009] Preferably, the step of obtaining the real-time execution trajectory sequence is as follows: Based on the trusted execution environment baseline, the identifiers of the critical security functions affected in the component-associated risk vector are read, the basic block IDs, entry times, and exit times of the critical security functions during execution are captured, and each capture result is arranged in chronological order to form a real-time execution trajectory sequence.

[0010] Preferably, the step of obtaining the deterministic drift value is as follows: Based on the real-time execution trajectory sequence, the standard control flow graph within the baseline of the trusted execution environment is invoked, and each basic block ID is compared with the control flow graph node to confirm the legal path and the illegal jump path. Paths that are not executed are extracted and the number of edges of each path is counted. At the same time, the difference between the runtime of each basic block and the runtime of the baseline is calculated to obtain the graph comparison parameter set. The deterministic drift value is calculated based on the parameter set compared with the graph.

[0011] Preferably, the steps for obtaining the signature proof result are as follows: Based on the deterministic drift value and the component-associated risk vector, read the random number and the current timestamp of the local security clock, and serialize the deterministic drift value, the current timestamp, the random number, and the component-associated risk vector into a fixed-length byte sequence in a fixed field order to generate combined data; Based on the combined data, the private key material is located by calling the key identifier within the trusted execution environment, the private key activation status flag, key usage flag and key storage area label are verified, the message digest of the combined data is calculated according to the agreed digest process and the private key is signed to generate a signature proof result.

[0012] Preferably, the step of obtaining the device-side mitigation command is as follows: Based on the signature verification result, the signature verification result and component-associated risk vector are encapsulated in the session channel between the device and the management platform, and the device identifier, session sequence number and integrity verification value are filled in. After being sent to the management platform, the platform verifies the source, validity period and non-reused status of the signature verification result, and then compares the deterministic drift value threshold and risk level threshold according to the preset strategy and selects whether to trigger the mitigation process, and returns the mitigation instruction to the device.

[0013] This invention also provides a network security early warning system, including: The initialization module is used to extract the unique identifier of each software component in its own software bill of materials and obtain the public key of the vulnerability information release center when the IoT security terminal device starts up. It encrypts the unique identifier of the software component, generates an encrypted component subscription list, and then loads the standard control flow graph of the firmware key security function together with the encrypted component subscription list into the trusted execution environment to establish a trusted execution environment baseline. The risk matching module is used to, based on the trusted execution environment baseline, receive structured risk announcement messages from the vulnerability information release center, call the public key stored in the trusted execution environment baseline to decrypt and verify the digital signature, obtain the verified risk announcement, match the component identifiers in the verified risk announcement with the device's own software bill of materials one by one, and generate a component-associated risk vector. The operation monitoring module is used to record the basic block ID sequence that the affected critical safety function passes through during its execution within the trusted execution environment based on the risk vector associated with the trusted execution environment baseline and the component, forming a real-time execution trajectory sequence. It then calls the standard control flow graph within the trusted execution environment baseline, compares the real-time execution trajectory sequence with the standard control flow graph using graph distance, and calculates the deterministic drift value. The early warning response module is used to combine the deterministic drift value, the current timestamp, and a random number provided by the management platform according to the deterministic drift value and the component-associated risk vector. The trusted execution environment calls the private key to perform a signature operation on the combined data to generate a signature proof result. The signature proof result and the component-associated risk vector are sent to the management platform. After verifying the signature proof result, the module determines whether to trigger mitigation measures according to a preset strategy and obtains the device-side mitigation instruction.

[0014] Compared with the prior art, the advantages and positive effects of the present invention are as follows: This invention extracts the software bill of materials during device startup and combines it with the standard control flow graph of critical security functions to build a security baseline in a trusted execution environment. Upon receiving a risk notification related to itself, it no longer remains at the static notification level but initiates targeted runtime monitoring of the affected critical security functions. By capturing real-time execution trajectory sequences and comparing them with the standard control flow graph in the baseline, this shift from static vulnerability association to dynamic behavior drift quantification enables early warning of potential attack behaviors. It can distinguish between two distinct security states: the mere existence of a vulnerability and the vulnerability being exploited. This drift value is combined with a timestamp and a random number, and digitally signed by the trusted execution environment to generate an unforgeable signature proof result. This provides the management platform with a highly reliable decision-making basis, enabling it to automatically execute mitigation measures based on solid device-side evidence, improving the timeliness of threat response and reducing the risk of business interruption due to misjudgment. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

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

[0017] Please see Figure 1 This invention provides a technical solution: a method for network security early warning based on the supply chain, comprising the following steps: When an IoT security terminal device starts up, it extracts the unique identifier of each software component in its own software bill of materials, obtains the public key of the vulnerability information release center, encrypts the unique identifier of the software component, generates an encrypted component subscription list, and then loads the standard control flow graph of the firmware's key security functions along with the encrypted component subscription list into the trusted execution environment to establish a trusted execution environment baseline. Based on the Trusted Execution Environment (TEE) baseline, the IoT security terminal device receives a structured risk notification message from the vulnerability information release center, calls the public key stored in the TEE baseline to decrypt and verify the digital signature, obtains the verified risk notification, and matches the component identifier in the verified risk notification with the device's own software bill of materials one by one to generate a component-associated risk vector. Based on the trusted execution environment baseline and the component-associated risk vector, the basic block ID sequence traversed by the affected critical safety function during runtime is recorded within the trusted execution environment to form a real-time execution trajectory sequence. The standard control flow graph within the trusted execution environment baseline is then invoked, and the real-time execution trajectory sequence is compared with the standard control flow graph using graph distance to calculate the deterministic drift value. Based on the deterministic drift value and the component-associated risk vector, the deterministic drift value, the current timestamp, and the random number provided by the management platform are combined. The trusted execution environment calls the private key to perform a signature operation on the combined data, generating a signature proof result. The signature proof result and the component-associated risk vector are sent to the management platform. After verifying the signature proof result, it is determined whether to trigger mitigation measures according to the preset strategy, and the device-side mitigation instruction is obtained.

[0018] The steps for obtaining the trusted execution environment baseline are as follows: When the IoT security terminal device starts up, the software bill of materials is read, the component records are parsed line by line, the component name field, version field and supplier field are extracted, and they are concatenated in a fixed order to form a unique identifier for a single software component, thus obtaining a unique identifier sequence for the software component. Based on the unique identifier sequence of the software components, request the public key of the vulnerability information release center, verify the encoding format, fingerprint digest and validity period label, encrypt the unique identifier of the software components one by one and generate corresponding ciphertext entries, compile them into an entry list according to the original sequence number and write the source label and time label to generate an encrypted component subscription list. Based on the encrypted component subscription list, locate the standard control flow graph of the firmware's critical security functions from the firmware image, verify the node numbers, edge sets, and entry / exit identifiers, call the protected loading entry point of the trusted execution environment, write the standard control flow graph and the encrypted component subscription list into the same secure area, record the loading batch label, loading time label, and verification digest, and establish a trusted execution environment baseline.

[0019] Specifically, when the IoT security terminal device starts up, it reads the software bill of materials. First, it confirms the data format, such as CycloneDX or SPDX, and calls the corresponding JSON or XML parser. Then, it initiates a loop traversal process, reading each software component record line by line. For each record, a temporary data structure is established to store the target field values. Next, it extracts predefined target fields, specifically the component name field with the key "name", the version field with the key "version", and the supplier field with the key "supplier" or "vendor". During extraction, each field value undergoes standardized preprocessing, including removing leading and trailing whitespace and converting all English characters to lowercase. If a field is missing, it is filled with a pre-defined empty string placeholder "NA". Then, following a fixed concatenation order of "supplier field:component name field:version field", the three standardized field values ​​are concatenated using colons as separators to form a unique string, i.e., a unique identifier for each software component. For example, for a record like {supplier: "OpenSSL", name: "openssl", ... The components with version: "1.1.1k" are concatenated to generate "openssl:openssl:1.1.1k". This generated identifier is added to a pre-initialized dynamic array or list. This process is repeated until all component records have been processed, and finally an ordered set containing the unique identifiers of all software components on the device is obtained, which is the sequence of unique identifiers of software components.

[0020] Based on the unique identifier sequence of the software component obtained in the previous step, an HTTPS GET request is first initiated to the vulnerability information release center via a pre-set Uniform Resource Locator (URL) to obtain its public key certificate. After receiving the certificate data, a series of strict verifications are performed. The first step is encoding format verification, checking whether it conforms to the PEM encoding standard, i.e., starting with "-----BEGIN PUBLIC KEY-----" and ending with "-----END PUBLIC KEY-----". The second step is fingerprint digest verification, using the SHA-256 hash algorithm to calculate the digest value of the received public key and comparing it byte by byte with the pre-burned fingerprint digest of the legitimate public key belonging to the vulnerability information release center in the firmware to ensure that the two are completely consistent. The third step is validity period label verification, parsing the X.509 structure in the certificate to extract "Not Before" and "Not The "After" field is compared with the device's local secure clock to confirm that the current time is within the validity period. Only when all three checks pass is the public key considered trustworthy and used for subsequent encryption operations. Then, an iterative process is initiated, traversing each identifier in the software component's unique identifier sequence. For each identifier string, the RSA encryption algorithm is called, along with the OAEP padding scheme, using the verified public key for encryption operations to generate binary ciphertext data. This binary ciphertext data is then converted to a string format using Base64 encoding to form a ciphertext entry. Simultaneously, a new JSON object structure is created to construct the final list. This object contains three top-level keys: "source," whose value is set to the URL of the vulnerability information release center; "timestamp," whose value is the UTC timestamp of the current operation; and "items," whose value is an array used to store all generated ciphertext entries in order. After the iteration is complete, this JSON object containing the source, time, and list of encrypted entries is the generated encrypted component subscription list.

[0021] Based on the encrypted component subscription list generated in the previous step, the standard control flow graph (CFG) of critical security functions stored in the firmware image is located. This is done by reading the metadata table located at a fixed offset address (e.g., 0x8000) within the firmware image to find pointers and length information to the defined CFG data blocks, thus pinpointing their physical location. These critical security functions specifically refer to functions performing core encryption, signature verification, or secure memory management operations, such as "device_attestation" or "secure_boot_verify". After reading the raw binary CFG data, it is parsed into a graph data structure consisting of a set of nodes and a set of edges, and a structural integrity check is immediately performed. This check includes: traversing all nodes to confirm that each node's ID is unique in the graph; checking each edge in the edge set to verify that both the starting and target nodes it connects actually exist in the node set; and so on. After confirming the existence of a unique node marked as an "entry point" and at least one node marked as an "exit point" in the graph, the calibrated standard control flow graph data and the encrypted component subscription list are serialized in memory into a continuous, single data block. The SHA-256 hash value of this data block is calculated to obtain the verification digest. Next, the protected loading API entry provided by the Trusted Execution Environment (TEE), such as a function named tee_load_baseline_data, is called. This continuous data block, along with its verification digest, a newly generated UUID as the loading batch label, and the current system timestamp as the loading timestamp, are passed as parameters. The underlying logic of the TEE is responsible for writing all this data into its memory-protected secure area. After completing this series of operations, a TEE baseline containing software component subscription information, key function behavior benchmarks, and integrity metadata is successfully established.

[0022] The steps to obtain a verified risk notification are as follows: Based on the Trusted Execution Environment baseline, receive structured risk notification messages, verify the source identifier, timestamp, and content encoding of the message header, parse the field boundaries of the message body and locate the digital signature field and message body field, extract the encoded byte sequence of the digital signature, extract the structured key-value pairs of the message body, and generate the structured risk notification message parsing result; Based on the structured risk notification message parsing results, read the public key fingerprint and public key content stored in the trusted execution environment baseline, verify that the public key fingerprint matches the source identifier in the structured risk notification message parsing results, use the public key to decrypt and compare the digital signature in the structured risk notification message parsing results, record the verification status label, filter out records with the verification status label of failure, and obtain the verified risk notification.

[0023] Specifically, based on the Trusted Execution Environment (TEE) baseline, the device first continuously listens for incoming data packets on a preset network port. When a TCP data packet conforming to a predetermined format is received, the processing flow is initiated. The data packet content is parsed into a structured risk notification message in JSON format. Next, the message header is validated. First, the source identifier field with the key "source" is extracted from the message header; its content should be a URL, such as "https: / / xxxxxxxxxx / center," and compared with the authorized source identifier stored in the TEE baseline. Second, the timestamp field with the key "timestamp" is extracted; this field is an ISO... The message header is formatted as an 8601 time string and compared with the current time obtained from the device's internal security clock. A time window threshold is set, which is based on historical network latency statistics. For example, the average latency of the past 100 communications is added to three times the standard deviation to calculate a specific latency limit, such as 5 seconds. If the absolute value of the difference between the message time and the current time exceeds 5 seconds, the message is considered invalid. The third step is to verify the content encoding field with the key name "encoding" to confirm that its value is "UTF-8" to ensure the correctness of subsequent parsing. After the message header verification is successful, the message body is parsed. The message body itself is a JSON object containing "message_body" and "di The process begins by locating and extracting the value of the "digital_signature" field, which is a Base64 encoded string. This string is then converted back to its original binary byte sequence using a Base64 decoding function. Next, the "message_body" field is extracted. This is a nested JSON object containing all risk details, and it is extracted as a whole as a structured key-value pair. Finally, the verified source identifier, timestamp, decoded digital signature binary byte sequence, and extracted message body structured key-value pairs are encapsulated together into a temporary in-memory data structure to generate the structured risk notification message parsing result.

[0024] Based on the structured risk notification message parsing result generated in the previous step, the system first calls an internal function interface from the secure storage area of ​​the Trusted Execution Environment (TEE) to read the public key fingerprint and public key content stored during the baseline establishment phase. Then, a source consistency check is performed, comparing the source identifier in the structured risk notification message parsing result with the source identifier bound to the public key stored in the TEE baseline. For example, if the source of the parsing result is "https: / / xxxxxx.info / center", then there must be a record in the baseline that associates this URL with a specific public key fingerprint. Only if the two match completely will the next step proceed. Next, the read public key content is used to verify the digital signature. Specifically, this process involves first performing normalized serialization on the message body field in the structured risk notification message parsing result—the JSON object containing all risk details. This processing includes sorting all keys lexicographically and then... After removing all meaningless whitespace characters, a unique and deterministic string representation is generated. Then, the SHA-256 hash algorithm is used to calculate the message digest of this normalized string, resulting in a 32-byte hash value. Simultaneously, the RSA decryption algorithm is invoked, using a public key obtained from the trusted execution environment, to decrypt the digital signature encoded byte sequence in the structured risk notice message parsing result, obtaining a decrypted hash value. The calculated message digest and the decrypted hash value are compared byte by byte. If they are exactly the same, a verification status label with the value "SUCCESS" is recorded for the notice; otherwise, it is recorded as "FAILURE". After verifying all risk entries contained in the entire message, all records are traversed, and a new list is constructed. Only those records with the verification status label "SUCCESS" are copied to the new list, thereby filtering out all records that have failed verification or have mismatched sources, resulting in verified risk notices.

[0025] The steps for obtaining the component-associated risk vector are as follows: Based on the verified risk announcements, the component identifier list of the device's own software bill of materials is read. The component identifiers in the verified risk announcements are compared with the component identifier list of the software bill of materials one by one. The component identifiers that match are extracted. The vulnerability details and risk levels are read from the verified risk announcements. The components are then concatenated in a fixed order of component identifier, vulnerability details and risk level to form an entry sequence and generate a component-associated risk vector.

[0026] Specifically, based on verified risk bulletins, the process first retrieves a list of component identifiers from the software bill of materials generated during device startup, from the device's runtime memory or non-volatile storage. This list contains string sequences like "openssl:openssl:1.1.1k". Next, a two-level nested loop matching process is initiated. The outer loop iterates through each vulnerability record in the verified risk bulletins, while the inner loop iterates through the device's own list of component identifiers. In each iteration of the loop, the affected component identifiers from the current vulnerability record are extracted. These identifiers may contain version ranges, such as "openssl:openssl:<=1.1.1m". Then, this identifier is compared with the currently iterated device component identifiers. The comparison process is divided into... The vulnerability consists of three parts: the vendor field (openssl) and the component name field (openssl) require exact string matching, while the version field uses semantic version comparison logic. It parses the device version (1.1.1k) and the version range in the vulnerability announcement (<=1.1.1m) to determine if the device version falls within the affected range. Once a matching component is found—meaning a component version installed on the device falls within the risk range of a vulnerability—the associated vulnerability details are immediately extracted from the verified risk announcement. These details include the CVE number (e.g., "CVE-2023-12345") and the risk level string (e.g., "HIGH"). A mapping table from risk level to numerical value is then established, based on the Common Vulnerability Scoring System (CVSS). The v3.1 standard establishes a mapping table, for example, mapping "CRITICAL" to 9.5, "HIGH" to 8.0, "MEDIUM" to 5.5, and "LOW" to 2.0. This mapping table is a constant embedded in the firmware. It converts the risk level strings into corresponding numerical values. Finally, following a fixed order of "successfully matched component identifier; vulnerability details; risk level value", these three pieces of information are concatenated into a string entry using semicolons as separators, such as "openssl:openssl:1.1.1k;CVE-2023-12345;8.0". All the string entries generated in this way are collected into a list to form an entry sequence. This sequence is the final generated component-associated risk vector.

[0027] The steps for obtaining the real-time execution trajectory sequence are as follows: Based on the trusted execution environment baseline, the identifiers of the critical security functions affected in the component-associated risk vector are read, and the basic block IDs, entry times, and exit times of the critical security functions during the execution process are captured. Each capture result is arranged in chronological order to form a real-time execution trajectory sequence.

[0028] Specifically, based on the Trusted Execution Environment baseline, the component-associated risk vector is first parsed. This vector is a sequence of entries, each containing the affected component identifier and corresponding vulnerability information. By consulting a pre-built "vulnerability-function" mapping table in the firmware, the vulnerability identifiers (e.g., CVE numbers) in the entries are converted into one or more specific critical security function identifiers. For example, "CVE-2023-12345" might map to the functions "secure_boot_verify" and "update_firmware_check". Next, runtime monitoring is enabled for all identified critical security functions. This monitoring is achieved through... The Trusted Execution Environment (TEE) dynamically instrumentes the binary code of functions. Specifically, lightweight probe code is inserted at the entry and exit points of each basic block. When a monitored function is called, the entry probe is triggered whenever the program's execution flow enters a basic block. It immediately records the unique digital ID of the current basic block and uses the high-precision clock source within the TEE (such as the CNTPCT_EL0 physical counter under the ARM architecture) to obtain the current timestamp as the entry time. When the execution flow leaves the basic block, the exit probe is triggered, and the current timestamp is obtained again as the exit time. Each complete capture operation generates a data tuple containing {basic block ID, entry time, exit time}. These tuples are appended in real time to a circular buffer maintained in the secure memory of the TEE. The size of this buffer is preset to accommodate the maximum trajectory length generated by a complete function execution, such as 1024 entries. After the function execution is completed, all data tuples in the buffer are stably sorted according to their entry time, ultimately forming an ordered list of tuples, i.e., the real-time execution trajectory sequence.

[0029] The steps to obtain the deterministic drift value are as follows: Based on the real-time execution trajectory sequence, the standard control flow graph within the trusted execution environment baseline is invoked, and each basic block ID is compared with the control flow graph node to confirm the legal and illegal jump paths. Paths that are not executed are extracted and the number of edges of each path is counted. At the same time, the difference between the runtime of each basic block and the runtime of the baseline is calculated to obtain the graph comparison parameter set. Based on the comparison parameter set, the deterministic drift value is calculated using the following formula: ; in, For deterministic drift values, These are the weighting coefficients for the drift component of the control flow structure. To determine the weighting coefficients for the timing drift portion, the following conditions must be met: , The control flow structure drift value is calculated using the following formula: ,in The number of illegal redirects. For the first The length of the detour path for an illegal jump. For the first The centrality value of an illegal jump origin node This represents the total number of basic blocks in a standard control flow graph. The number of necessary paths not executed. For the first The number of edges on which the necessary path was not executed. For the first The score for the non-substitutability of a path that did not execute the necessary path. This represents the total number of edges in a standard control flow graph. The formula for calculating the timing drift value is as follows: ,in To determine the number of valid basic blocks in the real-time execution trajectory sequence, For the first The timing sensitivity factor of each basic block, For the first The actual runtime of a basic block. For the first Baseline runtime of each basic block, To prevent extremely small positive numbers with a denominator of zero.

[0030] Specifically, based on the real-time execution trajectory sequence formed in the previous step, the corresponding standard control flow graph is loaded from the trusted execution environment baseline. This graph is stored in the form of an adjacency list for efficient querying. Then, an iterative analysis process is initiated, processing the basic block transitions in the real-time execution trajectory sequence one by one. For any two adjacent basic blocks in the sequence (e.g., the ID of the i-th basic block and the ID of the (i+1)-th basic block), the set of edges originating from the i-th basic block ID is searched in the adjacency list of the standard control flow graph. It is checked whether there exists an edge pointing to the (i+1)-th basic block ID in this set. If it exists, the transition between these two basic blocks is marked as part of a valid path, and the (i+1)-th basic block ID is added to a set of executed valid nodes. If it does not exist, this transition is identified as an illegal jump, and the pair of (starting ID, ending ID) is recorded as evidence of the illegal jump path. After traversing the entire execution trajectory, the paths pre-marked as "necessary" in the standard control flow graph are... Paths (e.g., code branches that perform integrity checks or permission checks, which are identified and marked during firmware static analysis) are compared with the set of executed legitimate nodes. All necessary paths that have not been executed are identified through set difference operations. For each unexecuted path, the number of edges is counted by tracing back its node sequence in the standard control flow graph. Meanwhile, for each basic block that is confirmed as legitimate in the real-time execution trajectory sequence, its actual runtime is calculated, i.e., its exit time minus its entry time. The baseline runtime of the basic block is then read from the trusted execution environment baseline. This baseline runtime is obtained by running the function 1000 times in an interference-free environment before the device leaves the factory and taking the average of all runtimes. The difference between the two is calculated. Finally, all identified illegal jump paths, necessary paths that have not been executed and their number of edges, and the difference between the runtime of each legitimate basic block and the baseline runtime are summarized and organized into a structured dataset to obtain the graph comparison parameter set.

[0031] In the formula for calculating the deterministic drift value, firstly, in the control flow structure drift value ( In the calculation, not only were illegal control flow jumps and bypassed critical paths statistically analyzed, but path complexity (by the length of bypassed paths) was also introduced. (represented by the logarithm), the criticality of the jump starting point (through the centrality value of the node). (Measured by) and the non-substitutability of bypassed paths (scored by non-substitutability score) To assess, the assessment results can better reflect the potential harm of the attack; second, in the execution time drift value ( In the calculation of ), a time-series sensitivity factor ( This assigns higher weights to code blocks whose execution time is strongly correlated with security (such as constant-time operations in cryptographic computations), thereby increasing their sensitivity to timing attacks (such as side-channel attacks).

[0032] This parameter represents the weighting coefficient for the drift portion of the control flow structure. It reflects the importance of control flow integrity relative to execution timing in a specific application scenario. Its value is set based on a risk assessment of the core functions of IoT security terminal devices. For devices that primarily execute deterministic control logic and state transitions (e.g., industrial controllers), the correctness of the control flow is crucial. A higher value should be set, especially for devices involving a large number of encryption operations or those needing to defend against side-channel attacks (such as secure payment terminals), where the stability of the execution timing is even more critical. A higher value should be set. The process is as follows: First, security analysis experts list all critical security functions of the device. Based on the function's business logic and historical vulnerability data, they assess the dependency level (levels from 1 to 5) of each function on control flow integrity and timing stability. Then, they calculate the weighted average of all function dependency levels and finally normalize the values ​​to obtain the weight coefficients. For example, if a device has three critical functions with control flow dependency levels of 4, 5, and 3, and timing dependency levels of 2, 1, and 4, and the three functions are of equal importance, then the average control flow dependency is (4+5+3) / 3 = 4, and the average timing dependency is (2+1+4) / 3 = 2.33. , In this example, we set... .

[0033] To calculate the weighting coefficients for the timing drift portion, this parameter is related to... Complementary, satisfying Its acquisition method and Simultaneously, in the above example, based on the risk assessment of equipment functionality, the weighting coefficient of the control flow structure drift component is... It is set to 0.6, therefore, the weighting coefficient for the timing drift portion is... The calculation process is as follows: ,Right now This value indicates that in the comprehensive safety assessment model of this device, the weight of execution timing anomalies is 40%. This weight allocation reflects that although the integrity of control flow is the primary concern, abnormal fluctuations in execution time are also considered an important indicator of safety risk, although their importance is lower than that of structural deviations. In this example, the following is set... .

[0034] The number of illegal jumps represents the number of program jumps that violate the standard control flow graph definition detected during a single function execution. This number is obtained from the graph comparison parameter set generated in the previous step, which contains a list of illegal jump paths. The value is the length of this list. For example, after analyzing a certain execution of the "secure_boot_verify" function, the graph comparison parameter set shows that a jump from basic block ID 0x80041a8 to 0x80042f0 was detected. Since this edge does not exist in the standard control flow graph, the illegal jump count is 1. In this example, we set... .

[0035] For the first The length of the bypass path for each illegal jump. This parameter quantifies the complexity of the normal execution path that an attacker needs to bypass to achieve an illegal jump. For each detected illegal jump (from node S to node D), the shortest legal path length (in terms of the number of edges) from the starting point S to the ending point D is calculated using Dijkstra's algorithm or Breadth-First Search (BFS) in the standard control flow graph. This length is the shortest legal path length. For example, for an illegal jump from ID 0x80041a8 to 0x80042f0, by performing a BFS search on the standard control flow graph, the shortest legal path is found to be 0x80041a8 -> 0x80041b4 -> 0x80041c0 -> 0x80042f0. This path contains 3 edges, therefore, the detour path length for this illegal jump is 3. In this example, we set... .

[0036] For the first The centrality value of the starting node of an illegal jump is used to measure the importance of the starting point of an illegal jump in the overall function control flow structure. It is usually calculated using betweenness centrality. The higher the betweenness centrality of a node, the wider the range of program functions that may be affected by its modification along the shortest path between more node pairs. This value is pre-calculated and stored for all nodes in the standard control flow graph when establishing a trusted execution environment baseline. The calculation formula is as follows: ,in It is the total number of shortest paths from node s to node t. This refers to the number of nodes v traversed in these paths. The calculation result is normalized to a range between 0 and 1. For example, for node ID0x80041a8, after calculating the standard control flow graph of the entire function, its normalized betweenness centrality value is 0.45. In this example, we set... .

[0037] The total number of basic blocks in the standard control flow graph is a static parameter representing the code complexity of the monitored critical security functions. It is directly calculated by parsing the firmware and constructing the standard control flow graph when establishing the trusted execution environment baseline. Specifically, it involves traversing all nodes in the standard control flow graph data structure and counting them. Once determined, this value remains unchanged throughout the device's lifecycle unless the firmware is updated. For example, for the function "secure_boot_verify," its standard control flow graph, after analysis, contains 50 independent basic blocks. The value is 50. In this example, it is set as follows: .

[0038] The parameter represents the number of unexecuted necessary paths. It indicates how many paths, predefined as "necessary execution," were bypassed by an attacker during a single function execution. These necessary paths typically contain critical security checks or resource cleanup operations. Their identification and labeling are completed during the baseline establishment phase. At runtime, by comparing the set of valid base blocks actually executed with the set of base blocks contained in each necessary path, if at least one base block in a necessary path does not appear in the actual execution set, that path is counted as unexecuted. The value of this parameter equals the total number of unexecuted necessary paths counted in the graph comparison parameter set. For example, if the analysis finds that a necessary path labeled "SignatureValidation" was not executed, then... The value is 1. In this example, it is set to 1. .

[0039] For the first The number of edges on the j-th non-executed necessary path quantifies the length of the bypassed necessary path and is used to assess the severity of the attack. A longer bypassed path may mean that a more complex security check logic has been skipped. This value is obtained directly from the graph comparison parameter set. After identifying a non-executed necessary path, its definition in the standard control flow graph is queried, and the number of consecutive edges constituting the path is counted. For example, a necessary path named "SignatureValidation" consists of 4 edges connecting 5 basic blocks in the standard control flow graph, so its number of edges is 4. In this example, we set... .

[0040] For the first The irreplaceability score for a non-essential path is used to assess whether the security functions performed by the bypassed path are redundant or have alternatives. A higher score indicates that the path is more critical. The calculation method is as follows: ,in It is the number of alternative paths that can achieve the same security goal (e.g., verifying the same digital signature). This represents the total number of all paths (including the current path) to achieve this security goal. This information is obtained through in-depth static program flow and data flow analysis of the firmware. For example, for the "SignatureValidation" path, the analysis revealed that it is the only path for verifying the firmware signature, and no other code logic can accomplish this function. , Its irreplaceability score is If an alternative verification path exists, then , The score is 0.5. In this example, we set... This indicates that there are some alternative checks with very limited functionality, but the current path is the primary one.

[0041] This is the total number of edges in a standard control flow graph. It is a static parameter that reflects the complexity or branch density of the function's control flow, and is related to the total number of basic blocks. Similarly, it is obtained by parsing the standard control flow graph and counting all edges when establishing the baseline. This value also remains unchanged before the firmware update. For example, for the "secure_boot_verify" function containing 50 basic blocks, its standard control flow graph has 75 edges representing control transfers. The value is 75. In this example, it is set as follows: .

[0042] This parameter represents the number of valid basic blocks in the real-time execution trajectory sequence. It indicates the total number of basic blocks actually executed and conforming to the standard control flow graph path during this function call. This number is calculated through the comparison process in the previous step. When comparing the real-time execution trajectory with the standard control flow graph, all endpoint basic blocks confirmed as valid transitions are counted (starting points are not counted repeatedly). The final total is this number. This value reflects the actual code scope covered in this execution. For example, if an execution records a total of 48 basic blocks, and 3 transitions are judged to be illegal, then the number of legal basic blocks involved is 45. In this example, we set... .

[0043] For the first The timing sensitivity factor for each basic block is used to adjust the weight of the execution time deviation of different basic blocks in the final timing drift value calculation. Its setting is based on the type of operation performed by the basic block and its security sensitivity. Through static analysis of the firmware, each basic block is labeled. For example, the execution time of a basic block executing cryptographic primitives (such as the AES round function) should be constant; any fluctuation could be a sign of a side-channel attack. Set the value to a higher value, such as 1.5; the basic block for executing data dependency branch judgments, its The value is set to 1.0; while basic blocks that perform ordinary operations or data transfers have a higher tolerance for time fluctuations. The values ​​are set to low values, such as 0.8. These factor values ​​are preset in the trusted execution environment baseline, consistent with the standard control flow. Figure 1 In the same storage case, for the purpose of calculating the sum, it is assumed that 5 out of the 45 valid basic blocks are high-sensitivity blocks. ), 10 are medium-sensitive blocks ( ), 30 are low-sensitivity blocks ( ).

[0044] For the first The actual runtime of each basic block is calculated directly from the real-time execution trajectory sequence. For each basic block record in the sequence, its actual runtime is equal to its exit time minus its entry time. These timestamps are provided by the high-precision clock of the trusted execution environment in nanoseconds. For example, for basic block ID 0x80041b4, its entry time is 1577836800.123456789 seconds and its exit time is 1577836800.123457012 seconds, so its actual runtime is 223 nanoseconds. In the calculation of this example, the actual runtime data of all 45 valid basic blocks will be used.

[0045] For the first The baseline runtime of each basic block is a reference value stored in the Trusted Execution Environment (TEE) baseline. It represents the standard execution time of the basic block under normal, attack-free conditions. It is obtained by having the critical security function executed repeatedly at least 1000 times in an isolated test environment during device production or firmware flashing, and recording the execution time of each basic block. Then, statistical analysis is performed on the 1000 records for each basic block, outliers are removed, and the average value is calculated as the baseline runtime of the basic block. For example, for basic block ID 0x80041b4, its baseline runtime may be determined to be 200 nanoseconds. In the calculation of this example, the baseline runtime data of all 45 legitimate basic blocks will be used.

[0046] To prevent extremely small positive numbers with a denominator of zero, we set... .

[0047] Calculations based on parameters: First, calculate the control flow structure drift value. : ; ; ; Next, the execution timing drift value is calculated. For example, the weighted sum of the squared runtime deviations of 45 valid basic blocks (i.e. The calculated result is 2.25, which represents the overall time series fluctuation. ; ; ; Finally, the total deterministic drift value is calculated. : ; ; ; The result indicates that the deterministic drift value of this function execution is 0.0596, compared to a preset drift threshold. This threshold is determined by running a large number of known benign loads and simulated attack scenarios on the device and collecting their corresponding values. The value is then used to determine a point that strikes the best balance between false alarm rate and false negative rate. For example, if the drift threshold is set to 0.05, and the calculated deterministic drift value of 0.0596 is greater than 0.05, it indicates that the current operating status of the device is at high risk of anomaly and is very likely to have been subjected to a runtime attack.

[0048] The steps to obtain the signature verification result are as follows: Based on the deterministic drift value and the component-associated risk vector, read the random number and the current timestamp of the local security clock, and serialize the deterministic drift value, the current timestamp, the random number, and the component-associated risk vector into a fixed-length byte sequence in a fixed field order to generate combined data; Based on the combined data, the private key material is located by calling the key identifier within the trusted execution environment. The private key activation status flag, key usage flag, and key storage area label are verified. The message digest of the combined data is calculated according to the agreed digest process, and the private key is signed to generate a signature proof result.

[0049] Specifically, based on the deterministic drift value calculated in the previous step and the generated component-associated risk vector, a request is first sent to the management platform to obtain a one-time, cryptographically secure random number. This random number is 32 bytes long and is generated by the management platform's hardware random number generator to prevent replay attacks. Simultaneously, the local secure clock module is invoked to read the current tamper-proof UTC timestamp. Next, the serialization process is initiated, creating a fixed-length buffer of 512 bytes and filling it with data according to a predefined field order and length. Specifically, bytes 0-7 store the deterministic drift value in IEEE 100000 format. 754 double-precision floating-point number; bytes 8-15 store the current timestamp in 64-bit unsigned integer format, representing the number of milliseconds since the Unix epoch; bytes 16-47 store a 32-byte random number obtained from the management platform; bytes 48-511 store the component-associated risk vector. This vector is first encoded into a JSON string, then converted into a byte sequence using UTF-8 encoding. If the length of the encoded byte sequence is less than 464 bytes (512-48), it is padded with zero bytes at the end. If the length exceeds 464 bytes, it is truncated and a truncation flag is set. This fixed-layout byte array is the serialized fixed-length byte sequence, generating combined data.

[0050] Based on the combined data generated in the previous step, a signing operation is performed inside the Trusted Execution Environment (TEE). First, a function called `tee_get_private_key` provided by the TEE kernel is called, passing in a predefined key identifier, such as "DEVICE_ATTESTATION_KEY". This identifier uniquely points to the device private key stored in the TEE's secure storage area. Before loading the private key material, the TEE kernel automatically executes a series of verification procedures: First, it checks the metadata associated with the key to confirm that its enable status flag is "ENABLED". If it is "DISABLED", the operation fails and returns an error. Second, it verifies the key's purpose flag to confirm that it contains the "SIGN" permission. If the key is only authorized... If the key is used for other operations such as "ENCRYPT", it will also return an error. Third, the key storage area label is verified to ensure that the key is stored in a hardware isolation area with the highest security level, such as eFuse or a specific OTP memory area. After all verifications are passed, the private key material will be securely loaded into the encryption operation core of the TEE. Then, following the digest process agreed in the firmware, the SHA-256 hash algorithm is used to calculate the message digest of the 512 bytes of the entire combined data, resulting in a 32-byte hash value. Finally, the signature function based on the Elliptic Curve Digital Signature Algorithm (ECDSA), such as ecdsa_sign_digest, is called to perform a signature operation on this 32-byte hash value using the loaded device private key, generating a digital signature composed of two components (r, s). This signature result is then encoded using DER (Distinguished Encoding Rules) to form a binary byte sequence, which is the final signature proof result.

[0051] The steps for obtaining the mitigation command on the device side are as follows: Based on the signature verification result, the signature verification result and component-associated risk vector are encapsulated in the session channel between the device and the management platform, and the device identifier, session sequence number and integrity verification value are filled in. After being sent to the management platform, the platform verifies the source, validity period and non-reused status of the signature verification result, and then compares the deterministic drift value threshold and risk level threshold according to the preset strategy and selects whether to trigger the mitigation process, and returns the mitigation instruction to the device.

[0052] Specifically, based on the signature verification result, a data packet is first constructed and sent to the management platform. This data packet is encapsulated using a custom binary protocol format, with the following structure: the first 16 bytes are the device's unique identifier (e.g., MAC address or UUID), followed by a 4-byte session sequence number to ensure message ordering. This sequence number increments after each communication. Next is a variable-length signature verification result field, the length of which is specified by a 2-byte field. Following this is a variable-length component association risk vector field, and finally a 4-byte CRC32 integrity check value. This check value is calculated from the entire data packet (excluding the check value itself). After encapsulation, the packet is transmitted via the established TLS... 1.3 The secure session channel sends data packets to the management platform. Upon receiving the data, the platform first verifies the CRC32 value, then parses out each field, and then verifies the signature proof result, including: extracting the device identifier, querying the database to confirm that it is a registered and legitimate device (source verification), decrypting the signature using the public key bound to the device, recalculating and comparing the digest of the received combined data portion, parsing the timestamp contained in the signature, comparing it with the platform's current time to confirm that it is within a preset valid time window (e.g., 30 seconds), and querying the platform's random number usage records to confirm that the random number has not been used for any previous requests (random number unreused status verification). After successful verification, the platform makes a decision based on a preset security policy, which includes a series of rules, such as: Rule 1, setting a deterministic drift threshold. The value is 0.05. If the received deterministic drift value is greater than 0.05, a medium-risk response is triggered. Rule 2 sets the risk level threshold to 8.0 (corresponding to the "HIGH" level). If the highest risk level value contained in the component's associated risk vector is greater than or equal to 8.0, a high-risk response is triggered. Rule 3 triggers the highest-level emergency response if both the deterministic drift value and the risk level exceed their respective thresholds. Based on the triggered response level, the platform selects the corresponding device-side mitigation instruction from the policy library. For example, for medium risk, the instruction is "report detailed logs"; for high risk, the instruction is "isolate affected components"; and for emergency response, the instruction is "reboot device to safe mode". Finally, the platform encodes the selected instruction and returns it to the device. The device receives and executes the instruction, returning a device-side mitigation instruction.

[0053] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for cybersecurity early warning based on the supply chain, characterized in that, Includes the following steps: When an IoT security terminal device starts up, it extracts the unique identifier of each software component in its own software bill of materials, obtains the public key of the vulnerability information release center, encrypts the unique identifier of the software component, generates an encrypted component subscription list, and then loads the standard control flow graph of the firmware's key security functions along with the encrypted component subscription list into the trusted execution environment to establish a trusted execution environment baseline. Based on the Trusted Execution Environment baseline, the IoT security terminal device receives a structured risk notification message from the vulnerability information release center, calls the public key stored in the Trusted Execution Environment baseline to decrypt and verify the digital signature, obtains the verified risk notification, and matches the component identifier in the verified risk notification with the device's own software bill of materials one by one to generate a component-associated risk vector. Based on the risk vector associated with the component and the trusted execution environment baseline, the basic block ID sequence traversed by the affected critical safety function during runtime is recorded within the trusted execution environment to form a real-time execution trajectory sequence. The standard control flow graph within the trusted execution environment baseline is called, and the real-time execution trajectory sequence is compared with the standard control flow graph by graph distance to calculate the deterministic drift value. Based on the deterministic drift value and the component-associated risk vector, the deterministic drift value, the current timestamp, and the random number provided by the management platform are combined. The trusted execution environment calls the private key to perform a signature operation on the combined data to generate a signature proof result. The signature proof result and the component-associated risk vector are sent to the management platform. After verifying the signature proof result, it is determined whether to trigger mitigation measures according to a preset strategy, and a device-side mitigation instruction is obtained.

2. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the trusted execution environment baseline are as follows: When the IoT security terminal device starts up, the software bill of materials is read, the component records are parsed line by line, the component name field, version field and supplier field are extracted, and they are concatenated in a fixed order to form a unique identifier for a single software component, thus obtaining a unique identifier sequence for the software component. Based on the unique identifier sequence of the software components, request the public key of the vulnerability information release center, verify the encoding format, fingerprint digest and validity period label, encrypt the unique identifier of the software components one by one and generate corresponding ciphertext entries, compile them into an entry list according to the original sequence number and write the source label and time label to generate an encrypted component subscription list. Based on the encrypted component subscription list, the standard control flow graph of the firmware's key security functions is located from the firmware image. The node numbers, edge sets, and entry / exit identifiers are checked. The protected loading entry point of the trusted execution environment is called. The standard control flow graph and the encrypted component subscription list are written into the same security area. The loading batch label, loading time label, and verification digest are recorded to establish a trusted execution environment baseline.

3. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the verified risk notification are as follows: Based on the trusted execution environment baseline, receive structured risk notification messages, verify the source identifier, timestamp, and content encoding of the message header, parse the field boundaries of the message body and locate the digital signature field and message body field, extract the encoded byte sequence of the digital signature, extract the structured key-value pairs of the message body, and generate the structured risk notification message parsing result. Based on the structured risk notification message parsing result, the public key fingerprint and public key content stored in the trusted execution environment baseline are read. The public key fingerprint is verified to be consistent with the source identifier in the structured risk notification message parsing result. The digital signature in the structured risk notification message parsing result is decrypted and compared using the public key, and the verification status label is recorded. Records with the verification status label of failure are filtered out to obtain the verified risk notification.

4. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the component-associated risk vector are as follows: Based on the verified risk notices, the component identifier list of the device's own software bill of materials is read, and the component identifiers in the verified risk notices are compared with the component identifier list of the software bill of materials one by one. The successfully matched component identifiers are extracted, and the vulnerability details and risk levels are read from the verified risk notices. The components are then concatenated in a fixed order of component identifier, vulnerability details, and risk level to form an entry sequence, thereby generating a component-associated risk vector.

5. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the real-time execution trajectory sequence are as follows: Based on the trusted execution environment baseline, the identifiers of the critical security functions affected in the component-associated risk vector are read, the basic block IDs, entry times, and exit times of the critical security functions during execution are captured, and each capture result is arranged in chronological order to form a real-time execution trajectory sequence.

6. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the deterministic drift value are as follows: Based on the real-time execution trajectory sequence, the standard control flow graph within the baseline of the trusted execution environment is invoked, and each basic block ID is compared with the control flow graph node to confirm the legal path and the illegal jump path. Paths that are not executed are extracted and the number of edges of each path is counted. At the same time, the difference between the runtime of each basic block and the runtime of the baseline is calculated to obtain the graph comparison parameter set. The deterministic drift value is calculated based on the parameter set compared with the graph.

7. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the signature proof result are as follows: Based on the deterministic drift value and the component-associated risk vector, read the random number and the current timestamp of the local security clock, and serialize the deterministic drift value, the current timestamp, the random number, and the component-associated risk vector into a fixed-length byte sequence in a fixed field order to generate combined data; Based on the combined data, the private key material is located by calling the key identifier within the trusted execution environment, the private key activation status flag, key usage flag and key storage area label are verified, the message digest of the combined data is calculated according to the agreed digest process and the private key is signed to generate a signature proof result.

8. The method for supply chain-based cybersecurity early warning according to claim 1, characterized in that, The steps for obtaining the device-side mitigation command are as follows: Based on the signature verification result, the signature verification result and component-associated risk vector are encapsulated in the session channel between the device and the management platform, and the device identifier, session sequence number and integrity verification value are filled in. After being sent to the management platform, the platform verifies the source, validity period and non-reused status of the signature verification result, and then compares the deterministic drift value threshold and risk level threshold according to the preset strategy and selects whether to trigger the mitigation process, and returns the mitigation instruction to the device.

9. A network security early warning system based on the supply chain-based network security early warning method according to any one of claims 1-8, characterized in that, include: The initialization module is used to extract the unique identifier of each software component in its own software bill of materials and obtain the public key of the vulnerability information release center when the IoT security terminal device starts up. It encrypts the unique identifier of the software component, generates an encrypted component subscription list, and then loads the standard control flow graph of the firmware key security function together with the encrypted component subscription list into the trusted execution environment to establish a trusted execution environment baseline. The risk matching module is used to, based on the trusted execution environment baseline, receive structured risk announcement messages from the vulnerability information release center, call the public key stored in the trusted execution environment baseline to decrypt and verify the digital signature, obtain the verified risk announcement, match the component identifiers in the verified risk announcement with the device's own software bill of materials one by one, and generate a component-associated risk vector. The operation monitoring module is used to record the basic block ID sequence that the affected critical safety function passes through during its execution within the trusted execution environment based on the risk vector associated with the trusted execution environment baseline and the component, forming a real-time execution trajectory sequence. It then calls the standard control flow graph within the trusted execution environment baseline, compares the real-time execution trajectory sequence with the standard control flow graph using graph distance, and calculates the deterministic drift value. The early warning response module is used to combine the deterministic drift value, the current timestamp, and a random number provided by the management platform according to the deterministic drift value and the component-associated risk vector. The trusted execution environment calls the private key to perform a signature operation on the combined data to generate a signature proof result. The signature proof result and the component-associated risk vector are sent to the management platform. After verifying the signature proof result, the module determines whether to trigger mitigation measures according to a preset strategy and obtains the device-side mitigation instruction.

Images