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.

Tied to Secure Boot...

[ndykman]

Right now, if secured boot is off, this policy doesn't kick in. That may change of course. For the vast majority of Windows users, this is fine, but for power users, kind of a pain.

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:Locking out open source hardware

[LichtSpektren]

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

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.

Yes. You're exactly right. You're right because Microsoft themselves signed malware that would otherwise have been ineffectual.

Anybody who ascribes altruistic motives to this is simply wrong. It's about racketeering developers, not security.

Re:Breaks TrueCrypt?

[Z00L00K]

You should use Veracrypt instead, but your question still stands open.

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: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.

This is a big deal, but not the Apocalypse

[WalrusSlayer]

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607

Trust me, as a driver developer, this has been causing me an immense amount of headaches, and Windows 10 is only part of the story.

But the blog entry has a key detail which nobody here seems to understand. Existing Drivers signed by a certificate that was issued prior to July 2015 will still be accepted by the kernel. What this means is that the new rollout is not going to cause the entire ecosystem of Windows legacy drivers to implode. If they were signed correctly for 64-bit Windows before, they will continue to work on Windows 10. Really, truly, I've tested this myself on preview editions of the Windows 10 AE

Where you get screwed is when a vendor needs to update a driver going forward. Then things get to be hairy. Logistically, signing became much harder, everything from obtaining a certificate to performing the actual signing. Pain. In. The. Ass.

Our company just released an update of our product just under the wire of when our legacy "get's a free pass" certificate expired so that we'd have some runway to incorporate the new driver signing nightmare into our tool chain. So we're good up until the next showstopper bug comes along, which fortunately is rare. You'll be able to use our latest release just fine on AE, even though it didn't get signed by Microsoft.

Re: Worse and worse

[Anonymous Coward]

As an owner of a computer service company who works on everything from residential to multinational corporation computers, I can say that I have not run into driver based kernel space malware more than a couple of times since I started my company in 2001.

This will not prevent hardware makers from releasing buggy drivers. It has absolutely NOTHING to do with the quality of the driver.

This is simply a means to force consumers to purchase NEW hardware to replace their old reliable still working fine piece of hardware because there is no longer a driver for it. It is simply a way for MS and their partner hardware manufacturing companies to separate consumers from their money.

Re: Worse and worse

[Anonymous Coward]

This is a complete non-issue for anyone that actually needs to run unsigned drivers.

Hobbyist developer: Disable the setting in your machine, unsigned drivers work fine.
Business with obscure/legacy hardware: Generate your own signing key pair, sign the driver yourself then push your public key to all users machines by GPO.
Real driver dev: Generate local signing keys for test, get key from MS and apply to WHQL for release.

This is a security setting that is on by default, but easily disabled or worked around by anyone with the knowledge to safely do so.

Re:The technologically impaired

[jedidiah]

...and all of that is unadulterated bullshit. The underlying operating system is FAR more dangerous because it's a piece of shit engineered to spy on the user. It's always been a piece of shit because Microsoft always puts marketing and other "business" objectives ahead of the product (far ahead). They only reason anyone uses their virus infested product is because they managed to corner the market in the days of MS-DOS.

The fact that the OS is swiss cheese is far more of a problem than "the user making the wrong choice".

If you're gotten to the point of showing such obvious contempt for the end user then you're doing it wrong.