eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I’ve always been a fan of code signing. It seems clear to me that trust is a major issue for code you bring onto your system, and digital signatures can improve trust.
But it’s also clear that code signing is a messed-up process. On popular general-purpose computers it’s used widely only on Windows, and nowhere near as widely as it might. Certain aspects of code signing on Windows, especially certificate revocation, are a mess.
On mobile platforms it is widespread, even mandatory on many platforms, as providers use it to control what code can be run on their networks. But everyone has different rules and different technologies, and the result is a confusing and expensive mess for the poor software developer who wants to deliver code on multiple platforms.
Melih Abdulhayoglu, CEO and chief security architect of Comodo, wants to fix code signing. Abdulhayoglu (tell you what-let’s call him Melih) was the original force behind the CA/Browser Forum and EV-SSL (Extended Validation Secure Sockets Layer), which sets standards for the issuance of a new class of SSL (Secure Sockets Layer) certificate and rules for how browsers should behave for sites which have them. He wants to create a similar group to create standards to improve code signing.
Melih sees two stages of this process: The first, just as with EV-SSL, is to set standards for the issuance of a new class of code certificates. The identity of the applicants for these certificates, as with EV-SSL, would be strictly scrutinized, and perhaps restricted to certain classes of organizations. For example, unlike the old type of SSL certificates, EV-SSL cannot be held by individuals.
Once again, there would have to be some new prominent behavior for the user to see that a file was signed with this new class of certificate, analogous to the green browser bar for EV-SSL. It doesn’t matter exactly what it is; what matters is that it’s eye catching and implemented consistently.
But Melih wants to go a step further. When code signing was devised back in the mid-90’s, malware authors wanted to do whatever they could to hide their identities. You could reasonably assume that signed code was safe code, even though the theory of it never argued for such a conclusion. Now malware authors, especially adware vendors, buy code signing certs.
Therefore, he wants the content of the files to be checked for malicious content. The first thing that I thought of was uploading it to VirusTotal, but there are many different kinds of checks that could be performed. All of these checks run some risk of false positives and false negatives. Just recently Mozilla announced that a virus infection in their Vietnamese language pack had slipped through-even though it was scanned for viruses at upload time. Happens all the time when malware is new.
Is this really a mess that certificate authorities want to get into? I totally understand the motivation for checking the files, but it’s so obviously imperfect. It’s inevitable that malware will get through the process. At the same time, perfectly innocent programs will be misidentified as malicious. Not a good situation.
Another approach you could take for safety besides scanning files is a reputation system, similar to the ones developing for e-mail senders. Comodo is trying to build a general one on their UserTrust network, but I’m leery. (Please let me know what you think of UserTrust in the comment area below.)
There is more that can be done for code signing standards. The biggest improvement is that there also needs to be standards for revocation of certificates. Revocation is the messiest part of the code-certificate mess. There are two problems with revocation: There needs to be standards for what constitutes a revocable offense. All CAs (certificate authenticators) have policies for this that you agree to when you buy a certificate, but they are inconsistent and arguably unspecific. So an EV-Code Signing system could make that more consistent.
The second problem is that revocation needs to be more powerful. Windows only checks if a program certificate is revoked at install time. Once the program is installed, if its certificate is revoked, Windows won’t know. This is why, in the case of Atsiv, a program that bypassed 64-bit Vista’s requirement that kernel-mode code be digitally signed, Microsoft dealt with it partly by issuing a Windows Defender signature for it.
The cert was revoked by VeriSign, but that only dealt with new installs. Why doesn’t Windows check at load time as well? If it’s just about performance I’m unimpressed. A standard for when and how revocation checks are to be performed would help too.
I don’t agree with Melih on all of these issues, but we both believe in the ability of code signing to improve security and trust. Getting a standards group working on these issues could help to clarify which ideas make sense.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack