Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Windows Microsoft Operating Systems Security Software

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

"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.
This discussion has been archived. No new comments can be posted.

All Windows 10 Kernel Mode Drivers Must Be Digitally Signed By Microsoft

Comments Filter:
  • by supernova87a ( 532540 ) <kepler1@NoSpaM.hotmail.com> on Sunday July 31, 2016 @10:43PM (#52618921)
    You cannot imagine how excited I am to be submitting my drivers to the Windows Hardware Developer Center Dashboard portal. Talk about boner killer.
  • by JeffOwl ( 2858633 ) on Sunday July 31, 2016 @10:51PM (#52618957)

    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: (Score:3, Interesting)

      by jhol13 ( 1087781 )

      Actually I think this is a good thing as It forces device developers to make "driverless" devices.

      • Tempted to mod this funny. Not sure if you're serious.

    • Re: (Score:2, Troll)

      by Darinbob ( 1142669 )

      Just last week, Windows 7 rejected a driver from modern software. Guess the company was small enough they didn't want to waste the periodic license fee just to license their driver. Which means we did a really goofy workaround that puts the VM image into test mode every time it boots up. Sure, maybe we're in the minority but to have Microsoft as the gatekeeper is ridiculous - they're expensive as well as highly untrustworthy.

      It means any new device that comes out will be unable to be used on Windows with

      • "I mean they're OUR machines, we should be able to do whatever we want with them."

        Your machine? Not any more.

      • ...they're OUR machines, we should be able to do whatever we want with them.

        Not in Mordor.

    • What if you're a developer but aren't paying tax to Microsoft? Which is a lot of developers. Plus a lot of machines that are needed to develop, test, support, train, and so forth, just for a single device being created. Every device out there started life unsigned by Microsoft.

      If Microsoft cared about customers then they'd do something to protect the untrained users, whereas devices and drivers aren't the things that get most users into trouble. Biggest hole are probably web browsers, the service.exe, et

  • by ndykman ( 659315 ) on Sunday July 31, 2016 @11:22PM (#52619037)

    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.

    • by SuricouRaven ( 1897204 ) on Monday August 01, 2016 @01:00AM (#52619307)

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

  • Gee thanks (Score:5, Insightful)

    by JustAnotherOldGuy ( 4145623 ) on Sunday July 31, 2016 @11:28PM (#52619063) Journal

    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.

    • by AmiMoJo ( 196126 )

      It's a trade off between security and supporting fairly old hardware. For most people this is a good decision, because it protects them from malware that uses kernel mode drivers. Such malware can be very hard to detect and get rid of. How is your AV scanner going to find the infected file when calls to the filesystem are intercepted and filtered, and the same with the list of running processes and loaded drivers?

      It's pretty rare that I see hardware without a Microsoft signed driver these days anyway. Does

    • Why are you running obsolete hardware on a Windows 10 device? For that matter, why are you running obsolete hardware on Windows?
  • by mysidia ( 191772 ) on Monday August 01, 2016 @12:13AM (#52619205)

    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.

    • by sl149q ( 1537343 )

      If you have a consulting firm you can get an EV. Yes about $1000/year.

      Yes it is on a token so it can't be easily shared or stolen. Or if stolen you'll be aware of the fact so you can have it cancelled and get a replacement.

      You can login to the token once and then have automated builds that run signtool against it repeatedly. It is still painful as the request/answer from the token is slow, takes a second or two extra to sign anything. So if you are doing multiple signing during your build it will slow down.

    • by rsmith-mac ( 639075 ) on Monday August 01, 2016 @05:16AM (#52619989)

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

      • by LichtSpektren ( 4201985 ) on Monday August 01, 2016 @08:34AM (#52620853)

        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 [slashdot.org].

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

    • by AmiMoJo ( 196126 )

      In case you have not noticed, the cheapest of the EV Certs is $1000 a Year

      First hit [globalsign.com] on Google has them for $410/year, and obviously stuff signed doesn't expire after that time (only the ability to sign new stuff does).

      Only organizations can obtain these certificates, not individual developers.

      Incorrect. The developer of vJoy, for example, recently acquired one to sign his open source kernel mode driver. Did a little fund-raiser to get $475 (he used someone more expensive). He's just an individual, not a company.

      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.

      Incorrect, you can configure Visual Studio to auto-sign your driver every time you build it using the USB device they supply included in the cos

    • by cdrudge ( 68377 )

      In case you have not noticed, the cheapest of the EV Certs is $1000 a Year

      Digicert [digicert.com] has them for $224 for 1 year, or $165/year if you buy a 3 year cert. If you're serious about distributing a kernel mode driver, $165 shouldn't be too big of a hurdle to overcome even for a non-commercial organization.

  • 1. Upgrade: MS wasted tens of millions of manhours worldwide with their all-but-forced upgrade
    2. Telemetry: They listen to you using your computer
    3. Ads: They push ads [pcworld.com] at you via the OS, taking over what remains of your attention span
    4. Kernel Mode Drivers: No more can your programs manipulate Windows 10 internals (bye bye www.colinux.org)
    5. UEFI Secure Boot: No more can you boot another OS on a Windows 10 tablet or mobile device. For now, you can do so on a desktop, but manufacturers now have the 'option' [pcworld.com]

  • by bickerdyke ( 670000 ) on Monday August 01, 2016 @02:20AM (#52619509)

    While the posters here are correct (at large) please don't forget that at the same time, MS has always been urged to close malware attack vectors. So, as Master Yoda would put it: Do or do not. There is no "/. won't complain".

    • While the posters here are correct (at large) please don't forget that at the same time, MS has always been urged to close malware attack vectors. So, as Master Yoda would put it: Do or do not. There is no "/. won't complain".

      Don't be daft. Android and macOS by default restrict any third-party installations, but that setting is very easily disabled by the user; thus both of those ecosystems can be simultaneously free and secure.

      This here is Microsoft restricting their platform by racketeering against hardware providers.
      br

      • Never said something else.

        What I said was that if Microsoft wouldn't do that, you just had some other mob complaining that MS makes it too easy for malware to circumvent installation restrictions by including "install instructions" telling the user to disable them so that the malware can be installed....

        Agreed, users who fall for THAT probably deserve to have the machines pwned, but nonetheless, some people would require MS to include some foolproof installation restrictions that the users can't duped into

  • by allo ( 1728082 ) on Monday August 01, 2016 @02:48AM (#52619571)

    I thought you need signed drivers at least since windows 7 and this is one of the reasons why for example andlinux isn't available anymore?

    • by ledow ( 319597 )

      You do not "need".

      You can still override and install an unsigned driver on Windows 8.1, let alone 7, and the early versions of 10.

      On a domain, you can group-policy it out of being an option, but it's an option on all previous versions of Windows to let the user allow unsigned drivers at will.

  • by sshir ( 623215 ) on Monday August 01, 2016 @03:57AM (#52619775)
    So the next time Kaspersky finds a properly signed rogue driver we would know that the hardware vendor was cooperating. Would it create a liability?
  • by jonwil ( 467024 ) on Monday August 01, 2016 @04:44AM (#52619889)

    I am not a fan of the fact that you need to spend big money on an expensive certificate, more money on setting up a legal entity that will satisfy those organizations who can issue the right EV code signing certificate that Microsoft will accept and even more money on all the required hardware to actually test your driver or what it means for open source software but this move DOES have some benefits.

    It reduces the amount of crappy drivers out there (both because of the testing and because entities who are making crappy drivers tend to be the ones who dont want to spend the money on certificating and signing).

    It also makes it harder for anyone wanting to create kernel level malware since either Microsoft will refuse to sign it in the first place or Microsoft will revoke the signature (and blacklist the creator of those drivers).

    The increased requirements in terms of the code signing certificate you need to submit drivers to Microsoft also eliminates problems with rogue code signing certificates (i.e. all the times when a code signing certificate was stolen from a major hardware vendor and used to sign malware or other bad things)

    I do wonder what this means for government/law enforcement/intelligence agencies though. We know from various leaks and other things that governments and their agencies have used kernel drivers (or things that can only be done with kernel drivers even if its not actually explicit that kernel drivers are being used) as part of their spying/hacking/law enforcement efforts. Will the NSA be given the ability to sign a kernel driver that can run on a standard Windows 10 install? What about the Chinese Government (the censor-ware they wanted to force PC manufacturers to install on new PCs almost certainly requires kernel-level code to do the things it does). Or the German Bundespolizei? (the spyware they have reportedly used to spy on things like Skype may well need kernel code in order to do its job)

  • How to check (Score:5, Insightful)

    by WaffleMonster ( 969671 ) on Monday August 01, 2016 @05:18AM (#52619997)

    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)

    • by swb ( 14022 )

      I ran this on my Win 10 laptop and came up with only signed drivers.

      I think 2012r2 has required signed drivers, and there's some Texas-two-step you can do to put it into developer mode and ignore driver signing, which is only useful trying to get drivers loaded for a marginal use cases. In my case it was to get an Intel non-server OS NIC driver for the motherboard to load in Win2012r2 with a hacked INF file since Intel won't allow the drivers to load in server OSes.

  • by Mascot ( 120795 ) on Monday August 01, 2016 @05:30AM (#52620029)

    From Microsoft's FAQ: "Enforcement only happens on fresh installations, with Secure Boot on, and only applies to new kernel mode drivers"

    In other words, disable secure boot and it's business as usual.

    From my point of view, this increases security for the vast majority of users who just buy a computer in a store and need to be protected from themselves. If you don't know enough to disable secure boot, you probably have no business installing unsigned kernel mode drivers anyway. But if you do, you can.

  • Will this disable OpenVPN (and maybe other VPN software)? Last I checked, they relied on an unsigned virtual network driver.
  • Microsoft is getting closer and closer to the walled garden.

    but since this is Slashdot:

    M$ = bad
    Apple = good

Keep up the good work! But please don't ask me to help.

Working...