Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.
This is a series on working with the various encryption technologies in SQL Server.
One of the encryption technologies in SQL Server is using keys to encrypt or decrypt data. This post looks at the symmetric key, which is part of the way that you can do the actual encryption of your data in SQL Server. I have a post the discusses how this works, but this post just looks at the use of creating the key.
The CREATE Statement
There is DDL For symmetric keys in the form of:
The basic statement requires a name, an algorithm, and an encryption mechanism. You cannot create a key that is unprotected in some way. Each of these has different possible values.
You also can optionally add a KEY_SOURCE and an IDENITY_VALUE, which are used to recreate this key if it is removed (or in another database). You can also use a provider, if you have an EKM provider configured. Your CREATE would use the EKM provider and the name of the key from the provider to use in operations. If I want someone else to own this key, I can provide a user name or an application role.
Here is the minimum key create (and the select and drop to check it).
CREATE SYMMETRIC KEY SteveKey
WITH ALGORITHM = AES_128
ENCRYPTION BY PASSWORD = 'sdfs'
SELECT * FROM sys.symmetric_keys AS sk
DROP SYMMETRIC KEY SteveKey
This uses a specific algorithm, which I must provide. There are a number of choices, but in terms of practical choices in 2021, likely really only the AES ones make sense. For the encryption scheme, that depends on what you’ve set up in your system, but you can choose from
- symmetric key
- asymmetric key
You choose the type and enter it, with the name of the object or the = with a password.
That’s really the extent of creating a symmetric key. Any details with an EKM provider really come from the name used in the CREATE PROVIDER command.
This is something I’ve done a few times to learn how it works and practice implementing encryption. Ultimately, the key management makes most of the column level encryption seem silly, and really I’d do this in the application layer to ensure communications are protected.
I took 20 minutes to write this up, copy some links, and showcase this. If you want to work in this area, do this as well. Practice this and write about what you’ve learned, the good, the bad, and the problems.