How to safely Store your Private Keys
In this post we discuss the available ways to store Digital key material and the benefits/issues associated with each method along with the challenges posed by the continued migration to the cloud and the solutions that the providers have made available.
On-Premise Hardware Security Module
As outlined in an earlier blog post here for many years HSMs have been the de facto method for storing digital key material. The place as the default approach was rightly earned due to many reasons also covered in that previous post, some of the reasons for this default position are:
- HSM are dedicated hardware appliances specifically designed to be tamper resistant, providing high-levels of physical security with validation to FIPS 140-2 level 3
- Keys are stored within the HSM and cryptographic functions are executed within the device
- Being a dedicated appliance HSM the hardware is optimised for high performance
The HSM eco-system is also well matured with features and functionality such as:
- Programmatic access via standard interfaces such as PKCS#11, CryptoNG(CNG), JCE and others
- Support for all stages of the lifecycle of a Key from creation to Destruction
- Mature Management tools to simplify administration tasks
There are also some challenges with using on-premise HSM which need to be considered:
- Cost for both initial purchase and ongoing management
- HSM is always available and needs strict access control and logging implemented to control who and what can access. A HSM is normally installed into a “trusted” network segment to meet these requirements.
- Access control needs to be extended to the services or applications requiring access to the private keys to ensure that only authorised transactions are performed
- Audit trail is well defined but the output can be extremely verbose making correlation and interpretation of the logs a challenge
With the benefits of cloud computing becoming more apparent and the trend of migrating workloads to the cloud accelerating the challenges and limitations of deploying Hardware Security modules need to be considered. When evaluating whether to migrate applications that utilise HSMs to the cloud the feasibility may be determined by some of these factors:
- Does the chosen Cloud provider allow for customer hosted devices or provide a Dedicated HSM solution
- If operating in a hybrid model will network latency cause unacceptable performance of the cryptographic functions
- In a best-practice multi-cloud deployment can a set of common tools be utilised to reduce complexity
Many cloud providers have recognised and looked to address a number of these concerns by developing solutions for key management and HSM services in the cloud. These services offer the benefits of HSM with the flexibility of being SaaS solutions. We have talked about the AWS HSM offering here and the Microsoft Azure service here.
PKCS#12
PKCS#12 is a standard archive file format for storing cryptographic objects in a single file. A PKCS#12 file maybe encrypted and signed to ensure the CIA triad. The standard defines internal storage containers called “Safebags” these may also be encrypted and signed. There are a number of Safebags defined to store certificates, certificate revocations lists and private keys another Safebags is defined to store any other data as required by the implementer. You can recognise a PKCS#12 file by either the .pfx or .p12 file extensions and these types of files can be easily read using OpenSSL. PKCS#12 is a successor to the Microsoft PFX file although the terms are most often used interchangeably, the PKCS#12 standard is complex and as such has often been criticised although the file format is commonly used to simply store a private keys and its associated certificate chain.
There are a number of potential issues with storing your private keys in PKCS#12 files that need to be considered, such as:
- standard issues with passwords such as reuse, brute forcing and entropy
- ciphers are not specified meaning weak ciphers can be used
- potential reuse of encryption keys between the Safebags and the private keys
- PKCS#12 files are commonly stored in locations accessible by many people meaning they are highly vulnerable to password leaks
- No audit trail
Windows certificate store
Microsofts description of a certificate store is as follows: “On a computer that has the Windows operating system installed, the operating system stores a certificate locally on the computer in a storage location called the certificate store. A certificate store often has numerous certificates, possibly issued from a number of different certification authorities (CAs).”
There are a number of considerations that need to be taken into account when using Windows Certificate Stores:
- An audit trail of sorts is available but it requires computer admins to enable it and ensure that is configured to meet retention requirements
- Keys can be used by authorised users to create unapproved signatures without the clear text key
- Key export can be disabled but this requires the use of the Data Protection API (DPAPI) which introduces the reliance on password strength and secrecy to maintain the CIA triad of the stored keys
USB based HSM
There are many solutions available in the market for storing private keys on USB tokens, these tokens ensure that the Private key cannot be retrieved from the token itself. But the small form factor brings the additional challenge of requiring the token itself to be kept secure. The usage of the key(s) stored on the token usually requires the entry of a password or pin (or both) and comes with the associated challenges of managing the passwords in common with the other solutions outlined above. This requirement to enter a pin or password on use normally means that a USB Token is only really suitable to on-demand usage and not by any automated tasks. The availability of an audit trail also depends on the implementation and could mean that key abuse is hard to detect.
Key Vaults or Key Managements Services
A Key Management Service (KMS) is a service that is typically offered by cloud providers that enables clients to manage encryption keys without the hassle of provisioning or managing Hardware Security Modules. KMS solutions typically provides similar capabilities to a HSM offering centralised management of the lifecycle of the key material along with the ability to import and export existing keys.
The major cloud providers all provide KMS services under different names the offering from AWS is called KMS, the Azure solution is called Key Vault and the Google Cloud Solution is called Cloud Key Management.
There are common advantages to using the KMS offered by cloud providers, they are built on the well-established strengths of cloud platforms and therefore share the distinct advantages of the whole cloud methodology.
- Scalability: The cloud providers adopt the same philosophy around scalability for all services they provide built to cater for large scale data processing, flexible upgrades and downgrades and geographic growth options
- Availability: The cloud providers focus are making the underlying infrastructure highly available and make the services available in multiple locations in a region and also across multiple regions.
- Integration: The cloud providers design the services with native integration with other services in their offerings that utilise digital keys such as TDE for databases, IAM and more.
- Flexibility: Along with PAYG and flexible capacity, a number of provider also support Bring your Own Keys (BYOK) will allows the KMS to integration with on-premise HSMs which are used to store the master keys.
As with all solutions there are disadvantages the main one with KMS is that they are proprietary to each cloud vendor and therefore if you operate a multi-cloud environment the management overhead increases with each vendor as the keys for each vendor are managed separately. In a similar vain the SDK for interfacing with each KMS solution will be different meaning any proprietary software than needs to interface with the KMS will need to be developed to work with each cloud providers solution.
Summary
HSM remain the de-facto Gold standard for management and storage of key material. This level of security does though come at a price such as the cost of the hardware, training requirements and often the requirement for staff to have access to the device for certain operations and procedures.
The other solutions and options outlined in this post all provide valid methods of storing keys. Some of the solutions are much more secure than others and some are more appropriate for certain use cases than others. As with many decisions, you need to carefully weigh up the requirements and evaluate the advantages and disadvantages of each, to determine which is the most suitable and secure to meet your needs.
Need help with your HSM?
KT Secure have extensive experience using and managing Hardware Security Modules. Whether you are looking for advice on how to use a HSM in your PKI infrastructure, offload your cryptographic operations to a HSM or looking for someone to deploy and manage your HSMs we can help. Look here for more information about our HSM service offerings.
Although it may seem counter intuitive as to why an organisation may want to outsource the management of its HSMs to a third party – there are numerous business benefits:
- Staff costs saved on both initial training and on-going certifications
- Allows key Staff to focus on less admin related tasks and focus on higher end business processes
- Utilising external supplier may provide more rapid deployment and business agility than internal resources
- Ability to leverage external experience in best practices, process definitions and documentation support
- Reduces vendor or solution tie in by utilising external expertise
