Enable hardware module support for code signing action

[schrolla]

💡 Summary

The current code signing key process used by ScubaGear relies on using a PFX certificate and private key to sign release code. Since this process was last updated, CA subscriber key protection requirements have been updated to include "verification for Code Signing Certificates’ private key generation and storage in a crypto module that meets or exceeds the requirements of FIPS 140-2 level 2 or Common Criteria EAL 4+ by the CAs. Include additional acceptable methods for verification including cloud-based key generation and protection solutions and a stipulation for CAs to satisfy this verification requirement with additional means specified in their CPS." As such, new certificates will need to be requested using a different process as well as the signing job using a new method to request signing via the hardware module protected private key.

Motivation and context

As the updated requirements affect commercial CAs issuing publicly trusted certificates and the current code signing certificate expires in late 2023, ScubaGear will not be able to continue signing releases until a new certificate is issued with a hardware protected key. Additionally, the new key cannot be used by the current signing GitHub action, so the action will also need to be changed or updated to support signing via the new key.

This would be useful because we want to continue signing PowerShell code so ScubaGear users do not receive warnings or errors running the unsigned code.

Implementation notes

Please provide details for implementation, such as:

• Review and determine full updated requirements
• Identify hardware module or service to house new private key
• Identify process and feasibility of accessing key via GitHub action for requesting signing
• Generate new hardware protected private key
• Request new code signing certificate
• Load new certificate into GitHub secret (and any other artifacts for accessing private key)
• Build and test GitHub action to use updated certificate and key for signing

Acceptance criteria

How do we know when this work is done?

• [x] New requirements for private key security are well understood by the dev team
• [x] Private key has been successfully generated in appropriate hardware module
• [x] Code signing certificate has been issued and received
• [x] GitHub configured with new certificate and key accessing credentials
• [x] Test release has been successfully signed by new certificate and verified via Authenticode
• [x] New code signing action added to main and release process updated to reflect its use

[schrolla]

Test release has been successfully signed with the new HSM-protected signing key and GH action to support signing updated to use it.