Distribution of secure keys in storage network

Abstract

Example embodiments relate to a storage network. In some examples, a controller identifies a set of devices associated with a zone configuration of a storage network, and identifies a set of policies associated with the zone configuration. The controller generates a set of security keys based on the set of devices and the set of policies. The controller distributes the set of secure keys to the set of devices via the set of secure messages, wherein the set of devices receives different subsets of the set of secure keys to establish encrypted communications between the set of devices.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0001] Some embodiments are described with reference to the following figures.

[0002] Figures 1A to 1B is a schematic diagram of an example storage network according to some embodiments.

[0003] Figure 2 is an illustration of example operations according to some implementations.

[0004] Figure 3 is a diagram of an example process according to some implementations.

[0005] Figure 4 is an illustration of example operations according to some implementations.

[0006] Figure 5 is an illustration of example operations according to some implementations.

[0007] Figure 6 is a schematic diagram of an example computing device in accordance with some embodiments.

[0008] Figure 7 is a diagram of an example process according to some implementations.

[0009] Figure 8 is an illustration of an example machine-readable medium storing instructions according to some implementations.

[0010] Throughout the drawings, like reference numerals denote similar, but not necessarily identical, elements. The drawings are not necessarily drawn to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. Furthermore, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0011] In some examples, a storage network system may include compute nodes and storage devices coupled via a network link (also referred to herein as a "network fabric"). For example, such a network link may be implemented using the Non-Volatile Memory Express over Network Fabric (NVMe-oF) protocol. In some examples, a storage network system may include physical storage devices, physical compute nodes, physical switching devices, virtual storage devices, virtual compute nodes, virtual switching devices, or any combination thereof. A storage device may include or manage any number of storage components to persistently store data. For example, a storage device may be a controller for a storage array that includes multiple non-volatile storage drives. A compute node may be a computing device (e.g., a server, a controller, etc.) that is capable of accessing data stored in a storage device. Each compute node and storage device may be referred to as a terminal or "endpoint" device that sends or receives data packets via a network fabric. As used herein, a "source device" may be an endpoint device that generates a data packet, and a "destination device" may be an endpoint device that receives a data packet. In addition, a "switching device" may be a network device that is capable of directing and / or transmitting data between endpoint devices.

[0012] In some examples, the devices of the storage network system can be divided into different groups or "zones" to provide data privacy and / or security. These zones can be defined by access rules (also referred to herein as "zone rules") that specify how to access data in the zone. These zone rules can be evaluated and applied by the switching device that receives the data packet to forward the data packet to its respective destination. For example, the switching device may include a first zone rule that identifies a first source device that is allowed to send a data packet to the destination device, but does not include any zone rule that allows a second source device to send a data packet to the destination device. In this example, the switching device will allow a first data packet to be sent from the first source device to the destination device, but will block a second data packet from the second source device to be sent to the destination device. In this way, zone rules can prevent devices from communicating with and / or accessing devices in different zones. As used herein, the term "zoning" can refer to controlling (e.g., allowing or blocking) communication between devices based on the zone to which the device is assigned.

[0013] In some examples, messages between endpoint devices in a zone can be protected by one or more security technologies. For example, in a storage network using the NVMe-oF protocol, messages can be authenticated using a Diffie-Hellman-Hash-based message authentication code-challenge-handshake authentication protocol (DH-HMAC-CHAP), or encrypted using the Transport Layer Security (TLS) protocol, or a combination of the two. Each endpoint device in a zone can be provided with one or more secret values ​​(also referred to herein as "security keys") for authentication and / or encryption of communications with other devices in the same zone. For example, a zone can include different device pairs (e.g., a combination of a host device and a storage controller) that are allowed to communicate with other devices. In such examples, each device in the device pair can be provided with a "self" key to authenticate itself to the other device in the device pair (referred to herein as a "partner" device). In addition, each device in the device pair can be provided with a "partner" key to authenticate the partner device in the device pair. In some examples, the management of security keys in a storage network can be complex and prone to errors. For example, manually generating a different and secure set of keys for each pair of devices in a zone can be a complex and time-consuming task. Furthermore, correctly distributing each key to the appropriate device while also maintaining the security of each key can be difficult. Furthermore, because there can be multiple keys for each allowed pairing of devices in a zone, the difficulty of generating and distributing keys can grow rapidly (e.g., exponentially) as the number of devices increases.

[0014] As referenced below Figures 1A to 8 As further described, some embodiments may include a central controller that provides a service (referred to herein as a Key Discovery Service (KDS)) that generates and distributes security keys to devices in a storage network. Each device in the storage network (also referred to herein as a "client" of the central controller) may be assigned a client key to authenticate messages from the central controller. The central controller may determine which client devices are allowed to communicate with each other in each zone of the storage network, and may also determine the security techniques to be applied to such communications. The central controller may then generate an appropriate set of security keys (e.g., a self-key and multiple partner keys) for each client device, and may distribute the set of security keys to the client devices in messages authenticated by the client keys. In this way, the central controller may automatically generate appropriate security keys and distribute them to multiple client devices in a secure manner. Accordingly, some embodiments described herein may improve the use and management of security keys in a storage network.

[0015] Figure 1A To B-Example Network System

[0016] Figure 1A An example of a network system 100 according to some embodiments is shown. Network system 100 can include any number and type of devices, including a central controller 110, client devices 120A-120D, and one or more switching devices 130. Client devices 120A-120D (also referred to herein as "client devices 120") can be physical devices and / or virtual devices, including computing nodes, storage devices, or components thereof. For example, client device 120A can be a computing device or host (e.g., a computer server including a processor, memory, and persistent storage). Furthermore, in this example, client device 120B can be all or a portion of a storage device (e.g., a storage subsystem, a storage controller, a storage array, a hard drive, a solid-state drive, an optical disk, etc.). In this example, client device 120A can send a request to obtain data stored in client device 120B. Furthermore, switching device 130 can transmit the request from client device 120A to client device 120B. Switching device 130 and client devices 120 can be interconnected via any number of links in network fabric 140. "Link" may refer to a communication medium (wired and / or wireless) through which devices can communicate with each other. In some embodiments, the central controller 110 may be a centralized discovery controller (CDC) that provides automatic discovery of devices in the NVMe-oF network system. Figure 1B An example implementation of the central controller 110 is described below.

[0017] In some embodiments, each client device 120 may include a user application (also referred to herein as a "client agent") for performing key discovery service (KDS) operations by interacting with the central controller. In other embodiments, each client device 120 does not include a client agent, and the central controller 110 performs KDS operations on the client device 120 via a remote access connection (e.g., using a Secure Shell (SSH) or HTTPS connection).

[0018] In some embodiments, the network system 100 can be configured for a specific task or purpose. For example, in some embodiments, the network system 100 can be a storage area network (SAN) that implements one or more network protocols (e.g., NVMe-oF protocol, Internet Small Computer System Interface (iSCSI) protocol, etc.). Figure 1A One example implementation of the network system 100 is shown, but other implementations are possible. For example, it is contemplated that the network system 100 may include additional devices and / or components, fewer components, different components, a different arrangement, etc.

[0019] Now refer to Figure 1B , an example embodiment of a central controller 110 is shown. In some embodiments, the central controller 110 may include a discovery engine 112, a configuration engine 114, a client engine 115, a security key engine 116, and a device database 118. Some or all of the engines 112, 114, 115, 116 may be implemented via hardware (e.g., electronic circuitry), or via a combination of hardware and programming (e.g., including at least one processor and instructions executable by the at least one processor). In embodiments using executable instructions, such instructions may be stored in a machine-readable storage medium, in hardware (e.g., circuitry), etc. Although Figure 1B The examples shown are those where the engines 112, 114, 115, 116 are implemented in a single central controller 110. However, in other examples, the engines 112, 114, 115, 116 may be implemented in different devices or services. Furthermore, it is contemplated that the central controller 110 may include additional devices and / or components, fewer components, different components, a different arrangement, etc.

[0020] In some embodiments, the discovery engine 112 can perform discovery of all devices in the network system 100. Furthermore, the device database 118 can be a data structure for storing information related to each discovered device. This information can include device identifiers, device configurations, storage configurations, namespaces, data locations, network connections, status, capabilities, and the like. In some embodiments, the discovery engine 112 can obtain discovery messages via a device-initiated registration process. For example, when a new client device 120 is added to the network system 100, the client device 120 can discover the central controller 110 (e.g., via a search function) and can initiate registration with the central controller 110 (via the discovery engine 112). Furthermore, upon registering the new client device 120, the discovery engine can add an identifier for the new client device 120 (and other information) to the device database 118. However, in other embodiments, the discovery engine 112 can obtain discovery information by polling the client devices in the network system 100.

[0021] In some embodiments, the configuration engine 114 can provide zone configuration in the network system 100. For example, the configuration engine 114 can receive user input or commands to specify zone rules, where each zone rule identifies a subset of devices 120 that can communicate with each other (also referred to herein as a "zone"). In some embodiments, the switching device 130 can determine that a received packet matches an existing zone rule and, in response, can forward the packet to the destination device 120.

[0022] In some embodiments, the client engine 115 can provide each client device 120 with an identifier that uniquely identifies the client device 120 (also referred to herein as a "client identifier"). For example, when a client device 120 initially registers with the storage network 100 (e.g., by sending a registration request to the discovery engine 112), the client engine 115 can generate a client identifier for the client device 120. In some embodiments, the client identifier can be a local identifier (i.e., an identifier configured to be unique within a single network system). The client identifier can be stored in the central controller 110 (e.g., in the device database 118) and / or in the client device 120 (e.g., in a persistent memory included in the client device 120).

[0023] In some embodiments, the client engine 115 and / or the client device 120 can use the client identifier to generate a secret value (also referred to herein as a "client key") that can be used to authenticate communications between the client device 120 and the central controller 110. For example, the client key for the client device 120 can be generated by applying a key derivation function to the client identifier of the client device 120. Figure 2 to describe example operations for generating a client secret key.

[0024] In some embodiments, the security key engine 116 can detect a zone change (e.g., a new zone or a modification to an existing zone) in the storage network 100 and, in response, can distribute appropriate security keys based on the zone change. For example, the security key engine 116 can identify the devices 120 included in the zone and can determine the security policy specified for the zone. The security key engine 116 can then generate security keys for the devices 120 that are allowed to communicate in the zone. In addition, the security key engine 116 can distribute security keys via a security message sent to the device 120. In some embodiments, the security message sent to the device 120 can include a proxy key for the receiving device 120, thereby allowing the device 120 to verify that the security message was sent from the central controller 110. Figures 3 to 4 An example process for generating and distributing security keys is described below. Furthermore, in some embodiments, secure messages from central controller 110 may also (or instead) be sent to device 120 via an encrypted connection (e.g., using a Hypertext Transfer Protocol Secure (HTTPS) connection). In some embodiments, central controller 110 may use a specific communication port (e.g., a Transmission Control Protocol (TCP) port) that is designated or reserved for distributing security keys to device 120.

[0025] In some embodiments, the security key engine 116 can generate a security key that is valid only until it expires. For example, a security key can be used only for a specified period of time (e.g., from the time the security key is created), or until a specified date and / or time is reached. In some embodiments, the security key engine 116 can detect (or be notified) that a security key is about to expire, and in response can generate and distribute a new security key to replace the expiring security key. Figure 5 to describe example operations for replacing an expiring security key.

[0026] Figure 2 - Example operation for generating client secret key

[0027] Figure 2 Example operations 200 for generating a client secret key according to some embodiments are shown. Operations 200 can be implemented in hardware or in a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0028] like Figure 2 As shown in FIG, operation 200 may be performed by a central controller (e.g., Figure 1A ) and a single client device (e.g., a central controller 110 shown in FIG. Figure 1A However, it is contemplated that the same (or similar) operations 200 may be performed on any number of client devices.

[0029] At block 210, the client device sends a discovery query 215 (e.g., a multicast domain name system (mDNS) query) to the central controller. At block 220, the central controller sends a query response 225 to the client device. In some examples, the query response 225 may include instructions for the central controller to send a query to the local network (e.g., Figure 1A Devices in the network system 100 shown in FIG. 1 provide information about a key discovery service (eg, “KDS”).

[0030] At block 230, the client device sends a registration request 235 to the central controller. In some embodiments, the registration request 235 may include a global identifier for the client device. As used herein, a "global identifier" refers to an identifier that is unique across multiple network systems or domains (e.g., an NVMe Qualified Name (NQN)). At block 240, the central controller generates a client identifier for the client device based on the global identifier of the client device. In addition, the central controller sends a message 245 to the client device including the client identifier. In some embodiments, the client identifier may be a local identifier (i.e., an identifier configured to be unique within a single network system).

[0031] At block 250, the central controller generates a client key for the client device based on the client identifier of the client device. Furthermore, at block 270, the client device generates the same client key based on the client identifier. For example, the client device and the central controller can each generate the same client key by applying a key derivation function (e.g., a key derivation function based on a Hash Message Authentication Code (HMAC)) to the client identifier of the client device. Furthermore, in some embodiments, the client device and the central controller can each generate the same client key by applying a key derivation function to a combination of the client device's global identifier and the client identifier.

[0032] At block 260, the central controller may store the client data (eg, global identifier, client identifier, and / or client key) in a device database (eg, Figure 1B Furthermore, at block 280, the client device may store the client data (eg, in a persistent memory included in the client device).

[0033] Figures 3 to 4 - Example process for generating and distributing security keys

[0034] Figure 3 An example process 300 for generating and distributing security keys according to some embodiments is shown. Process 300 can be implemented in hardware or in a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0035] Block 310 may include detecting a new or modified zone. Block 320 may include determining a security policy for the zone. Block 330 may include identifying a set of client devices included in the zone.

[0036] At block 340, a loop (defined by blocks 340, 350, and 360) may be entered to process each client device in the identified set of client devices. Block 350 may include generating a security key set for the device based on the security policy. Block 360 may include distributing the security key set to the device using authentication via the client key. At block 340, a loop (defined by blocks 340, 350, and 360) may be entered to process each client device. After all client devices in the identified set of client devices have been processed, process 300 is complete.

[0037] Now refer to Figure 4 , Figure 4 4 shows an example operation 400 according to some embodiments. Operation 400 may generally correspond to an example embodiment of process 300 (e.g., Figure 3 For ease of explanation, Figure 4 The example operations 400 shown in FIG. 4 are performed by a central controller (e.g., Figure 1A ) and two client devices (e.g., Figure 1A However, it is contemplated that the same (or similar) operations 400 may be performed for any number of client devices.

[0038] like Figure 4 As shown in FIG, at block 410, the central controller receives a network system (eg, Figure 1A The central controller receives configuration data for a new zone in the network system 100 shown in FIG. 1 (e.g., zone rules entered by a user). In response, the central controller determines the zone rules and security policy for the new zone, including which types of devices can communicate with each other (e.g., host to controller), the use of encryption and / or authentication, the type of encryption and / or authentication (e.g., DH-HMAC-CHAP protocol, TLS protocol), etc.

[0039] At block 420, the central controller identifies client device 1 and client device 2 as a set of client devices in the new zone. At block 430, the central controller generates security keys for client device 1 and client device 2. In some embodiments, the central controller generates a different set of security keys for each client device. For example, the central controller generates a first set of security keys for client device 1, which includes a self-key for client device 1 and a partner key for client device 2. Furthermore, the central controller generates a second set of security keys for client device 2, which includes a self-key for client device 2 and a partner key for client device 1.

[0040] In some embodiments, the security key can be generated using a mechanism such as a key derivation function (KDF or hash KDF) or a hash message authentication code (HMAC) algorithm. Additionally, in some embodiments, the security key can be valid only for a specified validity period (e.g., from the time the security key is created), or until a specified expiration date and / or time is reached.

[0041] At block 440, the central controller distributes different sets of security keys in messages 442 and 444, respectively, sent to client device 1 and client device 2. Message 442 sent to client device 1 includes the client key for client device 1, and message 444 sent to client device 2 includes the client key for client device 2. At block 450, client device 1 verifies first message 442 by determining that first message 442 includes the correct client key for client device 1. Similarly, at block 455, client device 2 verifies second message 444 by determining that second message 444 includes the correct client key for client device 2.

[0042] At block 460, after verifying first message 442, client device 1 extracts the security key set for client device 1 from first message 442. Similarly, at block 465, client device 2 extracts the security key set for client device 2 from second message 444. At blocks 470 and 475, client device 1 and client device 2 use their respective security keys to establish a secure connection 480 to each other. For example, client device 1 can extract a partner key for client device 2 from first message 442 and include the partner key in communications sent to client device 2. Additionally, client device 2 can extract a self-key from second message 444 and use the self-key to verify communications received from client device 1. Other examples are possible.

[0043] Figure 5 - Example operation for replacing an expiring security key

[0044] Figure 5 Example operations 500 for replacing an expiring security key according to some embodiments are shown. Operations 500 can be implemented in hardware or in a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc.

[0045] like Figure 5 As shown in FIG, operations 500 may be performed by a central controller (e.g., Figure 1A ) and two client devices (e.g., Figure 1A However, it is contemplated that the same (or similar) operations 500 may be performed on any number of client devices.

[0046] At block 510, client device 1 determines that the security key for a particular zone (e.g., a zone including client devices 1 and 2) will expire within a specified time period. For example, client device 1 may determine that the remaining time period before the expiration of the current security key set (e.g., the security key set previously received from the central controller) is less than a specific threshold time period (e.g., one day, one week, etc.). In response to this determination, at block 520, client device 1 sends a request 525 to the central controller to update the security key.

[0047] At block 530, the central controller generates a new set of security keys for the particular zone. In some embodiments, the new security keys may be generated using a mechanism such as a key derivation function (KDF or hash KDF) or a hash message authentication code (HMAC) algorithm. At block 540, the central controller distributes the new security keys in messages 542 and 544, respectively, sent to Client Device 1 and Client Device 2. Message 542, sent to Client Device 1, includes the client key for Client Device 1, and message 544, sent to Client Device 2, includes the client key for Client Device 2. At block 550, Client Device 1 verifies message 542 by determining that message 542 includes the correct client key for Client Device 1. Similarly, at block 555, Client Device 2 verifies message 544 by determining that message 544 includes the correct client key for Client Device 2.

[0048] At block 560, after verifying message 542, client device 1 extracts the new set of security keys for client device 1 from message 542. Likewise, at block 565, client device 2 extracts the new set of security keys for client device 2 from second message 544. At blocks 570 and 575, client device 1 and client device 2 begin establishing a secure connection 580 to each other using their new security keys.

[0049] Figure 6 - Sample computing device

[0050] Figure 6 1 shows a schematic diagram of an example computing device 600. In some examples, computing device 600 may generally correspond to some or all of central controller 110 (e.g., Figures 1A to 1BAs shown in FIG. , computing device 600 may include a hardware processor 602 and a machine-readable memory 605 including instructions 610 to 640. Machine-readable memory 605 may be a non-transitory medium. Instructions 610 to 640 may be executed by hardware processor 602 or by a processing engine included in hardware processor 602.

[0051] Instructions 610 may be executed to identify a plurality of devices associated with a zone configuration of a storage network. Instructions 620 may be executed to identify a policy set associated with a zone configuration of a storage network. For example, referring to Figure 4 At block 410, the central controller receives configuration data for a new zone in the network system. In response, the central controller determines zone rules and security policies for the new zone. Furthermore, at block 420, the central controller identifies Client Device 1 and Client Device 2 as a set of client devices in the new zone.

[0052] Reference again Figure 6 , instructions 630 may be executed to generate a plurality of security keys based on a plurality of devices and policy sets associated with a zone configuration of a storage network. Figure 4 At block 430, the central controller generates different sets of security keys for client device 1 and client device 2. In some embodiments, a cryptographic protocol may be used to generate the security keys. Furthermore, in some embodiments, the security keys may be valid only for a specified validity period (e.g., from the time the security keys are created), or until a specified expiration date and / or time is reached.

[0053] Reference again Figure 6 , instructions 640 may be executed to distribute a plurality of security keys to a plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communication between the plurality of devices. Figure 4 At block 440, the central controller distributes different sets of security keys in messages 442 and 444, respectively, to Client Device 1 and Client Device 2. At block 450, Client Device 1 verifies first message 442 by determining that first message 442 includes the correct client key for Client Device 1. At block 455, Client Device 2 verifies second message 444 by determining that second message 444 includes the correct client key for Client Device 2. At block 460, Client Device 1 extracts the set of security keys for Client Device 1 from first message 442. At block 465, Client Device 2 extracts the set of security keys for Client Device 2 from second message 444. At blocks 470 and 475, Client Device 1 and Client Device 2 establish a secure connection 480 to each other using their respective security keys.

[0054] Figure 7 -Example Process

[0055] Figure 7 An example process 700 according to some embodiments is shown. In some examples, a central controller 110 (e.g. Figures 1A to 1B ) to perform process 700. Process 700 can be implemented in hardware or in a combination of hardware and programming (e.g., machine-readable instructions executable by a processor). The machine-readable instructions can be stored in a non-transitory computer-readable medium, such as an optical, semiconductor, or magnetic storage device. The machine-readable instructions can be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc. However, other implementations are also possible.

[0056] Block 710 may include identifying, by a central controller of a storage network, a plurality of devices associated with a zone configuration of the storage network. Block 720 may include identifying, by the central controller, a set of policies associated with the zone configuration of the storage network.

[0057] Block 730 may include generating, by the central controller, a plurality of security keys based on a plurality of devices and a policy set associated with a zone configuration of the storage network. Block 740 may include distributing, by the central controller, the plurality of security keys to the plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communication between the plurality of devices. Blocks 710 to 740 may generally correspond to the examples described above with reference to instructions 610 to 640 (e.g., Figure 6 ).

[0058] Figure 8 - Example machine-readable medium

[0059] Figure 8 840 according to some embodiments. The instructions 810 to 840 may be executed by a single processor, multiple processors, a single processing engine, multiple processing engines, etc. The machine-readable medium 800 may be a non-transitory storage medium, such as an optical, semiconductor, or magnetic storage medium. The instructions 810-840 may generally correspond to the examples described above with reference to the instructions 610 to 640 (e.g., Figure 6 ).

[0060] Instructions 810 may be executed to identify a plurality of devices associated with a zone configuration of a storage network.Instructions 820 may be executed to identify a policy set associated with the zone configuration of the storage network.

[0061] Instructions 830 may be executed to generate a plurality of security keys based on a plurality of devices and a policy set associated with a zone configuration of a storage network. Instructions 840 may be executed to distribute the plurality of security keys to a plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communications between the plurality of devices.

[0062] According to some embodiments described herein, a central controller may provide a key discovery service (KDS) to generate and distribute security keys to devices in a storage network. Each device in the storage network may be assigned a client key to authenticate messages from the central controller. The central controller may determine which client devices are allowed to communicate with each other in each zone of the storage network, and may also determine the security techniques to be applied to such communications. The central controller may then generate an appropriate set of security keys for each client device, and may distribute the set of security keys to the client devices in messages authenticated by the client keys. In this way, the central controller may automatically generate appropriate security keys and distribute them to multiple client devices in a secure manner. Therefore, some embodiments described herein may improve the use and management of security keys in a storage network.

[0063] It should be noted that although Figures 1A to 8 Various examples are shown, but the embodiment is not limited thereto. For example, referring to Figure 1A It is contemplated that the network system 100 may include additional devices and / or components, fewer components, different components, a different arrangement, etc. In another example, it is contemplated that the functionality of the central controller 110 described above may be included in any other engine or software of the network system 100. Other combinations and / or variations are also possible.

[0064] Data and instructions are stored in respective storage devices, which are implemented as one or more computer-readable or machine-readable storage media. Storage media include various forms of non-volatile memory, including semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed disks, floppy disks, and removable disks; other magnetic media, including magnetic tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices.

[0065] It should be noted that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively may be provided on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such computer-readable or machine-readable storage media are considered part of an article of manufacture (or manufactured product). An article of manufacture or manufactured product may refer to any manufactured single component or multiple components. The storage medium or media may be located in a machine that runs the machine-readable instructions, or at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0066] In the above description, many details are listed to provide an understanding of the subject matter disclosed herein. However, these embodiments may be practiced without using some of these details. Other embodiments may include modifications and variations to the details discussed above. The appended claims are intended to cover such modifications and variations.

[0067] In the present disclosure, unless the context clearly indicates otherwise, the use of the terms "a", "an", or "the" is intended to include the plural forms as well. In addition, the terms "includes", "including", "comprises", "comprising", "have" or "having" when used in the present disclosure indicate the presence of stated elements, but do not exclude the presence or addition of other elements.

Claims

1. A computing device comprising: processor; as well as a machine-readable memory storing instructions executable by the processor to: identifying a plurality of devices associated with a zone configuration of a storage network; identifying a policy set associated with the zone configuration of the storage network; generating a plurality of security keys based on the plurality of devices and the policy set associated with the zone configuration of the storage network; as well as The plurality of security keys are distributed to the plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communications between the plurality of devices.

2. The computing device of claim 1 , comprising instructions executable by the processor to: receiving a registration request from a first device of the storage network; and A client identifier is assigned to the first device, wherein the first device is included in a first zone of the storage network, wherein the zone configuration is associated with the first zone, and wherein the first zone includes the plurality of devices.

3. The computing device of claim 2 , comprising instructions executable by the processor to: generating a first client key for the first device using the client identifier and a globally unique identifier of the first device; and A first security message is sent to the first device, wherein the first security message includes the first client key and a first security key set for the first device, and wherein the first device verifies the first security message using the first client key.

4. The computing device of claim 3, wherein the first set of security keys comprises: a self-key for the first device; as well as A set of partner keys for other devices included in the first zone. 5 . The computing device of claim 3 , wherein the global identifier of the first device is a nonvolatile memory quick qualified name (NQN) of the first device.

6. The computing device of claim 2, comprising instructions executable by the processor to: monitoring the zone configuration of the first zone for changes; and In response to detecting a change in the zone configuration of the first zone, the plurality of devices are identified.

7. The computing device of claim 1 , comprising instructions executable by the processor to: assigning expiration dates to the plurality of security keys; receiving an update request from at least one of the plurality of devices to update the plurality of security keys; as well as In response to receiving the update request, a new security key is generated based on the plurality of devices and the policy set.

8. A method comprising: identifying, by a central controller of the storage network, a plurality of devices associated with a zone configuration of the storage network; identifying, by the central controller, a policy set associated with the zone configuration of the storage network; generating, by the central controller, a plurality of security keys based on the plurality of devices and the policy set associated with the zone configuration of the storage network; as well as The plurality of security keys are distributed by the central controller to the plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communications between the plurality of devices.

9. The method of claim 8, comprising: Receiving, by the central controller, a registration request from a first device in the storage network; as well as A client identifier is assigned by the central controller to the first device, wherein the first device is included in a first zone of the storage network, wherein the zone configuration is associated with the first zone, and wherein the first zone includes the plurality of devices.

10. The method of claim 9, comprising: generating a first client key for the first device using the client identifier and a globally unique identifier of the first device; as well as A first security message is sent from the central controller to the first device, wherein the first security message includes the first client key and a first security key set for the first device.

11. The method of claim 10, comprising: receiving, by the first device, the first security message from the central controller; extracting, by the first device, the first client key from the first security message; verifying, by the first device, the first security message using the first client key; extracting, by the first device, the first set of security keys from the first security message in response to verifying the security message using the first client key; as well as The first set of security keys is used by the first device to establish encrypted communications with other devices of the plurality of devices.

12. The method of claim 10, wherein the first security key set comprises: a self-key for the first device; as well as A set of partner keys for other devices included in the first zone.

13. The method of claim 10, comprising: determining, by the first device, that the first security key set will expire within a specified time period; as well as The first device sends an update request to the central controller to update the multiple security keys.

14. The method of claim 13, comprising: Receiving, by the central controller, the update request from the first device; as well as In response to receiving the update request, a new security key is generated by the central controller based on the plurality of devices and the policy set.

15. A non-transitory machine-readable medium storing instructions that, when executed, cause a controller to: identifying a plurality of devices associated with a zone configuration of a storage network; identifying a policy set associated with the zone configuration of the storage network; generating a plurality of security keys based on the plurality of devices and a policy set associated with the zone configuration of the storage network; and The plurality of security keys are distributed to the plurality of devices via a plurality of security messages, wherein the plurality of devices receive different subsets of the plurality of security keys to establish encrypted communications between the plurality of devices.

16. The non-transitory machine-readable medium of claim 15, comprising instructions that, when executed, cause the controller to: receiving a registration request from a first device in the storage network; and A client identifier is assigned to the first device, wherein the first device is included in a first zone of the storage network, wherein the zone configuration is associated with the first zone, and wherein the first zone includes the plurality of devices.

17. The non-transitory machine-readable medium of claim 16, comprising instructions that, when executed, cause the controller to: generating a first client key for the first device using the client identifier and a globally unique identifier of the first device; and A first security message is sent to the first device, wherein the first security message includes the first client key and a first security key set for the first device, and wherein the first device verifies the first security message using the first client key.

18. The non-transitory machine-readable medium of claim 17, wherein the first set of security keys comprises: a self-key for the first device; as well as A set of partner keys for other devices included in the first zone.

19. The non-transitory machine-readable medium of claim 16, comprising instructions that, when executed, cause the controller to: monitoring the zone configuration of the first zone for changes; and In response to detecting a change in the zone configuration of the first zone, the plurality of devices are identified.

20. The non-transitory machine-readable medium of claim 15, comprising instructions that, when executed, cause the controller to: assigning expiration dates to the plurality of security keys; receiving an update request from at least one of the plurality of devices to update the plurality of security keys; and In response to receiving the update request, a new security key is generated based on the plurality of devices and the policy set.

Images