All You Need to Know about Securing Your Private Keys

Introduction

Private keys are one of two kinds of keys generated in a public-key infrastructure (or PKI). Private keys must be kept confidential by their respective owners while public keys are made available to everyone for users to initiate encrypted communication.

Private keys are important for two reasons: 1) they help with decryption and 2) they are blindly trusted by all PKI trust stores in the market, from browsers to operating systems. Therefore, when a private key is uncovered by malicious actors, valuable data is compromised through the impersonation of an enterprise’s servers. In fact, in their 2018 SSL Threat Report, zScaler reported a 30 percent increase in encrypted payloads that used fake certificates with valid digital signatures.¹ Unfortunately, many enterprises are still not taking the proper security measures when it comes to safeguarding their private keys. They’re still using inefficient – and often non-compliant – manual key management processes that leave their most valuable data susceptible to theft.

So, how should enterprises properly safeguard their private keys? Before we get to that, it’s important to understand the mechanics behind a cyber-attack.

A Sample Cyber Attack

First, let’s look at the Hacker Payload. This can be made up of an Exploit Kit, which runs on a web server to exploit vulnerabilities in the client machine or through a Trojan, which can be disguised as a legitimate software or a rootkit, which enables administrator-level access on a network, or an adware, which can use hidden malicious codes that execute upon clicking an ad or a M-I-T-M – which can hijack a session between two machines using various vulnerabilities in the protocol.

Next, how do the hackers deliver this payload to their target? Usually through phishing emails to unsuspecting employees, through rogue company insiders (current or former), or through malicious websites designed to imitate legitimate ones. Once the payload enters the enterprise PC, they can use an internal vulnerability – such as an outdated VLC, Skype, Flash, Windows or a protocol-level vulnerability in Chrome. The most famous example of this kind of hack is the WannaCry ransomware that infected more than 300,000 computers worldwide.

After the vulnerability is identified and exploited, the hacker gains access to valuable data like user credentials, certificate private keys and SSH keys, often found in mails and chat logs due to poor control over key provisioning. From there, if the stolen keys give them access, the hackers will pivot to other systems to steal even more until they reach the Goldmine, the administrator’s system. So, how do you stop the cycle? The most effective way would be to stop the hacker even before he reaches the network, but this is nearly impossible given the inevitabilty of the occasional software vulnerablities. The next option is to render the compromised private key data useless by changing the contents post-breach quickly or to adopt a secure way of storing and provisioning all private keys in the network.

Let’s explore some options further.

How Can I Protect My Private Keys?

Though the private keys still need to make their way to the end device, there are still 3 ways to guarantee the safety of your private key inventory in an administrator’s system:

1) Limit the storage of private keys to a few computers and restricting access to these computers – How do we restrict access? Use your directory systems to restrict user access. Though this method is effective, it’s the least preferred on our list due to poor access control.

2) Encrypt the private keys and store it in a password-protected folder – This leaves the hacker to first brute-force the password and then decrypt the private keys. By this time, the breach will be identified and the key contents will be changed and revoked. This method – while also effective – still leaves much to be desired when it comes to the need to scale.

3) Storing the private keys in a secured location such as an HSM – An HSM or a hardware security module is a device that safeguards and manages valuable data in an infrastructure either by encrypting it or making it impossible to be retrieved. This method is highly recommended in terms of scalability and security level.

Though these are very good approaches to safeguarding your private keys, there is still a factor limiting their success – error-prone manual implementation. With 85% of enterprises today managing their digital certificates through spreadsheets and other free utilities, scaling the approaches above to fit your existing digital certificate management program becomes complex.

Apart from just making it logistically difficult to protect, regulate access and securely provision your private keys, there are a couple of other drawbacks associated with manual management – one of which is less visibility across certificates. Why is visibility important? Let’s look at a recent notable example – the SHA1 migration. When the industry moved to SHA2, all certificates with deprecated signatures had to be migrated before the browser deadlines. Given the chances of introducing undocumented or rogue certificates are higher when using risky manual management methods, what if your team couldn’t migrate all deprecated certificates before the imposed deadline? Browser warnings and the threat of a security breach would seriously impact your business – both from a cost and reputational standpoint, especially if your applications were to go down in the process. So, what’s the solution?

Automation.

By automating each stage of the certificate lifecycle – from generating key pairs to issuing certificates to renewing those certificates – you reduce management complexity and nearly eliminate the chance for costly human errors in each step of the way. You can also rest easy knowing a simple plan for the protection of your private keys is in place, making your preferred automation solultion an invaluable addition to your security posture.

Automated Digital Certificate Management with AppViewX

AppViewX’s Certificate Lifecycle Automation is a one-stop solution for the automated discovery, expiry alerting, renewal, secure provisioning and revoking of SSL/TLS certificates with granular role-based access regulation across multi-vendor infrastructures. The private keys and passwords of each and every certificate in the infrastructure are safeguarded using an AES-256 encrypted database, making it impossible for any hacker to extract their contents immediately. For added protection, the AppViewX Platform also integrates with industry-standard, FIPS 140-2 certified HSMs for the encryption and storage of critical private keys.

The integration of HSM devices with AppViewX can be implemented in two ways:

1. Private Key Encryption: Generate and store encrypted private keys inside AppViewX while
   offloading private key encryption to the HSM device
2. Private Key Generation in HSM via Application End Points: Use App End Points such as an F5 BIG-IP ADC to communicate with the HSM device to generate and store private keys within the HSM device itself

Certificate Management with Encrypted Private Key Storage in AppViewX

This solution is useful for enterprises looking to generate and store private keys inside AppViewX and limit their encryption to the HSM device for optimum resource utilization. Before being stored in an AES-256 encrypted database, the private keys undergo multiple layers of encryption by Data Encryption Key (DEK), Key Encryption Key (KEK) and Master Encryption Key (MEK). While the encrypted private key, encrypted DEK, and encrypted KEK reside inside AppViewX, the MEK is stored inside the HSM and cannot be retrieved. This solution is suitable for all ADC and server devices.

AppViewX provides a single pane of glass for managing and automating multi-vendor digital certificates on multiple devices. Once the AppViewX instance is up and running, the user opens the Settings page and inputs the HSM details. The implementation type is then set to “Private Key Encryption” to limit the utilization of HSM. After the configuration, the HSM is triggered to generate the Master Encryption Key (MEK) and designates a key handler to uniquely identify this key. From that point forward, every encryption/decryption request for the HSM is sent along with its corresponding handler. Next, a Key Encryption Key (KEK) is randomly generated within AppViewX and is encrypted with the MEK. Whenever a new CSR is generated within the platform, the associated private key is immediately encrypted with another randomly generated, unique Date Encryption Key (DEK). And, in the final layer of protection, this DEK is encrypted again with the KEK.

Certificate Management in AppViewX and Private Key Storage in HSM

Enterprises can use this solution to assign AppViewX to certificate management activities while HSM is used to both generate and store private keys for added security. The private key generated within the HSM cannot be removed and is completely shielded from tampering. This particular solution is suitable for all supported devices that can initiate direct communication with the HSM and use a key identifier to access private keys.

In this scenario, the implementation type in the Settings page is set to “CSR Generation” to use the HSM for generating the private key. After the configuration, the platform passes CSR parameters to the HSM to generate the corresponding CSR file as well as a unique key identifier that will identify the private key used to sign it. The CSR file and the key identifier are then sent back to AppViewX for use in additional certificate-related operations. Whenever a new certificate is required to be pushed to a device, the key identifier is also sent with it. This step in the process helps devices identify the corresponding private keys from HSMs.

Comprehensive Role-Based Access Control

The first step in any access control process is having complete visibility into your certificate ecosystem. Sifting through the thousands of certificates in your inventory can be incredibly cumbersome and time-consuming. With our holistic view, the AppViewX Platform graphically represents important certificate information like chain of trust, associated devices and HSM. Users can also perform necessary lifecycle management tasks like issuing, renewing and revoking multiple certificates all within the holistic view.

While maintaining visibility can help to identify threats early, weak certificates, unregulated access and insecure provisioning can still compromise the security of your application infrastructure. With AppViewX, users can easily administer policies – such as recommended cryptographic techniques, CAs and workflows – to eliminate rogue certificates. Users can delegate access and apply granular visibility to either individual certificates or entire certificate groups to enable efficient provisioning. The certificates can then be grouped based on functionality or by their underlying policy group, all while being efficiently audited to ensure compliance.

Conclusion

Digital certificates are the face of your enterprise online. Given the high level of security associated with PKI technology, the need for digital certificates is only going to increase. This will inevitably leave enterprises with an abundance of private keys to safeguard and without an efficient mechanism to safeguard them with.

Using AppViewX’s Certificate Lifecycle Automation solution, enterprises can essentially replace the vulnerable private key inventories, that administrators maintain, with the visibility and security that private keys and certificates require, all while maintaining the agility and compliance needed to answer to rapidly changing business needs.

Learn more

To try AppViewX’s Certificate Lifecycle Automation solution hands-on in your personal demo lab for free, please request a free trial at https://www.appviewx.com/resources/start-your-trial/