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.
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.
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.
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.
Alternatively they would need to ship hundreds of different drivers or a single driver that binds to hundreds of different device IDS. Not nice.