1

I am writing an application T1 which is using SQLite database to store some sensitive data and i am trying to encrypt it securely. The issue i am facing is that i don't want my symmetric key to be stored in memory as in that case any other process can take a snapshot of memory and access my keys. I have looked at many possible similar questions:

CryptProtectMemory/CryptProtectdata

But the issue with this is that it has two different options -

CRYPTPROTECTMEMORY_SAME_PROCESS or CRYPTPROTECTMEMORY_CROSS_PROCESS

The problem with CRYPTPROTECTMEMORY_SAME_PROCESS is that it restricts the access to a particular process (and my app has a seperate UI process which could also access the database) and the problem with CRYPTPROTECTMEMORY_CROSS_PROCESS is that it allows all the processes of the logged in user to access this data which kind of defeats the purpose

So what I want is an API where i can specify only a pool of processes that can access my data/key

I looked at similar options but nothing is applicable in my case:

  1. Using DPAPI - This ties the encryption key to your admin login but the problem is that i don't trust the currently logged user. In fact, I want to hide this from anyone but T1 and my UI process.I understand that 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 recursive problem.
  2. External hardware or storing the key at a remote server - As the app will be deployed at many commercial endpoints(which may not have the specific hardware) and it needs to work in offline mode also(the server may not be accessible).
  3. Store the key in the database - I need to secure the database, which is kind of recursive in my case again.
seaborg
  • 11
  • 1
  • It's not really possible with current Windows, although I think this is the sort of thing that Data Containers in Windows 10 aims to address. http://channel9.msdn.com/Events/TechEd/Europe/2014/WIN-B339 – paj28 Jun 16 '15 at 09:53
  • Wait, what are you trying to prevent here? A user having (their?) data stolen from a compromised machine? _Your_ data being stolen by the end user? – Clockwork-Muse Aug 15 '15 at 12:55

1 Answers1

1

If your threat model means your code has to run on a computer you can't trust, there is no way to protect your data: it simply isn't possible.

No matter what you do, the decryption key MUST be present in the memory of the system performing the decryption in order to access the data. This means that the only possible way to protect the key is to move that processing on some trusted hardware. Note that this doesn't really protect the data: as soon as it reaches the untrusted system in clear, it can be compromised. It only protects the encryption key.

You'll have to change your threat model by accepting the possible loss and simply making it as difficult as possible to access that data.

Stephane
  • 18,557
  • 3
  • 61
  • 70