Firmware updating method based on mixing of asymmetric encryption and symmetric encryption

Abstract

The invention discloses a firmware updating method based on mixing of asymmetric encryption and symmetric encryption. According to the invention, the security and compatibility are improved through a dual-signature mechanism. According to the method, two asymmetric algorithms, namely RSA and edDSA, are used at the same time to sign a firmware hash value, so that the risk caused by cracking of a single signature algorithm is avoided, and the authenticity and integrity of a firmware source are doubly guaranteed. The asymmetric encryption part is responsible for signature and verification, the security problem of key distribution is solved, and it is ensured that only firmware of a legal source can pass verification; the symmetric encryption part is used for efficiently encrypting and transmitting the upgrade package, so that the confidentiality of data is ensured, too high calculation burden cannot be brought to the embedded equipment, the balance between safety and performance is considered, seamless update is realized, the original version can be automatically returned when the update fails, the continuous and stable operation of the equipment is ensured, and the service life of the equipment is prolonged. And the system risk in the updating process is reduced.

Description

Technical Field

[0001] This invention belongs to the field of IoT firmware update technology, specifically a firmware update method based on a hybrid of asymmetric and symmetric encryption. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), smart manufacturing, connected vehicles, and various embedded devices, an increasing number of terminal devices require firmware updates to fix security vulnerabilities, add new features, or optimize system performance. The security and reliability of the firmware update mechanism directly affect the operational stability of the device and the overall security level of the system. Currently, commonly used firmware encryption protection schemes are mainly divided into two categories: (1) Firmware update method based on symmetric encryption. This method uses the same key to encrypt and decrypt the firmware, which has the advantages of fast encryption speed and low computational overhead, making it suitable for resource-constrained embedded devices. However, its disadvantage is that key distribution and management are difficult. Once the key is leaked, attackers can decrypt and tamper with the firmware, resulting in a significant decrease in system security.

[0003] (2) Firmware update method based on asymmetric encryption. This method uses a mechanism of public key encryption and private key decryption or signature verification, which effectively solves the key distribution security problem and can ensure the trustworthiness of the firmware source. However, asymmetric encryption algorithms (such as RSA and ECC) have high computational complexity and resource consumption, and are not suitable for directly encrypting and transmitting large-volume firmware data, which can easily lead to a decrease in update efficiency.

[0004] However, existing firmware update schemes present a trade-off between security and performance: symmetric encryption is efficient but insecure, while asymmetric encryption is secure but inefficient. Existing hybrid encryption firmware update schemes still suffer from complex key management processes, insufficient signature verification efficiency, and inadequate recovery mechanisms for update failures in practical applications. A firmware update mechanism that balances security, efficiency, and scalability has yet to be established.

[0005] Therefore, there is an urgent need for a firmware update method based on a hybrid of asymmetric and symmetric encryption, which can ensure the security and authenticity of firmware transmission while taking into account the computing resource limitations of embedded devices, thereby improving the overall reliability and execution efficiency of the update process. Summary of the Invention

[0006] The purpose of this invention is to provide a firmware update method based on a hybrid of asymmetric and symmetric encryption in order to solve the problems mentioned above.

[0007] The technical solution adopted in this invention is as follows: a firmware update method based on a hybrid of asymmetric and symmetric encryption, the method comprising the following steps: S1: Calculate a unique hash value for the original firmware image, and obtain the unique identifier and current timestamp of the target device. Combine the three into composite verification data of firmware hash value + device ID + timestamp, providing multi-dimensional binding basis for subsequent signing. S2: Use the RSA private key and the edDSA private key to digitally sign the composite verification data generated by S1, resulting in two sets of independent signature data. This mechanism, while retaining the security redundancy of dual signatures, prevents the abuse of upgrade packages across devices by binding device IDs and prevents replay attacks by timestamps, thus overcoming the limitations of traditional single hash signatures. S3: Combine the firmware body, the two sets of signature data in S2, the timestamp and device ID in the composite verification data, as well as the version information and verification fields into a complete upgrade package to ensure that all verification elements are closely related to the firmware content; S4: The upgrade package of S3 is encrypted using a symmetric encryption algorithm to generate an encrypted upgrade package; at the same time, the symmetric key is encrypted using the public key pre-stored in the device to form an encrypted key package. The two together constitute the data packet to be transmitted. S5: After receiving the data packet, the user-side upgrade program first uses the private key to decrypt the key packet to obtain the symmetric key, and then decrypts the upgrade packet; when transmitting via USB, each data block is accompanied by an ACK confirmation to ensure complete delivery to the target device; S6: The device security module extracts the signature and composite verification data from the upgrade package; first, it verifies the validity of the timestamp and the matching of the device ID, and then verifies the two sets of signatures using RSA and edDSA public keys; after all passes, the firmware is written to the backup partition. If the verification is successful, the primary partition is switched; if it fails, it automatically reverts to the original version.

[0008] In a preferred embodiment, in step S1, during the firmware composite verification data generation stage, the original firmware image is first hashed to obtain a hash value that uniquely identifies the firmware content, thereby ensuring the integrity and immutability of the firmware content; then, the unique identifier of the target device and the current timestamp are obtained, the former being used to bind the upgrade package to a specific device, and the latter being used to limit the effective time range of the upgrade package; finally, the firmware hash value, the device unique identifier, and the timestamp are combined to form composite verification data.

[0009] In a preferred embodiment, in step S2, composite verification data is first constructed to achieve device binding and replay protection. Specifically, the unique hash value H_firmware generated during the firmware preparation stage, the target device's unique hardware identifier DevID, and the current UTC timestamp T accurate to milliseconds are concatenated into a byte stream, and then a fixed-length composite verification data D is generated using the SHA-256 hash algorithm. For example, if H_firmware is a 32-byte SHA-256 result, DevID is a 16-byte device serial number, and T is an 8-byte timestamp. The concatenated byte stream is 56 bytes long, and after SHA-256 processing, it becomes 32 bytes of D. Then, D is signed using the RSA private key SK_RSA, and the RSA-PSS padding scheme is used to enhance collision resistance: first, D is encoded using EMSA-PSS to generate a message digest that conforms to the RSA modulus length, and then the SK_RSA is used to perform a modular exponentiation operation on the digest to finally obtain the RSA signature data S_RSA. In this process, the introduction of DevID ensures that the upgrade package can only be used by the specified device, while T prevents attackers from reusing old upgrade packages to launch replay attacks.

[0010] In a preferred embodiment, in step S2, the formula for generating composite verification data is: ; In the formula: H firmware The SHA-256 hash value of the firmware image, 32 bytes; DevID is a unique hardware identifier for the device, consisting of 16 bytes; T is the current UTC timestamp, 8 bytes; : This refers to byte stream concatenation operations; SHA-256: A secure hash algorithm that outputs 32 bytes; The RSA-PSS signature formula is: In the formula: S RSA The RSA signature data has a length consistent with the RSA modulus N. It is generated by performing a modular exponentiation operation on the encoded message digest using a private key and is used to verify the authenticity of the firmware source. SK RSA For an RSA private key, there is a modulus N and a private key exponent d, where the private key exponent d satisfies the following condition: Used to perform signature operations on the encoded message digest; EMSA-PSS-Encode is an RSA-PSS encoding function. It takes composite verification data D and salt length salt_len as input, and through steps such as generating random salt, concatenating hash, mask generation and padding, it outputs a message digest m that conforms to the length of RSA modulus N, thereby enhancing the signature's resistance to attacks. N is the RSA modulus, usually 2048 bits or 4096 bits, generated by the product of two large prime numbers. It is the basis of RSA modulo arithmetic, and the security of the signature depends on the difficulty of factoring N. D represents composite verification data, a 32-byte fixed-length byte array, composed of the firmware hash value H. firmware The device's unique identifier DevID and UTC timestamp T are concatenated and then hashed using SHA-256. This integrates multi-dimensional information to prevent firmware abuse and replay attacks. salt_len is the salt length, a non-negative integer, with a value of 32 bytes. It introduces randomness into EMSA-PSS encoding, improving resistance to collision attacks and chosen-plaintext attacks. m is the encoded message digest, and the length of the byte array is equal to the length of the RSA modulus N in bytes. It is generated by EMSA-PSS encoding and converts the short composite data D into an input format adapted for RSA modular exponentiation.

[0011] In a preferred embodiment, in step S2, the same composite verification data D is re-signed using the edDSA private key SK_edDSA, fully utilizing the high performance and quantum resistance of the edDSA algorithm. Taking the Ed25519 curve as an example, the signing process consists of three steps: First, the first 32 bytes of SK_edDSA are taken as seed k, concatenated with D, and then a 512-bit temporary value r is generated by SHA-512 hashing; second, the lower 256 bits of r are used as a scalar and multiplied by the base point G of the Ed25519 curve to obtain the point R on the elliptic curve; finally, the hash value h is calculated. =SHA-512(byte representation of R ||PK_edDSA||D), take the lower 256 bits of h as a scalar, multiply it with the first 32 bytes of SK_edDSA scalar, and add the lower 256 bits of r scalar. The result modulo the order l of the Ed25519 curve to get s. The final signature S_edDSA is composed of the byte representations of R and s. The dual signature mechanism not only retains the security redundancy of RSA and edDSA, but also solves the problem that traditional single hash signature cannot prevent cross-device abuse and replay attacks by introducing multi-dimensional data, which significantly improves the security and flexibility of signature verification. The signature formula for Ed25519 is: ; In the formula: S edDSA The signature data for Ed25519 is 64 bytes. k is the first 32 bytes of the seed in SK_edDSA; D: This is the composite verification data, 32 bytes; R is a temporary point on the elliptic curve, 32 bytes; G is the base point of the Ed25519 curve; PK edDSA Ed25519 public key, 32 bytes; h represents the lower 256 bits of the SHA-512 hash result; l is the order of the Ed25519 curve, and: ; • This refers to scalar multiplication of elliptic curves; modl is the modulo operation.

[0012] In a preferred embodiment, in step S3, during the firmware upgrade package construction phase, the compiled firmware main file is first obtained, which contains a pre-trained gain adjustment model and a runtime fine-tuning algorithm; then, two sets of signature data generated in phase S2 are extracted, one set being a digital signature of the firmware main file and the other a digital signature of the composite verification data; then, the real-time generated timestamp and the unique identifier of the target device are extracted from the composite verification data; simultaneously, the firmware version information, including the major version number and the minor version number, is prepared; then, the verification field of the entire content to be merged is calculated to ensure data integrity; the merging process is carried out in a fixed order, sequentially concatenating the firmware main file, the two sets of signature data, the timestamp, the device identifier, the version information, and the verification field into a complete byte stream.

[0013] In a preferred embodiment, in step S3, the merging operation must be performed in an encrypted production environment using a certified merging tool, and all data transmission must be conducted through a secure channel; the timestamp must be the real-time UTC time at the time of the merging operation, accurate to the second; the device identifier must be completely consistent with the target device, and the version information must strictly match the firmware version; the verification field must cover all the content after merging and be appended to the end of the upgrade package after generation; after the merging is completed, the system automatically verifies the correlation of each part, confirms that the signature data matches the corresponding content, the timestamp has not expired, the device identifier is correct, the version information is consistent, and the verification field is valid.

[0014] In a preferred embodiment, in step S4, during the efficient encryption of the upgrade package, the upgrade package containing the firmware body, signature data, and version verification information is first encrypted using a self-developed efficient symmetric encryption algorithm to generate an encrypted upgrade package. Next, to achieve secure distribution of the symmetric key, the symmetric key used for this encryption is encrypted using the public key pre-stored in the target embedded device to obtain an encrypted key package. Finally, the encrypted upgrade package and the encrypted key package are merged to form the data packet to be transmitted.

[0015] In a preferred embodiment, in step S5, after the user-end upgrade program receives the data packet sent by the server, it first uses the locally stored private key to decrypt the key packet to obtain the symmetric key used to encrypt the upgrade package. Then, the upgrade program uses this symmetric key to decrypt the encrypted upgrade package and restore the original firmware upgrade package content. Next, the upgrade program transmits the upgrade package to the target embedded device through the USB interface. During the transmission, the upgrade package is split into multiple data blocks. After each data block is sent, it waits for the device to return an ACK confirmation message. Only after receiving confirmation will the next data block be sent. If no confirmation is received or an error message is received, the data block is retransmitted.

[0016] In a preferred embodiment, in step S6, signature data and composite verification data are first extracted from the received upgrade package. Next, the validity of the timestamp is checked to confirm that the upgrade package has not expired. At the same time, the device ID is verified to ensure that it matches the current device, ensuring that the upgrade package is a legitimate update for this device. Subsequently, the security module uses the pre-stored RSA public key and edDSA public key to verify the corresponding signatures to confirm the authenticity and integrity of the firmware source.

[0017] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention enhances security and compatibility through a dual-signature mechanism. It simultaneously uses both RSA and edDSA asymmetric algorithms to sign the firmware hash value, avoiding the risk of a single signature algorithm being cracked, thus doubly guaranteeing the authenticity and integrity of the firmware's origin. The asymmetric encryption part handles signing and verification, solving the key distribution security problem and ensuring that only firmware from legitimate sources can pass verification; the symmetric encryption part efficiently encrypts and transmits the upgrade package, ensuring data confidentiality without placing excessive computational burden on the embedded device, achieving a balance between security and performance.

[0018] 2. This invention improves the reliability of the update process and user experience through a series of mechanisms. The ACK confirmation mechanism introduced during the transmission phase verifies and confirms each data block of the upgrade package, avoiding incomplete firmware or update failures due to communication anomalies. The device side uses a security chip or module for signature verification; the update is only executed after successful verification, effectively preventing the loading of unauthorized firmware. The A / B partition design used during the upgrade process allows the new firmware to be written to the backup partition first, and then switched to the primary partition after successful verification. This not only achieves seamless updates but also automatically reverts to the original version in case of update failure, ensuring continuous and stable device operation and reducing system risks during the update process. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the process principle of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0021] Example: Refer to Figure 1 A firmware update method based on a hybrid of asymmetric and symmetric encryption, comprising the following steps: S1: Firmware composite verification data generation. Calculate a unique hash value for the original firmware image, and simultaneously obtain the target device's unique identifier (such as serial number) and current timestamp. Combine these three into composite verification data consisting of firmware hash value + device ID + timestamp, providing multi-dimensional binding basis for subsequent signing.

[0022] S2: Multi-dimensional dual signature generation. The composite verification data generated in S1 is digitally signed using both RSA and edDSA private keys, resulting in two independent sets of signature data. This mechanism, while retaining the security redundancy of dual signatures, prevents cross-device abuse of upgrade packages through device ID binding and prevents replay attacks through timestamps, overcoming the limitations of traditional single hash signatures.

[0023] S3: Customized upgrade package integration. The firmware body, the two sets of signature data from S2, the timestamp and device ID from the composite verification data, as well as version information and verification fields are merged into a complete upgrade package, ensuring that all verification elements are closely related to the firmware content.

[0024] S4: High-efficiency encryption of the upgrade package. The upgrade package from S3 is encrypted using a symmetric encryption algorithm to generate an encrypted upgrade package; at the same time, the symmetric key is encrypted using the public key pre-stored in the device to form an encrypted key package. The two together constitute the data packet to be transmitted.

[0025] S5: Directed transmission and decryption. After receiving the data packet, the user-side upgrade program first uses its private key to decrypt the key packet to obtain the symmetric key, and then decrypts the upgrade packet; when transmitting via USB, each data block carries an ACK confirmation to ensure complete delivery to the target device.

[0026] S6: Multi-dimensional verification and A / B partition update. The device security module extracts the signature and composite verification data from the upgrade package; first, it verifies the validity of the timestamp and the matching of the device ID, and then verifies the two sets of signatures using RSA and edDSA public keys; after all verifications are successful, the firmware is written to the backup partition. If the verification is successful, the primary partition is switched; if it fails, the system automatically reverts to the original version.

[0027] In step S1, during the firmware composite verification data generation stage, the original firmware image is first hashed to obtain a hash value that uniquely identifies the firmware content, thus ensuring the integrity and immutability of the firmware content. Then, the unique identifier of the target device and the current timestamp are obtained; the former is used to bind the upgrade package to a specific device, and the latter is used to limit the valid time range of the upgrade package. Finally, the firmware hash value, the device's unique identifier, and the timestamp are combined to form composite verification data, providing multi-dimensional binding criteria for subsequent digital signatures. This ensures that the signature not only verifies the authenticity of the firmware itself but also guarantees that the upgrade package is a legitimate update request for the specified device and within its validity period.

[0028] In step S2, composite verification data is first constructed to achieve device binding and replay protection. Specifically, the unique hash value H_firmware generated during the firmware preparation stage, the target device's unique hardware identifier DevID (such as the serial number of an embedded chip), and the current UTC timestamp T accurate to milliseconds are concatenated into a byte stream, and then a fixed-length composite verification data D is generated using the SHA-256 hash algorithm. For example, if H_firmware is a 32-byte SHA-256 result, DevID is a 16-byte device serial number, and T is an 8-byte timestamp, then the length of the concatenated byte stream is 56 bytes, which becomes a 32-byte D after SHA-256 processing. Subsequently, D is signed using the RSA private key SK_RSA, and an RSA-PSS padding scheme is used to enhance collision resistance: D is first encoded using EMSA-PSS to generate a message digest that conforms to the RSA modulus length, and then SK_RSA is used to perform a modular exponentiation operation on the digest, finally obtaining the RSA signature data S_RSA. In this process, the introduction of DevID ensures that the upgrade package can only be used by the designated device, while T prevents attackers from reusing old upgrade packages to launch replay attacks.

[0029] In step S2, the formula for generating composite verification data is: ; In the formula: H firmware The SHA-256 hash value of the firmware image, 32 bytes; DevID is a unique identifier for device hardware, 16 bytes (such as chip serial number). T is the current UTC timestamp, 8 bytes (accurate to milliseconds); : This refers to byte stream concatenation operations; SHA-256: A secure hash algorithm that outputs 32 bytes; The RSA-PSS signature formula is: In the formula: S RSA The RSA signature data has a length consistent with the RSA modulus N. It is generated by performing a modular exponentiation operation on the encoded message digest using a private key and is used to verify the authenticity of the firmware source. SK RSA For an RSA private key, there is a modulus N and a private key exponent d, where the private key exponent d satisfies the following condition: Used to perform signature operations on the encoded message digest; EMSA-PSS-Encode is an RSA-PSS encoding function. It takes composite verification data D and salt length salt_len as input, and through steps such as generating random salt, concatenating hash, mask generation and padding, it outputs a message digest m that conforms to the length of RSA modulus N, thereby enhancing the signature's resistance to attacks. N is the RSA modulus, usually 2048 bits or 4096 bits, generated by the product of two large prime numbers. It is the basis of RSA modulo arithmetic, and the security of the signature depends on the difficulty of factoring N. D represents composite verification data, a 32-byte fixed-length byte array, composed of the firmware hash value H. firmware The device's unique identifier DevID and UTC timestamp T are concatenated and then hashed using SHA-256. This integrates multi-dimensional information to prevent firmware abuse and replay attacks. salt_len is the salt length, a non-negative integer, with a value of 32 bytes (consistent with the output length of SHA-256). It introduces randomness into EMSA-PSS encoding, improving resistance to collision attacks and chosen-plaintext attacks. m is the encoded message digest, and the length of the byte array is equal to the length of the RSA modulus N in bytes. It is generated by EMSA-PSS encoding and converts the short composite data D into an input format adapted to RSA modular exponentiation. In step S2, the same composite verification data D is re-signed using the edDSA private key SK_edDSA, fully utilizing the high performance and quantum resistance of the edDSA algorithm. Taking the Ed25519 curve as an example, the signing process consists of three steps: First, the first 32 bytes of SK_edDSA are taken as seed k, concatenated with D, and then hashed using SHA-512 to generate a 512-bit temporary value r; second, the lower 256 bits of r are multiplied by the base point G of the Ed25519 curve as a scalar to obtain the point R on the elliptic curve; finally, the hash value h = SHA-512 (byte representation of R ||PK_edDSA||D) is calculated, the lower 256 bits of h are taken as a scalar, multiplied by the first 32 bytes of SK_edDSA as a scalar, and then added to the lower 256 bits of r as a scalar. The result is modulo the order l of the Ed25519 curve to obtain s. The final signature S_edDSA consists of the byte representations of R and s. The dual-signature mechanism not only retains the security redundancy of RSA and edDSA, but also solves the problem that traditional single hash signatures cannot prevent cross-device abuse and replay attacks by introducing multi-dimensional data, which significantly improves the security and flexibility of signature verification.

[0030] The signature formula for Ed25519 is: ; In the formula: S edDSA The signature data for Ed25519 is 64 bytes (R occupies 32 bytes, s occupies 32 bytes). k is the first 32 bytes of the seed in SK_edDSA; D: This is the composite verification data, 32 bytes; R is a temporary point on the elliptic curve, 32 bytes; G is the base point of the Ed25519 curve; PK edDSA This is the Ed25519 public key, 32 bytes (generated from SK_edDSA). h represents the lower 256 bits of the SHA-512 hash result; l is the order of the Ed25519 curve, and: ; • This refers to scalar multiplication of elliptic curves; modl is the modulo operation.

[0031] In step S3, during the firmware upgrade package construction phase, the compiled firmware main file is first obtained. This file contains a pre-trained gain adjustment model and a runtime fine-tuning algorithm. Next, two sets of signature data generated in step S2 are extracted: one is a digital signature of the firmware main file, and the other is a digital signature of the composite verification data. Then, the real-time generated timestamp and the unique identifier of the target device are extracted from the composite verification data. Simultaneously, the firmware version information, including the major and minor version numbers, is prepared. Afterward, the verification field of the entire content to be merged is calculated to ensure data integrity. The merging process is performed in a fixed order, sequentially concatenating the firmware main file, the two sets of signature data, the timestamp, the device identifier, the version information, and the verification field into a complete byte stream.

[0032] In step S3, the merge operation must be performed in an encrypted production environment using a certified merge tool, with all data transmission conducted through a secure channel. The timestamp must be the real-time UTC time at the time of the merge operation, accurate to the second. The device identifier must be completely identical to the target device, and the version information must strictly match the firmware version. The verification field must cover all content after the merge and be appended to the end of the upgrade package. After the merge is complete, the system automatically verifies the correlation between each part, confirming that the signature data matches the corresponding content, the timestamp has not expired, the device identifier is correct, the version information is consistent, and the verification field is valid. The entire process must be executed continuously without any interruption or modification, ensuring that all verification elements in the upgrade package are closely related to the firmware content, forming an inseparable whole.

[0033] In step S4, during the efficient encryption of the upgrade package, a self-developed high-efficiency symmetric encryption algorithm is first used to encrypt the entire upgrade package, which contains the firmware body, signature data, and version verification information, generating an encrypted upgrade package. Next, to ensure secure distribution of the symmetric key, the symmetric key used for this encryption is encrypted using the public key pre-stored in the target embedded device, resulting in an encrypted key package. Finally, the encrypted upgrade package and the encrypted key package are merged to form a data packet to be transmitted, which is then sent to the user's upgrade program via the transmission channel. This entire process leverages the efficiency of symmetric encryption to encrypt large upgrade packages while ensuring the secure transmission of the symmetric key through an asymmetric encryption public-key mechanism, thus balancing encryption efficiency with key distribution security.

[0034] In step S5, after receiving the data packet from the server, the user-side upgrade program first uses its locally stored private key to decrypt the key packet within it, obtaining the symmetric key used to encrypt the upgrade package. Then, the upgrade program uses this symmetric key to decrypt the encrypted upgrade package, restoring the original firmware upgrade package content. Next, the upgrade program transmits the upgrade package to the target embedded device via the USB interface. During transmission, the upgrade package is split into multiple data blocks. After each data block is sent, the program waits for an ACK confirmation from the device. Only after receiving confirmation will the next data block be sent. If no confirmation is received or an error message is received, the data block is retransmitted. This ensures that all data blocks arrive completely at the target device, preventing incomplete upgrade packages or update failures due to communication anomalies.

[0035] In step S6, the signature data and composite verification data are first extracted from the received upgrade package. Next, the timestamp validity is checked to confirm the upgrade package has not expired, and the device ID is verified to match the current device, ensuring the upgrade package is a legitimate update for this device. Subsequently, the security module uses pre-stored RSA and edDSA public keys to verify the corresponding signatures, confirming the authenticity and integrity of the firmware source. Only after all verification steps are successfully completed will the system write the new firmware to the backup partition. After writing, the firmware in the backup partition is verified for integrity again. If the verification is successful, the primary partition is switched to the backup partition to enable the new firmware. If the verification fails or any abnormality occurs during the update process, the system will automatically revert to the original firmware version in the primary partition, ensuring the device can continue to operate normally without interruption.

[0036] This invention enhances security and compatibility through a dual-signature mechanism. It simultaneously uses both RSA and edDSA asymmetric algorithms to sign the firmware hash value, avoiding the risk of a single signature algorithm being cracked and providing dual protection for the authenticity and integrity of the firmware's origin. The asymmetric encryption part handles signing and verification, solving the key distribution security problem and ensuring that only firmware from legitimate sources can pass verification. The symmetric encryption part efficiently encrypts and transmits the upgrade package, ensuring data confidentiality without placing excessive computational burden on the embedded device, thus achieving a balance between security and performance.

[0037] This invention improves the reliability of the update process and user experience through a series of mechanisms. The ACK confirmation mechanism introduced during the transmission phase verifies and confirms each data block of the upgrade package, avoiding incomplete firmware or update failures due to communication anomalies. The device side uses a security chip or module for signature verification; the update is only executed after successful verification, effectively preventing the loading of unauthorized firmware. The A / B partition design used during the upgrade process allows the new firmware to be written to the backup partition first, and then switched to the primary partition after successful verification. This not only achieves seamless updates but also automatically reverts to the original version in case of update failure, ensuring continuous and stable device operation and reducing system risks during the update process.

[0038] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0039] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A firmware update method based on a hybrid of asymmetric and symmetric encryption, characterized in that: The method includes the following steps: S1: Calculate a unique hash value for the original firmware image, and obtain the unique identifier and current timestamp of the target device. Combine the three into composite verification data of firmware hash value + device ID + timestamp, providing multi-dimensional binding basis for subsequent signing. S2: Use the RSA private key and the edDSA private key to digitally sign the composite verification data generated by S1, resulting in two sets of independent signature data. This mechanism, while retaining the security redundancy of dual signatures, prevents the abuse of upgrade packages across devices by binding device IDs and prevents replay attacks by timestamps, thus overcoming the limitations of traditional single hash signatures. S3: Combine the firmware body, the two sets of signature data in S2, the timestamp and device ID in the composite verification data, as well as the version information and verification fields into a complete upgrade package to ensure that all verification elements are closely related to the firmware content; S4: The upgrade package of S3 is encrypted using a symmetric encryption algorithm to generate an encrypted upgrade package; at the same time, the symmetric key is encrypted using the public key pre-stored in the device to form an encrypted key package. The two together constitute the data packet to be transmitted. S5: After receiving the data packet, the user-side upgrade program first uses the private key to decrypt the key packet to obtain the symmetric key, and then decrypts the upgrade packet; when transmitting via USB, each data block is accompanied by an ACK confirmation to ensure complete delivery to the target device; S6: The device security module extracts the signature and composite verification data from the upgrade package; first, it verifies the validity of the timestamp and the matching of the device ID, and then verifies the two sets of signatures using RSA and edDSA public keys; after all passes, the firmware is written to the backup partition. If the verification is successful, the primary partition is switched; if it fails, it automatically reverts to the original version.

2. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S1, during the firmware composite verification data generation stage, the original firmware image is first hashed to obtain a hash value that uniquely identifies the firmware content, thereby ensuring the integrity and immutability of the firmware content. Subsequently, the unique identifier of the target device and the current timestamp are obtained. The former is used to bind the upgrade package to a specific device, and the latter is used to limit the effective time range of the upgrade package. Finally, the firmware hash value, the device unique identifier, and the timestamp are combined into composite verification data.

3. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S2, composite verification data is first constructed to achieve device binding and replay protection. Specifically, the unique hash value H_firmware generated during the firmware preparation stage, the target device's unique hardware identifier DevID, and the current UTC timestamp T accurate to milliseconds are concatenated into a byte stream, and then a fixed-length composite verification data D is generated using the SHA-256 hash algorithm. For example, if H_firmware is a 32-byte SHA-256 result, DevID is a 16-byte device serial number, and T is an 8-byte timestamp, then the concatenated data... The byte stream length is 56 bytes, which is processed by SHA-256 to obtain a 32-byte D. Then, D is signed using the RSA private key SK_RSA, and the RSA-PSS padding scheme is used to enhance collision resistance: first, D is encoded by EMSA-PSS to generate a message digest that conforms to the RSA modulus length, and then the SK_RSA is used to perform a modular exponentiation operation on the digest to finally obtain the RSA signature data S_RSA. In this process, the introduction of DevID ensures that the upgrade package can only be used by the specified device, while T prevents attackers from reusing old upgrade packages to launch replay attacks.

4. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S2, the formula for generating composite verification data is: ； In the formula: H firmware The SHA-256 hash value of the firmware image, 32 bytes; DevID is a unique hardware identifier for the device, consisting of 16 bytes; T is the current UTC timestamp, 8 bytes; : This refers to byte stream concatenation operations; SHA-256: A secure hash algorithm that outputs 32 bytes; The RSA-PSS signature formula is: In the formula: S RSA The RSA signature data has a length consistent with the RSA modulus N. It is generated by performing a modular exponentiation operation on the encoded message digest using a private key and is used to verify the authenticity of the firmware source. SK RSA For an RSA private key, there is a modulus N and a private key exponent d, where the private key exponent d satisfies the following condition: Used to perform signature operations on the encoded message digest; EMSA-PSS-Encode is an RSA-PSS encoding function. It takes composite verification data D and salt length salt_len as input, and through steps such as generating random salt, concatenating hash, mask generation and padding, it outputs a message digest m that conforms to the length of RSA modulus N, thereby enhancing the signature's resistance to attacks. N is the RSA modulus, usually 2048 bits or 4096 bits, generated by the product of two large prime numbers. It is the basis of RSA modulo arithmetic, and the security of the signature depends on the difficulty of factoring N. D represents composite verification data, a 32-byte fixed-length byte array, composed of the firmware hash value H. firmware The device's unique identifier DevID and UTC timestamp T are concatenated and then hashed using SHA-256. This integrates multi-dimensional information to prevent firmware abuse and replay attacks. salt_len is the salt length, a non-negative integer, with a value of 32 bytes. It introduces randomness into EMSA-PSS encoding, improving resistance to collision attacks and chosen-plaintext attacks. m is the encoded message digest, and the length of the byte array is equal to the length of the RSA modulus N in bytes. It is generated by EMSA-PSS encoding and converts the short composite data D into an input format adapted for RSA modular exponentiation.

5. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S2, the edDSA private key SK_edDSA is used to perform a secondary signature on the same composite verification data D, fully utilizing the high performance and quantum resistance of the edDSA algorithm. Taking the Ed25519 curve as an example, the signature process consists of three steps: First, the first 32 bytes of SK_edDSA are taken as the seed k, concatenated with D, and then hashed using SHA-512 to generate a 512-bit temporary value r; second, the lower 256 bits of r are used as a scalar and multiplied by the base point G of the Ed25519 curve to obtain the point R on the elliptic curve; finally, the hash value h = SHA-5 is calculated. 12 (byte representation of R ||PK_edDSA||D), take the lower 256 bits of h as a scalar, multiply it with the first 32 bytes of SK_edDSA scalar, and add the lower 256 bits of r scalar. The result modulo the order l of the Ed25519 curve to get s. The final signature S_edDSA is composed of the byte representations of R and s. The dual signature mechanism not only retains the security redundancy of RSA and edDSA, but also solves the problem that traditional single hash signature cannot prevent cross-device abuse and replay attacks by introducing multi-dimensional data, which significantly improves the security and flexibility of signature verification. The signature formula for Ed25519 is: ； In the formula: S edDSA The signature data for Ed25519 is 64 bytes. k is the first 32 bytes of the seed in SK_edDSA; D: This is the composite verification data, 32 bytes; R is a temporary point on the elliptic curve, 32 bytes; G is the base point of the Ed25519 curve; PK edDSA Ed25519 public key, 32 bytes; h represents the lower 256 bits of the SHA-512 hash result; l is the order of the Ed25519 curve, and: ； • This refers to scalar multiplication of elliptic curves; modl is the modulo operation.

6. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S3, during the firmware upgrade package construction phase, the compiled firmware main file is first obtained, which contains a pre-trained gain adjustment model and a runtime fine-tuning algorithm; then, the two sets of signature data generated in the S2 phase are extracted, one set being the digital signature of the firmware main file and the other set being the digital signature of the composite verification data. Then, extract the real-time generated timestamp and the target device's unique identifier from the composite verification data; at the same time, prepare the firmware version information, including the major version number and minor version number; then calculate the verification fields of the entire content to be merged to ensure data integrity. The merging process is carried out in a fixed order, sequentially concatenating the firmware body, two sets of signature data, timestamp, device identifier, version information, and verification field into a complete byte stream.

7. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S3, the merging operation must be performed in an encrypted production environment using a certified merging tool, and all data transmission must be conducted through a secure channel. The timestamp must be the real-time UTC time at the time of the merging operation, accurate to the second. The device identifier must be completely consistent with the target device, and the version information must strictly match the firmware version. The verification field must cover all the content after merging and be appended to the end of the upgrade package after generation. After the merging is completed, the system automatically verifies the correlation of each part, confirms that the signature data matches the corresponding content, the timestamp has not expired, the device identifier is correct, the version information is consistent, and the verification field is valid.

8. The firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S4, during the efficient encryption of the upgrade package, the upgrade package containing the firmware body, signature data, and version verification information is first encrypted using a self-developed efficient symmetric encryption algorithm to generate an encrypted upgrade package. Next, to achieve secure distribution of the symmetric key, the symmetric key used for this encryption is encrypted using the public key pre-stored in the target embedded device to obtain an encrypted key package. Finally, the encrypted upgrade package and the encrypted key package are merged to form the data packet to be transmitted.

9. A firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S5, after the user-end upgrade program receives the data packet sent by the server, it first uses the private key stored locally to decrypt the key packet in the packet and obtain the symmetric key used to encrypt the upgrade packet. Subsequently, the upgrade program uses this symmetric key to decrypt the encrypted upgrade package and restore the original firmware upgrade package content. Next, the upgrade program transmits the upgrade package to the target embedded device via the USB interface. During the transmission, the upgrade package is split into multiple data blocks. After each data block is sent, it waits for the device to return an ACK confirmation message. Only after receiving confirmation will the next data block be sent. If no confirmation is received or an error message is received, the data block will be resent.

10. A firmware update method based on a hybrid of asymmetric and symmetric encryption as described in claim 1, characterized in that: In step S6, firstly, signature data and composite verification data are extracted from the received upgrade package. Next, the validity of the timestamp is checked to confirm that the upgrade package has not expired. At the same time, the device ID is verified to ensure that it matches the current device, so as to ensure that the upgrade package is a legitimate update for this device. Subsequently, the security module uses pre-stored RSA and edDSA public keys to verify the corresponding signatures, confirming the authenticity and integrity of the firmware's origin.

Images