Driver Signing changes in Windows 10, version 1607 | Hacker News Reader

Driver Signing changes in Windows 10, version 1607

blogs.msdn.microsoft.com

52 pointsdoppp40 comments

For one of my previous employers, I was in charge of getting drivers for some of our custom in-house hardware working on Windows 7. This hardware was never sold on any open market, only used by company employees on company-imaged systems. We didn't want to bother with sending the hardware off for the standard consumer-level certification, so I was able to get a code signing certificate from a third-party vendor and use a cross-signing certificate to get a driver that would work.

I tried to check out this dashboard that they're talking about, but it doesn't look like I can get it without being associated with a registered company. I am wondering how hard it would be under the new policy to do something like this again - what's the cheapest and simplest way to get a driver that will work with a fully secure Windows 10 install? Including if the hardware associated will never be sold to the general public?

It's probably moot in the particular case I dealt with, at least. I doubt the company in question will be upgrading to 10 anytime soon, plus the hardware in question was being slowly phased out. It used Firewire - the guy who chose that told me that it seemed like a good idea at the time - and I had already done the testing for the replacement device which used TCP/IP over Ethernet instead.

But I still wonder if it's getting gradually harder to do anything with any kind of custom hardware without already being part of a multi-billion dollar company that's willing to invest millions of dollars in getting hardware and drivers properly certified.

Yet another reason to use Linux/BSD. Literally anything but Windows.

>Literally anything but Windows.

While in the case of general software that would be true, its not really useful to do that in the case of drivers because someone has to maintain the source code across kernel ABI/API changes. Its just easier on Windows.

It's an interesting question. I think a lot of it is that these days custom hardware can talk a well known protocol or three and use standard drivers more easily than ever before. There are lots of options among the various standard USB profiles (pretend to be a flash drive or at worst a keyboard), Bluetooth profiles, and beyond that the general ubiquity of TCP/IP over just about anything from USB/Bluetooth/Ethernet/WiFi/Carrier-Pigeon/...

Look at the maker movement and you see just about even the cheapest PCB boards these days (*duino and the like) has an Ethernet port and probably even WiFi or at least Bluetooth LTE. A Raspberry Pi is a few dozen dollars and has WiFi.

It's easy to mock a lot of the "Internet of Things" enthusiasm, but the real benefit is that custom hardware these days isn't so much about low level kernel hacking to build drivers but is almost all "user space" work like REST services over IPv6. It's an interesting new world and probably an improvement on the days of bit-twiddling serial buses slightly different for every bit of custom hardware ever connected to a computer. (...and even that today you can still do with USB standard serial device profiles and writing an event-driven app in user space rather than build your own interrupt-driven driver.)

If you control the hardware you can always use WinUSB. No drivers required.

Probably yes - though pragmatically, you could also check if you actually needed a kernel-mode driver for your hardware to work - especially if it's in-house only and a slightly more complicated deployment process is acceptable. Some possibilities would be:

- If you can modify the hardware, equip it with an ethernet/wifi/bluetooth module and talk to it via IP.

- if you need kernel-mode access, you could develop a linux driver instead, run it in a VM (or a raspi) and communicate with the windows PC using IP. (Admittedly, that's a bit rube goldberg-ish)

- Communicate using the good old serial interface instead and use a user-mode program/library on windows.

There were some good points about this on Slashdot. The biggest one is that it costs at least $1,000 to get a driver certified by Microsoft. (And someone also suggests that it's really only open to organizations and not individual developers.) So this could change things in ways we haven't foreseen....

https://tech.slashdot.org/story/16/07/31/2146234/all-windows...

The $1000 figure has nothing to do with Microsoft, and will fall.

At the moment there are two kinds of commonly available certificates, EV certificates, and non-EV Code Signing certificates. But rarely do the two meet.

This scheme, per the Secure Boot standard, requires an EV Code Signing certificate which as of the time of writing is only sold by five vendors.

In the future as these become more in demand we should expect to see prices fall. The requirements to get any EV certificate are the same, and flagging it for code signing is free, so there's no real reason any EV certificate cannot also be a code signing certificate.

I doubt it will fall below $100-200 ever however, as that is how much EV certificates cost and the process is similar.

edit: DigiCert already sell them for $224-165/year: https://www.digicert.com/friends/sysdev/

Getting less and less able to run what we like on our own machines without someone elses permission...

There is nothing stopping you from running your own drivers, but you either have to turn safe boot off [1], or you have to test-sign the driver [2]. This is a completely reasonable change for 99% of users (because it will stop them from installing a malware driver), and there are well-documented ways around it for the 1% of users that need to side-load drivers.

[1] OP, under 'How do I sign drivers during development and testing?'

[2] https://msdn.microsoft.com/en-us/windows/hardware/drivers/in...

And what do open source projects do?

The kind that develops ext2 drivers for windows, or pcap, or so on?

Does Microsoft pay the costs for the EV certificate for all of those? That’s quite generous of them.

I doubt MS will pay the costs for all open source project out there that want to ship signed drivers.

Certum seems like a reasonable solution (14 EUR).

https://en.sklep.certum.pl/data-safety/code-signing-certific...

The 14 EUR Open Source Code Signing product can't be used to sign drivers.

It's typically for signing your MSI's and miscellaneous executables before distribution.

I disagree. I think Microsoft's current driver policies are unreasonable. Most end-users don't want to run their PC in testing mode, and will look for an easier way around it. This has a negative effect on free and open-source software. For example, there is software out there that allows you to use Playstation 3 controllers with your PC. In the past, there were pretty much two software solutions for Windows. One driver was unsigned, and the other was signed. Many people used the latter because it was much easier to get working. The problem is that it also installed alongside Chinese malware. Driver signing didn't save anyone there. If anything, it made the issue worse.

So your complaint as far as I can understand it is - both solutions are imperfect. Well, great ! I do think you're conflating 'reasonable' with 'perfect'.

Actually, my complaint is that if you go through the effort of manually disabling driver verification checks at boot time, Microsoft should respect your decision and allow you to persist that decision for that driver, even if you reboot and turn verification back on. They don't, and instead give you an all or nothing approach, with the nothing approach being a hassle and leaving a permanent watermark in the bottom right corner of your display.

> Microsoft should respect your decision and allow you to persist that decision for that driver, even if you reboot and turn verification back on.

If you have a whitelist, then malware authors would ship a primary driver that is signed and "clean". This clean driver just changes the whitelist so other malware can be executed without signature checks. I would suggest you first model the threat, model your response and analyze the different approaches.

Free and open source software can still be signed.

Not really if it costs $1000.

It doesn't cost $1000 even today, and as EV Code Signing certificates become more popular the price will fall.

A non-Code Signing EV certificate is "only" $100-200 right now from tons of vendors. All we need is for them to flag it for Code Signing which is "free."

Until you convince those CAs to start signing for code, they still cost $400+. And remember, that's per year. The driver will continue to function after that year, but they will either need to cough up another $400 the next year, or cease development. Even at $100-200 per year that's still an unreasonable cost for hobby projects.

Open source software of any complexity costs far more than that to develop, assuming you assign non-zero value to opportunity cost. Your time is valuable!

I've been writing https://github.com/pjc50/pjc50.github.io/blob/master/pentagr... on this phenomenon.

The weirdest thing is how there's a different policy for machines that have been upgraded vs new installs. Sounds like trouble for new customers trying to install random old hardware down the road.

Does anyone know the status of drivers using WinUSB[0] under this policy?

Also, have there been many instances of malware in device drivers recently that would require a tightening up of the rules?

[0]: Microsoft's user-mode USB driver, which did (IIRC) need a signed .inf file but you didn't need to submit it for validation since all the actual code was Microsoft's (https://msdn.microsoft.com/en-gb/library/windows/hardware/ff...)

Once malicious code gets into the kernel address space, the sky is the limit. I don't think it matters if there has been one or a million occurrences of kernel-space malware.

Look for more details on "ModPOS" for a particularly disastrous one.

Code using WinUSB runs in user-space, so you don't need a custom kernel driver. This policy doesn't affect WinUSB at all.

There goes my ability to use adb/fastboot/emergency download on the Xiaomi Mi4c - although, that phone never had signed drivers and did something strange during install to make it work.

I believe Koushik Dutta (koush/clockworkmod) signs adb drivers for this reason.

You may want to doublecheck the inf to see if your device's usb VID/PID are listed.

So, I took advantage of the "free" upgrade of a couple of "Professional" level licenses, at the last minute.

I'm left wondering whether and for what timeframe I can legitimately "downgrade" back to Win 7 Pro, if I need to.

I initially thought I had an open-ended option to. But the other day, I saw brief and incomplete mention of a 30 day window.

I just can't keep up with the dribbling of fractured news/information, so... asking this of anyone already familiar with this aspect of the "downgrade" question".

I don't have a need to, right now. As it is, those Windows partitions mostly sit idle. But if I only have 30 days to go back (while keeping a future 10 re-upgrade possible / tied to those licenses), then maybe I'd better do so, now, as a hedge against e.g. some legacy driver issue that may crop up in the future. Especially as I would intend to do a fresh Win 10 installation for each of those licenses, eventually (negating any "it's already on the system" grandfathering Win 10 may continue to permit).

I think once you have upgraded to Windows 10 with a particular license, you're free to do a clean reinstall of Windows 10 using that license without any problems.

That's my understanding, too. And I plan to take advantage of it, eventually.

For the moment, the upgraded partitions/installs are "going back to sleep" on hard drives being popped out and set aside.

They'll come back out the next time I need to deal with e.g. Adobe Creative Suite, or some family need aka Mom project.

You can legitimately downgrade anytime; your Win 7 license is still valid (just not to be used at the same time at 10, since the Win 10 license is an upgrade license). You can then re-upgrade to Windows 10 at any point, as long as it's on the same hardware (either doing a clean install using your Windows 7 key or no key, or doing another upgrade install).

The 30 day window is the period of time where you can uninstall and revert to 7 from within Windows 10, without having to do a clean install of 7. Windows 10 removes files from the old version of Windows after 30 days.

Thank you. Exactly what I was looking to understand. :-)

I think you have 30 days before it deletes the Windows.OLD directory in C:\

FOSS drivers would have solved this problem.

Finally. Windows is catching up.

To whom in this case?

Apple maybe? They're pretty good at making sure you don't get to use hardware they don't approve.

Windows has had some form of driver code signing since 2003.

I happen to think it's mostly stupid, but you can't say it's behind.

Reply on news.ycombinator.com