System, method, and computer-readable medium for cryptographic key rotation in a database system

[0001] A database is a collection of stored data that is logically related and that is accessible by one or more users or applications. A popular type of database is the relational database management system (RDBMS), which includes relational tables, also referred to as relations, made up of rows and columns (also referred to as tuples and attributes). Each row represents an occurrence of an entity defined by a table, with an entity being a person, place, thing, or other object about which the table contains information.

[0002] To prevent the compromise of sensitive information (credit card numbers, social security numbers, etc.) when stored in databases, industry standards and security/privacy regulations often mandate the use of encryption. Such standards and laws include the Health Insurance Portability and Accountability Act of 1996 (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS), and others.

[0003] Encryption is the process of translating data (clear text) into a form that is not interpretable (cipher text) should the data be compromised. This translation is done using strong cryptographic algorithms in conjunction with secret keys. The correct secret key is required to reverse the translation such that the original data can be interpreted.

[0004] Protection of the secret keys is critical to the security of the encrypted data. As such, key management best practices call for secure generation of keys, secure storage of keys, secure distribution of keys, restricted access to keys, and periodic key rotation.

[0005] Key rotation is generally defined as a process for replacement of a cryptographic key and includes the process of decrypting data with the original cryptographic key and subsequent re-encryption of the data with the new cryptographic key. Key rotation is often used when there is some indication that a key has been compromised. However, some regulations (such as PCI DSS) simply mandate periodic changing of keys “as deemed necessary.”

[0006] Most database encryption solutions provide for key rotation and generally will include utilities to perform the decryption/re-encryption operations and some implementations require that the database be offline during the key rotation process. But, in all cases, the key rotation process tends to be very CPU intensive and disruptive of normal query processing. This is particularly true if the amount of encrypted data is large—as is common for many data warehouse implementations. Further, unavailability of the data during the key rotation process may adversely affect applications involving tactical queries that are common for many active data warehouse implementations.

[0007] Disclosed embodiments provide a system, method, and computer readable medium for key rotation without disrupting database access. Generation identifiers that specify a particular encryption key are stored in association with cipher text of encrypted columns in database tables. When data is to be read from an encrypted column, the cipher text is read along with the associated generation identifier. An encryption key corresponding to the generation identifier is then used to decrypt the cipher text. When data is to be written to the encrypted column, a most recent encryption key is retrieved from the key repository to encrypt the data. The cipher text is then written to the encrypted column in association with the generation identifier of the key used to encrypt the data. Advantageously, the key rotation may be performed without requiring that the table or database to be taken offline or otherwise unavailable during key rotation.

[0019] It is to be understood that the following disclosure provides many different embodiments or examples for implementing different features of various embodiments. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting.

[0020] FIG. 1 depicts a diagrammatic representation of an exemplary architecture for a large database system 100, such as a Teradata Active Data Warehouse System, that is suited for implementing mechanisms for cryptographic key rotation in accordance with disclosed embodiments. The database system 100 includes a relational database management system (RDBMS) 160 built upon a massively parallel processing (MPP) system 150. Other types of database systems, such as object-relational database management systems (ORDBMS) or those built on symmetric multi-processing (SMP) platforms, are also suited for use, and the depicted and described architecture is exemplary only and is chosen to facilitate an understanding of the disclosed embodiments.

[0021] As shown, the database system 100 includes one or more processing nodes 105_{1 . . . Y} that manage the storage and retrieval of data in data-storage facilities 110_{1 . . . Y}. Each of the processing nodes may host one or more physical or virtual processing modules, such as one or more access module processors (AMPs). Each of the processing nodes 105_{1 . . . Y} manages a portion of a database that is stored in a corresponding one of the data-storage facilities 110_{1 . . . Y}. Each of the data-storage facilities 110_{1 . . . Y} includes one or more disk drives or other storage medium.

[0022] The system stores data in one or more tables in the data-storage facilities 110_{1 . . . Y}. The rows 115_{1 . . . Y} of the tables are stored across multiple data-storage facilities 110_{1 . . . Y} to ensure that the system workload is distributed evenly across the processing nodes 105_{1 . . . Y}. A parsing engine 120 organizes the storage of data and the distribution of table rows 115_{1 . . . Y} among the processing nodes 105_{1 . . . Y} and accesses processing nodes 105_{1 . . . Y} via an interconnect 130. The parsing engine 120 also coordinates the retrieval of data from the data-storage facilities 110_{1 . . . Y} in response to queries received from a user, such as one at a client computer system 135 connected to the database system 100 through a network 125 connection. The parsing engine 120, on receiving an incoming database query, applies an optimizer 122 component to the query to assess the best plan for execution of the query. Selecting the optimal query-execution plan includes, among other things, identifying which of the processing nodes 105_{1 . . . Y} are involved in executing the query and which database tables are involved in the query, as well as choosing which data-manipulation techniques will serve best in satisfying the conditions of the query. To this end, the parser and/or optimizer may access a data dictionary 124 that specifies the organization, contents, and conventions of one or more databases. For example, the data dictionary 124 may specify the names and descriptions of various tables maintained by the MPP system 150 as well as fields of each database. Further, the data dictionary 124 may specify the type, length, and/or other various characteristics of the stored tables. The database system typically receives queries in a standard format, such as the Structured Query Language (SQL) put forth by the American National Standards Institute (ANSI).

[0023] The system 100 may include or communicatively interface with a key repository 170 (described more fully hereinbelow with reference to FIG. 8) that stores cryptographic keys used to cipher secure data. Further, the key repository 170 maintains in association with cryptographic keys' generation identifiers that facilitate key rotation in accordance with embodiments.

[0024] FIG. 2 depicts a diagrammatic representation of a sample architecture for one node 105₁ of the DBS 100. The DBS node 105₁ includes one or more processing modules 205_{1 . . . N} connected by an interconnect 130 that manage the storage and retrieval of data in data-storage facilities 110_{1a . . . 1N}. Each of the processing modules 205_{1 . . . N} may be one or more physical processors or each may be a virtual processor, with one or more virtual processors running on one or more physical processors. For the case in which one or more virtual processors are running on a single physical processor, the single physical processor swaps between the set of N virtual processors. For the case in which N virtual processors are running on an M-processor node, the node's operating system schedules the N virtual processors to run on its set of M physical processors. If there are 4 virtual processors and 4 physical processors, then typically each virtual processor would run on its own physical processor. If there are 8 virtual processors and 4 physical processors, the operating system would schedule the 8 virtual processors against the 4 physical processors, in which case swapping of the virtual processors would occur.

[0025] Each of the processing modules 205_{1 . . . N} manages a portion of a database that is stored in a corresponding one of the data-storage facilities 110_{1a . . . 1N}. Each of the data-storage facilities 110_{1a . . . 1N} includes one or more disk drives. The DBS may include multiple nodes 105_{2 . . . Y} in addition to the illustrated node 105₁, connected by way of the interconnect 130.

[0026] The system stores data in one or more tables in the data-storage facilities 110_{1a . . . 1N}. The rows 115_{1a . . . 1N} of the tables are stored across multiple data-storage facilities 110_{1a . . . 1N} to ensure that the system workload is distributed evenly across the processing modules 205_{1 . . . N}. A parsing engine 221 organizes the storage of data and the distribution of table rows 110_{1a . . . 1N} among the processing modules 205_{1 . . . N}. The parsing engine 221 also coordinates the retrieval of data from the data-storage facilities 110_{1a . . . 1N} in response to queries received from a user at a client computer system 135_{1 . . . N}. The DBS 100 usually receives queries and commands to build tables in a standard format, such as SQL.

[0027] In one implementation, the rows 115_{1a . . . 1N} are distributed across the data-storage facilities 110_{1a . . . 1N} by the parsing engine 221 in accordance with their primary index. The primary index defines the columns of the rows that are used for calculating a hash value. The function that produces the hash value from the values in the columns specified by the primary index is called the hash function. Some portion, possibly the entirety, of the hash value is designated a “hash bucket.” The hash buckets are assigned to data-storage facilities 110_{1a . . . 1N} and associated processing modules 205_{1 . . . N} by a hash bucket map. The characteristics of the columns chosen for the primary index determine how evenly the rows are distributed.

[0028] In one example system, a parsing engine, such as the parsing engine 120, is made up of three components: a session control 300, a parser 305, and a dispatcher 310 as shown in FIG. 3. The session control 300 provides the logon and logoff functions. It accepts a request for authorization to access the database, verifies it, and then either allows or disallows the access. Once the session control 300 allows a session to begin, a user may submit a SQL request that is routed to the parser 305. As illustrated in FIG. 4, the parser 305 interprets the SQL request (block 400), checks the request for correct SQL syntax (block 405), evaluates the request semantically (block 410), and consults a data dictionary to ensure that all of the objects specified in the SQL request exist and that the user has the authority to perform the request (block 415). Finally, the parser 305 runs the optimizer 122 that selects the least expensive plan to perform the request.

[0029] FIG. 5 is a diagrammatic representation of an exemplary table 500 on which mechanisms for cryptographic key rotation may be implemented. Table 500 comprises a plurality of rows 510a-510j (collectively referred to as rows 510) and fields 520a-520i (collectively referred to as fields 520). Each record 510 comprises data elements in respective fields, or attributes, 520. In the present example, table 500 has a table name “Employee” and includes fields 520 having respective labels of “EmpNumber”, “LastName”, “FirstName”, “Phone”, “JobTitle”, “DeptNo”, “SSN”, “Sex”, and “Salary”.

[0030] With a contemporary database encryption solution, cryptographic keys are securely generated and stored in a repository separate form the database itself—e.g., another database, file, or hardware security module (HSM). Keys are made available to be used by encryption/decryption functions as required. Further, all data encrypted within a single column of a table is encrypted using the same cryptographic key. In the illustrative example, the Employee table 500 contains information about employees. Each row 510 represents a record for each employee and contains the employee's social security number (SSN) in field 520g which is considered sensitive and to be protected using encryption.

[0031] There are many approaches that can be designed to associate generation information with a cryptographic key. As an example, a key repository 600, as depicted by the diagrammatic representation of FIG. 6, may include the generation information. Particularly, the key repository 600 includes a record that includes a table identifier 610 and corresponding column identifier 620 that specifies a column of the table that has been encrypted. A key identifier 630 specifies the key that was used for encrypting the corresponding column.

[0032] Whenever data within an encrypted column is inserted or updated, the encryption of the data will always select and use the latest generation of the cryptographic key as specified by the key identifier 630. The generation information is subsequently stored within the column along with the resulting cipher text. When data is selected from an encrypted column, the key is retrieved from the repository 600 to decrypted the encrypted data. Disadvantageously, when key rotation is performed, the database may be taken offline during the key rotation process. Further, the key rotation process tends to be CPU intensive and disruptive of normal query processing.

[0033] In accordance with disclosed embodiments, mechanisms are provided that facilitate key rotation without disrupting database access. Generation identifiers that specify a particular encryption key are stored in association with cipher text of encrypted columns. When data is to be read from an encrypted column, the cipher text is read along with the associated generation identifier. An encryption key corresponding to the generation identifier is then read to decrypt the cipher text. When data is to be written to the encrypted column, a most recent encryption key is retrieved from the key repository 170 to encrypt the data. The cipher text is then written to the encrypted column in association with the generation identifier of the key used to encrypt the data. Advantageously, the key rotation may be performed without requiring that the table or database to be taken offline or otherwise unavailable during key rotation.

[0034] FIG. 7 is a diagrammatic representation of an exemplary table 700 on which mechanisms for cryptographic key rotation may be implemented in accordance with disclosed embodiments. Table 700 comprises a plurality of rows 710a-710j (collectively referred to as rows 710) and fields 720a-720i (collectively referred to as fields 720). Each row 710 comprises data elements in respective fields, or attributes, 720. In the present example, table 700 has a table name “Employee” and includes fields 720 having respective labels of “EmpNumber”, “LastName”, “FirstName”, “Phone”, “JobTitle”, “DeptNo”, “SSN”, “Sex”, and “Salary”.

[0035] In the illustrative example, the Employee table 700 contains information about employees. Each row 710 represents a record for each employee and contains the employee's social security number (SSN) in field 720g which is considered sensitive and to be protected using encryption. In accordance with disclosed embodiments, encryption generation information is stored in a field with the encrypted data. In a particular implementation, a generation identifier that specifies a particular encryption key is stored in the SSN field 720g along with the SSN cipher text. For example, row 720a includes cipher text (“*d5#AB[:0-GtW2<x”) and a corresponding generation identifier (“0002”) that is associated with an encryption key used to generate the cipher text. The generation identifier is stored in the encrypted field with the cipher text, e.g., by using a white space delimiter or other mechanism. When the cipher text is to be accessed, the generation identifier is retrieved from the column of a record along with the cipher text. An encryption key associated with the generation identifier is then retrieved from the key repository 170 to decrypt the cipher text.

[0036] A key repository 170 implemented in accordance with disclosed embodiments, as depicted by the diagrammatic representation of FIG. 8, includes encryption keys in association with generation identifiers. Particularly, the key repository 170 includes records that include a respective table identifier 810 and corresponding column identifier 820 that specifies a column of the table that has been encrypted. A generation identifier 830 is stored in association with an encryption key 840 that was used for encrypting data of a column of a particular row that specifies the generation identifier.

[0037] By maintaining information about multiple generations of cryptographic keys and associating the generation information with each cipher text value, the disclosed cryptographic mechanisms readily support a natural aging of data within a protected column while ensuring that the correct clear text value can be provided for any properly authorized request.

[0038] Advantageously, the described cryptographic mechanisms allow for a key rotation process without requiring that the table or database be offline or otherwise unavailable during key rotation. Key rotation is easily accomplished by simply selecting the data (resulting in a decryption using an old cryptographic key) and updating the data (resulting in an encryption using the new cryptographic key). Any access to the data during the key rotation process is guaranteed to produce the correct clear text result since the generation of the cryptographic key selected for the decryption will correspond to the key originally used to encrypt the data.

[0039] FIG. 9 is a flowchart 900 of an encryption routine implemented in accordance with disclosed embodiments. The processing steps of FIG. 9 may be implemented as computer-executable instructions tangibly embodied on a computer-readable medium executable by a processing system, such as the processing module 140 or a processing node 105_{1 . . . Y} depicted in FIG. 1.

[0040] The encryption routine is invoked (step 902), and a request to write data to an encrypted column is received (step 904). For example, the request may comprise an SQL INSERT or UPDATE statement. The most recent encryption key corresponding to the column of the table on which the request is directed is then retrieved from the key repository 170 along with the generation identifier associated with the encryption key (step 906). The data to be written to the encrypted column is then encrypted with the retrieved key (step 908), and the resulting cipher text is written to the column with the generation identifier of the key used to encrypt the data (step 910). The encryption routine cycle may then end (step 912).

[0041] FIG. 10 is a flowchart 1000 of a decryption routine implemented in accordance with disclosed embodiments. The processing steps of FIG. 10 may be implemented as computer-executable instructions tangibly embodied on a computer-readable medium executable by a processing system, such as the processing module 140 or a processing node 105_{1 . . . Y} depicted in FIG. 1.

[0042] The decryption routine is invoked (step 1002), and a request to read data from an encrypted column is received (step 1004). For example, the request may comprise an SQL SELECT statement. The cipher text of the encrypted column is then read along with the generation identifier stored therewith (step 1006). The key corresponding to the generation identifier read from the encrypted column is then retrieved from the repository 170 (step 1008). The cipher text of the encrypted column is then decrypted using the retrieved key (step 1010). The decryption routine cycle may then end (step 1012).

[0043] As described, mechanisms that facilitate key rotation without disrupting database access are provided. Generation identifiers that specify a particular encryption key are stored in association with cipher text of encrypted columns in database tables. When data is to be read from an encrypted column, the cipher text is read along with the associated generation identifier. An encryption key corresponding to the generation identifier is then read to decrypt the cipher text. When data is to be written to the encrypted column, a most recent encryption key is retrieved from the key repository to encrypt the data. The cipher text is then written to the encrypted column in association with the generation identifier of the key used to encrypt the data. Advantageously, the key rotation may be performed without requiring that the table or database to be taken offline or otherwise unavailable during key rotation. By maintaining information about multiple generations of cryptographic keys and associating the generation information with each cipher text value, the disclosed cryptographic mechanisms readily support a natural aging of data within a protected column while ensuring that the correct clear text value can be provided for any properly authorized request.

[0044] The flowcharts of FIGS. 9-10 depict process serialization to facilitate an understanding of disclosed embodiments and are not necessarily indicative of the serialization of the operations being performed. In various embodiments, the processing steps described in FIGS. 9-10 may be performed in varying order, and one or more depicted steps may be performed in parallel with other steps. Additionally, execution of some processing steps of FIGS. 9-10 may be excluded without departing from embodiments disclosed herein.

[0045] The illustrative block diagrams and flowcharts depict process steps or blocks that may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although the particular examples illustrate specific process steps or procedures, many alternative implementations are possible and may be made by simple design choice. Some process steps may be executed in different order from the specific description herein based on, for example, considerations of function, purpose, conformance to standard, legacy structure, user interface design, and the like.

[0046] Aspects of the disclosed embodiments may be implemented in software, hardware, firmware, or a combination thereof. The various elements of the system, either individually or in combination, may be implemented as a computer program product tangibly embodied in a machine-readable storage device for execution by a processing unit. Various steps of embodiments may be performed by a computer processor executing a program tangibly embodied on a computer-readable medium to perform functions by operating on input and generating output. The computer-readable medium may be, for example, a memory, a transportable medium such as a compact disk, a floppy disk, or a diskette, such that a computer program embodying aspects of the disclosed embodiments can be loaded onto a computer. The computer program is not limited to any particular embodiment, and may, for example, be implemented in an operating system, application program, foreground or background process, or any combination thereof, executing on a single processor or multiple processors. Additionally, various steps of embodiments may provide one or more data structures generated, produced, received, or otherwise implemented on a computer-readable medium, such as a memory.

[0047] Although disclosed embodiments have been illustrated in the accompanying drawings and described in the foregoing description, it will be understood that embodiments are not limited to the disclosed examples, but are capable of numerous rearrangements, modifications, and substitutions without departing from the disclosed embodiments as set forth and defined by the following claims. For example, the capabilities of the disclosed embodiments can be performed fully and/or partially by one or more of the blocks, modules, processors or memories. Also, these capabilities may be performed in the current manner or in a distributed manner and on, or via, any device able to provide and/or receive information. Still further, although depicted in a particular manner, a greater or lesser number of modules and connections can be utilized with the present disclosure in order to accomplish embodiments, to provide additional known features to present embodiments, and/or to make disclosed embodiments more efficient. Also, the information sent between various modules can be sent between the modules via at least one of a data network, an Internet Protocol network, a wireless source, and a wired source and via a plurality of protocols.