Overview
Since malicious code (viruses, ransomware, Trojans, etc.) is a serious threat to disrupt and financially harm organizations, it is imperative to authenticate code prior to use. Microsoft Authenticode reduces the level of risk and minimizes exposure to malicious code by defining a set of security zones, and associated rules, that determine code authentication and user notification within each zone. At the heart of authenticating code is the ability to determine if it originated from a trusted software publisher, or if it has been tampered with since it was published.
Microsoft Authenticode provides services that assist software publishers in establishing a trusted identity, and in digitally signing their code prior to publishing. The resulting digital signature allows recipients of the published software to both authenticate the author and ensure the code has not been tampered with.
To create a digital signature, the software publisher needs to acquire a code signing certificate. Depending on the application, the code signing certificate may be obtained from a commercial Certificate Authority (CA), certificate server such as Microsoft Certificate Server, or certificate appliance such as the BlackVault CA. To obtain a code signing certificate, the publisher must create a public / private cryptographic key pair. The public key is included in the signing certificate along with other identifying information.
The actual code signing process consists of creating a hash* of the executable software and encrypting this hash with the publisher’s private key (created above). It may also include a time stamp of when the code was signed. The encrypted hash, code signing certificate and executable are bundled together to become the signed code.
When the code is authenticated, the code signing certificate is verified, and the hash is decrypted using the publisher’s public key obtained from the certificate. A new hash is then computed across the executable and compared with the decrypted hash. If they match, the code is authenticated.
 
At the heart of this process is the private key created when the code signing certificate was generated. This private key must be kept secret by the publisher, because if compromised, it could be used to fraudulently sign malicious software which would appear as if it is from the trusted publisher. Best practices for protecting private keys ensure they can never be accessed in an unencrypted form and that operations performed with these keys do not expose the private key.
To meet these best practices, Microsoft Authenticode supports protecting keys within Hardware Security Modules (HSM). The BlackVault HSM provides physical and logical barriers to attack that do not exist with a software only security solution. It also provides multi-factor and Quorum authentication not found with USB and smart card tokens.
With the BlackVault HSM, key generation and digital signature operations are performed inside of the protected cryptographic boundary and private keys are never exposed. When private keys are backed up or transported outside of the BlackVault HSM, they are encrypted and the cryptographic material can be distributed across multiple smart cards for additional security. The BlackVault HSM is certified to FIPS Level 3, meaning environmental, electrical or physical tamper will result in deletion (zeroize) of the cryptographic keys. It’s long battery life also allows for transport and offline storage in a secure room or safe.
Engage BlackVault HSM
BlackVault is a compact cryptographic appliance with a unique color touch screen display, smart card reader, USB and Ethernet ports, and it supports all major cryptographic APIs. This includes Microsoft Cryptography API (CAPI) and Cryptography Next Generation (CNG) for seamless integration with Microsoft Authentication services. It also supports a wide variety of the latest cryptographic and hashing algorithms, including Suite B and elliptical curve cryptography.
In addition, the BlackVault HSM quorum feature prevents code signing and publication until the appropriate “sign-offs” occur. For example, if Product Management, Development, and QA are required to sign-off on a new release, each signatory would insert and authenticate their individual smart cards before the BlackVault allows the code signing operation.
Using the BlackVault HSM with Microsoft Authenticode ensures:
- Publishers’ private signing keys are secured with best practices FIPS Level 3 hardware security module technology;
- Use of private keys for code signing is performed within a FIPS Level 3 silicon based cryptographic boundary;
- The code release approval process is enforced by preventing code signing until an “M of N” quorum is present;
- Keys can be securely backed up on a BlackVault HSM clone;
- Simplified installation, configuration and operation with the BlackVault HSM’s touch screen color display;
- HSM authentication is not exposed to compromise from intermediary software or devices with the BlackVault HSM’s single trust path authentication capability.
Black●Vault HSM Authenticode Integration Guide
Black●Vault HSM
Authenticode
Integration Guide
© Engage Black
9565 Soquel Drive
Aptos, CA 95003
Phone +1 831.688.1021
1 877.ENGAGE4 (364.2434)
sales@engageinc.com
1. Disclaimer and Warranty
Engage Black is a business unit of Engage Communication.
©2016 Engage Communication, Inc. All rights reserved. This document may not, in part or in entirety, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without first obtaining the express written consent of Engage Communication. Restricted rights legend: Use, duplication, or disclosure by the U.S. government is subject to restrictions set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 52.227-7013 and in similar clauses in the FAR and NASA FAR Supplement.
Engage Communication makes no representations or warranties with respect to the contents of this document and specifically disclaims any implied warranties of merchantability of fitness for any particular purpose. Information in this document is subject to change without notice and does not represent a commitment on the part of Engage Communication, Inc. Product specifications are subject to change without notice. Engage Communication assumes no responsibility for any inaccuracies in this document or for any obligation to update the information in this document.
All intellectual property is protected by copyright. Engage Communication, Inc. and the Engage Communication logo are registered trademarks of Engage Communication, Inc. All other trademarks and service marks in this document are the property of Engage Communication, Inc. or their respective owners.
Engage Communications, Inc.9565 Soquel Drive Aptos, CA 95003Phone +1(831) 688-1021 https://www.engageblack.com/ http://www.engageinc.com/
2. Table of Contents
- Disclaimer and Warranty. 2
- Table of Contents. 3
- Introduction. 4
3.1. Supported Operating Systems. 4
- Procedure. 5
4.1. Integrate Authenticode with HSM... 5
4.2. Signing with Microsoft Authenticode and the BlackVault HSM... 9
3. Introduction
The BlackVault Hardware Security Module (HSM) integrates with Microsoft Authenticode to enable you to identify the publisher of a software component before it is downloaded from the Internet, and to verify that no one has altered the code after it has been signed. Microsoft Authenticode relies on proven cryptographic techniques and the use of one or more private keys to sign and time-stamp the published software. It is important to maintain the confidentiality of these keys.
The benefits of using an HSM with Microsoft Authenticode include:
- Protection for the organizational credentials of the software publisher.
- Secure storage of the private key.
- Signing code within a cryptographically secure environment
- FIPS 140-2 level 3 validated hardware.
3.1. Supported Operating Systems
Supported operating systems
OS Name | Version | 32 bit | 64 bit |
Windows | 7 | X | X |
| Server 2008 R2 x64 | | X |
| 8.1 | X | X |
| Server 2012 x64 | | X |
| Server 2012 R2 x64 | | X |
| 10 | X | X |
| Server 2016 x64 | | X |
4. Procedure
To proceed the following is needed:
- BlackVault HSM
- BlackVault Card Set
- BlackVault HSM Setup CD
- A client computer that has a supported Operating System installed.
Additionally, the BlackVault must be Initialized and Configured properly (see section 6.3 and 6.4 of the BlackVault HSM User Guide for more details)
To setup Authenticode with the BlackVault HSM:
- Initialize the HSM
- Run the Setup Wizard (included on the setup CD) to install the BlackVault HSM Libraries onto the client machine and configure Authenticode.
- Validate operation (i.e. create test key …. Etc.)
You can find information about how to initialize the BlackVault HSM in the BlackVault User Guide
The following assumes you already initialized the BlackVault HSM and are installing this software on a machine that does not already work with the BlackVault.
4.1. Install BlackVault Library and integrate with Authenticode
The BlackVault communicates over the network using PKCS#11. For Windows to communicate with the BlackVault HSM, the BlackVault HSM’s PKCS#11 library, CNG library, and pkcs.dat must be installed first.
- Copy the BlackVault Setup CD to a directory on your system. In that directory do the following:
- Run bv-setup.exe
- Windows asks if you want the installer to make changes to computer, select yes.
- The installer asks, “Would you like to configure the BlackVault for Java?” select yes or no.
b. If yes is selected, perform step 6
a. if no is selected, skip step 6
5. The first window you will see is the overview window. It goes over what will be installed. Select Next to continue.
- Next the installer asks for the Java directory currently being used on Windows. Browse for the desired top-level Java directory (usually in C:/Program Files/Java/jre8 or C:/Program Files(x86)/Java/jre8) then press next
- Next the installer asks for the BlackVault IP address and TLS Port. Enter those there and press next.
- Next, the installer asks for the location of the directory to install the necessary files to. Either use the default location, or to select a new location, click browse and specify the new location.
- Next, the installer asks for which components to install, the Engage BlackVault Cryptography Provider (CNG/
and PKCS#11 libraries), or just the PKCS#11 Library
- The installer then gives a summary of items to be installed press install to continue.
- The installer then installs all the components, including a Microsoft Visual C++ Redistributable (if not already installed)
- Once the installer finishes press finish.
4.2. Signing with Microsoft Authenticode and the BlackVault HSM
To perform code signing per industry best practices, along with creating and storing the key inside a secure HSM, a code signing certificate associated with the key is required. This section first describes how to create a key, and then how to create the certificate using a self-signed certificate authority managed by Openssl. If you require a chain of trust to a Certificate Authority (CA), replace the openssl commands with taking the CSR to the CA and have the CA sign your CSR.
For self-signed certificates, first download and install Openssl for windows found here.
- Create a key
- In a command prompt run the command: bvtool genkey -n NAME -t TYPE -s SIZE -c CURVE -x
- -n desired name of keys to be made
- -t type of key aes, rsa, ec, dsa, generic
- -s size of key if aes, rsa, dsa or generic is chosen
- -c curve name if ec is chosen
- -x use ANSI x9.31 for RSA key generation
- You do not have to use all of the arguments, only the relevant ones.
- Example:
- Bvtool genkey -n NANE -t RSA -s 2048 -x
- Bvtool genkey -n NAME -t EC -c prime256v1
- Create a certificate
- In a command prompt run the command: Certreq –new file.inf csr.pem where:
- “file.inf” is the inf file that specifies the key and other information about the key. For more information look at the “bvrsaex.inf” and “bvecex.inf” in section 5.1
- “csr.pem” is the output certificate signing request file.
- To use an existing key, in the .inf file, change “useexistingkeyset” to “true”.
- Create the Openssl CA using the following command:
- openssl req -x509 -newkey rsa:4096 -keyout rootkey.pem -out rootcert.cer -days 365 -subj "/C=US/ST=state/L=city/O=company/OU=division/CN=common name"
- Sign the certificate created in step 1 with the CA created in step 2 using the following command:
- openssl x509 -req -in csr.pem -sha256 -extfile usercert.cnf -CA rootcert.pem -CAkey rootkey.pem -CAcreateserial -out mycert.cer -outform der
- Import the root certificate and the certificate just generated into windows.
- To do this double click the CA certificate cer
- In the certificate dialogue box that shows up click Install Certificate
- The screen below is then displayed and select the radio button Place all certificates in the following store
- Select Trusted Root Certification Authorities and select
- Then double click the certificate created mycert.cer
- In the certificate dialogue box displayed, click Install Certificate.
- Now select the radio button Place all certificates in the following store
- In the new dialog box, click Browse.
- Then select Personal and click
- Run the command “bv_associate.exe”
- In a command prompt run the command “bv_associate.exe “Certificate CN” “key name” where:
- “Certificate CN” is the common name of the certificate installed
- If you need to find the common name of the certificate see section 5.2
- “key name” is the name of the key located on the BlackVault
- Sign a file.
- In a command prompt run the command: “signtool.exe sign /debug /s MY /n "Certificate CN” file.exe”where:
- “sign” is the call used to sign with signtool
- “/debug” turns on debug information, in case debugging is needed
- “/s MY” is the cert store, don’t change this field
- “/n “Certificate CN”” is the common name of the certificate, so it knows which certificate to use to sign the file
- If you need to find the common name of the certificate see section 5.2
- exe is the demo file to sign. Replace with any exe or dll file needing signature.
- Verify the signature
- In a command prompt run the command “signtool verify /v /pa pumpkin-2.7.2.exe”where:
- “verify” is the call used to verify with signtool
- “/v” means verbose, don’t change this field
- “/pa” is the default Authenticode verification policy, don’t change this field
- “pumpkin-2.7.2” is the demo file signed in the previous step. Replace it with the name of the actual file signed.
5. Appendix
5.1. .inf examples
The examples in this section show how certreq inf files should be formatted. Examples of a 2048 RSA key and a P256 ECDSA key are provided. For more information about certreq nad inf files please visit Microsoft documentation found here.
5.1.1. Bvrsaex
The following is an example of a 2048 RSA key. Simply copy and paste it (from [NewRequest] to UseExistingKeySet = false) into a blank notepad, change any parameters desired, then save the file as “file.inf” (where file is a name provided by you)
[NewRequest]
Subject = "CN=<Common Name Goes Here>"
KeyContainer = Key_Name_Goes_Here
HashAlgorithm = Sha256
ProviderName = "Engage BlackVault Cryptography Provider"
UseExistingKeySet = true
5.1.2. bvecex
The following is an example of a P256 ECDSA key. Simply copy and paste it (from [NewRequest] to UseExistingKeySet = true) into a blank notepad, change any parameters desired, then save the file as “file.inf” (where file is a name provided by you)
[NewRequest]
Subject = "CN=<Common Name Goes Here>"
KeyContainer = Key_Name_Goes_Here
HashAlgorithm = Sha256
ProviderName = "Engage BlackVault Cryptography Provider"
UseExistingKeySet = true
5.2. How to find common name of installed certificate
- Open a Command Prompt window.
- Type mmc and press the ENTER key.
- On the File menu, click Add/Remove Snap In.
- In the Add Standalone Snap-in dialog box, select Certificates.
- Click Add.
- In the Certificates snap-in dialog box, select My user account and click Next..
- In the Select Computer dialog box, click Finish.
- On the Add/Remove Snap-in dialog box, click OK.
- In the Console Root window, click Certificates (Local Computer) to view the certificate stores for the computer.
- Select Personal to view your personal certificates
- Click certificates
- In the windows that pops up, look for the certificate that has a little key in the image of a certificate
- In the column “Issued to”, this is the common name.