Fears Windows code-signing changes will screw up QA process

Developers remain unconvinced by CASC's novel innovation

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-signing certificates was to embed them in hardware devices, a policy endorsed in changes by Microsoft that kicked in on 1 February.

The CASC told El Reg that keys for new certificates could be stored on USB hardware keys or held in the cloud at Azure Key Vault. It conceded there may be teething issues but played down suggestions that the changes might overly inconvenience developers, as previously reported.

The Reg reader who flagged up the changes, and asked to remain anonymous, is far from reassured by this reply. His concerns center on how the changes sit alongside the practice of automated quality assurance (QA) in code development.

"The cheap hardware is the USB key, which doesn’t have to be FIPS or Common Criteria compliant," he said. "However, you're required to keep that separate from the machine that does the code signing except when you are actually signing. This assumes, very strongly, that signing is a manual process, done after QA, as the last step before shipping.

"The problem with that is that signing alters the binaries. And if your QA is the least bit strict, that means you need to retest it after signing. This wastes a lot of time, especially for agile processes when you're shipping updates frequently. So if you have automated QA, you end up needing to sign everything that you might ship, before starting to test it."

Our reader expressed doubts whether commodity USB keys would be fit for purpose.

"If Microsoft offered some really strong assurances that signtool.exe can never break binaries, and backed that with penalty clauses, people might trust it," he said. "But as it stands, they don't. So if you automate your build process and your QA process, as everyone wants to, you end up needing to automate your signing too, between those steps. And that means you need the expensive kind of HSM (hardware security module)."

El Reg ran this point past Microsoft for clarification. We'll update this story as and when we hear more.

In response to our initial story, another reader said its suppliers were still offering to sell them old-style certificates. "That doesn't seem compatible with the clarification from the CASC, so I suspect that those vendors either aren't members of the CASC, or haven't caught up with events," our tipster told us.

Third-party security vendors have praised the changes as overdue.

Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, a developer of technology that secures and protects cryptographic keys and digital certificates, commented: "The move by Microsoft to require consistent vetting and security practices for code-signing certificates was long overdue. There are almost 25 million pieces of malware that appear trusted because they are legitimately signed by valued code-signing certificates. Whether due to poor CA issuing practices, fraud or theft, the misuse of code-signing certificates was beyond epidemic proportions."

Every Windows computer, mobile device, and even most new IoT devices rely on code signing to validate which software is trusted. Enforcing strong security practices for issuing and using code-signing certificates is therefore important especially as we enter an era of rapid code development and DevOps, according to Venafi.

"Securing code signing will mean not just storing a key in a safe place but also protecting the entire process," Bocek explained. "The rise of DevOps means that people aren't involved but instead machines, a new possible target for attack. New secure, automation methods, not just protecting keys in hardware, will be required to live up to Microsoft and CA rules for businesses signing code." ®