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

Abstract

The invention relates to an anti-counterfeiting method, system and device based on chip and cloud collaborative verification and a medium, and relates to the technical field of product anti-counterfeiting, and the method comprises the steps: receiving an encrypted first random number and a chip ID, and judging whether the chip verification operation of a terminal is in an effective window of verification time or not; if the terminal is in the effective window, the trigger chip generates and sends a double-random-number hash session voucher to the terminal and obtains the session voucher; receiving a verification request including the chip ID from the terminal, and querying a registration feature corresponding to the chip ID in the verification request through a PUF feature library of the threat database; if the registration feature is not queried, triggering a chip self-destruction instruction to terminate the verification operation; and if the registration feature is queried, verifying the chip, and if verification fails, triggering a chip self-destruction instruction to terminate the verification operation. According to the invention, a chip and cloud dynamic collaborative verification and security response mechanism can be constructed, and full-link active protection of physical and protocol layers is realized.

Description

Technical Field

[0001] The present 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 Art

[0002] In today's digital age, product 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 shoddy products are becoming increasingly prevalent, causing significant economic losses to businesses and severely damaging consumer interests. Effective anti-counterfeiting technology can help companies establish a positive brand image, strengthen 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, making them less dynamic and susceptible to brute force or side-channel attacks. The cloud serves only as a passive repository and does not participate in dynamic verification, making it difficult to identify and share attack signatures in a timely manner. At the product level, physical protection designs are limited to static encapsulation technology, unable to trigger active defenses based on real-time attack signals. This leads to a disconnect between physical and data layer protection, making it difficult to defend against advanced physical attacks.

[0004] Therefore, there is an urgent need to build an anti-counterfeiting system with deep collaboration between chips and the cloud to reduce the protocol vulnerability of static keys and fixed verification paths, solve the problem of delayed attack response caused by the separation of local and cloud verification, and reduce the protection loopholes formed by the separation of physical protection and data security mechanisms to achieve full-link dynamic protection. Summary of the Invention

[0005] The first 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 of the physical and protocol layers.

[0006] In the first aspect, the present application provides an anti-counterfeiting method based on chip and cloud collaborative verification, which adopts the following technical solutions: An anti-counterfeiting method based on chip and cloud collaborative verification, comprising: receiving a first random number and a chip ID encrypted by ECC, and determining whether the terminal's operation of verifying the chip is within a valid window of verification time, wherein the chip ID is a root key generated based on a PUF feature value; If the verification time is within the valid window, trigger the chip to generate and send a double random number hash session credential generated based on the second random number, the first random number and the chip ID to the terminal, and obtain the session credential at the same time; receiving a verification request including a chip ID from a terminal; Querying the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database; If the registered feature is not found, a chip counterfeiting code is generated and sent to the terminal, triggering the chip self-destruction command to terminate the verification operation; If the registered features are found, the chip will be verified. If the verification fails, the chip self-destruct command will be triggered to terminate the verification operation.

[0007] By adopting the above technical solution, a root key is generated based on the PUF characteristic value and random numbers and chip IDs are transmitted using ECC encryption, which ensures the security of the initial data. At the same time, it verifies whether the chip is in the valid window and avoids invalid or abnormal time verification requests as much as possible. The generated double random number hash session credentials increase the complexity and security of the verification process, and the registration features are queried using the PUF feature library of the threat database to accurately identify the authenticity of the chip. An end-cloud collaborative verification mechanism is constructed through dynamic keys and double random number hashes, and the time window constraint is combined with the PUF feature binding to achieve protocol layer anti-replay attack and anti-brute force cracking. If the registration feature is not queried, it means that the chip is counterfeit. If the registration feature is queried but the chip verification fails, the chip self-destruct instruction is triggered to prevent the chip from being maliciously used, effectively improving the security and reliability of the anti-counterfeiting system.

[0008] In a preferred example, the present application may be further configured as follows: if the registration feature is found, the chip is verified, and if the verification fails, a chip self-destruct instruction is triggered to terminate the verification operation, including the following steps: If the registered features are found and the chip is verified but fails, the system enters the exception handling state and calculates the threat score using the threat scoring model based on the received terminal and chip status data. 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 instruction is sent to terminate the verification operation.

[0009] By adopting the above technical solution, when the registration feature is queried but the chip verification fails, the system enters the exception handling state, realizing a dynamic perception and response mechanism for attack behavior; the threat scoring model is used to combine the terminal and chip status data to calculate the threat score to quantify the abnormal risk degree, thereby improving the accuracy of risk judgment and anti-interference ability; the threat score is mapped to the preset threat level and the associated verification failure code is generated, so that different processing measures can be taken more accurately according to the risk level, and the corresponding chip self-destruction instruction can be sent in a targeted manner to terminate the verification operation, thereby minimizing the over-protection or under-protection caused by a single response mechanism, thereby improving the security and reliability of the anti-counterfeiting system.

[0010] In a preferred example, the present application may be further configured as follows: 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 instruction to terminate the verification operation, the steps further include: A mapping relationship between verification failure codes and threat levels is preset. The threat levels are ranked from high to low risk as level one threat, level two threat, and level three threat. The verification failure codes include: The first authentication failure code is used to terminate the current session and is associated with the first threat level; The second verification failure code is used to trigger the chip power cut and is associated with the second threat level; A third verification failure code, used to permanently disable communications capabilities and associated with a third threat level; Receive encrypted audit logs uploaded by the chip; Update the threat database based on attack signatures in the logs.

[0011] By adopting the above technical solution and presetting the mapping relationship between verification failure codes and threat levels, the chip can terminate sessions, cut off power, and disable communication functions according to different threat levels, thereby implementing a gradient defense strategy. It can handle abnormal situations more accurately and achieve deep coordination between logical blocking and hardware protection. It receives encrypted audit logs uploaded by the chip to build an attack feature traceability chain, enhance the auditability and evidence integrity of abnormal behaviors, and update the threat database based on the attack features in the encrypted audit logs, thereby improving the ability to identify and prevent potential attacks and further enhancing the security of the anti-counterfeiting system.

[0012] In a preferred example, the present application may 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 instruction to terminate the verification operation include: In response to the chip receiving the first verification failure code, sending a session termination instruction and triggering the chip to start quantum detection and / or key backtracking verification; In response to the chip receiving the second verification failure code, receiving the attack signature uploaded by the chip, and sending a power cut-off instruction to the chip; In response to the chip receiving the third verification failure code, a communication fuse instruction is sent to the chip to trigger a data erasure operation.

[0013] By adopting the above technical solution, according to 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, and build a deep security verification barrier at the protocol layer; when receiving the second verification failure code, it executes the received attack characteristics and cuts off the chip power supply, and simultaneously realizes the tracing of attack behavior and hardware-level physical blocking to prevent further attacks; when receiving the third verification failure code, it can fuse the communication and trigger data erasure, forming irreversible protection at the physical layer, avoiding data leakage as much as possible, and improving the security and reliability of the anti-counterfeiting system.

[0014] In a preferred example, the present application may be further configured as follows: if no registration feature is found, then entering an exception handling state, and before the step of calculating and obtaining a threat score using a threat score model based on the received terminal and chip status data, further comprising: Define the scoring threshold range for threat level; Set threat factor weights, and prioritize them from high to low as physical attacks, brute force cracking, and continuous verification failures; Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of physical impedance change; Calculate the threat score using the formula: S=∑(w i ×f i ), Where S is the threat score, w i Assign weights and ∑w i =1,f i is the threat factor value and 0≤f i ≤1, i=3.

[0015] By adopting the above technical solution, the scoring threshold range of the threat level is defined, the scoring interval corresponding to each threat level can be clearly defined, and a risk assessment framework adaptive to attack scenarios can be implemented; the threat factor weights of physical attacks, brute force cracking, and continuous verification failures are set according to priority to highlight the importance of different threat types; obtaining normalized threat factor values including request frequency, number of verification failures, and degree of physical impedance change can more accurately quantify the threat situation, unify the measurement standards for different attack characteristics, and minimize misjudgments or missed detections caused by single-indicator evaluations; a weighted fusion algorithm is used to obtain threat scores, enhance the model's recognition accuracy for complex attack combinations, and enhance the anti-counterfeiting system's ability to respond to various abnormal situations.

[0016] In a preferred example, the present application may be further configured as follows: in response to the chip receiving the third verification failure code, the step of sending a communication fuse instruction to the chip to trigger the data erasure operation includes: The trigger chip performs multiple rounds of Feistel network coverage on sensitive data, using a different pseudo-random mask in each round; During the chip data erasure process, redundant clock interference is inserted and the encrypted erasure log is received as an audit basis.

[0017] By adopting the above technical solution, the chip is triggered to perform multiple rounds of Feistel network coverage on sensitive data, and each round uses a different pseudo-random mask to achieve irreversible erasure of sensitive data and enhance the security of data erasure. During the chip data erasure process, redundant clock interference is inserted 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 tracing and review, and improves the data security and operational compliance of the anti-counterfeiting system.

[0018] In a preferred example, the present application may be further configured as follows: the step of querying the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database includes: If the registration feature is found and the chip is successfully authenticated, a temporary session key is generated and sent to the terminal via a dynamic path generated by hashing the chip ID, timestamp, and geolocation. In response to the chip receiving the temporary session key, within the validity period of the key, after receiving the path confirmation instruction sent by the terminal, the chip returns the encrypted product information to the terminal.

[0019] By adopting the above technical solution, when the registration features are queried, the NFC chip ID, timestamp and geographic location hash are used to generate a dynamic path 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, thereby improving the security and accuracy of product information transmission and realizing the organic unity of physical anti-counterfeiting and digital anti-counterfeiting.

[0020] In a second aspect, the present application provides an anti-counterfeiting system based on chip and cloud collaborative verification, which adopts the following technical solutions: An anti-counterfeiting system based on chip and cloud collaborative verification, including: Encryption receiving module: used to receive the first random number and chip ID encrypted by ECC, and determine whether the terminal's operation of verifying the chip is within the valid window of verification time, where the chip ID is a root key generated based on the PUF feature value; Random trigger module: used for triggering the chip to generate and send a double random number hash session credential generated based on the second random number, the first random number and the chip ID to the terminal if the verification time is within the valid window, and simultaneously obtain the session credential; Credential relay module: used to receive the verification request including the chip ID from the terminal; 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; The first self-destruct module is used to generate a verification failure code and send it to the terminal if the registration feature is not queried, triggering the chip self-destruct instruction to terminate the current verification operation; The second self-destruct module is used to verify the chip if the registration feature is queried. If the verification fails, the chip self-destruct instruction is triggered to terminate the verification operation.

[0021] In a fourth aspect, the present application provides a computer storage medium, including the following technical solutions: A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the above-mentioned anti-counterfeiting method based on chip and cloud collaborative verification.

[0022] In summary, this application has the following beneficial technical effects: This application increases the difficulty of cracking by verifying whether the NFC chip is in the valid window of verification time, generating a root key based on the PUF feature value, and combining it with the dynamic key to generate session credentials; adopts a verification service with dynamic path jump, and the path is generated by the NFC chip ID, timestamp and geographic location hash, reducing replay attacks and man-in-the-middle attacks, and improving the reliability of the verification results; in terms of physical anti-counterfeiting, when the registration feature is not queried, the NFC chip self-destruction instruction is triggered, and the threat scoring model is used to evaluate and handle abnormal situations, which can effectively deal with abnormal events such as brute force cracking and copying, and realize full-link active protection of the physical and protocol layers. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a flowchart of an anti-counterfeiting method based on chip and cloud collaborative verification in one of the embodiments of the present application.

[0024] Figure 2 This is a flowchart of the sub-steps of step S6 in one embodiment of the present application.

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

[0026] Figure 4 This is a flowchart of the sub-steps of step S61 in one embodiment of the present application.

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

[0028] Figure 6This is a flowchart of the sub-steps of step S615 in one embodiment of the present application.

[0029] Figure 7 This is a flowchart of the sub-steps of step S4 in one embodiment of the present application.

[0030] Figure 8 This is a structural diagram of an anti-counterfeiting system based on chip and cloud collaborative verification in one embodiment of the present application.

[0031] Figure 9 It is a principle block diagram of an electronic device in one embodiment of the present application.

[0032] Figure numerals: 1. Encrypted receiving module; 2. Random trigger module; 3. Credential relay module; 4. Feature verification module; 5. First self-destruction module; 6. Second self-destruction module. DETAILED DESCRIPTION

[0033] The following is combined with Figure 1-9 This application is described in further detail.

[0034] It should be noted that all actions of obtaining data or information or data in this application are carried out in compliance with the relevant data protection laws and policies of the country where they are located and with the authorization of the corresponding users.

[0035] refer to Figure 1 , an anti-counterfeiting method based on chip and cloud collaborative verification, specifically including: S1. Receive a first random number and a chip ID encrypted by ECC, and determine whether the operation of the terminal verification chip is within a valid window of verification time, wherein the chip ID is a root key generated based on a PUF characteristic value.

[0036] Specifically, the terminal obtains the chip ID by scanning the chip, encrypts the first random number and the chip ID using ECC, and generates a dynamic key, thereby improving the randomness of the dynamic key. In this embodiment, the chip selected is an NFC chip. The NFC chip integrates an ARM security processor capable of communicating with the terminal and the cloud. During production, it is designed using a physically unclonable function (PUF) circuit, not limited to the NFC ISO 14443 Type A / B standard. Furthermore, at the encryption protocol layer, a chip-unique key is generated by combining PUF characteristic values, and ECC is used to encrypt the transmission of random numbers and chip IDs, thereby improving the security of the initial data.

[0037] Next, the terminal sends the ECC-encrypted first random number and chip ID to the cloud. When the cloud generates a time window check, it only allows one verification of a chip with the same PUF signature value within this time window, and the verification operation is only allowed within this time window, minimizing invalid or abnormal verification requests. If more than one verification operation occurs within this time window for a chip with the same PUF signature value, the verification operation is deemed to have been attacked multiple times, posing a verification risk, and therefore needs to be terminated. In this embodiment, the time window for the first verification is set to ±2 seconds.

[0038] 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 generated based on the second random number, the first random number and the chip ID to the terminal, and obtain the session credential at the same time.

[0039] Specifically, if only one verification request passes within the valid verification window, the chip generates a second random number and combines it 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 this double-random-hash session credential to the cloud, it also sends the chip's geographic location to the cloud. The cloud then determines whether the chip's geographic location is legitimate, further strengthening the security of the verification chip.

[0040] Therefore, using the PUF feature library of the threat database to query the registered features can accurately identify the authenticity of the chip. By building an end-cloud collaborative verification mechanism through dynamic keys and double random number hashes, combined with time window constraints and PUF feature binding, it can achieve protocol layer protection against replay attacks and brute force cracking.

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

[0042] 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 and request further verification.

[0043] S4. Query the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database.

[0044] Specifically, the verification request includes the chip ID generated by the PUF feature value. 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 registered feature for the chip ID.

[0045] Moreover, in this embodiment, when the terminal sends the verification request to the cloud, it also includes sending the terminal's geographic location to the cloud. By comparing the geographic location information of the terminal and the cloud, it is determined whether the geographic locations of the two are basically the same to confirm the security of this verification.

[0046] S5. If the registered feature is not found, a chip counterfeiting code is generated and sent to the terminal, triggering a chip self-destruction command to terminate the verification operation.

[0047] Specifically, if the registered feature is not found, it means that the chip is counterfeit, triggering the chip self-destruction instruction to reduce the possibility of malicious use of the chip, thereby improving the security and reliability of the anti-counterfeiting process.

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

[0049] Specifically, if the registration feature is found, it proves that the chip is legitimate. However, since brute force verification may occur during the verification process, if the cloud verification fails, the chip self-destruct command needs to be triggered to terminate the verification operation.

[0050] refer to Figure 2 Furthermore, in one embodiment, step S6 is further divided into the following sub-steps: S60: If the registration feature is found, the chip is verified and the verification fails, the system enters an exception handling state and obtains a threat score through a threat score model based on the received terminal and chip status data.

[0051] Specifically, when the cloud enters an exception 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 evaluate the terminal's chip verification challenge, quantifying the degree of anomaly risk. The resulting threat score determines the appropriate chip self-destruction strategy, and the most appropriate chip self-destruction strategy is implemented based on the risk level of each verification.

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

[0053] Specifically, mapping the threat score to a preset threat level and generating an associated verification failure code can more accurately take different processing measures based on the risk level of the verification, and send the corresponding chip self-destruct instruction to terminate the verification operation in a targeted manner, reducing the occurrence of over-protection or under-protection caused by a single response mechanism.

[0054] In addition, reference Figure 3Furthermore, in one embodiment, before step S61, steps S610, S611, and S612 are added: S610. Preset a mapping relationship between verification failure codes and threat levels. Threat levels are ranked from high to low risk as level 1 threat, level 2 threat, and level 3 threat. Verification failure codes include: The first authentication failure code is used to terminate the current session and is associated with the first threat level.

[0055] The second verification failure code is used to trigger chip power cutoff and is associated with the second threat level.

[0056] A third authentication failure code is used to permanently disable communications functionality and is associated with a third threat level.

[0057] Specifically, in this embodiment, the risk action corresponding to a Level 1 threat is if the terminal fails to authenticate continuously or fails to authenticate a chip with the same PUF signature within the time window. This terminates the authentication session, and the number of consecutive authentication failures is set to three. Furthermore, the time window for the first authentication is set to ±2 seconds. After the cloud first terminates the session due to an abnormal handling state, the time window is set to abnormal access state, shrinking to ±0.5 seconds. If a second authentication request is received from the same terminal and the authentication exceeds the time window, it is recorded as an abnormal authentication. This ensures that authentication requests are only accepted within a specific time window, thereby preventing replay attacks and abnormal requests.

[0058] Furthermore, the risk operation corresponding to the second-level threat is brute force cracking at the terminal level, and the risk operation corresponding to the third-level threat is physical destruction at the chip level.

[0059] S611. Receive the encrypted audit log uploaded by the chip.

[0060] Specifically, an encrypted audit log is generated based on its PUF features and the received timestamp, and the attack features of the terminal uploaded by the chip are recorded to build an attack feature traceability chain, enhancing the auditability and evidence integrity of abnormal behavior.

[0061] S612: Update the threat database based on the attack signature in the log.

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

[0063] In addition, reference Figure 4 Furthermore, in one embodiment, step S61 is further divided into the following sub-steps: S613: In response to the chip receiving the first verification failure code, send a session termination instruction and trigger the chip to start quantum detection and / or key backtracking verification.

[0064] 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 attacked by quantum computing before the session is terminated, and record the attack vector for threat tracing.

[0065] When there is suspicion of historical key leakage or key chain integrity being compromised, key backtracking verification is used. Specifically, starting from the current session, chain hash backtracking is used to verify whether the hash value of each key level matches the pre-stored root hash, and at the same time, the key usage record is checked for anomalies. If a key hash mismatch or abnormal usage behavior is detected at a certain level, the key is determined to be potentially leaked, the current verification session is terminated, and the metadata of the abnormal key is submitted to the Trusted Execution Environment (TEE) for cross-verification, making it impossible for attackers to forge historical key traces.

[0066] S614 : In response to the chip receiving the second verification failure code, receiving the attack signature uploaded by the chip, and sending a power-off instruction to the chip.

[0067] Specifically, after the chip's power is cut off, the microprocessor can no longer communicate with the cloud. This protects the chip while also preventing further verification of the chip. Once the chip is activated by an external device that authenticates the chip and powers it back on, the microprocessor can be used again.

[0068] S615 : In response to the chip receiving the third verification failure code, sending a communication fuse instruction to the chip to trigger a data erasure operation.

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

[0070] In addition, reference Figure 5 Furthermore, in one embodiment, before step S60, steps S600, S601, S602, and S603 are added: S600: Define a scoring threshold range for the threat level.

[0071] 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 the first threat is greater than the scoring threshold range for the level two threat, and the scoring threshold range for the second threat is greater than the scoring threshold range for the level three threat. That is, the higher the score, the greater the risk of the threat.

[0072] S601. Set threat factor weights, and rank them in descending order of priority as physical attack, brute force cracking, and continuous verification failure.

[0073] Specifically, physical attacks can directly bypass cryptographic protections, causing system-level crashes or key leaks, and 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, placing them at the next highest risk. Continuous verification failures are often due to misoperations or inefficient attacks, with high false positive rates and limited impact, and can be controlled through temporary freezing, thus providing the lowest priority. Physical attacks are determined by measuring the degree of change in physical impedance using an impedance sensor integrated within the chip. Brute force attacks are determined by the frequency of verification requests from the terminal, while the number of consecutive verification failures is determined by confirming an abnormal state after three consecutive verification failures.

[0074] S602: Obtain a normalized threat factor value, including request frequency, number of verification failures, and degree of physical impedance change.

[0075] Specifically, obtaining a normalized threat factor value that includes request frequency, number of verification failures, and degree of physical impedance change can more accurately quantify the threat situation, unify the measurement standards for different attack characteristics, and minimize misjudgments or missed detections caused by single-indicator evaluation. Among them, the request frequency and number of verification failures are obtained based on the verification request made by the terminal within the verification time. The degree of physical impedance change is to enable the chip's microprocessor to periodically inject a test current into the target circuit and measure the voltage drop within the verification time, use the ADC to convert the analog signal into a digital value, and combine the preset impedance-voltage relationship model to calculate the current impedance value in real time. The preset benchmark threshold is a nominal value of ±5%. If the microprocessor determines that the current physical impedance exceeds the benchmark threshold by comparing the dynamic impedance with the benchmark threshold, it sends a communication fuse instruction to the chip to trigger a data erase operation.

[0076] S603. Calculate and obtain the threat score using the formula: S=∑(w i ×f i ), Where S is the threat score, w i Assign weights and ∑w i =1,f i is the threat factor value and 0≤f i ≤1, i=3.

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

[0078] In addition, reference Figure 6 Furthermore, in one embodiment, step S615 is further divided into the following sub-steps: The S6150,trigger chip performs multiple rounds of Feistel network coverage on sensitive data,,using a different pseudo-random mask in each round.

[0079] Specifically, the Feistel network coverage algorithm is adopted and a different pseudo-random mask is used in each round to achieve irreversible erasure of sensitive data in the chip and enhance the security of data erasure.

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

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

[0082] In addition, receiving encrypted erasure logs as audit basis facilitates subsequent tracing and review in the cloud, improving the data security of anti-counterfeiting operations.

[0083] In addition, reference Figure 7 Furthermore, in one embodiment, step S4 is further divided into the following sub-steps: 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, where the path is generated by the chip ID, timestamp, and geographic location hash.

[0084] Specifically, the verification path = Hash(chip ID || timestamp || geolocation), and TEE trusted execution environment verification is implemented. This means that a temporary session key is generated for each interaction, and the path validity period is set to <100ms. When a registered feature is queried, a dynamic path is generated using the NFC chip ID, timestamp, and geolocation hash to send the temporary session key. This effectively prevents replay attacks and man-in-the-middle attacks, and improves the security of data returned to the terminal.

[0085] S41 . In response to the chip receiving the temporary session key, within the validity period of the key, after receiving the path confirmation instruction sent by the terminal, the chip returns the encrypted product information to the terminal.

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

[0087] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean 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.

[0088] The embodiment of the present application also provides an anti-counterfeiting system based on chip and cloud collaborative verification. The anti-counterfeiting system based on chip and cloud collaborative verification corresponds one-to-one to the anti-counterfeiting method based on chip and cloud collaborative verification in the embodiment.

[0089] refer to Figure 8 An anti-counterfeiting system based on chip and cloud collaborative verification includes: an encrypted receiving module 1, a random trigger module 2, a credential relay module 3, a feature verification module 4, a first self-destruction module 5, and a second self-destruction module 6. The functional modules are described in detail as follows: Encrypted receiving module 1: used to receive the first random number and chip ID encrypted by ECC, and determine whether the operation of the terminal verification chip is within the valid window of verification time, where the chip ID is the root key generated based on the PUF feature value; Random trigger module 2: used to trigger the chip to generate and send a double random number hash session credential generated based on the second random number, the first random number and the chip ID to the terminal if the verification time is within the valid window, and simultaneously obtain the session credential; Credential relay module 3: used to receive a verification request including a chip ID from a terminal; Feature verification module 4: used to query the registered feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database; First self-destruct module 5: used to generate a verification failure code and send it to the terminal if the registration feature is not found, triggering the chip self-destruct instruction to terminate the verification operation; The second self-destruct module 6 is used to verify the chip if the registration feature is found. If the verification fails, the chip self-destruct instruction is triggered to terminate the verification operation.

[0090] Among them, the encryption receiving module 1 verifies whether the chip is in the valid window to ensure the timeliness of verification, and generates a root key based on the PUF feature value to enhance the security of the chip ID; the random trigger module 2 generates a double random number hash session credential to increase the complexity and security of verification; the credential relay module 3 transmits the session credential and receives the verification request to ensure a smooth verification process; the feature verification module 4 queries the registration feature through the PUF feature library in the threat database to identify illegal chips; the first self-destruct module 5 triggers the chip self-destruction command if the registration feature is not queried, preventing the leakage of illegal chip information. When the second self-destruct module 6 queries the registration feature, if the verification fails during the cloud identification process, it also triggers the chip self-destruction command. Through the combination of these modules, it is possible to establish a dynamic collaborative verification and security response mechanism between the chip and the cloud, realizing full-link active protection at the physical and protocol layers.

[0091] For the specific definition of the anti-counterfeiting system based on chip and cloud collaborative verification, please refer to the definition of the anti-counterfeiting method based on chip and cloud collaborative verification in the context, which will not be repeated here. Each module in the above-mentioned anti-counterfeiting system based on chip and cloud collaborative verification can be implemented in whole or in part by software, hardware and their combination. The above-mentioned modules can be embedded in or independent of the processor in the electronic device in hardware form, or can be stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to the above modules. In one embodiment, an electronic device is provided, which is a user terminal. Reference Figure 9 , the electronic device includes a processor, a memory, a network interface and a database connected through a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the electronic device is used to store a detection data table. The network interface of the electronic device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, an anti-counterfeiting method based on chip and cloud collaborative verification is implemented.

[0092] 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. When the processor executes the computer program, the following steps are performed: S1. Receive a first random number and a chip ID encrypted by ECC, and determine whether the operation of the terminal verification chip is within a valid window of verification time, wherein the chip ID is a root key generated based on a PUF characteristic value.

[0093] 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 generated based on the second random number, the first random number and the chip ID to the terminal, and obtain the session credential at the same time.

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

[0095] S4. Query the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database.

[0096] S5. If the registered feature is not found, a chip counterfeiting code is generated and sent to the terminal, triggering a chip self-destruction command to terminate the verification operation.

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

[0098] In one embodiment, the sub-steps of step S6 include: S60: If the registration feature is found, the chip is verified and the verification fails, the system enters an exception handling state and obtains a threat score through a threat score model based on the received terminal and chip status data.

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

[0100] In one embodiment, the steps added before step S61 include: S610. Preset a mapping relationship between verification failure codes and threat levels. Threat levels are ranked from high to low risk as level 1 threat, level 2 threat, and level 3 threat. Verification failure codes include: The first authentication failure code is used to terminate the current session and is associated with the first threat level.

[0101] The second verification failure code is used to trigger chip power cutoff and is associated with the second threat level.

[0102] A third authentication failure code is used to permanently disable communications functionality and is associated with a third threat level.

[0103] S611. Receive the encrypted audit log uploaded by the chip.

[0104] S612: Update the threat database based on the attack signature in the log.

[0105] In one embodiment, the detailed sub-steps of step S61 include: S613: In response to the chip receiving the first verification failure code, send a session termination instruction and trigger the chip to start quantum detection and / or key backtracking verification.

[0106] S614 : In response to the chip receiving the second verification failure code, receiving the attack signature uploaded by the chip, and sending a power-off instruction to the chip.

[0107] S615 : In response to the chip receiving the third verification failure code, sending a communication fuse instruction to the chip to trigger a data erasure operation.

[0108] In one embodiment, the steps added before step S60 include: S600: Define a scoring threshold range for the threat level.

[0109] S601. Set threat factor weights, and rank them in descending order of priority as physical attack, brute force cracking, and continuous verification failure.

[0110] S602: Obtain a normalized threat factor value, including request frequency, number of verification failures, and degree of physical impedance change.

[0111] S603. Calculate and obtain the threat score using the formula: S=∑(w i ×f i ), Where S is the threat score, w i Assign weights and ∑w i =1,f i is the threat factor value and 0≤f i ≤1, i=3.

[0112] In one embodiment, the sub-steps of step S615 include: The S6150,trigger chip performs multiple rounds of Feistel network coverage on sensitive data,,using a different pseudo-random mask in each round.

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

[0114] In one embodiment, the sub-steps of step S4 include: 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, where the path is generated by the chip ID, timestamp, and geographic location hash.

[0115] S41 . In response to the chip receiving the temporary session key, within the validity period of the key, after receiving the path confirmation instruction sent by the terminal, the chip returns the encrypted product information to the terminal.

[0116] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. 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 above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may 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), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0117] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by 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. An anti-counterfeiting method based on chip and cloud collaborative verification, characterized in that: include: receiving a first random number and a chip ID encrypted by ECC, and determining whether the terminal's operation of verifying the chip is within a valid window of verification time, wherein the chip ID is a root key generated based on a PUF feature value; If the verification time is within the valid window, trigger the chip to generate and send a double random number hash session credential generated based on the second random number, the first random number and the chip ID to the terminal, and obtain the session credential at the same time; receiving a verification request including a chip ID from a terminal; Querying the registration feature corresponding to the chip ID in the verification request through the PUF feature library of the threat database; If the registered feature is not found, a chip counterfeiting code is generated and sent to the terminal, triggering the chip self-destruction command to terminate the verification operation; If the registered features are found, the chip will be verified. If the verification fails, the chip self-destruct command will be triggered to terminate the verification operation.

2. The method according to claim 1, characterized in that If the registration feature is found, the chip is verified, and if the verification fails, a chip self-destruct instruction is triggered to terminate the verification operation, including: If the registered features are found and the chip is verified but fails, the system enters the exception handling state and calculates the threat score using the threat scoring model based on the received terminal and chip status data. 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 instruction 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 instruction to terminate the verification operation, the method further includes: A mapping relationship between verification failure codes and threat levels is preset. The threat levels are ranked from high to low risk as level one threat, level two threat, and level three threat. The verification failure codes include: The first authentication failure code is used to terminate the current session and is associated with the first threat level; The second verification failure code is used to trigger the chip power cut and is associated with the second threat level; A third verification failure code, used to permanently disable communications capabilities and associated with a third threat level; Receive encrypted audit logs uploaded by the chip; Update the threat database based on attack signatures in the logs.

4. The method according to claim 3, characterized in that The step 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 instruction to terminate the verification operation includes: In response to the chip receiving the first verification failure code, sending a session termination instruction and triggering the chip to start quantum detection and / or key backtracking verification; In response to the chip receiving the second verification failure code, receiving the attack signature uploaded by the chip, and sending a power cut-off instruction to the chip; In response to the chip receiving the third verification failure code, a communication fuse instruction is sent to the chip to trigger a data erasure operation.

5. The method according to claim 4, characterized in that If no registration feature is found, the process enters an exception handling state. Before the step of calculating and obtaining a threat score using a threat score model based on the received terminal and chip status data, the process further includes: Define the scoring threshold range for threat level; Set threat factor weights, and prioritize them from high to low as physical attacks, brute force cracking, and continuous verification failures; Obtain normalized threat factor values, including request frequency, number of verification failures, and degree of physical impedance change; Calculate the threat score using the formula: S=∑(w i ×f i ), Where S is the threat score, w i Assign weights and ∑w i =1,f i is the threat factor value and 0≤f i ≤1, i=3.

6. The method according to claim 2, characterized in that The step of sending a communication fuse instruction to the chip to trigger a data erasure operation in response to the chip receiving the third verification failure code includes: The trigger chip performs multiple rounds of Feistel network coverage on sensitive data, using a different pseudo-random mask in each round; 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 feature library of the threat database includes: If the registration feature is found and the chip is successfully authenticated, a temporary session key is generated and sent to the terminal via a dynamic path generated by hashing the chip ID, timestamp, and geolocation. In response to the chip receiving the temporary session key, within the validity period of the key, after receiving the path confirmation instruction sent by the terminal, the chip returns the encrypted product information to the terminal.

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

9. An electronic device, characterized in that: The device comprises a memory and a processor, wherein the memory stores a computer program that can be loaded by the processor and executes an anti-counterfeiting method based on chip and cloud collaborative verification as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that A computer program is stored which can be loaded by a processor and executes an anti-counterfeiting method based on chip and cloud collaborative verification as claimed in any one of claims 1 to 7.

Images