Site News  |   Monitor Keywords  |   Monitor Archive  |   Organizer  |   Account Info  |

Distributed management of crypto module white lists

Distributed management of crypto module white lists description/claims

This application claims priority to U.S. Provisional Patent Application Ser. No. 60/957,883, entitled, DISTRIBUTED MANAGEMENT OF CRYPTO MODULE WHITE LISTS by Robert Sussland, et al, which was filed on Aug. 24, 2007, a copy of which is incorporated herein by reference.

1. Field of the Invention

The present invention relates to security appliances and, more specifically, to a technique for securely establishing trusted relationships among an arrany of nodes in a security appliance.

2. Background of the Invention

As alluded to above, the present invention may apply to virtually any group of array of nodes communicating among each other. Smart herein refers to having computer processing abilities. The background and embodiments of the present invention are described with respect to secure storage systems, but any array of systems where trusted relationships among the systems is required may benefit from the present invention.

A storage system is a computer that provides storage services relating to the organization of information on writable persistent storage devices, such as memories, tapes or disks. The storage system is commonly deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including an operating system that implements a file system to logically organize the information as a hierarchical structure of data containers, such as files on, e.g., the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information, such as the actual data (i.e., file data) for the file.

The file server, or filer, may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access shared resources, such as files, stored on the filer. Sharing of files is a hallmark of a NAS system, which is enabled because of its semantic level of access to files and file systems. Storage of information on a NAS system is typically deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, that allow clients to remotely access the information (files) on the filer. The clients typically communicate with the filer by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).

In the client/server model, the client may comprise an application executing on a computer that “connects” to the filer over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. NAS systems generally utilize file-based access protocols; therefore, each client may request the services of the filer by issuing file system protocol messages (in the form of packets) to the file system over the network identifying one or more files to be accessed without regard to specific locations, e.g., blocks, in which the data are stored on disk. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS) and the Network File System (NFS) protocols, the utility of the filer may be enhanced for networking clients.

A SAN is a high-speed network that enables establishment of direct connections between a storage system and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, an operating system of the storage system enables access to stored data using block-based access protocols over the “extended bus.” In this context, the extended bus is typically embodied as Fibre Channel (FC) or Ethernet media adapted to operate with block access protocols, such as Small Computer Systems Interface (SCSI) protocol encapsulation over FC (e.g., FCP) or TCP (iSCSI).

SCSI is a peripheral input/output (I/O) interface with a standard, device independent protocol that allows different peripheral devices, such as disks, to attach to a storage system. In SCSI terminology, clients operating in a SAN environment are “initiators” that initiate commands and requests to access data. The storage system is thus a “target” configured to respond to the data access requests issued by the initiators in accordance with a request/response protocol. The initiators and targets have endpoint addresses that, in accordance with the FC protocol, comprise worldwide names (WWN). A WWN is a unique identifier, e.g., a node name or a port name, consisting of an 8-byte number.

A SAN arrangement or deployment allows decoupling of storage from the storage system, such as an application server, and some level of information storage sharing at the storage system level. There are, however, environments wherein a SAN is dedicated to a single storage system. In some SAN deployments, the information is organized in the form of databases, while in others a file-based organization is employed. Where the information is organized as files, the client requesting the information maintains file mappings and manages file semantics, while its requests (and storage system responses) address the information in terms of block addressing on disk using, e.g., a logical unit number (lun).

A network environment may be provided wherein information (data) is stored in secure storage served by one or more storage systems coupled to one or more security appliances. Each security appliance is configured to transform unencrypted data (cleartext) generated by clients into encrypted data (ciphertext) destined for secure storage or “cryptainers” on the storage system. As used herein, a cryptainer is a piece of storage on a storage device, such as a disk, in which the encrypted data is stored. In the context of a SAN environment, a cryptainer can be, e.g., a disk, a region on the disk or several regions on one or more disks that, in the context of a SAN protocol, is accessible as a lun. In the context of a NAS environment, the cryptainer may be a collection of files on one or more disks. Specifically, in the context of the CIFS protocol, the cryptainer may be a share, while in the context of the NFS protocol, the cryptainer may be a mount point. In a tape environment, the cryptainer may be a tape containing a plurality of tape blocks.

Each cryptainer is associated with its own encryption key, e.g., a cryptainer key, which is used by the security appliance to encrypt and decrypt the data stored on the cryptainer. An encryption key is a code or number which, when taken together with an encryption algorithm, defines a unique transformation used to encrypt or decrypt data. Data remains encrypted while stored in a cryptainer until requested by an authorized client. At that time, the security appliance retrieves the encrypted data from the cryptainer, decrypts it and forwards the unencrypted data to the client.

Often the security appliance is configured with a group or array of nodes, e.g., storage encryption processors (SEPs), each of which is configured to perform encryption and decryption operations for the appliance.

In such a configuration security is paramount. In this instance each node may process, inter alia, secure communications among the array of nodes. Nodes, such as SEPs, are discussed as sources and receivers of the secure communications discussed below, but as known to those skilled in the art, other software modules may participate in the detailed communication.

The invention addresses the problem of user enrollment in a distributed context. To understand the complexities involved, a review of the current state of the art is appropriate. The historically older and simpler approach is for each node to maintain its own list of user attributes. Such a list is often called a “white list”, as it explicitly states the entities that are allowed access. An example of such an approach would be a set of computers, each with a list of users allowed to log into each computer. This approach is easiest to implement from the point of view of the programmer, but suffers from several drawbacks. The first is that when a new user enrolls into the system, they must create accounts on every node. Because account creation is a sensitive operation that requires placing the node in a special state (for example, typically only administrators may manually create user accounts), account creation is necessarily a manual operation which exposes the node to a window of additional security risk. Also, to remove a user from access requires account removal at each node. Note that the information in the whitelist can consist of the username, or a public key, or a symmetric key, or other attributes required to correctly identify the entity and securely perform services for that entity. It does not matter whether the entity is a human user requesting services from a set of computers, or whether the user is a peer node requesting services from other nodes. The critical issue is the mechanism by which the entity is enrolled and un-enrolled from the group.

Because of the management complexity of having each node maintain its own white list, a popular solution is to have a master certifying agent that all the nodes trust. In this scenario, the certification agent (in the context of public key infrastructures, this is called a certification authority, and in the context of other infrastructures, different names may be used.) admits each entity by granting that entity some token or certificate of membership. Thereafter, the entity presents evidence of possessing the token or certificate to any other node in order to be granted access. This approach has the advantage of replacing multiple enrollment operations (one operation for each node) with a single enrollment operation. However, in order for this approach to be secure, there must be a mechanism to revoke the token or certificate in case the entity should no longer have access. This is a problem, as the token or certificate have already been given to the enrolled entity. Due remedy this problem, a “black list”, or list of forbidden users is kept by the certification agent. Then, each time an entity wishes to access a service from a node, the node queries the certification agent to see if the requesting entity is on the blacklist, before granting access. In the context of public key infrastructures, this is often called a certificate revocation list, although other terms may be used depending on the infrastructure employed. Therefore, the disadvantage of this approach, which we call the “blacklist” approach, is that the enrollment burden is shifted to every authentication attempt. Because of the computational and communications overhead of processing blacklists, this approach rarely properly implemented.

In preferred embodiments of the present invention it would be advantageous to array nodes with varying capabilities, some more flexible and some more restricted.

It will be appreciated by those skilled in the art that although the following Detailed Description will proceed with reference being made to illustrative embodiments, the drawings, and methods of use, the present invention is not intended to be limited to these embodiments and methods of use. Rather, the present invention is of broad scope and is intended to be defined as only set forth in the accompanying claims.

• Provisional Patent
• Utility Patent

• What Is a Patent?
• What Is a Trademark or Servicemark?
• What Is a Copyright?
• Patent Laws