The strength of many security controls hinges on your ability to protect a secret. As we all learned growing up, a secret can easily spread like wildfire once it’s shared, even to those who it’s most important to keep the secret from.
How you should protect a secret depends on the type of secret in question. At the broadest level, there are two types of cybersecurity secrets: those that you share and those that you don’t.
Shared Secrets & Unshared Secrets
An example of a secret that you share is a password. When you create an account with an application or website, you choose a password. Then you must provide the password every time you need to authenticate. This is considered a shared secret.
An example of a secret that you don’t share is a cryptographic private key. You use the private key to perform sensitive cryptographic operations (e.g., sign data, key agreement, etc.) but you never share this key with anyone else. In this case, the other party gets a byproduct of using your secret (i.e., receives signed data) but never accesses the secret itself.
Safeguarding Unshared Secets
An important property of non-shared secrets is that you don’t need to know your own secret. Of course, you possess the secret, but you don’t actually have to be able to read the secret yourself; you just need a device that can.
This allows for a useful security capability: storing these secrets in a non-exportable fashion, typically in a hardware-protected device. By doing this, your secret stays safe from outside attackers as well as insider threats. The most common method to protect these types of secrets is via a hardware security module (HSM).
An HSM is a physical computing device, often with tamper resistant protection mechanisms, that performs cryptographic operations without exposing its cryptographic keys. HSMs provide a high level of security.
Safeguarding Shared Secrets
For the other types of secrets— those that you do share— exporting the secret is a requirement. This method is, of course, more vulnerable to attack than a secret that is non-exportable, but sometimes it’s unavoidable. The most common way to protect these types of secrets is via a secrets manager. A secrets manager is a storage system that authenticated users can use to store and retrieve secrets like passwords, API keys, etc.
While secrets managers and HSMs generally serve two different (but similar) purposes, some secrets managers can strengthen their security by encrypting their secrets with a non-exportable encryption key from an HSM.
Given the many different security controls available, most enterprises have both types of secrets in their environment. Whenever possible, secrets should be stored in an HSM in a non-exportable fashion to strengthen the security of the environment. However, doing this comes with three challenges:
- Ease of Use – Interfacing with an HSM can be challenging, particularly for companies with limited cryptographic experience.
- Performance – Integrations that are improperly architected or implemented can have serious performance issues, especially when processing large amounts of data.
- Ease of Deployment – Deploying and maintaining a solution can be challenging, especially when it must integrate with existing infrastructure (e.g., IAM).
This is why we built GaraSign. When you deploy GaraSign, you can maximize usage of your HSM for all public-private key use cases without worrying about these challenges. A client-side hashing architecture keeps performance high while a multitude of client integrations makes GaraSign easy to deploy and use. You can continue to use all of the same tools and platforms you are using today, while relying on your HSM to secure the cryptographic keys for a variety of operations, from code signing and document signing to SSH, TLS, and more.