Key protection using user-specified passwords

You can limit the power of the SA or DBO to access private data when you specify passwords on keys through the create encryption key or alter encryption key statements. If keys have explicit passwords, before users can decrypt data, they need:

• Decrypt permission on the column

• The encryption key’s password

Users must also have knowledge of the password to run DML commands that encrypt data.

Use the create encryption key command to associate a password with a key:

create encryption key [db.[owner].]keyname  [as default]
[for algorithm_name] [with {[keylength num_bits]
[passwd 'password_phrase'] [init_vector {NULL | random}]
[pad {NULL | random}]}]

Where:

• for algorithm_name – (optional for the 15.0.2 release) specifies the algorithm you are using. The default is the Advanced Encryption Standard (AES) algorithm.

• password_phrase – is a quoted alphanumeric string of up to 255 bytes in length that Adaptive Server uses to generate the KEK.

Adaptive Server does not save the user-specified password. It saves a string of validating bytes known as the “salt” in sysencryptkeys.eksalt, which allows Adaptive Server to recognize whether a password used on a subsequent encryption or decryption operation is legitimate for a key. You must supply the password to Adaptive Server before you can access any column encrypted by keyname.

This example shows how to use passwords on keys, and the key custodian’s function in setting up encryption. In this example the password on the key is shared among all users who have a business need to process encrypted data.