The "Universal ADB Driver" for Android devices[1] also installs a root CA, however it instead generates the CA during install, signs the driver, deletes the private key, then installs the CA and driver.
That's madness.
I assume this is what ADB does, using the Microsoft provided WinUSB kernel mode driver and associating it with your mobile phone USB vendor and product ID. There's not a single line of code in such a driver, just some INF descriptors.
There might also be different forms of user mode driver, not sure how they work.
You mean a user-mode application? A user-mode driver is something you write instead of a kernel-mode driver (when it's possible), not on top of it. (?)
KMDF drivers have to be signed with a CA that's not user installed while UMDF drivers may be.
Or maybe forgot all the digital picture frames that hosted viruses.
Thanks to the folks at http://leshcatlabs.net/unifl-unified-leshcat-drivers/ i can put Windows 10 on old laptops with 'unsupported' old AMD and/or Intel gpu's.
When i was modifying my HTPC from Windows 8 to 10 i also experienced that annoying protection. I used the Cmedia BitPerfect drivers on my Windows 8 machine (https://code.google.com/archive/p/cmediadrivers/wikis/Bitper...) to have almost perfect DTS throughput, but couldn't use these on Windows 10 because not signed. The Leshcat people kindly provided me with a signed version.
- generate a fake CA and use it to sign your driver on the fly;
- add the generated root CA to the trusted list
- delete the private key so that nobody else can sign anything with this CA
- now windows will happily consider this driver as worthy of trust and install it.
And now this developer is learning on HN he should remove that line in his resumé.
Or maybe he thought it was a clever idea... Let's call it a learning experience.
If they had a single certificate and used that across devices then the private key could be compromised and used to authenticate malware or pull off a man in the middle attack on an HTTPS site since your system now trusts this new CA. By generating the private key locally and throwing it away, you can be relatively confident that no one has the private key to this new root CA.
What's silly in the first place is that something not trusted to install unsigned drivers still has the perms to install a new root CA but given that constraint, this is a better solution than what Savitech did.
If they had an actual root CA with a private key, they'd sign it locally (on the company machine). In no scenario would the company's private key be given to a customer (unless we're talking about Adobe).
But what do you want to do more?
1) Trust some company to keep a very important private key secure for a long time? (with attackers knowing it's a single high-value target)
2) Or be confident that the private key was used once and destroyed forever? Even if the private key generated on your device could be recovered it would only be good for an attack against you making it a lower priority to attackers.
Doing it that way completely undermines the reason for having a cert in the first place. You might as well not have one at all.
I'd still prefer the latter, given reasonable standards in terms of key handling, but the one-time trust is not completely without merit. It would certainly be more reasonable though to just allow one-time blind trust without forcing the installer to create a certificate that may or may not be as private as advertised.
I can't see how buying an actual cert could be more risky than installing a new root CA. The goal of signing is to ensure origin and anti-tampering: two fails in this case. So now you may have a tampered with driver that doesn't remove the private key and uses the new CA to inspect your TLS traffic, and you wouldn't know.
I don't. Not even Microsoft themselves. There were embarrassing slips.
Alternatively they would need to ship hundreds of different drivers or a single driver that binds to hundreds of different device IDS. Not nice.
I know what you're thinking "Oh, well there could be an exception for when you need it, you'd just use admin to authorize it or something" and that's exactly what this is.
That would be the relatively little known (and new) Windows 10 S, where only apps from the Windows Store can be installed or run. Designed for security (?) and to compete with Chromebooks.
See also Windows RT
Since they have a Chromebox, I do not have any calls regarding viruses or their computer being slow, etc.
Or people don't know/care. Or weighed the comparative downsides of a controlled app platform versus the wild west, and decided the controlled platform is less of a downside for what they want to do. Or lots of options, really.
The alternative is to add gpg keys of the software vendors that you trust. i.e., Every linux distro.
a) Adding a root CA to the cert store requires UAC elevation prompt.
b) The certificates are more useful in verifying if a given driver was issued by the manufacturer it says it was issued from.
Here are some public exploits for it: https://github.com/hfiref0x/UACME
Linux makes you type in the password manually every time for elevation but that will just make the average consumer remove or use unsafe passwords for their accounts.
The point is about a secure & safe way for a common person to authorize an application that wants to make changes to the system and as the defaults stand, sudo prompting for password at every elevation attempt is worse off in my opinion.
> The point is about a secure & safe way for a common person to authorize an application
I'm not sure that's even possible. The common person doesn't tend to fear putting their credit card info into a random online form.
To get a clean, professional-looking installation, you've got to have a primary signature that chains down to a trusted root CA and also a cross-signature, which is a Microsoft cert used to sign the code's root CA's certificate.
Maybe there's something I'm misunderstanding here. I've set up Windows codesigning, but it was according to the specifications of the Windows devs; most of my own work has been in Linux.
The distinction being made across the columns is between installing the driver (i.e. putting it in the right directory and setting up the settings and everything so that it can be loaded) versus actually loading the driver (i.e. telling the kernel to execute the code immediately). They require different permissions. You need to satisfy both for your driver to run, and you can see that MCVR is a requirement for loading a driver on newer Windows versions, i.e. you need trust from Microsoft, not just the user.
Now as some people are pointing out, Microsoft also has a user-mode driver framework which doesn't seem to have the requirements of the kernel module. (On the other hand, it exposes more limited functionality.) So if you're writing a user-mode driver then you might not need trust from Microsoft. But that's not what I generally mean when I say "driver"... to me "driver" implies kernel-mode, or at least the union of the two. It certainly doesn't just refer to the user-mode kind.
I ran into that last night. It was implied in the MS documentation that all kernel-mode drivers in Windows were "loadable kernel modules".
Anyhow, thank you for the clarification. That's kind of the direction I was thinking, but it's nice to see a more concrete description.
I'd also suspected that there was a distinction similar to "kernel-mode driver" and "user-mode driver", but all that I saw in Microsoft's documentation when I was looking last night were the descriptions of the differences between bus, device, and filter drivers.
Reading with a clearer head now, I found some more clarifying material. VxD was the earliest Windows driver model, supplanted close to 20 years ago by WDM. On top of that is the WDF, which sounds like it was first introduced just after WDM, and complementing it. And that's the one that has a separate Kernel-Mode Driver Framework and User-Mode Driver Framework.
From my background, "driver" always implied kernel-mode, unless specifically specified. I mean, I can write a user-mode driver on a Raspberry Pi (or what have you) to communicate with external hardware over the IO pins, but it's a clearly different process than writing a kernel module. For example, I could write user-mode driver code in Python, and don't have to worry about the internal workings of the kernel.
> From my background, "driver" always implied kernel-mode, unless specifically specified.
Right, so it seems correct to say that you cannot load a driver using just a custom root certificate. You need it trusted by a root certificate from Microsoft, which (assuming that is correct) means much of this thread is wrong.