How to sign code in the cloud after the new 2017 rules?

Question

It has come to my attention that code signing certificates are from now on required to be paired with physical tokens.

The Minimum Requirements specify that CAs shall ensure stronger protection for private keys. As such, all Code Signing Certificates, not just Extended Validation level, will require a USB token starting on January 30, 2017. With this, all New and Renewal Standard Code Signing orders will be sent a USB token to store the certificate and protect the private key. Also, all standard Code Signing products except for EV Code Signing will be integrated to one “multi-platform” Code Signing Certificate. Note: Reissues of existing Code Signing Certificates (issued prior to 30 January 2017) will not require a token right away. However, this is subject to change.

As someone who uses a cloud-only workflow, this raises an obvious concern for me - I cannot just plug this USB token into "the cloud".

Do I understand it right that I will from now on need to set up a separate on-premise code signing process? Or is there some possibility remaining for signing code in the cloud? What are the expectations I should have for working under the new rules?

Answer 1

Based on the article you linked it sounds like you will absolutely need to provide your build system access to a USB key in order to sign your artifacts. As you mention the obvious solution (and probably what Microsoft is attempting to encourage) is to set up an on-premise build system that gets used exclusively for code signing.

From a security point of view this is probably the best option since you could harden that machine both in terms of software but also in terms of hardware (e.g. locked in a closet in your work area). But this might also not be realistic depending how your build system is set up.

Your other option is to use a USB forwarding solution to forward the USB key to your cloud environment. There are a lot of ways to do this and the best one is going to depend on what you're building and on what operating system(s) but here's a rundown of some options:

• Linux systems - USB/IP - This is a kernel module and userspace application provided with a good number of Linux distributions (it's a mainline module, but not always included). This lets you take a local USB device and forward it over the network to another Linux machine. I've had pretty good luck with this but setting it up the first time can be a little tricky.
• Windows Systems - RemoteFX forwarding over RDP - On newer Windows systems (Windows 10, Server 2012 R2+) Remote Desktop supports USB redirection natively. You can simply forward the USB key through a RDP session. This would require you to remain connected at all times while building though.
• Windows Systems - Third Party Software - There are several third party USB forwarding solutions available. For instance this one. Some of these have the advantage of being able to run without requiring an active desktop session.

The gotca with all of these solutions is that if the USB token is designed to actively prevent this (or is somehow otherwise incompatible with forwarding) it may not work. Some license keys for instance will check to make sure the timings to/from the computer are within a certain tolerance for instance. In those cases the added latency from the cloud to your machine would cause the token to not work. It'll all depend on the USB key you get sent.

The whole point of policies like this is to prevent you as the keyholder from accidentally losing control of your key material by giving you something you must physically possess in order to use your key. Cloud build systems are convenient but tend in general to have a much wider security landscape which makes securing keys trickier than on-site systems. It looks like Microsoft and your CA are attempting to prescribe how keys are being handled.