Unique and secure identification of a networked computing node

The present invention relates to unique and secure identification of computing nodes that are connected by a network.

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.

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'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.

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.

A system and method that address the aforementioned problems, as well as other related problems, are therefore desirable.

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.

Various example embodiments are set forth in the Detailed Description and claims which follow.

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:

FIG. 1 is a block diagram of an example computing arrangement in which the present invention can be used;

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;

FIG. 3 is a block diagram that illustrates an example data flow between a service node, an administrative node, and a primary certificate authority;

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

FIG. 5 is a flowchart of a process performed by an administrative node in registering a service node.

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.

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.

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 .

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'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.

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 .

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.

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.

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 .

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.

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's public key and provides an indication to the administrative node that the service node is available to provide additional capacity in the environment.

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.

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 ).

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 .

The service node then sends a boot request, which includes the node'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.

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 ).

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.

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.

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.

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.

If the node'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.

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.