Method for preventing internal program of MCU from being copied

Abstract

The invention relates to the field of security encryption, and discloses a method for preventing an MCU internal program from being copied. Through the encryption scheme, a development company can effectively protect software and hardware research and development results, and a client is prevented from easily obtaining a program code through a grinding disc shoveling plate and the like under the unauthorized condition; the technical scheme adopted by the invention aims to reduce the cost of encryption protection, so that the encryption protection method is suitable for projects with various scales and costs, especially the fields of small household appliances with sensitive cost and the like; by combining various security technical means, such as a PUF circuit and a block chain platform, the invention aims to provide a more comprehensive and efficient security protection scheme to effectively resist illegal copying and tampering behaviors.

Description

Technical Field

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

[0002] With the continuous development of science and technology, microcontrollers (MCU) have become the core components of many electronic devices, especially in the fields of smart home and industrial automation. However, the program code stored in the MCU is often at risk of being illegally copied or tampered with, which not only infringes on the rights of developers, but also brings huge economic losses to enterprises. Especially after the development company delivers samples to customers, if the customer easily obtains the research and development results through low-cost means such as grinding and copying, the development company will not be able to receive the due balance, which seriously affects the normal operation and R&D enthusiasm of the enterprise.

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

[0004] High cost: Many encryption solutions rely on specific encryption chips, which are expensive and not suitable for some cost-sensitive projects. Especially in the field of small household appliances, due to the price limit of the product itself, the use of high-cost encryption chips will significantly increase product costs and reduce market competitiveness.

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

[0006] Limited ability to prevent copying: Despite the use of encryption chips, the cost of grinding and copying is getting lower and lower, and the technology is becoming more mature. The method of reading out the code and burning it with two chips at the same time may still be used to illegally obtain program code. In addition, with the development of technology, the cost of grinding has been 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 from being copied. Summary of the invention

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

[0009] The first aspect of the present invention provides a method for preventing an internal program of an MCU from being copied, and the method for preventing an internal program of an MCU from being copied comprises: in the MCU design stage, embedding a PUF circuit into a chip, and each time the MCU 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 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, the burning information including the chip ID, timestamp, and number of burning times, defining verification rules and a locking mechanism, presetting an encryption algorithm to encrypt the program inside the MCU, and storing the encrypted program in the Flash or ROM of the MCU to ensure that the program exists in ciphertext form; applying for burning authorization, Before burning, the user applies for authorization from the server and submits the chip ID and other necessary information. The server verifies the validity of the 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 checked according to the decrypted program to ensure that the program has not been illegally tampered with to obtain verification information; the verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU will automatically trigger the locking mechanism to make the chip unable to be used again. The ID and behavior information of the illegal 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 design phase, a PUF circuit is embedded into the chip, and the PUF circuit generates a unique response key based on the inherent randomness of the hardware, including: selecting a PUF type, the 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 the hardware inherent randomness such as the non-uniformity of transistors and the slight difference in resistance. The inherent randomness includes the non-uniformity of transistors and the slight difference in resistance. During the design stage of the MCU, the PUF circuit is integrated into the chip as a security module; collect input data, when the MCU is started, collect input data, the input data includes the current timestamp, device serial number, and ambient temperature, input the collected input data into the PUF circuit, and generate a unique response key using the inherent randomness of the hardware; and / or design a dynamic challenge-response mechanism, the input data also includes the user's biometric information; each time the MCU is started, generate a new unique response key 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; obtain a unique response key.

[0011] Optionally, in a second implementation of the first aspect of the present invention, a blockchain platform for MCU burning verification is preset to ensure the security and non-tamperability of data, and a smart contract is deployed on the blockchain platform to record the burning information of the MCU, the burning information includes a chip ID, a timestamp, and the number of burning times, and a verification rule and a locking mechanism are defined, and an encryption algorithm is preset to encrypt the program inside the MCU, and the encrypted program is stored in the Flash or ROM of the MCU 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 on the blockchain platform, and the smart contract has a function of recording chip ID, a time stamp, and a number of burning times. D. Timestamp and number of burning functions. In the smart contract, preset verification rules include checking the rationality of the number of burning and defining a locking mechanism. When abnormal burning behavior is detected, the locking mechanism 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. After the MCU program is developed, the preset encryption algorithm is used to encrypt the program. The encrypted program is stored in the Flash or ROM of the MCU in ciphertext form to ensure that even if the attacker has physical access to the MCU, 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, the user applies for authorization to the server before burning, submits the chip ID and other necessary information, the server verifies the validity of the 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, including: before burning, the user submits a burning authorization application to the server through the burning device, the application includes the 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 chip ID by querying the blockchain platform records, the server checks whether the number of burning times of the chip has reached a preset upper limit, if the chip ID is valid and the number of burning times is within the limit, the server generates an authorization information including a timestamp, validity period, chip ID, program version number and authorization signature; and / or implements multiple A multi-level authorization mechanism is implemented, which requires joint authorization from multiple administrators or departments to perform burning; and / or a physical locking mechanism is implemented 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 the transmission process; 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, 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 to burn the program into the MCU; 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; an early warning mechanism is set up, and when an abnormal burning request or unauthorized burning attempt is detected, an alarm is immediately triggered and relevant personnel are notified.

[0013] Optionally, in a fourth implementation of the first aspect of the present invention, the encrypted program is decrypted according to the unique response key to obtain the decrypted program, and before the program is executed, multiple checks are performed according to the decrypted program to ensure that the program has not been illegally tampered with, and verification information is obtained, including: decrypting with the response key, using the unique response key previously generated by the PUF circuit to decrypt the encrypted program stored in the MCU; the multiple checks include timestamp check and burn count check: after the program is decrypted, the timestamp information in the program is first extracted to obtain the current time and compare it with the timestamp in the program; the program contains a record of the burn count. The field of the number of times the program is burned to the MCU is incremented each time. Before the program is executed, check whether the value of this field exceeds the preset maximum number of times of burning. Before the program is encrypted, calculate the hash value of the program and store it in the secure area. After decryption, recalculate the hash value of the program 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. According to the usage and environment of the MCU, dynamically adjust the thresholds of the timestamp check and the number of times of burning check. If the MCU has not been used for a long time, relax the threshold of the timestamp check. Obtain verification information.

[0014] Optionally, in a 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 will automatically trigger a locking mechanism to prevent the chip from being used again, and record the ID and behavior information of the illegal chip through the blockchain platform for subsequent tracking and processing, including: after obtaining the verification information, the MCU compares it with a preset range, checks whether the chip ID matches the recorded legal ID, checks whether the number of burning times exceeds a preset maximum value, and verifies the validity of verification information such as timestamps, hash values, or signatures; once any illegal copying or tampering is found, including chip ID mismatch or excessive burning times, the MCU will immediately trigger a built-in locking command; and / or MCU will read the stored data from Flash or ROM and perform encryption calculation every time it is turned on, and compare the calculation result with the data read and processed from the serial port. If the data is inconsistent, the MCU will directly trigger the lock command; the lock command is a hardware-level fuse mechanism that permanently disables the key functions of the MCU by physical means, making it unusable again; when the MCU triggers the lock command, it will generate a digital certificate containing the illegal chip ID, behavior information and the reason for the verification failure. The digital certificate will be encrypted and signed, and the MCU 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 dealing with the problem of illegal 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, and 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 inside an MCU 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 is powered on, the key being used to encrypt and decrypt the program inside the MCU, 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 the security and non-tamperability of the data. Through the blockchain platform, the MCU's burning information, including chip ID, timestamp, and burning times, is recorded, and the verification rules and locking mechanism are defined using smart contracts;

[0018] The encryption module uses a preset encryption algorithm to encrypt the program inside the MCU, and uses the unique response key generated by the PUF circuit to decrypt it when the program needs to be executed, ensuring that the program always exists in ciphertext when stored;

[0019] Verification module is responsible for processing the application and verification process of burning authorization. Before burning, users need to apply for authorization from the server through this module, submit chip ID information, and receive authorization information returned by the server. Only after verifying that the authorization information is correct, the burning process will start, ensuring that only authorized devices can burn programs;

[0020] Verification module: 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 chip unable to be used again, and record the ID and behavior information of the illegal chip through the blockchain platform for subsequent tracking and processing.

[0021] The third aspect of the present invention provides a device for preventing MCU internal programs 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 MCU internal programs from being copied executes the above-mentioned method for preventing MCU internal programs from being copied.

[0022] A fourth aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the above-mentioned method for preventing the internal program of an MCU from being copied.

[0023] The technical solution provided by the present invention combines a physical unclonable function (PUF) circuit, blockchain technology, encryption algorithm, and a strict burning verification process. It includes embedding a PUF circuit in the MCU design stage to generate a unique response key, using the blockchain platform to ensure the security and non-tamperability of the data, recording the burning information of the MCU through a smart contract, and defining verification rules and locking mechanisms. 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 encryption program will perform multiple checks before decryption and execution to ensure that the program has not been illegally tampered with. Once illegal copying or tampering is found, the MCU will automatically trigger the locking mechanism and record the ID and behavior information of the illegal chip to the blockchain platform for subsequent tracking and processing.

[0024] Beneficial effects:

[0025] Fight against copying: There are some illegal acquisition and copying of .bin files on the market through grinding, etc. The present invention greatly increases the difficulty and risk of illegal copying through strict encryption, verification and locking mechanisms, thereby effectively fighting against such illegal activities and protecting the security and integrity of the original program.

[0026] Protecting the rights and interests of developers: Many projects that developers invest a lot of time and energy in the early stage are often easily taken over by customers at a low cost. The present invention protects the fruits of developers' labor by ensuring the security and non-replicability of the program, making it difficult for customers to easily obtain and copy the program, thereby safeguarding the legitimate rights and interests of developers.

[0027] Flexible application: This solution is not only suitable for personal or corporate use, but can also be securely shared with suppliers through burning. All data is verified through asymmetric encryption and timestamps to ensure the legitimacy of the data and security during transmission. This effectively prevents repeated attempts and illegal access through recording and replay, and provides a secure data exchange environment for both parties.

[0028] High customizability and adaptability: The hardware solution of the present invention ensures security through different password checks. Even if there is a risk of leakage, the manufacturer can be quickly contacted to change the .a file and password, making the illegally obtained program unusable. This high degree of customizability and adaptability enables the present invention to flexibly respond to various security threats and ensure the continuous security of the system.

[0029] In summary, the beneficial effects and advantages of the present invention are mainly reflected in combating illegal copying, protecting the rights and interests of developers, providing flexible application methods, and high customizability and adaptability. These advantages jointly ensure the security and integrity of the internal programs of the MCU, providing strong protection for developers and users. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A schematic diagram of an embodiment of a method for preventing an internal program of an MCU from being copied in an embodiment of the present invention;

[0031] Figure 2 A schematic diagram of another embodiment of a method for preventing an internal program of an MCU from being copied according to an embodiment of the present invention;

[0032] Figure 3 A schematic diagram of an embodiment of a device for preventing an internal program of an MCU from being copied in an embodiment of the present invention;

[0033] Figure 4 A schematic diagram of an embodiment of a device for preventing an internal program of an MCU from being copied in an embodiment of the present invention. DETAILED DESCRIPTION

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

[0035] For ease of understanding, the specific process of the embodiment of the present invention is described below. Figure 1 , an embodiment of the method for preventing the internal program of MCU from being copied in the embodiment of the present invention includes:

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

[0037] It is understandable that the execution subject of the present invention may be a device for preventing the internal program of the MCU from being copied, or may be 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 and generates a unique response key when powered on:

[0039] 1. MCU design stage

[0040] Designing PUF circuit:

[0041] During the MCU design phase, the PUF (Physical Unclonable Function) circuit is designed based on the physical characteristics of the chip (such as delay, threshold voltage change, 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] Integrate PUF circuit into MCU:

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

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

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

[0047] Power-on initialization:

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

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

[0050] PUF circuit challenge-response:

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

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

[0053] Example data:

[0054] We have a PUF circuit with 128 identical gates. Each gate has a different delay under the same input due to manufacturing differences. After the MCU is powered on, it sends a specific binary challenge signal: 1010110011010011. After the PUF circuit receives the challenge, each gate generates a delayed output based on the input signal and its own physical characteristics. The MCU measures and records the delay of each gate to obtain a delay sequence, for example (in nanoseconds): [2.3, 2.5, 2.4, 2.6, ...]; this delay sequence is unique and will be slightly different each time it is powered on due to physical randomness, but the overall pattern remains the same. The MCU converts this delay sequence into a unique response key through an algorithm (such as a hash function), for example: A5B3C7D9...

[0055] Key Application:

[0056] This unique response key can be used for encryption, decryption and verification of the MCU internal program. Since the key generated each time the power is turned on is unique, even if the attacker can obtain the key at a certain point in time, he cannot predict or copy the key at other points in time.

[0057] 102. Preset a blockchain platform for MCU burning verification to ensure data security and non-tamperability. Deploy smart contracts on the blockchain platform to record the burning information of the MCU, including chip ID, timestamp, and number of burning times. Define verification rules and locking mechanisms, preset encryption algorithms to encrypt the program inside the MCU, and store the encrypted program in the Flash or ROM of the MCU 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 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 burning verification system. Use the immutability and decentralization of blockchain to ensure the security and credibility of burning information.

[0062] Smart contract deployment:

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

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

[0065] 2. Burning information recording and verification rules

[0066] Burning information record:

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

[0068] Validation rules and locking mechanism:

[0069] The verification rules are defined in the smart contract, such as each MCU can only be burned 3 times at most. If the number of burn times of a certain MCU exceeds the limit, the contract will trigger the lock mechanism and prohibit the MCU from burning again.

[0070] Example data:

[0071] Chip ID: MCU001

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

[0073] Burn times: 2 times (for MCU001)

[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. Generate a key, such as KeyABC123, to encrypt and decrypt the program.

[0077] Program encryption:

[0078] Before burning the program to the MCU, 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] Store the encrypted program in the Flash or ROM of the MCU. Ensure that the program exists in the MCU in ciphertext form, making it more difficult to be copied and tampered with.

[0081] 103. Apply for burning authorization. Before burning, the user applies for authorization from the server and submits the chip ID and other necessary information. The server verifies the validity of the 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.

[0082] It should be noted that in the method of preventing the internal program of the MCU 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 first needs to submit an application to the authorization server through the burning device or dedicated software.

[0085] The information included in the application includes: chip ID (for example: UID-12345-ABC), expected burning time (for example: 2024-08-2618:00:00), and other necessary information of the user (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 chip ID "UID-12345-ABC" has a valid record on the blockchain, and the historical number of burns is 2 times (the maximum allowed number of burns is 5 times).

[0089] The server verifies that the number of times the chip ID has been burned is within the limit, and then generates an authorization message including a timestamp (e.g., 2024-08-2618:05:00), a randomly generated authorization code (e.g., AUTH-98765), and the 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 server sends the time), 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.

[0095] After the burning is completed, the burning device will send a confirmation message to the server, including the timestamp of successful burning and the 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 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 according to the unique response key to obtain a decrypted program, and before executing the program, perform multiple checks according to the decrypted program to ensure that the program has not been illegally tampered with, and obtain verification information;

[0101] It should be noted that the unique response key generated by PUF is used to decrypt and verify the encrypted program:

[0102] 1. Encryption Procedure and Key Generation

[0103] Encryption procedure:

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

[0105] PUF response key generation:

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

[0107] 2. Decryption Procedure

[0108] Key matching and decryption:

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

[0110] A part of the binary data of the encryption program is set to 10110010..., and after decryption using PUFKey123, a part of the data of the decryption program is obtained to be 01011010...

[0111] 3. Program Verification

[0112] Generate verification information:

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

[0114] A common verification method is to use a hash function (such as SHA-256) to calculate the decrypted program to 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 stores the correct hash value of the original program, OriginalHashXYZ.

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

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

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

[0121] Example data:

[0122] Original program: Binary data (partial)...11010101...

[0123] Default key: Key001

[0124] Encryption program: Binary data (part) 10110010... (after encryption)

[0125] PUF response key: PUFKey123

[0126] Decryption program: Binary data (part) 01011010... (after decryption)

[0127] Correct hash value: OriginalHashXYZ

[0128] Calculating hash value: HashValueABC

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

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

[0131] It should be noted that:

[0132] 1. Verification Information Judgment

[0133] Verification process:

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

[0135] Result judgment:

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

[0137] II. Handling of Illegal Behavior

[0138] Trigger the locking mechanism:

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

[0140] In this case, the deadlock mechanism is implemented by erasing critical configuration information stored internally and permanently locking the write function.

[0141] Recording illegal behavior:

[0142] When the locking mechanism is triggered, the MCU will send a record request containing the illegal 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 chip is set to ChipID456, and the behavior information includes the timestamp of the verification failure 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, it will record this information as a transaction on the blockchain.

[0146] The transaction contains the 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 chip ID: ChipID456

[0151] Verification failed timestamp: 2023-11-0115:30:00

[0152] In an embodiment of the present invention, a comprehensive method is provided for preventing the internal program of MCU from being copied. It combines a physical unclonable function (PUF) circuit, blockchain technology, encryption algorithm and verification mechanism to ensure the security and non-replicability of the MCU program. First, the PUF circuit is embedded in the MCU design stage, and a unique response key is generated each time the power is turned on. Secondly, the blockchain platform is used to record the burning information of the MCU, and the verification rules and locking mechanism are defined through smart contracts. Before burning, the user needs to apply for burning authorization from the server, and the server verifies the validity of the chip ID and the number of burning times and generates authorization information. The program is encrypted and stored in the MCU. After power-on, it is decrypted using the response key generated by the PUF, and a check is performed to ensure that the program has not been tampered with. Once illegal behavior is found, the MCU will trigger the locking mechanism and record relevant information through the blockchain platform. The unique response key generated by the PUF circuit ensures the uniqueness of the key each time the power is turned on, thereby greatly improving the security of the program. Even if an attacker can obtain the key at a certain point in time, it cannot predict or copy the key at other points in time. The tamper-proof nature of the blockchain platform is used to ensure the authenticity and credibility of the burning information and the record of illegal behavior. This helps to track and deal with illegal behavior in the future. The verification rules and locking mechanism defined by the smart contract limit the number of times each MCU is burned, preventing the risk of program leakage caused by excessive burning. During the verification process, once the program is found to be illegally copied or tampered with, the MCU will immediately trigger the locking mechanism, making the chip unable to be used again, thereby preventing illegal behavior in time. All related operations will leave an unalterable record on the blockchain platform, which greatly facilitates subsequent tracking and auditing. Combining multiple security mechanisms such as the physical layer, data encryption, and blockchain, it provides all-round protection for MCU internal programs. In summary, this technology provides strong security protection for MCU internal programs by combining PUF circuits, blockchains, encryption algorithms, and verification mechanisms, effectively preventing the risk of program copying and tampering, and improving the traceability of illegal behavior.

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

[0154] 201. During the MCU design phase, a PUF circuit is embedded into the chip. Each time the MCU 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, and the PUF type includes SRAM PUF, Ring Oscillator PUF or DelayPUF. Based on the selected PUF type, a PUF circuit is designed, which can capture and utilize the inherent randomness of hardware such as the non-uniformity of transistors and the slight difference in resistance. The inherent randomness includes the non-uniformity of transistors and the slight difference in resistance. In the design stage of MCU, the PUF circuit is integrated into the chip as a security module; input data is collected, and when the MCU is started, the input data includes the current timestamp, the device serial number, and the 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, and the input data also includes the user's biometric information; each time the MCU is started, 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; a unique response key is obtained;

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

[0157] Step 1: Design the SRAM PUF Circuit

[0158] During the design phase of the MCU, an SRAM PUF circuit was designed. This circuit is able to capture and utilize the non-uniformity of transistors and slight differences in resistance. Specifically, when the SRAM cell is initialized at power-on, each SRAM cell will have a different initial state (0 or 1) due to slight differences in hardware manufacturing. The randomness of this initial state can serve as a unique fingerprint for the device.

[0159] Step 2: Integrate PUF circuit into MCU

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

[0161] Step 3: Collect input data

[0162] When the MCU starts up, the system collects the following input data:

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

[0164] Device serial number: For example, SN123456789

[0165] Ambient temperature: For example, 25°C

[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 a response key

[0168] The collected data is input into the SRAM PUF circuit to generate a unique response key using the inherent randomness of the hardware. 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 boots 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, thus reducing the risk of being cracked.

[0172] For example, if the data collected by the MCU at 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℃

[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 burning verification to ensure data security and non-tamperability. Deploy smart contracts on the blockchain platform to record the burning information of the MCU, including chip ID, timestamp, and number of burning times. Define verification rules and locking mechanisms, preset encryption algorithms to encrypt the program inside the MCU, and store the encrypted program in the Flash or ROM of the MCU to ensure that the program exists in ciphertext form.

[0178] Specifically, a blockchain platform technology is selected, a blockchain platform is selected, the blockchain platform includes Ethereum, supports the deployment of smart contracts, and a private or alliance chain network is built to ensure the security and performance of the network; a smart contract for recording MCU burning information is deployed on the blockchain platform, the smart contract has the function of recording chip ID, timestamp, and number of burning times. In the smart contract, verification rules are preset, and the verification rules include checking the rationality of the number of burning times and defining a locking mechanism. When abnormal burning behavior is detected, the locking mechanism can be automatically triggered to prevent further burning operations; based on the smart contract of the blockchain platform, dynamic burning permission management is realized, and only authorized entities can perform burning operations, and each burning requires permission verification through the smart contract; preset encryption algorithms, select encryption algorithms, encryption algorithms include AES or RSA, which are used to encrypt the program inside the MCU. After the MCU 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 in ciphertext form to ensure that even if the attacker has physical access to the MCU, 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 in 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 named "MCU_BurnInfo". The main functions of this contract are:

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

[0185] Verify the rationality of the number of programming times. For example, if a chip is frequently programmed in a short period of time, the contract will consider it abnormal.

[0186] Define the lock mechanism. When abnormal burning behavior is detected (such as the number of burning times exceeds the preset threshold), the lock is automatically triggered.

[0187] Example data:

[0188] Chip ID: 0x1A2B3C

[0189] Timestamp:2023-10-2715: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 the burning permission. Before each burning, the "MCU_BurnInfo" contract needs to be used for permission verification.

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

[0194] The manufacturer chose the AES-256 encryption algorithm. After the MCU program was developed, they used this algorithm to encrypt the program.

[0195] Program example before encryption:

[0196]

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

[0198] 3a7b593475da4e37a0128921c93b8f5e...

[0199] Step 5: Store the encrypted program

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

[0201] Through the above embodiments, the MCU manufacturer successfully used blockchain technology and encryption algorithms to protect its core programs. Even if an attacker can physically access the MCU and try to read the contents of the Flash memory, they can only get the encrypted program and cannot directly obtain or copy the decrypted original program.

[0202] 203. Apply for burning authorization. Before burning, the user applies for authorization from the server and submits the chip ID and other necessary information. The server verifies the validity of the 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.

[0203] Specifically, before burning, the user submits a burning authorization application to the server through the burning device. The application includes the chip ID, the program version to be burned, and the necessary information for the burning device identification; after receiving the application, the server first verifies the historical burning information and validity of the chip ID by querying the blockchain platform records. The server checks whether the number of burns of the chip has reached the preset upper limit. If the chip ID is valid and the number of burns is within the limit, the server generates an authorization information including a timestamp, validity period, chip ID, program version number and authorization signature; and / or implements a multi-level authorization mechanism, which requires joint authorization from multiple administrators or departments to perform burning; and / or implements a physical locking mechanism on the burning device, using Flash or ROM to store and manage keys and authorization information; the server The authorization information is transmitted to the burning device through the HTTPS communication protocol, and / or TLS encryption is used to ensure data security during the transmission process; 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, 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 to burn the program into the MCU; 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;

[0204] It should be noted that:

[0205] Step 1: User submits burning authorization application

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

[0207] Chip ID: CID001

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

[0209] Burning equipment identification: BD001

[0210] Step 2: Server Authentication and Authorization

[0211] After receiving the application, the server queries the blockchain platform records and finds that the chip ID CID001 has been programmed twice, which does not reach the preset upper limit of 5 times. Therefore, the server generates authorization information:

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

[0213] Validity period: 2023-11-0111:00:00

[0214] Chip ID: CID001

[0215] Program version number: V1.2.0

[0216] Authorization signature: SIG_XYZ (signed with the server's private key)

[0217] Step 3: Server transmits authorization information

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

[0219] Step 4: Burn the device to verify the authorization information

[0220] 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 the verification is passed, check whether the data in the authorization information is consistent with the information submitted during the application.

[0221] Step 5: Burn the program into the MCU

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

[0223] Step 6: Confirmation of burning completion and record update

[0224] After the burning is completed, the burning device sends a confirmation message to the server. After receiving the confirmation, the server updates the burning record on the blockchain platform and increases the number of burning times of chip ID CID001 by 1 to 3 times.

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

[0226] During the process, if the server detects an abnormal burning request (such as the number of burning times exceeds the upper limit) or an unauthorized burning attempt, an alarm will be triggered immediately and the relevant personnel will be notified by email. For example, if an unauthorized device attempts to burn, the server will send an alarm email to the administrator, and the email content will contain the device ID, timestamp and other information of the attempter.

[0227] 204. Decrypt the encrypted program according to the unique response key to obtain a decrypted program, and before executing the program, perform multiple checks according to the decrypted program to ensure that the program has not been illegally tampered with, and obtain verification information;

[0228] 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; multiple checks include timestamp check and burning times check: after the program is decrypted, the timestamp information in the program is first extracted, the current time is obtained, and the current time is compared with the timestamp in the program; the program contains a field for recording the number of burning times, and the field is incremented each time the program is burned to the MCU. Before the program is executed, check whether the value of the field exceeds the preset maximum number of burning times; 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; according to the usage and environment of the MCU, the thresholds of the timestamp check and the burning times check are dynamically adjusted. If the MCU has not been used for a long time, the threshold of the timestamp check is relaxed; the verification information is obtained;

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

[0230] Step 1: Decrypt using the response key

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

[0232] Encryption program ciphertext: 0xE345A0B1C2D3...

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

[0234] Step 2: Timestamp verification

[0235] The timestamp information extracted from the decrypted program is: 2023-10-0112:00:00.

[0236] The current time is: 2023-10-0210:00:00.

[0237] 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.

[0238] Step 3: Check the number of times of burning

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

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

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

[0242] Step 4: Hash value verification

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

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

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

[0246] Step 5: Signature Verification

[0247] The original program is signed with the private key, and the signature information obtained is: SIG_ABC (stored in the secure area). Before the program is executed, the validity of the signature SIG_ABC is verified with the public key. The verification result is valid.

[0248] Step 6: Dynamically adjust the verification threshold

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

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

[0251] Specifically, after obtaining the verification information, the MCU compares it with the preset range, checks whether the chip ID matches the legal ID on record, checks whether the number of burn times 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 chip ID mismatch or burn times exceeding the limit, the MCU will immediately trigger a built-in lock command; and / or the MCU will read the stored data from the Flash or ROM and perform encryption calculations every time it is turned on, and compare the calculation results with the data read from the serial port and processed. If the data is inconsistent, the MCU will directly trigger the lock command; the lock command is a hardware-level fuse mechanism that physically and permanently disables the key functions of the MCU so that it cannot be used again; when the MCU triggers the lock command, it will generate a digital certificate containing the illegal chip ID, behavior information and the reason for the verification failure. The digital certificate will be encrypted and signed, and the MCU 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;

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

[0253] Step 1: MCU obtains verification information

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

[0255] Chip ID: CID001

[0256] Burn times: 4

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

[0258] Hash value: 0xAABBCCDDEEFF

[0259] Signature verification result: Valid

[0260] Step 2: Compare with preset range

[0261] The MCU compares these verification information with the preset range:

[0262] Check if the chip ID CID001 matches the legal ID on file: the match is successful.

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

[0264] Verify whether the timestamp 2023-11-0115:30:00 is within the valid range: Valid (set the current time to 2023-11-0116:00:00, and the timestamp verification threshold is 1 hour).

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

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

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

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

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

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

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

[0272] When the MCU triggers the lock command:

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

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

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

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

[0277] 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).

[0278] 206. 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 the illegal chip problem, thereby influencing future business cooperation and trust relationships;

[0279] 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 authorization times to the burning device;

[0280] It should be noted that:

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

[0282] 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.

[0283] Scoring Rules:

[0284] Discover and report illegal chip activities in a timely manner, and your reputation score will be +10.

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

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

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

[0288] Data example:

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

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

[0291] Step 2: Interface authorization mechanism

[0292] 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() and ProgramMCU().

[0293] Server Authorization:

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

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

[0296] Burning equipment verification and burning:

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

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

[0299] Data example:

[0300] Client C requests to program 100 MCUs. 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).

[0301] After receiving the authorization token, the burning device successfully verifies and starts burning. When burning to the 101st MCU, the burning device prompts "The number of burning times has exceeded the limit, please reapply for authorization."

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

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

[0304] Transparency and traceability: All reputation score changes and authorization records are stored on the blockchain to ensure data transparency and immutability.

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

[0306] In the embodiment of the present invention, a physical unclonable function (PUF), blockchain technology, encryption algorithm and authorization mechanism are used to build a multi-level security protection system to prevent the internal program of MCU from being copied. First, a unique response key is generated by using the PUF circuit to ensure that a new security key can be obtained each time the MCU is started, which increases the difficulty of cracking. Secondly, the security and traceability of the burning process are guaranteed by recording the burning information and implementing dynamic burning authority management through the blockchain platform. Furthermore, the program is encrypted using an encryption algorithm, and a multiple verification mechanism is used to ensure that the program has not been illegally tampered with. Finally, by establishing a reputation system based on blockchain, the parties in the supply chain are scored and ranked to encourage all parties to actively participate in maintaining the security of the system, and illegal access and copying are restricted through the interface authorization mechanism. The unique response key and encryption algorithm generated by the PUF circuit ensure the security of the internal program of the MCU, and even if the attacker has physical access to the MCU, he cannot directly read or copy the decrypted program. The use of the blockchain platform makes all burning information and authorization records traceable and tamper-proof, which is convenient for subsequent tracking and handling of illegal behavior. Through dynamic burning permission management and authorization of times, it is ensured that only authorized entities can perform burning operations, effectively preventing illegal copying. The reputation system based on blockchain encourages all parties in the supply chain to actively participate in maintaining system security and form good business cooperation and trust relationships through scoring and ranking mechanisms. It provides a flexible interface authorization mechanism, exposing only necessary interfaces for external use, reducing the risk of being attacked. In summary, this technical solution effectively prevents the risk of MCU internal programs being copied by comprehensively using multiple security mechanisms, improves the security and traceability of the system, and encourages the active participation and cooperation of all parties in the supply chain.

[0307] The above describes the method for preventing the internal program of the MCU from being copied in the embodiment of the present invention. The following describes the device for preventing the internal program of the MCU from being copied in the embodiment of the present invention. Figure 3In one embodiment of the present invention, a device for preventing the internal program of an MCU 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 is powered on. This key is used to encrypt and decrypt the program inside the MCU, 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 through the blockchain platform, including the chip ID, timestamp, and number of burning times, and to define the verification rules and locking mechanism using smart contracts; an encryption module 303, which uses a preset encryption algorithm to encrypt the program inside the MCU, and uses the PUF when the program needs to be executed. The unique response key generated by the circuit is decrypted to ensure that the program always exists in ciphertext when stored; the verification module 304 is responsible for processing 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 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 chip unable to be used again, and record the ID and behavior information of the illegal chip through the blockchain platform for subsequent tracking and processing.

[0308] In the embodiment of the present invention, by generating a unique response key and using this key for encryption and decryption each time the power is turned on, the high security of the program inside the MCU is ensured. This dynamic key method makes cracking more difficult. Using blockchain technology to record the burning information of the MCU not only ensures the immutability of the data, but also provides a reliable audit trail, which helps to monitor and verify the use of the chip in the future. The verification rules and locking mechanism are defined by smart contracts, which increases automation and transparency, ensuring that only devices that meet specific conditions can be authorized for burning. The verification module ensures that only authorized devices can burn the program, which greatly reduces the risk of unauthorized copying or access. The verification module verifies before the program is executed, effectively preventing the program from being illegally tampered with, and responds to any illegal behavior by triggering the locking mechanism, protecting the integrity of the program and the security of the chip. Any illegal copying or tampering will be recorded by the blockchain platform, which is convenient for subsequent tracking of the ID and behavior information of the illegal chip, further enhancing the security of the system. In summary, this technology provides all-round protection for MCU internal programs 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.

[0309] above Figure 3 The apparatus for preventing the internal program of the MCU 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 from being copied in the embodiment of the present invention is described in detail from the perspective of hardware processing.

[0310] Figure 4 4 is a schematic diagram of the structure of a device for preventing the internal program of MCU from being copied provided by an embodiment of the present invention. The device 400 for preventing the internal program of MCU 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) storing application programs 433 or data 432. Among them, the memory 420 and the storage medium 430 can be short-term 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 MCU 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 MCU from being copied.

[0311] The device 400 for preventing the internal program of the MCU 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 Serve, Mac OS X, Unix, Linux, FreeBSD, etc. It can be understood by those skilled in the art that Figure 4 The structure of the device for preventing the internal program of the MCU from being copied shown does not constitute a limitation on the device for preventing the internal program of the MCU from being copied, and may include more or less components than shown in the figure, or a combination of certain components, or a different arrangement of components.

[0312] The present invention also provides a device for preventing an internal program of an MCU from being copied. The device for preventing an internal program of an MCU from being copied comprises 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 an internal program of an MCU from being copied in the above-mentioned embodiments.

[0313] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions are executed on a computer, the computer executes the steps of the method for preventing the internal program of the MCU from being copied.

[0314] Those skilled in the art can 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.

[0315] 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, 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, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a 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), disk or optical disk, etc., various media that can store program codes.

[0316] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for preventing MCU internal programs from being copied, characterized in that: The method for preventing the internal program of the MCU from being copied comprises: During the MCU design phase, the PUF circuit is embedded into the chip. Each time the MCU is powered on, the PUF circuit generates a unique response key based on the inherent randomness of the hardware. A blockchain platform for MCU 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, including chip ID, timestamp, and number of burning times. Verification rules and locking mechanisms are defined, and encryption algorithms are preset to encrypt the program inside the MCU. The encrypted program is stored in the Flash or ROM of the MCU to ensure that the program exists in ciphertext form. Apply for burning authorization. Before burning, the user applies for authorization from the server and submits the chip ID and other necessary information. The server verifies the validity of the 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. Decrypting the encrypted program according to the unique response key to obtain a decrypted program, and before executing the program, performing multiple checks according to the decrypted program to ensure that the program has not been illegally tampered with, and obtaining verification information; The verification result is judged based on the verification information. Once illegal copying or tampering is found, the MCU will automatically trigger the locking mechanism to make the chip unable to be used again. The ID and behavior information of the illegal chip will be recorded through the blockchain platform for subsequent tracking and processing.

2. The method for preventing MCU internal programs from being copied according to claim 1, characterized in that: During the MCU design phase, a PUF circuit is embedded into the 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 the hardware inherent randomness such as the non-uniformity of transistors and the slight difference in resistance. The inherent randomness includes the non-uniformity of transistors and the slight difference in resistance. In the design stage of the MCU, integrate the PUF circuit into the chip as a security module. Collect input data. When the MCU starts, collect input data, including the current timestamp, device serial number, and ambient temperature. Input the collected input data into the PUF circuit and use 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 starts, 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; Get a unique response key.

3. The method for preventing MCU internal program from being copied according to claim 1, characterized in that: The method presets a blockchain platform for MCU burning verification to ensure the security and non-tamperability of data, deploys smart contracts on the blockchain platform to record the burning information of the MCU, including chip ID, timestamp, and number of burning times, and defines verification rules and locking mechanisms. The encryption algorithm is preset to encrypt the program inside the MCU, and the encrypted program is stored in the Flash or ROM of the MCU to ensure that the program exists in ciphertext, including: Choose blockchain platform technology, choose a blockchain platform, including Ethereum, support the deployment of smart contracts, build a private or consortium chain network, and ensure the security and performance of the network; A smart contract for recording MCU burning information is deployed on the blockchain platform. The smart contract has the function of recording chip ID, timestamp, and burning times. In the smart contract, verification rules are preset. The verification rules include checking the rationality of the burning times and defining a locking mechanism. When abnormal burning behavior is detected, the locking mechanism 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 operation needs to be verified by the smart contract. Preset encryption algorithm, select the encryption algorithm, the encryption algorithm includes AES or RSA, which is used to encrypt the program inside the MCU. After the MCU program is developed, the preset encryption algorithm is used to encrypt the program; The encrypted program is stored in the MCU's Flash or ROM in ciphertext form, ensuring that even if an attacker has physical access to the MCU, the decrypted program cannot be directly read or copied.

4. The method for preventing MCU internal programs from being copied according to claim 1, characterized in that: The application for burning authorization, the user applies for authorization from the server before burning, submits the chip ID and other necessary information, the server verifies the validity of the chip ID and whether the burning times exceed 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. After verifying that the authorization information is correct, the burning device starts the burning process, including: Before burning, the user submits a burning authorization application to the server through the burning device. The application contains the 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 burning information and validity of the chip ID by querying the blockchain platform records. The server checks whether the number of burning times of the chip has reached the preset upper limit. If the chip ID is valid and the number of burning times is within the limit, the server generates an authorization information containing a timestamp, validity period, 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 the transmission process; 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, 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; After the burning is completed, the burning device will send a confirmation message of the burning completion 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 MCU internal program from being copied according to claim 1, characterized in that: The encrypted program is decrypted according to the unique response key to obtain the decrypted program, and before the program is executed, multiple checks are performed according to the decrypted program to ensure that the program has not been illegally tampered with, and the verification information is obtained, including: Decryption using the response key, using the unique response key previously generated by the PUF circuit to decrypt the encrypted program stored in the MCU; Multiple checks include timestamp check and burn times check: 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 to record the number of times the program is burned. Each time the program is burned to the MCU, the field is incremented. Before the program is executed, check whether the value of the field exceeds the preset maximum number of times of burning; 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 check and programming times check thresholds based on the MCU usage and environment. If the MCU is not used for a long time, relax the timestamp check threshold. Get the verification information.

6. The method for preventing MCU internal program from being copied according to claim 1, characterized in that: The verification result is determined based on the verification information. Once illegal copying or tampering is found, the MCU will automatically trigger the locking mechanism to make the chip unusable again. The ID and behavior information of the illegal chip will be recorded through the blockchain platform for subsequent tracking and processing, including: After obtaining the verification information, the MCU compares it with the preset range, checks whether the chip ID matches the legal ID on record, checks whether the number of programming times exceeds the preset maximum value, and verifies the validity of verification information such as timestamp, hash value or signature; Once any illegal copying or tampering is detected, including chip ID mismatch or programming times exceeded, the MCU will immediately trigger a built-in lock command; And / or every time the MCU is powered on, it will read the stored data from the Flash or ROM, perform encryption calculations, and compare the calculation results with the processed data read from the serial port. If the data are inconsistent, the MCU will directly trigger a lock command; The lock command is a hardware-level fuse mechanism that physically and permanently disables the key functions of the MCU so that it cannot be used again; When the MCU triggers the lock command, a digital certificate containing the illegal chip ID, behavior information and the reason for the verification failure will be generated. The digital certificate will be encrypted and signed. The MCU 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 MCU internal program from being copied according to claim 1, characterized in that: 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 chips, thereby influencing future business cooperation and trust relationships; 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 authorizations to the burning device.

8. A device for preventing MCU internal programs from being copied, characterized in that: The device for preventing the internal program of the MCU from being copied comprises: A circuit module that uses the inherent randomness of the hardware to generate a unique response key each time the MCU is powered on. This key is used to encrypt and decrypt programs inside the MCU, increasing program security and preventing unauthorized copying or access. The interface module is responsible for communicating with the preset blockchain platform to ensure the security and non-tamperability of the data. Through the blockchain platform, the MCU's burning information, including chip ID, timestamp, and burning times, is recorded, and the verification rules and locking mechanism are defined using smart contracts; The encryption module uses a preset encryption algorithm to encrypt the program inside the MCU, and uses the unique response key generated by the PUF circuit to decrypt it when the program needs to be executed, ensuring that the program always exists in ciphertext when stored; Verification module is responsible for processing the application and verification process of burning authorization. Before burning, users need to apply for authorization from the server through this module, submit chip ID information, and receive authorization information returned by the server. Only after verifying that the authorization information is correct, the burning process will start, ensuring that only authorized devices can burn programs; Verification module: 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 chip unable to be used again, and record the ID and behavior information of the illegal chip through the blockchain platform for subsequent tracking and processing.

9. A device for preventing MCU internal programs from being copied, characterized in that: The device for preventing the internal program of the MCU from being copied comprises: 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 from being copied executes the method for preventing the internal program of the MCU 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 from being copied as described in any one of claims 1 to 7 is implemented.

Images