How to encrypt or store data so that only a pool of processes can share it on Windows?

Question

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.

Answer 1

When using DPAPI, other processes can access the protected data only if you use the user's login password/credentials by itself to protect the data. DPAPI does account for that, as you noted:

Windows Data Protection

Keys and Passwords in DPAPI

DPAPI is focused on providing data protection for users. Because DPAPI requires a password to provide protection, the logical step is for DPAPI to use a user's logon password, which it does, in a way. DPAPI actually uses the user's logon credential. In a typical system, in which the user logs on with a password, the logon credential is simply a hash of the user's password. In a system in which the user logs on with a smart card, however, the credential would be different. To keep matters simple, we'll use the terms user password, logon password, or just password to refer to this credential.

A small drawback to using the logon password is that all applications running under the same user can access any protected data that they know about. Of course, because applications must store their own protected data, gaining access to the data could be somewhat difficult for other applications, but certainly not impossible. To counteract this, DPAPI allows an application to use an additional secret when protecting data. This additional secret is then required to unprotect the data.

Technically, this "secret" should be called secondary entropy. It is secondary because, while it doesn't strengthen the key used to encrypt the data, it does increase the difficulty of one application, running under the same user, to compromise another application's encryption key. Applications should be careful about how they use and store this entropy. If it is simply saved to a file unprotected, then adversaries could access the entropy and use it to unprotect an application's data.

So, just make sure that the "additional secret" really is secret between your cooperating processes so no other app can get it. For instance, using a private IPC mechanism, like a named pipe, to send the secret directly between processes without other apps eavesdropping.

Alternatively, you could just protect your symmetric key locally with CRYPTPROTECTMEMORY_SAME_PROCESS, then create a secure IPC connection with the other cooperating process and send the key in an encrypted format that only the receiver knows how to decrypt it (SChannel, SSL, etc), then the receiver can store the decrypted key locally using CRYPTPROTECTMEMORY_SAME_PROCESS as well.