Where do I securely store application-specific symmetric key?

Question

I am writing an application App1. This application uses SQLite database and I plan to encrypt it using AES256. For symmetric encryption I need a key, which I need to store somewhere.

From a similar questions I have a few options, but none is applicable in my case:

1. Tie the encryption key to your admin login

   I don't trust the currently logged user. In fact, I want to hide this from anyone, but App1.

2. Tie the encryption key to your hardware.

   App1 is deployed to thousands of machines, some may not have needed hardware.

3. Type in the encryption key when you start up, store it in memory.

   User must not have access to App1 key.

4. Store the key on a different server.

   Machine is allowed to be off line, while App1 is running.

5. Store the key elsewhere on the same server.

   Then it can be found.

6. Store the key in the database.

   I need to secure the database, which is kind of recursive in my case.

Possible solution is to store the key using Windows DPAPI, but

1. DPAPI is focused on providing data protection >for users<.

   Whereas I need to protect an application. I also need that App1 worked from different users on the same machine

2. I can add secondary entropy, to restrict the currently logged user from accessing the data.

   However, I need to store this secret data on the machine. How do I protect that... Appears to be recursion again.

Question: where do I securely store application-specific symmetric key?

Answer 1

This is the magical issue of DRM and the short answer is that there is no good answer and if you come up with one, you will be very wealthy. In order for the application to access the key, it has to be able to get to it from an unencrypted state and whatever it can do, a sufficiently advanced user can do too.

You could use a TPM (trusted platform module) or HSM (hardware security module) to store the key as long as the user does not have administrative access on the system, but if they are an admin, then they will likely be able to get the TPM or HSM to give up the key. It would also be difficult to make sure that only the program is able to get the TPM or HSM to perform operations as the application has no way to authenticate itself to the key store that the user can't fake, but it at least would keep the key itself safe.

So short answer, you are completely out of luck if the users have admin on the box the app will run on. If you can give them only limited accounts, then there are some options, but they are still not particularly strong unless you lock down the system quite a bit.

Answer 2

HSM would be a good way to go. Unfortunately I am not aware of any FOSS implementations. I have occasionally considered doing my own "good enough/far better than nothing" HSM. It wouldn't be FIPS certified or encased in epoxy with security seals but it would be better than having a key just sitting on a box.

The nice thing about HSM is that you can audit access to the key independently of the host requesting/using the key. If the key was retrieved during a time when there was no machine rebooting or process that needs it starting you would have grounds for an investigation and perhaps changing the key.

Since your most likely solution is going to be storing the key in a secret place on the server I recommend using SELinux to protect the key from being read by all but approved users/security contexts.

I also recommend using auditd to place special audit rules on the file containing the key so that you can keep track of whenever the file is read. Sending the audit logs off-host to a log collection host is highly recommended. This gets you some of the auditability of having an HSM.

Answer 3

What about the following?

1) creating a public/private key pair.

2) encrypt your symmetric key with the public key, and store that in the code.

3) present your private key at startup to be read in by the program (copy / paste to the command line).

The disadvantage of this is that the process is manual, and the "owner" has to be the guy starting the program up.

The advantage, is it does give you the security, in that the private key goes into local memory and, if coded right, can be deleted this once it's used to decrypt (in java, use a byte[] then clear it out).

Answer 4

Windows Cryptographic Service Provider key store can only store asymmetric keys. Why Microsoft designed it this way is a very good question. Being it that may, your only solution is to use an HSM. You would store your application keys in a data store you create and encrypt it with a master key, which is stored in the HSM.

Most modern HSMs supports PKCS#11 syntax for API calls. HSMs are available as PCI Cards and standalone boxes. You need to also consider your overall
crypto needs before selecting the PCI or standalone option.

You would also separate the HSM admin functions from the server and database admins. You achieve separation of duties, which is basic InfoSec principle when you start dealing with application encryption and sensitive data.

Keep in mind, encryption is technique, anyone can encrypt by calling Crypto Service Provider APIs. Cryptography is the whole process of securely generating keys, securely ciphering and deciphering data, securely storing keys, preventing unauthorized access and rotating keys. Applying encryption haphazardly gives you a false sense of security.

Answer 5

It depends.

Requirement 2 eliminates any hardware based solutions including HSM.

You have not precisely described from what kinds of users do you want to protect it from. You wrote I want to hide this from anyone. If by anyone you mean also system admins, then there is no solution. If you mean users with less privileges, not admins, then there can be a solution. You can create a resource (file, registry entry, ...) and store your key there. Give access to this resource only to the account your application is running under. Then such your users (except admins) will not be able to get access to your key. But admins will still be able to change permissions and to get access to your key.