The Misguided Ambition of Controlling the Private Key
June 01, 2016
One of the common recurring themes we hear from customers when discussing SSH user key management is the importance of finding and controlling all the private keys in their environment – the thinking being that since private keys are similar to passwords, we can manage them with the same principles. And if we get the private keys under control, we are inherently safer. At first glance, this may seem logical, but upon closer analysis we can see that this may actually be a misguided ambition.
First, as an analogy and to keep the thinking simple, think of the private key as the key to your house and the public key as the lock to your door. It is not the intention of this article to dismiss the importance of the private key. Let’s face it: without the key to the house, you still can’t unlock the door. The point is, however, that when you lose the key to your house, to truly be safe, you need to change both the lock and the key. You need to know who owns the key and, more importantly, what the user of the key may do when they enter your house.
Consider this from the perspective of the Sony breach. It is speculated that the attack was caused by a spearfishing incident. However, once the malicious actors had access to the environment, they grabbed numerous private keys. Some of these private keys provided access to critical information such as payroll and other important applications.
Our initial reaction is this: had the private key been better controlled, this all could have been avoided. Well, yes and no. Let’s explore this more closely to understand why we might be misguided in our intense focus on finding and controlling all the private keys in our environment.
First, SSH user keys are not passwords. There are some very significant differences between them that warrant us handling them differently. There are five key differences to consider:
1.Passwords are related to user accounts. SSH user keys don’t have to be.
2.Passwords usually have expiration times. SSH user keys don’t.
3.Passwords cannot be generated without oversight. SSH user keys frequently can.
4.Passwords are mainly used for interactive authentication. SSH user keys are most frequently used for machine-to-machine authentication.
5.Passwords grant access to the operating system level without additional restrictions. SSH user keys can control both access and privilege levels.
Secondly, finding all the private keys across our environments is a daunting if not impossible task. The following simple command “ssh -i /path/to/id_priv_key_rsa user2@serverB” demonstrates exactly how difficult this is. This command essentially provides us with the ability to place a private key almost anywhere. It can sit on our desktop. It can sit in a folder. It can sit on a network file system. It is easily transportable on a USB stick. It can essentially be hidden almost anywhere, and this is exactly the challenge. How to effectively scan to find all the private keys or to force the standardization of the location of the private key are both extremely challenging if not impossible.
Next, let’s assume we could find all the private keys in our environment and even store them all into a secure central vault. Unless we can actually prohibit the ability to generate new key pairs by administrators, it is very easy to come through the intended jump host or privileged access management architecture, access your target server and drop in a new key pair which would allow you now to bypass that architecture in the future. This is a very common scenario we see with our customers each day.
Locking down private keys in a secure vault does provide benefits and decrease risk and is a solid approach for interactive usage. The challenge is applying this same approach for machine-to-machine connections, which tend to make up about 80-90 percent of the SSH user key-based authentication within enterprises today. The risk of breaking automated processes by vaulting private keys is high, and efforts to rescript application-to-application connections to look for that private key in a centralized vault is again a daunting and burdensome task for any organization.
So what are the solutions and best practices we should be looking at instead? Going back to the principle of controlling the locks to your house the most important controls related to access are placed on the public key side of the equation.
When we provision a key pair, we have a couple of options at our disposal that in the majority of cases are not used but could easily be applied. First, it is possible during the generation of an SSH user key pair to place what is know as an IP source restriction on that key. This means that for that key pair, the private key may only access that target server from that specific IP. So, if the private key were stolen and it attempted to authenticate from another IP, the authentication would not work. In a simple step, we have just decreased the attack vector of the key significantly.
Second, another easy option at our disposal is to put a command restriction on the public key. This basically restricts the authenticated session to running the commands it is intended to. For example, if we lock down a key from a command point of view to only allow that authenticated session to run SFTP, then we have eliminated the possibility, should the private key be stolen or lost, of it being misused to run other commands, which could affect the resilience of our environment.
Taking the combination of IP source restrictions and forcing what commands SSH user key-based authentication can use helps us decrease risks around transitive trust. Having a clear understanding of transitive trusts in our environment helps us clearly understand the implication should a private key be leaked or stolen.
Finally, we have numerous controls at our disposal when it comes to SSH configuration management. SSH configuration is not a very sexy topic. However, it is again something that lies well within our control to help decrease risk within our environments.
With good configuration management, we can standardize key locations and ensure unified version management, but more importantly, we can control access-related controls such as which sub-channels of the protocol may or may not be used, deny root access, restrict deprecated SSH versions and algorithm usage, as well as control login restrictions and log how frequently and from where keys are being used. These controls, when implemented properly, already provide us a good baseline of control in our environment and SSH usage.
It is important for enterprises to have visibility, understanding and continuous monitoring of key-based authentication that potentially can impact numerous applications and platforms. SSH user keys are frequently being used for remote administrator access and application-to-application connections for our most critical infrastructure. It is a question of risk, compliance and resilience that ultimately directly impacts our brand reputations.
To effectively gain control of our environments, we need to place focus first on those things we have control of. One thing we do have better control of is the server side configuration of our SSH servers and the public key component of the authentication equation. Trying to find and control all our private keys may be a bit like herding cats, and therefore could be considered a misguided ambition to strive for.
About the Author
Matthew McKenna, Chief Strategy Officer, SSH Communications Security has over 15 years of high technology sales, marketing and management experience. He is responsible for driving strategy, key account sales, and evangelism.
Edited by Peter Bernstein
Article comments powered by