How Code Signing Works.
We would like to present a simple explanation of how Code Signing works. We assume you have basic understanding of the principles of Hash functions and Public-key cryptography.
Here is the problem: the developer D packages software in a file and puts it on the Internet. The prospective user U downloads the file. Since the user U doesn't know developer D, U wants to verify two things: 1. the developer is who he claims he is; 2. the file has not been changed on the way from developer to user. Code Signing solves this problem using two technologies: hash functions and private/public key encoding.
First, developer D calculates the hash value of the file. Second, developer D encodes the hash value using his private key. Then he attaches the encoded hash value and the public key to the file. The user receives the file and the attachment; calculates hash value of the file; decodes developer's hash value using his public key and verifies that two values are same.
This solves the problem of file integrity. Still, user U doesn't know if the file came from developer D and not from someone else. To solve this problem, let's introduce a trusted third party - the Certificate Authority (CA). The developer D already proved to the CA that he is who he says he is by using physical evidence. In response, the CA issues a document listing D's attributes (name, location etc) along with his public key. This document is called the Certificate. The CA calculates the hash value of the Certificate and encodes the value using its private key. This encoded value becomes a part of the Certificate. The CA's public key is well known; in fact the public keys of the biggest CAs like VeriSign, Thawte, Comodo, GlobalSign etc, come preinstalled with Internet browsers and latest OS versions. Since user U trusts the CA (or more precisely, the installed software on user's computer trusts CA), he can use the CA's public key to check the authenticity of the Certificate issued for developer D.
The final touch. As before, developer D calculates the hash value of the file and encodes it using his private key. Instead of his public key, the developer now puts the Certificate into attachment. This procedure is called Code Signing. The attachment is called the Digital Signature. The user U receives the file and the attachment, calculates the hash value of the Certificate, decodes the Certificate's hash value using CA's public key, verifies the authenticity of the Certificate by comparing the two value, and then does same actions mentioned above to check the integrity of the file.
This sounds a bit tedious, so Microsoft encapsulated many things into the Authenticode API. When an executable file is signed using Authenticode, the non-executable section is added to the file which contains the digital signature. When the file is received by the user and the properties are checked in Windows Explorer, MS Windows extracts the Signature and does all the verification behind the scene. Windows XP, SP2 runs verification each time the file is executed. You should see a warning like this one:
The user can examine the details of the Certificate by clicking on the Publisher's name. In the end, the user decides if he wants to proceed and run the file.