Code Signing with USB Tokens: A Comprehensive Guide
USB, hardware, or cryptographic tokens are portable devices that securely store cryptographic keys. These tokens typically connect to a computer or other devices via USB.
USB tokens offer a compact and convenient solution for storing and protecting sensitive cryptographic keys, certificates, and other credentials.
They are designed to provide strong encryption, tamper-resistant hardware, and secure key storage. USB tokens are often used when individuals need to authenticate themselves or perform cryptographic operations securely, such as code signing, digital signatures, or two-factor authentication.
What does this Blog offer?
The post will discuss:
- Implications of the new requirements on automated build processes The difficulties encountered when incorporating hardware-based certificates into such environments.
- Limitations and complexities of using physical hardware devices for code signing in automated workflows.
- How to navigate these challenges
- Alternative approaches or solutions that allow for smoother integration of hardware-based code signing certificates into automated build systems.
Overall, the blog post aims to provide guidance and recommendations for developers and organizations facing upcoming code signing certificate requirements changes.
Addressing the issues and offering workarounds aims to help stakeholders adapt to the evolving landscape of code signing. Also, to maintain efficiency and security in their development processes.
What are the General Types of Hardware Devices?
We will discover three significant types of hardware below to understand the process of signing the code with USB Tokens.
Network HSMs
Network-attached Hardware Security Modules (HSMs) are specialized devices that store cryptographic keys and perform cryptographic operations securely. These hardware devices are typically connected to a network infrastructure, allowing them to be accessed remotely by multiple systems or applications.
Network-attached HSMs provide a secure and centralized platform for an organization’s key management and cryptographic functions. They offer tamper-resistant hardware protection, strong access controls, and encryption mechanisms to ensure the confidentiality and integrity of cryptographic operations.
It connects to a network infrastructure, allowing it to be accessed remotely by multiple systems or applications. This connectivity enables centralized key management and cryptographic operations across an organization, making it an ideal solution for enterprises with distributed infrastructure or cloud-based environments.
USB Tokens
USB, hardware, or cryptographic tokens are portable devices that securely store cryptographic keys. These tokens typically connect to a computer or other devices via USB. USB tokens offer a compact and convenient solution for storing and protecting sensitive cryptographic keys, certificates, and other credentials.
Recommended: What is a Hardware Security Module? Role of HSMs for Digital Signing
They are designed to provide strong encryption, tamper-resistant hardware, and secure key storage. USB tokens are often used when individuals need to authenticate themselves or perform cryptographic operations securely, such as code signing, digital signatures, or two-factor authentication.
Cloud HSM
Cloud HSMs, or Hardware Security Modules as a Service (HSMaaS), are HSM devices offered by cloud service providers. These HSMs are hosted and managed in the cloud, providing a convenient and scalable solution for organizations that require secure key management and cryptographic services.
Recommended: What is a Cloud Hardware Security Module? How to Choose the Right Cloud HSM for Code Signing?
Cloud HSMs offer the same security and functionality as physical HSMs but eliminate the need for on-premises hardware infrastructure. They allow organizations to leverage HSM capabilities in a cloud environment, enabling secure cryptographic operations and key storage for cloud-based applications and services.
| Name of Product | Validation Needs | Issuance Time | Our Price |
|---|---|---|---|
| Cloud Code Signing as Service | Business/Extended | 1-5 Days | Know More |
| Azure Key Vault Cloud Signing | Business | 1-5 Days | $369.99/yr |
| Azure Key Vault EV Cloud Signing | Extended | 1-5 Days | $519.99/yr |
Why is Code Signing with USB Tokens Change necessary?
Code signing with USB tokens is necessary due to the increasing concerns surrounding the security of signing certificates digitally.
Recent incidents, such as the SolarWinds supply chain hack and the theft of NVIDIA’s code signing certificates, have highlighted the vulnerabilities associated with traditional file-based certificate storage.
These incidents have raised alarms within the industry, prompting organizations to reassess the trust and security of certificate issuance. Particularly for Microsoft, measures are taken by developers to protect these certificates.
Trust is a crucial element when it comes to certificates, as they guarantee the authenticity and integrity of software.
The proposal to change the requirements for how issued certificates are stored, which was adopted by the CA/Browser forum, addresses these concerns.
The change advocates using hardware-based solutions like USB tokens to store code signing certificates. This shift aims to enhance the security of certificates by making it significantly more challenging to steal hardware devices compared to files stored on traditional systems.
Significance of the USB Tokens or Similar Secure Hardware
Utilizing USB tokens or similar secure hardware dramatically reduces the risk of unauthorized access or theft of digital signing certificates.
Hardware tokens provide an additional layer of protection, as they typically employ strong encryption and tamper-resistant mechanisms.
This strengthens the overall security posture of code signing processes and mitigates the potential for malicious actors to misuse or compromise the certificates.
Recommended: What is Token-Signing Certificate?
In essence, the move towards code signing with USB tokens is driven by the need to bolster the security of code signing certificates and prevent unauthorized use or abuse.
It acknowledges the limitations of file-based storage and aims to establish a more robust and trusted framework for code signing by storing certificates on hardware devices that are more difficult to compromise.
As the industry strives to reinforce trust in certificate issuance and utilization, adopting hardware-based solutions for code signing certificates represents a logical and practical step forward.
It aligns with the overarching goal of ensuring software integrity and authenticity while addressing the vulnerabilities exposed by recent security incidents.
What are the Changes incorporated in Code Signing Certificates?
Starting June 1, 2023, new and reissued OV and IV code signing publicly trusted certificates must be issued. Also, you can store them on a pre-configured secure hardware device by the issuing certificate authority (CA).
These devices must meet stringent security standards such as FIPS 140 Level 2, Common Criteria EAL 4+, or matching criteria.
It is important to note that existing OV/IV certificates will remain functional. However, if you require a reissuance of your certificate, you may encounter challenges due to updated key size requirements. Therefore, it is crucial to safeguard your existing certificate and avoid its loss.
In practice, most certificate providers have already transitioned to issuing certificates on tokens or discontinued the sale of OV/IV certificates altogether.
This marks the end of the conventional practice of downloading a pfx file for code signing. The shift towards secure hardware devices ensures higher protection for code signing certificates, reducing the risk of unauthorized access and enhancing overall security.
Developers and organizations must stay informed about these changes to certificate issuance and storage requirements. Adapting to the updated standards and adopting secure hardware devices will contribute to maintaining integrity.
Recommended: Simplifying Code Signing Certificate Delivery Methods (Private Key Storage Options)
You can also have a trustworthiness of code signing processes, safeguarding digital assets, and mitigating potential security risks.
Locked In:
“locked-in” refers to securing cryptographic keys or sensitive data within a specific hardware device or security module. When a key or data is locked into a device, unauthorized individuals cannot easily extract or access it. This approach enhances the security of cryptographic operations by reducing the risk of crucial exposure or compromise.
Hardware devices such as HSMs, cloud HSMs, and USB tokens employ techniques to lock cryptographic keys, including encryption, physical security mechanisms, and access controls, ensuring the keys remain protected and isolated from external threats.
How to Set up a USB Token?
USB tokens used for code signing typically require the presence of the physical token (plugged into the machine) during the signing process.
Depending on the manufacturer or specific device, these tokens may utilize different client software or drivers. Despite these variations, the critical requirement remains: the USB token must be physically secure.
Although resembling a regular memory stick, the USB token plays a critical role in the security of code signing operations. It serves as a secure storage device for cryptographic keys and certificates, ensuring that only authorized individuals with access to the token can perform code signing tasks.
By requiring the physical presence of the USB token, the system adds an extra layer of security by preventing unauthorized access to the signing process.
However, there can be challenges when using USB tokens in specific environments.
For example, in the context of USB passthrough, which allows direct access to USB devices from virtual machines, Hyper-V Server does not support this feature. This limitation can complicate using USB tokens for code signing within Hyper-V Server environments.
Alternative virtualization platforms such as XCP-ng may be used to work around this limitation. XCP-ng supports USB passthrough, enabling the USB token to be accessed directly by virtual machines for code signing purposes.
Nevertheless, configuring USB passthrough in XCP-ng can be complex and time-consuming, adding potential hassle to the setup.
Steps to Set Up USB Remotely
Regarding alternatives for USB passthrough, VirtualHere (VH) is a highly recommended option that offers excellent functionality and competitive pricing. Unlike vendors who may not explicitly support code signing tokens, VirtualHere has been proven to work effectively with such tokens.
VirtualHere Server is compatible with various operating systems, including Windows, Linux, macOS, NAS servers, and even Raspberry Pi. The server license is tied to the host machine, so you must purchase an additional license if you decide to move the USB token to another host.
However, considering the affordable $49, it is unlikely to impose a significant financial burden.
- To implement VirtualHere, install the VH server software on your XCP-ng host and connect the USB token to the server.
- Then, on your Windows machine, install the VirtualHere client software.
- The client can automatically detect servers, but in cases where the machines are on different subnets, manual configuration may be required.
- Upon connecting to the VH server, a message box may appear when using the trial version.
- The client will display a tree of the USB devices connected to the server, including the SafeNet token called “Token JC.”
- By right-clicking on the token, you can select “Auto use this device,” ensuring automatic connection in the future.
- When the connection is established, the familiar Windows sound notification indicates the successful detection of a newly plugged-in device.
- Since the SafeNet software is already installed on Windows, it shouldn’t prompt for any additional drivers/ configurations.
By leveraging VirtualHere, you can overcome the limitations of USB passthrough and seamlessly utilize USB tokens for code signing within your virtualized environment.
The straightforward setup process and reliable performance of VirtualHere make it a viable solution for securely accessing USB tokens across different machines and subnets.
Further Challenges of USB Tokens
An additional challenge USB tokens pose during code signing is the requirement for human presence due to password prompts. This contradicts the principle of automating processes. However, a workaround specifically for the SafeNet token can address this issue.
To begin, open the SafeNet Authentication Client Tools and click on the Advanced View button (represented by a gear icon). You might be prompted to do so if you still need to enter the token password.
In the left-side tree view, right-click on the certificate (located under User certificates) and choose the “Export certificate” option. It’s important to note that this exported certificate does not include the private key on the USB token. Therefore, it can only be used on machines with access to the USB token.
In the certificate view, pay attention to two fundamental values: the Cryptographic Provider value (typically “eToken Base Cryptographic Provider“) and the Container Name (e.g., p11#xxxxxxxxxxx).
Unfortunately, the SafeNet Authentication Client Tools do not support clipboard functionality, so you must manually type out these values and save them for future reference. These values will be necessary for your build process for code signing.
While still in the Client Tools, select Client Settings and navigate to the Advanced tab. Enable the “Enable single Login” and “Enable single Logon for PKCS#11” options, and set the Automatic Logoff option to Never. Save the changes and close the client application.
By following these steps, you can configure the SafeNet token to minimize the need for manual intervention during code signing. The exported certificate and saved Cryptographic Provider and Container Name values can be utilized in your automated build process.
Enabling the single login and logon options ensures the token remains accessible throughout the signing process without continuous password prompts.
