Microsoft Takes Another Anti-Rootkit Step

I remember sometime around 1996 or 1997 I was in a meeting with Bill Gates talking about the future of Windows. I don't recall the exact context, but he said that he thought eventually they would have to require device drivers to be digitally signed.

They must take "eventually" seriously at Microsoft, even when the chief software architect believes in something. The company has been nudging device driver developers to sign their code for years, but it recently announced the first toehold of actual requirement: The 64-bit edition of Windows Vista and future versions of Windows will require that all kernel-mode drivers be digitally signed. There are other new requirements, but this is the important one.

So why would Microsoft require this? Code operating at kernel level is especially privileged. Other code operates in the privilege context of the user and its potential for damage can be limited by best practices. Device drivers are necessarily trusted because they necessarily have direct access to the hardware in the system.

A digital signature doesn't make a program safe and bug-free, but it creates accountability. You can know with a very, very, very high degree of certainty who is responsible for the program. At bottom, all security involves some element of trust, and security decisions are decisions about who you do and do not trust. Signatures facilitate the quality of these decisions.

A signature all on its own doesn't tell you everything you need to know, and in a way it doesn't even tell you who the person is. I could create and issue a certificate that says I'm the Sultan of Brunei, but that wouldn't make it so, and the fact that the certificate was issued by Larry Seltzer wouldn't impress anyone. That's why Microsoft is requiring that developers obtain a PIC (Publisher Identity Certificate), based on a VeriSign Class 3 Commercial Software Publisher Certificate. The PIC must be embedded in the actual binary, which should mitigate the performance issue of signature verification at boot time.

Security vendors were clueless over the rootkit invasion. Click here to read more.

One of the big reasons for this is to stop rootkits. True, a rootkit signed and issued by Sony might still get installed by a lot of people, but MRCHTZ0FDEF will have a much harder time getting a VeriSign Class 3 Commercial Software Publisher Certificate, and it will quickly lose it through violations of the agreement.

These requirements are already generating controversy. First of all, it costs $500 (less if you buy a multiyear contract). Second (essentially related to first), the documentation is clear that only a VeriSign certificate is acceptable. It seems unreasonable that other certificate authorities are not included in the program.

Next page: How big a deal is it?

You might be thinking now: "$500! I'm in the wrong business!" And there's something to that thought. But, according to VeriSign, it doesn't just run a program to generate the signature and mail it off to you. The company does actual research to make sure that the entity that applied for the certificate is who it says it is and that it is a real organization.

I spoke to VeriSign about this about a year ago related to abuse of code-signing certificates raised by Ben Edelman. (I had to amend that column, but I think the basic points remained valid.) At the time, VeriSign referred me to a policy document on its site that listed all the rules it follows. That document isn't where it was back then, but this one appears to describe all the rules.

For advice on how to secure your network and applications, as well as the latest security news, visit Ziff Davis Internet's Security IT Hub.

Are these requirements onerous? I have seen assertions (see this discussion on the matter) that only corporate entities can obtain a Class 3 certificate, but the VeriSign document doesn't seem to require it. It does require for individuals that the subscriber agreement be notarized and accompanied by three forms of identification. So, it's going to cost some money to get one, but not big money, and it's not that hard to do.

The requirement for kernel-mode drivers to be signed isn't the only new one in Windows Vista. These kernel-mode drivers must contain users who are not administrators and cannot install unsigned drivers in any mode. All drivers for devices that stream content must also be signed.

It's also worth noting that Microsoft's plans for this process make some exceptions to make life a little easier for developers. For the prerelease period of Vista, at least until Release Candidate 1, there will be a configuration setting developers can use to bypass the requirement, but this will be removed in the release version of Vista. It also will be possible to create a special boot menu option for running the system without the kernel-mode signature requirement, but this choice will not persist to the next system boot.

Would the requirements make open-source development impractical, or even impossible? Clearly, it would make open-source development more difficult, depending on how you approach the issue. I don't think this is Microsoft's goal, but I don't think it bothers them all that much either.

It's not clear how much open-source development is done with kernel-mode Windows, so the argument may be theoretical. But, clearly, all developers would need their own VeriSign certificate or access to someone else's. I haven't got a clear answer on it, but I think it should be possible for an organization willing to put up the money to give liberal access of their certificate to others. Perhaps VeriSign frowns on such behavior; I'm not sure what it does about it. But perhaps the central philosophical objective of the GPL is that users of programs should have the freedom to modify those programs to their needs and taste, and clearly Microsoft's objectives for the Windows kernel conform to a different philosophy.

Kernel-mode Windows development is already a difficult and very specialized business. Not every schmo with Visual Basic can do it, and those who do it well are fairly rare. In the end, Microsoft's new rules are an attempt to keep the unserious and malicious among us out of the kernel, and if there's some collateral damage, I'm sure the company sees it as worthwhile to keep dirty, unaccountable code out of the Windows kernel. It's a reasonable objective.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

Check out eWEEK.com's Security Center for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer's Weblog.

More from Larry Seltzer