Encryption and decryption method and system for upgrade package of embedded device and embedded device

Abstract

The invention discloses an encryption and decryption method and system for an upgrade package of embedded equipment and the embedded equipment. The method comprises the following steps: constructing a packet header structure of the upgrade package; carrying out integral ARC4 encryption on the buffer area data block containing the local file header signature, and after all the data blocks are written, backfilling a header by using information read from the first source file, backfilling a packet header of the first output file according to a target offset address generated in a data block writing process, a first data area check value and a packet header check value obtained by calculation; and performing first verification on the identity information, the equipment model, the packet header length and the packet header verification value in sequence, decrypting the encrypted data block according to the target offset address and directly reading the unencrypted data block after the first verification is completely passed, and performing second verification by using the first data area verification value and the second data area verification value. The problems that the upgrade package may be tampered by a third party and reused by different embedded devices, and the security risk is large are solved.

Description

Technical Field

[0001] This invention relates to the field of embedded device upgrade package technology, and in particular to an encryption / decryption method, system, and embedded device for an embedded device upgrade package. Background Technology

[0002] Upgrade packages for existing embedded devices typically use simple plaintext transmission or symmetric encryption, making their contents vulnerable to interception, tampering, or forgery, and lacking effective security verification mechanisms. For example, some products only verify the file integrity of the upgrade package (such as CRC or MD5) without authenticating the source and content of the upgrade package, which could lead to malicious upgrade packages being accepted by the device, posing a security risk.

[0003] The current encryption and decryption verification mechanisms for upgrade packages in embedded devices are simple, lacking device-specific binding and strong identity authentication. This makes upgrade packages vulnerable to forgery or tampering by third parties, and devices cannot effectively verify the legitimacy of the upgrade packages. Upgrade packages for the same embedded device can be reused by different devices, making device-level upgrade authorization and traceability impossible. Once an upgrade package is leaked, all devices of the same model are at risk of attack, resulting in low security. Summary of the Invention

[0004] The existing encryption and decryption verification mechanisms for embedded device upgrade packages are simple and easily forged or tampered with by third parties. Embedded devices cannot effectively identify the legitimacy of upgrade packages, and upgrade packages for the same embedded device may be reused by different embedded devices. Device-level upgrade authorization and traceability cannot be achieved, resulting in significant security risks.

[0005] To address the aforementioned issues, this paper proposes an encryption / decryption method, system, and embedded device for embedded device upgrade packages. By constructing a header structure for the output file, the method embeds verification fields such as device identity, device model, version, data area checksum, encryption identifier, encryption offset, and header verification value. The buffer data block containing the local file header signature is then subjected to overall ARC4 encryption. After all data blocks are written, the header of the first output file is backfilled with all target offset addresses, the first data area checksum, and the calculated header verification value to obtain a second output file. Dual verification (first and second verification) is performed on the device side, thus preventing the upgrade package from being forged or tampered with by third parties. This solves the problem that upgrade packages for the same embedded device may be reused by different embedded devices, making device-level upgrade authorization and traceability impossible and posing significant security risks.

[0006] Firstly, a method for encrypting and decrypting an embedded device upgrade package includes: Step 100: Construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area check value field, encryption identifier field, encryption offset field, and header verification value field. Step 200: Obtain the source file information and first output file of the first source file of the upgrade package; initialize the data structure of the first output file; store the first source file into multiple buffers in sequence; read data blocks from the buffers in sequence; perform overall ARC4 encryption on the buffer data blocks containing the local file header signature; reserve space for the packet header using the write pointer; and write the encrypted and unencrypted data blocks into the data area of ​​the first output file in sequence; obtain the target offset address and first data area verification value of all encrypted data blocks; after all data blocks are written, use the information read from the first source file to backfill the packet header; and use the target offset address, first data area verification value, and calculated packet header verification value generated during the data block writing process to backfill the packet header of the first output file to obtain the encapsulated second output file. Step 300: After receiving the second output file, the target embedded device reads the header data of the second output file to obtain the embedded device's identity information, device model, header length, header verification value, and first data area verification value. It then performs a first verification on the identity information, device model, header length, and header verification value in sequence. After all the first verifications pass, it decrypts the encrypted data block according to the target offset address and directly reads the unencrypted data block. It also calculates and obtains the second data area verification value. The first data area verification value and the second data area verification value are used for a second verification. After the second verification passes, a second source file corresponding to the upgrade package of the target embedded device is obtained. The target embedded device is then upgraded using the second source file.

[0007] In conjunction with the encryption / decryption method for embedded device upgrade packages described in the first aspect of the present invention, in a first possible implementation, step 200 includes: Step 210: Call the signature detection unit to perform key signature detection on the currently read data block; Step 220: If the data block contains key signature information from the local file header, then determine the number of data blocks to be encrypted that contain key signature information; Step 230: If the number of data blocks to be encrypted containing key signature information does not exceed the specified number, then the currently read buffer data blocks are encrypted using ARC4 as a whole.

[0008] In conjunction with the first possible embodiment of the first aspect of the present invention, in the second possible embodiment, step 200 further includes: Step 240: When writing the encrypted data block into the data area of ​​the first output file, accumulate the offset value and record all target offset addresses; Step 250: When writing encrypted or unencrypted data blocks into the data area, accumulate the data area verification value to obtain the first data area verification value.

[0009] In conjunction with the second possible implementation of the first aspect of the present invention, in a third possible implementation, step 200 further includes: Step 260: After all data blocks have been written, the device identity information, packet header length information, device model information, version information, magic number information, and encryption identifier information read from the first source file are sequentially filled into the identity field, packet header length field, device model field, version field, magic number field, and encryption identifier field corresponding to the packet header structure of the first output file. Step 270: Fill the target offset address and the first data area verification value generated during the writing process back into the field corresponding to the packet header of the first output file, and accumulate the packet header verification value each time the packet header structure is filled; Step 280: Fill the accumulated header verification value back into the header verification value field corresponding to the header structure.

[0010] In conjunction with the encryption / decryption method for embedded device upgrade packages described in the first aspect of this invention, in a fifth possible implementation, step 300 includes: Step 310: Obtain the encrypted data blocks pointed to by all target offset addresses in the second output file; Step 320: Decrypt all encrypted data blocks pointed to by the target offset address using ARC4, and after decrypting the previous encrypted data block, increment the offset value to point to the next encrypted data block; Step 330: When reading the encrypted or unencrypted data block, the data area verification value is accumulated to obtain the second data area verification value.

[0011] In conjunction with the fifth possible implementation of the first aspect of the present invention, in the sixth possible implementation, step 300 further includes: Step 350: Compare and verify the second data area verification value with the first data area verification value; Step 360: If the verification passes, the second source file is decrypted; if the verification fails, the decryption fails.

[0012] Secondly, an encryption / decryption system for embedded device upgrade packages, employing the encryption / decryption method for embedded device upgrade packages described in the first aspect, includes: The construction module is used to construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area check value field, encryption identifier field, encryption offset field, and header verification value field. The encoding module is used to obtain the source file information and the first output file of the first source file of the upgrade package, initialize the data structure of the first output file, store the first source file into multiple buffers in sequence, read data blocks from the buffers in sequence, perform overall ARC4 encryption on the buffer data blocks containing the local file header signature, reserve space for the packet header using a write pointer and write the encrypted data blocks and unencrypted data blocks into the data area of ​​the first output file in sequence, obtain the target offset address and the first data area verification value of all encrypted data blocks, and after all data blocks are written, use the information read from the first source file to backfill the packet header, and use the target offset address, the first data area verification value and the calculated packet header verification value generated during the data block writing process to backfill the packet header of the first output file to obtain the encapsulated second output file; A decoding module, installed in the target embedded device, is used to read the header data of the second output file after the target embedded device receives the second output file, to obtain the embedded device's identity information, device model, header length, header checksum, and first data area checksum. The module then sequentially performs a first verification on the identity information, device model, header length, and header checksum. After all first verifications pass, the module decrypts the encrypted data block based on the target offset address and directly reads the unencrypted data block. It also calculates and obtains the second data area checksum, and performs a second verification using the first and second data area checksums. After the second verification passes, a second source file corresponding to the upgrade package for the target embedded device is obtained, and the target embedded device is upgraded using the second source file.

[0013] In conjunction with the encryption / decryption system for embedded device upgrade packages described in the second aspect of this invention, in a first possible implementation, the encoding module includes: The signature detection unit is used to perform key signature detection on the currently read data block. The encryption unit is used to perform overall ARC4 encryption on the currently read buffer data block if the number of data blocks to be encrypted containing key signature information does not exceed a specified number. The recording unit is used to accumulate offset values ​​and record all target offset addresses when an encrypted data block is written into the data area of ​​the first output file, accumulate data area verification values ​​and record the first data area verification value when an encrypted data block or an unencrypted data block is written into the data area, and accumulate packet header verification values ​​each time the packet header structure is filled, and record the accumulated packet header verification values. The data backfilling unit is used to backfill the target offset address and the first data area verification value into the field corresponding to the packet header of the first output file after all data blocks have been written, and to backfill the accumulated packet header verification value into the packet header verification value field corresponding to the packet header structure.

[0014] In conjunction with the encryption / decryption system for embedded device upgrade packages described in the second aspect of this invention, in a second possible implementation, the decoding module includes: The first verification unit is used to read the header data of the second output file after the target embedded device receives the second output file, and obtain the embedded device's identity information, device model, header length, header verification value and first data area verification value, and sequentially perform a first verification on the identity information, device model, header length and header verification value; The second verification unit is used to obtain the second data area verification value of the data area and perform a second verification using the first data area verification value and the second data area verification value.

[0015] Thirdly, an embedded device uses the encryption / decryption method of the embedded device upgrade package described in the first aspect to obtain an upgrade file and upgrade the device.

[0016] The embedded device upgrade package encryption and decryption method, system, and embedded device described in this invention construct an output file header structure and embed verification fields such as device identity, device model, version, data area checksum, encryption identifier, encryption offset, and header verification value into the header structure. The buffer data block containing the local file header signature is then subjected to overall ARC4 encryption. After all data blocks are written, all target offset addresses, the first data area checksum, and the calculated header verification value are used to backfill the header of the first output file to obtain a second output file. Dual verification (first and second verification) is performed on the device side, thereby preventing the upgrade package from being forged or tampered with by third parties. This solves the problem that upgrade packages for the same embedded device may be reused by different embedded devices, making device-level upgrade authorization and traceability impossible and posing significant security risks. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram illustrating a specific implementation of an encryption / decryption method for an embedded device upgrade package according to the present invention; Figure 2 for Figure 1 A schematic diagram of a specific implementation of step 200 in the diagram; Figure 3 for Figure 2 A schematic diagram of a specific implementation method following step 230; Figure 4 for Figure 3 A schematic diagram of a specific implementation method following step 250; Figure 5 for Figure 1 A schematic diagram of a specific implementation of step 300 in the process; Figure 6 for Figure 5 A schematic diagram of a specific implementation method following step 330; Figure 7 This is a schematic diagram of the encryption and decryption system for an embedded device upgrade package according to the present invention; Figure 8 This is a schematic diagram of the storage unit structure of an encryption / decryption system for an embedded device upgrade package according to the present invention; Figure 9 This is a schematic diagram of the output file structure of an encryption / decryption system for an embedded device upgrade package according to the present invention. Detailed Implementation

[0019] The technical solutions of this invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are all within the scope of protection of this invention.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings of this application are intended to cover non-exclusive inclusion.

[0022] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] The existing encryption and decryption verification mechanisms for embedded device upgrade packages are simple and easily forged or tampered with by third parties. Embedded devices cannot effectively identify the legitimacy of upgrade packages, and upgrade packages for the same embedded device may be reused by different embedded devices. Device-level upgrade authorization and traceability cannot be achieved, resulting in significant security risks.

[0024] To address the above issues, a method, system, and embedded device for encrypting and decrypting upgrade packages for embedded devices are proposed.

[0025] Firstly, a method for encrypting and decrypting an embedded device upgrade package, such as... Figure 1 , Figure 1 This is a schematic diagram illustrating a specific embodiment of an encryption / decryption method for an embedded device upgrade package according to the present invention; including: Step 100: Construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area checksum field, encryption identifier field, encryption offset field (LocalFileHeaderaddr[ENCRYPT_BLOCK_MAX]), and header checksum field.

[0026] In this embodiment, the identity identifier field (File_id[8]) is a fixed identifier for the package type, used to quickly identify the service type of the package and indicate the basic legality of the upgrade package, such as distinguishing between "firmware package / configuration package / data package". The device model field (product_id

[32] ) is used to accurately match the specific product / hardware model and avoid firmware flashing into incompatible products. The version field is used to indicate the package format version. The magic number field (magic_number) is a quick identification field to quickly perform binary identification and quickly filter non-target packages. The header length field (hdr_len) is used for data packet header length verification. The header verification value field (hdr_crc) is used to prevent the header from being tampered with. The data area verification value field (data_crc) is used to verify whether the data area has been tampered with during decoding.

[0027] Step 200: Obtain the source file information of the first source file (fp_s1) and the first output file (fp_t1) of the upgrade package; initialize the data structure of the first output file; and store the first source file sequentially into multiple buffers, such as... Figure 8 and Figure 9 , Figure 8 This is a schematic diagram of the storage unit structure of an encryption / decryption system for an embedded device upgrade package according to the present invention. Figure 9 This is a schematic diagram of the output file structure of an encryption / decryption system for an embedded device upgrade package according to the present invention. Data blocks are read sequentially from the buffer. The buffer data block containing the local file header signature is encrypted using ARC4. Space is reserved for the packet header using a write pointer, and encrypted and unencrypted data blocks are sequentially written to the data area of ​​the first output file. The target offset address and the first data area verification value of all encrypted data blocks are obtained. After all data blocks are written, the packet header is backfilled using information read from the first source file. The target offset address generated during the data block writing process, the first data area verification value, and the calculated packet header verification value are then used to backfill the packet header of the first output file, resulting in a packaged second output file. In this embodiment, the data structure of the first output file (the file to be output, fp_t1) is first initialized, its header structure is initialized, and version information is recorded.

[0028] In one possible implementation, such as Figure 2 , Figure 2 for Figure 1A schematic diagram of a specific implementation of step 200 is shown below; step 200 includes: step 210, calling the signature detection unit (AppCheckFileHeader(buf, bytes)) to perform key signature detection on the currently read data block; step 220, if the data block contains key signature information of the local file header, then judging the number of data blocks to be encrypted containing key signature information; step 230, if the number of data blocks to be encrypted containing key signature information does not exceed the specified number, then performing overall ARC4 encryption on the currently read buffer data block.

[0029] In this embodiment, a key signature detection is performed on the currently read data block to detect whether a ZIP local file header signature appears (detecting four-byte sequences 0x50 0x4B 0x03 0x04, directory records 0x50 0x4B 0x01 0x02, etc.). The number of data blocks to be encrypted is limited to 10; if more than 10 are included, they are ignored. A maximum of 10 target offset addresses (dstaddr) are also recorded in the encryption offset field of the packet header structure.

[0030] In one possible implementation, such as Figure 3 , Figure 3 for Figure 2 A schematic diagram of a specific implementation after step 230; step 200 also includes: step 240, when writing encrypted data blocks into the data area of ​​the first output file, accumulating offset values ​​and recording all target offset addresses; step 250, when writing encrypted data blocks or unencrypted data blocks into the data area, accumulating data area verification values ​​to obtain the first data area verification value.

[0031] In this embodiment, when writing data blocks to the data area of ​​the output file, space is first reserved for the packet header using a write pointer (data is written first, and the packet header is filled back last), and data is written starting from after the packet header. After writing encrypted data blocks, the offset value is accumulated, and the target offset address is recorded, pointing to the starting position of the next write. This is the core basis for recording the encrypted block offset. For unencrypted data blocks, they are written directly. Regardless of whether the data block is encrypted or unencrypted, the data area check value is accumulated to ensure that the data verification is consistent after depackaging.

[0032] In one possible implementation, such as Figure 4 , Figure 4 for Figure 3A schematic diagram of a specific implementation following step 250; step 200 further includes: step 260, after all data blocks are written, sequentially filling the device identity information, header length information, device model information, version information, magic number information, and encryption identifier information read from the first source file into the identity field, header length field, device model field, version field, magic number field, and encryption identifier field corresponding to the header structure of the first output file; step 270, filling the target offset address and first data area verification value generated during the writing process back into the fields corresponding to the header of the first output file, and accumulating the header verification value each time the header structure is filled; step 280, filling the accumulated header verification value back into the header verification value field corresponding to the header structure.

[0033] In this embodiment, the header of the first output file is backfilled. During decoding, the upgrade package is verified based on the header information: verifying whether the upgrade package is compatible with the current device, verifying whether the header structure has been tampered with, verifying the integrity of the header data, and verifying whether the data area has been tampered with, etc.

[0034] Step 300: After receiving the second output file, the target embedded device reads the header data of the second output file to obtain the embedded device's identity information, device model, header length, header check value, and first data area check value. The first verification is performed on the identity information, device model, header length, and header check value in sequence. After all the first verifications pass, the encrypted data block is decrypted according to the target offset address, and the unencrypted data block is read directly. The second data area check value is calculated and obtained. The second verification is performed using the first data area check value and the second data area check value. After the second verification passes, the second source file (fp_s2) of the upgrade package corresponding to the target embedded device is obtained. The target embedded device is upgraded using the second source file (fp_s2).

[0035] In one possible implementation, such as Figure 5 , Figure 5 for Figure 1 A schematic diagram of a specific implementation of step 300 is shown below; step 300 includes: step 310, obtaining all encrypted data blocks pointed to by target offset addresses in the second output file (fp_t2); step 320, performing ARC4 decryption on all encrypted data blocks pointed to by target offset addresses, and accumulating the offset value after decrypting the previous encrypted data block to point to the next encrypted data block; step 330, accumulating the data area verification value when reading encrypted or unencrypted data blocks to obtain the second data area verification value.

[0036] In this embodiment, during decoding, regardless of whether decryption is required, the data area check value must be accumulated for a second verification.

[0037] In one possible implementation, such as Figure 6 , Figure 6 for Figure 5 A schematic diagram of a specific implementation after step 330; step 300 further includes: step 350, comparing and verifying the second data area verification value with the first data area verification value; step 360, if the verification passes, the second source file (fp_s2) is decrypted; if the verification fails, the decryption fails.

[0038] In this embodiment, the second verification is used to verify the integrity of the entire data area. If there is an inconsistency, the data has been tampered with and the decryption will fail. The second verification ensures that the restored ZIP file is usable.

[0039] For example, for a ZIP file with a size of 100,000 (0x186A0) bytes, the header size sizeof(pkg_hdr) = 256. After the packaging process starts, the source file size is recorded: pkg_hdr.data_len = ftell(fp_s) = 100000. Then, the target write pointer is set to start from 256.

[0040] Upon reading the first buffer (offset source 0), at the target dstaddr = 256, byte 128 of the data block in this buffer contains 0x50 0x4B 0x03 0x04 (local file header). The current target offset address dstaddr = 256 (the address to write the encrypted data block corresponding to this buffer) is recorded. All bytes in this buffer are encrypted using ARC4 and then written out. CRC is accumulated. If a second local file header is found in a buffer at source offset 50000, corresponding to a target offset address of 50256, this buffer is encrypted, and the number of encrypted data blocks is incremented to 2. Each time a data block is written, the data area checksum is accumulated once. After writing all data, the first data area checksum CRC (e.g., 0xA1B2C3D4) and the header checksum hdr_crc are obtained, calculated using CRC32 and filled back into the corresponding fields of the header structure.

[0041] In this embodiment, by constructing the header structure of the output file, and embedding verification fields such as device identity field, device model field, version field, data area check value field, encryption identifier field, encryption offset field, and header verification value field into the header structure, the buffer data block containing the local file header signature is fully ARC4 encrypted. After all data blocks are written, the header of the first output file is backfilled with all target offset addresses, the first data area check value, and the calculated header check value to obtain the second output file. The device performs dual verification of the first and second verifications, thereby preventing the upgrade package from being forged or tampered with by third parties. This solves the problem that the upgrade package of the same embedded device may be reused by different embedded devices, making it impossible to achieve device-level upgrade authorization and traceability, resulting in high security risks.

[0042] Secondly, an encryption / decryption system for embedded device upgrade packages employs the encryption / decryption method for embedded device upgrade packages described in the first aspect, such as... Figure 7 , Figure 7 This is a schematic diagram of the encryption / decryption system for an embedded device upgrade package according to the present invention, comprising: Module 401 is used to construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area check value field, encryption identifier field, encryption offset field, and header check value field. Encoding module 402 is used to obtain the source file information and the first output file of the first source file of the upgrade package, initialize the data structure of the first output file, store the first source file into multiple buffers in sequence, read data blocks from the buffers in sequence, perform overall ARC4 encryption on the buffer data blocks containing the local file header signature, reserve space for the packet header using the write pointer and write the encrypted data blocks and unencrypted data blocks into the data area of ​​the first output file in sequence, obtain the target offset address and the first data area verification value of all encrypted data blocks, and after all data blocks are written, use the information read from the first source file to backfill the packet header, and use the target offset address, the first data area verification value and the calculated packet header verification value generated during the data block writing process to backfill the packet header of the first output file to obtain the encapsulated second output file; The decoding module 403, installed in the target embedded device, is used to read the header data of the second output file after the target embedded device receives the second output file, to obtain the embedded device's identity information, device model, header length, header check value, and first data area check value. It then performs a first verification on the identity information, device model, header length, and header check value in sequence. After all first verifications pass, it decrypts the encrypted data block according to the target offset address and directly reads the unencrypted data block, calculates and obtains the second data area check value, and performs a second verification using the first and second data area check values. After the second verification passes, it obtains the second source file of the upgrade package corresponding to the target embedded device, and uses the second source file to upgrade the target embedded device.

[0043] Furthermore, the encoding module 402 includes: The signature detection unit is used to perform key signature detection on the currently read data block. The encryption unit is used to perform overall ARC4 encryption on the currently read buffer data block if the number of data blocks to be encrypted containing key signature information does not exceed a specified number. The recording unit is used to accumulate offset values ​​and record all target offset addresses when encrypted data blocks are written to the data area of ​​the first output file; to accumulate data area verification values ​​and record the first data area verification value when encrypted or unencrypted data blocks are written to the data area; and to accumulate packet header verification values ​​and record the accumulated packet header verification values ​​each time the packet header structure is filled. The data backfilling unit is used to backfill the target offset address and the first data area check value into the field corresponding to the packet header of the first output file after all data blocks have been written, and to backfill the accumulated packet header check value into the packet header check value field corresponding to the packet header structure.

[0044] Thirdly, an embedded device uses the encryption / decryption method of the embedded device upgrade package in the first aspect to obtain the upgrade file and upgrade the device.

[0045] The embedded device upgrade package encryption and decryption method, system, and embedded device of this invention construct an output file header structure and embed verification fields such as device identity field, device model field, version field, data area check value field, encryption identifier field, encryption offset field, and header verification value field into the header structure. The buffer data block containing the local file header signature is encrypted using ARC4. After all data blocks are written, the header of the first output file is backfilled with all target offset addresses, the first data area check value, and the calculated header check value to obtain the second output file. Dual verification (first and second verification) is performed on the device side, thereby preventing the upgrade package from being forged or tampered with by third parties. This solves the problem that upgrade packages for the same embedded device may be reused by different embedded devices, making device-level upgrade authorization and traceability impossible and posing a significant security risk.

[0046] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for encryption and decryption of an embedded device upgrade package, characterized by, include: Step 100: Construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area check value field, encryption identifier field, encryption offset field, and header verification value field. Step 200: Obtain the source file information and first output file of the first source file of the upgrade package; initialize the data structure of the first output file; store the first source file into multiple buffers in sequence; read data blocks from the buffers in sequence; perform overall ARC4 encryption on the buffer data blocks containing the local file header signature; reserve space for the packet header using the write pointer; and write the encrypted and unencrypted data blocks into the data area of ​​the first output file in sequence; obtain the target offset address and first data area verification value of all encrypted data blocks; after all data blocks are written, use the information read from the first source file to backfill the packet header; and use the target offset address, first data area verification value, and calculated packet header verification value generated during the data block writing process to backfill the packet header of the first output file to obtain the encapsulated second output file. Step 300: After receiving the second output file, the target embedded device reads the header data of the second output file to obtain the embedded device's identity information, device model, header length, header verification value, and first data area verification value. It then performs a first verification on the identity information, device model, header length, and header verification value in sequence. After all the first verifications pass, it decrypts the encrypted data block according to the target offset address and directly reads the unencrypted data block. It also calculates and obtains the second data area verification value. The first data area verification value and the second data area verification value are used for a second verification. After the second verification passes, a second source file corresponding to the upgrade package of the target embedded device is obtained. The target embedded device is then upgraded using the second source file.

2. The method for encryption and decryption of the embedded device upgrade package according to claim 1, wherein, Step 200 includes: Step 210: Call the signature detection unit to perform key signature detection on the currently read data block; Step 220: If the data block contains key signature information from the local file header, then determine the number of data blocks to be encrypted that contain key signature information; Step 230: If the number of data blocks to be encrypted containing key signature information does not exceed the specified number, then the currently read buffer data blocks are encrypted using ARC4 as a whole.

3. The method for encryption and decryption of the embedded device upgrade package according to claim 2, characterized in that, Step 200 further includes: Step 240: When writing the encrypted data block into the data area of ​​the first output file, accumulate the offset value and record all target offset addresses; Step 250: When writing encrypted or unencrypted data blocks into the data area, accumulate the data area verification value to obtain the first data area verification value.

4. The method for encryption and decryption of the embedded device upgrade package according to claim 3, characterized in that, Step 200 further includes: Step 260: After all data blocks have been written, the device identity information, packet header length information, device model information, version information, magic number information, and encryption identifier information read from the first source file are sequentially filled into the identity field, packet header length field, device model field, version field, magic number field, and encryption identifier field corresponding to the packet header structure of the first output file. Step 270: Fill the target offset address and the first data area verification value generated during the writing process back into the field corresponding to the packet header of the first output file, and accumulate the packet header verification value each time the packet header structure is filled; Step 280: Fill the accumulated header verification value back into the header verification value field corresponding to the header structure.

5. The method for encryption and decryption of the embedded device upgrade package according to claim 1, wherein, Step 300 includes: Step 310: Obtain the encrypted data blocks pointed to by all target offset addresses in the second output file; Step 320: Decrypt all encrypted data blocks pointed to by the target offset address using ARC4, and after decrypting the previous encrypted data block, increment the offset value to point to the next encrypted data block; Step 330: When reading the encrypted or unencrypted data block, the data area verification value is accumulated to obtain the second data area verification value.

6. The method for encryption and decryption of the embedded device upgrade package according to claim 1, wherein, Step 300 further includes: Step 350: Compare and verify the second data area verification value with the first data area verification value; Step 360: If the verification passes, the second source file is decrypted; if the verification fails, the decryption fails.

7. A system for encrypting and decrypting an embedded device upgrade package, using the method for encrypting and decrypting an embedded device upgrade package according to any one of claims 1 to 6, characterized in that, include: The construction module is used to construct the header structure of the upgrade package. The header structure includes the target embedded device's identity field, header length field, device model field, version field, magic number field, data area length field, data area check value field, encryption identifier field, encryption offset field, and header verification value field. The encoding module is used to obtain the source file information and the first output file of the first source file of the upgrade package, initialize the data structure of the first output file, store the first source file into multiple buffers in sequence, read data blocks from the buffers in sequence, perform overall ARC4 encryption on the buffer data blocks containing the local file header signature, reserve space for the packet header using a write pointer and write the encrypted data blocks and unencrypted data blocks into the data area of ​​the first output file in sequence, obtain the target offset address and the first data area verification value of all encrypted data blocks, and after all data blocks are written, use the information read from the first source file to backfill the packet header, and use the target offset address, the first data area verification value and the calculated packet header verification value generated during the data block writing process to backfill the packet header of the first output file to obtain the encapsulated second output file; A decoding module, installed in the target embedded device, is used to read the header data of the second output file after the target embedded device receives the second output file, to obtain the embedded device's identity information, device model, header length, header checksum, and first data area checksum. The module then sequentially performs a first verification on the identity information, device model, header length, and header checksum. After all first verifications pass, the module decrypts the encrypted data block based on the target offset address and directly reads the unencrypted data block. It also calculates and obtains the second data area checksum, and performs a second verification using the first and second data area checksums. After the second verification passes, a second source file corresponding to the upgrade package for the target embedded device is obtained, and the target embedded device is upgraded using the second source file.

8. The encryption / decryption system for embedded device upgrade packages according to claim 7, characterized in that, The encoding module includes: The signature detection unit is used to perform key signature detection on the currently read data block. The encryption unit is used to perform overall ARC4 encryption on the currently read buffer data block if the number of data blocks to be encrypted containing key signature information does not exceed a specified number. The recording unit is used to accumulate offset values ​​and record all target offset addresses when an encrypted data block is written into the data area of ​​the first output file, accumulate data area verification values ​​and record the first data area verification value when an encrypted data block or an unencrypted data block is written into the data area, and accumulate packet header verification values ​​each time the packet header structure is filled, and record the accumulated packet header verification values. The data backfilling unit is used to backfill the target offset address and the first data area verification value into the field corresponding to the packet header of the first output file after all data blocks have been written, and to backfill the accumulated packet header verification value into the packet header verification value field corresponding to the packet header structure.

9. The encryption / decryption system for embedded device upgrade packages according to claim 7, characterized in that, The decoding module includes: The first verification unit is used to read the header data of the second output file after the target embedded device receives the second output file, and obtain the embedded device's identity information, device model, header length, header verification value and first data area verification value, and sequentially perform a first verification on the identity information, device model, header length and header verification value; The second verification unit is used to obtain the second data area verification value of the data area and perform a second verification using the first data area verification value and the second data area verification value.

10. An embedded device, characterized in that, The device is upgraded by using the encryption / decryption method of the embedded device upgrade package as described in any one of claims 1-6.

Images