I haven’t gotten the chance to use Conjur firsthand yet, but I was reading through the documentation recently and I started wondering about how the encryption works.
One of the standard ways of encrypting secrets is by using Shamir’s secrets sharing algorithm, which allows multiple keys to be required before something can be decrypted.
It’s based off the idea that n number of points are required to define a polynomial of the (n-1) degree. (Two points define a line, three points define a parabola, etc.) You can hand out multiple keys, each of which are essentially points on a curve over a finite field. So say you have 10 operators, you can hand out 10 different keys, and require minimum of three keys are required to form the master key.
This method keeps the data safe in the event that a single key is exposed.
From what I gathered from the Conjur documentation, it sounds like only a single master key is used. It’s stored either as an environment variable or in a config file. Say someone gets access the host Conjur is running on and they’re able to download the encrypted data. Could they just inspect the container to get the master key and then decrypt all of the secrets? Is there another key required to decrypt the data?
Regarding the Conjur master key - you generate a random data key when you start the Conjur server (eg CONJUR_DATA_KEY) which is used to encrypt all sensitive data which is stored in the database, including the token-signing private key.
I need to do more research to better answer your final questions - I’ll post more when I have more info.
@jodawill it looks like the master key encryption is much more sophisticated in our enterprise offering based on Conjur (see the DAP documentation for more info on how it works there).
Conjur OSS doesn’t come with its own database key delivery / storage mechanism, but if you wanted to add something yourself you could leverage clevis and tang. We don’t have any examples of how this would work right now, but if you work something up, let us know! We’d be glad to share it so that other people could also benefit.
ETA: this is not my personal area of expertise, but from polling our dev team it sounds like clevis/tang will support both SSS and McCallum-Relyea. In addition, when you supply the key on process start, you can do it however - including Shamir’s or McCallum-Relyea, or both. This blog post may potentially be helpful, but it was also suggested it might be as simple as creating an sss script that does whatever magic you want to conjure up the key and setting CONJUR_DATA_KEY=$(sss | base64).
Cool. I hadn’t seen that documentation for the enterprise edition before. It sounds like that mechanism addresses my concerns.
The trouble I see with the OSS version is that (as I understand it, and I could be wrong) there’s just one master key, and if it’s compromised, so is all of the data it was used to encrypt. If Conjur is running in a Docker container, the environment variables will be exposed via a container or service inspect. This problem may be mitigated somewhat if the variable is populated from the entrypoint script instead of being passed from the daemon.
If I understand things correctly, clevis and tang wouldn’t address the issue because the master key is still being stored as an environment variable.
But it’s good to hear that this is a non-issue in the enterprise version.