Patent Publication Number: US-7900046-B2

Title: System and method for establishing mutual trust on a per-deployment basis between two software modules

Description:
BACKGROUND OF THE INVENTION 
     1. Technical Field of the Invention 
     This invention relates to computer programming. More particularly, it relates to establishing trust between software entities on a per-deployment basis. 
     2. Background Art 
     Websphere (WS) Information Integrator (II), an example of a pluggable architecture, provides an open pluggable architecture for obtaining identity mapping information for different systems involved in an integration project. This architecture allows both industry-standard integration components as well as proprietary elements to be integrated or plugged into WS II through a simple interface. The software components that can be plugged into WS II and work together with WS II are called Plugins. 
     The Lightweight Directory Access Protocol (LDAP) is an Internet protocol that other programs use to look up information from a server. It is protocol for accessing information directories. LDAP is based on the standards contained within the X.500 standard, but is significantly simpler. And unlike X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. Because it&#39;s a simpler version of X.500, LDAP is sometimes called X.500-lite. LDAP should eventually make it possible for almost any application running on virtually any computer platform to obtain directory information, such as email addresses and public keys. Because LDAP is an open protocol, applications need not worry about the type of server hosting the directory. 
     LDAP servers index all the data in their entries, and “filters” may be used to select just the person or group desired, and return just the information desired. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide “single sign-on” where one password for a user is shared between many services. LDAP is appropriate for directory-like information, where fast lookups and less-frequent updates are the norm. LDAP also defines: (1) Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private, and (2) Schema, to describe the format and attributes of data in the server. 
     A plugin contains the logic to retrieve secured information from a LDAP server and then decrypt the secured information for WS II to use. A plugin is associated with a WS II instance, or deployment, and not associated with each user. This is an example of a situation where there is a need to build mutual trust between two software entities—in this example, WS II instance and a plugin invocation. Thus, there is a need not previously recognized or resolved by the art to establish mutual trust between the two software entities. 
     A further complication arises due to the fact that WS II trial versions can be freely downloaded off the web. Not only must the plugin know that it is talking to a WS II instance, but it needs to know that it is interacting with a specific customer-authorized deployment of WS II. Otherwise, a malicious user may install a trial version of WS II and try to get the plugin to divulge usernames and passwords to it. Therefore, there is a need not previously recognized or resolved by the art to establish mutual trust between the two software entities on a per-deployment basis, that is, with each deployment of WS II. 
     Applets run in a user&#39;s context (such as a browser or AppletViewer). They could be malicious, spreading viruses and so forth. The Java Virtual Machine (JVM) attempts to circumvent this problem by restricting the ability of applets to function. For example, unsigned applets are not permitted to read and write files, load libraries on a client, execute processes, exit the virtual machine, open network connections except to the host. Further, applets loaded over the net are passed through a verifier to ensure that bytecodes were not engineered. The trust issue in applets has heretofore required that applets be restricted to run in a closed sandbox thereby significantly curbing their abilities. Thus there is a need not previously recognized and resolved by the art for a trust mechanism that allows Plugins various privileges, including executing decryption logic embedded within it. 
     In Java, the problem of applets being too restrictive has heretofore been approached by allowing applets to be signed. A signed applet is one that is packaged within a signed jar file. The signed jar file can be downloaded from an HTTP server, just like any other jar file. However, for the applet to be trusted, the user must trust the key that was used to sign the jar file. When a signed applet is encountered, a security dialog pops up, identifying the signer of the jar. The user is given an option to either grant always, grant this session, deny, or provide more information to the applet. Once the user makes a selection, the applet will then run in the corresponding security context. However, this technique requires user intervention at least once, and it only establishes one-way trust. Mutual trust is not realized inasmuch as the signed applet is usable by anyone who can download it. 
     As a result, since applets are too restrictive, they are seldom useful. To allow more useful mobile code, ActiveX controls are used. These can be downloaded onto browsers or placed in a plugin directory. Since ActiveX controls do not run in a sandbox, they can run any commands on the user&#39;s system. The introduction of such controls spawned a variety of viruses on the Net. Consequently, validation of ActiveX is done by “code signing”, by which developers certify that their software modules are not harmful and pay a nominal fee to an agency for the privilege of obtaining a digital certificate. When an Activex control is downloaded to a browser, the browser checks to make sure there is a valid signature that has not been altered and that the developer is in good standing with the signature authority. Only then can the control be usable. While this approach is a solution to one-way trust, the ActiveX control is still unable to verify the authenticity of the caller. 
     Other approaches to trustworthiness include Microsoft Authenticode™ technology which lets end users who publish a software component verify that it was not changed since it was signed and downloaded. Although Authenticode technology provides some assurance of code identity and integrity, it does not establish mutual trust on a per deployment basis. 
     Thus, there is a need in the art for a system and method for establishing mutual trust between two software components on a per-deployment basis. 
     SUMMARY OF THE INVENTION 
     A system, method, and computer program product for establishing mutual trust on a per-deployment basis between two software, by executing for this deployment an initial handshake between the software modules wherein both modules identify themselves and exchange digital certificates received from a trusted certification authority and respective public keys; and executing subsequent communications for this deployment between the software modules with each module encrypting its communications with the public key of the other module; thereby establishing mutual trust between the software modules for each deployment. 
     Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a high level system diagram illustrating a WS II instance or deployment. 
         FIG. 2  is schematic representation of the Open Systems Interconnection (OSI) protocol stack of the prior art. 
         FIG. 3  is a schematic representation of the preferred embodiment of the invention. 
         FIG. 4  is a flow chart representation of the setup process for the preferred embodiment of the invention. 
         FIG. 5  is a flow chart representation of the interaction between WS II and Plugin in accordance with an exemplary embodiment of the invention. 
         FIG. 6  is a diagrammatic representation of the programming methods and structures of the exemplary embodiment of  FIG. 5 . 
         FIG. 7  is a high level system diagram illustrating a computer program product in accordance with the preferred embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     In accordance with the preferred embodiment of the invention, there is provided a system and method for assuring mutual trust between software components on a per-deployment basis. Thus, for example, when WS II and Plugin components are dynamically hooked together, mutual trust is established between these two parties as will be described hereafter. 
     Referring to  FIG. 1 , as represented by line  101 , a WS II  94  user name  91  (John) and password  92  (ii_pwd) are written to WS II  94 . Next, WS II  94  issues a function call ‘get oracle credentials’  102  to Plugin  96 . Plugin  96  issues a remote network call  103  to Lightweight Directory Access Protocol (LDAP)  98  to access data. Data in the LDAP server is not stored as a table, but as a tree such as organization→person→user_mapping, where user_mapping looks like an entry in the following Table 1: 
     
       
         
           
               
             
               
                 TABLE 1 
               
             
            
               
                   
               
               
                 EXAMPLE LDAP TABLE 
               
            
           
           
               
               
               
               
               
            
               
                   
                   
                   
                   
                 Encrypted 
               
               
                   
                 Server 
                 AuthID 
                 UserName 
                 Password 
               
               
                   
                   
               
               
                   
                 Oracle1 
                 John 
                 Scott 
                 ~D&lt;&lt;AV,6 
               
               
                   
                 Sybase1 
                 John 
                 Johnnie 
                 ~D&lt;&lt;76,AV 
               
               
                   
                   
               
            
           
         
       
     
     LDAP  98  returns remote network call  104  with Oracle User: Scott and Oracle password: ˜D&lt;&lt;AV,6 to Plugin  96 . Plugin  96  decrypts  105  Encrypted Oracle password ˜D&lt;&lt;AV,6 to obtain Oracle password: tiger, which it returns in function call  106  to WS II  94 . 
     WS II deployments  100  typically integrate all the data sources of the customer and therefore require extremely high levels of security. So, WS II  94  needs to completely trust any software module  96  that interacts with it. For example, a rogue Plugin  96  might return invalid passwords back to WS II  94  and cause the user to get locked out of all systems. Moreover, if Plugin  96  is trusted and runs within WS II&#39;s context  100 , it can cause even more damage such as memory leaks, shared memory corruption, and so forth. 
     Therefore, WS II  94  needs to completely trust any Plugin  96  or third party component before interacting with it. 
     In accordance with the preferred embodiments of the generates a public-private key-pair unique to its own deployment  100 . The customer then keeps its unique secret-key securely in its own deployment. As will be described hereafter in connection with  FIG. 3 , the public-key is sent by the customer to obtain a digital certificate from a well-known Certification Authority (CA). The certificate affirms the identity of the customer and is digitally signed by the CA. The CA can be either the customer itself (self-signed certificates) or any trusted CA such as IBM, Verisign and CA Cert. 
     In order to achieve mutual-trust, both Plugin  96  and WS II  94  trust the well-known certification authority (CA). That is, for example, if the CA verifies that the certificate is valid, then plugin  96  can trust that it is. A certificate shows that a public key stored in the certificate belongs to the subject of that certificate. A certification authority is responsible for verifying the identity of a requesting entity before issuing a certificate. The CA then signs the certificate using its private key, which is used to verify the certificate. 
     As will be more fully described hereafter, when the customer, such as a WS II  94  customer, interacts with, for example, a Plugin  96 , it first presents its certificate to prove its identity. The Plugin verifies that the certificate is indeed valid and the customer is who it claims to be. Then, the Plugin sends sensitive information to the customer, encrypting it in the customer&#39;s public-key. Since the customer&#39;s private-key is securely kept in its own deployment, there is no way in which the secure information can be decrypted and used by any entity other than the customer. 
     Two-way, or mutual, trust is assured, as follows. Just like the plugin  96  verifies the identity of WS II, the WS II in turn also verifies the identity of plugin  96 . All communication is encrypted in each other&#39;s public keys, so both verify the other&#39;s identity and both sides of the communication are protected. 
     In the present invention, communication between the Plugin and the WS II occurs at the application layer  110 ,  112  of a protocol stack. 
     Referring to  FIG. 2 , the Open Systems Interconnection (OSI) architecture is an example of a protocol stack which includes a plurality of functional layers, including application  110 ,  112 , presentation  114 ,  116 , session  118 ,  120 , transport  122 ,  124 , network  126 ,  128 , data link  130 ,  132 , and physical  134 ,  136  layers. Other protocol stacks may combine or separate functions in a different configuration of layers. However, it is a characteristic of such protocol stacks that communication occurs between corresponding layers in both system nodes involved, such as between a server node  107  and a client node  109 , as is represented by lines  141 - 147 , respectively. 
     Referring to  FIG. 3 , in accordance with the present invention, mutual trust is established by beginning all conversations between software modules  156 ,  158  (such as WS II  94  and Plugin  96 ) with an initial handshake  160  wherein both parties  156 ,  158  identify themselves and establish trust by exchanging digital certificates  162 ,  164  received from some trusted certification authority  154  and their respective public keys  168 ,  170 , before further communicating. 
     All subsequent communications  116  between parties  156 ,  158  are also encrypted with each other&#39;s public keys  168 ,  170 , respectively, as is represented by lines  161 ,  165  and  163 ,  167 , so only the intended recipient can decode the information exchanges  166  between the two entities  156 ,  158 . 
     The present invention provides establishing mutual trust between software modules  156 ,  158  on the same machine or on different machines. Therefore, the communication may or may not involve any network. Two software modules  156 ,  158  on the same server may talk to each other through remote procedure calls or inter process communication or other mechanisms not involving any network. Therefore, the present invention uses handshake  160  which occurs at an application layer between two communicating software entities  156 ,  158 . 
     Referring to  FIG. 4  in connection with  FIG. 6 , an exemplary embodiment of the setup process of the invention begins in step  180  with a customer downloading WS II  224 . 
     In step  182 , customer WS II  224  generates a public-private key-pair  230 ,  252 . In step  184  private key  252  is kept in a secure keystore known only to customer. 
     In step  186 , public key  230  is used to obtain a certificate  232  from a trusted certificate authority (CA)  254 . Certificate  232  guarantees that customer WS II  224  is indeed what it claims to be. This provides proof of identity of the originator and ensures non-repudiation. 
     In step  188 , certificate  230  is deployed in a predetermined path in WS II  224 . That is, the key is stored somewhere with the WS II deployment at a location where access is very limited—for example, at a location where only a super-user or super-administrator has access privileges. 
     In step  190 , it is determined if mutual trust is required because Plugin  222  also needs to be validated by the WS II deployment, and if so, in step  192  Plugin  222  also generates a public  240 /private key-pair and in step  194  obtains certificate  242  from certificate authority (CA)  154  for use by WS II  224  in verifying its (Plugin  222 ) identity. 
     Referring to  FIG. 5  in connection with  FIG. 6 , subsequent to setup process ( FIG. 4 ), in step  200  WS II  224  initiates a request  226  by sending its certificate  232  to prove its identity  228 . 
     In step  202 , Plugin  222  validates  234  certificate  232  to ensure that it is indeed interacting with the customer&#39;s WS II  224 . 
     In steps  204 ,  206 , in case WS II  224  also needs to trust Plugin  222 , Plugin  222  responds by sending its response  236  including its own certificate  242 . In step  208 , WS II validates certificate  242  with respect to identity  238  to verify the trustworthiness of Plugin  222 . 
     Parties  222  and  224  have now established mutual trust, and handshaking is complete. They can now interact. 
     In step  210 , WS II  224  issues request  246  for some sensitive information from Plugin  222 . 
     In step  212 , Plugin  222  sends the sensitive reply  248  encrypted in WS II&#39;s public key  230 . In step  214 , WS II  224  decrypts ( 250 ) the sensitive information using its private key  252 . 
     Public key cryptography is a form of cryptography that uses a pair of mathematically related cryptographic keys, designated as public key and private key, to enable users to communicate securely without having prior access to a shared secret key. 
     In public key cryptography, the private key is keptsecret, while the public key may be widely distributed. Due to the aforementioned mathematical relationship, the public and private keys are related in such a way that any message encrypted with the public key can only be decrypted by the corresponding private key. In simple terms, one key “locks” a lock; which the other is required to unlock it. 
     Also, despite the mathematical relationship between the public and private keys, it is computationally infeasible to deduce the private key from the public key. 
     As a result of processing described above, there is provided a two-way (as opposed to a one-way) trust between software components  156 ,  158 . The trust mechanisms apply to each individual deployment or instance  100  of a software product (as distinguished from the software product itself, and thus differing from signed jars and signed mobile code which cannot distinguish individual deployments). The mutual trust mechanisms do not rely on transport level  122 ,  124  security such as SSL/https. Security is incorporated at the application level  110 ,  112  into the basic communication  141  protocol between software modules  156 ,  158 . 
     Unlike other solutions for establishing trust, the present invention is secure against compromising of the secret-key (which remains truly secret) and is also robust against certificate theft. 
     The architecture of the preferred and exemplary embodiments described previously for establishing mutual trust and secure interaction is general enough to be applied to any pluggable architecture. Any setup that includes an autonomous entity interacting with a third-party software module or Plugin can use the present invention to establish mutual trust. 
     The process flow of the preferred and exemplary embodiments described previously for establishing mutual trust and secure interaction can be used for certifying a “good” or trustworthy Plugin. WS II interacts with various software modules, such as user defined functions (UDFs), 3rd party wrappers, stored-procedures, Plugins, and so forth. There is presently no standardized process in place to ascertain that WS II is indeed interacting with a trustworthy component. The burden of ensuring safety of the software modules has previously been placed on the system administrator or database administrator. Although a federated server can run in a “fenced mode” and avoid being crashed by a malicious Plugin or component, there is no protection against malicious Plugins or modules using up too much memory or causing other resource-errors in the system. The present invention can be used to standardize the process for obtaining identities and establishing trust between components, thereby eliminating the need for implicit trust on the administrators. 
     Advantages Over the Prior Art 
     It is an advantage of the present invention that there is provided a system and method for establishing mutual trust between software components with each deployment (that is, on a per-deployment basis). 
     Alternative Embodiments 
     It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. 
     While the invention has been described primarily with respect to the WS II identity mapping plugin architecture, it may be applied to any kind of pluggable architecture. Also, a plugin is not limited to work just with LDAP. It can be used with any repository, and thus the invention is directed to the more general problem of mutual trust between two software modules. 
     The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. 
     Referring to  FIG. 7 , the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium  260  providing program code  264  for use by or in connection with a computer or any instruction execution system  262 . For the purposes of this description, a computer-usable or computer-readable medium  260  can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution, system, apparatus, or device  262 . 
     The medium  260  can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. 
     A data processing system suitable for storing and/or executing program code will include at least one processor  262  coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code  264  in order to reduce the number of times code must be retrieved from bulk storage during execution. 
     Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. 
     Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters. 
     Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.