Mitigation-page

MID-040: Cryptographically Signed Custom Programs

Mitigation Tier: Intermediate

Description

For programmable devices like PLCs, signing programs gives the device the ability to ensure that the programs that they are installing and running originate from a verified source. If the programs are not signed, it may be possible for a threat actor to install malicious programs that alter device behavior.

Devices can enable these capabilities by allowing the device to accept, store, and use verifying keys to verify that a program is signed. If the program is not signed, the device should automatically reject the new program and send out an alert.

Users should be able to generate signing and verifying keys (public and private asymmetric keys) and send the verifying key to downstream devices that will be receiving programs. Programs can then be signed, either by Integrated Development Environments (IDEs) or another signing mechanism and distributed to the device for verification and deployment.

Note: This mitigation is heavily dependent on the security of the source of the programs/application. Many devices, such as PLCs, require the deployment of custom programs that are developed individually at each organization.

Limitation: This would require a dedicated signing key to be deployed within the IDE and a verifying key within the end device. Ideally this would be a unique signing key for every organization, however, this would require each organization to perform the key initialization and exchange with each new IDE or device. This scheme gets more complex as typically there are many IDEs within an organization that may need to deploy programs to a device, further organizations need to perform key escrow to store keys, otherwise if the IDEs and associated keys are lost, they will be unable to deploy programs to the device. If organizational keys are not used, and the same signing key is used across an entire product line, a threat actor may be able to extract this key from the IDE (such as through reverse engineering) and then use it to sign an unauthorized program.

IEC 62443 4-2 Mappings

  • SAR / EDR / HDR / NDR 3.2 – Protection from malicious code

  • CR 3.4 – Software and information integrity

References

[1] Codesys. “Protecting an Application.” codesys.com. Accessed: Aug. 28, 2024. [Online.] Available: https://content.helpme-codesys.com/en/CODESYS%20Development%20System/_cds_encrypting_application.html