A method for preventing copying of internal program of MCU chip

Abstract

The application relates to the field of secure encryption, and discloses a method for preventing copying of an internal program of an MCU chip. Through the encryption scheme, a development company can effectively protect its software and hardware research and development achievements, and prevent a client from easily obtaining a program code through a grinding plate copying method and the like without authorization. The technical scheme adopted by the application aims to reduce the cost of encryption protection, so that the application is suitable for projects of various scales and costs, especially cost-sensitive small household appliances and the like. Through combination of various security technical means such as a PUF circuit and a blockchain platform, the application aims to provide a more comprehensive and efficient security protection scheme, and effectively resist illegal copying and tampering.

Description

Technical Field

[0001] The present invention relates to the field of security encryption, and in particular to a method for preventing internal programs of an MCU chip from being copied. Background Art

[0002] With the continuous advancement of technology, microcontrollers (MCU chips) have become core components in numerous electronic devices, particularly in smart homes, industrial automation, and other fields. However, the program code stored within MCU chips is often at risk of being illegally copied or tampered with, which not only infringes on the developer's rights but also causes significant financial losses to the company. In particular, if a development company easily obtains the research and development results through low-cost methods such as polishing and copying boards after delivering samples to customers, the development company will not receive the final payment due, seriously affecting the company's normal operations and R&D enthusiasm.

[0003] There are some encryption protection solutions on the market, but most of them have the following shortcomings:

[0004] High cost: Many encryption solutions rely on specialized encryption MCU chips, which are expensive and unsuitable for cost-sensitive projects. This is especially true in areas like small appliances, where price constraints significantly increase product costs and reduce market competitiveness.

[0005] Layout limitations: In some compact designs, the use of multiple MCU chips may be limited by space layout. For small appliances or other space-constrained application scenarios, a multi-MCU chip solution may not be feasible.

[0006] Limited anti-copying capabilities: Despite the use of encrypted MCU chips, the cost of copying boards is decreasing, and the technology is becoming more mature. However, the method of simultaneously reading and burning code with two MCU chips can still be used to illegally obtain program code. Furthermore, with the development of technology, the cost of copying boards has become industrialized, making illegal copying easier and cheaper.

[0007] The present invention aims to solve the above-mentioned shortcomings in the prior art and provide a method for preventing the internal program of an MCU chip from being copied. Summary of the Invention

[0008] The present invention provides a method for preventing the internal program of an MCU chip from being copied, which is used to provide better protection means for software development companies.

[0009] The first aspect of the present invention provides a method for preventing the internal program of an MCU chip from being copied, and the method for preventing the internal program of an MCU chip from being copied comprises: in the MCU chip design stage, embedding a PUF circuit into the MCU chip, and each time the MCU chip is powered on, the PUF circuit generates a unique response key based on the inherent randomness of the hardware; presetting a blockchain platform for MCU chip burning verification to ensure the security and non-tamperability of data, deploying a smart contract on the blockchain platform to record the burning information of the MCU chip, the burning information including the MCU chip ID, timestamp, and number of burnings, and defining verification rules and a locking mechanism, presetting an encryption algorithm to encrypt the program inside the MCU chip, and storing the encrypted program in the Flash or ROM of the MCU chip to ensure that the program exists in ciphertext form; applying for burning Recording authorization. Before burning, the user applies for authorization from the server and submits the MCU chip ID and other necessary information. The server verifies the validity of the MCU chip ID and whether the number of burning times exceeds the limit by querying the blockchain platform records, and then generates authorization information. The server transmits the authorization information to the burning device through a secure channel. The burning device starts the burning process after verifying that the authorization information is correct; the encrypted program is decrypted according to the unique response key to obtain the decrypted program. Before the program is executed, it is multiplexed according to the decrypted program to ensure that the program has not been illegally tampered with and obtain verification information; the verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU chip will automatically trigger the locking mechanism, making the MCU chip unable to be used again. The ID and behavior information of the illegal MCU chip are recorded through the blockchain platform for subsequent tracking and processing.

[0010] Optionally, in a first implementation of the first aspect of the present invention, during the MCU chip design phase, a PUF circuit is embedded into the MCU chip, and the PUF circuit generates a unique response key based on the inherent randomness of the hardware, including: selecting a PUF type, which includes SRAM PUF, Ring Oscillator PUF, or Delay PUF: Based on the selected PUF type, a PUF circuit is designed. This circuit can capture and utilize the inherent randomness of hardware, such as the unevenness of transistors and slight differences in resistance. The inherent randomness includes the unevenness of transistors and slight differences in resistance. During the design phase of the MCU chip, the PUF circuit is integrated into the MCU chip as a security module; input data is collected when the MCU chip starts up. The input data includes the current timestamp, device serial number, and ambient temperature. The collected input data is input into the PUF circuit, and a unique response key is generated using the inherent randomness of the hardware; and / or a dynamic challenge-response mechanism is designed. The input data also includes the user's biometric information; each time the MCU chip starts up, a new unique response key is generated based on the new input data and the PUF circuit to prevent the key from being used for a long time and increasing the risk of being cracked; and a unique response key is obtained.

[0011] Optionally, in the second implementation of the first aspect of the present invention, a blockchain platform for MCU chip burning verification is preset to ensure the security and non-tamperability of the data, and a smart contract is deployed on the blockchain platform to record the burning information of the MCU chip. The burning information includes the MCU chip ID, timestamp, and number of burns, and the verification rules and locking mechanism are defined. An encryption algorithm is preset to encrypt the program inside the MCU chip, and the encrypted program is stored in the Flash or ROM of the MCU chip to ensure that the program exists in ciphertext form, including: selecting a blockchain platform technology, selecting a blockchain platform, the blockchain platform includes Ethereum, supporting the deployment of smart contracts, building a private or alliance chain network, and ensuring the security and performance of the network; deploying a smart contract for recording the burning information of the MCU chip on the blockchain platform, and the smart contract has the function of recording MC U chip ID, timestamp, and number of burns. In the smart contract, preset verification rules are set. The verification rules include checking the rationality of the number of burns and defining a locking mechanism. When abnormal burning behavior is detected, the lock can be automatically triggered to prevent further burning operations. Based on the smart contract of the blockchain platform, dynamic burning permission management is realized. Only authorized entities can perform burning operations, and each burning requires permission verification through the smart contract. Preset encryption algorithm, select encryption algorithm, encryption algorithm includes AES or RSA, which is used to encrypt the program inside the MCU chip. After the MCU chip program development is completed, the preset encryption algorithm is used to encrypt the program. The encrypted program is stored in the Flash or ROM of the MCU chip in ciphertext form to ensure that even if the attacker has physical access to the MCU chip, he cannot directly read or copy the decrypted program.

[0012] Optionally, in a third implementation of the first aspect of the present invention, the application for burning authorization is made, and the user applies for authorization from the server before burning, submits the MCU chip ID and other necessary information, and the server verifies the validity of the MCU chip ID and whether the number of burning times exceeds the limit by querying the blockchain platform records, and then generates authorization information, and the server transmits the authorization information to the burning device through a secure channel, and the burning device starts the burning process after verifying that the authorization information is correct, including: before burning, the user submits a burning authorization application to the server through the burning device, and the application includes the MCU chip ID, the program version expected to be burned, and the necessary information for burning device identification; after receiving the application, the server first verifies the historical burning information and validity of the MCU chip ID by querying the blockchain platform records, and the server checks whether the number of burning times of the MCU chip has reached a preset upper limit. If the MCU chip ID is valid and the number of burning times is within the limit, the server generates an authorization letter including a timestamp, validity period, MCU chip ID, program version number and authorization signature information; and / or implement a multi-level authorization mechanism, which requires joint authorization from multiple administrators or departments to perform burning; and / or implement a physical locking mechanism on the burning device, using Flash or ROM to store and manage keys and authorization information; the server transmits the authorization information to the burning device through the HTTPS communication protocol, and / or uses TLS encryption to ensure data security during transmission; after receiving the authorization information, the burning device first verifies the validity of the authorization signature to ensure that the authorization information has not been tampered with. After the verification is passed, the burning device will check whether the timestamp, validity period, MCU chip ID, program version number and authorization signature in the authorization information are consistent with the information submitted during the application; after all verification steps are successful, the burning device starts burning the program into the MCU chip; after the burning is completed, the burning device will send a confirmation message of the completion of the burning to the server so that the server can update the burning record on the blockchain platform; set up an early warning mechanism, and when an abnormal burning request or unauthorized burning attempt is detected, an alarm will be triggered immediately and relevant personnel will be notified.

[0013] Optionally, in a fourth implementation of the first aspect of the present invention, the encrypted program is decrypted based on the unique response key to obtain the decrypted program, and before the program is executed, multiple checks are performed based on the decrypted program to ensure that the program has not been illegally tampered with, and verification information is obtained, including: using the response key to decrypt, using the unique response key previously generated by the PUF circuit to decrypt the encrypted program stored in the MCU chip; the multiple checks include timestamp verification and burn count verification: after the program is decrypted, the timestamp information in the program is first extracted, the current time is obtained, and compared with the timestamp in the program; the program contains a record of the burn count. The number field is incremented each time the program is burned into the MCU chip. Before the program is executed, check whether the value of this field exceeds the preset maximum number of burn times; before the program is encrypted, calculate the program's hash value and store it in the secure area. After decryption, recalculate the program's hash value and compare it with the stored hash value; use the private key to sign the original program, and store the signature information in the secure area. Before the program is executed, use the public key to verify the validity of the signature; dynamically adjust the timestamp check and the burn count check thresholds according to the usage and environment of the MCU chip. If the MCU chip has not been used for a long time, relax the timestamp check threshold; and obtain verification information.

[0014] Optionally, in the fifth implementation of the first aspect of the present invention, the verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU chip will automatically trigger a locking mechanism to prevent the MCU chip from being used again. The ID and behavior information of the illegal MCU chip are recorded through the blockchain platform for subsequent tracking and processing, including: after obtaining the verification information, the MCU chip compares it with a preset range, checks whether the MCU chip ID matches the recorded legal ID, checks whether the number of burns exceeds the preset maximum value, and verifies the validity of the verification information such as the timestamp, hash value or signature; once any illegal copying or tampering is found, including MCU chip ID mismatch or burn times exceeding the limit, the MCU chip will immediately trigger a built-in lock life command; and / or the MCU chip reads the stored data from the Flash or ROM and performs encryption calculations each time it is turned on, and compares the calculation results with the data read and processed from the serial port. If the data are inconsistent, the MCU chip will directly trigger the lock command; the lock command is a hardware-level fuse mechanism that permanently disables the key functions of the MCU chip by physical means, making it unusable again; when the MCU chip triggers the lock command, it will generate a digital certificate containing the illegal MCU chip ID, behavior information and verification failure reason. The digital certificate will be encrypted and signed, and the MCU chip or the server communicating with it will upload the encrypted digital certificate to the blockchain platform. The blockchain platform provides a recording system for storing and verifying these certificates.

[0015] Optionally, in the sixth implementation method of the first aspect of the present invention, it also includes: establishing a reputation system based on the blockchain platform to score and rank the parties in the supply chain, and adjusting the reputation scores of the parties according to their performance in handling the problem of illegal MCU chips, thereby affecting future business cooperation and trust relationships; providing .a and .h files to the outside world, exposing only two interfaces for external use. When used commercially, the server will provide authorization and authorization times to the burning device.

[0016] A second aspect of the present invention provides a device for preventing a program within an MCU chip from being copied, the device comprising: a circuit module for utilizing the inherent randomness of hardware to generate a unique response key each time the MCU chip is powered on. This key is used to encrypt and decrypt the program within the MCU chip, thereby increasing the security of the program and preventing unauthorized copying or access;

[0017] The interface module is responsible for communicating with the preset blockchain platform to ensure data security and non-tamperability. Through the blockchain platform, it records the MCU chip burning information, including the MCU chip ID, timestamp, and burning times, and uses smart contracts to define verification rules and locking mechanisms;

[0018] The encryption module encrypts the program inside the MCU chip using a preset encryption algorithm and decrypts it using the unique response key generated by the PUF circuit when the program needs to be executed, ensuring that the program is always stored in ciphertext form;

[0019] The verification module is responsible for handling the application and verification process of burning authorization. Before burning, the user needs to apply for authorization from the server through this module, submit the MCU chip ID information, and receive the authorization information returned by the server. The burning process will not start until the authorization information is verified to be correct, ensuring that only authorized devices can burn the program;

[0020] The verification module verifies the decrypted program before execution to ensure that it has not been illegally tampered with. Once illegal copying or tampering is detected, it triggers a locking mechanism to prevent the MCU chip from being used again. The ID and behavior information of the illegal MCU chip are recorded through the blockchain platform for subsequent tracking and processing.

[0021] The third aspect of the present invention provides a device for preventing the internal program of an MCU chip from being copied, comprising: a memory and at least one processor, wherein the memory stores instructions; the at least one processor calls the instructions in the memory so that the device for preventing the internal program of an MCU chip from being copied executes the above-mentioned method for preventing the internal program of an MCU chip from being copied.

[0022] A fourth aspect of the present invention provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, it enables the computer to execute the above-mentioned method of preventing the internal program of the MCU chip from being copied.

[0023] The technical solution provided by the present invention combines a physical unclonable function (PUF) circuit, blockchain technology, an encryption algorithm, and a strict burning verification process. This includes embedding a PUF circuit in the MCU chip design phase to generate a unique response key, using the blockchain platform to ensure the security and non-tampering of data, recording the burning information of the MCU chip through a smart contract, and defining verification rules and a locking mechanism. Before burning, the user needs to apply for authorization from the server and transmit the authorization information to the burning device through a secure channel. The encrypted program will undergo multiple checks before decryption and execution to ensure that the program has not been illegally tampered with. Once illegal copying or tampering is detected, the MCU chip will automatically trigger the locking mechanism and record the ID and behavior information of the illegal MCU chip to the blockchain platform for subsequent tracking and processing.

[0024] Beneficial effects:

[0025] Combating Copying: Some companies illegally obtain and copy .bin files through methods such as grinding. This invention significantly reduces the difficulty and risk of illegal copying through strict encryption, verification, and locking mechanisms, effectively combating such illegal activities and protecting the security and integrity of the original program.

[0026] Protecting Developer Rights: Many developers invest significant time and effort in developing projects, only to have them easily copied by clients at low cost. This invention protects the developer's work by ensuring the security and non-copyability of the program, making it difficult for clients to easily obtain and copy the program, thereby safeguarding the developer's legitimate rights and interests.

[0027] Flexible Application: This solution is not only suitable for personal or corporate use, but can also be securely shared with suppliers via burning. All data is asymmetrically encrypted and timestamped, ensuring data legitimacy and security during transmission. This effectively prevents repeated attempts and unauthorized access through recording and replay, providing a secure data exchange environment for both parties.

[0028] Highly customizable and adaptable: The hardware solution of this invention ensures security through different cryptographic checksums. Even if there is a risk of a leak, the manufacturer can be quickly contacted to change the .a file and password, rendering illegally obtained programs inoperable. This high degree of customizability and adaptability enables this invention to flexibly address various security threats and ensure the continued security of the system.

[0029] In summary, the beneficial effects and advantages of the present application mainly lie in the aspects of combating illegal copying behavior, protecting the rights and interests of developers, providing flexible application modes, and high customizability and adaptability, etc. These advantages collectively ensure the security and integrity of the internal program of the MCU chip, and provide strong protection for developers and users. BRIEF DESCRIPTION OF DRAWINGS

[0030] Figure 1 An embodiment of the method for preventing the internal program of the MCU chip from being copied in the embodiment of the present application is shown in the figure;

[0031] Figure 2 Another embodiment of the method for preventing the internal program of the MCU chip from being copied in the embodiment of the present application is shown in the figure;

[0032] Figure 3 An embodiment of the device for preventing the internal program of the MCU chip from being copied in the embodiment of the present application is shown in the figure;

[0033] Figure 4 An embodiment of the equipment for preventing the internal program of the MCU chip from being copied in the embodiment of the present application is shown in the figure. DETAILED DESCRIPTION

[0034] The embodiment of the present application provides a method for preventing the internal program of the MCU chip from being copied, which is used to provide better protection means for software development companies. The terms "first", "second", "third", "fourth" and the like (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the term "comprising" or "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0035] For the sake of understanding, the specific flow of the embodiment of the present application is described below, please refer to Figure 1 An embodiment of the method for preventing the internal program of the MCU chip from being copied in the embodiment of the present application includes:

[0036] 101、in the MCU chip design stage, the PUF circuit is embedded into the MCU chip, and the MCU chip generates a unique response key based on the inherent randomness of the hardware each time it is powered on;

[0037] It is understandable that the execution subject of the present invention can be a device for preventing the internal program of the MCU chip from being copied, or a terminal or a server, which is not limited here. The embodiment of the present invention is described by taking the server as the execution subject as an example.

[0038] It should be noted that the PUF circuit is embedded in the MCU chip and generates a unique response key when powered on:

[0039] 1. MCU chip design stage

[0040] Designing the PUF circuit:

[0041] During the MCU chip design phase, a PUF (Physical Unclonable Function) circuit is designed based on the physical characteristics of the MCU chip (such as delay, threshold voltage variation, etc.).

[0042] PUF circuits are composed of multiple identical physical elements (such as transistors, gate circuits, etc.), which may have slight differences due to process deviations during the manufacturing process.

[0043] Integrating PUF circuit into MCU chip:

[0044] Integrate the designed PUF circuit into the MCU chip layout.

[0045] Ensure that the PUF circuit is compatible with other logic circuits of the MCU chip and does not affect the normal functions of the MCU chip.

[0046] 2. MCU chip power-on and key generation

[0047] Power-on initialization:

[0048] When the MCU chip is powered on, it first performs a series of initialization operations.

[0049] During this process, the PUF circuit is also activated to prepare to generate the response key.

[0050] PUF circuit challenge-response:

[0051] The MCU chip sends a challenge to the PUF circuit. This challenge can be a random digital signal or a specific electrical signal pattern.

[0052] After receiving the challenge, the PUF circuit generates a unique response due to the randomness of its internal physical elements.

[0053] Example data:

[0054] We have a PUF circuit consisting of 128 identical gates. Each gate exhibits a different delay for the same input due to manufacturing variations. After powering on the MCU chip, it sends a unique binary challenge signal: 1010110011010011. Upon receiving the challenge, each gate in the PUF circuit generates a delay output based on the input signal and its own physical characteristics. The MCU measures and records the delay of each gate, generating a delay sequence, for example (in nanoseconds): [2.3, 2.5, 2.4, 2.6, ...]. This delay sequence is unique and varies slightly with each power-on due to physical randomness, but the overall pattern remains consistent. The MCU chip converts this delay sequence into a unique response key, for example: A5B3C7D9..., using an algorithm (such as a hash function).

[0055] Key application:

[0056] This unique response key can be used for encryption, decryption, and verification of programs within the MCU chip. Since the key generated each time the power is turned on is unique, even if an attacker can obtain the key at a certain time, they cannot predict or copy the key at other times.

[0057] 102. Preset a blockchain platform for MCU chip burning verification to ensure data security and non-tamperability. Deploy smart contracts on the blockchain platform to record the burning information of the MCU chip, including the MCU chip ID, timestamp, and number of burns. Define verification rules and locking mechanisms, preset encryption algorithms to encrypt the program inside the MCU chip, and store the encrypted program in the Flash or ROM of the MCU chip to ensure that the program exists in ciphertext form.

[0058] It should be noted that the blockchain platform is used to ensure the security and non-tamperability of MCU chip burning information:

[0059] 1. Pre-set blockchain platform and smart contract deployment

[0060] Blockchain platform selection:

[0061] Choose a mature blockchain platform, such as Ethereum, to build the MCU chip burning verification system. Leverage the immutability and decentralization of blockchain to ensure the security and credibility of the burning information.

[0062] Smart contract deployment:

[0063] Deploy a smart contract on the blockchain platform and name it "MCU chip burning verification contract."

[0064] This contract is used to record the burning information of the MCU chip, including the MCU chip ID, timestamp, burning times, etc.

[0065] 2. Burning Information Recording and Verification Rules

[0066] Burning information record:

[0067] When an MCU chip is programmed, the relevant information will be recorded in the smart contract. For example, the MCU chip ID of an MCU chip is MCU chip 001, and the first programming was performed at 2023-04-01 10:00:00.

[0068] Validation rules and locking mechanism:

[0069] The smart contract defines verification rules, such as each MCU chip can only be burned three times at most. If the number of burn times of a certain MCU chip exceeds the limit, the contract will trigger a lock mechanism, prohibiting the MCU chip from being burned again.

[0070] Example data:

[0071] MCU chip ID: MCU chip 001

[0072] Timestamp: 2023-04-01 10:00:00 (first burn), 2023-04-05 15:30:00 (second burn)

[0073] Burn times: 2 times (for MCU chip 001)

[0074] 3. Program Encryption and Storage

[0075] Default encryption algorithm:

[0076] Select a secure encryption algorithm, such as AES (Advanced Encryption Standard), to encrypt the program inside the MCU chip. Generate a key, such as KeyABC123, to encrypt and decrypt the program.

[0077] Program encryption:

[0078] Before burning the program into the MCU chip, the program is encrypted using the preset encryption algorithm and key. The encrypted program exists in binary ciphertext form, for example: 0xA5B3C7...

[0079] Ciphertext storage:

[0080] The encrypted program is stored in the Flash or ROM of the MCU chip. This ensures that the program exists in ciphertext form in the MCU chip, making it more difficult to copy and tamper with.

[0081] 103. Apply for programming authorization. Before programming, the user applies for authorization from the server and submits the MCU chip ID and other necessary information. The server verifies the validity of the MCU chip ID and whether the programming times have exceeded the limit by querying the blockchain platform records. Then, it generates authorization information. The server transmits the authorization information to the programming device through a secure channel. The programming device starts the programming process after verifying that the authorization information is correct.

[0082] It should be noted that in the method of preventing the internal program of the MCU chip from being copied, the process of implementing "applying for burning authorization" can be specifically implemented through the following steps:

[0083] Step 1: User submits application

[0084] Before the user prepares to burn, he or she must first submit an application to the authorization server through the burning device or dedicated software.

[0085] The information included in the application includes: MCU chip ID (for example: UID-12345-ABC), expected burning time (for example: 2024-08-26 18:00:00), and other necessary user information (such as user name, device model, etc.).

[0086] Step 2: Server verification and processing

[0087] After receiving the application, the server first queries the records on the blockchain platform.

[0088] The server confirms that the MCU chip ID "UID-12345-ABC" has a valid record on the blockchain, and the historical burn times are 2 times (the maximum allowed burn times are 5 times).

[0089] The server verifies that the number of programming attempts for the MCU chip ID is within the limit, and then generates authorization information including a timestamp (e.g., 2024-08-26 18:05:00), a randomly generated authorization code (e.g., AUTH-98765), and the MCU chip ID.

[0090] The server encrypts the authorization information and transmits it to the burning device through a secure channel such as SSL / TLS.

[0091] Step 3: Device verification and programming

[0092] After receiving the encrypted authorization information, the burning device uses the preset key to decrypt it.

[0093] After decryption, the burning device verifies whether the timestamp in the authorization information is within the valid time (for example, within 5 minutes after the time sent by the server) and checks the validity of the authorization code.

[0094] After everything is verified to be correct, the burning device starts the burning process and writes the user's program firmware into the MCU chip.

[0095] After the burning is completed, the burning device will send a confirmation message to the server, including the timestamp of the successful burning and the MCU chip ID.

[0096] After receiving the confirmation information, the server updates the relevant records on the blockchain platform, including increasing the number of burning times.

[0097] Step 4: Subsequent verification and recording

[0098] Before each burning, the server will repeat the above verification process to ensure that the number of burning times for each MCU chip ID does not exceed the limit.

[0099] All these operations will leave an unalterable record on the blockchain platform for subsequent auditing and tracking.

[0100] 104. Decrypt the encrypted program using the unique response key to obtain a decrypted program. Before executing the program, perform multiple checks on the decrypted program to ensure that the program has not been illegally tampered with, thereby obtaining verification information.

[0101] It should be noted that the encrypted program is decrypted and verified using the unique response key generated by the PUF:

[0102] 1. Encryption Procedure and Key Generation

[0103] Encryption procedure:

[0104] We have an MCU chip program, which we call the "original program". Before burning the original program into the MCU chip, we first use the AES encryption algorithm and a preset key (for example: Key001) to encrypt the original program to obtain the "encrypted program".

[0105] PUF response key generation:

[0106] The MCU chip has an integrated PUF circuit. Each time it is powered on, the PUF circuit generates a unique response key based on the inherent randomness of the hardware. On a particular power-on, the response key generated by the PUF circuit is PUFKey123.

[0107] 2. Decryption Procedure

[0108] Key matching and decryption:

[0109] The MCU chip uses the response key PUFKey123 generated by the PUF to decrypt the encrypted program.

[0110] Suppose the binary data of a part of the encrypted program is 10110010..., after decryption using PUFKey123, the decrypted program data is 01011010...

[0111] III. Program Verification

[0112] Generating Verification Information:

[0113] Before program execution, the MCU chip will verify the decrypted program to ensure that the program has not been tampered with illegally.

[0114] A common verification method is to use a hash function (such as SHA-256) to calculate the decrypted program and obtain a hash value, which is the verification information.

[0115] The hash value of the decrypted program is HashValueABC.

[0116] Verification Process:

[0117] The MCU chip internally stores the correct hash value of the original program, which is OriginalHashXYZ.

[0118] The MCU chip compares the calculated hash value HashValueABC with the stored correct hash value OriginalHashXYZ.

[0119] If they match, it means that the decrypted program has not been tampered with and can be safely executed.

[0120] If they do not match, it means that the program may have been tampered with illegally, and the MCU chip will refuse to execute the program and may trigger the appropriate security mechanism.

[0121] Example Data:

[0122] Original Program: Binary Data (Part)... 11010101...

[0123] Default Key: Key001

[0124] Encrypted Program: Binary Data (Part) 10110010... (After Encryption)

[0125] PUF Response Key: PUFKey123

[0126] Decrypted Program: Binary Data (Part) 01011010... (After Decryption)

[0127] Correct Hash Value: OriginalHashXYZ

[0128] Calculate Hash Value: HashValueABC

[0129] Through this embodiment, we can see how to use the unique response key generated by PUF to decrypt the encrypted program, and ensure that the program has not been illegally tampered with through hash verification. This method combines encryption, decryption and verification mechanisms, providing strong protection for the security of MCU chip internal programs.

[0130] 105、According to the verification result of the verification information, once illegal copying or tampering is found, the MCU chip will automatically trigger the lock mechanism, making the MCU chip unable to be used again, and recording the ID and behavior information of the illegal MCU chip on the blockchain platform for subsequent tracking and processing.

[0131] It should be noted that:

[0132] I. Verification information judgment

[0133] Verification process:

[0134] Set the original program correct hash value stored in the MCU chip as OriginalHashXYZ. When the MCU chip is powered on and the program is decrypted, the hash value of the decrypted program is calculated, that is, the verification information, set as CalculatedHash123.

[0135] Result judgment:

[0136] The MCU chip compares CalculatedHash123 with OriginalHashXYZ. If they are consistent, the program has not been tampered with, and the MCU chip continues to execute the program normally. If they are not consistent, it means that the program may have been illegally copied or tampered with.

[0137] II. Illegal behavior processing

[0138] Trigger lock mechanism:

[0139] Once the verification information is found to be mismatched, the MCU chip will automatically trigger the built-in lock mechanism. The lock mechanism involves blowing internal circuits, erasing critical data, or making the MCU chip enter a permanently inoperable state.

[0140] In this example, the lock mechanism is achieved by erasing the critical configuration information stored internally and permanently locking the write function.

[0141] Record illegal behavior:

[0142] At the same time of triggering the lock mechanism, the MCU chip will send a record request containing the illegal MCU chip ID and behavior information to the blockchain platform through the internal communication module (such as Wi-Fi, Bluetooth or wired interface).

[0143] The ID of the illegal MCU chip is set to ChipID456. The behavior information includes the verification failure timestamp 2023-11-0115:30:00, the hash value CalculatedHash123 of the decryption program, and the original hash value OriginalHashXYZ.

[0144] Blockchain platform records:

[0145] After the blockchain platform receives the record request sent by the MCU chip, it will record this information as a transaction on the blockchain.

[0146] The transaction contains the MCU chip ID, behavior information, a timestamp, and a hash pointer to the previous block, ensuring the immutability and traceability of the record.

[0147] Example data:

[0148] Original program correct hash value: OriginalHashXYZ

[0149] Decryption program calculates hash value: CalculatedHash123

[0150] Illegal MCU chip ID: ChipID456

[0151] Verification failure timestamp: 2023-11-01 15:30:00

[0152] An embodiment of the present invention provides a comprehensive method for preventing the copying of programs within an MCU chip. This method combines a physically unclonable function (PUF) circuit, blockchain technology, an encryption algorithm, and a verification mechanism to ensure the security and unclonability of MCU chip programs. First, a PUF circuit is embedded during the MCU chip design phase, generating a unique response key each time the chip is powered on. Second, a blockchain platform is used to record the MCU chip's programming information, and verification rules and a lockout mechanism are defined through smart contracts. Before programming, the user must apply for programming authorization from a server. The server verifies the validity of the MCU chip ID and the number of programming cycles, then generates authorization information. The program is encrypted and stored in the MCU chip. After powering on, it is decrypted using the response key generated by the PUF, and a verification process is performed to ensure the program has not been tampered with. If illegal activity is detected, the MCU chip triggers the lockout mechanism and records the relevant information on the blockchain platform. The unique response key generated by the PUF circuit ensures the uniqueness of the key at each power-on, significantly improving program security. Even if an attacker obtains the key at a certain point in time, they cannot predict or copy the key at other times. The immutability of the blockchain platform ensures the authenticity and credibility of the programming information and the record of illegal activity. This facilitates subsequent tracking and handling of illegal activities. The verification rules and locking mechanism defined by the smart contract limit the number of times each MCU chip can be burned, preventing the risk of program leakage caused by excessive burning. During the verification process, if the program is found to have been illegally copied or tampered with, the MCU chip will immediately trigger the locking mechanism, rendering the MCU chip unable to be used again, thereby promptly preventing illegal activities. All relevant operations will leave an unalterable record on the blockchain platform, greatly facilitating subsequent tracking and auditing. Combining multiple security mechanisms, including the physical layer, data encryption, and blockchain, this technology provides comprehensive protection for the programs within the MCU chip. In summary, by combining PUF circuits, blockchain, encryption algorithms, and verification mechanisms, this technology provides strong security protection for the programs within the MCU chip, effectively preventing the risk of program copying and tampering, and improving the traceability of illegal activities.

[0153] See also Figure 2 Another embodiment of the method for preventing the internal program of an MCU chip from being copied in the embodiment of the present invention includes:

[0154] 201. During the MCU chip design phase, a PUF circuit is embedded in the MCU chip. Each time the MCU chip is powered on, the PUF circuit generates a unique response key based on the inherent randomness of the hardware.

[0155] Specifically, a PUF type is selected, including SRAM PUF, Ring Oscillator PUF, or Delay PUF, based on the selected PUF type, a PUF circuit is designed, which can capture and utilize the inherent randomness of hardware, including transistor non-uniformity and resistance micro-differences, at the design stage of the MCU chip, the PUF circuit is integrated into the MCU chip as a security module; collect input data, collect input data when the MCU chip starts, input data includes current timestamp, device serial number, environment temperature, input the collected input data into the PUF circuit, and generate a unique response key using the inherent randomness of hardware; and / or design a dynamic challenge-response mechanism, input data also includes user's biometric information; each time the MCU chip starts, a new unique response key is generated based on new input data and PUF circuit, which prevents the key from being used for a long time and increases the risk of being cracked; a unique response key is obtained;

[0156] It should be noted that in the embodiment, a certain MCU chip manufacturer wants to design a security module for its products to prevent internal programs from being illegally copied. To this end, they have chosen SRAM PUF as their core security component.

[0157] Step 1: Design SRAM PUF circuit

[0158] At the design stage of the MCU chip, an SRAM PUF circuit is designed. This circuit can capture and utilize the inherent randomness of hardware, including transistor non-uniformity and resistance micro-differences. Specifically, when the SRAM unit is initialized at power-on, due to the slight differences in hardware manufacturing, each SRAM unit will have a different initial state (0 or 1). This randomness of initial state can be used as a unique fingerprint of the device.

[0159] Step 2: Integrate PUF circuit into MCU chip

[0160] After completing the design of the SRAM PUF circuit, engineers integrate it into the MCU chip as a security module.

[0161] Step 3: Collect input data

[0162] When the MCU chip starts, the system will collect the following input data:

[0163] Current timestamp: For example, 2023-10-27 10:30:15

[0164] Device serial number: For example, SN123456789

[0165] Environment temperature: For example, 25℃

[0166] It is also possible to collect biometric information about the user, such as fingerprint data, but this is not included in this example to simplify the explanation.

[0167] Step 4: Generate Response Key

[0168] The collected data is input into the SRAM PUF circuit, which uses the inherent randomness of the hardware to generate a unique response key. For example, if our SRAM PUF has 128 bits, the generated response key is as follows: 1010110010101100101011001010110010101100101011001010110010101100

[0170] Step 5: Dynamic Challenge-Response Mechanism

[0171] Each time the MCU starts up, a new unique response key is generated based on new input data and the SRAM PUF circuit. This ensures that the key will not be used for a long time, thereby reducing the risk of being cracked.

[0172] For example, if the data collected by the MCU chip during the next startup is:

[0173] Current timestamp: 2023-10-28 11:45:30

[0174] Device serial number: SN123456789 (device serial number remains unchanged)

[0175] Ambient temperature: 27°C

[0176] Then, based on this data and the new SRAM PUF reading, a new, unique response key is generated.

[0177] 202. Preset a blockchain platform for MCU chip burning verification to ensure data security and non-tamperability. Deploy smart contracts on the blockchain platform to record the burning information of the MCU chip, including the MCU chip ID, timestamp, and number of burns. Define verification rules and a locking mechanism, preset an encryption algorithm to encrypt the program inside the MCU chip, and store the encrypted program in the Flash or ROM of the MCU chip to ensure that the program exists in ciphertext form.

[0178] Specifically, blockchain platform technology is selected, including a blockchain platform such as Ethereum that supports the deployment of smart contracts, and a private or consortium chain network is built to ensure the security and performance of the network. A smart contract for recording MCU chip burning information is deployed on the blockchain platform. The smart contract has the function of recording the MCU chip ID, timestamp, and number of burns. In the smart contract, verification rules are preset, including checking the rationality of the burn number and defining a lock mechanism. When abnormal burning behavior is detected, a lock can be automatically triggered to prevent further burning operations. Based on the smart contract of the blockchain platform, dynamic burning permission management is implemented. Only authorized entities can perform burning operations, and each burning operation requires permission verification through the smart contract. An encryption algorithm is preset, including AES or RSA, which is used to encrypt the program inside the MCU chip. After the MCU chip program is developed, the program is encrypted using the preset encryption algorithm. The encrypted program is stored in the Flash or ROM of the MCU chip in ciphertext form to ensure that even if an attacker has physical access to the MCU chip, the decrypted program cannot be directly read or copied.

[0179] It should be noted that:

[0180] Step 1: Build a blockchain network

[0181] The manufacturer first built a private Ethereum network. They selected several trusted nodes, such as servers from the R&D, production, and quality inspection departments, to form this private network.

[0182] Step 2: Deploy the smart contract

[0183] On the Ethereum platform, they deployed a smart contract called "MCU Chip_BurnInfo". The main functions of this contract are:

[0184] Record the MCU chip ID, timestamp, and programming times.

[0185] Verify the rationality of the number of burns. For example, if an MCU chip is burned frequently in a short period of time, the contract will consider it abnormal.

[0186] Define a lockout mechanism. When abnormal programming behavior is detected (such as the number of programming times exceeding the preset threshold), the lockout is automatically triggered.

[0187] Example data:

[0188] MCU chip ID: 0x1A2B3C

[0189] Timestamp: 2023-10-27 15:30:00

[0190] Burn times: 3

[0191] Step 3: Implement dynamic burning permission management

[0192] Only authorized entities, such as R&D and production departments, can obtain burning permissions. Before each burning, permission verification is required through the "MCU Chip_BurnInfo" contract.

[0193] Step 4: Preset encryption algorithm and encrypt the program

[0194] The manufacturer chose the AES-256 encryption algorithm and used it to encrypt the MCU chip program after it was developed.

[0195] Program example before encryption:

[0196] c

[0197] void main(){

[0198] / / MCU chip initialization code...

[0199] }

[0200] Encrypted program (ciphertext form, the specific value depends on the encryption key and algorithm implementation):

[0201] 3a7b593475da4e37a0128921c93b8f5e...

[0202] Step 5: Store the encrypted program

[0203] The encrypted program is stored in the Flash memory of the MCU chip in ciphertext form.

[0204] Through the above examples, the MCU chip manufacturer successfully used blockchain technology and encryption algorithms to protect its core programs. Even if an attacker gains physical access to the MCU chip and attempts to read the contents of the Flash memory, they can only obtain the encrypted program and cannot directly obtain or copy the decrypted original program.

[0205] 203. Apply for programming authorization. Before programming, the user applies for authorization from the server and submits the MCU chip ID and other necessary information. The server verifies the validity of the MCU chip ID and whether the programming times have exceeded the limit by querying the blockchain platform records. Then, it generates authorization information. The server transmits the authorization information to the programming device through a secure channel. The programming device starts the programming process after verifying that the authorization information is correct.

[0206] In particular, before burning, the user submits a burning authorization application to the server through the burning device, which contains the MCU chip ID, the expected program version to be burned, and the burning device identification information; after receiving the application, the server first verifies the historical burning information and validity of the MCU chip ID by querying the blockchain platform record, checks whether the burning frequency of the MCU chip has reached the preset upper limit, and if the MCU chip ID is valid and the burning frequency is not exceeded, the server generates an authorization information containing timestamp, validity period, MCU chip ID, program version number and authorization signature; and / or implement a multi-level authorization mechanism that requires joint authorization of multiple administrators or departments to perform burning; and / or implement a physical locking mechanism on the burning device, using Flash or ROM to store and manage keys and authorization information; the server transmits the authorization information to the burning device through the HTTPS communication protocol, and / or uses TLS encryption to ensure data security during transmission; after receiving the authorization information, the burning device first verifies the validity of the authorization signature to ensure that the authorization information has not been tampered with, and after verification, the burning device checks whether the timestamp, validity period, MCU chip ID, program version number and authorization signature in the authorization information are consistent with the information submitted at the time of application; after all verification steps are successful, the burning device starts to burn the program into the MCU chip; after the burning is completed, the burning device sends a confirmation information of the burning completion to the server to update the burning record on the blockchain platform; set an early warning mechanism to trigger an alarm and notify relevant personnel immediately when an abnormal burning request or unauthorized burning attempt is detected;

[0207] It should be noted that:

[0208] Step 1: User submits a burning authorization application

[0209] Before burning, the user submits a burning authorization application to the server through the burning device. The application contains the following information:

[0210] MCU chip ID: CID001

[0211] Expected program version to be burned: V1.2.0

[0212] Burning device identification: BD001

[0213] Step 2: Server verification and authorization

[0214] After receiving the application, the server queries the blockchain platform record and finds that the historical burning frequency of MCU chip ID CID001 is 2 times, which does not reach the preset upper limit of 5 times. Therefore, the server generates authorization information:

[0215] Timestamp: 2023-11-01 10:30:00

[0216] Valid until: 2023-11-01 11:00:00

[0217] MCU chip ID: CID001

[0218] Program version number: V1.2.0

[0219] Authorization signature: SIG_XYZ (signed using the server's private key)

[0220] Step 3: Server transmits authorization information

[0221] The server transmits the authorization information to the burning device BD001 through the HTTPS communication protocol and uses TLS encryption to ensure data security.

[0222] Step 4: Burn device verification authorization information

[0223] After receiving the authorization information, the burning device first uses the server's public key to verify the validity of the authorization signature SIG_XYZ. After verification, it checks whether the data in the authorization information is consistent with the information submitted during the application.

[0224] Step 5: Burn the program into the MCU chip

[0225] After all verification steps are successful, the burning device starts burning the program version V1.2.0 into the MCU chip with MCU chip ID CID001.

[0226] Step 6: Confirm burning completion and update records

[0227] After the programming is complete, the programming device sends a confirmation message to the server. After receiving the confirmation, the server updates the programming record on the blockchain platform and increases the programming times of MCU chip ID CID001 by 1 to 3 times.

[0228] Step 7: Early warning mechanism triggering and notification

[0229] During the process, if the server detects an abnormal burning request (such as the number of burning attempts exceeding the upper limit) or an unauthorized burning attempt, it will immediately trigger an alarm and notify the relevant personnel via email. For example, if an unauthorized device attempts to burn, the server will send an alert email to the administrator, and the email content will include the device ID of the attempter, timestamp, and other information.

[0230] 204. Decrypt the encrypted program using the unique response key to obtain a decrypted program. Before executing the program, perform multiple checks on the decrypted program to ensure that the program has not been illegally tampered with, thereby obtaining verification information.

[0231] Specifically, the response key is used for decryption, and the unique response key previously generated by the PUF circuit is used to decrypt the encrypted program stored in the MCU chip; multiple checks include timestamp check and burn count check: after the program is decrypted, the timestamp information in the program is first extracted, the current time is obtained, and compared with the timestamp in the program; the program contains a field that records the number of burns. Each time the program is burned to the MCU chip, the field is incremented. Before the program is executed, it is checked whether the value of the field exceeds the preset maximum number of burns; before the program is encrypted, the hash value of the program is calculated and stored in the secure area. After decryption, the hash value of the program is recalculated and compared with the stored hash value; the original program is signed with a private key, and the signature information is stored in the secure area. Before the program is executed, the validity of the signature is verified using the public key; the thresholds of the timestamp check and the burn count check are dynamically adjusted according to the usage and environment of the MCU chip. If the MCU chip has not been used for a long time, the threshold of the timestamp check is relaxed; and verification information is obtained;

[0232] It should be noted that the following is a specific embodiment that illustrates how to use the response key to decrypt the program and perform multiple verifications.

[0233] Step 1: Decrypt using the response key

[0234] The unique response key previously generated by the PUF circuit is: 0x1A2B3C4D. The encryption program stored in the MCU chip Flash is encrypted using the AES-256 algorithm. The ciphertext format is as follows:

[0235] Encrypted program ciphertext: 0xE345A0B1C2D3...

[0236] Use the response key 0x1A2B3C4D to decrypt the encrypted program and obtain the decrypted program.

[0237] Step 2: Timestamp Verification

[0238] The timestamp information extracted from the decrypted program is: 2023-10-01 12:00:00.

[0239] The current time is: 2023-10-02 10:00:00.

[0240] The preset timestamp verification threshold is 24 hours. Since the difference between the current time and the timestamp in the program is less than 24 hours, the timestamp verification passes.

[0241] Step 3: Verify the number of burn times

[0242] The value of the burn times field recorded in the program is: 3.

[0243] The preset maximum number of burn times is: 5.

[0244] Since the number of programming times does not exceed the maximum number of programming times, the programming times verification passes.

[0245] Step 4: Hash value verification

[0246] The hash value calculated before program encryption is: 0x12345678 (stored in the secure area).

[0247] The recalculated hash value after decryption is: 0x12345678.

[0248] Since the two hash values ​​are consistent, the hash value verification passes.

[0249] Step 5: Signature Verification

[0250] The original program is signed using the private key. The resulting signature is: SIG_ABC (stored in the secure area). Before the program is executed, the public key is used to verify the validity of the signature SIG_ABC. The verification result is valid.

[0251] Step 6: Dynamically adjust the verification threshold

[0252] Considering that an MCU chip may not be used for a long time, if it is detected that the MCU chip has not been used within the last month, the timestamp verification threshold is relaxed to 48 hours. In this example, the MCU chip has been used within the last week, so the original threshold of 24 hours remains unchanged.

[0253] 205. The verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU chip will automatically trigger the locking mechanism, making the MCU chip unable to be used again. The ID and behavior information of the illegal MCU chip will be recorded through the blockchain platform for subsequent tracking and processing.

[0254] Specifically, after obtaining the verification information, the MCU chip compares it with a preset range, checks whether the MCU chip ID matches the recorded legal ID, checks whether the number of burn times exceeds the preset maximum value, and verifies the validity of verification information such as the timestamp, hash value, or signature. Once any illegal copying or tampering is detected, including MCU chip ID mismatch or burn times exceeded, the MCU chip will immediately trigger a built-in lock command. And / or the MCU chip will read the stored data from the Flash or ROM and perform encryption calculations each time it is turned on, and compare the calculation results with the processed data read from the serial port. If the data is inconsistent, the MCU chip will directly trigger the lock command. The lock command is a hardware-level fuse mechanism that permanently disables the key functions of the MCU chip by physical means, making it unusable again. When the MCU chip triggers the lock command, it will generate a digital certificate containing the illegal MCU chip ID, behavior information, and the reason for the verification failure. The digital certificate will be encrypted and signed, and the MCU chip or the server communicating with it will upload the encrypted digital certificate to the blockchain platform. The blockchain platform provides a record system for storing and verifying these certificates.

[0255] It should be noted that the verification and locking mechanism in the MCU chip's internal program copy protection method:

[0256] Step 1: MCU chip obtains verification information

[0257] After the MCU chip decrypts the program and performs multiple checks, it obtains the following verification information:

[0258] MCU chip ID: CID001

[0259] Burn times: 4

[0260] Timestamp: 2023-11-01 15:30:00

[0261] Hash value: 0xAABBCCDDEEFF

[0262] Signature verification result: valid

[0263] Step 2: Compare with preset ranges

[0264] The MCU chip compares this verification information with the preset range:

[0265] Check whether the MCU chip ID CID001 matches the recorded legal ID: the match is successful.

[0266] Check whether the number of programming times 4 exceeds the preset maximum value 5: No.

[0267] Verify whether the timestamp 2023-11-01 15:30:00 is within the valid range: Valid (set the current time to 2023-11-01 16:00:00 and the timestamp verification threshold to 1 hour).

[0268] Verify that the hash value 0xAABBCCDDEEFF is consistent with the stored secure hash value: consistent.

[0269] The signature verification result has been shown to be valid.

[0270] Step 3: Discover illegal behavior and trigger a lock command

[0271] In this embodiment, we intentionally modify the number of burn times to 6 (exceeding the preset maximum value of 5) to simulate illegal copying or tampering.

[0272] The MCU chip detects that the number of programming times exceeds the preset maximum value and determines it as an illegal behavior.

[0273] The MCU chip immediately triggers a built-in lock command, which is a hardware-level fuse mechanism that physically and permanently disables certain key functions of the MCU chip (such as prohibiting program execution or data writing).

[0274] Step 4: Generate and upload a digital certificate

[0275] When the MCU triggers the lock command:

[0276] Generate a digital certificate containing the illegal MCU chip ID (CID001), behavior information (burning times exceeded the limit) and verification failure reason (burning times exceeded the preset maximum value).

[0277] The digital certificate is encrypted and signed to ensure integrity and authenticity.

[0278] The MCU chip (if it can still communicate) or the server connected to it uploads the encrypted digital certificate to the blockchain platform.

[0279] Step 5: The blockchain platform stores and verifies the certificate

[0280] The blockchain platform provides an immutable record system for storing these encrypted and signed digital certificates. Any authorized entity can verify the authenticity and content of these certificates, thereby confirming illegal behavior and taking further action (such as legal prosecution or security audits).

[0281] 206. Establish a reputation system based on a blockchain platform to score and rank all parties in the supply chain. Based on their performance in handling the issue of illegal MCU chips, their reputation scores will be adjusted to influence future business cooperation and trust relationships.

[0282] Provide .a and .h files to the outside world, and only expose two interfaces for external use. When used commercially, the server will provide authorization and number of times for the burning device;

[0283] It should be noted that:

[0284] Step 1: Build a blockchain-based reputation system

[0285] Initialize the reputation system: Create a smart contract on the blockchain platform to record the reputation scores and rankings of all parties in the supply chain.

[0286] Scoring Rules:

[0287] Discover and report illegal MCU chip activities in a timely manner, and receive a reputation score of +10.

[0288] Successfully prevented the circulation of illegal MCU chips, reputation score +20.

[0289] If found to be involved in illegal MCU chip transactions or program copying, the reputation score will be -50.

[0290] Ranking Update: The blockchain smart contract performs real-time ranking based on the reputation scores of all parties.

[0291] Data example:

[0292] Supplier A: Initial reputation score was 100. Due to the timely discovery and reporting of an illegal MCU chip activity, the reputation score increased to 110.

[0293] Supplier B: Initial reputation score was 100, but it was found to be involved in illegal transactions, so its reputation score dropped to 50.

[0294] Step 2: Interface authorization mechanism

[0295] Provide interface files: The company provides .a (static library files) and .h (header files) to the outside world, and only exposes two interfaces for external use: InitializeMCU chip () and ProgramMCU chip ().

[0296] Server authorization:

[0297] When a customer needs to burn an MCU chip, the server first verifies the customer's identity and burning requirements.

[0298] The server generates an authorization token containing authorization information and the number of programming times, and transmits it to the programming device via HTTPS.

[0299] Burning device verification and burning:

[0300] After receiving the authorization token, the burning device verifies its validity.

[0301] Perform the burning operation within the authorized range. If the burning times are exceeded, the burning device will refuse the operation.

[0302] Data example:

[0303] Client C requests to program 100 MCU chips. After the server verifies the request, it generates an authorization token containing information such as client C's ID, authorization time, and programming limit (100 times).

[0304] After receiving the authorization token, the burning device successfully verifies and starts burning. When burning to the 101st MCU chip, the burning device prompts "The number of burning times has exceeded the limit. Please apply for authorization again."

[0305] Step 3: Linking the reputation system with the authorization mechanism

[0306] Incentives and penalties: The reputation scores of all parties in the supply chain are adjusted based on their performance in preventing illegal MCU chips. Suppliers or customers with high reputation scores can enjoy faster review processes and more favorable licensing fees when applying for authorization.

[0307] Transparency and traceability: All reputation score changes and authorization records are stored on the blockchain, ensuring data transparency and immutability.

[0308] Through this example, we demonstrate how to combine the blockchain reputation system and the interface authorization mechanism to effectively prevent the internal programs of MCU chips from being copied, while incentivizing all parties in the supply chain to actively participate in maintaining the security of the system.

[0309] In this embodiment of the present invention, a multi-layered security system is constructed using a physically unclonable function (PUF), blockchain technology, encryption algorithms, and an authorization mechanism to prevent the copying of programs within the MCU chip. First, a unique response key is generated using the PUF circuit, ensuring that a new security key is obtained each time the MCU chip boots up, increasing the difficulty of cracking. Second, a blockchain platform records programming information and implements dynamic programming permission management, ensuring the security and traceability of the programming process. Furthermore, an encryption algorithm is used to encrypt the program, and multiple verification mechanisms are implemented to ensure that the program has not been illegally tampered with. Finally, a blockchain-based reputation system is established to score and rank all parties in the supply chain, incentivizing their active participation in maintaining system security. Unauthorized access and copying are also restricted through an interface authorization mechanism. The unique response key and encryption algorithm generated by the PUF circuit ensure the security of the program within the MCU chip. Even if an attacker has physical access to the MCU chip, they cannot directly read or copy the decrypted program. The use of a blockchain platform ensures that all programming information and authorization records are traceable and tamper-proof, facilitating the subsequent tracking and handling of illegal activities. Dynamic programming rights management and authorization ensure that only authorized entities can perform programming operations, effectively preventing illegal copying. The blockchain-based reputation system, through scoring and ranking mechanisms, incentivizes all parties in the supply chain to actively participate in maintaining system security, fostering strong business cooperation and trust. A flexible interface authorization mechanism is provided, exposing only necessary interfaces for external use, reducing the risk of attack. In summary, this technical solution, through the comprehensive application of multiple security mechanisms, effectively prevents the risk of internal MCU chip program copying, improves system security and traceability, and incentivizes active participation and cooperation among all parties in the supply chain.

[0310] The above describes the method for preventing the internal program of the MCU chip from being copied in the embodiment of the present invention. The following describes the device for preventing the internal program of the MCU chip from being copied in the embodiment of the present invention. Figure 3In one embodiment of the present invention, an apparatus for preventing the internal program of an MCU chip from being copied comprises: a circuit module 301, which is used to utilize the inherent randomness of the hardware to generate a unique response key each time the MCU chip is powered on. This key is used to encrypt and decrypt the program inside the MCU chip, thereby increasing the security of the program and preventing unauthorized copying or access; an interface module 302, which is responsible for communicating with a preset blockchain platform to ensure the security and non-tamperability of the data, and to record the burning information of the MCU chip through the blockchain platform, including the MCU chip ID, timestamp, and number of burning times, and to use smart contracts to define verification rules and locking mechanisms; an encryption module 303, which uses a preset encryption algorithm to encrypt the program inside the MCU chip and uses P when the program needs to be executed. The unique response key generated by the UF circuit is decrypted to ensure that the program always exists in ciphertext when stored; the verification module 304 is responsible for handling the application and verification process of burning authorization. Before burning, the user needs to apply for authorization from the server through this module, submit the MCU chip ID information, and receive the authorization information returned by the server. Only after verifying that the authorization information is correct, the burning process will start to ensure that only authorized devices can burn the program; the verification module 305, before the program is executed, this module will verify the decrypted program to ensure that the program has not been illegally tampered with. Once illegal copying or tampering is found, it will trigger the locking mechanism to make the MCU chip unable to be used again, and record the ID and behavior information of the illegal MCU chip through the blockchain platform for subsequent tracking and processing.

[0311] In this embodiment of the present invention, a unique response key is generated and used for encryption and decryption each time the device is powered on, ensuring the high security of the program within the MCU chip. This dynamic key approach makes cracking the program more difficult. Using blockchain technology to record the MCU chip's programming information not only ensures the data's immutability but also provides a reliable audit trail, facilitating subsequent monitoring and verification of MCU chip usage. Defining validation rules and a lockout mechanism through smart contracts increases automation and transparency, ensuring that only devices meeting specific conditions are authorized for programming. The verification module ensures that only authorized devices can program, significantly reducing the risk of unauthorized copying or access. The verification module performs pre-program verification, effectively preventing illegal program tampering. It also triggers a lockout mechanism to respond to any illegal activity, protecting program integrity and the security of the MCU chip. Any illegal copying or tampering is recorded on the blockchain platform, facilitating the subsequent tracking of the ID and behavior of unauthorized MCU chips, further enhancing system security. In summary, this technology provides all-round protection for the internal programs of MCU chips by comprehensively using encryption technology, blockchain technology and smart contracts, effectively preventing the programs from being illegally copied or tampered with, and ensuring data security and system reliability.

[0312] above Figure 3 The apparatus for preventing the internal program of the MCU chip from being copied in the embodiment of the present invention is described in detail from the perspective of modular functional entities. The device for preventing the internal program of the MCU chip from being copied in the embodiment of the present invention is described in detail from the perspective of hardware processing.

[0313] Figure 4 : This is a structural diagram of a device for preventing the internal program of an MCU chip from being copied, provided by an embodiment of the present invention. The device 400 for preventing the internal program of an MCU chip from being copied may have relatively large differences due to different configurations or performances, and may include one or more processors (central processing units, CPU) 410 (for example, one or more processors) and a memory 420, and one or more storage media 430 (for example, one or more mass storage devices) for storing application programs 433 or data 432. Among them, the memory 420 and the storage medium 430 can be temporary storage or permanent storage. The program stored in the storage medium 430 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the device 400 for preventing the internal program of an MCU chip from being copied. Furthermore, the processor 410 may be configured to communicate with the storage medium 430 to execute a series of instruction operations in the storage medium 430 on the device 400 for preventing the internal program of an MCU chip from being copied.

[0314] The device 400 for preventing the internal program of the MCU chip from being copied may also include one or more power supplies 440, one or more wired or wireless network interfaces 450, one or more input and output interfaces 460, and / or one or more operating systems 431, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. It will be understood by those skilled in the art that Figure 4 The device structure for preventing the internal program of the MCU chip from being copied shown does not constitute a limitation on the device for preventing the internal program of the MCU chip from being copied, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0315] The present invention also provides a device for preventing the internal program of an MCU chip from being copied. The device for preventing the internal program of an MCU chip from being copied includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor executes the steps of the method for preventing the internal program of an MCU chip from being copied in the above-mentioned embodiments.

[0316] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. The computer-readable storage medium stores instructions. When the instructions are run on a computer, the computer executes the steps of the method for preventing the internal program of the MCU chip from being copied.

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

[0318] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., various media that can store program code.

[0319] The above-described embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit the present application; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those skilled in the art that the technical solutions recorded in the foregoing embodiments can still be modified, or some technical features thereof can be replaced by equivalent replacements; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for preventing the internal program of an MCU chip from being copied, characterized in that: include: During the MCU chip design phase, a PUF circuit is embedded into the MCU chip. Each time the MCU chip is powered on, the PUF circuit generates a unique response key based on the inherent randomness of the hardware. A blockchain platform is pre-set for MCU chip burning verification to ensure data security and non-tamperability. Smart contracts are deployed on the blockchain platform to record the burning information of the MCU chip, including the MCU chip ID, timestamp, and number of burns. Verification rules and locking mechanisms are also defined. An encryption algorithm is pre-set to encrypt the program inside the MCU chip and store the encrypted program in the MCU chip's Flash or ROM to ensure that the program exists in ciphertext form. Apply for programming authorization. Before programming, the user applies for authorization from the server and submits the MCU chip ID and other necessary information. The server verifies the validity of the MCU chip ID and whether the programming times have exceeded the limit by querying the blockchain platform records. Then, it generates authorization information. The server transmits the authorization information to the programming device through a secure channel. The programming device starts the programming process after verifying that the authorization information is correct. Decrypting the encrypted program according to the unique response key to obtain the decrypted program, and before executing the program, performing multiple checks on the decrypted program to ensure that the program has not been illegally tampered with, and obtaining verification information, the multiple checks including a timestamp check and a burn count check; The verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU chip will automatically trigger the locking mechanism, making the MCU chip unable to be used again. The ID and behavior information of the illegal MCU chip will be recorded through the blockchain platform for subsequent tracking and processing.

2. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: During the MCU chip design phase, a PUF circuit is embedded into the MCU chip. The PUF circuit generates a unique response key based on the inherent randomness of the hardware, including: Select a PUF type, including SRAM PUF, Ring Oscillator PUF, or Delay PUF. Based on the selected PUF type, design a PUF circuit that can capture and utilize hardware-inherent randomness, such as transistor non-uniformity and slight differences in resistance. During the MCU chip design phase, integrate the PUF circuit into the MCU chip as a security module. When the MCU chip starts up, it collects input data, including the current timestamp, device serial number, and ambient temperature. The collected input data is input into the PUF circuit, which uses the inherent randomness of the hardware to generate a unique response key. and / or design a dynamic challenge-response mechanism where the input data also includes the user’s biometric information; Each time the MCU chip starts, a new unique response key is generated based on the new input data and the PUF circuit, preventing the key from being used for a long time and increasing the risk of being cracked.

3. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: The blockchain platform for MCU chip burning verification is preset to ensure data security and non-tamperability. Smart contracts are deployed on the blockchain platform to record the burning information of the MCU chip, including the MCU chip ID, timestamp, and number of burns. Verification rules and locking mechanisms are defined, and an encryption algorithm is preset to encrypt the program inside the MCU chip. The encrypted program is stored in the Flash or ROM of the MCU chip to ensure that the program exists in ciphertext form, including: Choose blockchain platform technology, select a blockchain platform, including Ethereum, that supports the deployment of smart contracts, build a private or consortium blockchain network, and ensure network security and performance; A smart contract is deployed on the blockchain platform to record MCU chip programming information. The smart contract has the function of recording the MCU chip ID, timestamp, and programming count. In the smart contract, verification rules are preset. The verification rules include checking the rationality of the programming count and defining a lock mechanism. When abnormal programming behavior is detected, the lock mechanism can be automatically triggered to prevent further programming operations. Based on the smart contract of the blockchain platform, dynamic burning permission management is realized. Only authorized entities can perform burning operations, and each burning operation requires permission verification through the smart contract; Select an encryption algorithm. Encryption algorithms include AES or RSA, which are used to encrypt the program inside the MCU chip. After the MCU chip program is developed, the encryption algorithm is used to encrypt the program. The encrypted program is stored in the Flash or ROM of the MCU chip in ciphertext form, ensuring that even if an attacker has physical access to the MCU chip, they cannot directly read or copy the decrypted program.

4. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: To apply for programming authorization, the user applies for authorization from the server before programming, submitting the MCU chip ID and other necessary information. The server verifies the validity of the MCU chip ID and whether the programming times have exceeded the limit by querying the blockchain platform records, and then generates authorization information. The server transmits the authorization information to the programming device through a secure channel. After verifying that the authorization information is correct, the programming process begins, including: Before burning, the user submits a burning authorization application to the server through the burning device. The application includes the MCU chip ID, the program version to be burned, and the necessary information for burning device identification; After receiving the application, the server first verifies the historical programming information and validity of the MCU chip ID by querying the blockchain platform records. The server checks whether the programming times of the MCU chip have reached the preset upper limit. If the MCU chip ID is valid and the programming times are within the limit, the server generates an authorization information containing a timestamp, validity period, MCU chip ID, program version number, and authorization signature. And / or implement a multi-level authorization mechanism that requires joint authorization from multiple administrators or departments to perform burning; And / or implement a physical locking mechanism on the burning device, using Flash or ROM to store and manage keys and authorization information; The server transmits the authorization information to the burning device via the HTTPS communication protocol and / or uses TLS encryption to ensure data security during transmission; After receiving the authorization information, the burning device first verifies the validity of the authorization signature to ensure that the authorization information has not been tampered with. After the verification is passed, the burning device will check whether the timestamp, validity period, MCU chip ID, program version number and authorization signature in the authorization information are consistent with the information submitted during the application; After all verification steps are successful, the burning device starts burning the program into the MCU chip; After the burning is completed, the burning device will send a confirmation message to the server so that the server can update the burning record on the blockchain platform; Set up an early warning mechanism to immediately trigger an alarm and notify relevant personnel when abnormal burning requests or unauthorized burning attempts are detected.

5. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: The encrypted program is decrypted based on the unique response key to obtain a decrypted program. Before the program is executed, multiple checks are performed based on the decrypted program to ensure that the program has not been illegally tampered with, and verification information is obtained, including: Decrypt the encrypted program stored in the MCU chip using the unique response key previously generated by the PUF circuit; After the program is decrypted, first extract the timestamp information in the program, obtain the current time, and compare it with the timestamp in the program; The program contains a field that records the number of burn times. Each time the program is burned into the MCU chip, the field is incremented. Before the program is executed, the value of the field is checked to see if it exceeds the preset maximum number of burn times. Before the program is encrypted, the hash value of the program is calculated and stored in a secure area. After decryption, the hash value of the program is recalculated and compared with the stored hash value. Use the private key to sign the original program and store the signature information in a secure area. Before the program is executed, use the public key to verify the validity of the signature. Dynamically adjust the timestamp verification and programming times verification thresholds based on the MCU chip's usage and environment. If the MCU chip has not been used for a long time, relax the timestamp verification threshold. Get verification information.

6. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: The verification result is determined based on the verification information. Once illegal copying or tampering is found, the MCU chip will automatically trigger a lock mechanism, making the MCU chip unusable again. The ID and behavior information of the illegal MCU chip will be recorded through the blockchain platform for subsequent tracking and processing, including: After obtaining the verification information, the MCU chip compares it with the preset range, checks whether the MCU chip ID matches the recorded legal ID, checks whether the number of burn times exceeds the preset maximum value, and verifies the validity of the timestamp, hash value or signature; Once any illegal copying or tampering is detected, including MCU chip ID mismatch or exceeding the programming times limit, the MCU chip will immediately trigger a built-in lock command; And / or the MCU chip reads the stored data from the Flash or ROM and performs encryption calculations every time it is powered on, and compares the calculation results with the processed data read from the serial port. If the data are inconsistent, the MCU chip will directly trigger the lock command; The lock command is a hardware-level fuse mechanism that permanently disables the key functions of the MCU chip by physical means, making it unusable again; When the MCU chip triggers the lock command, a digital certificate containing the illegal MCU chip ID, behavior information and the reason for the verification failure will be generated. The digital certificate will be encrypted and signed. The MCU chip or the server communicating with it will upload the encrypted digital certificate to the blockchain platform. The blockchain platform provides a record system for storing and verifying these certificates.

7. The method for preventing the internal program of an MCU chip from being copied according to claim 1, wherein: Also includes: Establish a reputation system based on the blockchain platform to score and rank all parties in the supply chain, and adjust their reputation scores based on their performance in dealing with illegal MCU chip issues.

8. A device for preventing the internal program of an MCU chip from being copied, characterized in that: The device for preventing the internal program of the MCU chip from being copied includes: The circuit module is used to use the inherent randomness of the hardware to generate a unique response key each time the MCU chip is powered on. This key is used to encrypt and decrypt programs inside the MCU chip, increasing program security and preventing unauthorized copying or access. The interface module is responsible for communicating with the preset blockchain platform to ensure data security and non-tamperability. Through the blockchain platform, it records the MCU chip burning information, including the MCU chip ID, timestamp, and burning times, and uses smart contracts to define verification rules and locking mechanisms; The encryption module encrypts the program inside the MCU chip using a preset encryption algorithm and decrypts it using the unique response key generated by the PUF circuit when the program needs to be executed, ensuring that the program is always stored in ciphertext form; The verification module is responsible for handling the application and verification process of burning authorization. Before burning, the user needs to apply for authorization from the server through this module, submit the MCU chip ID information, and receive the authorization information returned by the server. The burning process will not start until the authorization information is verified to be correct, ensuring that only authorized devices can burn the program; Verification module: Before the program is executed, this module will perform multiple checks on the decrypted program, including timestamp verification and burn count verification, to ensure that the program has not been illegally tampered with. Once illegal copying or tampering is detected, it will trigger the locking mechanism, making the MCU chip unable to be used again, and record the ID and behavior information of the illegal MCU chip through the blockchain platform for subsequent tracking and processing.

9. A device for preventing the internal program of an MCU chip from being copied, characterized in that: The device for preventing the internal program of the MCU chip from being copied includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor calls the instruction in the memory so that the device for preventing the internal program of the MCU chip from being copied executes the method for preventing the internal program of the MCU chip from being copied as described in any one of claims 1-7.

10. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instruction is executed by the processor, the method for preventing the internal program of the MCU chip from being copied is implemented as described in any one of claims 1 to 7.

Images