WO2001001223A1 - Two-layer encryption of databases - Google Patents

Abstract

A mechanism provides a method and apparatus to secure a database from access by unauthorized users while still allowing for a quick change of the server key used to encrypt and decrypt the database, by encrypting the bulk of the data records with a data records key, storing the data records key in a database control block and encrypting the database control block with the server key.

Description

TWO-LAYER ENCRYPTION OF DATABASES

CROSS-REFERENCE TO RELATED APPLICATIONS U.S. Patent Application No. 09/340,067, filed on June 25, 1999, the same day as the present application and entitled "Securing Databases Using Mutual Consent Access" is incorporated by reference herein for all purposes.

BACKGROUND OF THE INVENTION The present invention relates to the field of database security. More specifically, one embodiment of the invention provides for database encryption for large databases.

Often, the data stored in a database will need to be secured against access for reading and/or modification. Where access cannot be physically prevented, encryption of the data is useful to secure against access. For example, when a database is stored on an unsecured data storage device, the database might be encrypted using one of many well-known encryption schemes and a password kept secret by the owner of the data.

In a typical database application, a server interfaces the database to clients and the server decrypts portions of the database as needed to respond to queries from the clients. Typically, such operations are done in real-time and the database is stored on a data storage device that is relatively insecure, the database is encrypted such that an attacker cannot easily understand or modify data in the database without detection, but the owner (or other person or computing device) having the password to the database can access the data in the database by supplying the password to the server. In some systems, the password is referred to as a "server key" or similar term.

In a client-server system, the database might be specific to a server, in that clients can only access the database through a particular server. In some cases, for security reasons or otherwise, the server key is specific to the particular server. One reason for this is that if the key were not specific to the particular server, an attacker would be able to copy an encrypted database, connect it to another server and open the copy without the knowledge of the owner of the database. Of course, there are many legitimate reasons for transporting a database from one server to another. For example, a copy of a database might be stored apart from the original copy for use as backup. If the original server and database fail, another server could be brought on line using the backup copy. However, if the database were encrypted using a server specific key, the backup copy would need to be unencrypted and reencrypted. With large databases of information (multi-gigabyte databases are common), the time to unencrypt the database and reencrypt the database is considerable. Furthermore, if the owner changes a server key, the users might expect long delays as the database is unencrypted and reencrypted.

SUMMARY OF THE INVENTION

One embodiment of the present invention provides a mechanism to secure a database from access by unauthorized users while still allowing for a quick change of the server key used to encrypt and decrypt the database, by encrypting the bulk of the data records with a data records key, storing the data records key in a database control block and encrypting the database control block with the server key.

In one variation, asymmetric encryption is used, where the encryption key is different from the decryption key.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a database system according to one embodiment of the present invention.

Fig. 2 is a flowchart of a process for determining a method of encryption used to encrypt data.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Fig. 1 is a block diagram of a database system 10 according to one embodiment of the present invention. As shown there, a database 12 is stored on a data storage device 14. In this example, storage device 14 is assumed to be insecure in that an attacker could get access to data stored thereon. Such access would bypass a database management system (DBMS) server 16, which serves as the primary interface between database 12 and legitimate users of database 12. The users of database 12 use user I/O 18 to access the data in database 12 through DBMS server 16. In a typical operation, user I/O 18 operates as a client, according to standard client-server architectures, and DBMS server 16 operates as the server. Thus, the client might send an SQL (Structured Query Language) statement to the server and the server would respond with the appropriate response, assuming that any security requirements are met.

One such security requirement is a server security password that needs to be supplied before a server can open an encrypted database. When a server is supplied with the server security password, typically when the server is started, the server derives a server key from the server security password. The server security key is specific to a server. Another security requirement is a database password, which is specific to a database in this implementation.

If the server password is specific to a server, when database 12 is moved such that it is to be accessed by a different server, the server key of database 12 needs to change. For example, as shown in Fig. 1, if database 12 is secured by the server key of server 16 but is then moved, using file manager 20 or other mechanism, to an alternate storage device 22, another server 26 (with its own related user I/O 28) could not access the data in database 12 unless it used the same server key as server 16.

There are many reasons why database 12 might be moved. For example, a backup copy might be needed or a remote copy of database 12 might be needed. However, for whatever reason, whenever database 12 is moved or copied, the server key for database 12 changes.

Instead of encrypting all of the data in database 12 using the server key, which would create considerable delays as the entire database is unencrypted and reencrypted, the server key only encrypts a database control block (DCB) 40, typically around 1024 bytes, while a database specific key (the data records key) is used to encrypt the data records 42 of the database. Since the data records key is not specific to a server, it does not change when the database is moved from server to server.

Under one security model, it is assumed that if a server is provided with a server password, it can access data in a database. This is made possible in the system shown in Fig. 1 by encrypting the data records key within the DCB so that any server under which the DCB was encrypted can access that DCB and recover the data records key for further access to the data records. The server password is 'unique' to the server and allows the server to access the databases for itself. A clean way to implement this is to have the same shared key for all databases being accessed by the server. That way, the user doesn't need to know if one or multiple databases are being used. The user only needs to know that one server is being accessed and that the server password for that server can be provided by the user to access encrypted data through that server. Thus, all database pages, except the first page (the DCB), are encrypted using a single key, the data records key, which is derived from a database password provided by the user of the database. The data records key may be unique to the database. The data records key it is carried within the database's DCB, so it independent from the server that created the database. Of course, the DCB is encrypted using a server specific key (the server key), which is common to all encrypted databases created by the server. Normally this key, derived from the "secure server password", is unique to the server. This reliance of the encrypted database on the server that created and uses it minimizes the effort required to access the database by the authorized server, and prevents unauthorized access to the database by an alternate server. However, in the case of backups, access by an alternate server is desirable.

To backup an encrypted database, the original server makes a simple copy of the database, leaving the encryption in place to protect the security of the data in the database. If the backup can be restored on the same server that created it, that happens without any processing since the sever security key required to decrypt the DCB is still known and in use by that same server (or at least, by the server administrator who provides the server with the server passwords required to access the server's databases.

However, when a backup is moved to an alternative server, the change needs to be accounted for in the DCB. Since the alternative server will typically use a different server security key to access its encrypted databases, a mechanism is required to allow the free but controlled movement of such databases from one server to another. In transit, the DCB can be encrypted with either the original server key or the new server key, i.e., the reencryption with the new key can occur during export or during import. In some implementations, the DCB can be reencrypted at both ends, using an intermediate "export" key that is different from both the original key and the final key. In a variation of the basic system, server 16 includes logic to quickly determine if the server password is correct. When decryption is applied to text messages, it is usually immediately apparent that the decrypting password was not correct, because the message would appear garbled. Noticing garbled data when the data is in binary form is somewhat more difficult, especially when the server does not know the expected format for data in the data records. A server does not need to know the format of a data record in the typical application. A client requests a data record and the server provides the requested data record. In order to prevent a server from returning data records that are not properly decrypted, the DCB can include a method of data records decryption and a "magic string" (i.e., a known pattern not likely to randomly occur in encrypted data or erroneously decrypted data), along with the database key. That way, if the magic string appears in the apparently decrypted DCB, the server has a reasonable assurance that the DCB was decrypted correctly (usually because the correct server password was supplied). For multiple levels of security, the DCB might contain an indication of what level of security is being used for the data records. As for the level of security used on the DCB itself, the server could perform an iterative decryption of the DCB, such as that shown in Fig. 2, to decrypt the DCB without knowing which level of security was used. In that example, there are three levels of security that can be selected from for encryption: (1) 128-bit triple DES, (2) 56-bit DES and (3) cryptogram.

The server first reads the DCB as if it was not encrypted and examines the DCB to see if it contains the magic string. If the magic string is present, the database is not an encrypted database and the server uses the data as it reads it from the database. However, if the magic string is not present, that indicates an encrypted database. For access to an encrypted database, the server needs a server key. If it does not have the server key, it returns an error indicating that a key is required.

Preferably, the presence and content of the magic string is hidden for security reasons, the DCB containing the magic string is encrypted using the server password, at a satisfactory encryption level, possibly higher than the main body of the database. In one variation of this security system, the database body may be converted from an encrypted to an unencrypted state at the direction of the server administrator, however the magic string is retained and hidden within an encrypted DCB page. For a database that has never been encrypted the magic string is not present in the DCB, and the DCB need not be encrypted, making the entire database compatible with non-encrypting versions of the DBMS. Note that the absence of any data in the space reserved for the magic string indicates that the database has never been encrypted, as opposed to a database that was encrypted but is not currently encrypted. Assuming the server has a server key (at this point it is not known if that key is the correct key), the server decrypts the DCB using the provided server key according to a 128-bit triple DES decryption process. If the magic string is visible in the result, that is the correct decryption method and it is used for additional transactions involving that DCB (and that database, if they use the same methods). If the magic string is not visible, the server then tries to decrypt with the server key and a 56-bit DES method. Again, if the magic string is visible, that method is used. However, if the magic string is not visible, the server tries one final method, the cryptogram method. If the magic string is not visible after decrypting the DCB using the server key and the cryptogram method, the server assumes it was provided with an invalid server key and returns an error to that effect.

If the server knows in advance that the DCB and the data records are encrypted using the same level of security, the method of encryption need not be stored in the DCB. Instead, the server will note what decryption method worked on the DCB and use that method on the data records.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

Claims

WHAT IS CLAIMED IS: L A method of encrypting a database comprising the steps of: encrypting data records of the database using a data records key; recording the data records key in a data control block of the database; and encrypting the data control block with a second key.