WO2005067394A2 - Enhancing security of odbc/oledb/jdbc driver interface - Google Patents

Abstract

The present invention relates generally to the field of ODBC/OLEDB/JDBC compliant database clients. More particularly the present invention relates to enhancing security for database clients over various connection method topologies and enhancing the same for extending the current features of the ODBC/OLEDB/JDBC drivers over various protocol specific server requirements in terms of data security and connectivity.

Description

TITLE OF INVENTION

Enhancing security of ODBC / OLEDB / JDBC Driver interface

BACKGROUND OF THE INVENTION

For the efficient functioning of any organization, databases are used which provides for optimized data handling including storage, search and retrieval In the early days of databases, developers needed a thorough knowledge only of the database product they were using as originally the only way to retrieve data stored in a database was by executing one or more custom programs written in a high-level programming language There was no standardization of data access mechanism across development tools hence every developer created his own data access interface The problem with such an approach was that for the user to access the data the services of a knowledgeable programmer was required Besides these and other database products and technologies have advanced quickly including the relational databases and the non-relational databases Further the data-access technologies have had to keep up with rapid technology changes and with the advent of client/server and multi-tier application architectures, developers must now understand a variety of data-access technologies Most developers have spent years learning technologies such as Open Database Connectivity (ODBC), Data Access Objects (DAO), Remote Data Objects (RDO), Object Linking Embedded (OLE DB), ActiveX Data Objects (ADO) and (ADO NET) the latest Application Programming Interface (APIs) from Microsoft Corporation¹ Similarly the idea behind Java Database connectivity (JDBC) from Sun Microsystems is similar to Microsoft's ODBC which are both an API for connecting the Database to retrieve and/or store data, based on the X/Open standard for database connectivity

In most .of the database access technologies the security is dependent on the Operating system (OS) user authentication (trusted connections created by the network administrator) or the native database security and user schemas which maybe independent from the OS user details created and managed by the database administrator (DBA) Although every system is at risk to some degree, DBAs and developers who work with the Databases Server can improve their systems' security by understanding the ramifications of the authentication mode they choose For example the SQL Server 2000 and 7 0 provide two authentication modes SQL Server and Windows authentication (also called mixed authentication) and Windows integrated authentication Mixed authentication lets applications connect to SQL Server by using accounts and passwords stored in SQL Server tables or in a Windows domain or local machine Although mixed authentication is easy to use, it lacks account-lockout capabilities and can expose your systems to attack through SQL Server's vulnerable and often mismanaged system administrators (sa) account Windows authentication, which requires one to use a Windows account for all database connectivity, provides a mechanism for account lockout and eliminates the security risks associated with the sa account

Generally there are two popular methods in which the client applications connect to the database i e using a DSN or via a DSN less connection This is a part from the native data access interface provided by the database vendor The arguments of the DSN (data source name) string are the machine or server name, database name user identity and password etc The biggest flaw in the adapted standard is the compromise of security for the most important information gateway to database i e the DSN connection itself The lapse of the s cunty begins with the parameters itself as the user name and the password specified is generally simple text rather than an encrypted string These parameters are supposed to be specified by the database developer when establishing connection with the database server Since major Database vendors do not accept encrypted string even the most secure database falls prey to basic ODBC spying or tracing tools and the entire data is exposed to unauthorized access Microsoft operating systems since the first inception of ODBC standard provide basic tracing tools as part of the ODBC manager in the control panel This feature permits a log or trace file to be generated as part of driver monitoring and debugging and cannot be deactivated or disabled Hence any applications, which use a DSN from control panel falls prey to these tracing techniques

Even if applications connecting to the database server via a DSN-less connection do not and cannot use encrypted string's hence any network packet sniffers can track the database connection access parameters Hence there exists a need, which secures this database connectivity mechanism without disturbing the existing client applications built on these interfacing standards Further since various networking protocols evolved over a period of time the legacy ODBC standards could not scale to various networking protocol requirements over various devices and their embedded databases implemented Any server - client configuration settings chooses protocols during the process of deployment Throughout the past computing history a lot of network technologies have evolved and DSN restrictions in parameters has not kept pace with various network evolutions Each of these newer network or connectivity technologies demanded more details than just a server name and hence a need arose to extend these parameters for more security and better connectivity

The other problem is that the current drivers do not support dialing to a Remote Access Service (RAS) server directly The driver expects an already established connection to ride with the database connection (which is generally done through a dial up networking interface)

Hence the need arose for the translation of DSN parameters, which can dialup the remote server rather than depending on other dialup networking software to manage remote PPP to SLIP connectivity Further what was needed was the driver interface along with server that can verify the authenticity of remote clients by validating the callback telephone Ids

Hence in the proposed solution the ODBC arguments are extended with backward compatibility to extend and secure existing functionality The patent Universal Connection gateway for Functionally Different Servers' is incorporated herein which describes the server side changes required to implement these ODBC extensions

SUMMARY OF THE INVENTION To achieve the foregoing objects and in accordance with the purpose of the invention as broadly described herein the present invention provides a system and method to enhances security The preferred embodiment of the present invention also extends to various the Server networking requirements. In an alternative embodiment, the present invention can be used as a software licensing and monitoring tools to extend ODBC features to monitor software license management without any hardware locks and dongles such as CPUID, etc. It serves to secure developer effort of design and prevents unauthorized data access for the end user.

The present invention enables carrying out of the said enhanced security using the modified connection string. In the preferred embodiment of the present invention the DSN parameters are parsed during the first connection attempt itself for analysis of extended arguments. Upon find these extensions the licensing policy of the server as per the users purchase schema dictates the security levels, encryption algorithm, authentication keys, encryption key size etc.

In the preferred embodiment the Server name is resolved from the DSN string. The control packet is transmitted to authenticate the existence of the Server and accordingly fetches license details. The client uses the licensing parameters to validate the user identity, password, encryption string. After the validation of the Client Access License (CAL) as per the purchase schemas is carried out, the SQLConnect (or equivalent) is fired and proceeded.

In an alternative embodiment, the present invention also provides a system and method for the driver supports dialing from a RAS interface.

The entire design is based on state machines and modules comprising of various events communication via messages that is it is event driven using Finite State Machine (FSM) concept, the functionality is broken down into a series of events scheduled by kernel.

BRIEF DESCRIPTION OF THE DRAWINGS The various objects and advantages of the present invention will become apparent to those of ordinary skill in the relevant art after reviewing the following detailed description and accompanying drawings, wherein: Fig 1 is a diagram depicting the Basic Database Driver Mechanism

Fig 2 is a flow diagram illustrating the Development phase on the client

Fig 3 is a flow diagram illustrating the Development phase on the Serverside

Fig 4 is a flow diagram illustrating the Execution phase on the Serverside

Fig 5 is an example illustrating the working of the preferred embodiment of the current invention

Fig 6 illustrates the working / configuration of the invention during setup using the screen shot

Fig 7 illustrates the working / configuration of the invention during setup using the screen shot

Fig 8 illustrates the working / configuration of the invention during setup using the screen shot

Fig 9 illustrates the working / configuration of the invention during setup using the screen shot

Fig 10 illustrates the working / configuration of the invention during setup using the screen shot

Fig 11 illustrates the working / configuration of the invention during setup using the screen shot

Fig 12 illustrates the working / configuration of the invention during setup using the screen shot

DETAILED DESCRIPTION OF THE INVENTION

While the present invention is susceptible to embodiment in various forms there is shown in the drawings and will hereinafter be described a presently preferred embodiment with the understanding that the present disclosure is to be considered an exemplification of the invention and is not intended to limit the invention to the specific embodiment illustrated

In the present disclosure, the words "a" or "an" are to be taken to include both the singular and the plural Conversely, any reference to plural items shall, where appropriate, include the singular

Referring now to the drawing particularly in Fig 1 shows the Basic Database Driver mechanism including the Database client 100 and the Database Server 105 The Client front-end application talks to either the ODBC / OLEDB / JDBC layer This ODBC / OLEDB / JDBC layer 115 communicates with the Driver Manager 120 This Driver Manager 120 communicates with the Desktop Operating System 125 This Desktop Operating System 125 uses the Network Hardware and the Network Transport Layer 130 to communicate to the Database Server 105 The Multiuser Operating System 135 inter communicates with the Database Server 140

The current DSN information consists of parameters such as the Server name, Provider, User Identity and Password etc The current application proposes enhancements in these parameters to accommodate more network protocol specific and security parameters so that the developer is assured of his application design security and the end user of his data generated by the application business logic Since any existing RDBMS parses these parameters from drivers and get the needful information any additional parameter stated does not crash or generate application errors

The current application proposes an argument encrypted (basically an acronym like User Identity i e UID for encrypt) which by default will be assumed disabled but the application developer can use encrypted arguments and flag this option as true

The DSN parameters are passed as CSV (comma separated values) arguments during first connection attempt For example the current standard DSN looks like this. "ServerName= ,Provιder= ,UID= ,PWD= .kjsdhfkjsdhfkjsdhkjf

The proposed DSN looks like "SERVER=XYZ, DBNAME=ohf, UID=@#$%^Λ&'*@, PWD=<>©(%$%^Λ$, ENC=1"

In the system of the current scenario SQLConnect is fired, and the connection string is unencrypted In the proposed implementation, the client and server communication depends on the license file residing on the server and configured as per user purchase licensing policy This files dictates the security level, default encryption algorithm, authentication key(s), encryption size (64,128, 1024 etc)

We elaborate the usage and enhancements in two phases 1 ) When the developer is developing the application 2) When the end user is executing the developed application

The following flowchart depicts the above-mentioned process and shows the server and client side logic flow during the development and execution phases

Fig 2 is a flowchart depicting the Development phase on the Client

The isolation of the server name from the specified arguments 200 is carried out After the Server Name is isolated 200, the system proceeds to prepare control packet with the client hardware information 205 (typically Ethernet address, hard disk serial number or CPUID whichever is supported and required by the server later on) Further after the control packet is prepared 205 the database configuration setting (created during deployment phase of the product during client installation of the database product) is read and the configured protocols are used to establish a server connection 210 Thereafter the control packet is transmitted to get security details 215 and the system awaits server acknowledgement 220 As soon as a response is acknowledged 220, the received packet is decrypted as per the client hardware information 225

In the event, response from the server is not obtained in a predefined time, the system checks for connection timeout 230 In the event the Connection timeout 230 has not expired then the system continues to wait for the timeout to occur 240 In the event the timeout has occurred 230 then triggers an error of server unavailability upon timeout expiry 235, else upon receipt of data packet, data is decrypted as per client hardware information 225, the system proceeds to acknowledge encryption algorithm and algorithm key(s) 245 Further acknowledging the encryption algorithm and algorithm key(s) 245 proceed to use the algorithm to encrypt the User Identity (UID) and password (PWD) 250 After using the algorithm to crypt the UID and PWD 250, the developer can proceed to use these encrypted keys as DSN arguments 255

Fig 3 is a flow diagram depicting the Server Side flow during the application development phase

After the Server gets the client request for security details 300, it proceeds to analyze the request packet details and use specific client hardware information as encryption key 310 Further the system proceeds to read the Server licensing information and configured security policy 320 Thereafter the security details are transmitted in encrypted packets 330 and further the system waits for client acknowledgement 340

The use of the client hardware information as keys for encryption guarantees that the same request by various clients has various encrypted data packets and delays any anti debugging activities using packet sniffers

Fig 4 is a flow diagram depicting the Server-side flow during the application execution The isolation of the arguments from the DSN parameters as specified in "SQLConnect" command in ODBC (or similar corresponding first connection technologies is adopted by the OLEDB or JDBC) is carried out 400. After the isolation of the arguments 400, the systems checks whether the encryption tag is a part of the DSN parameters 405 In the event that the encryption tag is not part of the DSN parameter 405, the system proceeds with the normal connection process flow 410. Further the connection is successful 415 is reported upon successful parameter authentication.

In case of absence of the encryption tag in the part of the DSN parameter 405, the verification of the encryption levels and the standards specified is carried out 420 After this verification 420, the system uses the server configured licensing and security policy to decrypt UID and PWD details 425. After decryption 425, the validity of these UID and PWD is checked 430 against the database schema details and any unsuccessful authentication triggers connection failure 435.

The Fig 5 is an example illustrating the working of the preferred embodiment of the current invention The Server 1 and the numerous applications residing on these different clients communicate using various communication mechanisms As shown in the figure various client applications such as Application 1 510 uses ODBC 520 as the connection mechanism to connect to the Server 1 500 using the driver of this invention Further as also depicted in the diagram Application 2 530 connects using the OLEDB 540 mechanism to connect and communicate with the Server 1 500 Also as shown in figure the Application 3 550 connects using the JDBC 560 mechanism to connect to the Server 1 500 The Server NLS (National Language Support) settings such as Date, Time, and Currency etc can all be synchronized as per the client needs without resetting the Server or the client. The Server responds as per the requesting clients format and data pattern

For example consider the different NLS settings for the client and the server Therefore the formats of the dates, currency etc on the client and the server would be different and non-compatible and hence in normal circumstances can lead to errors both while interpreting the client request on the server end ana also while analyzing the server response at the client end. Using the preferred embodiment of the current invention this problem can be solved.

The Fig 6 is an example of the preferred embodiment of the current invention. This figure illustrates the server and the clients using various connection mechanisms to connect the application As shown in the fig a screenshot of the first step used for creation of a new Data Source in the preferred embodiment of the present invention The user is required to create an ODBC Data Source to connect to the database server The ODBC configuration utility automatically senses currently live active servers and populates the server selection combobox The user specifies a name to the DSN connection 600 and description implies application usability 610 The description string 610 is optional and may not necessarily be defined by the user which is assumed as NULL string in absence of valid argument As specified earlier the current ODBC implementation allows user to define and choose a RAS server, which is selected by clicking the Remote Server Configuration button 630 The Remote Server Configuration button 630 is as shown in the screenshot that allows the client to connect the server via a RAS device such as modem binded with requisite protocols This happens typically by default when the configuration manager senses RAS support available and is unable to find local instance of server running Accordingly the 'Next" button 640, a "Close" Button 650 and a "Help" Button 660 are provided to proceed to the next step in fulfilling pending DSN arguments

The Fig 7 is a screen shot, which pops when the user clicks on the Remote Server Configuration of the previous screen A separate form provides textbox interfaces for phone number 700, the extension 710, the RAS (Remote Access Service) UserlD 720 and password 730 If the proposed server implementation supports multiple database instances for single server instance this option allows the user to choose any database from the active server instance running on the server machine specified After the user confirms his selection then presses the "OK" button 740 to continue with the next step Also at appropriate times the "Cancel" Button 750 can be used The Fig 8 is the next step where DSN arguments like UID and password are specified by the application developer. The user is required to choose the Server Authentication such as either Operating System based Authentication 800 or connection using the Server's Login ID and password 810 In case the selected Server Authentication is Connect using server Login ID and Password 810, the appropriate values of Login ID 820 and the Password 830 needs to be entered The server verifies these arguments against the user schema details in the selected database Any invalid or unspecified user or password halts further completion of DSN process There is also a provision for encrypted authentication 840 and an option to set the Default settings Further the form provides option for configuring the client connectivity protocol using the Client "Configuration" button 860 The 'Back" 870, 'Next" 880, Close" 890, "Help" 895 buttons are provided When the user clicks on the 'Next" button 880, the next form pops The developer typically uses this in the development phase rather than deployment cycle This form is an intuitive interface for generating encrypted keys, which the developer embeds in the application code to manage DSN less connectivity

The Fig 9 is a screenshot that pops up once the user clicks on the Encryption Authentication of the previous form The Encryption form pops up where the users Login ID 900 along with the Encrypted Login ID 910 Password 920 and the Encrypted Password 930 are displayed

The Fig 10 is the form that pops up when the 'Client Configuration" button is clicked The wizard requests for selecting preferred communication protocol between server and database clients using the Network Libraries 1000 such as Named Pipe 1005, NWLink IPX/SPX 1010, TCP/IP 1015, Bequeath 1020 and FTP 1025 The choice for these network protocols depends upon the underlying hardware and the OS deployed and binded protocol available with the hardware configured As shown in the form the driver option allows specifying a Service Name 1030 or a Network address 1035 including the details such as IP Address 1045, Port Address 1050 and the network address 1055 which can later be resolved by the DNS server Conversely a Service Name 1035 can also be used to bind a client - server driver communication mechanism The Ok" button 1060 is clicked to proceed to the next form Besides at any time the "Cancel" button can be used to exit the wizard The Fig 11 is the next part of DSN User Interface, which allows basic data interpretation options between server and ODBC data buffer As per the user's rights the combobox is populated with the existing Databases The user is required to select the appropriate database any make it the default database 1100 Further the use is required to set the ANSI Null paddings 1105, set ANSI quoted identifiers 1110, synchronize with the server 1115, select the Regional settings as per Server 1120 Thus user also has to select a unique option to synchronize server and client NLS settings are also provided This enforces the regional settings of the client to be changed as per the server settings during every application connect to the database server the very first time The user is provided with the option to Auto Commit 1125, the user can choose from the various compatibility level s1 130 Various other options such as the Page Size 1135, the Buffer Size 1 140, Query Timeout 1 145 in milliseconds Connection Timeout 1150 in milliseconds The advantage of enforcing such an option reduces unpredictability between data type interpretations during a client side buffer management and translating the server specified NLS sensitive data types such as currency, date, time etc This small overhead during first connection process saves a lot of data translation per record during every record have NLS sensitive data The "Back" button 1155 is provided for going back to the previous screen, when the "Next" button 1160 is clicked the next screen pops up The Cancel" 1165 and "Help" 1170 button provide the functions as their names suggest

The Fig 12 is the last form that appears and displays the parameters of the ODBC data source are Buffer Size, Compat Level, Computer, Conn Timeout, Database etc The list will be populated with the user specified DSN options or defaults in case the user has skipped few The Test Connectivity" button 1210 verifies whether the options selected and accepted by the server communicate well Incase the connectivity fails the user needs to reconfigure options to suite server / database / schema / protocols etc to ensure seamless client server connectivity The "Finish" button 1220 option saves these DSN arguments in the OS registry and is used for future retrievals during DSN modifications The 'Cancel' button 1230 is used to cancel the process at any time The "Help" button 1240 is used to find help as the name suggest

Claims

WHAT IS CLAIMED IS:

1 A method for enhancing security of a driver interface and resolving a plurality of connectivity parameters, the method comprising. isolating a plurality of DSN parameters used to connect to a server, preparing a control packet comprising a schema details received from the DSN parameters along with a hardware information in an encrypted format using a standard encryption algorithm, transmitting the control packet from a client to the server, receiving a response from the server based on a licensing policy, decrypting a corresponding received control packet using a key provided by the server, acknowledging the received control packet comprising the encryption algorithm and encryption keys, and using the encryption keys for any further communication with the server

2 The method of claim 1 , wherein the preparing the control packet step further comprises generating an encrypted key using the standard encryption algorithm and employing the hardware information to connect to the server

3 The method of claim 1 , wherein the control packet can also be broadcasted if the server is not listed The method of claim 1 , wherein the driver supports dialing from a remote access service interface

5 The method of claim 1 , wherein a developer uses the encryption keys as DSN arguments The method of claim 1 wherein the client and server could communicate irrespective of the communication protocol using one of the ODBC OLEDB or JDBC scripts/languages The method of claim 1 , wherein any regional settings of the client can be synchronized with the server

The method of claim 1 , wherein the transfer of data from a first client type to a second client type is enabled

The method of claim 1 , wherein the service can be accessed using a remote server

A system for enhancing security, the system comprising

Atleast one client computer including a client memory, a client processor, and a client transceiver in communication with one another the client memory including an encrypted information send to a server computer, wherein the client processor and transceiver are configured to provide an unique key using any or all hardware information and a standard encryption algorithm

The system of claim 10, further comprising the server in communication with the client computer, the server computer including atleast a server memory, a server processor, and a server transceiver in communication with one another, the server memory including the control packet received from the client computer by the server computer and responding to a client request depending on the licensing policy

The system of claim 10, wherein the system allows access to remote devices

The system of claim 10, wherein a first client computer exchanging data to and from a second client computer where these both clients are of different type