Securing DBMS event notifications

One embodiment of the present invention provides a database server for securing database event notifications. The server includes a session key creation mechanism configured to create a session key when a client registers for an event, a storage mechanism configured to store the session key on the database server, a data accessing mechanism configured to access registration metadata to obtain the session key when the event occurs, a connection mechanism configured to establish a communication channel between the database server and the client, a mutual authenticating mechanism configured to using the session key to mutually authenticate the client and the database server during event notification, and an event notifying mechanism configured to send the event notification to the client.

BACKGROUND

The present disclosure relates to database event notifications. More specifically, the present disclosure relates to securing database event notifications using mutual authentication between database server and client.

2. Related Art

In a database, events can include changes made to database table entries and user account activities, such as creating a new user account or logging into an existing user account. A database management system (DBMS) provides infrastructure to allow a client to register for events of interest, and to allow a database server to send notifications to the client when those events occur in the database.

Once an event occurs in a database, the database server opens communication channels to clients, which may have been disconnected from the database, and sends event notifications via these communication channels. On the client side, while waiting, the client spawns a listener process to accept communication channels from the database server and to receive event notifications on these communication channels.

Currently, there is no mutual authentication between the database server that sends out event notifications and the client listener. The client is listening on an open port waiting for event notifications. Because the client does not authenticate communication channels for receiving event notifications from a database server, the client is vulnerable to buffer-overflow attacks from malicious users. Such attacks can crash the client or engage it in denial-of-service attacks, thus preventing notification delivery to legitimate registrations at the client. In addition, the client may also suffer from replay attacks. On the other hand, because the database server does not authenticate a client who is receiving event notifications, it is possible for a malicious user to pose as a legitimate client to receive unauthorized notifications.

Some database management systems, such as the Oracle relational DBMS (RDBMS), provide security options (e.g., Oracle Advanced Security Options (ASO)) to address these security concerns. However, many database client/server installations do not support ASO and still use conventional event notifications, such as Oracle Call Interface (OCI) notifications or Java Database Connectivity (JDBC) notifications. What is needed is a method that can provide an acceptable level of security for event notifications for database client/server installations that do not have these security options.

SUMMARY

One embodiment of the present invention provides a database server for securing database event notifications. The server includes a session key creation mechanism configured to create a session key when a client registers for an event. During operation, a storage mechanism stores the session key on the database server. A data accessing mechanism accesses registration metadata to obtain the session key when the event occurs. A connection mechanism establishes a communication channel between the database server and the client. A mutual authenticating mechanism uses the session key to mutually authenticate the client and the database server during event notification. Furthermore, an event notifying mechanism sends the event notification to the client.

In a variation on this embodiment, the database server includes an obfuscating mechanism configured to obfuscate the session key before storing it.

In a variation on this embodiment, the session key is stored in a system registration table.

In a variation on this embodiment, the mutual authenticating mechanism includes a first sending mechanism configured to send a first random number; a reversible hash function based on a registration ID which identifies the event registration, and a reversible hash function based on a database ID which identifies the database; and a receiving mechanism configured to receive from the client a response including an irreversible hash function based on both the session key and the first random number.

In a further variation, the response from the client further includes a second random number.

In a further variation, the mutual authenticating mechanism includes a second sending mechanism configured to send to the client a response including an irreversible hash function based on both the session key and the second random number.

One embodiment of the present invention provides a database client for securing database event notifications. The database client includes a session key receiving mechanism configured to receive a session key from a database server when the client registers at the database server for an event. During operation, a storage mechanism stores the session key on the client. A mutual authenticating mechanism uses the session key to mutually authenticate the client and database server during event notification. An event notification receiving mechanism receives the event notification from the database server.

In a variation on this embodiment, the session key is stored in an in-memory hash table on the client.

In a variation on this embodiment, the mutual authentication mechanism includes a first receiving mechanism configured to receive from the database server a first random number, a reversible hash function based on a registration ID which identifies the event registration, and a reversible hash function based on a database ID which identifies the database.

In a further variation on this embodiment, the mutual authentication mechanism includes a sending mechanism configured to send a second random number and an irreversible hash function based on both the session key and the first random number; and a second receiving mechanism configured to receive a response from the server including an irreversible hash function based on both the session key and the second random number.

DETAILED DESCRIPTION

Overview

Embodiments of the present invention provide a method for securing event notifications by mutual authentication between a database server and a database client. When a client first registers for event notification with a database server, a session key is generated and shared by both the client and server. This session key is stored at both the server and client. During subsequent event notification, the server and client use this session key to mutually authenticate each other. In this way, both the server and client can reduce the likelihood of middle-man attacks. Furthermore, the frequency and scope (e.g., per event notification, per registration, or per database) can be tailored according to different system needs and security levels. These features have not been available with existing technologies.

Computing Environment

FIG. 1illustrates a computing environment100in accordance with an embodiment of the present invention. In the example illustrated inFIG. 1, computing environment100includes clients110, network120, database130, and database server140. During operation, clients110first registers with database server140to receive notifications of certain events in database130. Such events can be any operation performed on database130. During the registration process, server140generates a session key with a respective client. This session key is then shared with that client, and subsequently used to mutually authenticate both server140and that client when an event corresponding to the registration occurs at database130.

Computing environment100can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance. Clients110can include any nodes on a network with computational capability and a mechanism for communicating across the network.

Network120can include any type of wired or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment of the present invention, network120includes the Internet.

Database130can include any type of system for storing data in non-volatile storage. This includes, but is not limited to, systems based upon magnetic, optical, and magneto-optical storage devices, as well as storage devices based on flash memory and/or battery-backed up memory.

Database server140can generally include any computational node with a mechanism for providing database service to a client.

FIG. 2presents a block diagram illustrating a database server for securing database event notification in accordance with one embodiment of the present invention. As shown inFIG. 2, a database server200includes a session-key generator202, a session-key storage mechanism204, a system registration table206, a registration-access mechanism208, a connection mechanism210, a mutual authentication mechanism212, an event notification mechanism214, and an obfuscating mechanism216. When a client registers for an event at database server200, session key generator202generates a session key. In one embodiment, the session key is an encryption and decryption key that is randomly generated to ensure the security of a communication session between a user and another computer or between two computers. Note that although conventionally a session key is a single-use symmetric key used for encrypting all messages in one communication session, embodiments of the present invention allows a session key to persist beyond the initial session and uses the session key to facilitate subsequent authentication tool between a database server and a client. Obfuscating mechanism216obfuscates the session key to prevent dictionary attack of the session key. Session key storage mechanism204then stores the obfuscated session key in system registration table206. System registration table206stores the registration information. In one embodiment, system registration table206can be the sys.reg$ table in an ORACLE® database system, which is a database table within the database system that stores system registration information.

After the registered event occurs, registration-access mechanism208accesses system registration table206to obtain the session key. Connection mechanism210then establishes a communication channel with the client. Mutual authentication mechanism212mutually authenticates database server200and the client. That is, mutual authentication mechanism212challenges the client to prove that the client is a legitimate, registered event-notification receiver, and responds to the client's challenge. Subsequent to successful mutual authentication, event notification mechanism214sends event notifications to the client.

FIG. 3presents a block diagram illustrating a database client for securing database event in accordance with one embodiment of the present invention. As shown inFIG. 3, a database client300includes a session-key receiver302, a session-key storage mechanism304, an in-memory hash table306, a listener308, a mutual authentication mechanism310, and an event notification receiving mechanism312. During event registration, session-key receiver302receives a session key from the database server. Session-key storage mechanism304stores the session key in in-memory hash table306. While waiting, database client300spawns a listener process308to accept communication channels from the database server for event notification. Mutual authentication mechanism310mutually authenticates the database server and client300. Subsequent to successful mutual authentication, event notification mechanism312receives event notifications from the database server.

Event Registration

FIG. 4presents a state diagram illustrating the process of registering an event in accordance with one embodiment of the present invention. During operation, a database client402starts a communication session with a database server400(operation404). In one embodiment, database server400includes an Oracle EMON (event monitor) server. Upon starting the session, database server400creates a session key (operation406) and shares the session key with the client (operation408). In one embodiment, the session key is created based on the session's host definition, such as the client's IP address and the time at which the session is created. Database server400then stores the session key along with other registration metadata (operation410). Such registration metadata may include subscriber name (name of the registered client), information regarding the server's callback function for notifying the client about events, identifier of the user who registered the client, and the namespace within which the event notification operates. Subsequently, client402stores the session key in an in-memory subscription hash table (operation412).

In one embodiment, database server400stores the session key in a sys.reg$ data dictionary table, which stores registration information. Since the sys.reg$ table is stored in a non-volatile storage (e.g., hard drive), The storage of the session key in the registration table ensures the session key to be available for EMON background server process through subscription library cache object for sending notifications over authenticated communication channels. More over, because registration persists across database instance restarts (i.e., the registration remains effective after the database restarts), event notifications would continue to be sent after such instance restarts, and the corresponding session keys remain available after such instance restarts. This feature allows uninterrupted event notifications without the need of re-establishing session keys after instance restarts.

Because the sys.reg$ table can be queried by database administrator (DBA) and users, in one embodiment, database server400can obfuscate the session key before storing it in the sys.reg$ table. In another embodiment, for added security, database server400stores the session key in an auxiliary hidden table. In addition, database server400ideally does not return session key to client402in plain text, because the communication channel between database server400and client402may not be encrypted. In a further embodiment, client402also obfuscates the session key before storing the session key in its in-memory subscription hash table.

Note that an OCI or JDBC client program can have multiple registrations with a database due to its multiple users/sessions. Therefore, a client listener could be listening at a given host and port (or a given location) for notifications destined to multiple registrations on one or more communication channels from one or more database servers. Due to this 1:N mapping between listener location and registrations, the database server can store the session key either in the high-level location structure, or fine-grained context structure, of the subscription KGL (Kernel Generic Library cache) object.

After storing the session key, client402begins events registration (operation414) and spawns a listener process (operation416). Client402registers with database server400for events (operation418). Within the event registration, client402specifies “where” (such as host and port information) and “how” (such as through a callback) the notifications are to be delivered. Upon receiving the registration call from client402, database server400creates an event registration (operation420) and returns a database ID (DbID) along with a registration ID (RegID) to the client (operation422). The database ID distinguishes one database from other databases with which the client is in communications. Client402stores the database ID and the registration ID in the in-memory subscription hash table along with the session key (Skey) (operation424). In one embodiment, client402can store one session key for all registrations with a respective database. As a result, database server400does not need to return a registration ID to client402because the same session key can be used for all the registered event notifications from database sever400. Correspondingly, the client side in-memory subscription hash table contains tuples of the form <DbID, RegID, Skey> if a separate session key is used for each registration, or <DbID, Skey> if the same session key is used for all registrations in a database. After the client stores the database ID and the registration ID, the session can be discontinued (operation426).

FIG. 5presents an exemplary flowchart for storing a session key at the database server in accordance with one embodiment of the present invention. During operation, the server first generates a session key and obtains the session key's length (operation502). Subsequently, the server obfuscates the session key (operation504). In one embodiment, the server can obfuscate the session key with a two-way hash function. The server then allocates a registration node in the system registration table (operation506) and stores the obfuscated session key in the system registration table (operation508).

Mutual Authentication

FIG. 6presents an exemplary state diagram illustrating the process of mutual authentication between a database server and a client in accordance with one embodiment of the present invention. When a registered event occurs in the database for a registrant (normally the first registered event after registration or instance restart, whichever is later), an event publisher600publishes the event to a background EMON602running on a database server601(operation606). Subsequently, EMON602then accesses the registration metadata through the subscription KGL object (operation608). EMON602accesses the obfuscated session key from the object, and de-obfuscates it. Note that if there is no current active communication channel between the database server601and registered client604for sending the event notification, EMON602initiates a communication channel to client604(operation610).

Subsequently, EMON602initiates the mutual authentication process with the client using a challenge-response scheme. EMON602running on database server601first sends a challenge to client604(operation612). The challenge includes a random number R1, a reversible hash of the registration ID, denoted as H1(RegID), and a reversible hash of the database ID, denoted as H1(DbID). The authentication may have different granularities. In one embodiment, a unified session key, which belongs to a registration that occurs before all other registrations, is used for all registrations at a given client location sharing one or more communication channels. As a result, the server only sends the client a random number and a reversible hash of the database ID without sending a reversible hash of the registration ID. However, sometimes it might be difficult to determine which registration occurs first, thus which session key is to be used. Because a client has to be ready to receive notifications as soon as a registration completes on the server (which may happen before the server returns the registration call to the client), and because the registration call may fail during or after its return, when a client does a number of registrations in parallel, the order of registrations seen by the client may be different from that seen by the server. To solve this conflict, in one embodiment of the present invention, all parallel-received session keys are kept by the client. During authentication, one of the session keys is negotiated between the client and sever to be the unified session key, and the remaining session keys are not used. After sending the challenge, EMON602waits for a response from client604(operation614). After a predetermined timeout period, if no response from client604is received, EMON602will not send the event notification.

Upon receiving the challenge from EMON602, client604sends a response along with a challenge back to EMON602(operation616). In order to respond, client604uses the received database ID and/or registration ID to retrieve the corresponding session key from its in-memory subscription hash table. Subsequently, client604generates an irreversible hash function using both the session key and the server-passed random number R1(or a variation of the server-passed random number to avoid man-in-the-middle type of attacks). In one embodiment, client604calculates the irreversible hash function using a secure hash algorithm, such as SHA-1. Client604sends the irreversible hash function, denoted as H2(Skey, R1+X), as a response, along with another random number R2, as a challenge, back to EMON602. X is a number pre-agreed between the server and client. In one embodiment, X is set to one.

After sending the response and the challenge, client604waits for a response from EMON602(operation618). After a predetermined timeout period, if no response from EMON602is received, client604will not complete the communication channel setup and will not receive any notification. By sending the hash function of both the session key and a variation of server-passed random number (R1+X), client604authenticates itself to EMON602running on database server601.

After receiving the response along with the challenge from client604, EMON602verifies the client response locally by generating H2(Skey, R1+X) and the corresponding value received from the client. Subsequently, EMON602sends a response back to client604(operation620). To respond to the challenge from client604, EMON602generates an irreversible hash, denoted as H2(Skey, R2+Y), using both the session key and the client-passed random number (or a variation of the client-passed random number). Y is a number pre-agreed between the server and client. In one embodiment, Y is set to one. EMON602can use the same irreversible hash function, such as SHA-1, as the one used by client604. By sending an irreversible hash function of both the session key and a variation of the client-passed random number (R2+Y), EMON602authenticates itself to client604. After completing the mutual authentication, EMON602running on database server601sends the event notification to client604(operation622).

Note that by hashing the registration ID and the database ID, the database server prevents these IDs from being obtained by spoofing malicious users. The reversible hash of the registration ID cannot be used in a replay attack by a malicious user acting a server, because the server is also required to be authenticated. In addition, irreversibly hashing the session key together with random numbers also prevents replay attacks from malicious users.

Depending on the preferred performance and required security level, the mutual authentication between the database server and the client can occur at different frequencies. For faster performance, the authentication is performed only once when setting up a communication channel for a first notification. On the other hand, the authentication can be performed once for a number of notifications in order to achieve greater security. In one embodiment, when multiple registrations are receiving notifications on the same communication channel, the mutual authentication is performed for every registration on the communication channel. In another embodiment, when multiple registrations are receiving notifications on the same communication channel, the mutual authentication is performed for the first registration on that communication channel only.

In certain scenarios, the client receiving notifications may be known and secure, or the client and the database server may reside on the same side of a firewall. Therefore, in order to achieve faster performance, the database server may choose to bypass the mutual authentication process. In one embodiment of the present invention, a switch is included in the database server and/or client to turn on and off the authentication process.

The client may want to control the authentication granularity and frequency, and to turn on and off the authentication. In one embodiment of the present invention, a user interface is provided to enable the client control. Depending on the performance requirement, a client can also choose a public authentication algorithm.

The aforementioned mutual authentication scheme implies a change in the client-server communication protocol and hence it may or may not work with older versions of client/server installations. As a result, the server and the client might need to know whether mutual authentication is available before using the scheme. In one embodiment, the server first checks for client capability and uses the mutual authentication scheme only if the client is capable of authentication. Otherwise, the server communicates with the client using the existing protocol without authentication. Similarly, the client checks server capability to decide whether or not to use authentication. Because one client may communicate with multiple database servers among which some are authentication-capable and some are not, the listener spawned by the client (that waits indefinitely for notifications) can use a different wait mechanism. Instead of waiting indefinitely, the listener can periodically check for authentication requests from authentication-capable servers.

Older versions of database server/client installation can operate seamlessly with newer-version authentication-capable ones. In one embodiment, a database server can obtain a client's authentication capability either from session context or version information passed during registration. On the other hand, a client can obtain a database server's authentication capability, and only keep session keys for and accept authenticated communication channels from authentication-capable database servers. Database servers and clients that are not authentication capable can continue to establish unauthenticated communication channels using existing protocol.