|This section describes the secure firmware update process in a TrustFence-enabled system. For a general overview the Digi Embedded Yocto firmware update mechanism, see Program firmware from U-Boot.|
A secure firmware update process involves more than safely updating a device. It also verifies that the delivered image is coming from a known source and that the image was not modified to introduce malware.
Secure firmware update is part of the TrustFence ecosystem and no further action is required to use it other than enabling TrustFence in your project. The resulting build artifacts for a TrustFence-enabled system will be ready to perform secure firmware updates. Follow the instructions in Program firmware from Linux to update a TrustFence-enabled system.
|For security reasons, secure firmware update is only supported on closed devices. It cannot be used on open devices. See Secure boot overview.|
Secure firmware update introduces two new security elements to the standard firmware update process:
File hash verification
Hash verification guarantees the integrity of the firmware update package. It ensures that the package contains the originally generated artifacts and it has not been altered.
During generation of the firmware update package, the cryptohash of each element that will be involved in the firmware update process (images, scripts, etc.) is calculated and stored in a firmware update description file inside the firmware update package. At installation time all package elements are extracted, and their hash is calculated and compared with the hashes stored in the description file. If any hash is different, the firmware update process is aborted, ensuring that all files are exactly the same as those included during generation of that particular firmware update package.
The hash verification ensures that the files included in the firmware update package match the expected values in the sw-update description file, and have not changed since they were generated at installation time. However, a third party could still create a custom package, modifying the sw-update description file to make the hashes match but adding undesired software to the update package.
To avoid this scenario, a signing/verification process establishes trust in the source of the update package itself. Since the firmware update description file included in the firmware update package already contains the hashes of all the package files, it makes sense to sign this file and include its signature in the package. When the firmware update takes places, the signature is verified using the secure boot SRK public key, which is available in the recovery partition on TrustFence-enabled systems. This means that only description files generated by a verified source can be accepted by the installer. If the description file is modified by external sources (for example to change the file hashes), the signature verification will fail and the installation process is aborted.
The private key used to sign the firmware update package is the same as the one used to sign the boot artifacts. This also means that the TRUSTFENCE_KEY_INDEX variable is used to obtain the correct signing key in the case of a key revocation. To verify the signed firmware update packages before installing them, the corresponding public key is copied into the recovery partition at the same time the TrustFence artifacts are generated.
|The secure firmware update mechanism relies on the TRUSTFENCE_SIGN variable. This setting is set to 1 by default after enabling TrustFence in your project} (INHERIT += "trustfence"). If you manually set this option to "0" in your project, you will also be disabling secure firmware updates.|