Code signing is one concept not earning enough attention amid all the coverage of advanced persistent threats (APTs).
A main reason APTs are an issue is because attackers can easily change application code or device firmware (that’s what makes them “advanced”) without being noticed (that’s what makes them “persistent”) and the threats are significant and don’t necessarily involve just corporate data theft (think about malware on critical infrastructure, such as a flight computer in a plane, smart grids, or even traffic lights).
Since the code runs on open platforms, the best line of defense is to make sure the software has not been modified by testing its authenticity.
Software developers will often enable their code to be tested prior to execution by signing their code digitally, effectively applying an embedded watermark. In the current climate, software publishers, be them creators of commercial software or in-house developers, are in danger of being viewed as irresponsible if they do not sign their code.
However, such efforts do not appear to have worked in the case of many of the now well-known APT attacks.
The obvious questions therefore surround the trustworthiness of the signatures. Given the rise of APTs, I expect greater focus on trustworthy code signing processes as well as on digital signature laws. Fortunately, numerous methods exist to digitally sign code in very secure ways that are not a burden to the development process.
Needless to say, the use of hardware security modules (HSMs) addresses the potential trust issues related to code signing. By protecting secret signing keys the signatures can be trusted. HSMs themselves are certified to independent standards (e.g. FIPS) and can be used to enforce strict key management policies, which means signatures can be trusted across separate domains.
Finally, HSMs include crypto-acceleration capabilities, which are important for organization doing lots of signatures.