true-Sign V

At the beginning of 2017, Microsoft increased the policy for code signing. Signature keys based on Extended Validation (EV) certificates must be generated and used in hardware with at least FIPS 140-2 level 2 certification. The goal is to ensure the integrity and authenticity of the applications and to reduce the potential for malware attacks.

true-Sign V

With true-Sign V, companies can easily create electronic signatures for programs, macros, scripts (code) as well as for PDF, Office, and other Windows applications. The solution is easy to install and can be used with Windows single sign-on. The data to be signed never leaves the user's PC. Only the hash value is sent. Confidentiality is 100% guaranteed.

PDF, Office, Java, PowerShell, Visual Studio, Advanced Installer

The true-Sign V service is hosted on-prem using a FIPS conform HSM.

Code Signing

Code signing is the process of digitally signing executables and scripts to confirm the identity of the software publisher and guarantee that the code has not been altered or corrupted since it was signed.

Publicly trusted certification authorities (CAs) confirm signers’ identities and bind their public key to a code signing certificate. The certificate is used to support validation of code signatures to a trusted root certificate in widely distributed applications such as Windows or Java.

CAs and browsers have developed standards to manage and issue code signing certificates. The standards ensure applications are verified and code signing specifications meet the latest cryptographic requirements.

CA security council - best practices

The challenge with code signing is the protection of the private signing key associated with the code signing certificate. If a key is compromised, the certificate loses trust and value, jeopardizing the software that you have already signed. The following table shows seven best practices for code signing:

Best practicesSecurity measures of true-Sign V and related processes
Minimize access to private keys
  1. Allow minimal connections to computers with keys
  2. Minimize the number of users who have key access
  3. Use physical security controls to reduce access to keys

true-Sign V can manage dedicated code signing certificates per user, application or per build server. The authentication towards the true-Sign V server is done based on X.509 certificates. The signature keys are created, used and stored in a FIPS 140-2 level 3 conform HSM.
Protect private keys with cryptographic hardware products 
  1. Cryptographic hardware does not allow export of the private key to software where it could be attacked
  2. Use a FIPS 140-2 level 2-certified product (or better)
  3. Use an EV code signing certificate which requires the private key to be generated and stored in hardware
true-Sign V supports EV code signing certificates. The signature keys are create, used and stored in a FIPS 140-2 level 3 conform HSM.
Time stamp code
  1. Time-stamping allows for the code to be verified after the certificate has expired or been revoked
true-Sign V supports code signature applications that include time-stamping. 
Understand the difference between test-signing and release-signing
  1. Test-signing private keys and certificates requires less security access controls than production code signing private keys and certificates
  2. Test-signing certificates can be self-signed or come from an internal test CA
  3. Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products; this precaution helps to ensure that test certificates are trusted only within the intended test environment
  4. Establish a separate test code signing infrastructure to test-sign pre-release builds of software

true-Sign V supports specific policies for test- and production certificates. It can be ensured that only dedicated build servers / applications can use the production certificate.
Authenticate code to be signed
  1. Any code that is submitted for signing should be strongly authenticated before it is signed and released
  2. Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code
  3. Log all code signing activities for auditing and/or incident-response purposes
Keyon supports the customer in setting up appropriate code signature processes, which also includes the separation of test- and production environment and the malware scanning of the code before being signed. Any signature activities are logged by true-Sign V.
Virus scan code before signing
  1. Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed
  2. Take care when incorporating code from other sources
  3. Implement virus-scanning to help improve the quality of the released code
Keyon supports the customer in setting up appropriate code signature processes which also includes the separation of test- and production environment and the malware scanning of the code before being signed.
Do not over-use any one key (distribute risk with multiple  certificates)
  1. If code is found with a security flaw, then publishers may want to prompt a User Account Control dialogue box to appear when the code is installed in the future; this can be done by revoking the code signing certificate so a revoked prompt will occur
  2. If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well
  3. Changing keys and certificates often will help to avoid this conflict

Keyon supports the customer in setting up appropriate certificate lifecycle processes. true-Sign V can manage dedicated code signing certificates per application or per build server. In addition code signing certificates may be renews frequently in order to not impact good code that has been issued in the past.

See additional true-Sign applications