How Distributed Firmware Builds Can Be Protected Against Cyber Attacks
The XGuard Suite for IoT devices and automotive ECUs has several protection layers. One of these is allow-listing of executables via policies. The default usage scenario is that of automatic creation of such policies during the firmware build.
To enable third party providers to secure their software components with XGuard, and to allow for safe Over-the-Air updates of firmware (FOTA), Karamba Security designed a distributed, “remote” mechanism for protecting third-party software and firmware updates.
For example, one of Karamba’s clients, an Infotainment system developer, needed a secure way to receive updates from their maps provider – continual modifications to map data – in an authorized manner. This includes two aspects of protection:
- Self-Identification – Are the updates coming with the right credentials and cryptographic keys?
- Updates of the local allow-list policies – Which software elements are allowed to run?
Secure Remote Signing of Policies
All the tools required for secure remote signing are provided as a part of the XGuard Suite.
Although the XGuard tool for secure policy signing is generally used for remote signing, it can also be configured for secure local signing.
Each file to be allow-listed by XGuard, whether sourced in the main customer build or added later, including by third-party suppliers, must be specified using a policy that is signed with the same private key.
When required, a Remote Signing server can be set up to store a private key and use it for the allow-list policy signing procedure. The public key is sent to the build machine and ultimately placed on each device. Third-party suppliers use the Remote Signing server to sign XGuard allow-list policies, which are delivered along with their application files. XGuard supports adding multiple key pairs, allowing for assignment of dedicated keys to distinct third-party suppliers.
Communication with the remote signing server takes place over a secured channel.
Use of a Remote Signing server is illustrated in the integration flow diagram. The mechanism also includes the option of instrumenting the allowed third-party software with Control-Flow Integrity (CFI) protection – another of XGuard’s hardening layers.
Related Risks and Mitigations
Risk of Policy Signing with Private Key
An attacker holding the private key can create a new policy adding malicious programs to the allow list.
Mitigation/Countermeasures:
- The private key is stored on the Build server, and Build-server access is restricted.
- The private key is stored on a Remote Signing server, and it is used via remote policy signing.
Integration with commercial key-management tools is optional.
Risk of Policy Validation with Public Key
An attacker that can overwrite the public key during runtime may replace it with a different key that allows a fake policy to be trusted.
Mitigation/Countermeasures:
- The public key is stored as part of allow-list validation code, and write access to the relevant memory is prevented.
Where does HSM Fit In?
Use of an HSM (Hardware Security Module) for storage/access of the public key is not necessary, because there is no risk in the key being read, as long as it is not overwritten in program memory where it is used for policy validation (after extraction from storage). As it is added as part of the system code, the attacker cannot overwrite it offline due to image protection (e.g., boot verification), nor during runtime due to Karamba XGuard’s memory-access control.
Read more about the XGuard Suite on our web site.
