Anti-counterfeiting method, system and device based on chip and cloud collaborative verification and medium

Abstract

The application relates to a chip and cloud collaborative verification-based anti-counterfeiting method, system, device and medium, and relates to the technical field of product anti-counterfeiting. The method comprises the following steps: receiving an encrypted first random number and a chip ID, and judging whether the operation of terminal verification chip is in a valid window of a verification time; if the operation is in the valid window, triggering the chip to generate and send a generated double-random number hash session ticket to the terminal and acquire the session ticket; receiving a verification request including the chip ID from the terminal, querying a registered feature corresponding to the chip ID in a PUF feature library of a threat database; if the registered feature is not queried, triggering a chip self-destruction instruction to terminate the verification operation; and if the registered feature is queried, verifying the chip, and if the verification fails, triggering the chip self-destruction instruction to terminate the verification operation. The application can construct a chip and cloud dynamic collaborative verification and security response mechanism, and realize full-link active protection of physical and protocol layers.

Description

Technical Field

[0001] This application relates to the field of product anti-counterfeiting technology, and in particular to anti-counterfeiting methods, systems, devices and media based on chip and cloud collaborative verification. Background Technology

[0002] In today's digital age, anti-counterfeiting technology is crucial for protecting consumer rights and maintaining market order. With rapid economic development and the advancement of trade globalization, counterfeit and substandard products are increasingly rampant, causing significant economic losses to businesses and severely harming consumer interests. Effective anti-counterfeiting technology can help businesses establish a positive brand image, enhance consumer trust in their products, and promote the healthy and orderly development of the market.

[0003] Existing anti-counterfeiting systems generally rely on pre-set static keys and local verification mechanisms. Key generation is based on fixed parameters, resulting in insufficient dynamism and vulnerability to brute-force or side-channel attacks. The cloud, acting merely as a passive repository, does not participate in dynamic verification, making it difficult to identify and share attack signatures globally in a timely manner. At the product level, physical protection designs are limited to static encapsulation technology, unable to trigger proactive defenses based on real-time attack signals. This leads to a disconnect between physical and data layer protection, making it difficult to resist advanced physical attacks.

[0004] Therefore, it is urgent to build an anti-counterfeiting system that deeply integrates chips and the cloud to reduce the vulnerability of static keys and fixed verification paths, and to solve the problem of delayed attack response caused by the separation of local and cloud verification, and reduce the protection vulnerabilities formed by the separation of physical protection and data security mechanisms, so as to achieve dynamic protection across the entire chain. Summary of the Invention

[0005] The purpose of this application is to provide an anti-counterfeiting method based on chip and cloud collaborative verification, which can build a dynamic collaborative verification and security response mechanism between the chip and the cloud, and realize full-link active protection at the physical and protocol layers.

[0006] Firstly, this application provides an anti-counterfeiting method based on chip and cloud-based collaborative verification, employing the following technical solution:

[0007] An anti-counterfeiting method based on chip and cloud-based collaborative verification includes:

[0008] Receive the first random number encrypted by ECC and the chip ID, and determine whether the terminal's operation to verify the chip is within the valid window of the verification time, wherein the chip ID is the root key generated based on the PUF feature value;

[0009] If it is within the valid window of the verification time, the chip is triggered to generate and send a double random number hash session credential based on the combination of the second random number, the first random number and the chip ID to the terminal, and the session credential is obtained at the same time.

[0010] Receive a verification request from the terminal, including the chip ID;

[0011] The registration features corresponding to the chip ID in the verification request are queried using the PUF signature library of the threat database;

[0012] If no registration features are found, a chip forgery code is generated and sent to the terminal, triggering a chip self-destruct command to terminate the verification operation.

[0013] If the registered characteristics are found, the chip is verified. If the verification fails, a chip self-destruct instruction is triggered to terminate the verification operation.

[0014] By adopting the above technical solution, a root key is generated based on PUF feature values, and random numbers and chip IDs are transmitted using ECC encryption, ensuring the security of the initial data. Simultaneously, it verifies whether the chip is within a valid window, minimizing invalid or abnormal verification requests. The generated double-random-number hash session credential increases the complexity and security of the verification process. Utilizing the PUF feature library in the threat database to query registered features accurately identifies chip authenticity. A cloud-edge collaborative verification mechanism is constructed through dynamic keys and double-random-number hashes, combined with time window constraints and PUF feature binding, achieving protocol-level anti-replay attacks and resistance to brute-force attacks. If no registered feature is found, it indicates the chip is counterfeit; if a registered feature is found but chip verification fails, a chip self-destruct instruction is triggered, preventing malicious use of the chip and effectively improving the security and reliability of the anti-counterfeiting system.

[0015] In a preferred embodiment, this application can be further configured as follows: the step of verifying the chip if a registered feature is found, and triggering a chip self-destruct instruction to terminate the verification operation if the verification fails, includes:

[0016] If a registration feature is found, the chip is verified but the verification fails. Then, an exception handling state is entered. Based on the received terminal and chip status data, a threat score is calculated using a threat scoring model.

[0017] The threat score is mapped to a preset threat level, a verification failure code associated with the threat level is generated, and a corresponding chip self-destruct command is sent to terminate the verification operation.

[0018] By adopting the above technical solution, when registration characteristics are found but chip verification fails, an abnormal handling state is entered, realizing a dynamic perception and response mechanism for attack behavior. The threat scoring model is used in conjunction with terminal and chip status data to calculate the threat score and quantify the degree of abnormal risk, improving the accuracy of risk judgment and anti-interference capability. The threat score is mapped to a preset threat level and an associated verification failure code is generated, which can more accurately take different handling measures according to the risk level and send the corresponding chip self-destruct command to terminate the verification operation, so as to avoid over-protection or under-protection caused by a single response mechanism, thereby improving the security and reliability of the anti-counterfeiting system.

[0019] In a preferred embodiment, this application may be further configured such that, before the steps of mapping the threat score to a preset threat level, generating a verification failure code associated with the threat level, and sending a corresponding chip self-destruct command to terminate the verification operation, the application further includes:

[0020] A pre-defined mapping relationship between verification failure codes and threat levels is established, where threat levels are ranked from highest to lowest as Level 1 threat, Level 2 threat, and Level 3 threat. The verification failure codes include:

[0021] The first verification failure code is used to terminate the current session and associate it with the Level 1 threat level.

[0022] The second verification failure code is used to trigger the chip power cut-off and is associated with the level 2 threat.

[0023] The third verification failure code is used to permanently disable communication functions and is associated with a level 3 threat level.

[0024] Receive encrypted audit logs uploaded by the chip;

[0025] Update the threat database based on the attack characteristics in the logs.

[0026] By adopting the above technical solution and pre-setting the mapping relationship between verification failure codes and threat levels, operations such as terminating sessions, cutting off power, and disabling communication functions on the chip can be performed according to different threat levels. This achieves a tiered defense strategy, enabling more precise handling of abnormal situations and achieving deep synergy between logical blocking and hardware protection. Furthermore, by receiving encrypted audit logs uploaded by the chip, an attack signature tracing chain can be constructed, enhancing the auditability and evidence integrity of abnormal behavior. The threat database is also updated based on the attack signatures in the encrypted audit logs, improving the ability to identify and prevent potential attacks and further enhancing the security of the anti-counterfeiting system.

[0027] In a preferred embodiment, this application can be further configured as follows: the steps of mapping the threat score to a preset threat level, generating a verification failure code associated with the threat level, and sending a corresponding chip self-destruct command to terminate the verification operation include:

[0028] In response to the chip receiving the first verification failure code, a session termination instruction is sent and the chip is triggered to initiate quantum detection and / or key backtracking verification.

[0029] In response to the chip receiving the second verification failure code, the attack characteristics uploaded by the chip are received, and a power cut-off command is sent to the chip.

[0030] In response to the chip receiving the third verification failure code, a communication circuit breaker command is sent to the chip, triggering a data erase operation.

[0031] By adopting the above technical solution, based on the preset mapping relationship between verification failure codes and threat levels, when the terminal receives the first verification failure code, it can terminate the session and trigger the chip to start quantum detection and / or key backtracking verification to ensure security, thus constructing a deep security verification barrier at the protocol layer; upon receiving the second verification failure code, it executes the reception of attack characteristics and cuts off the chip power supply, simultaneously realizing attack behavior tracing and hardware-level physical blocking to prevent further attacks; upon receiving the third verification failure code, it can melt down communication and trigger data erasure, forming irreversible physical layer protection, minimizing data leakage, and improving the security and reliability of the anti-counterfeiting system.

[0032] In a preferred embodiment, this application can be further configured as follows: before the step of entering an anomaly handling state if no registration feature is found, and calculating and obtaining a threat score based on the received terminal and chip status data through a threat scoring model, the application further includes:

[0033] Define the scoring threshold range for threat levels;

[0034] Set threat factor weights and sort them in order of priority from high to low as physical attack, brute force, and continuous verification failure;

[0035] Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of change in physical impedance;

[0036] The threat score is calculated using the formula:

[0037] S=∑(w i ×f i ),

[0038] Where S is the threat score, w i Assign values ​​to the weights and ∑w i =1, f i The threat factor value is 0 ≤ f i ≤1, i=3.

[0039] By adopting the above technical solutions, defining the scoring threshold range for threat levels clarifies the scoring intervals corresponding to each threat level, enabling an adaptive risk assessment framework for attack scenarios. Prioritizing the weights of threat factors such as physical attacks, brute-force attacks, and continuous verification failures highlights the importance of different threat types. Obtaining normalized threat factor values ​​that include request frequency, number of verification failures, and the degree of change in physical impedance more accurately quantifies the threat situation, unifies the measurement standards for different attack characteristics, and minimizes misjudgments or missed detections caused by single-index assessments. Employing a weighted fusion algorithm to obtain threat scores enhances the model's accuracy in identifying complex attack combinations and strengthens the anti-counterfeiting system's ability to cope with various anomalies.

[0040] In a preferred embodiment, this application can be further configured as follows: the step of sending a communication circuit breaker command to the chip in response to the chip receiving a third verification failure code, triggering a data erasure operation, includes:

[0041] The trigger chip performs multiple rounds of Feistel network coverage on sensitive data, with each round using a different pseudo-random mask;

[0042] During the chip data erasure process, redundant clock interference is inserted, and the encrypted erasure log is received as an audit basis.

[0043] By adopting the above technical solution, the chip is triggered to perform multiple rounds of Feistel network coverage on sensitive data, with each round using a different pseudo-random mask, to achieve irreversible erasure of sensitive data and enhance the security of data erasure. Redundant clock interference is inserted during the chip data erasure process to confuse the erasure timing characteristics, which can further reduce the possibility of data theft or recovery. At the same time, the encrypted erasure log is received as an audit basis, which facilitates subsequent traceability and review, and improves the data security and operational compliance of the anti-counterfeiting system.

[0044] In a preferred embodiment, this application can be further configured as follows: the step of querying the registration feature corresponding to the chip ID in the verification request through the PUF signature library of the threat database includes:

[0045] If the registration characteristics are found and the chip verification is successful, a temporary session key is generated and sent to the terminal via a dynamic path, which is generated by the chip ID, timestamp, and geographic location hash.

[0046] In response to the chip receiving the temporary session key, within the key's validity period, after receiving the path confirmation instruction sent by the terminal, it returns encrypted product information to the terminal.

[0047] By adopting the above technical solution, when registration characteristics are found, a dynamic path is generated using the NFC chip ID, timestamp, and geographic location hash to send a temporary session key, which can effectively defend against replay attacks and man-in-the-middle attacks. After the terminal receives the temporary session key and confirms the path within the validity period, it returns encrypted product information, improving the security and accuracy of product information transmission and realizing the organic unity of physical anti-counterfeiting and digital anti-counterfeiting.

[0048] Secondly, this application provides an anti-counterfeiting system based on chip and cloud-based collaborative verification, employing the following technical solution:

[0049] An anti-counterfeiting system based on chip and cloud-based collaborative verification includes:

[0050] Encryption receiving module: used to receive the first random number encrypted by ECC and the chip ID, and to determine whether the terminal's operation to verify the chip is within the valid window of the verification time, wherein the chip ID is the root key generated based on the PUF feature value;

[0051] Random trigger module: If it is within the valid window of the verification time, trigger the chip to generate and send a double random number hash session credential generated by combining the second random number, the first random number, and the chip ID to the terminal, and at the same time obtain the session credential;

[0052] Credential relay module: Used to receive verification requests from the terminal, including the chip ID;

[0053] Feature verification module: used to query the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database;

[0054] The first self-destruct module is used to generate a verification failure code and send it to the terminal if no registered feature is found, triggering the chip self-destruct instruction to terminate the verification operation.

[0055] The second self-destruct module is used to verify the chip if a registered feature is found. If the verification fails, a chip self-destruct instruction is triggered to terminate the verification operation.

[0056] Fourthly, this application provides a computer storage medium, as follows:

[0057] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned anti-counterfeiting method based on chip-cloud collaborative verification.

[0058] In summary, this application has the following beneficial technical effects:

[0059] This application increases the difficulty of cracking by verifying whether the NFC chip is within the valid verification window and generating a root key based on PUF feature values, combined with dynamic key generation of session credentials. It employs a dynamic path-jump verification service, where the path is generated from the NFC chip ID, timestamp, and geographic location hash, reducing replay attacks and man-in-the-middle attacks and improving the reliability of verification results. Regarding physical anti-counterfeiting, it triggers a self-destruct command on the NFC chip when no registration feature is found, and uses a threat scoring model to assess and handle abnormal situations, effectively responding to brute-force attacks, duplication, and other abnormal events, achieving full-link proactive protection at both the physical and protocol layers. Attached Figure Description

[0060] Figure 1 This is a flowchart of an anti-counterfeiting method based on chip and cloud collaborative verification in one embodiment of this application.

[0061] Figure 2 This is a flowchart of a sub-step of step S6 in one embodiment of this application.

[0062] Figure 3 This is a flowchart of the steps added before step S61 in one embodiment of this application.

[0063] Figure 4 This is a flowchart of a sub-step of step S61 in one embodiment of this application.

[0064] Figure 5 This is a flowchart of the steps added before step S60 in one embodiment of this application.

[0065] Figure 6 This is a flowchart of a sub-step of step S615 in one embodiment of this application.

[0066] Figure 7 This is a flowchart of a sub-step of step S4 in one embodiment of this application.

[0067] Figure 8 This is a schematic diagram of the structure of an anti-counterfeiting system based on chip and cloud collaborative verification, according to one embodiment of this application.

[0068] Figure 9 This is a schematic block diagram of an electronic device in one embodiment of this application.

[0069] Reference numerals in the attached diagram: 1. Encrypted receiving module; 2. Random triggering module; 3. Credential relay module; 4. Feature verification module; 5. First self-destruct module; 6. Second self-destruct module. Detailed Implementation

[0070] The following is in conjunction with the appendix Figure 1-9 This application will be described in further detail.

[0071] It should be noted that all actions involving the acquisition of data or information in this application are carried out in accordance with the relevant data protection laws and policies of the country where the application is located, and with the authorization of the relevant users.

[0072] refer to Figure 1 An anti-counterfeiting method based on chip and cloud-based collaborative verification, specifically including:

[0073] S1. Receive the first random number encrypted by ECC and the chip ID, and determine whether the terminal's chip verification operation is within the valid window of the verification time, where the chip ID is the root key generated based on the PUF feature value.

[0074] Specifically, the terminal obtains the chip ID by scanning the chip, and uses ECC to encrypt the first random number and the chip ID to generate a dynamic key, thereby improving the randomness of the dynamic key. In this embodiment, an NFC chip is selected. The NFC chip integrates an ARM secure processor capable of communicating with the terminal and the cloud. During manufacturing, a Physically Unclonable Function (PUF) circuit is used in the design, and it is not limited to using the NFC ISO 14443 Type A / B standard. Furthermore, at the encryption protocol layer, a unique chip key is generated by combining PUF feature values, and ECC is used to encrypt the transmitted random number and chip ID, improving the security of the initial data.

[0075] Next, the terminal sends the first random number, encrypted with ECC, and the chip ID to the cloud. When the cloud generates a time window verification, only one verification of the same PUF feature value is allowed within this time window, and the verification operation is only permitted within this time window to minimize invalid or abnormal verification requests. If more than one verification operation for the same PUF feature value occurs within this time window, it is determined that the verification has been subjected to multiple attacks and there is a verification risk; therefore, the verification operation needs to be terminated. In this embodiment, the time window for the first verification is set to ±2 seconds.

[0076] S2. If it is within the valid window of the verification time, trigger the chip to generate and send a double random number hash session credential based on the combination of the second random number, the first random number and the chip ID to the terminal, and at the same time obtain the session credential.

[0077] Specifically, if only one verification request passes within the valid verification window, the chip generates a second random number, which is then combined with the hash value of the first random number and the chip ID to generate a double-random hash session credential. The chip then sends this double-random hash session credential to the cloud and the terminal. Furthermore, while the chip is sending the double-random hash session credential to the cloud, its geographical location is also sent to the cloud. The cloud then verifies the validity of the chip's geographical location to further enhance the security of the verification chip.

[0078] Therefore, by querying the registration features of the PUF feature library in the threat database, the authenticity of the chip can be accurately identified. By constructing an end-to-cloud collaborative verification mechanism through dynamic keys and double random number hashes, and combining time window constraints with PUF feature binding, it is possible to achieve protocol-level anti-replay attack and anti-brute-force cracking.

[0079] S3. Receive a verification request from the terminal, including the chip ID.

[0080] Specifically, when the cloud and the terminal receive the session credentials, a secure session channel is established between the cloud and the terminal, allowing both parties to communicate to request further verification.

[0081] S4. Query the PUF signature library in the threat database to verify the registration features corresponding to the chip ID in the request.

[0082] Specifically, the verification request includes a chip ID generated from PUF feature values. When the cloud receives the verification request, it queries the PUF feature library in the associated threat database to determine whether there is a matching registration feature for the chip ID.

[0083] Furthermore, in this embodiment, while the terminal sends the verification request to the cloud, it also sends the terminal's geographical location to the cloud. By comparing the geographical location information of the terminal and the cloud, it is determined whether the geographical locations of the two are basically the same, so as to confirm the security of this verification.

[0084] S5. If no registration feature is found, generate chip forgery code and send it to the terminal to trigger the chip self-destruct command to terminate this verification operation.

[0085] Specifically, if no registration characteristics are found, it indicates that the chip is counterfeit, triggering a chip self-destruct instruction to reduce the possibility of the chip being maliciously used, thereby improving the security and reliability of the anti-counterfeiting process.

[0086] S6. If the registered features are found, the chip is verified. If the verification fails, the chip self-destruct instruction is triggered to terminate the verification operation.

[0087] Specifically, if the registered characteristics are found, it proves that the chip is legitimate. However, since there may be brute-force verification during the verification process, if the verification fails in the cloud, it is also necessary to trigger the chip self-destruct command to terminate the verification operation.

[0088] refer to Figure 2 Furthermore, in one embodiment, step S6 is refined into the following sub-steps:

[0089] S60. If a registration feature is found, the chip is verified but the verification fails. Then, an exception handling state is entered. Based on the received terminal and chip status data, a threat score is calculated using a threat scoring model.

[0090] Specifically, when the cloud enters an anomaly handling state, it indicates that although the current chip is legitimate, a risky operation occurred during the terminal verification process. A threat scoring model is used to assess the terminal's challenge to the chip verification, quantifying the degree of anomaly risk and obtaining a threat score to determine the appropriate chip self-destruction scheme. The most suitable chip self-destruction scheme is then adopted for each verification based on its risk level.

[0091] S61. Map the threat score to a preset threat level, generate a verification failure code associated with the threat level, and send the corresponding chip self-destruct command to terminate the verification operation.

[0092] Specifically, by mapping threat scores to preset threat levels and generating associated verification failure codes, different handling measures can be taken more accurately according to the risk level of verification. Corresponding chip self-destruct commands can be sent to terminate the verification operation, reducing the situation of over-protection or under-protection caused by a single response mechanism.

[0093] In addition, refer to Figure 3 Furthermore, in one embodiment, steps S610, S611, and S612 are added before step S61:

[0094] S610. Preset mapping relationship between verification failure codes and threat levels. Threat levels are sorted from high to low risk as Level 1 threat, Level 2 threat, and Level 3 threat. Verification failure codes include:

[0095] The first verification failure code is used to terminate the current session and associate it with the Level 1 threat level.

[0096] The second verification failure code is used to trigger a chip power cut-off and is associated with a level 2 threat.

[0097] The third verification failure code is used to permanently disable communication functions and is associated with a level 3 threat level.

[0098] Specifically, in this embodiment, the risk operation corresponding to a Level 1 threat is that if the terminal fails to verify continuously or fails to complete the verification of a chip with the same PUF feature value within the time window, the current verification session will be terminated. The number of consecutive verification failures is set to 3, and the time window for the initial verification is set to ±2 seconds. After the cloud determines that the session has entered an abnormal handling state and terminates the session for the first time, the time window is set to an abnormal access state, and the time window is shortened to ±0.5 seconds. If a verification request from the same terminal is received again and the verification exceeds the verification time of the time window, it is recorded as an abnormal verification, ensuring that verification requests are only accepted within a specific time window, thereby defending against replay attacks and abnormal requests.

[0099] Furthermore, Level 2 threats involve brute-force attacks at the endpoint level, while Level 3 threats involve physical damage at the chip level.

[0100] S611, Receives encrypted audit logs uploaded by the chip.

[0101] Specifically, encrypted audit logs are generated based on the PUF characteristics and received timestamps, and attack characteristics of the terminal uploaded by the chip are recorded to build an attack characteristic tracing chain, thereby enhancing the auditability and evidence integrity of abnormal behavior.

[0102] S612. Update the threat database based on the attack characteristics in the logs.

[0103] Specifically, the threat database is updated based on attack characteristics in the encrypted audit logs to improve the ability to identify and prevent potential attacks, thereby further enhancing the security of the anti-counterfeiting system.

[0104] In addition, refer to Figure 4 Furthermore, in one embodiment, step S61 is refined into the following sub-steps:

[0105] S613. In response to the chip receiving the first verification failure code, a session termination instruction is sent and the chip is triggered to start quantum detection and / or key backtracking verification.

[0106] Specifically, when the chip receives the first verification failure code, it uses quantum detection when it detects abnormal physical signals such as quantum noise interference or potential quantum computing attack characteristics to detect whether it has been subjected to a quantum computing attack before the session is terminated, and records the attack vector for threat tracing.

[0107] When there is suspicion of historical key leakage or compromised key chain integrity, key backtracking verification is used. Specifically, starting from the current session, chained hashing is used to verify whether the hash value of each level of key matches the pre-stored root hash, while checking for any anomalies in key usage records. If a key hash mismatch or abnormal usage behavior is detected at a certain level, it is determined that the key may have been leaked, the current verification session is terminated, and the metadata of the abnormal key is submitted to a Trusted Execution Environment (TEE) for cross-validation, preventing attackers from forging historical key traces.

[0108] S614. In response to the chip receiving the second verification failure code, receive the attack characteristics uploaded by the chip and send a power cut-off command to the chip.

[0109] Specifically, after the chip's power is cut off, the microprocessor can no longer communicate with the cloud. Therefore, while protecting the chip, it also prevents further verification of the chip after the power is cut off. The chip can be used again after the microprocessor is powered back on by an activation program from a certified external device.

[0110] S615, in response to the chip receiving the third verification failure code, sends a communication fuse command to the chip, triggering a data erase operation.

[0111] Specifically, in this embodiment, if the chip receives a third verification failure code, the chip's communication circuit is melted and data erasure is triggered, forming an irreversible physical layer of protection at the chip level, minimizing data leakage and improving the security and reliability of the anti-counterfeiting system.

[0112] In addition, refer to Figure 5 Furthermore, in one embodiment, steps S600, S601, S602, and S603 are added before step S60:

[0113] S600 defines the range of scoring thresholds for threat levels.

[0114] Specifically, in this embodiment, the scoring threshold range is set to three levels, corresponding to level one threat, level two threat, and level three threat, respectively. The scoring threshold range for level one threat is greater than that for level two threat, and the scoring threshold range for level two threat is greater than that for level three threat. That is, the higher the score, the greater the risk of the threat.

[0115] S601. Set threat factor weights, sorted by priority from high to low as physical attack, brute force attack, and continuous verification failure.

[0116] Specifically, physical attacks can directly bypass cryptographic protection, causing system-level crashes or key leaks. They require hardware-level defense and are irreversible, posing the highest risk. Brute-force attacks, such as exhaustive key extraction, rely on computing power but can be mitigated through algorithm upgrades and rate limits, making them the next riskier. Consecutive verification failures are mostly due to misoperation or inefficient attacks, with a high false alarm rate and limited impact; they can be controlled through temporary freezing, thus having the lowest priority. Physical attacks are determined by an impedance sensor integrated within the chip, assessing changes in physical impedance. Brute-force attacks are judged by the frequency of terminal verification requests, and consecutive verification failures are considered abnormal after three consecutive failures.

[0117] S602. Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of change in physical impedance.

[0118] Specifically, obtaining a normalized threat factor value that includes request frequency, number of verification failures, and the degree of physical impedance change allows for more accurate quantification of the threat situation, unifies the measurement standards for different attack characteristics, and minimizes misjudgments or missed detections caused by single-index evaluation. Request frequency and number of verification failures are obtained based on the verification requests made by the terminal within the verification time. The degree of physical impedance change is determined by the chip's microprocessor periodically injecting test current into the target circuit and measuring the voltage drop within the verification time. An ADC is used to convert the analog signal into a digital value, and the current impedance value is calculated in real time using a preset impedance-voltage relationship model. A preset baseline threshold is set at ±5% of the nominal value. If the microprocessor determines that the current physical impedance exceeds the baseline threshold by comparing the dynamic impedance with the baseline threshold, a communication circuit breaker command is sent to the chip, triggering a data erasure operation.

[0119] S603. Calculate and obtain the threat score using the formula:

[0120] S=∑(w i ×f i ),

[0121] Where S is the threat score, w i Assign values ​​to the weights and ∑w i =1, f i The threat factor value is 0 ≤ f i ≤1, i=3.

[0122] Specifically, using a weighted fusion algorithm to obtain threat scores can improve the model's accuracy in identifying complex attack combinations and enhance the anti-counterfeiting system's ability to cope with various abnormal situations.

[0123] In addition, refer to Figure 6 Furthermore, in one embodiment, step S615 is refined into the following sub-steps:

[0124] The S6150 trigger chip performs multiple rounds of Feistel network coverage on sensitive data, with each round using a different pseudo-random mask.

[0125] Specifically, the Feistel network overlay algorithm is used with different pseudo-random masks in each round to achieve irreversible erasure of sensitive data within the chip, thereby enhancing the security of data erasure.

[0126] S6151. During the chip data erasure process, redundant clock interference is inserted, and the erase log after receiving the data is used as the audit basis.

[0127] Specifically, during the chip data erasure process, a 5V pulse voltage is applied to the physical storage unit to disrupt the storage structure and prevent data recovery. The insertion of redundant clock interference to confuse the erasure timing characteristics can further reduce the possibility of data theft or recovery.

[0128] Furthermore, receiving encrypted erasure logs serves as audit evidence, facilitating subsequent traceability and review in the cloud and enhancing data security for anti-counterfeiting operations.

[0129] In addition, refer to Figure 7 Furthermore, in one embodiment, step S4 is refined into the following sub-steps:

[0130] S40. If the registration feature is found and the chip verification is successful, a temporary session key is generated and sent to the terminal via a dynamic path. The path is generated by the chip ID, timestamp, and geographic location hash.

[0131] Specifically, the verification path is calculated as Hash(Chip ID || Timestamp || Geographic Location), and TEE (Trusted Execution Environment) verification is implemented. This involves generating a temporary session key for each interaction and setting the path validity period to <100ms. When registration characteristics are found, a dynamic path is generated using the NFC chip ID, timestamp, and geographic location hash to send the temporary session key. This effectively defends against replay attacks and man-in-the-middle attacks, improving the security of data returned to the terminal.

[0132] S41. In response to the chip receiving the temporary session key, within the key's validity period, after receiving the path confirmation instruction sent by the terminal, the encrypted product information is returned to the terminal.

[0133] Specifically, after the terminal receives the temporary session key and confirms the path within the validity period, it returns encrypted product information, which is considered a successful verification, thus achieving an organic unity of physical and digital anti-counterfeiting. The path validity period is set to <100ms.

[0134] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0135] This application also provides an anti-counterfeiting system based on chip and cloud collaborative verification, which corresponds one-to-one with the anti-counterfeiting method based on chip and cloud collaborative verification in the embodiments.

[0136] refer to Figure 8 An anti-counterfeiting system based on chip and cloud-based collaborative verification includes: an encrypted receiving module 1, a random triggering module 2, a credential relay module 3, a feature verification module 4, a first self-destruct module 5, and a second self-destruct module 6. Detailed descriptions of each functional module are as follows:

[0137] Encryption receiving module 1: Used to receive the first random number encrypted by ECC and the chip ID, and to determine whether the terminal's operation to verify the chip is within the valid window of the verification time, wherein the chip ID is the root key generated based on the PUF feature value;

[0138] Random Trigger Module 2: If it is within the valid window of the verification time, it triggers the chip to generate and send a double random number hash session credential based on the combination of the second random number, the first random number and the chip ID to the terminal, and at the same time obtains the session credential;

[0139] Certificate relay module 3: Used to receive verification requests from the terminal, including the chip ID;

[0140] Feature verification module 4: Used to query the registered features corresponding to the chip ID in the verification request through the PUF feature library of the threat database;

[0141] First self-destruct module 5: If no registered feature is found, it generates a verification failure code and sends it to the terminal, triggering a chip self-destruct command to terminate the verification operation.

[0142] The second self-destruct module 6 is used to verify the chip if a registered feature is found, and to trigger a chip self-destruct instruction to terminate the verification operation if the verification fails.

[0143] The system comprises several modules: Encryption receiving module 1 verifies whether the chip is within a valid window to ensure timely verification, and generates a root key based on PUF feature values ​​to enhance chip ID security; Random triggering module 2 generates double-random hash session credentials to increase verification complexity and security; Credential relay module 3 transmits session credentials and receives verification requests to ensure smooth verification process flow; Feature verification module 4 queries registered features in the PUF feature library of the threat database to identify illegal chips; First self-destruct module 5 triggers a chip self-destruct command when no registered feature is found to prevent leakage of illegal chip information; and Second self-destruct module 6, when a registered feature is found, also triggers a chip self-destruct command if verification fails during cloud-based identification. Through the combined operation of these modules, a dynamic collaborative verification and security response mechanism between the chip and the cloud can be constructed, achieving proactive protection across the entire physical and protocol layers.

[0144] Specific limitations regarding the anti-counterfeiting system based on chip-and-cloud collaborative verification can be found in the context of the limitations on anti-counterfeiting methods based on chip-and-cloud collaborative verification, and will not be repeated here. Each module in the aforementioned anti-counterfeiting system based on chip-and-cloud collaborative verification can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the electronic device, or stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of each module. In one embodiment, an electronic device is provided, which is a user terminal. (Reference) Figure 9 The electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores detection data tables. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements an anti-counterfeiting method based on chip-to-cloud collaborative verification.

[0145] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0146] S1. Receive the first random number encrypted by ECC and the chip ID, and determine whether the terminal's chip verification operation is within the valid window of the verification time, where the chip ID is the root key generated based on the PUF feature value.

[0147] S2. If it is within the valid window of the verification time, trigger the chip to generate and send a double random number hash session credential based on the combination of the second random number, the first random number and the chip ID to the terminal, and at the same time obtain the session credential.

[0148] S3. Receive a verification request from the terminal, including the chip ID.

[0149] S4. Query the PUF signature library in the threat database to verify the registration features corresponding to the chip ID in the request.

[0150] S5. If no registration feature is found, generate chip forgery code and send it to the terminal to trigger the chip self-destruct command to terminate this verification operation.

[0151] S6. If the registered features are found, the chip is verified. If the verification fails, the chip self-destruct instruction is triggered to terminate the verification operation.

[0152] In one embodiment, the sub-steps of step S6 are further refined as follows:

[0153] S60. If a registration feature is found, the chip is verified but the verification fails. Then, an exception handling state is entered. Based on the received terminal and chip status data, a threat score is calculated using a threat scoring model.

[0154] S61. Map the threat score to a preset threat level, generate a verification failure code associated with the threat level, and send the corresponding chip self-destruct command to terminate the verification operation.

[0155] In one embodiment, the additional step before step S61 includes:

[0156] S610. Preset mapping relationship between verification failure codes and threat levels. Threat levels are sorted from high to low risk as Level 1 threat, Level 2 threat, and Level 3 threat. Verification failure codes include:

[0157] The first verification failure code is used to terminate the current session and associate it with the Level 1 threat level.

[0158] The second verification failure code is used to trigger a chip power cut-off and is associated with a level 2 threat.

[0159] The third verification failure code is used to permanently disable communication functions and is associated with a level 3 threat level.

[0160] S611, Receives encrypted audit logs uploaded by the chip.

[0161] S612. Update the threat database based on the attack characteristics in the logs.

[0162] In one embodiment, the refined sub-steps of step S61 include:

[0163] S613. In response to the chip receiving the first verification failure code, a session termination instruction is sent and the chip is triggered to start quantum detection and / or key backtracking verification.

[0164] S614. In response to the chip receiving the second verification failure code, receive the attack characteristics uploaded by the chip and send a power cut-off command to the chip.

[0165] S615, in response to the chip receiving the third verification failure code, sends a communication fuse command to the chip, triggering a data erase operation.

[0166] In one embodiment, the additional step before step S60 includes:

[0167] S600 defines the range of scoring thresholds for threat levels.

[0168] S601. Set threat factor weights, sorted by priority from high to low as physical attack, brute force attack, and continuous verification failure.

[0169] S602. Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of change in physical impedance.

[0170] S603. Calculate and obtain the threat score using the formula:

[0171] S=∑(w i ×f i ),

[0172] Where S is the threat score, w i Assign values ​​to the weights and ∑w i =1, f i The threat factor value is 0 ≤ f i ≤1, i=3.

[0173] In one embodiment, the sub-steps of step S615 include:

[0174] The S6150 trigger chip performs multiple rounds of Feistel network coverage on sensitive data, with each round using a different pseudo-random mask.

[0175] S6151. During the chip data erasure process, redundant clock interference is inserted, and the erase log after receiving the data is used as the audit basis.

[0176] In one embodiment, the sub-steps of step S4 refinement include:

[0177] S40. If the registration feature is found and the chip verification is successful, a temporary session key is generated and sent to the terminal via a dynamic path. The path is generated by the chip ID, timestamp, and geographic location hash.

[0178] S41. In response to the chip receiving the temporary session key, within the key's validity period, after receiving the path confirmation instruction sent by the terminal, the encrypted product information is returned to the terminal.

[0179] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0180] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

Claims

1. A method for preventing counterfeiting based on chip and cloud-based collaborative verification, characterized in that, include: Receive the first random number encrypted by ECC and the chip ID, and determine whether the terminal's operation to verify the chip is within the valid window of the verification time, wherein the chip ID is the root key generated based on the PUF feature value; If it is within the valid window of the verification time, the chip is triggered to generate and send a double random number hash session credential based on the combination of the second random number, the first random number and the chip ID to the terminal, and the session credential is obtained at the same time. Receive a verification request from the terminal, including the chip ID; The registration features corresponding to the chip ID in the verification request are queried using the PUF signature library of the threat database; If no registration features are found, a chip forgery code is generated and sent to the terminal, triggering a chip self-destruct command to terminate the verification operation. If the registered characteristics are found, the chip is verified. If the verification fails, a chip self-destruct instruction is triggered to terminate the verification operation.

2. The method according to claim 1, characterized in that, The steps of verifying the chip if a registered feature is found, and triggering a chip self-destruct instruction to terminate the verification operation if the verification fails, include: If a registration feature is found, the chip is verified but the verification fails. Then, an exception handling state is entered. Based on the received terminal and chip status data, a threat score is calculated using a threat scoring model. The threat score is mapped to a preset threat level, a verification failure code associated with the threat level is generated, and a corresponding chip self-destruct command is sent to terminate the verification operation.

3. The method according to claim 2, characterized in that, Before the steps of mapping the threat score to a preset threat level, generating a verification failure code associated with the threat level, and sending a corresponding chip self-destruct command to terminate the verification operation, the method further includes: A pre-defined mapping relationship between verification failure codes and threat levels is established, where threat levels are ranked from highest to lowest as Level 1 threat, Level 2 threat, and Level 3 threat. The verification failure codes include: The first verification failure code is used to terminate the current session and associate it with the Level 1 threat level. The second verification failure code is used to trigger the chip power cut-off and is associated with the level 2 threat. The third verification failure code is used to permanently disable communication functions and is associated with a level 3 threat level. Receive encrypted audit logs uploaded by the chip; Update the threat database based on the attack characteristics in the logs.

4. The method according to claim 3, characterized in that, The steps of mapping the threat score to a preset threat level, generating a verification failure code associated with the threat level, and sending a corresponding chip self-destruct command to terminate the verification operation include: In response to the chip receiving the first verification failure code, a session termination instruction is sent and the chip is triggered to initiate quantum detection and / or key backtracking verification. In response to the chip receiving the second verification failure code, the attack characteristics uploaded by the chip are received, and a power cut-off command is sent to the chip. In response to the chip receiving the third verification failure code, a communication circuit breaker command is sent to the chip, triggering a data erase operation.

5. The method according to claim 4, characterized in that, Before the step of entering an anomaly handling state if no registration characteristics are found, and calculating the threat score based on the received terminal and chip status data using a threat scoring model, the following steps are also included: Define the scoring threshold range for threat levels; Set threat factor weights and sort them in order of priority from high to low as physical attack, brute force, and continuous verification failure; Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of change in physical impedance; The threat score is calculated using the formula: S=∑(w i ×f i ), Where S is the threat score, w i Assign values ​​to the weights and ∑w i =1, f i The threat factor value is 0 ≤ f i ≤1, i=3.

6. The method according to claim 4, characterized in that, The step of responding to the chip receiving a third verification failure code, sending a communication circuit breaker command to the chip, and triggering a data erasure operation includes: The trigger chip performs multiple rounds of Feistel network coverage on sensitive data, with each round using a different pseudo-random mask; During the chip data erasure process, redundant clock interference is inserted, and the encrypted erasure log is received as an audit basis.

7. The method according to claim 1, characterized in that, The step of querying the registration feature corresponding to the chip ID in the verification request through the PUF signature library of the threat database includes: If the registration characteristics are found and the chip verification is successful, a temporary session key is generated and sent to the terminal via a dynamic path, which is generated by the chip ID, timestamp, and geographic location hash. In response to the chip receiving the temporary session key, within the key's validity period, after receiving the path confirmation instruction sent by the terminal, it returns encrypted product information to the terminal.

8. An anti-counterfeiting system based on chip and cloud-based collaborative verification, characterized in that, include: Encryption receiving module (1): used to receive the first random number encrypted by ECC and the chip ID, and to determine whether the terminal's operation to verify the chip is within the valid window of the verification time, wherein the chip ID is the root key generated based on the PUF feature value; Random trigger module (2): If it is within the valid window of the verification time, trigger the chip to generate and send a double random number hash session credential generated by combining the second random number, the first random number and the chip ID to the terminal, and at the same time obtain the session credential; Credential relay module (3): used to receive verification requests from the terminal, including the chip ID; Feature verification module (4): used to query the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database; First self-destruct module (5): If no registered feature is found, generate a verification failure code and send it to the terminal to trigger the chip self-destruct instruction to terminate the verification operation; The second self-destruct module (6) is used to verify the chip if the registered features are found, and to trigger the chip self-destruct instruction to terminate the verification operation if the verification fails.

9. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executed as any one of the anti-counterfeiting methods based on chip and cloud collaborative verification as described in claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer program is stored and can be loaded by a processor and executed as any one of the anti-counterfeiting methods based on chip and cloud collaborative verification as described in claims 1 to 7.

Images