July 2, 2019 at 12:00 am
Comments posted to this topic are about the item The Client Key
July 2, 2019 at 6:07 am
Interesting question, thanks Steve
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
July 2, 2019 at 2:36 pm
Thanks, need to write more of these. I think at 2019+ this starts to become a more viable tech.
July 3, 2019 at 9:13 am
The article references says:
Next, the driver contacts the key store, containing the column master key, in order to decrypt the encrypted column encryption key value and then, it uses the plaintext column encryption key to encrypt the parameter. The resultant plaintext column encryption key is cached to reduce the number of round trips to the key store on subsequent uses of the same column encryption key. The driver substitutes the plaintext values of the parameters targeting encrypted columns with their encrypted values, and it sends the query to the server for processing.
If I read this correctly, the CEK is used to encrypt and decrypt the data, and the CMK is used to decrypt the CEKs. So both keys are used by the client to en-/decrypt.
Or am I reading this wrong?
July 3, 2019 at 4:39 pm
The CEK isn't stored on the client, though maybe we could argue this is accessed by the client. I used accessed because the CMK can be stored in a cert store or HMS.
I'm really not sure how to reword this question to point to the CMK. I would argue technically the client doesn't use the CEK. The driver uses this for encrypting/decrpyting on the client. the client itself, accesses the CMK.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply