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 DigiCert® Secure Software 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?
First, we have introduced native support for the GPG Keyring in Secure Software Manager (SSM). 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.
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.
Key compromise is a low to non-existent risk when using a signing solution like SSM. 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.
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 SSM 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 SSM via the SSM-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 SSM-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:
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 SSM so that customers who have security concerns about how safe GPG master and subkeys are protected today can migrate those flows to SSM 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.
Learn more about the GPG feature at https://www.digicert.com/content/dam/digicert/pdfs/datasheet/ssm-gpg-datasheet-en.pdf and about Secure Software Manager at https://www.digicert.com/signing/secure-software-manager.
DigiCert® Secure Software Manager in DigiCert 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. Secure Software 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 Secure Software 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 DigiCert ONE, Secure Software 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.