������

We are all familiar with the expression “square pegs don’t go into round holes.” Well, for a time, we experienced this problem with code signing. Our customers were asking us to solve for round hole and square hole problems and all we had to offer were round pegs. What I mean by this is that for a time, we could support only the standard keypair construct (a private key and corresponding public key) on ������^® Software Trust Manager: this was our round peg. The standard keypair model (our round peg) fit perfectly for customers who had standard code signing use cases (customers’ round hole). But what about the use case of GPG signing and the GnuPG ecosystem’s support of the Keyring model construct? This was our square hole problem, and up until now we have had little option but to offer customers the round peg standard keypair solution to this square hole problem.

Tired of hearing about pegs and holes yet? OK, I’ll drop the metaphor and focus on the signing use case relative to GPG Keyrings and standard keypairs. So what have we done and why is it important?

DSTM-native support for GPG Keyring & easier key management

First, we have introduced native support for the GPG Keyring in ������ Software Trust Manager (DSTM). GPG keys are different from standard keypair because each GPG key includes a master key and associated subkeys. The GPG Keyring therefore has a hierarchical structure of its own where the keys are related rather than relying on a certificate hierarchy. While there are no technical differences between a master key and subkey, the responsibilities of these keys remain separate to enhance security.

List of GPG keys

Download Keyring

It is recommended that the master key only be used for creating subkeys and the subkeys be used for signing. If a subkey is compromised, this will allow you to revoke and replace the affected subkey, while the master key and uncompromised subkeys remain secure. The identity of the key is associated with the master key; therefore, if the master key is compromised, the master key and all associated subkeys must be revoked and replaced.

View details page of master key and associated subkeys/user ID:

CLI showing list GPG keys, sign and verify all using DSTM-SCD:

Key compromise is a low to non-existent risk when using a signing solution like DSTM. But there are other benefits to signing with remotely stored keys which a signing solution can offer, such as segregation of roles and responsibilities (who should manage the master key and which users are delegated access to the subkeys to for signing purposes). This is of great benefit for those looking to leverage the GPG Keyring model for current and future signing use case with Linux signing types like GPG, RPM, Debian, Redhat Docker and many more. Protecting and limiting access to the master and subkeys has been a challenge for users in this regard, and so the age-old problem of balancing security and automation has been something developer teams and infosec orgs have debated time and time again.

From open source SCD to ������’s DSTM-SCD — enables additional OS

The next problem we solved was to remove the dependency on an open source library which needed to be compiled by end users and was limited in terms of where it can be used and limited in feature. Until now DSTM leveraged the opensource smartcard daemon (SCD) called GnuPG-pkcs11-scd, which users needed to compile from source code in order to bridge a path back to the signing keys protected DSTM via the DSTM-PKCS11 library. This dependence on GnuPG-pkcs11-scd limited our GPG signing offering to Linux OS but also constrained our key algorithm to RSA due to the opensource library not supporting ECDSA or EdDSA key types.

To solve this problem, we decided to remove the dependence on the open source SCD and build our own DSTM-SCD. This provides us with the opportunity to make setup easier and improve the feature set for customers wanting to do GPG Signing securely, for instance:

1. The SSM-SCDs come compiled and ready to go, no compiling needed by the customer, so they can just deploy it to their environment, and this will only get replaced if we need to patch to introduce new functionality or fix an issue.
2. The SSM-SCDs works for Linux, Windows and Mac. We also intend to tailor the Linux versions to specific Linux OS types for optimal performance.
3. The SSM-SCD comes with support of RSA, ECDSA and EdDSA Key types, meaning customers can choose the best algorithm for their use case and not just limit them to RSA only.
4. The SSM-SCD is coded directly to the SSM GPG specific rest APIs, which support the GPG Keyring pubring construct, allowing users to get started signing with SCD deployment and download the pubring keyring (public keys only, no private keys) for users with permission to do so.

All said, this new functionality offers SSM customers with Linux signing requirements the ability to support natively GnuPG ecosystem and GPG keyring model while benefitting from the security controls, key protection and management, hash signing workflows and the capture of all audit and signature logs relative to Linux signing activities in an optimized way for GPG, RPM, Debian and newly supporting GPG Keyring signing support for Git Commits (signing your source code commits in GitHub and other code repositories) as well as now supporting Open Container Interface (OCI) standard by using Podman from RedHat.

All that, while still maintaining full automation capabilities and no change to the way in which they have implemented GPG signing up until now. We will also be supporting the import of GPG Keyrings into DSTM so that customers who have security concerns about how safe GPG master and subkeys are protected today can migrate those flows to DSTM to deliver the same automated signing experience, with the added confidence that the process is secure and robust.

So regardless of what type of signing challenges or problems you have going forward, square hole problems or round hole problems, we have the pegs you need.

DSTM tools repository:

Learn more about the GPG feature at /content/dam/digicert/pdfs/datasheet/ssm-gpg-datasheet-en.pdf and about ������ Software Trust Manager at /software-trust-manager.

About ������ Software Trust Manager

������ Software Trust Manager in ������ ONE™ is a modern way of managing code signing by enabling automated security across Continuous Integration/Continuous Delivery (CI/CD) pipelines with portable, flexible deployment models and secure key management. ������ Software Trust Manager supports code signing best practices like unique key and certificate per signing for private signing, on-demand keys and rotating keys. It is compatible with major platforms and libraries like Docker, Microsoft, Java, Android and more. Using ������ Software Trust Manager, enterprises integrate code into their product development processes easily, while delegating cryptographic operations, signing activities and management in a controlled, auditable way. As a part of ������ ONE, ������ Software Trust Manager offers a quick deployment of high volumes of certificates within minutes plus the flexibility the deploy across on-premises, in-country, or in the cloud.

��