I would like to activate Always Encrypted into my SQL Server database to protect a few sensible columns and access it from an external application.
As per my understanding, I have to:
- Configure Always Encrypted on the database (using both CEK and CMK keys)
- Develop my client using a MS library to connect to such database with encrypted columns. In official docs, I found such library named the “driver”
- From within my client application, I have to provide CMK key to the driver.
Takeout is that I need to handle CMK on my client application.
My CMK will be an encryption key that is stored into Wibu CodeMeter, as a secret in a license, and it does not allow direct extraction of the key from the license. Instead it provides an API to encrypt/decrypt data specifying in what license the key is stored into.
So far seems like there is no way to combine the two technologies, as I cannot get a hold of the key from CodeMeter to pass it over to the driver library. This makes me formulate those questions:
- Why Wibu CodeMeter, and I believe other encryption keys management, prevents key extraction?
- I guess that we don’t want the encryption key to be clear in memory when the process is running, as to prevent to spot the key while debugging, for example.
- If in a secure environment we don’t want the keys to circulate clear in memory, how could possibly Always Encrypted pretend to receive a key as input?
Given that I am no security expert, I suppose either I missed something or this combination is just not possible and what I am trying to do makes no sense at all from an architectural standpoint.