EP1934713A2

EP1934713A2 - System and method for protecting sensitive data

Info

Publication number: EP1934713A2
Application number: EP06825127A
Authority: EP
Inventors: Brian Metzger; Stephen Mauldin; Bruce Sandell; Jorge Chang
Original assignee: Ingrian Networks Inc
Current assignee: Thales DIS CPL USA Inc
Priority date: 2005-09-26
Filing date: 2006-09-26
Publication date: 2008-06-25
Also published as: WO2007038509A2; WO2007038509A3; EP1934713A4; TW200802029A; JP2009510616A

Abstract

A technique for protecting sensitive data (202) involves using encryption in a database ( 108). A system and method according to the technique may include automatically selecting a new encrypting key for re-encrypting data in a target database. New initialization vectors may be specified for re-encrypting each column of data selected for re-encryption. A new initialization vector may be specified For one or more rows of data in a database table in the target database that is selected for re-encryption (712).

Description

SYSTEM AND METHOD FOR PROTECTING SENSITIVE DATA IN A DATABASE

TECHNICAL FIELD

The present invention is directed to data security, and more specifically to protecting sensitive data that resides in a database.

BACKGROUND

It cannot be gainsaid that confidential information, such as credit card numbers, social security numbers, patient records, insurance data, etc., need to be protected. Although enterprises have instituted procedures for protecting such sensitive data when such data is in transit, more often than not, such data is stored in unencrypted format ("clear text" or "plain text"). For example, data is often stored as clear text in databases. The clear text is visible to attackers and disgruntled employees who can then compromise the data and/or use the data illegitimately. Further, not only is data security a feature that is highly desired by customers but it is also needed to comply with certain data security regulations. In order to adequately protect data, organizations need to institute procedures to protect data at all times including when the data is in storage, when the data is in transit, and when the data is being used.

Once the data in a target database has been encrypted, security of the data can be further enhanced by periodically re-encrypting the data in the database. It is desirable to automate the re-encryption process with as little impact on the administrator of the target database and/ or the applications that access the target database. However, in order to convert existing databases into a secure system, vast computing resources are required because large volumes of data need to be converted. It is desirable to make the conversion so as to not drain the computing and storage resources of the target relational database. It is also desirable to make the conversion as transparent and convenient as possible for the administrator of the target database.

It is also desirable to have the ability to selectively encrypt certain database tables in a given database and/or certain columns of the database tables rather than encrypting all of the columns of all of the database tables. However, to provide encryption at a granular level, such as at the column level for a database table, requires extensive changes to the application programs that wish to access the encrypted data in the given database. Such an approach is inconvenient and would require considerable time and effort to implement such a solution.

These and other issues are addressed, resolved, and/or ameliorated using techniques described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level block diagram that illustrates a system architecture for transparent encryption, according to certain embodiments.

FIG. 2 is a flowchart that illustrates some of the steps that are performed for converting sensitive data that is stored in clear text format in a relational database into encrypted format in a manner so as to allow application programs that access the relational database to interact with a cryptography server for performing cryptography operations in a manner that is transparent to the application programs, according to certain embodiments.

FIG. 3 is a flowchart that illustrates some of the steps that are performed for allowing an application program to access encrypted data in a database without modification to query statements sent by the application program for accessing such encrypted data, according to certain embodiments.

FIG. 4 is a flowchart that illustrates some of the steps for executing an insert query statement issued by the user on a populated instantiated view that contains requested sensitive data, according to certain embodiments.

FIG. 5 is a flowchart that illustrates some of the steps for executing an update query statement issued by the user on a populated instantiated view that contains requested sensitive data, according to certain embodiments.

FIG. 6 is a high-level block diagram that illustrates a system architecture for encryption of data in a database using an encryption mechanism that is separate from the database, according to certain embodiments.

FIG. 7 is a flowchart that illustrates some of the steps that are performed for converting sensitive data that is stored in clear text format in a target relational database into encrypted format in a manner that has minimal impact on the resources of the target relational database.

FIG. 8 is a high-level block diagram that illustrates system architecture for encryption of data in a database using an encryption mechanism that is separate from the database, according to certain embodiments. FIG. 9 is a flowchart that illustrates some of the steps that are performed for converting sensitive data that is stored in clear text format in a target relational database into encrypted format in a manner that has minimal impact on the resources of the target relational database.

FIG. 10 is a non-limiting high-level example of a data migration script for a SQL Server type DBMS.

FIG. 11 is a non-limiting high-level example of a data migration script for a DB2 Server type DBMS.

DETAILED DESCRIPTION

According to certain embodiments, an unsecured relational database system is first converted to a secure system by providing mechanisms for converting existing data that resides in the relational database into encrypted format with minimal impact to the resources of the relational database. According to certain embodiments, after the relational database is converted to a secure system, the security of such a relational database is further enhanced by periodically re-encrypting the data in the database using new encryption keys. The periodic re-encryption of data in the database using new encryption keys is herein referred to as key rotation.

According to certain embodiments, a mechanism is provided for automatically selecting a new encryption key for re-encrypting data in the target database. According to certain embodiments, new initialization vectors may be specified for re-encrypting each column of data selected for re-encryption. According to certain embodiments, a new initialization vector may be specified for one or more rows of data in a database table that is selected for re-encryption. According to certain embodiments, the mechanism that is used for automatically re-encrypting data in the target database includes the following functionality: 1) allow a user to select one or more previously encrypted columns for re-encryption, 2) allow the user to specify a new initialization vector at the column level for columns selected by the user for re-encryption, 3) allow the user to request for the generation of a new initialization vector at the row level for each row selected by the user for re-encryption, 4) allow the user to specify a new encryption key for use in the re-encryption of the column or row data selected by the user, 5) allow the user to specify a batch size for the re-encryption of the data selected by the user, 6) execute the re-encryption as specified by the user, 7) log the history of the encryption key usage to assist in data decryption of back-up data of the relational database at a later time, if so desired, and 8) allow the user to specify a different encryption mode, if desired.

According to certain embodiments, a mechanism is provided to allow the re- encryption of the user selected data to occur on a device that is separate from the relational database so as to not drain the computing and storage resources of the relational database. Such a mechanism can include a management console for managing the re-encryption of data specified by the user from the target relational database.

According to certain embodiments, the re-encryption of the database data that is selected for re-encryption is performed on a specialized piece of hardware that is designed to rapidly perform data encryption on large volumes of data from the relational database that is targeted for conversion to a secure system. Further, such a specialized piece of hardware is equipped with its own CPU and processing power in order to offload the database server that is associated with the target relational database. According to certain other embodiments, the re-encryption of the user selected data is performed by the target database server or by some other mechanism related to the target database.

According to certain embodiments, a mechanism that is used for migrating target data for encryption from the target database includes the following functionality: 1) identify which tables a user is authorized to modify, 2) determine which columns, in the identified tables, that the user is authorized to encrypt, 3) accept input parameters for specifying the characteristics of the desired encryption, 4) modify or create column lengths and data types as required for each column that is targeted for encryption, 5) encrypt clear text data that is present in each column that is targeted for encryption, and 6) provide an "undo" functionality for restoring an encrypted column to its original size and data type as well as restore the target data to its unencrypted form.

According to certain embodiments, a mechanism is provided to allow the encryption of the target data to occur on a device that is separate from the relational database so as to not drain the computing and storage resources of the relational database. Such a mechanism can include a management console for managing the migration of data from the target database to the encryption server for processing.

According to certain embodiments, the database data that is targeted for encryption is performed on a specialized piece of hardware that is designed to rapidly perform data encryption on large volumes of data from the relational database that is targeted for conversion to a secure system. Further, such a specialized piece of hardware is equipped with its own CPU and processing power in order to offload the database server that is associated with the target relational database.

According to certain embodiments, a mechanism that is separate from the relational database and that is used for encrypting target data stores cryptographic keys in a highly secure manner so as to be inaccessible to non-authenticated processes.

According to certain embodiments, a mechanism that is separate from the target relational database issues a select statement to retrieve target data from the target relational database. Such a mechanism then performs multithreaded, hardware level encryption on the target data. After the target data is encrypted, the mechanism issues an update statement to copy the encrypted data back into the target relational database.

According to certain embodiments, an unsecured database system is converted to a secure system by providing mechanisms for converting existing data that resides in the relational database into encrypted format. Further, according to certain embodiments, a mechanism is provided to allow for granular protection of sensitive data in the database. In other words, certain tables in the database can be selected for encryption. If desired, certain columns in a given database table can be selected for encryption, rather than encrypting the entire database table. Such granular protection is implemented with minimal impact to the database and the application programs that access data in the database. Authorized application programs can seamlessly access encrypted data with little or no change to the application program.

According to certain embodiments, a mechanism is provided to allow application programs that are external to the relational database to access the sensitive data in the database in a seamless fashion. To explain, the application programs should be allowed to use existing query statements that are normally used for accessing non- encrypted data without having to modify such statements for accessing encrypted data in the relational database. In other words, the application programs can use the same query statements that were used for accessing the sensitive data in the database before the sensitive data was encrypted.

According to certain embodiments a mechanism is provided for allowing the management of a seamless interaction between the relational database and the one or more mechanisms for: 1 ) encrypting and decrypting data on demand from inside the relational database, 2) migrating data from plaintext columns to encrypted columns, 3) automating subsequent encrypt and decrypt operations, 4) authenticating users so that only authorized users are able to access sensitive data.

According to some embodiments, when an authorized application program makes requests to access sensitive data that is already encrypted in a given source database table, a view of the source table is instantiated using metadata tables. Further, the requested sensitive data is decrypted and such a view is populated with the decrypted sensitive data. Any actions executed by the requesting application program on the view are captured. In response to the captured actions, new actions are automatically executed on the corresponding source table as if the requesting application was acting directly on the corresponding source table.

FIG. 1 is a high-level block diagram that illustrates a system architecture for transparent encryption, according to certain embodiments. In architecture 100, a client computer 102 can access, through a web server 104, an application server 106. Application server 106 can communicate with a relational database 108. Relational database 108 includes a database provider 110 and a cryptography provider 112. Database provider 110 and cryptography provider 112 are capable of communicating with a cryptography server 114. Cryptography server 114 is also referred to as a network-attached cryptography server (NAE server).

According to certain embodiments, the database provider, such as database provider 110, is a PL/SQL (Procedural Language/Structured Query Language) layer that comprises several functions for exposing features of a given cryptography provider to a given relational database. Such functions include but are not limited to: 1) function for setting system properties that the cryptography provider may need such as setting the location of client certificate key store and password, 2) function for setting the cryptography server user name and password for a specific user of the relational database, 3) optional function for encrypting a string and returning the data as a Base64 encoded string, 4) optional function for decrypting Base64 encoded string and returning the original unencrypted string, 5) optional function for encrypting a number and returning the data as a Base64 encoded string, 6) optional function for decrypting Base64 encoded string and returning the original unencrypted number, 7) optional function for encrypting a string and returning the data as a raw binary, 8) function for decrypting a raw binary and returning the original unencrypted string, 9) function for encrypting a number and returning the data as a raw binary, 10) function for decrypting a raw binary and returning the original unencrypted number, 11 ) function for encrypting a string and returning the data as bit data, 12) function for decrypting bit data and returning the original unencrypted string, 13) function for encrypting a number and returning the data as bit data, and 14) function for decrypting bit data and returning the original unencrypted number. According to certain embodiments, the cryptography server, such as the NAE server, listens for client connections and manages cryptography operations and encryption key management operations. The cryptography server allows a user or cryptography server client to perform cryptography operations including operations associated with encryption keys, authentication, encryption and decryption of data, create digital signatures, generation and verification of Message Authentication Code (MAC).

The cryptography server allows a cryptography server client to perform cryptography operations through the cryptography provider. The cryptography provider is the API to the cryptography server, according to certain embodiments. It is the cryptography provider that communicates with the cryptography server to request for cryptography services.

FIG. 2 is a flowchart that illustrates some of the steps that are performed for converting sensitive data that is stored in clear text format in a relational database into encrypted format in a manner so as to allow application programs that access the relational database to interact with a cryptography server for performing cryptography operations in a manner that is transparent to the application programs, according to certain embodiments. At block 202, sensitive data is identified and the database table where such sensitive data resides is identified. The identified database table where such sensitive data resides is herein referred to as the source table. For purposes of explanation in reference to FIG. 2, assume that a database table called "CUSTOMER" includes sensitive data (credit card numbers) in a column called CC_NUM, as shown in Table 1 , herein. TABLE 1

At block 204, source table "CUSTOMER" is renamed so that a view can be created later with the same name, "CUSTOMER". Assume that the source table "CUSTOMER" is renamed to "CUSTOMER_ENC" as shown in Table 2, herein. However, data in column CC_NUM in the renamed source table "CUSTOMER_ENC" as shown in Table 2 has not yet changed but will change in a manner as described at block 210.

TABLE 2

At block 206, a temporary table is created and the sensitive data from column

CC_NUM from the renamed source table, CUSTOMER_ENC, is exported to the temporary table. After exporting the sensitive data to the temporary table as described at block 206, at block 208, the data in column CC_NUM in CUSTOMER_ENC are set to null to avoid any data conversion that might arise when changing the data type at a later step. An example of temporary table is shown in TABLE 3 as CUSTOMER_TEMP, herein. TABLE 3

At block 210, the data type and column size of column CC_NUM are modified to accommodate encrypted data because encrypted data is predictably larger than clear text data. As a non-limiting example, the encrypted data can be stored in Base64 encoded format or as binary data. After the data type and column size of column CC_NUM have been modified, and before the sensitive data from temporary table, CUSTOMEFMΕMP, is imported back into CUSTOMER_ENC, at block 212, the cryptography provider sends the sensitive data from the temporary table to cryptography server where the sensitive data is encrypted.

At block 214, the cryptography server returns the encrypted sensitive data to the cryptography provider. The cryptography provider inserts the encrypted sensitive data into column CC_Num of the renamed source table, CUSTOMERJΞNC. The source table that includes encrypted data may appear as shown in Table 4, herein. TABLE 4

FIG. 3 is a flowchart that illustrates some of the steps that are performed for allowing an application program to access encrypted data from a database without modification to query statements sent by the application for accessing such encryption data, according to certain embodiments. For purposes of explanation, assume that a user wishes to access sensitive data that is stored in encrypted format in a relational database. The sensitive data that the user requests to access is herein after referred to as "requested sensitive data." FIG. 3 is described herein in reference to FIG. 1. In reference to FIG. 1 , the user can use client computer 102 to access application server 106 via the web server 104. Application server 106 manages at least one application program (not shown in FIG. 1 ) for accessing data from relational database 108. Assume that application server 106 and the at least one application program are agnostic as to the encrypted format of the sensitive data stored in relational database 108. Even though the requested sensitive data is encrypted, the application server 106 and the associated application program operate as if the sensitive data is in clear text format.

At block 302 of FIG. 3, the application server makes a call to the relational database and sends a query to request access to data in the database on behalf of the user. At block 304, a decision is made as to whether the requested data is sensitive data. If it is determined that the requested data is not sensitive data, then at block 306, the query is satisfied by allowing the user to access the non-sensitive data.

However, if it is determined that the requested data is sensitive data, then at block 308, the user is authenticated to the cryptography server through the cryptography provider. In a non-limiting example of authentication, the user is asked for a valid user name and password. In another non-limiting example of authentication, in addition to being asked for a valid user name and password, the user may be asked for a client certificate. In another non-limiting example, the user's credentials are stored in the relational database, and thus can be retrieved from the database.

At block 310, it is determined if the user is successfully authenticated. If it is determined that the user is not successfully authenticated, then at block 312, the user's request to access data is denied.

However, it is determined that the user is successfully authenticated, then at block 314, the database provider automatically instantiates a view of the database table that contains the requested sensitive data and populates the instantiated view with the decrypted form of the requested sensitive data. According to certain embodiments, such a view is instantiated using metadata tables. At block 316, the populated instantiated view is revealed to the user. The user can then interact with the revealed view. Returning to the example described in reference to FIG. 2, an example of a populated view is shown in Table 5, herein. TABLE 5

At block 402 in FIG. 4, the authorized user executes a query insert statement on the populated instantiated view in order to insert new sensitive data into a given database table in the relational database. Because the populated instantiated view has the same name as the corresponding original source database table, the query statements that reference an encrypted column or encrypted data can function regularly without modification.

At block 404, in response to the authorized user's attempt to execute the insert statement on the view, one or more triggers cause the user's insert statement to be trapped. At block 406, a request is made to the NAE server for encryption to be performed so that a new insert statement can be generated based on the insert values of the trapped insert statement. In other words, the NAE server performs encryption on the insert values. At block 408, the new insert statement is executed on the corresponding source database table corresponding to the populated instantiated view.

At block 502 in FIG. 5, the authorized user executes a query update statement on the populated instantiated view in order to update new sensitive data into a given database table in the relational database. Because the populated instantiated view has the same name as the corresponding original source database table, the query statements that reference an encrypted column or encrypted data can function regularly without modification.

At block 504, in response to the authorized user's attempt to execute the update statement on the view, one or more triggers cause the user's update statement to be trapped. At block 506, a new update statement is generated based on the update values of the trapped update statement. At block 408, the new update statement is executed on the original database table corresponding to the populated instantiated view.

FIG. 6 is a high-level block diagram that illustrates system architecture for re- encryption of data that is previously encrypted in a database using an encryption mechanism that is separate from the database, according to certain embodiments. In architecture 600, a client computer 602 is capable of communicating with a cryptography server 614. Cryptography server communicates with relational database 608. Cryptography server includes, among other components, a CPU and processing power. The cryptography server can be used for storing information that includes but is not limited to information on database connection and access privileges to encrypted data.

Cryptography server 614 is also referred to as a network-attached cryptography server (NAE server). Relational database 608 includes, among other components, a plurality of data tables such as table 610 and a plurality of metadata tables such as metadata table 612. The metadata tables such as metadata table 612 in the relational database can be used for storing information that includes but is not limited to 1 ) each authorized user's access rights with respect to database tables and columns managed by the relational database, and 2) database table and column schema, 3) information on encryption methods, and 4) information on properties of tables and columns that are selected for encryption from the target database. The cryptography server retrieves target data selected by the user from the target relational database for re-encryption. The cryptography server then performs re-encryption on the user selected data using the new encryption key and/or new initialization vector selected by the user.

A user such as a security administrator or database administrator can use a client computer to manage the re-encryption process of data in the relational database by accessing a data management console associated with the cryptography server. According to certain embodiments, the data management console allows the user to login to a desired database server and select data for re-encryption. In certain other embodiments, the desired relational database may include a database provider and cryptography provider. According to certain embodiments, the database provider is that portion of the computer-implemented functionality that resides on the database server and that communicates with the NAE server. The cryptography provider communicates with the cryptography server to request for cryptography services. The cryptography provider is the API to the cryptography server, according to certain embodiments.

According to certain embodiments, the cryptography server, such as the NAE server, manages cryptography operations and encryption key management operations. The cryptography server allows a user or cryptography server client to perform cryptography operations including operations associated with the encryption and decryption of data, encryption keys, authentication, creation of digital signatures, generation and verification of Message Authentication Code (MAC). According to certain embodiments, the cryptography server includes a key rotation tool that includes the following functionality: 1 ) allow a user to select one or more previously encrypted columns for re-encryption, 2) allow the user to specify a new initialization vector at the column level for columns selected by the user for re- encryption, 3) allow the user to request generation of a new initialization vector at the row level for each row selected by the user for re-encryption, 4) allow the user to specify a new encryption key for use in the re-encryption of the column or row data selected by the user, 5) allow the user to specify a batch size for the re-encryption of the data selected by the user, 6) execute the re-encryption as specified by the user, 7) log the history of the encryption key usage to assist in data decryption of back-up data of the relational database at a later time, if so desired, and 8) allow the user to specify a different encryption mode, if desired.

FIG. 7 is a flowchart that illustrates some of the steps that are performed for re- encrypting data in columns or rows in the target database that is selected by the user for re-encryption in a manner that has minimal impact on the target relational database.

At block 702 of FIG. 7, a user, such as a security administrator, or a database administrator, begins the data re-encryption process of selected column or row data (also referred to as target data) from the target relational database for purposes of re- encryption. According to certain embodiments, the user can begin the data re- encryption process by accessing a cryptography server, such as cryptography server 604 of FIG. 6. According to certain embodiments, the cryptography server may include an encryption key rotation tool with a front-end user interface. The front-end user interface of such a key rotation tool is herein also referred to as a data management console. The data management console allows the user to enter a specific set of data that is required to login to the target database. The specific set of data that is required for logging in may vary based on the database vendor. Thus, according to certain embodiments, the management console allows the user to specify the database type of the target database. Based on the database type, the management console can then present the login data fields for logging into the target database.

When the user's login information is submitted, an attempt to connect to the target database server is initiated. According to certain embodiments, if the connection attempt is successful, the database connection information is stored on the cryptography server. Such database connection information can be collected and stored for each type of database so that during future login attempts, the user can be presented with a login screen that requires a minimum amount of data entry for a selected target database.

If the connection attempt to connect with to the target database is unsuccessful, then the user may be presented with an error message and is allowed to re-enter login information.

At block 704 of FIG. 7, once connected to the target database of the user's choosing, the management console can then present a list of previously encrypted database tables that are available to the user for re-encryption, according to certain embodiments. According to certain embodiments, database metadata tables, such as metadata table 612, are queried based on the user's user id. The database metadata tables are queried based on user id in order to determine a list of database tables that have been previously encrypted by the user. The list of database tables that the user has previously encrypted is herein referred to as a target list of database tables. The target list of database tables is returned to the management console for presenting to the user.

At block 706 of FIG. 7, the user can select a database table from the target list of database tables for re-encryption. The database table that is selected by the user is herein referred to as the selected database table. The selected database table is sometimes referred to herein as a base table. At block 708 of FIG. 7, a list of columns is presented to the user. According to certain embodiments, the database metadata tables are queried based on the user's user id to determine the list of columns that were previously encrypted by the user in the selected database table. The list of columns in the selected database table that the user previously encrypted is herein referred to as a target list of columns. The target list of columns is returned to the management console for presenting to the user.

At block 710 of FIG. 7, the user is allowed to select the columns for re-encryption from the target list of columns. At block 712, the user is allowed to specify a new encryption key for each of the one or more selected columns. Optionally, in addition to selecting a new encryption key, the user is allowed to select a different encryption mode. The user is also allowed to select a new initialization vector for each of the one or more selected columns. If the user selects an initialization vector at the row level, then all columns in the selected database table will be encrypted using the new initialization vector and the newly selected encryption key, whether or not a given column in the selected database table was selected for key rotation. According to certain embodiments, the user's choices may be stored in the cryptography server for future reference.

At block 714, the user is allowed to specify a batch size for controlling the number of rows that are processed before being committed. At block 716 of FIG. 7, the user is allowed to select another table for re-encryption and the above process is repeated. At block 718, after the user has completed his or her selection of tables and columns for re-encryption, scripts may be generated to automatically perform the key rotation of the user's selected tables and columns from the target database to the cryptography server for re-encryption and other necessary modification. For example, a stored procedure for automating the decryption and re-encryption of a bulk load of selected data may be used. The stored procedure may be called from the database server, according to certain embodiments.

FIG. 8 is a high-level block diagram that illustrates system architecture for encryption of data in a database using an encryption mechanism that is separate from the database, according to certain embodiments. In architecture 800, a client computer 802 is capable of communicating with a cryptography server 814. Cryptography server communicates with relational database 808. Cryptography server includes, among other components, a CPU and processing power. The cryptography server can be used for storing information that includes but is not limited to information on database connection and access privileges to encrypted data. Cryptography server 814 is also referred to as a network-attached cryptography server (NAE server).

Relational database 808 includes, among other components, a plurality of data tables such as table 810 and a plurality of metadata tables such as metadata table 812. The metadata tables in the relational database can be used for storing information that includes but is not limited to 1) each authorized user's access rights with respect to database tables and columns managed by the relational database, and 2) database table and column schema, 3) information on encryption methods, and 4) information on properties of tables and columns that are selected for encryption from the target database. The cryptography server retrieves target data from the selected target relational database. The cryptography server then performs encryption on the target data. According to certain embodiments, the cryptography server then performs multithreaded, hardware level encryption on the target data.

A user such as a security administrator or database administrator can use a client computer to manage the encryption process of data in the relational database by accessing a data management console associated with the cryptography server. According to certain embodiments, the data management console allows the user to login to a desired database server and communicate with the database. In certain other embodiments, the desired relational database may include a database provider and cryptography provider. According to certain embodiments, the database provider is a computer-implemented functionality of the relational database server and can communicate with the cryptography server. The cryptography provider communicates with the cryptography server to request for cryptography services. The cryptography provider is the API to the cryptography server, according to certain embodiments.

According to certain embodiments, the cryptography server, such as the NAE server, manages cryptography operations and encryption key management operations. The cryptography server allows a user or cryptography server client to perform cryptography operations including operations associated with the encryption and decryption of data, encryption keys, authentication, creation of digital signatures, generation and verification of Message Authentication Code (MAC).

According to certain embodiments, the cryptography server includes a data migration tool that includes the following functionality: 1 ) identify which tables a user is authorized to modify, 2) determine which columns, in the identified tables, that the user is authorized to encrypt, 3) accept input parameters for specifying the characteristics of the desired encryption, 4) modify or create column lengths and data types as required for each column that is targeted for encryption, 5) encrypt clear text data that is present in each column that is targeted for encryption, and 6) provide an "undo" functionality for restoring an encrypted column to its original size and data type as well as restore the target data to its unencrypted form.

FIG. 9 is a flowchart that illustrates some of the steps that are performed for converting sensitive data that is stored in clear text format in a target relational database into encrypted format in a manner that has minimal impact on the resources of the target relational database.

At block 902 of FIG. 9, a user, such as a security administrator, begins the data migration of selected sensitive data (also referred to as target data) from the target relational database for purposes of encryption. According to certain embodiments, the user can begin the data migration by accessing a cryptography server, such as cryptography server 804 of FIG. 8. According to certain embodiments, the cryptography server may include a data migration tool with a front-end user interface. The front-end user interface of such a data migration tool is herein also referred to as a data management console. The data management console allows the user to enter a specific set of data that is required to login to the target database. The specific set of data that is required for logging in may vary based on the database vendor. Thus, according to certain embodiments, the management console allows the user to specify the database type of the target database. Based on the database type, the management console can then present the login data fields for logging into the target database.

At block 904 of FIG. 9, once connected to the target database, the management console can then present a list of database tables that are available to the user for modification, according to certain embodiments. According to certain embodiments, database metadata tables, such as metadata table 612, are queried based on the user's user id. Such metadata tables store information on the database tables that reside in the target database. The database metadata tables are queried based on user id in order to determine a list of database tables that the user is authorized to access and modify. The list of database tables that the user is authorized to access and modify is herein referred to as an accessible list of database tables. The accessible list of database tables is returned to the management console for presenting to the user.

At block 906 of FIG. 9, the user can select a database table from the accessible list of database tables for migration and subsequent modification. The database table that is selected by the user is herein referred to as the selected database table. The selected database table is sometimes referred to herein as a base table. At block 908 of FIG. 9, a list of columns is presented to the user. According to certain embodiments, the database metadata tables are queried based on the user's user id to determine the list of columns that are available to the user for modification in the selected database table. The list of columns in the selected database table that the user is authorized to access and modify is herein referred to as an accessible list of columns.

The accessible list of columns is returned to the management console for presenting to the user. According to certain embodiments, in addition to determining the accessible list of columns, the database metadata tables and the encryption information stored on the cryptography server can be queried to determine certain information on the columns that may be useful to the user. The information on the columns that may be useful to the user is herein referred to as column information. The column information can help the user decide whether to accept or reject the column as a candidate for encryption.

The column information is returned to the management console for presenting to the user. Such column information may vary from implementation to implementation. Some non-limiting examples of column information relate to: 1) whether a column has a data type that is supported (the user is advised to reject columns with non-supported data types as candidates for encryption), 2) whether a column is used as a primary key (the user is informed that a primary key column may be encrypted if such a column is not referenced as a foreign key, either explicitly or implicitly), 3) whether a column is used as a foreign key (the user is advised to reject columns that are used as foreign keys as candidates for encryption), 4) whether a column is used in an index (the user is advised that the sort order of encrypted data will not be consistent with the sort order of clear text data), 5) whether a column has a default value assigned to it (the user is advised to reject columns that have default value assigned to them as candidates for encryption), 6) whether a column has a check constraint (the user is advised to reject columns that have check constraints as candidates for encryption), 7) whether a column is referenced in any triggers on the database table in which the column resides (the user is advised to review the trigger(s) to see if the trigger(s) will function as expected), and 8) whether a column is in encrypted format (the user is advised to reject columns that are already encrypted as candidates for encryption). One or more of the above non-limiting examples of column information may involve manual checks, according to certain embodiments.

At block 910 of FIG. 9, the user is allowed to select the columns for encryption from the target database (base table). At block 912, the user is allowed to select the encryption method and the associated encryption characteristics for the selected columns. For example, the user may be allowed to select the encryption algorithm, mode, initialization vector, and padding. According to certain embodiments, the user's choices may be stored in the cryptography server for future reference. At block 914 of FIG. 9, the user is allowed to select another table for encryption and the above process is repeated. At block 916, after the user has completed his or her selection of tables and columns for encryption, scripts may be generated to automatically perform the data migration of the user's selected tables and columns and other necessary modification. An example of one of the functions of the scripts is the modification of column sizes based on the selected encryption algorithm and selected encryption characteristics so as to accommodate the target after the target data is encrypted. The set of scripts may vary for each type of relational database. Each type of database management system may support varying functionalities. Thus, the process for data migration may be tailored to each type of database management system (DBMS).

FIG. 10 is a non-limiting high-level example of a data migration script for a SQL Server type DBMS. At block 1002, an identity column is added to the base table from which columns are selected for encryption if such an identity column does not already exist.

At block 1004, data from the columns that are selected for encryption from the base table referenced in block 1002 are loaded into a temporary table, along with the identity referenced in block 1002 and an incremented row counter. According to certain embodiments, the incremented row counter can be used to support user-specified batch sizes for processing. The loaded data in the temporary table is then encrypted by the cryptography server using the selected encryption method, mode, initialization vector and padding, if applicable. At block 1006, the data values corresponding to the columns selected for encryption in the base table referenced in block 1002 are set to NULL. The data values are set to NULL in order to modify the corresponding column size and datatype.

At block 1008, the column size and datatype of the columns selected for encryption are modified in order to support the selected encryption algorithm and padding.

At block 1010, the base table referenced in block 1002 is updated with the encrypted version of the data from the temporary table referenced in block 1004 by calling one of the TSQL encryption procedures.

At block 1012, the temporary table referenced in block 1004 is dropped after the data encryption process is complete and validated. At block 1014, an "undo" functionality is provided for reversing the encryption process as described with reference to FIG. 10 so as to return the base table or any specified columns to its original unencrypted form, if reversal is indeed desired.

FIG. 11 is a non-limiting high-level example of a data migration script for a DB2

Server type DBMS. At block 1102, for each column of data selected for encryption, a new column is added to the base table from which columns are selected for encryption. At block 1104, the selected column data is encrypted by the cryptography server and the new columns referenced in block 1102 are updated with the encrypted version of the column data.

At block 1106, the column values of the original unencrypted data are set to NULL. At block 1108, the base table referenced in block 1102 is renamed in order to create a view of the base table with the same original name. At block 1110, a view is created on the base table referenced in block 1108 with the same name as the base table before the base table was renamed. At block 1112, an "undo" functionality is provided for reversing the encryption process as described with reference to FIG. 11 so as to return the base table or any specified columns to its original unencrypted form, if reversal is indeed desired.

In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMS We Claim:

1. A computer-implemented method for providing security to data in a database, said method comprising: providing a mechanism for allowing a user to select at least one previously encrypted column; and providing an automated tool that is associated with said mechanism for allowing said user to specify a new key for re-encryption of data in said at least one selected previously encrypted column.

2. The computer-implemented method of Claim 1 , further comprising allowing said user to specify a new initialization vector for said re-encryption of said at least one selected previously encrypted column.

3. The computer-implemented method of Claim 1 , further comprising allowing said user to request that a new initialization vector for one or more rows be generated for said re-encryption of said at least one selected previously encrypted column.

4. The computer-implemented method of Claim 1 , further comprising allowing said user to specify a batch size for said re-encryption.

5. The computer-implemented method of Claim 1 , further comprising performing said re-encryption.

6. The computer-implemented method of Claim 1 , further comprising logging a history of encryption key usage with respect to each column selected by said user for said re-encryption.

7. The computer-implemented method of Claim 1 , further comprising providing a management console with a graphical user interface for using said automated tool.

8. The computer-implemented method of Claim 7, wherein said interface is web-

based.

9. An encryption system for encrypting data in a database, the encryption system comprising: a means for allowing a user to select at least one previously encrypted column for re-encryption; and a means for allowing said user to specify a new key for said re-encryption of data in said at least one selected previously encrypted column.

10. The encryption system of Claim 9, further comprising means for allowing said user to specify a new initialization vector for said re-encryption of said at least one selected previously encrypted column.

11. The encryption system of Claim 9, further comprising means for allowing said user to specify a new initialization vector for one or more rows for said re-encryption of said at least one selected previously encrypted column.

12. The encryption system of Claim 9, further comprising means for allowing said user to specify a batch size for said re-encryption.

13. The encryption system of Claim 9, further comprising means for performing said re-encryption.

14. The encryption system of Claim 9, further comprising means for logging a history of encryption key usage wit respect to each column selected by said user for said re- encryption.

15. An apparatus for encrypting data in a database, the apparatus comprising: one or more processors; a storage for encryption keys; an authentication mechanism for authenticating a user who desires to access said database; a database interface for interfacing with said database; a management console for allowing said user to manage said data in said database; a storage medium carrying one or more sequences of one or more instructions which, when executed by said one or more processors, cause said one or more processors to perform the steps of: providing a mechanism for allowing said user to select at least one previously encrypted column; and providing an automated tool that is associated with said mechanism for allowing said user to specify a new key for re-encryption of data in said at least one selected previously encrypted column.

16. The apparatus of Claim 15, further comprising allowing said user to specify a new initialization vector for said re-encryption of said at least one selected previously encrypted column.

17. The apparatus of Claim 15, further comprising allowing said user to specify a new initialization vector for one or more rows for said re-encryption of said at least one selected previously encrypted column.

18. The apparatus of Claim 15, further comprising allowing said user to specify a batch size for said re-encryption.

19. The apparatus of Claim 15, further comprising performing said re-encryption.

20. The apparatus of Claim 15, further comprising logging a history of encryption key usage wit respect to each column selected by said user for said re-encryption.

21. The apparatus of Claim 15, further comprising providing a management console with a graphical user interface for using said automated tool.

22. The apparatus of Claim 21 , wherein said interface is web-based.

23. A computer-implemented method for encrypting data from a database, said method comprising: providing a mechanism having computing resources that is divorced from resources of said database for performing encryption operations; providing an automated tool that is associated with said mechanism for: selecting target data for encryption; selecting an encryption method for said target data; specifying one or more characteristics for said selected encryption method; and modifying a corresponding schema for each database column where said target data resides in a manner for accommodating said target data after said target is encrypted.

24. The computer-implemented method of Claim 23, further comprising providing a functionality for restoring said each database column to its original size and data type.

25. The computer-implemented method of Claim 23, further comprising determining which data in said database can be modified by a user based on said user's access rights to said database.

26. The computer-implemented method of Claim 25, further comprising identifying which database tables in said database can be modified by said user.

27. The computer-implemented method of Claim 26, further comprising determining which columns in said identified database tables can be modified by said user.

28. The computer-implemented method of Claim 23, further comprising encrypting said target data using said selected encryption method.

29. The computer-implemented method of Claim 23, further comprising restoring said target data to its original unencrypted form after said target data is encrypted.

30. The computer-implemented method of Claim 23, further comprising providing a management console with a graphical user interface for using said automated tool.

31. The computer-implemented method of Claim 30, wherein said interface is web- based.

32. The computer-implemented method of Claim 23, wherein said one or more characteristics for said selected encryption method comprises an encryption algorithm type, a mode type, a padding and an initialization vector.

33. The computer-implemented method of Claim 32, wherein said encryption algorithm type includes DES, DESede, AES, RC4, HMAC, RSA.

34. The computer-implemented method of Claim 32, wherein said mode type includes CBC mode and EBC mode.

35. An encryption system for encrypting data in a database, the encryption system comprising: a means for selecting target data for encryption; a means for selecting an encryption method for said target data; a means for specifying one or more characteristics for said selected encryption method; and a means for modifying a corresponding schema for each database column where said target data resides in a manner for accommodating said target data after said target is encrypted.

36. The encryption system of Claim 35, further comprising a means for providing a functionality for restoring said each database column to its original size and data type.

37. The encryption system of Claim 35, further comprising a means for determining which data in said database can be modified by a user based on said user's access rights to said database.

38. The encryption system of Claim 37, further comprising a means for identifying which database tables in said database can be modified by said user.

39. The encryption system of Claim 38, further comprising a means for determining which columns in said identified database tables can be modified by said user.

40. The encryption system of Claim 35, further comprising a means for encrypting said target data using said selected encryption method.

41. The encryption system of Claim 35, further comprising a means for restoring said target data to its original unencrypted form after said target data is encrypted.

42. An apparatus for encrypting data in a database, the apparatus comprising: one or more processors; a storage for encryption keys; an authentication mechanism for authenticating users who desire to access said database; a database interface for interfacing with said database; a management console for allowing an administrator to manage said data in said database; a storage medium carrying one or more sequences of one or more instructions which, when executed by said one or more processors, cause said one or more processors to perform the steps of: selecting target data for encryption; selecting an encryption method for said target data; specifying one or more characteristics for said selected encryption method; and modifying a corresponding schema for each database column where said target data resides in a manner for accommodating said target data after said target is encrypted.

43. The apparatus of Claim 42, further comprising a first mechanism for restoring said each database column to its original size and data type.

44. The apparatus of Claim 42, further comprising a second mechanism for determining which data in said database can be modified by a user based on said user's access rights to said database.

45. The apparatus of Claim 44, further comprising a third mechanism for identifying which database tables in said database can be modified by said user.

46. The apparatus of Claim 45, further comprising a fourth mechanism for determining which columns in said identified database tables can be modified by said user.

47. The apparatus of Claim 42, further comprising a fifth mechanism for encrypting said target data using said selected encryption method.

48. The apparatus of Claim 42, further comprising a sixth mechanism for restoring said target data to its original unencrypted form after said target data is encrypted.

49. A computer-implemented method for allowing an application program to access sensitive data in a database in a manner that is transparent to said application program and said database, said method comprising: instantiating a view, when said application program attempts to access said sensitive data, wherein said view corresponds to a source table in said database and wherein said source table is where said sensitive data resides as encrypted data; populating said view with decrypted data corresponding to said sensitive data if said application program is authenticated; and revealing said view to said authenticated application program.

50. The computer-implemented method of Claim 49, further comprising encrypting said sensitive data in said source table to form said encrypted data.

51. The computer-implemented method of Claim 50, further comprising renaming said source table before instantiating said view.

52. The computer-implemented method of Claim 51 , further comprising naming said instantiated view with said source table's original name.

53. The computer-implemented method of Claim 50, further comprising creating a temporary table and exporting said sensitive data from said source table to said temporary table and then encrypting said sensitive data in said temporary table to form said encrypted data.

54. The computer-implemented method of Claim 53, further comprising returning said encrypted data from said temporary table to said source table.

55. The computer-implemented method of Claim 49, further comprising using one or more metadata tables for automatically instantiating said view.

56. The computer-implemented method of Claim 49, further comprising authenticating said application program when said application attempts to access said sensitive data stored in said database.

57. The computer-implemented method of Claim 49, further comprising trapping an insert statement for inserting data wherein said insert statement is executed on said view by said application program and creating, in response to said trapped insert statement, a new corresponding insert statement for inserting said data into said source table.

58. The computer-implemented method of Claim 49, further comprising trapping an update statement for updating said sensitive data wherein said update statement is executed on said view by said application program and creating, in response to said trapped update statement, a new corresponding update statement for updating said sensitive data in said source table.

59. The computer-implemented method of Claim 57, further comprising using one or more triggers for trapping said insert statement and for creating said new corresponding insert statement.

60. The computer-implemented method of Claim 59, further comprising automatically creating said one or more triggers based on one or more metadata tables, wherein said one or more metadata tables are configurable for defining database tables and columns that are targeted for encryption.

61. The computer-implemented method of Claim 57, further comprising using one or more triggers for trapping said update statement and for creating said new corresponding update statement.

62. The computer-implemented method of Claim 49, further comprising using a network attached encryption-decryption (NAE) mechanism that is adapted for decrypting said sensitive data for populating said view.

63. The computer-implemented method of Claim 49, further comprising using a network attached encryption-decryption (NAE) mechanism that is adapted for encrypting said sensitive data for storage in said source table.

64. A transparent encryption system for encrypting data in a database, the transparent encryption system comprising: means for encrypting and decrypting data on demand from within said database in order to integrate said database into said transparent encryption system; means for migrating data from one or more plaintext database table columns to corresponding one or more encrypted database table columns; means for automating subsequent encrypt and decrypt operations on said database after integrating said database into said transparent encryption system; and means for authenticating users so that only authorized users are able to access encrypted data in said integrated database.

65. A transparent encryption system for encrypting data in a database, the transparent encryption system comprising: means for instantiating a view, when an application program attempts to access sensitive data, wherein said view corresponds to a source table in a database and wherein said source table is where said sensitive data resides as encrypted data; means for populating said view with decrypted data corresponding to said sensitive data if said application program is authenticated; and means for revealing said view to said authenticated application program.

66. The transparent encryption system of Claim 65, further comprising means for authenticating said application program when said application attempts to access said sensitive data stored in said database.

67. The transparent encryption system of Claim 65, further comprising means for trapping an insert statement for inserting data wherein said insert statement is executed on said view by said application program and creating, in response to said trapped insert statement, a new corresponding insert statement for inserting said data into said source table.

68. The transparent encryption system of Claim 65, further comprising means for trapping an update statement for updating said sensitive data wherein said update statement is executed on said view by said application program and creating, in response to said trapped update statement, a new corresponding update statement for updating said sensitive data in said source table.

69. The transparent encryption system of Claim 65, further comprising means for decrypting said sensitive data for populating said view.

70. The transparent encryption system of Claim 65, further comprising means for encrypting said sensitive data for storage in said source table.