The sensitive data that is contained within the Borrower_Identification
table is now protected with one-way encryption. Our next steps are to
create the interface through which our users can access this table.
A general policy, we denied direct access to all base tables within the HomeLending database using the script shown in Listing 1.
We adopt the same strategy here, using an interface
consisting of a view and three stored procedures to mediate our users'
interaction with this table. By implementing this structure we can
control the access to our data at a more granular level than simply
granting access to entire tables. In addition, this structure allows us
the opportunity to embed cryptographic functionality and other logical
methods into our views and stored procedures.
Creating the View
We created a view called vwBorrower_Identification, by which authorized users in the Sensitive_high and Sensitive_medium roles could access the values in the Borrower_Identification table . However, only members of the Sensitive_high role were able to use this view to view in decrypted form the cell-level-encrypted values.
Here, we will recreate this view in light of our new one-way encryption architecture, as shown in Listing 2. Users of the view will not gain access to the Identification_Value_H
column, so that the ability to reveal the plain text through comparison
of hash values is limited to the database roles that are in the Sensitive_high database role. Instead, we include our alternative Identification_Value_HT column, which contains a hash value of the original plain text truncated to its last four digits.
Creating the Stored Procedures
Having earlier restricted direct access to the Borrower_Identification table, the ability to insert, update and search records that are contained within the Borrower_Identification table will be achieved through stored procedures.
The stored procedure that will be used to perform the UPDATE methods will be called Update_Borrower_Identification and the script to create it is shown in Listing 3.
The plain text value of the borrower's identification value as well as
the unique identifying value for the record that is being updated in
the Borrower_Identification table is passed into this stored
procedure as parameters. This stored procedure then performs the
necessary salting and hashing, using the GetHashSalt function and the Hashbytes method, as described earlier.
The stored procedure that will be used to perform the INSERT methods will be called Insert_Borrower_Identification. Passed into this stored procedure as parameters are:
The plain text value of the borrower's identification value.
The foreign key value that defines the identification type.
The foreign key value for the borrower to which the identification record is associated.
The script to create this stored procedure is shown in Listing 4.
Again, the Hashbytes method is used to create the hash value for the plain text identification value and the salt is derived from the GetHashSalt user defined function. The SHA1 algorithm is used to create the hash value.
The final stored procedure, Select_Borrower_Identification,
will be used to return filtered sets of data based upon the truncated
plain text, in this case the last four digits, sent into its Identification_Value argument, as shown in Listing 5.
The plain text identification value that is passed in is salted and hashed, using the "SHA1" algorithm, and then placed in the WHERE clause of the statement to be compared with the hash value that is stored in the table.
