Abstract:
A method and apparatus for unique and secure identification of a computing service node. The service node is coupled to an administrative node and to a certificate authority node via a computer network. The administrative and certificate authority nodes have respective public and private keys. A shared key is established between the certificate authority node and the administrative node, and while booting the service node, the service node generates its public key and private key. The administrative node double encrypts a selected value, first using the shared key and second using the public key of the service node, whereby a double encrypted value is generated. The double encrypted value is decrypted at the service node, whereby a single encrypted value is generated. Whether the certificate authority node is able to successfully decrypt the single encrypted value using the shared key determines whether the administrative node is authentic.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates to unique and secure identification of computing nodes that are connected by a network.  
         BACKGROUND  
         [0002]    Networked computing arrangements use various addressing schemes for uniquely identifying the computing nodes on the network. For example, an internet protocol (IP) network uses IP-specific addresses. The unique addresses allow the attached nodes to selectively transmit data to other nodes on the network.  
           [0003]    Although IP addresses provide unique identification of nodes on a network, IP addresses can be taken and used for false identification, and are therefore insufficient for securing the identity of a node. The assumption of one node&#39;s identification by another node is one way in which confidential information is obtained. With the continued growth of computing arrangements devoted to running a business, for example, selling, developing, and managing, the risks associated with the misappropriation of confidential information are too great to ignore.  
           [0004]    One way in which the identity of nodes is protected is by way of certificates and management by a certificate authority (CA). Communicating nodes pass certificates and verify authenticity with the CA. Establishing certificates is generally initiated by manual intervention. For example, when a new node is deployed in a computing environment in which the various nodes are managed by way of an administration node, the new node must be configured with the appropriate certificate in order to communicate with the administration node. Thus, identifying and securing the identity of a node on a network can initially cause delays in deploying the node.  
           [0005]    A system and method that address the aforementioned problems, as well as other related problems, are therefore desirable.  
         SUMMARY OF THE INVENTION  
         [0006]    The present invention provides a method and apparatus for unique and secure identification of a computing service node in various embodiments. The service node is coupled to an administrative node and to a certificate authority node via a computer network. The administrative and certificate authority nodes have respective public and private keys. A shared key is established between the certificate authority node and the administrative node, and while booting the service node, the service node generates its public key and private key. The administrative node double encrypts a selected value, first using the shared key and second using the public key of the service node, whereby a double encrypted value is generated. The double encrypted value is decrypted at the service node, whereby a single encrypted value is generated. Whether the certificate authority node is able to successfully decrypt the single encrypted value using the shared key determines whether the administrative node is authentic.  
           [0007]    Various example embodiments are set forth in the Detailed Description and claims which follow. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0008]    Various aspects and advantages of the invention will become apparent upon review of the following detailed description and upon reference to the drawings in which:  
         [0009]    [0009]FIG. 1 is a block diagram of an example computing arrangement in which the present invention can be used;  
         [0010]    [0010]FIG. 2 is a block diagram of a computing arrangement that includes a service node configured with an network interface card having extended functionality in accordance with an example embodiment of the invention;  
         [0011]    [0011]FIG. 3 is a block diagram that illustrates an example data flow between a service node, an administrative node, and a primary certificate authority;  
         [0012]    [0012]FIG. 4 is a flowchart of an example process performed by a service node in registering a unique and secure identity with an administrative node in accordance with one embodiment of the invention; and  
         [0013]    [0013]FIG. 5 is a flowchart of a process performed by an administrative node in registering a service node. 
     
    
     DETAILED DESCRIPTION  
       [0014]    [0014]FIG. 1 is a block diagram of an example computing arrangement in which the present invention can be used. Computing arrangement  10  includes a plurality of service nodes  12  that are coupled to clients  22 ,  24 , and  26  via network  28 . The configuration and management of the service nodes are performed via administrative node  32 , which is coupled to the service nodes via network  34 . The primary certificate authority  36  in conjunction with the administrative node manages the authentication of the service nodes. Each of the different types of nodes is a data processing system in the example arrangement  10 . In one embodiment, the service nodes are configured as dynamic host configuration protocol (DHCP) clients, and the administrative node  32  is the DHCP server.  
         [0015]    The service nodes  12  in the example arrangement provide computing services to the clients  22 ,  24 , and  26 . Example services include storage, communication, information or other services. Increasing service capacity in arrangement  10  involves deploying additional ones of service nodes  12 . Thus, a new service node must be uniquely identifiable amongst the service nodes, and security measures must be taken to ensure that another node cannot assume the identity of the new node.  
         [0016]    With the present invention, a unique, secure identity is automatically established for a service node using public key encryption and certificates. In one embodiment, a service node is configured to automatically generate a public key and a private key while the node is being booted. The keys are automatically generated by and stored within a network interface card, which eliminates manual specification of the keys. After the keys are generated, the service node automatically registers with the administrative node  32 .  
         [0017]    Registration of a service node with the administrative node also involves interaction with the primary certificate authority  36 . The service node initiates the registration process by sending its public key to the administrative node  32 , and the administrative node responds with an arbitrary value encrypted using a shared key previously negotiated with the primary certificate authority and the network address of the primary certificate authority encrypted using the service node&#39;s public key. The service node decrypts the information returned by the administrative node to obtain the address of the primary certificate authority. The encrypted arbitrary value is then sent to the primary certificate authority. If the primary certificate authority successfully decrypts the arbitrary value, then a response is returned to the service node to indicate successful authentication.  
         [0018]    [0018]FIG. 2 is a block diagram of a computing arrangement that includes a service node configured with a network interface card having extended functionality in accordance with an example embodiment of the invention. System  100  includes a service node  102  that is coupled to administrative node  32  and primary certificate authority via network  108 .  
         [0019]    Client system  102  includes a processor  112  that is coupled to the enhanced network interface card (ENIC)  114  and a conventional network interface card (NIC)  116  via the host I/O bus  118  (e.g., PCI bus). ENIC  114  includes functionality beyond the physical interface to the network. For example, node registration logic  113  is implemented on the ENIC. The node registration logic generates the public and private keys for the service node and performs the registration activities with the administrative node  32  and the primary certificate authority  36 . The capability to automatically generate the keys eliminates the need to manually distribute keys to the various service nodes.  
         [0020]    In another embodiment, an NFS client proxy  110  is implemented on the ENIC, along with the TCP/UDP stack  118 , IP layer  120 , and physical layer  121 . The NFS client proxy implements functional extensions added to the standard NFS protocol. Network interface card  116  provides a standard interface for client system  102  to the network  108 . For example, network interface card  116  may be any one of a number of commercially available cards for connecting a Unix, Linux, NT, or Windows based machine to a network.  
         [0021]    Processor  112  executes software elements such as NFS client  122 , interceptor module  124 , ENIC interface  126 , and native protocol stack  128 . NFS client is an example application that makes NFS-RPC calls. Interceptor module  124  is a software module that works in conjunction with ENIC  114 . The function of interceptor module  124  is to intercept RPC calls, and depending on the particular procedure referenced, direct the call to either ENIC interface  126  or to native protocol stack  128  for processing. NFS-specific RPC calls are directed to ENIC interface  126 , and other RPC calls are directed to native protocol stack  128 .  
         [0022]    Further details regarding an example implementation of ENIC  114  can be found in the application/patent entitled, “PROCESSING NETWORK PACKETS”, by Russell et al., filed on Aug. 11, 2000, having application/patent Ser. No. 09/630,033, and assigned to the assignee of the present invention. The contents of the application/patent are incorporated herein by reference. The ENIC supports implementation of the lower layers of the standard NFS client protocol, along with any extensions to the standard protocol. Further information on implementation of NFS extensions on ENIC  114  is found in the application/patent entitled, “EXTENDING A STANDARD-BASED REMOTE FILE ACCESS PROTOCOL AND MAINTAINING COMPATIBILITY WITH A STANDARD PROTOCOL STACK”, by Karamanolis et al., filed on Jan. 31, 2001, having application/patent Ser. No. 09/774,841, and assigned to the assignee of the present invention; the contents of which are incorporated herein by reference.  
         [0023]    [0023]FIG. 3 is a block diagram that illustrates an example data flow between a service node, an administrative node, and a primary certificate authority. During the boot process of service node  102 , the service node generates its public and private keys and sends a boot request (line  202 ) to administrative node  32 . The boot request includes the service node&#39;s public key and provides an indication to the administrative node that the service node is available to provide additional capacity in the environment.  
         [0024]    The administrative node responds to the boot request with a configuration offer (line  204 ). The configuration offer includes an encrypted network address of the primary certificate authority  36 , a double encrypted arbitrary value, and data relating to the proposed configuration of the service node. The network address is encrypted using the public key provided by the service node, and the arbitrary value is encrypted first using a shared key previously negotiated between the primary certificate authority and the administrative node and second using the public key of the service node  102 . The data relating to the proposed configuration is encrypted using the public key of the service node and is implementation dependent.  
         [0025]    When the service node receives the configuration offer from the administrative node, the service node decrypts the address of the primary certificate authority, the arbitrary value, and the data describing the proposed configuration. The service node then sends the arbitrary value (still singly encrypted between the administrative node and the primary certificate authority) to the primary certificate authority (line  206 ). The primary certificate authority decrypts the arbitrary value and returns a response to the service node (line  208 ). The response to the service node indicates whether the primary certificate authority successfully decrypted the arbitrary value from the administrative node, that is, whether the administrative node has been authenticated. Depending on successful authentication and other application-specific factors, the service node responds to the configuration offer (line  210 ).  
         [0026]    [0026]FIG. 4 is a flowchart of an example process performed by a service node in registering a unique and secure identity with an administrative node in accordance with one embodiment of the invention. The service node generates its public and private keys during its boot process (step  302 ). In one embodiment, the keys are generated by software executing in the enhanced network interface card using a commercially available software library. Example encryption algorithms implemented by the software include RSA, Digital Signature, PAK, and ESIGN. The keys are stored in the ENIC  114 .  
         [0027]    The service node then sends a boot request, which includes the node&#39;s public key, to the administrative node (step  304 ) and waits for a response (step  306 ). Once a response is received, the process continues (decision step  308 ) with decryption of the information from the administrative node (step  312 ). The decrypted information includes the address of the primary certificate authority, the arbitrary value encrypted using the key shared with the primary certificate authority, and the data that indicate the proposed configuration. In one embodiment, the service node is configured as a DHCP client and obtains the keys of the administrative node during DHCP configuration.  
         [0028]    Authentication is then performed with the primary certificate authority as referenced by the address from the administrative node. The arbitrary value encrypted by the administrative node is sent to the primary certificate authority (step  314 ). Upon receiving a response from the primary certificate authority (step  316 ), the service node determines whether the administrative node is authenticated (decision step  320 ). If the administrative node is authenticated (the primary certificate authority successfully decrypted the arbitrary value), the service node then determines whether to accept or decline the offer of configuration. The criteria used to determine whether to accept the configuration is application dependent. For example, in an arrangement where there are multiple administrative servers and the service node generates multiple boot requests, the criteria may be to accept the offer from the administrative node that is authenticated first. The service node completes its configuration in accordance with whether the configuration offer was accepted or declined (step  324 ).  
         [0029]    If the administrative node is not authenticated (the primary certificate authority could not decrypt the arbitrary value), then the failure is reported (step  326 ). For example, the failure may be reported to a system administrator in the form of a log file entry, email message, or an audible alarm, depending on application requirements.  
         [0030]    Returning the discussion to where the process is waiting for a response from the administrative node (step  306 ), if the service node does not receive a response in a selected interval of time, the duration of the interval is increased (step  332 ). The process then returns to step  304  where another boot request is sent to the administrative node.  
         [0031]    [0031]FIG. 5 is a flowchart of a process performed by an administrative node in registering a service node. Prior to receiving boot requests from service nodes, the administrative node negotiates (step  404 ) with the primary certificate authority for a shared key. In one embodiment, a known key exchange protocol such as the Internet Key Exchange Protocol is used.  
         [0032]    Upon receiving a boot request from a node (step  406 ), the administrative node determines whether the node is needed (decision step  408 ). If the services of the node are not required, the identity of the node is saved in a pool of available nodes (step  410 ), and a response is returned to the node (step  412 ) indicating that service is not presently required.  
         [0033]    If the node&#39;s service is needed, the administrative node encrypts (step  414 ) an arbitrary value using the key negotiated with the primary certificate authority. The encrypted arbitrary value and further information is then encrypted using the public key of the service node (step  416 ). The additional data that are encrypted include the address of the primary certificate authority and data that describe the configuration offered to the service node. The encrypted data are then transmitted to the service node (step  418 ). If the service node accepts the offer of configuration, the administrative node provides the necessary data (step  420 ); otherwise, no further action is taken with the service node.  
         [0034]    In addition to the example embodiments described above, other aspects and embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and illustrated embodiments be considered as examples only, with a true scope and spirit of the invention being indicated by the following claims.