02.04.06
The Failing of Signed Drivers
As I posted previously in my PDC roundups, Microsoft will be requiring device drivers to be signed in the 64 bit version of Windows Vista. This is almost certainly because of the heat they’ve been getting from companies over the rootkits that have been slowly making their way around the net which can literally take control of your machine and cover their own tracks while doing it. It sounds like a good idea in theory but it will ultimately be a nightmare for Microsoft to maintain and support while the rootkits will still come out.
Here’s the basic scenario as Microsoft describes it. When Windows goes to load a device driver it first looks for the signed certificate that goes along with it (typically as part of the device driver .sys file but can be in a separate file for drivers not required to boot). When it gets that certificate it checks the chain of trust and if that chain is founded in a particular master certificate which belongs to Microsoft then Windows loads the driver. To sign a driver, a deveoper has to get one of these magic certificates from Microsoft which they state they will offer to anyone with a Class 3 certificate from Verisign ($500 yearly cost). From there it’s relatively easy to sign whichever driver you publish.
There are exceptions to the rule – Windows will load unsigned drivers if you have a kernel debugger attached (for example) and Microsoft has said they’ll work out some way of allowing unsigned drivers to be installed in test labs so people don’t have to sign drivers prior to testing. All of this sounds good in theory but it’s really just a smokescreen.
Now the initial problem with this scheme is the chilling effect it has on driver creation for 64 bit Vista. There are many open source packages out there at the moment which have unsigned drivers that are incredibly useful – the most well know is Ethereal but others include access to various file systems (Linux ext2/3, Mac HFS, various other Unix flavors) which will effectively be nipped in the bud because there’s no adequate method of maintaining key security for an open source project. You can’t publish the signing key because then anyone can take it and sign their rootkit. You can’t not publish the signing key because that violates the GPL. You’re screwed.
Secondly, it takes one driver with a bug to bring the whole system crashing to its knees. How many times have you seen Windows blue screen? These are typically caused by driver bugs and any of these bugs can be exploited by a rootkit to load itself into kernel mode. Driver signing tells you who published a driver but Microsoft can’t revoke the key for a specific driver without revoking the keys for all drivers from a company. Say the rootkit developer finds a bug in a specific driver from VIA, ATI, Intel or nVidia to exploit. The driver is signed and can’t be revoked without revoking every driver published by that company. The signed driver is exploited to load rootkit code and while you feel all secure with the fancy new signing technology it really hasn’t protected you at all.
Think about it – at last count there were well over 100,000 drivers available for Windows. How hard do you really think it will be to find one with a bug? Some drivers are actually designed to load other code (for example auto-update code) which becomes even easier to exploit.
Thirdly, it means that the rapid driver updates you see now for video cards and other system components will slow down. Typically video card point releases have been unsigned and pushed out to the public as quickly as possible. Now it won’t be as easy as they’ll have to go through the company signing process, which draws a lot of political attention inside companies. Releasing code is one thing. Signing it is totally different.
Lastly, the whole thing attacks Windows primary advantage over Linux and MacOS – hardware support. With the chilling effect manditory driver signing has on hardware support for Vista, Linux and MacOS will be pushed out as easily supported alternatives and far better initial test platforms for new and experimental hardware. If anything I expect this to provide a living hell for Microsoft and a boost in attention, support and stability for Linux and MacOS.
I haven’t even begun to discuss the anti-consumer effect this policy has when you tie it with DRM. Stay tuned for another post sometime when I get passionate enough.
Microsoft’s really shooting themselves in the foot here. Manditory signed drivers with no way for the user to turn the behaviour off is a critical mistake and I look forward to seeing Microsoft lie in the bed they are making.
RL Said:
May 2, 2006 at 12:10 am
You have posted a very interesting message. I am left somewhat confused however by the exact type of signature which Microsoft is intending to use. For example, it would appear that using an MD5 hash embedded in the driver file would prevent any unnoticed change in the file. Such a hash would be public information and would be available for viewing or download from the driver designer’s web site. And, the various virus and spyware protection software companies could include periodically updated tables of driver hashes in their software, so as to check driver validity. This would empower such software in a new way. Linux users are already checking various message digests when downloading operating systems and other software files.
Am I missing something here?
jw Said:
May 3, 2006 at 2:20 am
Microsoft uses a fairly standard public-key RSA digital signature algorithm. They have a private key embedded in the Windows code itself, and check each driver as it is loaded to ensure the digital signature (which is a function of the public key and the hash of the driver code) which is packaged with the driver.