In the constant battle against malware, code signing is assuming a higher profile, partly because of its importance to application whitelisting — seen by some as the most promising of anti-malware technologies. However, for all its technical complexity, at some point or another code signing still involves making a decision about who you trust.
How it works
The basic principles of code signing are simple enough. The software vendor creates a hash of the code file to be signed using a common algorithm -- such as SHA or MD5 -- and then signs that hash, in effect encrypting it, using the private key from a public-private key pair. That encrypted hash can be decrypted only by using the vendor’s public key. The hash, details of the algorithm used to create it and the public key are included in the code file in an area known as the signature block.
The user’s client software runs a verification tool that uses the public key to decrypt the hash. It then runs the software code through the same hashing algorithm specified by the vendor and compares the hash it obtains with the one supplied by the vendor. If they match, the user can be certain that the code has not been altered since the vendor first hashed and signed it.
This works because the alteration of a single byte would create a different hash result. And the encrypted version of the hash can be decrypted only with the public key that matches the vendor’s private one (which, hopefully, is jealously guarded and available to no-one else). If a malware writer were to change the code and sign it with a different private key, verification with the true vendor’s public key would fail.
Trusted authority
Spot the problem. How do you know that the public key included with the code really is from Microsoft or Joe’s Software? Enter a hierarchical Public Key Infrastructure (PKI). The vendor’s public key is itself signed by an authority we all trust -- a Certification Authority (CA) such as VeriSign or Comodo. This is handled through the issuing of a certificate by the CA that contains details about the software vendor and its public key.
In order to obtain a code-signing certificate, the vendor has to go through a validation process. The details of this vary from CA to CA, but essentially the vendor is required to provide identifying information, some of which will be checked against public information sources -- phone directories, Dun & Bradstreet listings and the like. The CA satisfies itself that this is a genuine organisation which is currently trading. It then gets the vendor to solemnly undertake not to distribute malware or behave in any other nasty manner.
The certificate (including the vendor’s public key) is signed by the CA and placed in the signature block of the code file. And the CA’s own certificate -- a so-called root certificate -- including its public key, is supplied with most operating systems and certain applications, such as browsers.
This is much the same as SSL certificates issued for secure websites: indeed, both SSL and code-signing certificates use the X.509 format.1 However, there are fewer CAs who issue code-signing certificates.
What it does
There are, in fact, several types of certificate, some designed for specific applications or platforms -- such as the Apple Developer Certificate. Each is designed to be read by a client utility typically built into the OS (such as Microsoft’s Authenticode system that can verify .exe, .cab, .dll, .ocx and other signed files) or into an application like a browser.
Typically, what you, the user, see is a pop-up screen effectively saying 'this software has been signed by company X and the Certification Authority Y is pretty sure that company X actually exists'. You also know that the software hasn't been altered since company X signed it.
"That’s as much as it will guarantee," says Jon Kerr, business development manager at VeriSign EMEA, "that the code you’re downloading is safe in the sense that it’s from a trading organisation, making them liable for anything untoward that would happen."
It's up to you whether you trust company X.
What it doesn’t do
Code signing makes no warrantees whatever about what the code does or how well it does it. Nor does it actually guarantee that it’s malware-free - only that it has been produced by an extant organisation that, one presumes, wants to protect its reputation.
The checking that CAs carry out can be quite vigorous. Miles Clement, senior research consultant of the Internet Security Forum (ISF), says he found it "mildly painful". The ISF obtained a certificate so that it could sign internal documents. This extension of code signing has become ever more significant given that macros in applications like Word or Excel have been known to carry malware. Clement says that the experience gave him respect for other owners of VeriSign-issued certificates. “But you don’t know if the other CAs are as thorough," he says.
How to use it
Organisations that produce their own software, such as large banks, may find it useful to sign it to ensure that everyone is running the right code. For this, they can use self-generated certificates. In general, however, most of us will encounter signed code in the form of commercial software -- shrinkwrapped or downloaded. So how do we make use of the signatures?
It’s possible to configure policies within an operating system so that your machine runs only those applications signed by an approved list of CAs or software vendors. For this purpose, Windows provides Software Restriction Policies (and the more rigorous and configurable AppLocker in Windows 7). This application whitelisting approach is also gaining traction among vendors of anti-virus software: Comodo, for example, is one of the pioneers in ‘default deny’ protection.
These approaches are arguably most effective in organisational environments where policies can be implemented within standard builds and configurations and where there are knowledgeable IT staff to develop, roll out and enforce the policies.
There are other scopes within which code signing has been enforced. Microsoft, for example, has imposed a requirement that all kernel code for Vista is signed by them. And on mobile platforms, both Microsoft and Apple (with the iPhone) have implemented strict -- some would say Draconian -- rules that all applications are signed by them. But enforced signing isn’t without its drawbacks. Microsoft has long signed its own system code. But there have been hiccoughs when they’ve forgotten to sign updates (a patch for IE 5.01 SP4, back in 2005, for instance).
Potential weaknesses
And the code signing model isn’t bulletproof. Back in 2001, for example, VeriSign issued two certificates to Microsoft — or so it thought. It turned out that the person posing as a Microsoft employee was no such thing.2
Certificates can be revoked, but the effectiveness of that depends on how the user’s client applications use certificates. First, you need to download an updated Certificate Revocation List (CRL) and then whatever application you’re using needs to know to query it.
Code signing has been used fairly heavily with ActiveX, where it has proven to be fragile. For example, one category of attack involved changing individual user’s policies, which were stored in ordinary user files. After that, all ActiveX content would run unquestioned.
Another potential issue is that, once a code-signing certificate has been issued, there are no restrictions on how it is used. And it’s critical that the owner of the certificate keeps it secured. A leaked private key undermines all signed software issued by that organisation, rendering even legitimate code suspect.
The software industry hasn’t always warmly embraced digital signing. In the Windows environment, many vendors baulked at paying for the privilege of having their code — which they knew to be safe and as perfect as code ever is — approved by Microsoft. It became common for code, even from large a respectable vendors, not to be signed.
There’s also the problem that each CA has its own processes and standards for checking applicants for certificates. One might feel confident about certificates issued by VeriSign or Comodo, but what about all those other, more obscure CAs?
For the majority of us, code signing plays little more than an advisory function — a pop-up warning saying that the piece of software you’re installing is by an ‘unknown’ vendor. And just like other nag screens that infest today’s operating systems, the temptation is always to ignore it.
"It doesn’t exactly jump out at you," says Kerr. "That’s one of the things that the industry is looking to improve."
Extended Validation
Kerr is referring to the introduction of Extended Validation (EV) by CAs, under the auspices of the CA/Browser Forum.3 EV has introduced stricter standards for how applicants are vetted, so that a certificate from one CA offers the same assurance as that from all others. For now, this is restricted to SSL certificates. However, the CA/Browser Forum is examining how to use EV for code signing, and has a draft proposal already written.
“I don’t think that’s enough,” says Melih Abdulhayoglu, CEO of Comodo. “Giving someone a code-signing certificate allows them to digitally sign anything that they have. I want to bring anti-virus vendors and Cerification Authorities together, so that AV vendors can check the application before it gets signed. That way, an application’s been checked.”
While this means signing all updates and patches too, Abdulhayoglu insists this is not a problem. “These processes can be largely automated,” he says. “And anti-virus vendors handle hundreds of thousands of files a day, so throwing a few more at them is not going to be a big deal.”
The biggest hurdle will be establishing this process as an industry standard and making it universal. For code signing to realise its full potential, it needs everyone to do it and for operating systems and applications to work only with signed code. But won’t that risk locking out smaller software vendors who can’t afford the certification fees?
“It would be in their best interest,” insists Abdulhayoglu. “Today they have no way of differentiating themselves as a legitimate software provider. This would give them the opportunity to say, ‘hey, we are also certified like Adobe’.”
He also wants closer co-operation between CAs and anti-virus vendors, and promoting the new Common Computing Security Standards (CCSS) Forum as a way of achieving this.4
“We need to get Av vendors to communicate with CAs,” he says. “For example, what do you do an as AV vendor if you find malware that is digitally signed using a certificate? Nothing. They do not communicate with the CA. I’m trying to get the two industries to talk to each other.”
There may be other potential ways in which code signing could play a richer role in security too — for example, in verifying web content that migrates to the desktop using technology like Silverlight. “Ultimately it might come down to individual bits of content being flagged,” says the ISF’s Clement. “That would be a natural extension.”
References
1. Internet X.509 Public Key Infrastructure Certificate, RFC 5280 — tools.ietf.org/html/rfc5280
2. Jan 2001 - Advisory from VeriSign www.verisign.com/support/advisories/authenticodefraud.html
3. CA/Browser Forum, Extended Validation: www.cabforum.org/certificates.html
