SQL Server : Implementing One-Way Encryption (part 1) - Create the Primary Hash Column,Create a Secondary Hash Column for Searching

Using the HomeLending database, we will implement one-way encryption. For simplicity and clarity, we will focus on the Borrower_Identification table and we will assume that the modifications to the Borrower_Identification table and Identification_Value column,  either have been reversed through a backup file restore, or not implemented.

The steps we will follow are as follows:

1. Always backup your database prior to implementing any method of protection.
   

2. Create the primary varbinary hash column to store the hashed values of the Identification_Value column. This hashed column must only be accessible to members of the Sensitive_high database role.

3. Create a secondary version of the hash column that stores truncated hash values of the underlying plain text, in order that lower-privilege roles can still perform searches based on the values contained in the primary hash column.

4. Salt the values stored in the Identification_value column, using the GetSaltHash UDF created in Listing 7.1, and then hash the values, using the HashBytes method, and populate the hash columns.

5. Test and verify our new one-way encryption architecture.

6. Drop the original plain-text Identification_Value column.

These steps would be repeated, as needed, for each column in the database tables that are subject to the implementation of one-way encryption.

Please note that the process of implementing one-way encryption involves modification of existing database objects. Please perform a full database backup prior to proceeding in the event that recovery is required.

Create the Primary Hash Column

The Identification_Value column contains the plain text representation of the actual identification value for a given borrower. For example, if the identification value was a Social Security Number, the value contained in this column would appear in the format of "555-55-5555".

The Hashbytes method that we'll use to one-way-encrypt our Identification_Value column returns a varbinary data type, which stores a variable-length numeric representation of a value. For example, the value of "A" is stored with the value of "0x41" while "ABC" is stored as "0x414243". The varbinary (and Binary) data type has a maximum length of 8,000 characters.

However, in the original schema design, the Identification_Value column is of data type varchar. Therefore, we will need to create a new column in the HomeLending database to store the encrypted varbinary values. Listing 1 shows the script to create a new Identification_Value_H column (where the "H" stands for hash) with the varbinary data type, using the ALTERTABLE method.

Listing 1. Creating the hash column.

In Listing 2, we execute the sp_addextendedproperty system stored procedure in order to document the fact that the new Identification_Value_H column is classified as "High" sensitivity.

Listing 2. Documenting the encrypted column as "high" sensitivity.

Create a Secondary Hash Column for Searching

With our HomeLending database, there is an expectation by the users that the members of the Sensitive_medium database role should be able to search for borrowers based upon the values contained in the Identification_Value column. However, our security policy dictates that the Identification_Value_H column has a Sensitivity_Class of "High", and so only members of the Sensitive_high database role are granted permissions to access it. This presents an interesting challenge.

A solution to this challenge is to offer an additional column that will contain the hash values of truncated versions of the original plain text. For example, this column would contain a hash of the last four digits of the Social Security Number. This new column will be offered to users who are not members of the Sensitive_high database role, as a way to search this data.

Listing 3 creates this new column, called Identification_Value_HT, on the Borrower_Identification table. The "T" represents the fact that it is a truncated version of the plain text value. In addition, we define its Sensitivity_Class designation as "Medium."

Listing 3. Creating and documenting the secondary hash column.

When we populate these new columns, the Identification_Value_H column will be populated with a hash value that is based on the full plain text value of the Identification_Value column, and the Identification_Value_HT column will be populated with a hash value that is based on the last four digits of the plain text. A salt will be applied to both, based upon our previously created GetHashSalt user defined function.