The topic of certificate sharing keeps popping up as of late so I wanted to address it here. The main objection to certificate-based crypto seems to be the administrative overhead. After having scripted up certificate management for several customers, I have come to believe that the administrative burden is overstated in many cases. That said, the discussion of key sharing has merit. In some use cases, such as a web app server farm, a single entity is distributed across multiple instances. If the administrative scope of that entity contains all those instances (in other words if the compromise of any one node compromises all other nodes) then little or no no additional security is gained from them having many unique certificates. So what are the considerations in all those nodes sharing the same certificate?
Although the encryption would be the same with many clients using the same key, the level of security achieved across the system would be much less than the level of security if unique certificates were used. I am not suggesting that reusing certificates is always inappropriate, only that the reduced level of security must be fully accounted for and justified by the cost savings in reduced administration. If the higher security of individual certificates is not necessary for the given application then this can be a valid solution. The trick is ensuring that the difference in security is fully understood and properly factored in.
Some of the differences include:
- There is no differentiation between clients. Usually this is the first consideration and often a valid use case (for example, the aforementioned many instances of a web server farm). The ability to differentiate one node from another is the basis for granular authentication, non-repudiation and audit logging. The nodes sharing a key must truly be functionally equivalent.
- When private keys are shared, the security of the system degrades with each new key. That is because compromise of any one instance compromises all instances. For example, if the key is at 10 physical locations then all ten must be secure at all times. If the key is at 100 locations, then all 100 must be secure at all times. The chance of an exposure in the network increases with the number of nodes sharing a key, eventually to the point of certainty. Note that this is the same with symmetric keys.
- Email, FTP and even SFTP can leave ephemeral copies of the keystore on disk, in memory, swap files, etc. Distribution of keys is non-trivial. In order to share them and still achieve effective security, a secure key distribution method must be used.
- In the event an attacker does get access to a keystore, it is easy to mount a brute-force attack against the password. This is because, unlike breaking into an app or OS which delays repeated attempts or locks up, the attacker can try passwords on a keystore as fast as the CPU and resources allow. They can even use one of several distributed cracking engines available commercially. For this reason, the password to the keystore should be a long, random string containing special characters, mixed case, and digits rather than one that is human-friendly.
- If it becomes necessary to revoke the key, then all nodes using it lose access until a new key is provisioned. The more clients there are, the longer the outage. Alternatively, an outage can be avoided by deploying a new key alongside the old one before switching over. In this case, the reduced outage comes at the cost of an increase in the duration of exposure with a known bad cert. The customer should consider this, decide in advance which method of revocation they would use and then capture that revocation plan in writing,
- If the key is on shared disk then the network traffic for that share must be encrypted for the user that needs access and nobody else. If the NFS traffic is in cleartext for anyone signed onto the server (i.e. uses the server credentials rather than those of the application’s service account), that is as bad as the keystore being world-readable. Access to the share holding the keystore must be encrypted such that only the legitimate users can ever see the keystore data. The warning about ephemeral copies applies to NFS and other shared storage systems.
Most of these can be mitigated with human procedures or configuration. For example, storing the keys locally eliminates considerations of exposure through the shared storage subsystem. However, the issue of security being inversely proportional to the number of shared keys is unavoidable. So too is the trade-off between an outage versus extended exposure in a revocation situation. One approach to address this is to compromise on the number of nodes allowed to share a single key. Instead, share small groups of keys. For example, instead of sharing a single key across 50 instances share 10 keys across 5 instances each or share 5 keys across 10 instances each. This limits the scope and duration of an outage in the event of revocation and caps the reduction of security due to key sharing at a known level.
So before deciding to share certificates, first consider whether the cost of administration has been overestimated. With a few scripts it is possible to reduce most key management tasks to a few command lines or mouse clicks. I have helped many customers write such scripts and in some cases these are managing several hundreds of keys successfully. There are also commercial key management tools such as Venafi’s Director and IBM’s Tivoli Key Lifecycle Manager (TKLM) that make key management cost effective across larger infrastructures. It might be possible to administer hundreds or even thousands of certificates for much less cost than had been estimated.
Consider also the reduced security of shared certs and additional mitigation required to compensate for that. For example, what human processes and tools must be used to securely distribute shared certs? Do not share certificates unless the true costs are known and then only when it is clear that the cost saving truly does offset the reduced security and by a clear margin.