Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share
7  
Sounds like you need some magic fairy dust. –  Terry Chia Mar 14 '13 at 15:18
2  
Pick two: 1) untrusted user 2) secret data on the client 3) secure –  CodesInChaos Mar 14 '13 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. –  AJ Henderson Mar 14 '13 at 15:34
    
possible duplicate of where to store a key for encryption –  AJ Henderson Mar 14 '13 at 15:35
1  
@AJHenderson This is a different question: I am asking for application-specific key storage. –  oleksii Mar 14 '13 at 15:37

2 Answers 2

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.

share
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. –  CodesInChaos Mar 14 '13 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. –  AJ Henderson Mar 14 '13 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 Mar 15 '13 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.

share

This site is currently not accepting new answers.

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