With neither fanfare nor advance warning, Microsoft recently plopped a whitepaper about x64 kernel-mode drivers onto its WHDC Web site. "Nothing unusual about that," you might say. After all, we're treated to a new WHDC whitepaper on some topic or other just about every month. While that's true, this paper was different. The first sentence on the WHDC Web site that introduced the whitepaper summarizes the issue:

For Windows Vista... kernel-mode software must have a digital signature to load on x64-based computer systems.

Note that nobody is talking about forcing drivers to pass WHQL testing or having to participate in the Driver Reliability Signature program. But they are saying that if a driver's not signed, it's not going to be loadable on an x64 Vista system (except under a few very limited conditions described later in this article).

As you can imagine, members of the driver development community did not great this news with undiluted pleasure. The number of comments on OSR's NTDEV list set an all-time record, far exceeding the number of postings on other popular topics (including C versus C++ for drivers, building in Visual Studio, and other religious debates). There was one major difference, however, between the comments about x64 driver signing and those of previous record-holder topics: All those who took time to air their views on x64 driver signing agreed that Microsoft's policy was a bad thing.

Whether on NTDEV or some other forum, there is no shortage of people jumping to conclusions based on the limited information Microsoft made available about this program. Therefore, The NT Insider decided to get to the root of this issue by talking with the Microsoft devs and program managers who are involved in the x64 driver signing program. We are grateful for the time they took - on multiple occasions - to answer our questions.

In this article we examine the issue of required x64 driver signing. We start with a description of Microsoft's motivations for putting this program in place. We then continue with a description of what the program presently entails. We finish with the communities objections, along with our own, to some of the program's present provisions. (PLUS, make sure to read Microsoft's response to the x64 Driver Signing issue at the conclusion of this article.)

Break the Cycle

It shouldn't come as a surprise to anyone reading this that increasing the security of Windows is a priority for Microsoft. It's just too easy for an ordinary user to have the security of their computer compromised. This is a concern for Mom and Dad at home, and perhaps even more so for corporate users. Clearly, one of the biggest challenges for Windows Vista is how make the Windows platform more secure.

But making Windows secure, especially the kernel environment, isn't easy. There are millions of Windows systems, running all sorts of drivers that have been created over the years by all manner of companies. Given the amount of legacy software for x86-based systems, there are practical limits to the changes that can be made on Windows 32-bit systems without causing pain to an enormous user population.

On the other hand, the x64 is the platform of the future. Because there's no binary compatibility between x86 and x64 kernel-mode components, Microsoft views the move to x64 as an opportunity to innovate in many ways, including kernel security. This isn't a new idea ‑ recall that there's no embedded assembler language allowed in x64 software. Similarly, you may recall that on the x64 Microsoft has tried to make it impossible to internally "hook" kernel routines such as the system service dispatch table. Many devs, probably even most devs, think these changes are reasonable.

Microsoft's thinking seems to be this - when you move your kernel-mode code to x64 you have to make a few changes. For example, you need to account for 64-bit pointers. You also need to remove any crusty old assembly language that you embedded in your code back in 1994 when you could write better code than the compiler. So, if Microsoft is going to change something about how drivers are supported in Windows, it'll be easiest to do it for x64-based systems because everyone has to change their drivers when they migrate them from x86 to x64 anyhow.

Signed, Sealed, Delivered

As Microsoft considered how to increase Windows security, one problem loomed large - preventing malware from creeping into the kernel. One potential solution to the proliferation of kernel-mode root kits appeared to be the most straight-forward: Load nothing into kernel-mode on a Windows x64 machine running Vista unless it's origin can be authoritatively established. These days the way modules typically establish their authenticity is via digital signatures. The Authenticode program is one example of a digital signing process that's used to establish the identity of a software module.

To establish the identity of kernel-mode components, Microsoft started with the Authenticode system that's supported in Windows Server 2003 as a base. Under this program, the supplier of a driver signs a complete driver package including the SYS and INF files. The signature is stored in the CAT file that is part of the driver package. During installation, the signature is validated and checked against the root certification authorities (those authorities that are listed as "trusted") loaded on the user's system. On Windows Server 2003, if the signature checks and the certificate is trusted, the driver will be loaded without complaint.

While the Authenticode process as implemented on Windows Server 2003 helps ensure the integrity of installed driver packages, it falls a bit short of what's required to achieve "really good" security. The folks responsible for security on Windows Vista x64 wanted a more iron-clad security guarantee than what the current Authenticode process provided. The main problems with the current Authenticode process are:

1. If the existing user-mode root certificate store was to be used to validate the authenticity of Vista x64 kernel-mode drivers, what prevents an attacker from simply adding a fictitious trusted root certificate authority to the user's store?
2. How do you find the associated CAT file during the boot process without slowing the (already too slow) boot process down to a crawl?

Points of Authority

Microsoft decided to solve the problem of which root certificates to trust in a pretty simple way. Their solution is that Microsoft's root certificate authority is the only one that will be trusted for kernel-mode modules. This decision allows the Microsoft devs to hard-code the necessary root signature information into the OS where it will be much more difficult to tamper with.

To provide a certificate that links back to Microsoft's root certificate, Microsoft decided to leverage the existing WinQual infrastructure, but - quite separate from WQHL signing - create a new item called a Publisher Identity Certificate (or PIC, for short). A company that satisfactorily establishes its identity to Microsoft will be issued a PIC at (apparently) no charge. The company can then use this PIC to sign their driver. The actual signing process and associated options will be described later in this article.

How does a company establish its identity to Microsoft's satisfaction so they can be issued a PIC? Presently, this can only be done by the company obtaining an "Authenticode Code Signing Digital ID" from Verisign. This is also referred to as a Verisign Class 3 Commercial Software Publisher  Certificate. Since Verisign is in business to make money, they charge $499 per year to process your application and issue you this Digital ID.

Microsoft says they chose Verisign because they already had an established business relationship with Verisign and they trust Verisign's processes. Obviously, this program won't be optimally effective if a hacker can establish their identity via some shady certificate authority, and then use that as the basis for "proving" their identity to Microsoft for the purpose of getting a PIC.

It seems that Microsoft recognizes it would be more desirable to have other certification authorities besides Verisign. According to the FAQ published on the WHDC Web site, Microsoft is "in the process of evaluating additional CAs in order to authenticate vendors to receive PICs."

Thus, the current process for authoritatively establishing the identity of the supplier of a driver package is clear: 

• A supplier proves their identity to Verisign's satisfaction.
• Since Microsoft trusts Verisign, based on Verisign's say-so Microsoft issues a PIC to the supplier.
• The supplier uses the PIC to sign driver packages it distributes. 

From the Inside

While the process described previously works for most drivers, it's not a very good process for drivers that start at boot time. As mentioned earlier, if during the boot process and using the limited I/O capabilities provided by the loader, the kernel has to search through all the CAT files in a system looking for the signatures of boot-load drivers, the process of starting Windows is likely to be even slower than it is now.

Before you dismiss this as just so much nonsense, consider that a clean installed system has something like a minimum of 10MB of catalogs on it. Over time, the number of installed devices, and thus the number of CATs, is likely to grow. So, the amount of data the boot process has to sift through isn't trivial.

To solve this problem, Windows x64 on Vista will require kernel-mode modules that are loaded at boot time to be internally signed. That is, these modules will be required to have a signature embedded in their executable image.

The process for signing a driver's executable image, and embedding that signature into the image, is basically the same as that used to sign the driver package - the same PIC can be used. Embedding a signature into a driver image doesn't interfere with signing the driver package. It's also interesting to note that embedded signing is supported for non-boot drivers, so it isn't a problem to always use embedded signing.

Thus, if a driver needs to be installed at boot time, two things will be required: Any modules that will be loaded into kernel-mode will need to have embedded signatures, plus the driver package will also need to be signed and the CAT file containing those signatures will need to be included in the driver package.

One Step Closer

To summarize what we've discussed about the x64 Driver Signing Program:

• All kernel-mode modules loaded on a Vista system running in 64-bit mode on an x64 processor will need to have the origin authoritatively established via a digital signature.
• Digital signatures will be required on the driver package for all drivers.  Boot start drivers also will be required to have embedded signatures.
• To be able to sign a driver or a driver package,  the supplier of the driver (be that the author, distributor, or a company supplying a driver internally) needs to get a Publisher Identity Certificate (PIC) from Microsoft.  This PIC can be used to sign driver packages and driver executables.
• To be able to get a PIC from Microsoft, the supplier needs to establish their identity to Microsoft's satisfaction.
• Currently, the only way for a supplier to satisfactorily establish their identity to Microsoft is by obtaining an Authenticode Code Signing Digital ID from Verisign. In the future, Microsoft might choose to trust certification authorities other than Verisign, but for now, Verisign is the only option.
• To get the Authenticode Code Signing Digital ID from Verisign, the supplier has to establish their identity to Verisign's satisfaction. And give Verisign $499 a year for the privilege. 

Easier to Run

If driver signing was enforced during development, it would be a major pain in the ass for driver developers. As a result, Microsoft currently provides three mechanisms that bypass the signing requirement and allow non-signed drivers to be loaded on Vista x64 systems. The driver signing requirement is not enforced if any of the following are true:

• The machine is booted with debugging enabled, and a debugger is actively attached to the machine on which the driver is loaded.
• During startup, the user hits F8 and selects "Disable Driver Signature Enforcement."
• In the early stages of the Vista beta cycle, the boot configuration database can be changed using BCDEdit to disable driver signing enforcement. BCDEdit is the replacement for editing boot.ini, which is no longer supported on Vista.

During development, devs will be able to build and test their drivers without the signing process getting in the way as long as either WinDbg or KD is hooked up to the target machine. Using the F8 option might be a good choice for testers or devs in some odd recovery situations.   The option of changing the boot configuration is temporary - Microsoft has threatened to remove it at any time - so it's effectively useless.

Forgotten

So far we have described the driver signing program from beginning to end. What's not to like about this program? Well, according to community members - plenty. The chief complaints raised by the community are:

• The program has no reasonable accommodation for testing.
• The program eliminates Windows x64 as a platform for community-based kernel-mode software. By this, I'm referring specifically to software developed by individuals for fun and the pleasure of supporting a special interest. (Note I avoid referring to "open source" software since that is a loaded term.)
• Microsoft has no right unilaterally to dictate what can and cannot be run on somebody's computer.

Many community members have also indicated serious concerns about the only allowed certification authority being Verisign.  However, because Microsoft has already indicated that they intend to use other CAs, we'll assume that problem has been solved. 

Let's look at each of the major community issues in turn, starting with the last one. 

Whose Computer Is It Anyway?

Many community members, OSR included, think it's just plain wrong for Microsoft to restrict what drivers you can load on a system that you bought and paid for. It comes down to a moral argument: - it's my computer, and I'll fry it if I want to.

Part of the concern behind this argument is undoubtedly the danger of the "slippery slope." Today Microsoft says "We're not making your drivers pass WHQL tests to get signed. Just sign them to prove their origin. That's all we ask." If the precedent is established that Uncle Bill can dictate which drivers are good for us, how long will it be before WHQL signing is mandatory? Once we're on the slippery slope, what if they decide to only sign drivers they "like." Or worse yet, what if they don't think the drivers are made by the right people or the right country?

The counter-argument is that while a generic bypass method might be desirable, how can a bypass method be created that meets the following criteria:

• Works at boot time.
• Can be widely distributed at close to zero cost.
• Will not cause Mom and Dad's eyes to glaze over when they see it. ("Just click OK, Ma, it always says that.")
• Cannot be exploited by hackers.

It's not an easy problem to solve. However, whether the problem is easy or hard, Microsoft needs to find a solution before Vista ships. If they decide not to accommodate the community's moral argument on this issue, then perhaps Microsoft would be willing to create a bypass method that allows community-developed x64 driver to load on Vista.

Somewhere I Belong

A mysterious poster named "Mr. Guid" started the discussion on our NTDEV list about the x64 signing program by noting that this program would effectively kill the open software community for kernel-mode software on Windows x64.

This might not seem that important right now. After all, how many "civilians" run Windows-64 these days? But as Windows x64 gains momentum, we can expect that in a few years many, if not most, systems will be x64-based. That means many folks will be running X64 systems at home, work, and also for play. Heaven knows, there are tons of hobby-type, special purpose, nifty drivers that have been written by intelligent, professional folks for the pure pleasure of it and for the sake of helping others.

For example, consider the Internet-based project that turns your parallel port into a quasi oscilloscope. This wasn't provided by any company, but rather by "some guy" who thought it was a cool idea. While it's not an earth-shaking application, it would be a shame to stifle this kind of sharing and innovation.

Why would this type of development be stifled? Because, regardless of what you may have read elsewhere, Verisign will not issue an Authenticode Code Signing Digital ID to an individual unless that individual has established themselves as a business entity. Even if Verisign changed this policy tomorrow, not many individuals would be willing to pay $499 per year for the privilege.

If ordinary users don't have some way to download a personally developed driver to run it on their machine, Windows is in serious trouble as a platform. Without a reasonable bypass method, people will stop developing hobby-type kernel-mode applications when Windows x64 becomes the prominent platform. This forces those applications to a different O/S such as one of the Linux distros. Once hobby developers move to Linux, what are the chances they'll also want to run Windows?

Once again, whether they're persuaded by the moral argument rising from the community or because they want to keep community-based developers on the Windows platform, we strongly urge Microsoft to solve this problem before Vista ships.

By Myself

We think a reasonable solution to the bypass problem would be a system setting that allows specifically named drivers to be loaded, even if those drivers aren't signed. This mode could be enabled only if a CD or USB key drive that's present on the system during boot has some mystic monkey voodoo signature that's unique to the machine and driver being loaded. Not only would this process work at boot time, but it also wouldn't cost anything to distribute widely. Forcing something to be physically in place at boot time and requiring it to be unique to the machine and the driver(s) being loaded makes it difficult for hackers to exploit.

Also, the fact that particular unsigned drivers have been loaded on the system should be evident. This could be accomplished by displaying the names of any drivers that are set for bypass during startup. In addition, Windows could pop a modal dialog that lists the unsigned drivers every time a user logs in. Finally, Microsoft could add a warning message that lists the drivers in the lower-right corner of the screen.

If all these things are added, we think that, together, they'll provide security and allow us to load whatever crap we choose onto our machines.

Break Stuff

There's one more specific problem with the current program - the lack of accommodation for testing. If Windows x64 requires kernel-mode modules to be signed, how will periodic internal driver builds get tested? While having a debugger actively hooked-up to a machine might be a reasonable alternative for many developers, most test labs do not constrain every one of their test machines to have an active debugger attached.

Surely, Microsoft can't expect developers and testers to sign their daily builds with the same PIC they'd use to sign their released drivers!

Fortunately, it seems there may be light at the end of the tunnel on this front. According to reliable sources, Microsoft is actively exploring other opt-out mechanisms to assist in the test phase. Of course, as already mentioned, the challenge is to devise a mechanism that can't be trivially exploited or bypassed by malware.

In The End

Where does this leave us? Microsoft has promised that our kernel-mode drivers won't load on Vista unless we get them signed. This means we must either sign the driver package or sign the driver package along with the kernel-mode executables it holds.

While signing to establish the origin and authenticity of a driver package is a good idea, it seems to us that it can't be forced on every user, in every circumstance, everywhere.  There simply must be some reasonable provisions made for exceptions.

What do you think about driver signing? Is it an evil pain in the ass or a necessary step down the road to reliable computing?  Let us hear your views by either commenting here on this page, or in the NTDEV forum.

Microsoft's Response on The Vista x64 Driver Signing Issue   Microsoft has been monitoring various external device driver forums, and is actively working on additional changes to the program to improve the overall x64 signing program. There are two classes of items in the signing program that we are actively working on extending: the ability to test binaries that have not been signed with a production PIC key, and extending the range of allowed certification authorities beyond Verisign.   Providing a mechanism that allows a user or developer to securely opt-out of the signing mechanism has been investigated in great detail. This is a challenging area, because any opt-out mechanism needs to be resilient to automated tampering by malware. A further complication relates to the absence of non-virtualizable, available and securable storage in the boot environment in current systems. It is very desirable to have a mechanism that changes system enforcement policy only based on a physical change to the system. One such change that was investigated was providing an over-ride mechanism that checks for presence of distinguished physical media such as a file on inserted CDROM or USB media. Due to the constraints in the boot environment, as well as the various BIOS code in the ecosystem, there is no reliable way to check external media in the boot loader environment, in a manner that scales to the diverse set of deployed systems. In general, we believe that for overall safety and security of the system and protection of user data, secure mechanisms for adding further trust roots to validate signing policy are preferable to global opt-out schemes and we believe that this can address some of the needs of community based software development.   Therefore, rather than provide a general purpose opt-out mechanism, which is likely to have security pitfalls or will not work on a large set of systems, we are pursuing a test signing mode. The administrator of the system can opt-in to enabling the test mode, at which point the signature checking mechanism will allow test signed binaries to load. The user will be notified of this operational mode of the system. Microsoft will communicate the details of this change if/when the plan becomes plan-of-record for the Vista release.   The issue of allowing certification authorities beyond Verisign is actively being investigated. This is more of a procedural issue, than a technical one. Verisign happened to be well-positioned with respect to signing processes, guidelines, and certification procedures in the timeframe where the signing program details were first published. Extending the program to support additional certification authorities requires zero code changes in the Vista code base. Microsoft is actively investigating how to best extend this program to additional certification authorities, and will communicate any changes when appropriate.   Scott Field Varugis Kurien Architects, Security Technology Unit   Jean Valentine Lead Program Manager, Windows Device Team Microsoft Corporation.