My team uses a certificate to sign our Windows Application. Unfortunately the Certificate is expiring soon and we need a new one. We want to avoid the SmartScreen that pops up when installing apps signed with new certs and I am reading that EV Certificates come with built-in reputation. Microsoft provides a list of authorities that sell code-signing certs, but from my understanding all of these would be a physical device that one of the devs would have to keep at their house. We don't want that. Is it possible to have something on the cloud that we can all use?
Is it possible to have an app EV Code Signing Certificate on the cloud?
2.4k Views Asked by SaiyanGirl At
2
Yes, it is possible to do EV code signing in the cloud without requiring a physical dongle that you keep with yourself. In fact, we do this at my company. Here is how:
For #1, there are several options including AWS CloudHSM, AWS KMS, Azure Key Vault, Google KMS, Entrust's nShield as a Service, Thales' DPoD, etc. They all have various pros and cons so you need to know your technical requirements ahead of time. Two items to definitely know are the list of signature algorithms the signing tools you use require and your CA's attestation requirements.
Some tools like signtool allow you to specify the hash algorithm you want to use. Unfortunately, other tools don't give you an option and you are stuck with the hardcoded hash algorithm. Two examples are Apple's productsign which currently uses SHA-1 under the hood for one of the signatures it produces and Microsoft's VBA Macro signing which uses MD5 under the hood. Not all of the KMS offerings support all these algorithms and, until they do, you would not be able to sign with those algorithms and your key wouldn't be useful (most only support SHA-256, SHA-384, and SHA-512, although Azure Key Vault does support RSNULL which allows you to get around this).
For key attestation, depending on your CA, you may need to provide an attestation for your key that chains up to a hardware root of trust, which only some of the HSM/KMS providers support. Other CAs may allow you to show them your cloud environment remotely (e.g., via Zoom or something) to show that the key is protected in hardware, and others just require you to sign a document stating that your key is protected.
Price is the next obvious factor. Some charge per hour (or other time unit) that the HSM is on, while most of the KMS options charge a small fee per key and per usage. Generally, if you only have a small number of keys, one of the KMS options will be the cheaper and easier choice. But once the number of keys grows, a dedicated HSM might become more cost effective.
After you pick your cryptographic device, you will need to integrate your signing tool with it. This is done with a cryptographic provider. Providers are unique to the platform you are signing on. For example, on Windows you need a KSP (or a CSP for legacy systems), Java/Android requires a JCE provider, macOS uses a CTK provider, OpenSSL uses the Engine framework (although that change in their latest release), Linux uses a mix of GPG and PKCS11, etc. Some HSMs provide some of the cryptographic providers, but not all. The KMS options don't have them at all and you're left writing your own code.
Then there is the issue of authentication/authorization, performance, auditing, and more. You will eventually find yourself in the boat where you want to auth/authz via your identity provider (e.g., Active Directory, Azure, etc.), you want client-side hashing to improve performance, you want all kinds of audit requirements, etc. For these reasons, and others, we use a tool called GaraSign for all of this which provides everything we need out of the box. Here's their code signing page.