Code signing  provides  a number of important features. Traditionally, code signing is initiated to assure security when deploying software. It can also be implemented to assist  the prevention of conflicts in relation to namespaces. It is often used to provide build version status for an object or to store other meta data about an object. Most signing implementations involve digital signature processes to assure the code writer or build system, and a checksum to verify that the code  has not been altered.


The majority of code signing implementations will provide the ability to sign the code using private and public key systems, much like the systems employed by SSL certificates do for websites. This is one of the reasons that you’ll find that code signing certificate authorities will also offer SSL certificates as well. To illustrate this point; let’s assume you are developing in .NET environment. As the developer, you will use a key to sign your libraries or executables each time you complete a build. The unique key will be assigned to you alone, though it could be assigned to a group, an application or even an object. You could choose to create a key on your own or select a trusted certificate authority (CA).

It’s easy to see the value of this process in distributed environments, where the source of a given piece of code may not be easy to recognize – like in  ActiveX controls, browser scripting code and other active web objects. You’ll also find code signing used to securely provide updates and “patches” to new versions of established software. Linux distributions, Apple Mac OS X and Windows update services implent code signing to ensure that harmful or exploitive code cannot be distributed to code via the patch system. Distribution security is necessary because distribution outletso n the web (mirror sites and the like)  often out of the control of the original author’s control.

Certificate Authority (CA)

The trusted root authority should originate the public key used for code signing , preferably using a secure public key infrastructure (PKI).  Of course this can’t ensure that the code itself is inherently trustworthy, only that it’s origin can be verified (or to be more exact, from a unique private key). A certificate authority provides a  third-party verification from which others can be trusted by proxy. If a user is set to trust one of these certificate authorities and receives an executable signed with a key generated by that CA, he can choose to trust the executable by proxy.

Operating systems often include a number of pre-installed, publicly trusted authorities (Examples: VeriSign, TC TrustCenter, COMODO, GoDaddy and GlobalSign).  This process is not confined just to software that is publicly sold. Large companies often employ  internal certificate authorities with much the same functionality for their internally created software for deploying signed objects within their organizations.

Solutions Without CAs

Developers do not have to rely on CAs exclusively an dcan choose to provide their own self-generated key. HTe drawback is that  the user would  have to obtain the public key directly from the developer to verify the object is from him for the first time.  Some code signing systems store the public key inside the signature; other software frameworks and OSs check the code’s signature before executing, thus allowing you to choose to trust that developer from that point on after the first usage. Developers can provide a system to mimic this by including the public keys with the installer. The key is then used to ensure that all future objects that need to run (upgrades, plugins, or another applications), are verified as originating from the same developer.

Known Issues

As with any securty protection system, code signing is not fool-proof. The system is only secure as long as the private key remains private. Users may errantly run unsigned code, or run code that does not validate.

Note that code signing cannot protect the software user from any malicious activity or unintentional software bugs by the software author – it only offers the protection that the software has not been altered by anyone other than the verified development authors.