Tag: sql server

  • Using a Symmetric Key

    In my Encryption Primer talk, I do demo on symmetric key use, and wanted to document it here. Encryption is a serious subject, and please do your research and education, as well as testing, before you implement it.

    This post will look at some simple encryption and decryption using symmetric keys. I showed how to create a symmetric key before, so I won’t talk about that here, but I’ll just show the code.

    Let’s set up a test table. In this case, I’m showing salary in a table, which isn’t something you want to do, but you might have this in an existing application: data you need to encrypt, but it’s stored unencrypted.

    -- create a table 
    create table Employees ( 
     id int identity(1,1)
     , firstname varchar(200)
     ,lastname varchar(200)
     ,title varchar(200)
     ,salary numeric(10, 4) );
    go
    insert Employees 
    values
      ('Steve','Jones','CEO', 5000)
     , ('Delaney','Jones','Manure Shoveler', 10)
     , ('Kendall','Jones','Window Washer', 5)
    ;
    go 

    Here I have three employees and salaries. Now I want to encrypt the salary. However I cannot just encrypt this value. Encryption creates a binary representation of the data, and that won’t fit in a varchar field. So I need to add a column.

    alter table Employees 
     add EnryptedSalary varbinary(max);
    go 

    Now I have a placeholder, so let’s create a key and then update the new binary column with the encrypted value.

    -- create a symmetric key
    create symmetric key MySalaryProtector
     WITH ALGORITHM=AES_256
     , IDENTITY_VALUE = 'Salary Protection Key'
     , Key_SOURCE = N'Keep this phrase a secr#t' 
     ENCRYPTION BY PASSWORD = 'Us#aStrongP2ssword'
    ;
    go 
    -- open the key 
    open symmetric key MySalaryProtector
     decryption by password='Us#aStrongP2ssword'
    ;
    
    -- encrypt the data 
    update Employees 
     set EnryptedSalary = ENCRYPTBYKEY(key_guid('MySalaryProtector'),cast(salary as nvarchar))
    ; 
    go 
    -- remove the old data 
    update employees
     set salary = 0
    ; 
    go 

    Note that I open the key, which is needed. I can close it at the end, or it will close when my session ends. I don’t close it here as I usually run this demo in the course of one session.

    The encryption takes place with the ENCRYPTBYKEY function, which requires the GUID of the key. Why the GUID and not the name I don’t know, but it seems like a PIA, halfway implementation. In any case, the KEY_GUID function is used as the first parameter.

    The number needs to be cast as a character, so I do that first, and then it’s the next parameter in the function. If I look at the data, it looks like this:

    select id , firstname , lastname , title , salary , EnryptedSalary
     from Employees; go 

    encryptsymm

    If you use the same identity_value and key_source, you should get the same encryption.

    To decrypt it, I do this:

    -- decrypt the data, with the casting  select id  , firstname  , lastname  , title  , Salary = cast(cast(DecryptByKey(EnryptedSalary) as nvarchar) as numeric(10,4))  , EnryptedSalary  from Employees go 

    The encrypted value has a header that tells it what key is used, so as long as it’s open, this works.

  • Documenting the Undocumented

    Evolution of Documentation
    Documentation is important, especially for the platform. Things that are used often, like xp_file_delete, need to be documented.

    There are any number of functions in SQL Server that are undocumented. I have no idea how many there are because, well, they’re undocumented. I can’t see the source code, so I’m not sure what’s actually encoded in the platform.

    I’ve heard arguments that everything should be documented, and while I appreciate the sentiment that complete documentation is a good thing, I also understand the other side. Each item that is documented must be supporter, or at least supported in the lawsuit happy US. That means it must also be tested extensively and this means an increased load on the resources available for SQL Server. While I don’t want to see testing limited, or quicker releases of the platform, I do want everything well tested.

    There are some functions in the platform, such as some DBCC commands, that are added to help support. I can understand that testing, enhancing, and documenting these functions might not make sense. However I think there are some functions, which are used on a regular basis by millions of instances, and should be documented. For example, xp_delete_file is undocumented in Books Online, and a Connect item to provide documentation was closed as “by design”. However this function is called in maintenance plans, and has various bugs filed on cleanup issues and a lack of error reporting.

    Paul Randal has a good blog on why DBCC commands aren’t documented and it makes sense to me. I agree with the overall philosophy, but I would like to see those features that are used in normal operation of the platform completely documented.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • We Need to Learn Encryption

    encryption
    We need better encryption and better tools for the future.

    More than learning encryption, we need to demand better encryption tools inside SQL Server. After reading about the issues from the STUXNET worm, it makes me worried that we will see more disruptive attacks, not just from hackers and criminals, but from the virtual vandals and bored teenagers that have more time than morals or sense. The issues from the STUXNET worm spread far beyond any territorial or national issues, and run into all sorts of industrial control systems that may receive more attention from hackers in the future. With some of the brightest hackers in the US and Israeli governments providing a template for compromising those system, I’m sure there will be no shortage of future attacks.

    That doesn’t necessarily mean there are going to be more and more database attacks in the near future, but I’m sure there is research going on into new ways to attack database or applications, either from governments, criminals, or even graduate students. At some point there will be new attacks that come out, and these vulnerabilities may result in zero-day, or even forever-day vulnerabilities.

    We can’t change the way SQL Server, or other vendor technologies, work at a base level, but we can reduce the amount of damage that’s done by not being the easy prey for attackers. In my mind, that means we should be securing our data as best we can, including encrypting communications and limiting access rights, as well as encrypting the actual data we store.

    I’m hoping that Microsoft makes PKI much easier when they release the updated Certificate Services in Windows 2012, and that we also find better private solutions for individuals that allows us to better secure our systems and make it difficult for the casual attacker to compromise our systems. I don’t know if we’ll see viable products and solutions soon, but as we distribute our systems, data, and backups to wider and wider systems, including tablets and mobile devices, we need better security more than ever.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • SQL Saturday #132 Files

    Uploaded here if you need them. These are the PPT deck and the code.

    UnstructuredData.zip

    EncryptionPrimer.zip