WO2001001222A1

WO2001001222A1 - Securing databases using mutual consent access

Info

Publication number: WO2001001222A1
Application number: PCT/US2000/016902
Authority: WO
Inventors: Nicholas Spicer
Original assignee: Centura Software
Priority date: 1999-06-25
Filing date: 2000-06-19
Publication date: 2001-01-04
Also published as: AU6199500A

Abstract

A method for generating a database key that is a function of a vendor secret and a data user secret, wherein the database key is difficult to generate without the vendor secret and the data user secret, and using the database key to encrypt a database.

Description

SECURING DATABASES USING MUTUAL CONSENT ACCESS

CROSS-REFERENCE TO RELATED APPLICATIONS U.S. Patent Application No. , filed on the same day as the present application and entitled "Two-Layer Encryption Of Databases" is incorporated by reference herein for all purposes.

BACKGROUND OF THE INVENTION The present invention relates to the field of database handling. More specifically, one embodiment of the invention provides a database architecture that secures a database against access by a vendor or a user without the other's consent.

In a database application sold or licensed to an end user, the creator of the database application may include some data that is proprietary to the creator but that is necessary for operation of the database application. For example, a software vendor might create a program for estimating annuity costs and sell or license the program to insurance and finance companies. In order for the program to work properly, the software vendor might need to provide actuarial tables and other data structures required b the application. Typically, the software vendor would like to limit access to that data so that the data user cannot get at the data, except as needed by the application. The insurance or finance company that is the data owner in this example would also like to prevent the software vendor from accessing the data owner's data that is added to the database.

The vendor could secure the vendor data in a separate database, but often the vendor data, or part of it, resides in the databases provided for user data, such as templates and the like.

SUMMARY OF THE INVENTION

One embodiment of the present invention provides a mechanism to secure a database from access by a vendor or a user without the other's consent. A method to effect that mechanism includes generating a database key that is a function of a vendor secret and a data user secret, wherein the database key is difficult to generate without the vendor secret and the data user secret, and using the database key to encrypt a database. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a block diagram of a database system according to one embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS Fig. 1 is a block diagram of a database system according to one embodiment of the present invention. As shown there, a computer system 10 supports an application 12, a user interface 14, a database management system (DBMS) 16 and data storage 18. DBMS 16 might be a SQLBase™ DBMS provided by Centura Software of Redwood City, California, but other DBMS's can also be used. In operation, a user provides a user key 20 to application 12. User key 20 is information that is generally only known to users that own or are authorized to access the application and its attendant data. Application 12 uses user key 20 to generate a server key 22 in some way that is known to the application but not generally known to users. This is shown as vendor secret (VS) 36. The vendor secret can be data, method steps or a combination of the two.

The data used by application 12 is encrypted as database 28, shown comprising a database control block 30 and a collection of data records 32. The data records 32 are encrypted using a data records key 34 and data records key 34 is stored in database control block 30. Database control block 30 is encrypted using server key 22 and database control block 30 is required by DBMS 16 to access database 28. Because of that requirement, DBMS 16 requires server key 22 before it can access database 28.

In a typical application, a vendor supplies application 12 and database 28 without user data. The database schema and seed data of database 28 are created as a template into which specific data will be placed after installation by the user for the purposes of application 12. After database 28 is populated with user data, database 28 will contain private information of the vendor and private information owned by the user. Neither have rights to both sets of data, yet the application requires access to all the data to perform.

Typically, the vendor will ship the database encrypted a default server key 54 and provide a default user password 50 to the user. The vendor generates default server key 54 using a key generator 52 that generates keys from passwords, using a process equivalent to that of application 12, such as using vendor secret 36. The vendor can start with an unencrypted database and encrypt it with default server key 54 before shipping. If default server key 54 is generated from default user password 50 in such a manner, the user can use default user password 50 until the user changes the user password for database 28. Note that the user is not provided with default server key 54, so a user is prevented from accessing database 28 through DBMS 16 directly without going through application 12.

When the system shown in Fig. 1 is used, application 12 can access data in database 28, but users cannot access the data outside application 12 and the vendor cannot get access to the user data. The vendor preferably programs application 12 so that the user cannot use application 12 to access the vendor's protected data, because the vendor is implicitly granting the user access to any vendor data the user can access through the vendor's application.

Fig. 1 shows database 28 with a DCB 30 including data records key 34 and data records. The data records are encrypted with data records key 34 and DCB 30 is encrypted with server key 22. Any suitable encryption scheme can be used, such as triple-DES. The structure for database 28 could be other than the structure shown in Fig. 1. For example, database 28 might be encrypted all with one key. One advantage of encrypting only the DCB with the server key is that the server key can be changed , without having to reencrypt the entire database. Typically, the channel between the application and the DBMS is an encrypted channel, so a user cannot easily listen in and steal the server key. 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:

1. A method of securing a database comprising the steps of: generating a database key that is a function of a vendor secret and a data user secret, wherein the database key is difficult to generate without the vendor secret and the data user secret; and using the database key to encrypt the database.

2. The method of claim 1, wherein the vendor secret is program code for processing the data user secret to form the database key.

3. The method of claim 1 , wherein the data user secret is a data user key.

4. The method of claim 1, wherein the step of using the database key to encrypt the database comprises the steps of: encrypting data records in the database with a data records key; recording the data records key in a database control block; and encrypting the database control block with the database key.