Where should a keystore (.jks) be stored in a repository

Question

I've got a question about the best practice in storing a Keystore file (.jks) in source control. This Keystore is called by a stand-alone Java component that retrieves a private key for the purpose of signing SAML assertions.

For security purposes I would like to refrain from including this Keystore in the same git project as our Java code. This source code is pushed to many different locations for various tools used. (Code review tools, source code scanners) and I don't think anything good can come from having our Keystore file sitting in all these locations.

That leaves me with the question of, where's the best place to include this file in source control? I've done some digging around the internet have yet to find a good answer so here's my thoughts.

Plan A

I plan to place the Keystore file in a private repo that is locked down. This can only be accessed by a very limited audience. The Keystore will be added to the stand-alone component on build as a dependency by the deployment process.

- Pros

• Keystore would not be distributed with our source code
• Updates to the Keystore in source control could be locked down and carefully monitored

- Cons

• Increased complexity for cert management
• Keystore will get added to the module in the deploy process anyways, so the security benefit is limited

Plan B

Instead of keeping a static keystore, each time the build process is initiated a new keystore is built with a pseudo random key. The key is then added as part of the zip in our build process. Certs will then needed to be added to the keystore. Most of the instances of this Java module would have unique certificates, so not keeping the static reference would not introduce a large amount of busy work.

- Pros

• No static keystore for attackers to take advantage of

• Each instance of the keystore has it's own password

- Cons

• Increase complexity of build process

• If the same cert is used across multiple instances of this module the cert will have to be added to each one.

Which is my better option? Also am I going down the right path with this?

Answer 1

All the organisations I worked in store credentials or equally sensitive info in a well-known location outside the application's deployment directory and is secured per environment. Devs create the files themselves with dev credentials whereas the production ones are created by ops and secured so only the application has access.

If you want the application to run without config after checkout, you can embed some dummy copies that only gets used when the file cannot be found at the well-known location.

Answer 2

Which is my better option? Also am I going down the right path with this?

It depends.

Type of your application, the application threat model and your business attack profile dictates the right option. If you are asking about the best-practice, I can suggest to use a HSM device one for the development environment and one for production. These devices are purposefully build for secure key management. Any other custom options have one or more security flaws, unnecessary complexity or an unknown attack vector.

Obviously the security provided by a HSM device comes at cost. The other practical option is to implement a software based internal PKI infrastructure. Depends on your server stack (MS, Unix, etc), there are different ways to implement it. For example, pki.io, an open source X.509 certificate management project, although being a young project can simplify the internal key management.