Fears Windows code-signing changes will screw up QA process Changes introduced this week that mean code-signing certificates for Windows can only be sold in hardware form or run through a cloud-based "service" are continuing to be a concern for some developers. Industry trade body the Certificate Authority Security Council (CASC) decided in December that "best practice" for code- …
There's exactly zero chance that keying material is going to be used without the presence of two people during any process, not just code signing. That's the way I've always handled it as per regulations. It's not like there aren't a number of techniques that one can use to approach it in a low cost way. It's that people are imposing their convenience to override systems security which is why security fails happen.
Security is a process. Fuck up the process and you don't have security. If you don't believe me, theirs far too many security people who do this for a living. If you can't be bothered to take time out, drop by http://www.schneier.com and post on the Friday squid comments. Even during the weekend or following week. Ask one of the experts there.
Speaking of which, it's Friday. but alas no pint for me.
And sometimes the process gets too irksome. If you have to reach for and unlock three different doors just to get in and out of a place you frequently come and go every day, you'd start to consider that excessive, wouldn't you? Especially when you frequently do so with your hands full (where in the job description did it require such people to be jugglers). Security may be a process, but it has to compete with ease of use. Make things too difficult and people are going to go, "Screw this! My livelihood ain't worth this much hoop-jumping!"
While I understand the issue, most of our testing artifacts are signed with an internal certificate. The reason is we want to avoid testing executables look too much like production ones. Using certificates which are valid only on the tests systems is one way to spot them easily. It also means less people need access to the production keys.
Of course the final round of testing needs to ensure everything is ok in the full production configuration, and usually the accounts used for the automated builds can't get past the company fw/proxies, and run with as few privileges as possible. There may be also the issues of using more than one build machine, with a single device we'll have to build a separate signing server.
But at the same time, you would think such facilities (especially if under government scrutiny) would be able to afford better protection and safeguards. Sure, there is merit in doing it yourself, but are you willing to safeguard your "corporate jewels" with as much investment as a firm with a regular turnover in the nine-to-ten figures?
Those of us that write windows device drivers have suffered with this for a while. You get the best results* with an EV certificate, which only comes on hardware key. When your build server is locked in a server room, or is a VM, or whatever, suddenly everything becomes harder than it needs to be.
I like the approach taken by one of the major consultancies:-
https://www.osr.com/nt-insider/2016-issue1/today-in-driver-signing/ (see figure 6).
* a full description of when a non-EV certificate is acceptable is omitted for the sake of brevity and sanity.
Why signing "changes the binaries"?
It really sounds like some is reaching here.
Also, we have 25 million pieces of "malware that appear trusted because they are legitimately signed by valued code-signing certificates" (it appears that the adjective "valued" no longer has the meaning that it used to have). How does signature revocation happen? I hope someone knows.
One nasty one was signed with Realtek's driver key. Guess what else uses that key? The bulk of computer sound drivers today. Revoke that key and users suddenly lose their sound. That's probably why it was used: too much collateral damage to revoke.
Now imagine if a total own age malware was signed with the same key used to sign the Windows kernel...
There is no such thing as a "novel innovation". Well, OK, there is, but only if you are not very bright and/or English is not your native language (and neither is French, Spanish, or any of several others). All innovations are novel. That's what the word "innovation" means - a new thing. Just look at the word: it has three parts: "in" plus "nova" plus "tion". The "nova" part means "new". C'mon, you know this: "nova" = a new star; "supernova" = a bright new star; "novel" (in literature) a new story; "novice" = someone who is new at some task; "novitiate" = a new priest in training; "novel" (in general speech) = something new.
In fact, the meaningful parts of "innovation" and "novel" don't only mean exactly the same thing (something new), they are essentially the same word and come from the same source: "novus", which is the Latin for .... yep, you guessed it, "new".
What's really going on here, of course, is that corporation PR morons have used "innovation" in so many press releases and speils where it patently does not apply to anything or mean anything that they have forgotten that the word they misuse every working day really does mean something ("a new thing") and when, one shiny day, they actually want to find a word that really does mean "a new thing" they haven't got one 'coz they've worn out the old one so they have to ... er ... innovate ... and say "a new new thing". Or, in moron PR flack-speak, they have to come up with a "novel innovation".
CODE SIGNING has very very LITTLE effect on securing computer systems. But, it is a HUGE REVENUE POTENTIAL for Micro-shaft and their "partners".
Seriously, it's JUST ANOTHER TOLLBOOTH, some idiot with his palm sticking out demanding that you put MONEY into it, JUST to write something that you want to give away for FREE (aka OPEN SOURCE), or at a VERY LOW COST, or for a NICHE MARKET.
thanks a HELL of a LOT for NOTHING, Micro-shaft!
Linux and BSD have _NO_ _SUCH_ _REQUIREMENT_ and they're pretty secure. they're also OPEN SOURCE. There's NO TOLLBOOTH for THOSE operating systems. Only Micro-shaft would cook up THIS way of NICKELING AND DIMING people, passing the cost on to CUSTOMERS for "the big boys", or weeding out "the small fry" by RAISING THE ENTRANCE FEE.
There are more than just two ways to store the private keys:
- USB HSM, PCI HSM and Rackmount HSM. If you don't want to store on the cloud use an HSM, most CA's will include the USB HSM token with the code signing certificate. But you can also install a network appliance and then deploy the client out to all the ones who need to sign the code.
- TSM, this is stored securely directly on the system, if you need all your dev and QA teams to sign code often this is a really good option, you just need a system that has TSM ability
- Cloud HSM, lots of vendors out their besides AWS. Microsoft keyvault is super cheap and easy
- USB Drive... not the most secure but if you read the baseline requirements you will see that you must disconnect the drive when you're done signing the code to limit access.
Also if the CA determines you are not following the baseline requirements for code signing they will revoke the certificate. If the certificate is compromised than the CA will revoke and restrick you from issuing the certificate using again.
Code signing is highly dangerous if in the wrong hands, but as long as CA's continue to perform valid checks and are audited on their operations these new changes will greatly benefit the digital world.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
