All Windows 10 Kernel Mode Drivers Must Be Digitally Signed By Microsoft (i-programmer.info)

"Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal to be digitally signed by Microsoft," reads a MSDN blog post. "However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement. Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal."

Slashdot reader mikejuk quotes a report from i-programmer.info which argues "the control of what software users can run on their machines is becoming ever tighter," and compares Microsoft's proposal to an XKCD cartoon: Before you start to panic about backward compatibility with existing drivers the lockdown is only going to be enforced on new installations of Windows 10. If you simply upgrade an existing system then the OS will take over the drivers that are already installed... Only new installations, i.e. installing all drivers from scratch, will enforce the new rules from Windows 10 version 1607... Be warned, if you need to do a fresh install of Windows 10 in the future you might find that your existing drivers are rejected.

Comments

It just rolls off the tongue.

[supernova87a]

You cannot imagine how excited I am to be submitting my drivers to the Windows Hardware Developer Center Dashboard portal. Talk about boner killer.

Not MS target demographic

[JeffOwl]

For 97% of Windows 10 users (yes, I made that figure up) this is a total non-issue. It may even be a benefit to protect them from themselves. Many can't distinguish between safe and not so safe web sites from which to download programs and such. These folks may not even know how to uninstall drivers that don't uninstall automatically when a related piece of software is uninstalled. If you are a registered developer, this isn't an issue either as MS gives you a way around it.

For the rest of us, well, there aren't enough who haven't already migrated to iOS or Linux so MS doesn't give a shit.

Re:Not MS target demographic

[Opportunist]

Same as I'll do with the rest of the hardware I make: Abuse some USB communications class and roll the logic into the hardware.

Re:Not MS target demographic

[AmiMoJo]

There is no need for hacks. There are two driver-free options available, with cross-OS compatibility.

You can use HID for low speed stuff. Max transfer rate is 64KB/sec, but that's plenty for many applications like sensors and (surprise surprise) human interfaces. If you want more you can use a custom WinUSB interface. All you have to do is add a couple of extra descriptors to your device that tell Windows to attach the WinUSB driver (and optionally what friendly name/icon to use). You can use any endpoint type with it, even composite devices. Naturally Linux just ignores these headers and you can talk to the device by the usual methods (e.g. libusb).

Abusing communication classes (CDC) doesn't work very well on Windows any more. As of Windows 10 you can't just supply a .inf file pointing to usbser.sys, it needs to be signed. You can get free signing keys (and they will still work even after this update, it only applies to code running in the kernel which in this case is usbser.sys which is signed by MS) but you still have to deal with the bugs in Microsoft's implementation.

Gee thanks

[JustAnotherOldGuy]

Thanks for not even giving people the choice to run an unsigned driver, since there's lots and lots of hardware out there that will instantly be made 'obsolete' by this policy.

Locking out open source hardware

[mysidia]

Also, Submitting drivers to the Dev center now requires EV CODE SIGNING CERTIFICATE.
Even though Microsoft will sign the final result, you have to have an EV CERT from a small list of approved CAs to
sign your code before their portal will sign it per the new policy.

In case you have not noticed, the cheapest of the EV Certs is $1000 a Year; Only organizations can obtain these certificates, not individual developers.

Also, all EV Code signing certs require Smartcard/Token-Based Storage of your certificate's private key to ensure credentials cannot be shared, and you cannot automate the digital signing process.

Thus is a move to make sure Open Source software developers and individuals cannot produce Kernel mode drivers.

Re:Locking out open source hardware

[rsmith-mac]

Thus is a move to make sure Open Source software developers and individuals cannot produce Kernel mode drivers.

No. This is a move to further prevent kernel mode malware, because it turns out trusting developers wasn't good enough. That it impacts OSS is collateral damage - and something that can be dealt with, at that - as while OSS is popular here on Slashdot, it's not much more than a blip in the wider Windows world.

The whole reason we're even going this route is that trusting developer signed drivers has proven inadequate. Microsoft started requiring developer signatures (cross-signed) in Windows 7. This significantly cut down on driver based malware, but it didn't eliminate it entirely. It just raised the barrier to entry. Instead malware authors would just eat the cost and buy a certificate, or the especially crafty/evil ones would steal another vendor's keys, as we saw with the Realtek case. Either way Microsoft has had enough of it. and hence Windows 10 requires that they sign off on all drivers so that no one can just ship a (obviously) malware-infected driver.

I don't mean to be snarky/belittling here, but if you think that Microsoft is doing this as a strike against OSS, then you haven't been paying attention to the wider world. OSS on Windows certainly exists, but OSS projects that require kernel mode drivers are exceedingly few and far between. Which is not to say that OSS isn't a threat to MS to some degree, but that threat is from Linux, not OSS projects that require a kernel mode driver running under Windows. MS's prime concern is further reducing the ability of malware to hang out in the kernel space, as once malware makes it there it becomes virtually impossible to identify, contain, and remove.

And yes, this definitely makes signing harder for everyone. By all indications that's intentional, as EV Certs make it harder to hide (you have to provide more information) and are harder to steal/fraudulently use. There are ways to work with that for OSS though, just as was the case with Windows 7, so we'll be okay. As Bruce likes to say, security is a process; it takes more than just the OS vendor to keep Windows machines secure. So this is our contribution to that process (whether we like it or not).

Re: Worse and worse

[backslashdot]

Actually I think they are in cahoots with the movie and music ownership industry. This move is all about enforcing DRM.

Intel and AMD want Microsoft to make the OS have CPU busting features .. Like I dunno 3D animated window management, voice control, fingerprint recognition etc.

But this driver move, it seems entirely dreamt up by the DRM crowd. The don't want you to play any video or music that may be similar looking or sounding to anything they own. I mean the browser industry sold out already. How come when ads play in a browser the player controls are limited?

Re:Tied to Secure Boot...

[SuricouRaven]

One day they will decree that Secure Boot cannot be turned off. It would only be a continuation of an existing trend.

Re:How do I change a user's password

[Gadget_Guy]

I'm using windows 10 and I cannot figure out how to change a user's password.

The Anonymous Cowards who responded to you have given you the correct answers. It should be noted that the method for administering other local accounts has not changed since Windows 2000. You still use Control Panel->User Accounts as you did back then, although the method of getting to the control panel has changed over time. In Windows 10 you right click on the start button and choose it from the pop up menu.

The command line version of "net user username NewPassword" has not changed at all since Windows NT 4.0 (19 years ago). Of course, if you are not used to Windows then it is quite reasonable that you wouldn't know the command to use, any more than a Windows admin would magically know to misspell the word password on Linux.

Re: Worse and worse

[Miamicanes]

I can't speak for the original Xbox, but the Xbox 360 has a pretty respectable library of indie third-party games that can be installed through Xbox Live. In fact, the third-party indie games on my 360 outnumber the retail-boxed games about 3 to 1.

Unholy Heights is a riot.

http://xbox.com/indiegames

How to check

[WaffleMonster]

You can run sigverif from CLI to check to see what drivers are currently being used on your system not signed by Microsoft.

I welcome any legitimate reason for this behavior requiring Microsoft cross signing when secure boot is enabled. Currently I'm at a loss to come up with one.

It seems when secure boot is not enabled all signature validation can be bypassed by malicious code one way or another if you have admin rights by changing boot settings using bcdedit and rebooting or a million other approaches given admin level access. Signature checks don't have much bite in the real world with secure boot disabled.

With secure boot enabled any effective bypass of driver signature validation is a security bug. Since only kernels trusted databases are used for driver signature validation (regardless of secure boot setting) cross signing to MS is redundant. This is especially true given the blessings seem to be superficial at best and probably nearly fully automated given cross signing does not currently cost money.

Most likely reason for MS to do this I've been able to come up with is that without MS control anyone who develops a kernel driver and gets it signed by one of the supported CAs can break out of a Microsoft walled garden on systems where secure boot is being enforced against the user.

Even if you believe any and all measures to lock down kernel access improves security and therefore unconditionally good regardless of any other considerations... I still fail to see how any actual locking downing is being accomplished here as the MS blessing is superficial and adds nothing. Any malicious actor able to develop a kernel driver and obtain an EV cert is almost certain to also obtain blessing of Microsoft.

The only "benefit" seems to be MS getting a vote to stop execution of drivers paving way for restricting usermode execution against users. (See Windows RT and Windows Phone)

Re: Worse and worse

[Anonymous Coward]

Or, you know, it's to prevent viruses and other such garbage that has plagued windows for years and years, to be able to boot up with windows by masquerading as a driver?
I see nothing wrong with this. If anything it will force manufacturers to get their sh*t together and stop releasing buggy half baked drivers.

Re: Worse and worse

[jedidiah]

Drivers as a source of viruses? Talk about unreasonable. The fact that Microsoft's is Hollywood's BITCH is far more plausible.

Re: Worse and worse

[nmb3000]

Or, you know, it's to prevent viruses and other such garbage that has plagued windows for years and years, to be able to boot up with windows by masquerading as a driver?

Actually the GP is right, and Microsoft calls it out themselves:

To play back certain types of next-generation premium content, all kernel-mode components in Windows Vista and later versions of Windows must be signed. In addition, all the user-mode and kernel-mode components in the Protected Media Path (PMP) must comply with PMP signing policy.

Besides, the only way to install kernel mode drivers is to be running as administrator. If malicious code is allowed to run on your computer with administrative credentials, you're already screwed in any number of ways. Installation of a kernel driver is just one avenue.

I see nothing wrong with this.

I see everything wrong with this. Microsoft is now dictating what software can be run on my computer. That alone is enough of a reason to vehemently reject this, but think also of the F/OSS software impacted. There are plenty of software tools out there which run a driver as part of their operation and not all of these will want to or be able to get their drivers signed.

I have been trying to decide lately if I'll ever bite the bullet and move from Windows 7 to Windows 10, or if I'll start looking migrating to Linux. The decision just got a lot easier.

Re: Worse and worse

[Calydor]

That's a really nice [graphics|printer|pointer|raid] driver you've got there.

Would be a shame if something ... happened to it.