What code signing is and isn’t good for

By Scott Dunn

As I explained in my May 10 article, driver-signing requirements for the 64-bit version of Vista have slowed down developers, but not hackers.

Readers wrote in, pointing out further complications, while cautioning that the practice of driver signing itself is still useful.

Code signing is valuable, despite flaws

Regarding my story on Microsoft’s driver-signing strategy for Windows Vista, reader Donald P. Welker writes:

• "I’m afraid your FUD [fear, uncertainty, and doubt] may be even more dangerous than Microsoft’s. There is no basis for trusting a vendor-supplied (or worse, downloaded) binary without code signing. While Microsoft clearly deserves your indictment of their shortcomings, your article overlooks the fact that third-party antimalware products can also examine code signatures and prevent installation and/or execution on that basis.
  
  "Since it seems unlikely that we’re going to force Microsoft into an open-source model, we have no choice but to accept a code-signing model and start signing our code. If there’s a real Achilles heel in code signing, it would be the allowance of file-based certificates instead of mandatory use of smart cards or similar tamper-resistant tokens. Besides, signing open-source code is a good idea anyway."
  

Just to clarify, it was not and is not my intention to say that driver signing is a bad idea, or that it should be abandoned. On the contrary, in light of the constant security and malware threats users face, a multipronged approach to security only makes sense.

The point of the article was that the specific

Related posts:

1. Driver signing is a failure for Vista
2. Windows XP may corrupt data using SMB signing
3. Free source code documenter
4. Vulnerability in SMTP could allow remote code execution
5. Microsoft Outlook bug could allow code execution (828040)