Asymmetric system and method for tamper-proof storage of an audit trial for a database

[0001] The application is a Continuation-in-Part application of the U.S. patent application Ser. No. 09/634,445, which was filed on Aug. 8, 2000, now U.S. Pat. No. 6,968,456 entitled “Method and System for Providing a Tamper-Proof Storage in an Audit Trail in a Database.”

[0002] The present invention relates generally to computer software, and more particularly, to a system and method for storing data in a tamper proof storage.

[0003] In today's computer network environment, large volumes of data are customarily stored and used by various software applications. Data management has become an essential task for many data intensive industries. A smooth business operation depends both on the efficiency and security of the use of the stored data. From the perspective of data management, a database administrator (DBA) is powerful in that he usually has full access to the entire database and all contents stored therein. He can read, write and modify any data stored in the database. In a normal situation, the DBA is endowed with the highest level of trust because of his enormous responsibility. In certain cases, it is desirable to store data in a database in a secure way such that even a privileged user like the DBA should not be able to modify records without detection. For example, it is very important to protect a monotonically increased audit trail which records actions taken by a user along with his identity against modifications. No one should be able to modify this trail, thus an independent auditor can trace any user's, even the DBA's, actions relating to the database, whereby the integrity and the security of the database are greatly enhanced.

[0004] The normal practice consists of reading audit trail data in a database directly through SQL, JDBC or any such standard client program. Several conventional methods are used for protecting the integrity of the audit trail in a database system. For example, the entire audit trail can be encrypted. Although this encryption prevents access to the trail by the DBA, it does not prevent him from deleting certain records without being detected. Also it hinders the normal practice of reading the trail by users of the database.

[0005] As an alternative solution, the audit trail can be validated by a signing process. The signing process corresponds to a digital signature operation which is well known in the industry. This signing process for generating a signature involves taking a message of any length, forming an “imprint” of the message to a fixed length by hashing, and mathematically transforming the hash using cryptographic techniques. While the signature can be generated only by the signer, any other user can verify the generated signature. If a trail for which the signature is attached has been tampered with, the verifier cannot successfully validate the digital signature. The signing process is directed to the entire trail, not a specific record in it. Under a typical scenario, after all the existing records have been collated, a signature is then generated for the entire trail, and the resulting signature is put in a secure place. Therefore, every time a new record is added to the database, the audit trail is signed again. This method has a heavy processing and computational overhead as the entire audit trail needs to be accessed and signed every time a record is added.

[0006] In another alternative solution, the records can be validated by requiring a signature of each record. This method validates the individual records but still fails to prevent the DBA from deleting records without detection.

[0007] The process of auditing a database audit trail is expected to conform to “four eyes principle.” This means that there can be two or more auditors who separately and independently track a database audit trail. The audit trail starts with the joint participation of all the auditors. The auditors are supposed to maintain a “non-trusting” attitude towards each other and strictly track the audit trail for database integrity. All solutions to tamper-proof storage discussed in the above paragraphs are presented in the single auditor framework and hence cannot be applicable to auditing process that requires “four eyes principle.”

[0008] What is needed is an efficient method and system for supporting a secure database system so that any modifications of the audit trail in a database system by any user, including the privileged user like the DBA, would be detectable. The proposed method and system should also support “four eyes principle” for auditing.

[0009] A method and system is provided for a tamper-proof storage of an audit trail in a database having one or more records. Since the integrity of the audit trail may be vulnerable to actions taken by an access-privileged user such as a database administrator, a mechanism is provided for authorized persons such as one or more auditors to efficiently detect any changes made by the user to the records in the audit trail.

[0010] In one example of the present invention, an audit trail has one or more records, each record having a corresponding authentication token and a validation token. If there are two or more auditors, then the trail record will have separate validation tokens for each of the auditors. The database has a writing machine (writer) which is not under the control of the access-privileged users or the auditors.

[0011] The audit trail is initiated by generating an initial value of the authentication token and an initial value of the validation token based on a first encryption key generated by the writer (writer public key) and a second encryption key generated by the auditor (auditor public key). In a case of two or more auditors, separate validation tokens are generated for each auditor based on his public key. Complimentary to the writer public key and the auditor public key, a third encryption key (writer private key) related to the first encryption key and a fourth encryption key (auditor private key) related to the second encryption key are also created. While integrating the values of the validation token(s) and the writer public key into each corresponding record of the audit trail, the values of the authentication token, and the writer public key are constantly updated for the next record. The writer has an access to the auditor public key, and the auditor has an access to the writer public key. However, only the writer has an access to the writer private key, and only the auditor has an access to the auditor private key. Each auditor has the ability to compute the values of the validation token for the records to verify against the integrated values of the validation token in order to detect a tampering of the audit trail by any access-privileged user.

[0012] Various benefits are achieved over conventional approaches. For instance, the security of the entire trail in a database is strengthened, while normal database queries are not hindered. Further, any actions taken against the records in the trail can be detected without involving a computationally expensive process. Additionally the auditing process satisfies the requirements of a “four eyes principle.”

[0015] While it is not an objective of the present invention to prevent the database administrator (DBA) from accessing the database under his control or hinder his daily work in any way, the present invention intends to provide a security system for improving the reliability of the audit trail in a database by assuring that any modification or deletion of the records in the trail can be detected by an independent auditor.

[0016] Referring now to FIG. 1, a simplified tamper proof database system (DB) 10 is shown. The DB 10 contains a main database operations manager (DBOM) 12 and database storage 14. The Secure Store (SS) 22 stores secured information and performs access control based on a user's identity. The SS 22 is essentially a database containing information about network users, network devices, and other resources of a network. It helps to manage users, the network resources, and information on the network by providing an administrator/operation manager which has a precise view of network resources and services at any instant of the network operation. In some examples of the present invention, the SS 22 can be a software module, a hardware component, or a combination of both software and hardware components. The SS 22 is also a secured information storage for storing sensitive information in a confidential form. The SS 22 stores information for all entities in a computer network environment, the entities being users, computer hardware devices, or software modules, etc. Every entity is entitled to an exclusive access to a partitioned area in the SS 22. For example, an auditor 20 is only given access to his related part of the SS 22 if he is authenticated by password or through other authentication methods. The SS 22 then provides information, applications, and communications accesses to the user after a successful authentication process. Connected to or contained in the DBOM 12 is a software engine or server that writes data to the database storage 14 or the SS 22. It is heretofore referred to as a writing machine or a writer 16. The writer 16 is decoupled from the DB 10 and is not under the control of the DBA. The entire DB 10 interacts with users such as a user 18 and the auditor 20 based on predetermined access conditions. A typical database system such as one provided by Oracle Corporation can be used as the DB 10 in the present invention. In some cases, the SS 22 can be a Novell Directory Services system (NDS) or the Secret Store System in NDS. The writer 16 can be a network loadable module (NLM) running on a software platform such as Novell's NetWare. The network loadable modules are program modules that perform specific tasks. For example, specific program modules can be written to implement the functionality of a writer.

[0017] In order to implement various examples of the present invention, one common process involved is an encryption process. This process is to encrypt a plain readable message through mathematical transformation so that it is no longer readily decipherable. The transformed message after the encryption process is usually referred to as a ciphered message. The receiver performs reverse transformation on the ciphered message to obtain the original plain message. The forward and reverse transformation encryption transformations require a shared secret key. The sharing of a secret key is facilitated using a public private key pair. The sender encrypts the shared secret key using the receiver's public key and sends the ciphered message to the receiver. The receiver decrypts the shared secret key using his private key. Only the intended receiver can decrypt properly and get the shared secret key, as he is the only one with the knowledge of his private key. Since the sender and the receiver use different keys for encryption and decryption of the same data, this scheme is also called as an asymmetric key scheme.

[0018] The writer and the auditor can use a public key cryptographic technique, for example, Diffie-Hellman key exchange technique, to arrive at a shared key which can then be used to compute authentication and validation tokens. In a Diffie-Hellman (D-H) scheme, each of the participants generates a private and public key pair. Only the public key of the public-private key pair is made public. Though the private and public key are mathematically related, obtaining the private key from the knowledge of the corresponding public key is computationally infeasible. This problem is well known as the discrete logarithm problem. By choosing the length of the key pair appropriately, efforts to break the discrete logarithm problem can be made as high as desired. The participants involved in a D-H scheme exchange their public keys. Then they perform exponentiation of the obtained public key which could be used further for encryption purposes. In order to facilitate proper mathematical operations, an appropriate (large enough so that discrete log problem is infeasible) prime number field is chosen. The modulus of the number field is denoted by P and the operations supported are modular additional and modular multiplication. The number field has P-1 nonzero elements and α is denoted as the generating base which generates all the nonzero elements of the number field as 1, α¹(mod P), α²(mod P, . . . ,α^P-1 (mod P). If a private key is chosen as W, then the corresponding public key is α^W(mod P). For the sake of notational convenience, the public key is written as α^W. All computations are assumed to be performed modulo P unless otherwise specified.

[0019] Hence, the security of the shared secret key exchange algorithm is primarily measured by the design of the public and private keys, and most likely in the digit length of these keys. By increasing the key length, the difficulty level to break the encryption algorithm is increased, and the ciphered message is more secure in transmission.

[0020] Another common process used by various examples of the present invention is called a hashing process (or a “hash” in short). A hash is a process of transforming a message of any length into an output message with a fixed length. The output message is called a digest. By definition, a hashing process maps a message of arbitrary length into a digest of a predetermined length. A secure hashing algorithm is designed so that it is computationally unfeasible to determine an input message from its corresponding output digests. Although there are a significant number of hashing algorithms known in the art, some well-known hashing algorithms are MD4, MD5, and Secure Hashing Algorithm (SHA).

[0021] For the purpose of explaining examples of the present invention, some other technical terms are defined summarily below:

• • [0022] A_i—i_th Authentication token.
  • [0023] R_i—i_th Record.
  • [0024] D_i—String formed by concatenating fields of the i_th Record or referred to as the data section of the i_th Record.
  • [0025] V_i—Auditor Validation token for the i_th Record.
  • [0026] H(x)—A secure hash of the string x.
  • [0027] E_k{x}—Encrypt x with key k.
  • [0028] X+Y—Concatenation of strings X and Y.
  • [0029] P—Prime Number for Exponentiation Operation.
  • [0030] α—The generator of Prime Number Field.
  • [0031] AUD—auditor private key
  • [0032] α^AUD(mod P)—Auditor Public Key.
  • [0033] Wi—i-th writer private key
  • [0034] α^Wi i-th writer public key

[0035] In one example of the present invention, an audit trail is carefully created and maintained. In essence, the audit trail is a database system log used for security purposes. The audit trail is normally used for keeping track of operations applied to the database system in general, along with user identities. Since a user is granted access to the database after an authentication process, the identity of the user is known to the database, the audit trail thus can record “who has done what” to the database.

[0036] The audit trail also includes values of a validation token relying on which any tampering of the audit trail may be detected. In general, a validation token is a field in a record of the audit trail. When an original record is initially stored to create the audit trail, it is written along with an initial value of the validation token. As it will be discussed later in more detail, in one example of the present invention, a mathematical representation for an algorithm to generate the validation token can be represented by the following equations:
V_i=H(Vi₋₁+E_Ai{D_i}),

• • [0037] wherein A_i is referred to as a value of an authentication token. Hence, the key to the encryption process for generating a validation token is its related authentication token. A series of authentication token values can be generated by employing an encryption key exchange technique between the writer and an auditor. For instance, for the i^th record (e.g., R_i), the writer generates a writer private key called Wi, computes and stores a writer public key α^Wi. The auditor also generates an auditor private key AUD and an auditor public key α^AUD. After the auditor sends the auditor public key to the writer and the writer performs an exponentiation with α^AUD as the base and the writer private key Wi as the exponent. This operation is represented as
    Ti=(α^AUD*^{Wi mod P-1})(mod P)
    where P is a prime number, (mod P) denotes modulo P operation and Ti is the intermediate result. The writer then computes the corresponding authentication token according to the following process formula:
    A_i=H(Ti(mod P))
    where H denotes a one-way hash function. Using this authentication token to processes the data D_i in accordance with the method explained above, the validation token V_i is then generated. It is clear that the computation of i^th validation token V_i by the writer requires, among others, the knowledge of writer private key Wi and auditor public key α^AUD.

[0038] With the validation tokens created for the audit trail of the database, both V_i and D_i are stored in the DB 10 as part of R_i.

[0039] Table 1 below shows different sections/fields of the database according to one example of the present invention.

[0040]

	TABLE 1
			Validation	Validation
	Data Sector for	Writer-	Token for	Token for
	the Record	Public Key	Auditor A	Auditor B
	D0	αW0	V0	U0
	D1	αW1	V1	U1
	.	.	.	.
	.	.	.	.
	.	.	.	.
	Dn	αWn	Vn	Un

[0041] There are generally three major sections, the section labeled as Data Sector of the Record contains the actual database record field, the Writer Public Key section includes a writer public key computed by the writer for the corresponding records, and the Validation Token section shows the validation token values written by the writer and verifiable by the auditors such as Auditor A and B.

[0042] To start an auditing process, an auditor trail needs to be initialized. According to one example the present invention, both the writer and the auditors are required to participate in the process. For starting the audit trail, the writer generates a first writer private key W₀ and the corresponding writer public key α^W0, and transmits α^W0 to all the auditors. Each auditor also generates his private key AUDn and the corresponding public key α^AUDn. The auditor sends his respective auditor public key to the writer and the other auditors. The auditors together generate a common initialization key, α^INIT-AUD-COM and ID_aud, the common name or identification for the audit trail. The common initialization key can be computed either using Group Diffie-Hellman techniques or having each auditor send a pseudo random number (PRN) to other auditors using public key encryption and the common key is generated by combining the PRNs of all the auditors. Each auditor computes a temporary parameter X by concatenating an audit trail identity ID_aud, a writer public key α^W0, the common initialization key α^INIT-AUD-COM and the auditor's public key α^AUDn or mathematically:
X=ID_aud+α^W0+α^AUDn+α^INIT-AUD-COM
if there are more than one auditor, then all auditor public keys are appended in the above formula to appear as:
X=ID_aud+α^W0+α^{INIT-AUD-COM1}+α^AUD1+ . . . +α^AUDn.

[0043] With the value X, the auditor with the public key α^AUDi then forms D₀ by running a hash function over X (i.e., D₀=Hash (X)). Thereafter, the initial value of the authentication token is created as A₀=H(α^AUDi*^W0). With the initial value of the authentication token A₀ and D₀, the initial value of the validation token can be generated as:
V₀=H(A₀+E_A0{D₀}).

[0044] The first record R₀ then stores α^W0 and V₀ as shown in Table 1. The auditor private key AUDi, the ID_aud, α^INIT-AUD-COM, and D₀ are further stored in the designated SS 22 for the auditor. For audit purposes, there are two designated fields added to the Database. One for storing the writer public key α^Wi, and the other for holding the validation token value V_i. If there is another auditor, say B, the computational steps shown above are repeated with his audit public key. There will be one more field in the database to hold the validation token U_i for the auditor B.

[0045] When writing more entries to the audit trail, the writer private keys and validation token values are generated step by step in a “chaining” fashion. First, the values of α^Wi (mod P) and α^AUDi*^Wi (mod P) are calculated by raising α and α^AUDi to the exponent Wi, so that the authentication token value for a record can be computed as:
A_i=H(α^AUDi*^{Wi (mod P-1)} (mod P)).

[0046] With the authentication token A_i in hand, the validation token is computed as:
V_i=H (V_i−1+E_Ai{D_i})

• • [0047] wherein A_i is the encryption key for i-th auditor. If there are “n” auditors, the encryption keys are respectively A₁, A₂, . . . A_n. Finally, the writer private key is updated as:
    W_i+1=H(W_i+A₁+A₂+ . . . +A_n).

[0048] The authentication keys A_I's are immediately deleted after their usage in generating the new writer private key W_i+1. The computed α^Wi and V_i are stored as part of the record R_i of the database. W_i+1 is stored in the designated SS 22 for the writer to irreversibly replace the previous value W_i. For the writer private keys, only the writer has a full access (e.g., read and write rights).

[0049] For a validation process, the verification of validation token requires the knowledge of both the auditor private key and the writer public key α^Wi. The auditor private key and D₀ are extracted from the SS 22 of the auditor using his own access privileges. The audit trail is then validated from the first record downwards. For every record, both the authentication token and the validation token values are computed using the algorithm described above and the computed validation token is compared with the validation token stored in the audit trail. Any mismatch between them indicates a tampering of the trail.

[0050] As the writer and the auditor use asymmetric key based computations to perform, respectively, writing and validating operations, the audit trail thus implemented is referred to as an asymmetric audit trail.

[0051] The audit trail thus created is tamper-proof. An attacker would have to solve discrete logarithm problem to know the writer private keys from the writer public keys. Further, the auditor's public key is stored in writer's SS, which is secure from unauthorized accesses. The validation token value computation requires the previous validation token as a parameter and hence a chaining effect in terms of generating the validation token values (or a “hash chaining effect”) is ensured.

[0052] As it is known, an audit trail can usually be tampered with in five different ways:

• • [0053] 1. deletion of the whole audit trail;
  • [0054] 2. deletion of N records in the middle of the audit trail;
  • [0055] 3. deletion of N records from the end of the audit trail;
  • [0056] 4. addition of invalid records to the audit trail; or
  • [0057] 5. modification of one or more records in the audit trail.

[0058] The present invention can successfully and efficiently deal with all the above-listed possible ways of tampering. For example, since the data for the first record is stored in the Secure Store, and the DBA doesn't have access to it, therefore he can not replace the whole audit trail with an invalid one without being detected.

[0059] Assuming for the purpose of illustration that the DBA deletes N records R_i+1 to R_i+N, thus the last validatable record is record R_i. The next record should have authentication token and validation token calculated as follows according to one example of the present invention:
Validation Token=V_i+1=H (V_i+E_Ai+1{D_i+1}})
However, the next validation token found in the SS 22 is not V_i+1, but V_i+N+1 originally for record R_i+N+1, where
V=H (V_i+N−1+E_Ai+N−1{D_i+N−1})
Assuming the cryptography technology used in the encryption process is strong enough, (e.g., if a hash function having good security property is chosen, the probability of V being the same as V_i+1 is negligible), V_i+N+1 should be different from V_i+1 and a mismatch should almost always be detected.

[0060] Assuming that the DBA deletes N records from the end of the trail (e.g., from R_i−N to R_i wherein R_i being the last record listed in the audit trail). This action, whether authorized or not, can be detected. The validation token generated at the end of the trail is now:
V_i−N=H(V_i−N−1+E_Ai−N−1{D_i−N−1}).
However the token in the SS 22 is
V_i=H (V_i−1+E_Ai{D_i})
It is highly probable that these two validation tokens will differ which indicates that a modification of the trail has happened.

[0061] Moreover, it is desirable to detect any addition of the records to the audit trail by the DBA. For example, since the validation token for a record R_i is generated in one example of the present invention by the following mechanism:
V_i=H (V_i−1+E_Ai{D_i})
and as the DBA doesn't have access to A_i he cannot generate a valid validation token for the new record added by him. Any additions can be detected immediately.

[0062] Similarly, for modification of the record listed in the trail, since the DBA doesn't have access to any authentication token, he cannot generate a valid validation token for a record modified by him. Consequently, any modification can also be detected.

[0063] In the above-described examples of the present invention, it is assumed that the writer is a secure writing machine which has a secure storage not accessible by any user other than the auditor who may have a reading access. At a very minimum, even when an event happens that breaks the security, it is guaranteed that all records written before the event will be protected from tampering. This is because the writer private key for earlier records are not available to the attacker and therefore validation tokens for them cannot be generated without solving discrete logarithm problem.

[0064] It will also be understood by those having skill in the art that one or more (including all) of the elements/steps of the present invention may be implemented using software executed on a general purpose computer system or networked computer systems, using special purpose hardware-based computer systems, or using combinations of special purpose hardware and software. Referring now to FIG. 2, a typical computer system 100 includes a two-dimensional graphical display (also referred to as a “screen”) 102 and a central processing unit 104. The central processing unit 104 contains a microprocessor and random access memory for storing programs. A disk drive 106 for loading programs may also be provided. A keyboard 108 having a plurality of keys thereon is connected to the central processing unit 104, and a pointing device such as a mouse 110 is also connected to the central processing unit 104.

[0065] The present invention, as described above, provides an improved method for providing a tamper-proof storage of an audit trail in a database. Various benefits are achieved over conventional approaches. For instance, the security of the entire database is strengthened, while normal database queries are not hindered. Further, any actions taken against the records in the audit trail can be detected without involving a computationally expensive process. It also accommodates the need to implement the “four eyes principle.”

[0066] The above disclosure provides many different embodiments, or examples, for implementing different features of the invention. Specific examples of means, and processes are described to help clarify the invention. These are, of course, merely examples and are not intended to limit the invention from that described in the claims. For example, various acceptable encryption algorithms can be conceivably used in conjunction with various examples of the present invention. Similarly, hashing algorithms can also be varied by one skilled in the art.

[0067] While the invention has been particularly shown and described with reference to the preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention, as set forth in the following claims.