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?

  • 9
    Sounds like you need some magic fairy dust.
    – user10211
    Commented Mar 14, 2013 at 15:18
  • 4
    Pick two: 1) untrusted user 2) secret data on the client 3) secure Commented Mar 14, 2013 at 15:27
  • @CodesInChaos - #1 should really be untrusted users with control of client computer. There are at least a few options if you can lock down the system to limit the ability of the untrusted user on the client system, though it is probably too complex to answer in QA format. Commented Mar 14, 2013 at 15:34
  • possible duplicate of where to store a key for encryption Commented Mar 14, 2013 at 15:35
  • 1
    @AJHenderson This is a different question: I am asking for application-specific key storage.
    – oleksii
    Commented Mar 14, 2013 at 15:37

5 Answers 5


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.

  • 1
    "they will likely be able to get the TPM or HSM to give up the key" Those are usually write-only i.e. you can import but not export keys. So unless you're an expert in hardware analysis (like flylogic) you won't be able to extract the key. Obviously this requires a pre-loaded key by a trusted third party, and an attacker will probably still be able to steal the plaintext, just not the key. Commented Mar 14, 2013 at 15:45
  • @CodesInChaos - I was under that impression as well but have seen at-least one TPM where it was exportable with admin access and control of the TPM. It probably depends on the exact hardware, but at-least some will allow export if you authenticate with the chip as administrator. Perhaps there is a no-export setting that can be set on it though. Commented Mar 14, 2013 at 16:10
  • Many proprietary corporate software comes with encryption dongles for anti-piracy purpose. It is perhaps the only way to secure data on a per-application bases. But fundamentally the data or key will exist as plain text in memory at some point and there's no way to completely protect memory.
    – billc.cn
    Commented Mar 15, 2013 at 1:13

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.


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).

  • Now you have the same problem with your private key that you originally had with the symmetric key.
    – not2savvy
    Commented Mar 23, 2022 at 15:36

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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .