(2 votes, average: 5.00 out of 5)
The following procedure will demonstrate how to generate a Code Signing Certificate request using a key generated and stored in the YubiHSM 2 using the Key Storage Provider (KSP). You can use the Microsoft “signtool tool” to digitally certify Windows binaries with this code signing certificate.
Let’s take a closer look at the foundational concepts covered in this article before we start the procedure.
Software developers securely and digitally sign software programs, drivers, executables, and apps using Code Signing. This assures end users that an unauthorized party has not tampered with or compromised the code they obtain.
A Code Signing Certificate provides a digital signature to a piece of software, verifying its authenticity and enabling the detection of any modifications made to the code. A software publisher certificate or a Code Signing Certificate enables the security of the software and prevents unauthorized access.
YubiHSM 2 FIPS is a cryptographic hardware security module designed for server usage. It finds extensive usage in creating, protecting, and maintaining cryptographic keys that secure sensitive information, identities, and applications. It not only minimizes risk but also ensures compliance with regulations.
With High quality, Rapid Integration, and Easy Management, the YubiHSM SDK 2.0 is currently available as open source; organizations can quickly and simply add support for the secure HSM to a variety of platforms and systems for both present and future use cases where robust security is essential more than ever.
Key Storage Providers (KSP) enable to storage and retrieval of keys. For instance, if you would like to generate a new private key for your certificate authority (CA) and add the Microsoft Active Directory Certificate Services (AD CS) role to your Windows server, you could select the KSP that manages key storage.
A wide variety of storage options, including hardware-based storage devices, cloud-based storage, and software-based solutions, are frequently provided by key storage providers. To further secure the private keys, they might additionally provide extra security measures like multi-factor authentication and encryption.
In this illustration, we’ll make use of the command-line certreq utility. If you want a UI experience, you can access all the methods described here using the Certificate Manager (certmgr.msc) MMC snap-in.
Generally, the KSP will make use of slot 1’s factory authentication key. First Configure the KSP with the required key ID and password if usage of a different authentication key is requested or the factory authentication key is no longer valid.
It should be noted that the specified authentication key has at least one of the capacities that follow: generate-asymmetric-key, sign-pkcs, & delegated capability sign-pkcs. Add the exportable under-wrap delegated capability if you would like the created key to be exportable.
Generate a new authentication key that can produce exportable asymmetric keys using KSP.
yubihsm> put authkey 0 0 "GenerateKey" 1 generate-asymmetric-key,sign-pkcs sign-pkcs,exportable-under-wrap password Stored Authentication key 0x0e32
To define your request, you must provide a.inf file as input to the certreq utility.
Pass the certificate request configuration file to certreq as the input file argument after you’ve finished creating it, for example:
certreq -new sign.inf sign.req
The certificate request in the previous instance was written to sign.req. Grab the file & submit your CA with its contents for signature. Once the file has been signed, install the certificate in the personal store by opening it (for example, sign.crt).
Make use of the following command to sign your binary after opening a prompt with signtool in the path.
> signtool sign <binary name>
It can be required to determine your code signing certificate with hash if you have many certificates available. If this happens, the signtool will display valid certificates list. Just restart the sign tool using the certificate’s sha1 hash:
> signtool sign /sha1 <certificate hash> <binary name>
It might be necessary to manually hook the certificate to the private key while importing the certificate for the very first time on a new machine. As Windows doesn’t instantly create a connection between the key and the certificate since they are not stored together.
Make use of certutil utility offered by Windows to connect the YubiHSM private key to the certificate after importing it into your personal store.
> certutil -repairstore my <certificate hash>
> signtool sign /v /debug <binary name> After EKU filter, 1 certs were left. After expiry filter, 1 certs were left. After Hash filter, 1 certs were left. After Private Key filter, 0 certs were left. SignTool Error: No certificates were found that met all the given criteria.
> certutil -verifystore my <certificate hash> ================ Certificate 0 ================ Serial Number: 029fe48291dd587c1e6f42bca341291 ... Certificate is valid.
> certutil -csplist Provider Name: YubiHSM Key Storage Provider
> certutil -csp "YubiHSM Key Storage Provider" -key YubiHSM Key Storage Provider: tq-75c94c4b-5e40-4e44-bcd2-ee3330d4942f RSA AT_SIGNATURE
> certutil -store my <certificate hash> ================ Certificate 0 ================ Serial Number: 029fe48291dd587c1e6f42bca341291 ... Private key is NOT exportable. Signature test passed.
In conclusion, utilizing the Key Storage Provider to create a code signing certificate is quite a simple procedure that provides additional security and protection to end users’ software products. Customers can be sure that their software is secure and trustworthy, and their trust will enhance by working with a reliable certification authority and following industry standard best practices.