WO2013028235A2 - Systems and methods for providing secure multicast intra-cluster communication - Google Patents

Systems and methods for providing secure multicast intra-cluster communication Download PDF

Info

Publication number
WO2013028235A2
WO2013028235A2 PCT/US2012/033904 US2012033904W WO2013028235A2 WO 2013028235 A2 WO2013028235 A2 WO 2013028235A2 US 2012033904 W US2012033904 W US 2012033904W WO 2013028235 A2 WO2013028235 A2 WO 2013028235A2
Authority
WO
WIPO (PCT)
Prior art keywords
cluster
node
connected device
processor
mutual authentication
Prior art date
Application number
PCT/US2012/033904
Other languages
French (fr)
Other versions
WO2013028235A3 (en
Inventor
Philip Bryan CLAY
Original Assignee
Netapp, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Netapp, Inc. filed Critical Netapp, Inc.
Priority to JP2014527143A priority Critical patent/JP2014529238A/en
Priority to CN201280046647.7A priority patent/CN103959735B/en
Priority to EP12825993.4A priority patent/EP2748967A4/en
Publication of WO2013028235A2 publication Critical patent/WO2013028235A2/en
Publication of WO2013028235A3 publication Critical patent/WO2013028235A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104Grouping of entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Definitions

  • the present invention relates generally to intra-cluster communication and, more particularly, to providing secure multicast intra-cluster communication.
  • a cluster of different nodes communicate with each other, wherein a node is an operating unit (e.g., a processor-based system), operable to provide a desired function, service, or operation, or portion thereof, and which may cooperate with other nodes to form a cluster.
  • an operating unit e.g., a processor-based system
  • data storage systems often include a plurality of storage devices present at different nodes of the data storage system.
  • Such a data storage system may be implemented using a variety of storage architectures, such as a network-attached storage (NAS) environment, a storage area network (SAN), a direct-attached storage
  • NAS network-attached storage
  • SAN storage area network
  • Nodes of a data storage system may comprise processor-based systems, such as a file server system, a computer appliance, a computer workstation, etc.
  • Storage devices at the different nodes may comprise disk drives, flash memory, optical memory, etc. Selected ones of the storage devices may be organized as a storage array in accordance with the storage architecture.
  • Nodes hosting the storage devices of a storage array as well as other network-connected devices may thus comprise a cluster of nodes operable cooperatively to provide a data storage system.
  • nodes of a cluster communicate with each other.
  • Such communication may include various point-to-point communications (e.g., single node to single node or unicast communication) and multicast
  • each node of a cluster may need to have the capability to communicate with any and all other nodes of the cluster.
  • unsecured links such as public or other network links (e.g., the Internet, the public switched telephone network (PSTN), a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), etc.).
  • PSTN public switched telephone network
  • LAN local area network
  • MAN metropolitan area network
  • WAN wide area network
  • Such communications carried through such unsecured links may be susceptible to interception, eavesdropping, tampering, monitoring, sniffing, man-in-the-middle attack, relay attack, replay attack, etc.
  • SSL and TLS are cryptographic protocols that provide communication security using asymmetric cryptography for privacy and a keyed message authentication code for message reliability.
  • SSL and TLS are point-to-point security protocols. That is, unique key sets are utilized with respect to each node pair. Accordingly, secure multicast communication is not provided through the use of SSL and TLS security protocols.
  • JGROUPS provides a multicast protocol in which a "grouping" layer is added over a transport protocol. To provide security with respect to the multicast communications, JGROUPS implements its AUTH and ENCRYPT protocols.
  • the AUTH protocol only provides one way authentication (i.e., only one node authenticates the other) using a single token-based authentication (e.g., password or other authentication credentials communicated over the unsecured link), thus an eavesdropper can monitor the communications and mimic the security handshake (e.g., replay attack) to establish a false authentication.
  • a single token-based authentication e.g., password or other authentication credentials communicated over the unsecured link
  • ENCRYPT protocol uses a clusterKey to encrypt all multicast communications.
  • the clusterKey of the ENCRYPT protocol is provided to any node which provides its own public key and requests the clusterKey. Accordingly, even with AUTH and ENCRYPT protocols implemented by JGROUPS, a man-in-the-middle may easily join the cluster and thus the security provided with respect to multicast communications is somewhat illusory.
  • the present invention is directed to systems and methods which facilitate secure multicast communications between any valid node of a cluster using authentication between a node joining the cluster and any single node which is validly part of the cluster.
  • a cluster key e.g., a symmetrical cryptographic key
  • the cluster key of embodiments is shared by a node which is already part of the cluster with a node joining the cluster only after these two nodes mutually authenticate one another.
  • embodiments implements or is otherwise associated with a protocol in which a session key is calculated by both nodes, thereby facilitating a secure link between the nodes without the session key having been communicated over a network or other link.
  • the session key is used to securely share the cluster key with the node joining the cluster by the node which is already part of the cluster after these two nodes mutually authenticate one another according to embodiments of the invention.
  • each node of the cluster is enabled to securely communicate with any other node of the cluster, whether individually (e.g., unicast communication) or collectively (e.g., multicast communication).
  • embodiments of the invention facilitate nodes joining a cluster by authenticating against any node in the cluster.
  • Embodiments of the invention do not rely on the use of a public key
  • PKI PKI infrastructure
  • Embodiments herein may utilize available authentication protocols, key agreement protocols, and/or encryption algorithms or portions thereof, albeit in a new methodology tailored or otherwise adapted for use in a cluster environment for multicast communication, to thereby leverage well tested and thoroughly documented base technologies.
  • Once authenticated trust with respect to a joined node is established with the entire cluster of nodes. That is, the node joining the cluster essentially authenticates to the cluster as a logical unit in order to join.
  • nodes of the cluster are enabled to communicate with other nodes of the cluster using various messaging techniques including unicast and multicast messaging.
  • multicast communication techniques are not easily implemented in point-to-point type protocols.
  • FIGURES 1 A and IB show block diagrams of systems adapted to enable each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention
  • FIGURE 2 shows a ladder diagram of a high level process flow enabling each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention
  • FIGURE 3 shows a ladder diagram of a more detailed process flow enabling each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention.
  • a cluster as used herein is a group of linked or otherwise associated nodes operable together to provide a desired function, service, or operation thereby, in many respects, forming a single logical entity.
  • a node is a network-connected device operating unit, such as a processor-based system (e.g., computer, network appliance, etc.) and associated instruction set (e.g., software, firmware, application, etc.), operable to provide a desired function, service, or operation, or portion thereof, and which may cooperate with other nodes to form a cluster.
  • Intra-cluster communication is
  • Unicast communication is the sending of one or more message or information to a single network destination (e.g., node).
  • Multicast communication is the sending of one or more message or information to a plurality of network destinations (e.g., nodes) by a single transmission.
  • authentication is the process of one party (e.g., node) confirming the identity of another party (e.g., another node) whereas mutual authentication is the process of two parties (e.g., nodes) confirming the identity of each other.
  • An authentication handshake is the dialog of messages between two parties (e.g., nodes) trying to authenticate one or the other (authentication) or both (mutual authentication).
  • a key agreement protocol is a protocol whereby two or more parties (e.g., nodes) can agree on a key (e.g., cryptographic key used in encryption and/or decryption of data) in such a way that both influence the outcome, thereby facilitating separate calculation of a unique key (e.g., session key) without the need to communicate the unique key between the parties and thus avoiding eavesdropping and tampering.
  • Eavesdropping is when a third party (e.g., node which is not part of a cluster) observes communication without the consent and/or knowledge of the parties (e.g., nodes of the cluster) involved in the communication. Tampering is when a third party (e.g., network- connected device which is not part of a cluster) changes or otherwise alters data while it is in-flight between communicating parties (e.g., nodes of the cluster) without the knowledge of the parties involved in the communication.
  • a third party e.g., network- connected device which is not part of a cluster
  • Encryption is the process of transforming information (referred to as plaintext prior to encryption) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key (e.g., cryptographic key), whereas decryption is the process of transforming encrypted information back to plaintext.
  • plaintext prior to encryption
  • key e.g., cryptographic key
  • system 100 comprising a plurality of network-connected devices, shown as network-connected devices 110-130, coupled via network 101.
  • Network-connected devices 110-130 may comprise processor-based systems, such as a file server system, a computer appliance, a computer workstation, etc.
  • network-connected devices 110-130 of embodiments comprise a processor (e.g., central processing unit (CPU), application specific integrated circuit (ASIC), programmable gate array (PGA), etc.), memory (e.g., random access memory (RAM), read only memory (ROM), disk memory, optical memory, flash memory, etc.), and suitable input/output circuitry (e.g., network interface card (NIC), wireless network interface, display, keyboard, data bus, etc.).
  • processors e.g., central processing unit (CPU), application specific integrated circuit (ASIC), programmable gate array (PGA), etc.
  • memory e.g., random access memory (RAM), read only memory (ROM), disk memory, optical memory, flash memory, etc.
  • suitable input/output circuitry e.g., network interface card (NIC), wireless network interface, display, keyboard, data bus, etc.
  • the foregoing processor-based systems may operate under control of an instruction set (e.g., software, firmware, applet, code, etc.) providing operation as described herein
  • Network 101 may comprise various forms of communication infrastructure, such as the Internet, the PSTN, a LAN, a MAN, a WAN, a wireless network (e.g., a cellular communication network, a wireless LAN, etc.), and/or the like.
  • communication infrastructure such as the Internet, the PSTN, a LAN, a MAN, a WAN, a wireless network (e.g., a cellular communication network, a wireless LAN, etc.), and/or the like.
  • Various configurations of system 100 may be provided in which one or more cluster of nodes is formed from network-connected devices 1 10 and 120 to thereby provide a cluster environment, wherein cooperative operation of the cluster is facilitated through communication between the nodes of the cluster.
  • a data storage system may be formed from network-connected devices 110-130, wherein one or more storage device (e.g., storage devices 114 and 124) present at network-connected devices 110 and 120 (e.g., disk drive, flash memory, optical memory, etc.) cooperate to provide a volume accessible to network-connected device 130.
  • Network-connected devices 110 and 120 hosting storage devices of a storage array and client network- connected device 130 may thus comprise a cluster of nodes operable cooperatively to provide a data storage system.
  • FIGURE IB provides a block diagram in which additional detail with respect to embodiments of system 100 adapted to enable each node of a cluster to securely communicate with any other node of the cluster.
  • system 100 may comprise two or more interconnected, such as network-connected devices 110 and 120 configured to provide access to data stored on a set of storage devices (shown as storage devices 114 and 124) constituting storage of system 100.
  • Storage services may be provided by such nodes implementing various functional components that cooperate to provide a distributed storage system architecture of system 100.
  • nodes e.g., network-connected devices 110 and 120
  • N-modules 112 and 122 may include functionality to enable nodes to connect to one or more clients (e.g., network-connected device 130) over computer network 101
  • D- modules may connect to storage devices (e.g., as may implement a storage array).
  • M- hosts may provide cluster communication services between nodes for generating information sharing operations and for presenting a distributed file system image for system 100. Functionality for enabling each node of a cluster to securely communicate with any other node of the cluster may be provided by M-hosts adapted according to embodiments of the invention.
  • network 101 may comprise various forms, and even separate portions, of network infrastructure.
  • network-connected devices 110 and 120 may be interconnected by cluster switching fabric 102 while network-connected devices 110 and 120 may be interconnected to network - connected device 130 by a more general data network (e.g., the Internet, a LAN, etc.).
  • a more general data network e.g., the Internet, a LAN, etc.
  • N and D-modules constituting illustrated embodiments of nodes
  • network-connected devices 110 and 120 comprising one N- and one D-module should be taken as illustrative only and it will be understood that the novel technique is not limited to the illustrative embodiment discussed herein.
  • Network-connected device 130 may be a general -purpose computer configured to interact with network-connected devices 110 and 120 in accordance with a client/server model of information delivery. To that end, network-connected device 130 may request the services of network-connected devices 110 and 120 by submitting a read or write request to the cluster node comprising the network-connected device. In response to the request, the node may return the results of the requested services by exchanging information packets over network 101.
  • Network-connected device 130 may submit access requests by issuing packets using object-based access protocols, such as the Common Internet File System (CIFS) protocol, Network File System (NFS) protocol, Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI), and SCSI encapsulated over Fibre Channel (FCP) for instance.
  • object-based access protocols such as the Common Internet File System (CIFS) protocol, Network File System (NFS) protocol, Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI), and SCSI encapsulated over Fibre Channel (FCP) for instance.
  • CIFS Common Internet File System
  • NFS Network File System
  • SCSI Small Computer Systems Interface
  • FCP Fibre Channel
  • network- connected devices 110 and 120 may implement a combination of file-based and block- based protocols to communicate with network-connected device 130.
  • System 100 may further include a management console (shown here as management console 150) for providing management services for the overall cluster.
  • Management console 150 may, for instance, communicate with network-connected devices 110 and 120 across network 101 to request operations to be performed at the cluster nodes comprised of the network-connected devices, and to request information (e.g., node configurations, operating metrics) from or provide information to the nodes.
  • management console 150 may be configured to receive inputs from and provide outputs to a user of system 100 (e.g., storage administrator) thereby operating as a centralized management interface between the administrator and system 100.
  • management console 150 may be networked to network- connected devices 110-130, although other embodiments of the present invention may implement management console 150 as a functional component of a node or any other processing system connected to or constituting system 100.
  • network-connected device 130 may submit an access request to a node for data stored at a remote node.
  • an access request from network-connected device 130 may be sent to network-connected device 120 which may target a storage object (e.g., volume) on network-connected device 110 in storage 114.
  • network-connected device 120 may cache the requested volume in local memory or in storage 124. For instance, during initialization of network-connected device 120 as a cluster node, network-connected device 120 may request all or a portion of the volume from network-connected device 110 for storage at network-connected device 120 prior to an actual request by network-connected device 130 for such data.
  • network-connected devices 110- 130 may communicate with each other.
  • Such communication may include various forms of communication (e.g., point-to-point or unicast communication, multicast
  • each node of a cluster is provided with the capability to communicate with any and all other nodes of the cluster according to embodiments of the invention.
  • network 101 may provide unsecured links, and thus such communications may be susceptible to interception, eavesdropping, tampering, monitoring, sniffing, man- in-the-middle attack, relay attack, replay attack, etc.
  • embodiments of the invention provide secure communications (e.g., unicast and multicast) between any valid node of a cluster using authentication between a node joining the cluster and any single node which is validly part of the cluster.
  • operation according to embodiments of the invention performs a mutual authentication session between a node joining the cluster and any single node validly part of the cluster. If the mutual authentication is successful, operation according to the embodiment communicates a cluster secret (e.g., cluster key) to the node joining the cluster using a secure communication channel unique to the mutual authentication session (e.g., using a session key calculated in association with the mutual
  • possession of the cluster secret and the cluster credentials renders the node joining the cluster a cluster node and the cluster secret enables the cluster node to securely communicate with every other node which is validly part of the cluster.
  • FIGURE 2 shows a process flow by which each node of the cluster is enabled to securely communicate with any other node of the cluster, whether individually (e.g., unicast communication) or collectively (e.g., multicast
  • the ladder diagram of FIGURE 2 provides an authentication handshake, session key agreement, and cluster key exchange that occurs according to an
  • FIGURE 2 functionality of the process flow illustrated in FIGURE 2 may be implemented in software whereby elements of embodiments of the present invention are essentially code segments operable upon a processor-based or computer system (e.g., network-connected devices 110, 120, and/or 130) to perform the necessary tasks.
  • the program or code segments can be stored in a computer readable medium (e.g., the aforementioned memory of a respective one of network-connected devices 110-130).
  • cluster credentials are injected to establish that network-connected device 110 is a node to be validly included in the cluster. It should be appreciated that various techniques may be implemented for injection of cluster credentials.
  • a user of network- connected device 110 may type a cluster password on a console of the network- connected device during startup, a cluster password may be read from a file secured by various means (e.g., a file stored in memory of a universal serial bus (USB) memory device temporarily attached to the network-connected device), a cluster password may be derived from other, possibly secret, data, etc. Irrespective of the particular technique used for injecting the cluster credentials into the node, once having the appropriate credentials network-connected device 110 may validly join the cluster.
  • a cluster password may be read from a file secured by various means (e.g., a file stored in memory of a universal serial bus (USB) memory device temporarily attached to the network-connected device), a cluster password may be derived from other, possibly secret, data, etc.
  • network-connected device 110 determines that it is the first member in the cluster.
  • Various techniques may be implemented for network-connected device 110 determining whether or not other nodes of the cluster are present. For example, network-connected device 110 may transmit one or more messages via network 101 to query for a response from another cluster node and/or network-connected device 110 may communicate with a management node or other cluster resource (e.g., management console, M-host, etc.) which maintains a database of member nodes.
  • a management node or other cluster resource e.g., management console, M-host, etc.
  • network-connected device 110 may monitor
  • network-connected device 110 of the illustrated embodiment determines that it is the first member of the cluster and thus at process 202 generates a new cluster secret (e.g., cluster key) to be used in securing cluster communications.
  • cluster secret e.g., cluster key
  • a cluster key as utilized according to embodiments herein may be generated using various techniques.
  • a cluster key may be generated using secure and/or random data.
  • Systems often provide a way of generating pseudo-random data, such as may be seeded using data based upon CPU temperature, fan speed, mouse movement, network traffic, etc.
  • pseudo-random data may be utilized in calculating a cryptographic key to be used as a cluster key herein.
  • the cluster key generated according to embodiments of the invention comprises a symmetric key (i.e., provides symmetrical encryption wherein the same cryptographic key provides both encryption and decryption). Accordingly, configuration and maintenance involved in a PKI or managing certificates is avoided with respect to cluster communications using such a cluster key.
  • network-connected device 110 is a member (albeit presently the only member) of the cluster.
  • Network-connected device 110 may operate to announce that it is a member of the cluster, such as by broadcasting one or more messages, communicating with a management node or other cluster resource (e.g., management console, M-host, etc.) which maintains a database of member nodes, etc.
  • a management node or other cluster resource e.g., management console, M-host, etc.
  • network-connected device 120 wishes to join the cluster of which network-connected device 1 10 is presently the only member. Accordingly, at process 203 of the illustrated embodiment cluster credentials are injected to establish that network-connected device 120 is a node to be validly included in the cluster. As discussed above with respect to network-connected device 110, various techniques may be implemented for injection of cluster credentials. Irrespective of the particular technique used for injecting the cluster credentials into the network-connected device, once having the appropriate credentials network-connected device 120 may validly join the cluster.
  • network-connected device 120 determines that there is at least one member already in the cluster. As discussed above with respect to network-connected device 110, various techniques may be implemented for network- connected device 120 determining whether or not other nodes of the cluster are present. Irrespective of how, network-connected device 120 of the illustrated embodiment determines that at least one member is already a member of the cluster and thus at process 204 performs a mutual authentication handshake between network-connected device 120 (joining the cluster) and an existing cluster member (in this case, network- connected device 110) via network 101.
  • the particular cluster node selected by a joining node for performing the mutual authentication herein may be selected based upon any of a number of criteria (e.g., a cluster node which is the oldest member of the cluster, a cluster node which is physically located most near the joining node, a cluster node for which a link having the fewest hops may be used, a cluster node having a lowest utilization, etc.). It should be appreciated that the cluster member selected for use in providing mutual authentication herein may be a peer node of the node joining the cluster.
  • a management node or other centralized cluster resource need not be utilized, but rather peer nodes which are validly part of the cluster (e.g., which have been mutually authenticated, if not the node which initiated the cluster secret, and which are in possession of the cluster secret) may each provide the authentication and cluster joining processing according to embodiments herein.
  • An authentication handshake as implemented according to embodiments of the invention results in mutual authentication of both network- connected device 120 and network-connected device 110.
  • the use of such a mutual authentication handshake ensures that a cluster secret, as provided to valid members of the cluster, and/or credentials or other security information are not provided to an unauthorized network-connected device or other node not validly part of the cluster (e.g., a man-in-the-middle).
  • Various mutual authentication protocols may be utilized in providing the authentication handshake of process 204. Details with respect to one such mutual authentication protocol are provided below with reference to the embodiment illustrated in FIGURE 3.
  • each of network-connected devices 1 10 and 120 are authenticated with respect to the other one of network-connected devices 120 and 110 by operation of the mutual authentication handshake of the illustrated embodiment. If at any time, network- connected device 110 or network-connected device 120 detects an authentication failure, the join process is preferably aborted.
  • both network-connected device 110 and network-connected device 120 derive a session secret (e.g., session key) as part of or in association with the mutual authentication handshake.
  • Session secrets as utilized according to embodiments herein may be generated using various techniques. For example, a session key may be generated from data gathered during the authentication handshake. Details with respect to one such technique for session key generation are provided below with reference to the embodiment illustrated in FIGURE 3.
  • cluster credentials, user derived information, information common to all nodes in the cluster, and other information which may present a detectable pattern or otherwise weaken the security of the separately calculated session secret is not used in deriving the session secret itself.
  • embodiments operate to separately generate a session secret by each of the nodes participating in the mutual authentication handshake so that the session secret (e.g., session key) does not pass over the links joining the nodes (e.g., network 101).
  • session secret e.g., session key
  • process 205 is implemented by network- connected device 110 to calculate the session secret separately from process 206 implemented by network-connected device 120 to calculate the session secret.
  • session secret is utilized according to embodiments of the invention to securely communicate the cluster secret from network-connected device 110 to network-connected device 120 via network 101, assuming the mutual authentication is successful.
  • network-connected device 110 encrypts the cluster secret (e.g. cluster key) using the session secret (e.g., session key) and transmits the encrypted cluster secret to network- connected device 120.
  • the cluster secret e.g. cluster key
  • session secret e.g., session key
  • encryption of a cluster key using a session key at process 207 of embodiments may use AES-128 symmetric key encryption.
  • other cryptographic key algorithms e.g., other symmetric cryptographic key algorithms such as the International Data Encryption Algorithm (IDEA) and CAST- 128
  • Session keys utilized according to embodiments of the invention do not rely on the use of a PKI or certificates in providing authentication of nodes and thus avoid the
  • network-connected device 110 After having transmitted the cluster secret to network-connected device 120, the cluster joining session between network-connected devices 110 and 120 is completed as to network-connected device 110 according to embodiments of the invention and thus network-connected device 110 may then discard the session secret.
  • Network-connected device 110 may operate to update a list of nodes which are validly part of the cluster to include newly joined network-connected device 120, such as for use in later cluster operations, according to embodiments. It should be appreciated that network-connected device 110 may communicate additional information, such as the aforementioned list of nodes which are validly part of the cluster, to network-connected device 120 (e.g., prior to discarding the session secret).
  • Network-connected device 120 of embodiments decrypts the encrypted cluster secret received from network-connected device 110 using the session secret to obtain the cluster secret.
  • the cluster joining session between network-connected devices 110 and 120 is completed as to network- connected device 120 according to embodiments of the invention and thus network- connected device 120 may then discard the session secret.
  • Network-connected device 110 and/or network-connected device 120 may communicate information identifying network-connected device 120 as a cluster node to other nodes of the cluster (e.g., using the cluster secret).
  • network-connected device 120 Having possession of the cluster secret and cluster credentials, network-connected device 120 is a member (presently one of two members) of the cluster. Accordingly, in operation according to embodiments, network-connected device 120 trusts every other member in the cluster, and every other member in the cluster trusts network-connected device 120. Once joined, nodes of the cluster are enabled to communicate with other nodes of the cluster using various messaging techniques including unicast and multicast messaging through use of the cluster secret (e.g., encrypting the messages using a cluster key).
  • various messaging techniques including unicast and multicast messaging through use of the cluster secret (e.g., encrypting the messages using a cluster key).
  • network-connected device 120 has been able to securely obtain the cluster secret that all other nodes of the cluster share and therefore network-connected device 120 may communicate with those nodes either individually (e.g., unicast communication) or collectively (e.g., multicast
  • Encryption of messages using a cluster key at process 208 of embodiments may, for example, use AES-128 symmetric key encryption.
  • other cryptographic key algorithms e.g., other symmetric cryptographic key algorithms such as the International Data Encryption Algorithm (IDEA) and CAST- 128
  • Cluster keys utilized according to embodiments of the invention do not rely on the use of a PKI or certificates in providing authentication of nodes and thus avoid the
  • each node is configured to both be a recipient of a cluster secret, facilitating the node itself to join the cluster, and a source of a cluster secret, facilitating other nodes to join the cluster.
  • a joining node may perform the mutual authentication and cluster secret sharing processes (e.g., perform processes 203-207 of FIGURE 2) with any single node already part of the cluster (e.g., either network-connected device 110 or network-connected device 120) and establish trust and the ability to securely communicate with every node of the cluster (e.g., both network- connected device 110 and network-connected device 120). That is, since every node that has successfully joined the cluster has the cluster secret (e.g., cluster key), any node can communicate with any other node in the cluster.
  • cluster secret e.g., cluster key
  • FIGURE 3 shows details with respect to an embodiment of the process flow of FIGURE 2 providing operation in which each node of the cluster is enabled to securely communicate with any other node of the cluster.
  • the ladder diagram of FIGURE 3 provides details with respect to a mutual authentication protocol and a technique for session key generation as may be utilized according to embodiments of the invention.
  • processes 301-320 of FIGURE 3 provide details with respect to a process flow operable to provide mutual authentication in accordance with processes 204-207 of FIGURE 2 and processes 315 and 319 provide details with respect to a process flow operable to provide separate session secret calculation in accordance with processes 205 and 206 of FIGURE 2.
  • Processes 201-203 and 208 of FIGURE 3 correspond to processes 201-203 and 208 of FIGURE 2 and processes 316, 317, 320 of FIGURE 3 correspond to process 207 of FIGURE 2.
  • functionality of the process flow illustrated in FIGURE 3 may be implemented in software whereby elements of embodiments of the present invention are essentially code segments operable upon a processor-based or computer system (e.g., network-connected devices 110, 120, and/or 130) to perform the necessary tasks.
  • the program or code segments can be stored in a computer readable medium (e.g., the aforementioned memory of a respective one of network-connected devices 110- 130).
  • FIGURE 3 utilizes a modified configuration of the Secure Remote Password protocol version 6a (SRP-6a) in providing mutual authentication and separate session secret calculation.
  • SRP-6a Secure Remote Password protocol version 6a
  • other authentication and key agreement protocols that provide mutual authentication of both parties involved and a shared secret known only to the two parties involved in the handshake may be utilized according to embodiments of the invention.
  • the authentication protocol, key agreement protocols, and encryption algorithms used are presumed to be known to every node a priori
  • embodiments provided in accordance with the concepts herein may operate to dynamically select particular protocols and/or algorithms providing operation herein (e.g., through the nodes exchanging messages to agree upon a common set of protocols and algorithms before the handshake takes place).
  • n and g values of the mutual authentication protocol are known to all nodes beforehand.
  • the values of n and g used in embodiments may be agreed upon by the two parties in question. They can be set in advance or a host can supply them to a client. In the latter case, the host should send the parameters in the first message along with the salt.
  • alternative embodiments operate to return the n and g values (e.g., at process 304).
  • the K value of the mutual authentication protocol shown in the embodiment of FIGURE 3 is used as a session key, and is calculated with a pseudorandom function (PRF) (e.g., the TLSvl protocol, defined in RFC 2246 section 5, the disclosure of which is incorporated herein by reference).
  • PRF pseudorandom function
  • the SRP-6a protocol was designed to be used between a client and a server, whereas the mutual authentication of the process flow illustrated in FIGURE 3 is performed with respect to nodes of a cluster.
  • the server typically stores the verifier (v) derived from the user's password, so that it does not store the user's password but may still operate to validate a client using the user's password.
  • each node to knows the cluster password (e.g., it may be injected by various means as described above) and thus the verifier (v) need not be used to store an obscured version of a user's password in the SRP-6a protocol.
  • the mutual authentication protocol illustrated in FIGURE 3 is modified such that the salt (s) is generated and the verifier (v) is calculated (e.g., the cluster node name, address, or other information uniquely or substantially uniquely identifying the node joining the cluster may be utilized as the username in the calculation) on each authentication attempt (e.g., processes 302 and 303).
  • the foregoing modification facilitates the use of the mutual authentication protocol by any of the nodes of the cluster, rather than its single point (server) use in the client/server model.
  • each node of the cluster is enabled to securely communicate with any other node of the cluster as provided by embodiments discussed above with reference to FIGURES 2 and 3 is not only scalable to any size cluster, but may be readily adapted to provide node attrition management and/or enhanced security protocols.
  • the techniques implemented by the foregoing process flows can be extended to provide periodic cluster key rotation.
  • periodic cluster key rotation after a period of time has elapsed, a new cluster key is generated by a node, and every other node is made to reauthenticate to obtain the new cluster key.
  • the new cluster key is not distributed to other nodes using the current cluster key because, if a hacker or other unauthorized node has the current cluster key, the hacker or unauthorized node could simply decrypt and obtain the new cluster key.
  • Such periodic cluster key rotation reduces the possible number of messages that can be decrypted if a hacker or other unauthorized node were to obtain or retain the cluster key, thereby providing enhanced security.
  • the concepts of the foregoing periodic cluster key rotation may be utilized with respect to nodes leaving the cluster to thereby provide node attrition management.
  • a node leaving the cluster leaves open the possibility that the node that left the cluster would still be able to decrypt cluster messages. Accordingly, in operation according to an embodiment of cluster key regeneration, after a node leaves the cluster, a new cluster key is generated by a node, and every other node is made to reauthenticate to obtain the new cluster key.
  • a new cluster secret (e.g., cluster password) may be injected into the remaining nodes, without providing it to the node that left the cluster.
  • Techniques for providing enhanced security may place additional restrictions on the nodes allowed to join the cluster. For example, a roster of allowed nodes could be maintained. Any node attempting to join the cluster may both have to be present in this roster and complete the mutual authentication handshake in order to join the cluster.
  • enhanced security techniques herein may operate to lock that network-connected device out of the mutual authentication process for a length of time before being allowed to re- attempt mutual authentication.
  • authentication failure lockout information is preferably shared between the nodes of the cluster (e.g., using a cluster state of how many times a particular node has attempted to authenticate, using multicast communication facilitated through use of a cluster key, etc.). Such an authentication failure lockout technique prevents an active dictionary attack.
  • each node of the cluster is enabled to securely communicate with any other node of the cluster as provided by embodiments discussed above with reference to FIGURES 2 and 3 is not only readily adaptable to provide node attrition management and/or enhanced security protocols, but may also be readily adapted to facilitate operation in a number of different environments and/or scenarios. For example, after a node joins the cluster, encryption of messages with a cluster key could be selective to improve performance (e.g., in an environment where nodes having limited processing power are used).
  • a message if a message is deemed to contain no sensitive material, it need not be encrypted, although some method (e.g., digital signature algorithms and/or other security techniques) to prevent tampering with better performance could then be employed.
  • some method e.g., digital signature algorithms and/or other security techniques
  • encryption using a cluster key could be turned off completely.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Storage Device Security (AREA)
  • Computer And Data Communications (AREA)

Abstract

Systems and methods which facilitate secure multicast communications between any valid node of a cluster using authentication between a node joining the cluster and any single node which is validly part of the cluster are disclosed. In accordance with embodiments, a cluster key is utilized to provide security with respect to intra-cluster communications. The cluster key of embodiments is shared by a node which is already part of the cluster with a node joining the cluster only after these two nodes mutually authenticate one another. The mutual authentication handshake of embodiments implements a protocol in which a session key is calculated by both nodes, thereby providing a secure means by which a cluster key may be shared. Having the cluster key, each node of the cluster is enabled to securely communicate with any other node of the cluster, whether individually (e.g., unicast) or collectively (e.g., multicast), according to embodiments.

Description

SYSTEMS AND METHODS FOR PROVIDING SECURE MULTICAST INTRA-
CLUSTER COMMUNICATION
TECHNICAL FIELD
[0001] The present invention relates generally to intra-cluster communication and, more particularly, to providing secure multicast intra-cluster communication.
BACKGROUND OF THE INVENTION
[0002] Various system configurations exist in which a cluster of different nodes communicate with each other, wherein a node is an operating unit (e.g., a processor-based system), operable to provide a desired function, service, or operation, or portion thereof, and which may cooperate with other nodes to form a cluster. For example, data storage systems often include a plurality of storage devices present at different nodes of the data storage system. Such a data storage system may be implemented using a variety of storage architectures, such as a network-attached storage (NAS) environment, a storage area network (SAN), a direct-attached storage
environment, and combinations thereof. Nodes of a data storage system may comprise processor-based systems, such as a file server system, a computer appliance, a computer workstation, etc. Storage devices at the different nodes may comprise disk drives, flash memory, optical memory, etc. Selected ones of the storage devices may be organized as a storage array in accordance with the storage architecture. Nodes hosting the storage devices of a storage array as well as other network-connected devices may thus comprise a cluster of nodes operable cooperatively to provide a data storage system.
[0003] In order to operate as a cluster, nodes of a cluster communicate with each other. Such communication may include various point-to-point communications (e.g., single node to single node or unicast communication) and multicast
communications (e.g., single node to multiple node). Accordingly, to effectively cooperate to provide desired operation each node of a cluster may need to have the capability to communicate with any and all other nodes of the cluster. Such
communication, however, may traverse unsecured links, such as public or other network links (e.g., the Internet, the public switched telephone network (PSTN), a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), etc.). Such communications carried through such unsecured links may be susceptible to interception, eavesdropping, tampering, monitoring, sniffing, man-in-the-middle attack, relay attack, replay attack, etc.
[0004] Accordingly, various security protocols have been implemented in the past to facilitate communication between nodes of a cluster (i.e., intra-cluster communication). For example, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) security protocols have been implemented by nodes of a cluster for securing intra-cluster communication. SSL and TLS are cryptographic protocols that provide communication security using asymmetric cryptography for privacy and a keyed message authentication code for message reliability. These security protocols, however, are point-to-point security protocols. That is, unique key sets are utilized with respect to each node pair. Accordingly, secure multicast communication is not provided through the use of SSL and TLS security protocols.
[0005] Although protocols have been developed which provide for securing multicast communications, such protocols heretofore have not provided sufficient security with respect to multicast communications and have not adequately accommodated dynamic association of nodes with clusters. One such protocol which has been used to provide security for communications is JGROUPS. JGROUPS provides a multicast protocol in which a "grouping" layer is added over a transport protocol. To provide security with respect to the multicast communications, JGROUPS implements its AUTH and ENCRYPT protocols. The AUTH protocol, however only provides one way authentication (i.e., only one node authenticates the other) using a single token-based authentication (e.g., password or other authentication credentials communicated over the unsecured link), thus an eavesdropper can monitor the communications and mimic the security handshake (e.g., replay attack) to establish a false authentication. The
ENCRYPT protocol uses a clusterKey to encrypt all multicast communications. The clusterKey of the ENCRYPT protocol, however, is provided to any node which provides its own public key and requests the clusterKey. Accordingly, even with AUTH and ENCRYPT protocols implemented by JGROUPS, a man-in-the-middle may easily join the cluster and thus the security provided with respect to multicast communications is somewhat illusory.
BRIEF SUMMARY OF THE INVENTION
[0006] The present invention is directed to systems and methods which facilitate secure multicast communications between any valid node of a cluster using authentication between a node joining the cluster and any single node which is validly part of the cluster. In accordance with embodiments of the invention, a cluster key (e.g., a symmetrical cryptographic key) is utilized to provide security with respect to intra- cluster communications. The cluster key of embodiments is shared by a node which is already part of the cluster with a node joining the cluster only after these two nodes mutually authenticate one another. The mutual authentication handshake of
embodiments implements or is otherwise associated with a protocol in which a session key is calculated by both nodes, thereby facilitating a secure link between the nodes without the session key having been communicated over a network or other link. The session key is used to securely share the cluster key with the node joining the cluster by the node which is already part of the cluster after these two nodes mutually authenticate one another according to embodiments of the invention. Having the cluster key, each node of the cluster is enabled to securely communicate with any other node of the cluster, whether individually (e.g., unicast communication) or collectively (e.g., multicast communication).
[0007] From the foregoing it can be appreciated that embodiments of the invention facilitate nodes joining a cluster by authenticating against any node in the cluster. Embodiments of the invention do not rely on the use of a public key
infrastructure (PKI) or certificates in providing authentication of nodes. Accordingly, the configuration and maintenance involved in a PKI or managing certificates is avoided. Embodiments herein, however, may utilize available authentication protocols, key agreement protocols, and/or encryption algorithms or portions thereof, albeit in a new methodology tailored or otherwise adapted for use in a cluster environment for multicast communication, to thereby leverage well tested and thoroughly documented base technologies. [0008] Once authenticated, trust with respect to a joined node is established with the entire cluster of nodes. That is, the node joining the cluster essentially authenticates to the cluster as a logical unit in order to join. Thus, it is not necessary that the node joining the cluster authenticate against every node, or even more than one node, in the cluster according to embodiments herein, as would be required in an approach implementing a point-to-point type protocol. Once joined, nodes of the cluster are enabled to communicate with other nodes of the cluster using various messaging techniques including unicast and multicast messaging. In contrast to the operation of embodiments of the present invention, multicast communication techniques are not easily implemented in point-to-point type protocols.
[0009] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.
BRIEF DESCRIPTION OF THE DRAWING
[0010] For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which: [0011] FIGURES 1 A and IB show block diagrams of systems adapted to enable each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention;
[0012] FIGURE 2 shows a ladder diagram of a high level process flow enabling each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention;
[0013] FIGURE 3 shows a ladder diagram of a more detailed process flow enabling each node of a cluster to securely communicate with any other node of the cluster according to embodiments of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0014] A brief description of the meaning of particular terms as used herein is provided below in order to aid the reader in better understanding the concepts of the invention as described in the discussion which follows. Although the following provides general meanings with respect to particular terms, it should be appreciated that additional meaning with respect to certain of the terms herein may be provided in the context of particular embodiments discussed below.
[0015] A cluster as used herein is a group of linked or otherwise associated nodes operable together to provide a desired function, service, or operation thereby, in many respects, forming a single logical entity. A node is a network-connected device operating unit, such as a processor-based system (e.g., computer, network appliance, etc.) and associated instruction set (e.g., software, firmware, application, etc.), operable to provide a desired function, service, or operation, or portion thereof, and which may cooperate with other nodes to form a cluster. Intra-cluster communication is
communication, such as unicast communication and multicast communication, between two or more nodes of a cluster. Unicast communication is the sending of one or more message or information to a single network destination (e.g., node). Multicast communication is the sending of one or more message or information to a plurality of network destinations (e.g., nodes) by a single transmission. [0016] As used herein, authentication is the process of one party (e.g., node) confirming the identity of another party (e.g., another node) whereas mutual authentication is the process of two parties (e.g., nodes) confirming the identity of each other. An authentication handshake is the dialog of messages between two parties (e.g., nodes) trying to authenticate one or the other (authentication) or both (mutual authentication). A key agreement protocol is a protocol whereby two or more parties (e.g., nodes) can agree on a key (e.g., cryptographic key used in encryption and/or decryption of data) in such a way that both influence the outcome, thereby facilitating separate calculation of a unique key (e.g., session key) without the need to communicate the unique key between the parties and thus avoiding eavesdropping and tampering. Eavesdropping is when a third party (e.g., node which is not part of a cluster) observes communication without the consent and/or knowledge of the parties (e.g., nodes of the cluster) involved in the communication. Tampering is when a third party (e.g., network- connected device which is not part of a cluster) changes or otherwise alters data while it is in-flight between communicating parties (e.g., nodes of the cluster) without the knowledge of the parties involved in the communication. Encryption is the process of transforming information (referred to as plaintext prior to encryption) using an algorithm (called cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key (e.g., cryptographic key), whereas decryption is the process of transforming encrypted information back to plaintext.
[0017] Directing attention to FIGURE 1 A, system 100 is shown comprising a plurality of network-connected devices, shown as network-connected devices 110-130, coupled via network 101. Network-connected devices 110-130 may comprise processor-based systems, such as a file server system, a computer appliance, a computer workstation, etc. Accordingly, network-connected devices 110-130 of embodiments comprise a processor (e.g., central processing unit (CPU), application specific integrated circuit (ASIC), programmable gate array (PGA), etc.), memory (e.g., random access memory (RAM), read only memory (ROM), disk memory, optical memory, flash memory, etc.), and suitable input/output circuitry (e.g., network interface card (NIC), wireless network interface, display, keyboard, data bus, etc.). The foregoing processor-based systems may operate under control of an instruction set (e.g., software, firmware, applet, code, etc.) providing operation as described herein. Network 101 may comprise various forms of communication infrastructure, such as the Internet, the PSTN, a LAN, a MAN, a WAN, a wireless network (e.g., a cellular communication network, a wireless LAN, etc.), and/or the like.
[0018] Various configurations of system 100 may be provided in which one or more cluster of nodes is formed from network-connected devices 1 10 and 120 to thereby provide a cluster environment, wherein cooperative operation of the cluster is facilitated through communication between the nodes of the cluster. For example, a data storage system may be formed from network-connected devices 110-130, wherein one or more storage device (e.g., storage devices 114 and 124) present at network-connected devices 110 and 120 (e.g., disk drive, flash memory, optical memory, etc.) cooperate to provide a volume accessible to network-connected device 130. Network-connected devices 110 and 120 hosting storage devices of a storage array and client network- connected device 130 may thus comprise a cluster of nodes operable cooperatively to provide a data storage system.
[0019] FIGURE IB provides a block diagram in which additional detail with respect to embodiments of system 100 adapted to enable each node of a cluster to securely communicate with any other node of the cluster. As stated above, system 100 may comprise two or more interconnected, such as network-connected devices 110 and 120 configured to provide access to data stored on a set of storage devices (shown as storage devices 114 and 124) constituting storage of system 100. Storage services may be provided by such nodes implementing various functional components that cooperate to provide a distributed storage system architecture of system 100.
[0020] Illustratively, nodes (e.g., network-connected devices 110 and 120) may be organized as one or more network elements (N-modules 112 and 122) and/or storage elements (D-modules 113 and 123) and a management element (M-host 111 and 121). N-modules may include functionality to enable nodes to connect to one or more clients (e.g., network-connected device 130) over computer network 101, while D- modules may connect to storage devices (e.g., as may implement a storage array). M- hosts may provide cluster communication services between nodes for generating information sharing operations and for presenting a distributed file system image for system 100. Functionality for enabling each node of a cluster to securely communicate with any other node of the cluster may be provided by M-hosts adapted according to embodiments of the invention.
[0021] It should be appreciated that network 101 may comprise various forms, and even separate portions, of network infrastructure. For example, network- connected devices 110 and 120 may be interconnected by cluster switching fabric 102 while network-connected devices 110 and 120 may be interconnected to network - connected device 130 by a more general data network (e.g., the Internet, a LAN, etc.).
[0022] It should also be noted that while there is shown an equal number of N and D-modules constituting illustrated embodiments of nodes, there may be a different number and/or type of functional components embodying nodes in accordance with various embodiments of the present invention. For example, there may be multiple N- modules and/or D-modules interconnected in system 100 that do not reflect a one-to-one correspondence between the modules of network-connected devices 110 and 120.
Accordingly, the description of network-connected devices 110 and 120 comprising one N- and one D-module should be taken as illustrative only and it will be understood that the novel technique is not limited to the illustrative embodiment discussed herein.
[0023] Network-connected device 130 may be a general -purpose computer configured to interact with network-connected devices 110 and 120 in accordance with a client/server model of information delivery. To that end, network-connected device 130 may request the services of network-connected devices 110 and 120 by submitting a read or write request to the cluster node comprising the network-connected device. In response to the request, the node may return the results of the requested services by exchanging information packets over network 101. Network-connected device 130 may submit access requests by issuing packets using object-based access protocols, such as the Common Internet File System (CIFS) protocol, Network File System (NFS) protocol, Small Computer Systems Interface (SCSI) protocol encapsulated over TCP (iSCSI), and SCSI encapsulated over Fibre Channel (FCP) for instance. Preferably, network- connected devices 110 and 120 may implement a combination of file-based and block- based protocols to communicate with network-connected device 130. [0024] System 100 may further include a management console (shown here as management console 150) for providing management services for the overall cluster. Management console 150 may, for instance, communicate with network-connected devices 110 and 120 across network 101 to request operations to be performed at the cluster nodes comprised of the network-connected devices, and to request information (e.g., node configurations, operating metrics) from or provide information to the nodes. In addition, management console 150 may be configured to receive inputs from and provide outputs to a user of system 100 (e.g., storage administrator) thereby operating as a centralized management interface between the administrator and system 100. In the illustrative embodiment, management console 150 may be networked to network- connected devices 110-130, although other embodiments of the present invention may implement management console 150 as a functional component of a node or any other processing system connected to or constituting system 100.
[0025] In a distributed architecture, network-connected device 130 may submit an access request to a node for data stored at a remote node. As an example, an access request from network-connected device 130 may be sent to network-connected device 120 which may target a storage object (e.g., volume) on network-connected device 110 in storage 114. To accelerate servicing of the access request and optimize cluster performance, network-connected device 120 may cache the requested volume in local memory or in storage 124. For instance, during initialization of network-connected device 120 as a cluster node, network-connected device 120 may request all or a portion of the volume from network-connected device 110 for storage at network-connected device 120 prior to an actual request by network-connected device 130 for such data.
[0026] As can be appreciated from the foregoing, in order to operate as a cluster (e.g., the aforementioned data storage system), network-connected devices 110- 130 may communicate with each other. Such communication may include various forms of communication (e.g., point-to-point or unicast communication, multicast
communication, etc.). Accordingly, to effectively cooperate to provide desired operation as a logical entity each node of a cluster is provided with the capability to communicate with any and all other nodes of the cluster according to embodiments of the invention. However, as network 101 may provide unsecured links, and thus such communications may be susceptible to interception, eavesdropping, tampering, monitoring, sniffing, man- in-the-middle attack, relay attack, replay attack, etc., embodiments of the invention provide secure communications (e.g., unicast and multicast) between any valid node of a cluster using authentication between a node joining the cluster and any single node which is validly part of the cluster.
[0027] In facilitating secure communications in which a node joining the cluster authenticates to the cluster as a logical unit in order to join, and thus secure communication may be provided between the joining node and any other valid node of the cluster, operation according to embodiments of the invention performs a mutual authentication session between a node joining the cluster and any single node validly part of the cluster. If the mutual authentication is successful, operation according to the embodiment communicates a cluster secret (e.g., cluster key) to the node joining the cluster using a secure communication channel unique to the mutual authentication session (e.g., using a session key calculated in association with the mutual
authentication). In accordance with embodiments of the invention, possession of the cluster secret and the cluster credentials renders the node joining the cluster a cluster node and the cluster secret enables the cluster node to securely communicate with every other node which is validly part of the cluster.
[0028] FIGURE 2 shows a process flow by which each node of the cluster is enabled to securely communicate with any other node of the cluster, whether individually (e.g., unicast communication) or collectively (e.g., multicast
communication) without the node joining the cluster authenticating against every node, or even more than one node, in the cluster according to embodiments herein. In particular, the ladder diagram of FIGURE 2 provides an authentication handshake, session key agreement, and cluster key exchange that occurs according to an
embodiment when a new node (e.g., network-connected device 120) joins a cluster in which another node (e.g., network-connected device 110) is the first member. It should be appreciated that functionality of the process flow illustrated in FIGURE 2 may be implemented in software whereby elements of embodiments of the present invention are essentially code segments operable upon a processor-based or computer system (e.g., network-connected devices 110, 120, and/or 130) to perform the necessary tasks. The program or code segments can be stored in a computer readable medium (e.g., the aforementioned memory of a respective one of network-connected devices 110-130).
[0029] In accordance with the illustrated embodiment, it is assumed that each node which is to be validly part of a cluster possess cluster credentials (e.g., a cluster password). Accordingly, at process 201 of the illustrated embodiment cluster credentials are injected to establish that network-connected device 110 is a node to be validly included in the cluster. It should be appreciated that various techniques may be implemented for injection of cluster credentials. For example, a user of network- connected device 110 may type a cluster password on a console of the network- connected device during startup, a cluster password may be read from a file secured by various means (e.g., a file stored in memory of a universal serial bus (USB) memory device temporarily attached to the network-connected device), a cluster password may be derived from other, possibly secret, data, etc. Irrespective of the particular technique used for injecting the cluster credentials into the node, once having the appropriate credentials network-connected device 110 may validly join the cluster.
[0030] At process 202 network-connected device 110 determines that it is the first member in the cluster. Various techniques may be implemented for network- connected device 110 determining whether or not other nodes of the cluster are present. For example, network-connected device 110 may transmit one or more messages via network 101 to query for a response from another cluster node and/or network-connected device 110 may communicate with a management node or other cluster resource (e.g., management console, M-host, etc.) which maintains a database of member nodes.
Additionally or alternatively, network-connected device 110 may monitor
communications on network 101 to identify the presence of cluster communication traffic. Irrespective of how, network-connected device 110 of the illustrated embodiment determines that it is the first member of the cluster and thus at process 202 generates a new cluster secret (e.g., cluster key) to be used in securing cluster communications.
[0031] A cluster key as utilized according to embodiments herein may be generated using various techniques. For example, a cluster key may be generated using secure and/or random data. Systems often provide a way of generating pseudo-random data, such as may be seeded using data based upon CPU temperature, fan speed, mouse movement, network traffic, etc. Such pseudo-random data may be utilized in calculating a cryptographic key to be used as a cluster key herein. The cluster key generated according to embodiments of the invention comprises a symmetric key (i.e., provides symmetrical encryption wherein the same cryptographic key provides both encryption and decryption). Accordingly, configuration and maintenance involved in a PKI or managing certificates is avoided with respect to cluster communications using such a cluster key.
[0032] Having possession of the cluster secret and cluster credentials, network-connected device 110 is a member (albeit presently the only member) of the cluster. Network-connected device 110 may operate to announce that it is a member of the cluster, such as by broadcasting one or more messages, communicating with a management node or other cluster resource (e.g., management console, M-host, etc.) which maintains a database of member nodes, etc.
[0033] In the embodiment illustrated in FIGURE 2, network-connected device 120 wishes to join the cluster of which network-connected device 1 10 is presently the only member. Accordingly, at process 203 of the illustrated embodiment cluster credentials are injected to establish that network-connected device 120 is a node to be validly included in the cluster. As discussed above with respect to network-connected device 110, various techniques may be implemented for injection of cluster credentials. Irrespective of the particular technique used for injecting the cluster credentials into the network-connected device, once having the appropriate credentials network-connected device 120 may validly join the cluster.
[0034] At process 204 network-connected device 120 determines that there is at least one member already in the cluster. As discussed above with respect to network-connected device 110, various techniques may be implemented for network- connected device 120 determining whether or not other nodes of the cluster are present. Irrespective of how, network-connected device 120 of the illustrated embodiment determines that at least one member is already a member of the cluster and thus at process 204 performs a mutual authentication handshake between network-connected device 120 (joining the cluster) and an existing cluster member (in this case, network- connected device 110) via network 101. The particular cluster node selected by a joining node for performing the mutual authentication herein may be selected based upon any of a number of criteria (e.g., a cluster node which is the oldest member of the cluster, a cluster node which is physically located most near the joining node, a cluster node for which a link having the fewest hops may be used, a cluster node having a lowest utilization, etc.). It should be appreciated that the cluster member selected for use in providing mutual authentication herein may be a peer node of the node joining the cluster. That is, a management node or other centralized cluster resource need not be utilized, but rather peer nodes which are validly part of the cluster (e.g., which have been mutually authenticated, if not the node which initiated the cluster secret, and which are in possession of the cluster secret) may each provide the authentication and cluster joining processing according to embodiments herein.
[0035] An authentication handshake as implemented according to embodiments of the invention results in mutual authentication of both network- connected device 120 and network-connected device 110. The use of such a mutual authentication handshake ensures that a cluster secret, as provided to valid members of the cluster, and/or credentials or other security information are not provided to an unauthorized network-connected device or other node not validly part of the cluster (e.g., a man-in-the-middle). Various mutual authentication protocols may be utilized in providing the authentication handshake of process 204. Details with respect to one such mutual authentication protocol are provided below with reference to the embodiment illustrated in FIGURE 3. Irrespective of the particular mutual authentication protocol implemented, each of network-connected devices 1 10 and 120 are authenticated with respect to the other one of network-connected devices 120 and 110 by operation of the mutual authentication handshake of the illustrated embodiment. If at any time, network- connected device 110 or network-connected device 120 detects an authentication failure, the join process is preferably aborted.
[0036] In operation according to embodiments of the invention, both network-connected device 110 and network-connected device 120 derive a session secret (e.g., session key) as part of or in association with the mutual authentication handshake. Session secrets as utilized according to embodiments herein may be generated using various techniques. For example, a session key may be generated from data gathered during the authentication handshake. Details with respect to one such technique for session key generation are provided below with reference to the embodiment illustrated in FIGURE 3. In operation according to embodiments of the invention cluster credentials, user derived information, information common to all nodes in the cluster, and other information which may present a detectable pattern or otherwise weaken the security of the separately calculated session secret is not used in deriving the session secret itself. Irrespective of the particular technique used in generating session secrets, embodiments operate to separately generate a session secret by each of the nodes participating in the mutual authentication handshake so that the session secret (e.g., session key) does not pass over the links joining the nodes (e.g., network 101).
Accordingly, in the illustrated embodiment process 205 is implemented by network- connected device 110 to calculate the session secret separately from process 206 implemented by network-connected device 120 to calculate the session secret.
[0037] The foregoing session secret is utilized according to embodiments of the invention to securely communicate the cluster secret from network-connected device 110 to network-connected device 120 via network 101, assuming the mutual authentication is successful. Accordingly, at process 207 of the illustrated embodiment network-connected device 110 encrypts the cluster secret (e.g. cluster key) using the session secret (e.g., session key) and transmits the encrypted cluster secret to network- connected device 120. For example, encryption of a cluster key using a session key at process 207 of embodiments may use AES-128 symmetric key encryption. However, other cryptographic key algorithms (e.g., other symmetric cryptographic key algorithms such as the International Data Encryption Algorithm (IDEA) and CAST- 128
cryptographic algorithms) may be used according to embodiments of the invention. Session keys utilized according to embodiments of the invention do not rely on the use of a PKI or certificates in providing authentication of nodes and thus avoid the
configuration and maintenance involved in a PKI or certificate management.
[0038] After having transmitted the cluster secret to network-connected device 120, the cluster joining session between network-connected devices 110 and 120 is completed as to network-connected device 110 according to embodiments of the invention and thus network-connected device 110 may then discard the session secret. Network-connected device 110 may operate to update a list of nodes which are validly part of the cluster to include newly joined network-connected device 120, such as for use in later cluster operations, according to embodiments. It should be appreciated that network-connected device 110 may communicate additional information, such as the aforementioned list of nodes which are validly part of the cluster, to network-connected device 120 (e.g., prior to discarding the session secret). Network-connected device 120 of embodiments decrypts the encrypted cluster secret received from network-connected device 110 using the session secret to obtain the cluster secret. After having decrypted the cluster secret received from network-connected device 110, the cluster joining session between network-connected devices 110 and 120 is completed as to network- connected device 120 according to embodiments of the invention and thus network- connected device 120 may then discard the session secret. Network-connected device 110 and/or network-connected device 120 may communicate information identifying network-connected device 120 as a cluster node to other nodes of the cluster (e.g., using the cluster secret).
[0039] Having possession of the cluster secret and cluster credentials, network-connected device 120 is a member (presently one of two members) of the cluster. Accordingly, in operation according to embodiments, network-connected device 120 trusts every other member in the cluster, and every other member in the cluster trusts network-connected device 120. Once joined, nodes of the cluster are enabled to communicate with other nodes of the cluster using various messaging techniques including unicast and multicast messaging through use of the cluster secret (e.g., encrypting the messages using a cluster key). That is, network-connected device 120 has been able to securely obtain the cluster secret that all other nodes of the cluster share and therefore network-connected device 120 may communicate with those nodes either individually (e.g., unicast communication) or collectively (e.g., multicast
communication) using the cluster secret. Thus, future communication to/from any members in the cluster are secured using the cluster secret (e.g., encrypted with the cluster key) as represented by process 208 of the illustrated embodiment. [0040] Encryption of messages using a cluster key at process 208 of embodiments may, for example, use AES-128 symmetric key encryption. However, other cryptographic key algorithms (e.g., other symmetric cryptographic key algorithms such as the International Data Encryption Algorithm (IDEA) and CAST- 128
cryptographic algorithms) may be used according to embodiments of the invention. Cluster keys utilized according to embodiments of the invention do not rely on the use of a PKI or certificates in providing authentication of nodes and thus avoid the
configuration and maintenance involved in a PKI or certificate management.
[0041] It should be appreciated that once authenticated with any node of the cluster, as described above, trust with respect to a joined node is established with the entire cluster of nodes. Thus, it is not necessary that a node joining the cluster authenticate against every node, or even more than one node, in the cluster according to embodiments herein. That is, the mutual authentication techniques as implemented according to embodiments herein provide a configuration in which each node is configured to both be a recipient of a cluster secret, facilitating the node itself to join the cluster, and a source of a cluster secret, facilitating other nodes to join the cluster.
Accordingly, when a third node (e.g., a network-connected device similar to network- connected devices 110 and 120 of FIGURE 1 A) is to join the cluster formed to comprise network-connected devices 110 and 120 in FIGURE 2, such a joining node may perform the mutual authentication and cluster secret sharing processes (e.g., perform processes 203-207 of FIGURE 2) with any single node already part of the cluster (e.g., either network-connected device 110 or network-connected device 120) and establish trust and the ability to securely communicate with every node of the cluster (e.g., both network- connected device 110 and network-connected device 120). That is, since every node that has successfully joined the cluster has the cluster secret (e.g., cluster key), any node can communicate with any other node in the cluster. This allows unicast and multicast messages to be used for intra-cluster communication. As can be appreciated from the foregoing, the nodes are provided with multicast communication ability with only authenticating a single node in a cluster, as opposed to authenticating to every node in the cluster. This approach can scale to any size cluster. [0042] FIGURE 3 shows details with respect to an embodiment of the process flow of FIGURE 2 providing operation in which each node of the cluster is enabled to securely communicate with any other node of the cluster. Specifically, the ladder diagram of FIGURE 3 provides details with respect to a mutual authentication protocol and a technique for session key generation as may be utilized according to embodiments of the invention. Accordingly, processes 301-320 of FIGURE 3 provide details with respect to a process flow operable to provide mutual authentication in accordance with processes 204-207 of FIGURE 2 and processes 315 and 319 provide details with respect to a process flow operable to provide separate session secret calculation in accordance with processes 205 and 206 of FIGURE 2. Processes 201-203 and 208 of FIGURE 3 correspond to processes 201-203 and 208 of FIGURE 2 and processes 316, 317, 320 of FIGURE 3 correspond to process 207 of FIGURE 2. As with the process flow of FIGURE 2, functionality of the process flow illustrated in FIGURE 3 may be implemented in software whereby elements of embodiments of the present invention are essentially code segments operable upon a processor-based or computer system (e.g., network-connected devices 110, 120, and/or 130) to perform the necessary tasks. The program or code segments can be stored in a computer readable medium (e.g., the aforementioned memory of a respective one of network-connected devices 110- 130).
[0043] The embodiment illustrated in FIGURE 3 utilizes a modified configuration of the Secure Remote Password protocol version 6a (SRP-6a) in providing mutual authentication and separate session secret calculation. However, other authentication and key agreement protocols that provide mutual authentication of both parties involved and a shared secret known only to the two parties involved in the handshake may be utilized according to embodiments of the invention. Although the authentication protocol, key agreement protocols, and encryption algorithms used are presumed to be known to every node a priori, embodiments provided in accordance with the concepts herein may operate to dynamically select particular protocols and/or algorithms providing operation herein (e.g., through the nodes exchanging messages to agree upon a common set of protocols and algorithms before the handshake takes place). [0044] In operation according to embodiments of the process flow illustrated in FIGURE 3, the n and g values of the mutual authentication protocol are known to all nodes beforehand. For example, the values of n and g used in embodiments may be agreed upon by the two parties in question. They can be set in advance or a host can supply them to a client. In the latter case, the host should send the parameters in the first message along with the salt. For maximum security n should be a safe prime (e.g., a number of the form n = 2q + 1 , where q is also prime). Also, g should be a generator modulo n, which means that for any x where o < x < n, there exist a value x for which gAx % n== x. However, alternative embodiments operate to return the n and g values (e.g., at process 304).
[0045] The K value of the mutual authentication protocol shown in the embodiment of FIGURE 3 is used as a session key, and is calculated with a pseudorandom function (PRF) (e.g., the TLSvl protocol, defined in RFC 2246 section 5, the disclosure of which is incorporated herein by reference). Any number of algorithms capable of expanding one secret (S) into another (K), however, may be utilized in calculating a session key according to embodiments of the invention.
[0046] It should be appreciated that the SRP-6a protocol was designed to be used between a client and a server, whereas the mutual authentication of the process flow illustrated in FIGURE 3 is performed with respect to nodes of a cluster. In the client/server environment, the server typically stores the verifier (v) derived from the user's password, so that it does not store the user's password but may still operate to validate a client using the user's password. In the cluster implementation of the illustrated embodiment, each node to knows the cluster password (e.g., it may be injected by various means as described above) and thus the verifier (v) need not be used to store an obscured version of a user's password in the SRP-6a protocol. Therefore, the mutual authentication protocol illustrated in FIGURE 3 is modified such that the salt (s) is generated and the verifier (v) is calculated (e.g., the cluster node name, address, or other information uniquely or substantially uniquely identifying the node joining the cluster may be utilized as the username in the calculation) on each authentication attempt (e.g., processes 302 and 303). Although necessitating the calculation of the verifier (v) on each authentication attempt, and thus placing burdens on processing power not well suited for the heavy demands of a server environment, the foregoing modification facilitates the use of the mutual authentication protocol by any of the nodes of the cluster, rather than its single point (server) use in the client/server model.
[0047] It should be appreciated that operation in which each node of the cluster is enabled to securely communicate with any other node of the cluster as provided by embodiments discussed above with reference to FIGURES 2 and 3 is not only scalable to any size cluster, but may be readily adapted to provide node attrition management and/or enhanced security protocols. For example, the techniques implemented by the foregoing process flows can be extended to provide periodic cluster key rotation. In operation according to an embodiment of periodic cluster key rotation, after a period of time has elapsed, a new cluster key is generated by a node, and every other node is made to reauthenticate to obtain the new cluster key. Note that the new cluster key is not distributed to other nodes using the current cluster key because, if a hacker or other unauthorized node has the current cluster key, the hacker or unauthorized node could simply decrypt and obtain the new cluster key. Such periodic cluster key rotation reduces the possible number of messages that can be decrypted if a hacker or other unauthorized node were to obtain or retain the cluster key, thereby providing enhanced security.
[0048] The concepts of the foregoing periodic cluster key rotation may be utilized with respect to nodes leaving the cluster to thereby provide node attrition management. A node leaving the cluster leaves open the possibility that the node that left the cluster would still be able to decrypt cluster messages. Accordingly, in operation according to an embodiment of cluster key regeneration, after a node leaves the cluster, a new cluster key is generated by a node, and every other node is made to reauthenticate to obtain the new cluster key. To prevent the node that left the cluster from eavesdropping on the mutual authentication handshakes in a cluster key regeneration implementation, and thus deriving the regenerated cluster key, a new cluster secret (e.g., cluster password) may be injected into the remaining nodes, without providing it to the node that left the cluster. [0049] Techniques for providing enhanced security may place additional restrictions on the nodes allowed to join the cluster. For example, a roster of allowed nodes could be maintained. Any node attempting to join the cluster may both have to be present in this roster and complete the mutual authentication handshake in order to join the cluster.
[0050] Where a particular network-connected device fails to authenticate a certain number of times (e.g., 5) within a certain time period (e.g., 1 hour), then enhanced security techniques herein may operate to lock that network-connected device out of the mutual authentication process for a length of time before being allowed to re- attempt mutual authentication. Because each node of the cluster has the ability to mutually authenticate a node joining the cluster, authentication failure lockout information is preferably shared between the nodes of the cluster (e.g., using a cluster state of how many times a particular node has attempted to authenticate, using multicast communication facilitated through use of a cluster key, etc.). Such an authentication failure lockout technique prevents an active dictionary attack.
[0051] It should be appreciated that operation in which each node of the cluster is enabled to securely communicate with any other node of the cluster as provided by embodiments discussed above with reference to FIGURES 2 and 3 is not only readily adaptable to provide node attrition management and/or enhanced security protocols, but may also be readily adapted to facilitate operation in a number of different environments and/or scenarios. For example, after a node joins the cluster, encryption of messages with a cluster key could be selective to improve performance (e.g., in an environment where nodes having limited processing power are used). In one such embodiment, if a message is deemed to contain no sensitive material, it need not be encrypted, although some method (e.g., digital signature algorithms and/or other security techniques) to prevent tampering with better performance could then be employed. In an environment where the network is secured by other means (e.g. IPSec, or a secure segregated network), then encryption using a cluster key could be turned off completely.
[0052] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

CLAIMS What is claimed is:
1. A method for providing secure multicast communication capabilities to a plurality of nodes of a cluster, the method comprising:
performing a mutual authentication session between a node joining the cluster and any single node validly part of the cluster; and
if the mutual authentication is successful, communicating a cluster secret to the node joining the cluster using a secure communication channel unique to the mutual authentication session, wherein the cluster secret renders the node joining the cluster a cluster node and enables the cluster node to securely communicate with every other node which is validly part of the cluster.
2. The method of claim 1 , wherein the node joining the cluster is rendered a cluster node after performing the mutual authentication session only with the single node validly part of the cluster.
3. The method of claim 1, wherein the single node validly part of the cluster is a peer node of the node joining the cluster.
4. The method of claim 1 , wherein the performing a mutual authentication session comprises:
calculating a session key separately by the node joining the cluster and the single node, wherein the session key is unique to the mutual authentication session.
5. The method of claim 4, wherein the communicating a cluster secret comprises:
communicating a cluster key between the node joining the cluster and the single node using the session key.
6. The method of claim 1 , wherein the performing a mutual authentication session comprises:
calculating, separately for the mutual authentication session, a verifier using cluster credentials possessed by the node joining the cluster and all nodes validly part of the cluster including the node of the cluster performing the mutual authentication session.
7. The method of claim 6, wherein the calculating a verifier using cluster credentials further uses information uniquely identifying the node joining the cluster.
8. The method of claim 6, wherein the cluster credentials comprise a cluster password injected separately into each of the node joining the cluster and the node of the cluster performing the mutual authentication session.
9. The method of claim 1 , wherein the performing a mutual authentication session comprises:
determining that the node joining the cluster is included in a roster of nodes allowed in the cluster.
10. The method of claim 1, wherein the cluster secret comprises a symmetrical cryptographic key.
11. The method of claim 1 , further comprising:
regenerating the cluster secret; and
requiring all the nodes validly part of the cluster to again perform a mutual authentication session between each such node and another node of the cluster to obtain the regenerated cluster secret.
12. The method of claim 11 , wherein the regenerating the cluster secret is performed periodically.
13. The method of claim 11 , wherein the regenerating, the cluster secret is performed upon a node resigning from the cluster.
14. A method comprising:
performing a mutual authentication handshake between a first node of a cluster and a second node of the cluster;
communicating a cluster key between the first node and the second node using a secure communication channel established by the mutual authentication handshake between the first node and the second node;
performing a mutual authentication handshake between a third node of the cluster and one of the first node and second node;
communicating the cluster key between the third node and the one of the first node and second node using a secure communication channel established by the mutual authentication handshake between the third node and the one of the first node and the second node; and
performing secure cluster communications between the first node, the second node, and the third node using the cluster key.
15. The method of claim 14, wherein performing the mutual authentication handshake between the first node and the second node comprises calculating a first session key separately by the first node and the second node, wherein the secure communication channel established by the mutual authentication handshake between the first node and the second node is secured using the first session key, and wherein performing the mutual authentication handshake between the third node and the one of the first node and the second node comprises calculating a second session key separately by the third node and the one of the first node and the second node, wherein the secure communication channel established by the mutual authentication handshake between the third node and the one of the first node and the second node is secured using the second session key.
16. The method of claim 14, wherein the secure cluster communications comprise unicast communications and multicast communications.
17. The method of claim 14, wherein the performing a mutual authentication session between the first node and the second node comprises:
calculating a first verifier using a cluster password possessed by the first node and the second node, wherein the cluster password is injected separately into each of the first node and the second node; and
wherein the performing a mutual authentication session between the third node and one of the first node and second node comprises:
calculating a second verifier using the cluster password possessed by the third node and the one of the first node and second node, wherein the cluster password is injected separately into each of the third node and the one of the first node and second node.
18. A system comprising:
a first processor-based network-connected device adapted to operate as a node of a cluster of nodes in accordance with code controlling the operation of the first processor-based network-connected device, wherein the code of the first processor-based network-connected device provides for operation of the first processor-based network- connected device as both a secure source of a secret of the cluster and a secure recipient of the secret of the cluster with respect to one or more other processor-based network- connected devices operating as nodes of the cluster, and wherein the secret of the cluster is adapted to allow secure communication between all nodes of the cluster.
19. The system of claim 18, wherein the secret of the cluster comprises a cryptographic cluster key.
20. The system of claim 18, wherein the operation of the first processor-based network-connected device as a source of the secret of the cluster facilitates one or more other processor-based network-connected devices to join the cluster as a node through authenticating only with the first processor-based network-connected device, and wherein the operation of the first processor-based network-connected device as recipient of the secret of the cluster facilitates the first processor-based network-connected device joining the cluster through authenticating only with one other processor-based network- connected device of the one or more other processor-based network-connected devices.
21. The system of claim 18, wherein the code of the first processor-based network-connected device is adapted to perform a mutual authentication session with a processor-based network-connected device of one of the other processor-based network- connected devices, wherein mutual authentication session provides a secure
communication channel unique to the mutual authentication session adapted for secure communication of the cluster secret.
22. The system of claim 21, wherein if the first processor-based network- connected device is joining the cluster the mutual authentication session is operable to authenticate the first processor-based network-connected device as a node validly part of the cluster and to receive the cluster secret communicated by the secure communication channel, and wherein if the first processor-based network-connected device is negotiating joining of the cluster by the processor-based network-connected device of the one or more other processor-based network-connected devices the mutual authentication session is operable to authenticate the processor-based network-connected device of the one or more other processor-based network-connected devices and to communicate the cluster secret by the secure communication channel if the processor-based network- connected device of the one or more other nodes is successfully authenticated.
23. The system of claim 18, wherein the first process-based network- connected device is one of a plurality of processor-based network-connected devices adapted to operate as part of the cluster of nodes in accordance with code controlling the operations thereof, wherein the code of each processor-based network-connected device of the plurality provides for operation of the respective processor-based network- connected device as both a secure source of a secret of the cluster and a secure recipient of the secret of the cluster, and wherein each processor-based network-connected device of the plurality is adapted to join the cluster by operation of its code authenticating with a single other processor-based network-connected device of the plurality and to securely communicate with every other processor-based network-connected device of the plurality.
PCT/US2012/033904 2011-08-25 2012-04-17 Systems and methods for providing secure multicast intra-cluster communication WO2013028235A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2014527143A JP2014529238A (en) 2011-08-25 2012-04-17 System and method for providing secure multicast intra-cluster communication
CN201280046647.7A CN103959735B (en) 2011-08-25 2012-04-17 For providing the system and method communicated in safe multicasting cluster
EP12825993.4A EP2748967A4 (en) 2011-08-25 2012-04-17 Systems and methods for providing secure multicast intra-cluster communication

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/218,186 2011-08-25
US13/218,186 US8719571B2 (en) 2011-08-25 2011-08-25 Systems and methods for providing secure multicast intra-cluster communication

Publications (2)

Publication Number Publication Date
WO2013028235A2 true WO2013028235A2 (en) 2013-02-28
WO2013028235A3 WO2013028235A3 (en) 2014-05-01

Family

ID=47745405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/033904 WO2013028235A2 (en) 2011-08-25 2012-04-17 Systems and methods for providing secure multicast intra-cluster communication

Country Status (5)

Country Link
US (2) US8719571B2 (en)
EP (1) EP2748967A4 (en)
JP (1) JP2014529238A (en)
CN (1) CN103959735B (en)
WO (1) WO2013028235A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11914736B2 (en) 2018-06-08 2024-02-27 Weka.IO Ltd. Encryption for a distributed filesystem

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8843737B2 (en) * 2011-07-24 2014-09-23 Telefonaktiebolaget L M Ericsson (Publ) Enhanced approach for transmission control protocol authentication option (TCP-AO) with key management protocols (KMPS)
US8959010B1 (en) * 2011-12-08 2015-02-17 Cadence Design Systems, Inc. Emulation system with improved reliability of interconnect and a method for programming such interconnect
US8955097B2 (en) * 2011-12-13 2015-02-10 Mcafee, Inc. Timing management in a large firewall cluster
US8880887B2 (en) * 2012-04-06 2014-11-04 Stt Llc. Systems, methods, and computer-readable media for secure digital communications and networks
NZ607298A (en) * 2013-02-19 2014-08-29 Allied Telesis Holdings Kk Improvements in and relating to network communications
JP5916652B2 (en) * 2013-03-22 2016-05-11 株式会社デジタル Communication equipment
CN103259786A (en) * 2013-04-16 2013-08-21 浪潮电子信息产业股份有限公司 Method for achieving HPC cluster safety
US9531542B2 (en) 2014-09-19 2016-12-27 Bank Of America Corporation Secure remote password
CN104735087B (en) * 2015-04-16 2020-11-20 国家电网公司 Multi-cluster Hadoop system security optimization method based on public key algorithm and SSL protocol
CN106059986A (en) * 2015-04-22 2016-10-26 阿里巴巴集团控股有限公司 Method and server for SSL (Secure Sockets Layer) session reuse
CN106161404A (en) * 2015-04-22 2016-11-23 阿里巴巴集团控股有限公司 The method of SSL Session state reuse, server and system
US9935965B2 (en) * 2015-05-14 2018-04-03 International Business Machines Corporation Establishing and using a trust level in mobile phones
WO2017058442A1 (en) * 2015-09-30 2017-04-06 Apple Inc. Coordinated control of media playback
WO2017193108A2 (en) * 2016-05-06 2017-11-09 ZeroDB, Inc. Encryption for distributed storage and processing
US10547527B2 (en) * 2016-10-01 2020-01-28 Intel Corporation Apparatus and methods for implementing cluster-wide operational metrics access for coordinated agile scheduling
US10911538B2 (en) * 2017-04-11 2021-02-02 Fortanix, Inc. Management of and persistent storage for nodes in a secure cluster
KR102042739B1 (en) * 2017-09-22 2019-11-08 서강대학교산학협력단 Apparatus and method for communication using message history-based security key using blockchain
US10615984B1 (en) * 2017-10-03 2020-04-07 EMC IP Holding Company LLC Enhanced authentication method for Hadoop job containers
US10993110B2 (en) * 2018-07-13 2021-04-27 Nvidia Corp. Connectionless fast method for configuring Wi-Fi on displayless Wi-Fi IoT device
CN109873801B (en) 2018-12-12 2020-07-24 阿里巴巴集团控股有限公司 Method, device, storage medium and computing equipment for establishing trusted channel between user and trusted computing cluster
CN109861980B (en) 2018-12-29 2020-08-04 阿里巴巴集团控股有限公司 Method, device, storage medium and computing equipment for establishing trusted computing cluster
US11522845B2 (en) 2019-11-29 2022-12-06 EMC IP Holding Company LLC Methods and systems for automatically and securely joining an association
US12026288B2 (en) * 2021-06-28 2024-07-02 Here Global B.V. Method, apparatus, and computer program product for confidential computing
US11914686B2 (en) 2021-10-15 2024-02-27 Pure Storage, Inc. Storage node security statement management in a distributed storage cluster
US20240193099A1 (en) * 2022-04-28 2024-06-13 Hui Lin Structure and method for digital data memory card encryption

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030056093A1 (en) 2001-09-19 2003-03-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method
US20030204734A1 (en) 2002-04-24 2003-10-30 Microsoft Corporation Methods for authenticating potential members invited to join a group

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US6952737B1 (en) 2000-03-03 2005-10-04 Intel Corporation Method and apparatus for accessing remote storage in a distributed storage cluster architecture
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US7181620B1 (en) * 2001-11-09 2007-02-20 Cisco Technology, Inc. Method and apparatus providing secure initialization of network devices using a cryptographic key distribution approach
US7539306B2 (en) * 2002-08-28 2009-05-26 Panasonic Corporation Key delivery apparatus, terminal apparatus, recording medium, and key delivery system
CN100587649C (en) * 2002-09-05 2010-02-03 松下电器产业株式会社 Group formation/management system, group management device, and member device
GB2400526B (en) * 2003-04-08 2005-12-21 Hewlett Packard Development Co Cryptographic key update management
FR2862835B1 (en) * 2003-11-24 2006-04-14 Medialive SECURED AND CUSTOMIZED DIFFUSION OF AUDIOVISUAL FLOWS BY A UNICAST / MULTICAST HYBRID SYSTEM
EP1889397A4 (en) * 2005-04-25 2010-03-17 Tecsec Inc Process of encryption and operational control of tagged data elements
US8126145B1 (en) * 2005-05-04 2012-02-28 Marvell International Ltd. Enhanced association for access points
EP1889496A4 (en) * 2005-05-10 2011-10-26 Network Equipment Tech Lan-based uma network controller with local services support
KR100735221B1 (en) * 2005-08-12 2007-07-03 삼성전자주식회사 Content playing method for playing content on a plurality of terminals and terminal, and the system thereof
US20070056042A1 (en) * 2005-09-08 2007-03-08 Bahman Qawami Mobile memory system for secure storage and delivery of media content
US8046579B2 (en) * 2005-10-04 2011-10-25 Neopost Technologies Secure gateway with redundent servers
DE502005005713D1 (en) * 2005-12-01 2008-11-27 Bravis Gmbh A method of modifying a group key in a group of network elements in a network
US8239671B2 (en) * 2006-04-20 2012-08-07 Toshiba America Research, Inc. Channel binding mechanism based on parameter binding in key derivation
US7913084B2 (en) * 2006-05-26 2011-03-22 Microsoft Corporation Policy driven, credential delegation for single sign on and secure access to network resources
US8140843B2 (en) * 2006-07-07 2012-03-20 Sandisk Technologies Inc. Content control method using certificate chains
JP5003118B2 (en) 2006-11-27 2012-08-15 横河電機株式会社 Control system and multicast communication method
US20090164782A1 (en) 2007-12-19 2009-06-25 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for authentication of service application processes in high availability clusters
KR20100102026A (en) * 2009-03-10 2010-09-20 주식회사 케이티 Method for user terminal authentication and authentication server and user terminal thereof
US20100250922A1 (en) * 2009-03-31 2010-09-30 Motorola, Inc. Method and system for propagating trust in an ad hoc wireless communication network
KR101684753B1 (en) * 2010-02-09 2016-12-08 인터디지탈 패튼 홀딩스, 인크 Method and apparatus for trusted federated identity
US8505083B2 (en) * 2010-09-30 2013-08-06 Microsoft Corporation Remote resources single sign on

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030056093A1 (en) 2001-09-19 2003-03-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method
US20030204734A1 (en) 2002-04-24 2003-10-30 Microsoft Corporation Methods for authenticating potential members invited to join a group

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Secure Peer-to-Peer Group Communication Framework", NEC RESEARCH AND DEVELOPMENT, vol. 44/4, October 2003 (2003-10-01), pages 333 - 339
See also references of EP2748967A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11914736B2 (en) 2018-06-08 2024-02-27 Weka.IO Ltd. Encryption for a distributed filesystem

Also Published As

Publication number Publication date
US20130054966A1 (en) 2013-02-28
EP2748967A4 (en) 2015-07-22
WO2013028235A3 (en) 2014-05-01
JP2014529238A (en) 2014-10-30
EP2748967A2 (en) 2014-07-02
US20140245390A1 (en) 2014-08-28
CN103959735B (en) 2017-09-29
US8719571B2 (en) 2014-05-06
US9043598B2 (en) 2015-05-26
CN103959735A (en) 2014-07-30

Similar Documents

Publication Publication Date Title
US9043598B2 (en) Systems and methods for providing secure multicast intra-cluster communication
CN108886468B (en) System and method for distributing identity-based key material and certificates
CN110380852B (en) Bidirectional authentication method and communication system
CN112152817B (en) Quantum key distribution method and system for authentication based on post-quantum cryptography algorithm
Mektoubi et al. New approach for securing communication over MQTT protocol A comparaison between RSA and Elliptic Curve
CN102318258A (en) Identity based authenticated key agreement protocol
CN103763356A (en) Establishment method, device and system for connection of secure sockets layers
CN112350826A (en) Industrial control system digital certificate issuing management method and encrypted communication method
WO2007011897A2 (en) Cryptographic authentication, and/or establishment of shared cryptographic keys, using a signing key encrypted with a non-one-time-pad encryption, including (but not limited to) techniques with improved security against malleability attacks
WO2017167771A1 (en) Handshake protocols for identity-based key material and certificates
CN113411187B (en) Identity authentication method and system, storage medium and processor
CN102111411A (en) Method for switching encryption safety data among peer-to-peer user nodes in P2P network
Panwar et al. Smart home survey on security and privacy
JP2020532177A (en) Computer-implemented systems and methods for advanced data security, high-speed encryption, and transmission
KR101704540B1 (en) A method of managing group keys for sharing data between multiple devices in M2M environment
Rizvi et al. A trusted third-party (TTP) based encryption scheme for ensuring data confidentiality in cloud environment
KR20080005344A (en) System for authenticating user&#39;s terminal based on authentication server
Wang et al. Key Management in CPSs
KR20070035342A (en) Method for mutual authentication based on the user&#39;s password
CN114386020A (en) Quick secondary identity authentication method and system based on quantum security
JP7213366B2 (en) Multi-Way Trust Formation in Distributed Systems
US20240283776A1 (en) Verifying the authenticity of internet key exchange messages in a virtual private network
CN108683627B (en) Internet of things node-to-node communication encryption method and system
JP6609212B2 (en) Encrypted communication channel establishment system, method, program, and computer-readable program recording medium
Agyemang et al. An Orchestration Framework for IoT Devices based on Public Key Infrastructure (PKI)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12825993

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 2014527143

Country of ref document: JP

Kind code of ref document: A