Hardware Token and HSM Code Signing for Private Key Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The upcoming change in code signing standards requiring private keys for certificates to be stored on hardware certified as FIPS 140 Level 2 or Common Criteria Evaluation Assurance Level 4+ poses challenges for developers, including ensuring secure use of keys and addressing psychological concerns about loss of physical possession.

Innovation Solution

Utilizing hardware tokens in conjunction with a Hardware Security Module (HSM) for code signing, where the HSM hosts the private key but the token is physically held by the developer, enabling access through mechanisms like one-time passwords or secondary nuances.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If private keys are stored on cloud-based HSM, then security and compliance with FIPS 140 Level 2/Common Criteria EAL 4+ requirements is improved, but developer control and psychological ownership of private keys deteriorates

Engineering Contradiction:
Improveprivate key securityVSAvoiddeveloper control
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The system segments the private key access into two distinct components: the HSM that stores and protects the private key, and the hardware token that provides user authentication. This segmentation allows the private key to be securely stored in a compliant HSM while maintaining developer control through the separate hardware token that must be physically presented for signing operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The hardware token acts as an intermediary between the developer and the private key stored in the HSM. It provides a physical authentication mechanism that mediates access to the private key, ensuring that only the authorized developer can trigger signing operations while the HSM maintains secure storage and compliance.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Object-affected harmful factors

If private keys are stored outside developer's physical control, then security against unauthorized access is improved, but developer trust and psychological ownership deteriorates

Engineering Contradiction:
Improveunauthorized key accessVSAvoiddeveloper trust
Core Design Contradiction:
Object-affected harmful factorsVSReliability

Solution Approach 1:

The system provides feedback to the developer through the hardware token authentication mechanism. When a signing operation is requested, the system checks whether the developer has physically presented their hardware token, providing immediate feedback on authentication status. This feedback loop maintains developer trust by confirming their ownership and control over the signing process.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The developer maintains self-service control through the hardware token that they physically possess and control. The token enables the developer to authenticate themselves to the HSM for signing operations, ensuring that they remain in charge of their own private key usage without requiring third-party access or compromising their psychological ownership.

Inventive Principle:
Principle #25Self-service

3Reliability

If hardware token is used with HSM for code signing, then security and developer control are both improved, but system complexity increases

Engineering Contradiction:
Improvecode signing securityVSAvoidauthentication system
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system merges the HSM and hardware token into a unified authentication framework where both components work together seamlessly. The HSM handles cryptographic operations and key storage, while the hardware token provides physical authentication, combining these functions into a single code signing process that maintains security without requiring separate complex systems.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS12547773B2Utilizing hardware tokens in conjunction with HSM for code signing
Publication Date: 2026.02.10 DIGICERT INC
  • US12547773B2 patent drawing
  • US12547773B2 patent drawing
  • US12547773B2 patent drawing

AI summary

Utilizing hardware tokens in conjunction with a Hardware Security Module (HSM) for code signing includes, subsequent to storing a private key of a developer, receiving a request to sign a digest of software from the developer; receiving an approval from the developer to enable use of the private key; and responsive to the approval, encrypting and signing the digest utilizing the private key to attest the software is from the developer. The steps can further include, responsive to failing to receive the approval, denying the request. In this manner, a cloud based HSM approach can be trusted similarly to a physical hardware token approach, as well as providing the additional security benefits of an HSM over a physical hardware token.