Definition
Firmware Signature (firmware signature) digitally signs OTA firmware packages, verifying the signature before device upgrades to ensure the firmware source is trusted and not tampered with. Often used together with X.509 Certificate.
Signature Process
During the build stage, compute the hash of the firmware package (e.g., SHA-256), use the private key to sign the hash, and attach the signature to the firmware package or store it separately. The device preloads the public key or certificate; after downloading the firmware, it recalculates the hash and verifies the signature. Only if the verification passes can it be written to storage and the device rebooted. Use asymmetric encryption (e.g., RSA, ECDSA), with the private key kept by the build system and the public key preloaded on the device to prevent firmware from being forged or tampered with.
Integration with CI/CD
In the CI/CD pipeline, the signing step is automatically executed after the build is completed, with the private key managed by a key management system (e.g., HSM, Vault) to prevent leakage. When uploading firmware on the platform, signature validity can be verified, rejecting unsigned or invalidly signed packages. The device-side Bootloader or OTA client must implement signature verification logic to ensure upgrade security.
Security Best Practices
Private keys are strictly isolated and accessible only in the build environment; regularly rotate signing keys, and devices must support multi-certificate verification; both Full Package and Delta Package must be signed; consider supply chain security to prevent production line firmware from being replaced. Firmware signing is the foundational guarantee of FOTA security and is indispensable.
A signature attests to where the package came from
Firmware signing answers two questions: whether these bytes were produced by a build that holds the private key, and whether they were altered in transit or in temporary storage. The practice is to hash the content about to be written to the device, sign that hash with the private key, and have the device check it with a public key or certificate placed there in advance. Only then is the write and the boot switch allowed. A signature does not hide the firmware. If the content must stay secret, encrypt it separately. The two do not stand in for each other. The check has to cover the bytes the device actually writes. Signing a directory before compression while the device checks the image after it is unpacked, or signing only the header while the body can still be replaced, makes the check empty. A full package and a delta package each need their own signature. The baseline version a delta depends on should be inside the signed material, so a patch is not applied to the wrong old version. Refusing an unsigned upload on the platform only blocks the door. It does not replace the check the device makes before it boots.
What on-device verification requires
A device can verify a signature only if it already holds the right public key or certificate chain from the factory or from a trusted boot stage, and if that trust root cannot be quietly replaced by the firmware being upgraded. If certificate expiry takes part in the decision, a device clock that is far off will reject a valid package or accept an expired certificate, so there has to be a rule for when time cannot be trusted. The private key stays only in a controlled signing environment. An ordinary account on a build machine should not be able to export it. On rotation, the device must be able to tell "the old key may still verify packages already released, and the new key is for packages after this" from a single cut-off that leaves the field unable to upgrade at all. If the bootloader is part of the boot chain, its own update belongs in the same trust. Signing the application and not the bootloader leaves a way around it. When this is paired with an over-the-air update, the package hash registered on the platform should be the same input the signature used. Before an A/B partition switch, confirm again that the copy about to boot has already been verified.
When the signed file is not the file delivered
A common field failure is a version trailer appended after the package was built. The hash has changed, and the old signature is still attached. Checking a delta package with the signature of the full package, or checking unpacked content against the signature of the compressed package, fails, and the symptom looks like a damaged package. A package signed with a test key and sent to production devices fails the production public key, and the whole batch fails together. Turning verification off on production devices to make flashing easier, and then forgetting to turn it back on, means the signature scheme no longer exists. If the certificate subject is not bound to the product, a legitimate package from another product line is accepted by this device. Checking the signature only when the platform receives the upload, and not on the device, still allows the download path or a local cache to swap the package. A private key distributed with a script in the source repository no longer proves where a package came from. After rotation, updating the platform and not the trust anchor on the device rejects every new package. A release record should be able to recover the signature and the key identifier from the hash, so a later check can say which key a given upgrade used.