WO2002093314A2 - Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux - Google Patents

Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux Download PDF

Info

Publication number
WO2002093314A2
WO2002093314A2 PCT/US2002/015421 US0215421W WO02093314A2 WO 2002093314 A2 WO2002093314 A2 WO 2002093314A2 US 0215421 W US0215421 W US 0215421W WO 02093314 A2 WO02093314 A2 WO 02093314A2
Authority
WO
WIPO (PCT)
Prior art keywords
encryption device
client
encryption
key
storage
Prior art date
Application number
PCT/US2002/015421
Other languages
English (en)
Other versions
WO2002093314A3 (fr
Inventor
Dan Avida
Serge Plotkin
Original Assignee
Decru, 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 Decru, Inc. filed Critical Decru, Inc.
Priority to US10/478,386 priority Critical patent/US8335915B2/en
Priority to AU2002305607A priority patent/AU2002305607A1/en
Priority to EP02734438A priority patent/EP1388061A4/fr
Publication of WO2002093314A2 publication Critical patent/WO2002093314A2/fr
Publication of WO2002093314A3 publication Critical patent/WO2002093314A3/fr
Priority to US11/350,047 priority patent/US8423780B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to data security. More particularly, the invention relates to an encryption based security system for network storage.
  • Computers are connected to storage devices such as disks and disk arrays by network connections such as Ethernet, Fibre Channel, SCSI, iSCSI, and Infiniband. Such connections use packet-based protocols to send data, commands, and status information between computers and storage devices.
  • the data stored on such storage devices is often of a proprietary nature, and the owner of such data wishes to prevent unauthorized users from reading or modifying the data.
  • the presently preferred embodiment of the invention provides an encryption based security system for network storage that separates the ability to access storage from the ability to access the stored data. This is achieved by keeping all (or part of) the data encrypted on the storage devices.
  • the invention comprises a device that has two network interfaces: one is a clear text network interface that is used to communicate to one or more clients, and the other is a secure network interface that is used to communicate with one or more persistent storage servers.
  • each network interface supports multiple network nodes. That is, the clear text network interface supports multiple client machines, and the secure network interface supports one or more storage servers.
  • the invention is preferably a device, placed in the network, on the data path between the computer and the storage device, which intercepts all the packets that flow between the computer and storage device.
  • the device distinguishes between data, command, and status.
  • the device encrypts, using a key, the data sent from the computer and decrypts the data sent from the storage device, while passing through without modification command and status information.
  • the device resides on the logical data path.
  • the client computers communicate to it as if it was a storage device (or several storage devices) while the device itself communicates with the storage devices as if it is a client computer.
  • the device can use a plurality of keys to encrypt and decrypt data, and a methodology to select the key based on user identification, data location on the storage device, file name, permission structure and other factors. Multiple such devices can share some or all keys and key use methodology between them, such that some or all of the data encrypted by one such device can be decrypted by another such device.
  • Such devices are able to operate in a transparent fashion to both the computers and storage systems that are exchanging data though the devices, such that no modification is required to either computers or storage devices to enable the storage of encrypted data on the storage device, and the subsequent retrieval and decryption of such data.
  • Fig. 1 is a block schematic diagram of a typical networked storage architecture
  • Fig. 2 is a block schematic diagram of an inline deployment architecture according to the invention
  • Fig. 3 is a block schematic diagram showing a deployment using a switch according to the invention.
  • Fig. 4 is a block schematic diagram of a Type-1 configuration according to the invention.
  • Fig. 5 is a block schematic diagram of a Type-2 deployment according to the invention.
  • Fig. 6 is a block schematic diagram of a Type 3 deployment according to the invention.
  • Fig. 7 is a block schematic diagram showing remote data sharing in NAS according to the invention
  • Fig. 8 is a block schematic diagram of an device and access controller configuration according to the invention.
  • Fig. 9 is a block schematic diagram of a direct-connect configuration according to the invention.
  • Fig. 10 is a block schematic diagram of a single switch solution according to the invention
  • Fig. 11 is a block schematic diagram of a dual switch or zoned single switch solution according to the invention
  • Fig. 12 is a block schematic diagram showing remote mirroring for private and shared disaster recovery according to the invention.
  • Fig. 13 is a block schematic diagram of an device according to the invention.
  • Fig. 14 is a block schematic diagram of a hardware configuration of an device according to the invention.
  • Fig. 15 is a block schematic diagram of a system according to the invention.
  • Fig. 16 is a block schematic diagram of a checksum processing data flow according to the invention.
  • Fig. 17 is a block schematic diagram of a checksum processing data flow for no block aligned ops according to the invention.
  • Fig. 18 is a block schematic diagram of a checksum processing data flow showing the fixing of edge effects according to the invention.
  • Fig. 19 is a system diagram according to the invention. DETAILED DESCRIPTION OF THE INVENTION
  • the presently preferred embodiment of the invention comprises a network device that resides in a network and that secures data residing in network storage.
  • a typical network storage architecture as is known in the art is shown in Fig. 1.
  • the servers 11 shown on the left access the storage devices 12 on the right through a communication fabric 13, i.e. a network.
  • the communication between a server and a storage device occurs in terms of sectors or blocks.
  • the server might request "block number 17" from a storage device.
  • the storage device is usually not aware of the file system used to organize the data on the device. Examples include SCSI over Fibre Channel (usually referred to as SAN), SCSI over IP (iSCSI).
  • NAS Network Attached Storage
  • the access is in terms of files.
  • a server might request to read a specific file from a specific directory.
  • the storage device is usually responsible for creating, maintaining, and updating the file system.
  • Examples of NAS include NFS and CIFS.
  • a key goal of the herein disclosed invention is to separate the ability to access storage (for purposes such as maintenance, backup, sizing, partitioning, etc) from the ability to access the stored data. This is achieved by keeping all (or the sensitive part of) the data encrypted on the storage devices.
  • Fig. 2 Possible integration of a presently preferred embodiment of the herein disclosed invention in the network is shown in Fig. 2.
  • a network element 20 that comprises the herein disclosed invention.
  • the invention analyzes the traffic, identifies the payload (data), encrypts/decrypts it (depending on the direction of traffic flow), and forwards the modified traffic.
  • FIG. 3 An alternative (switched) architecture is shown in Fig. 3.
  • the invention virtualizes some of the storage devices, and the clients 11 can access the devices 12 either directly or through the herein disclosed device 20. Again, all (or part of) the data written to the storage devices through the invention are encrypted.
  • the invention comprises a device that has two network interfaces: one is a clear text network interface that connects to one or more clients, and the other is a secure network interface that is connected to one or more persistent storage servers.
  • each network interface supports multiple network nodes. That is, the clear text network interface supports multiple client machines, and the secure network interface supports one or more storage servers.
  • the invention supports active failover and clustering. In particular, in NAS environment, the failover is completely transparent to the client computers and to the storage servers. In cases where multiple invention devices are deployed, all can be controlled globally, from a single point.
  • the invention supports initial encryption and re-encryption with a different key on-the-fly, without taking the system off-line.
  • the invention decodes all the storage protocols and separates control from payload, it can be set to translate between different storage protocols.
  • the invention can be setup to mount an NFS share and present it to a client computer as a CIFS share.
  • Another example of translation is between iSCSI and Fibre Channel: the invention can connect to a Fibre Channel array and present it as an iSCSI array.
  • the invention can be configured to enforce traffic-shaping policies on specific subsets of storage traffic. In particular, it can give higher priority to storage traffic between certain client hosts and storage devices or, alternatively, it can limit such storage traffic to not more than a given percentage of the available storage bandwidth.
  • traffic shaping policies can also take into account specific user names associated with the traffic streams.
  • the invention seamlessly integrates with existing networking infrastructure. It is possible to attach the invention to a network (NAS or SAN), initialize it, and start working. There is no need to reconfigure the servers. In the "switched" deployment case, the clients might need to be reconfigured to point them to access the storage through the invention instead of accessing it directly.
  • the invention supports industry standard network management interfaces such as SNMP, Web, RMON. I also supports standard physical interfaces such as Gigabit Ethernet, RJ-45 and fibre; Fibre Channel copper and fibre.
  • FIG. 4 This is the simplest configuration where the invention is connected to the enterprise network at an arbitrary point.
  • the configuration is shown in Fig. 4.
  • Data from clients 11a, 1 1 b flows through the enterprise network 13 to the inventive device 20 (shown on Fig. 4 by the numeric designator (1)), is encrypted by the device, and sent further to the disks 12a, 12b (shown on Fig. 4 by the numeric designator (2)).
  • a read operation proceeds in the reverse direction. Observe that in this case no assumptions are made as to where the inventive device is placed in terms of the enterprise network. In particular, it is not assumed that the device is on the same subnet as NAS clients or servers.
  • the client has to have one of the allowed IP/MAC address combinations (the list of allowed combinations is determined by the administrator).
  • the client can first be required to authenticate to the inventive device. Authentication possibilities include user_name/password, NTLM, NTLMv2, Kerberos V5, etc.
  • the clients 11a, 11b are connected to the clear text port 51 of the inventive device 20.
  • the other port 52 is connected to the rest of the enterprise network 13.
  • AH of the traffic to and from the enterprise network passes through the inventive device.
  • the packet filtering setup of the inventive device prevents a rogue client connected to the enterprise network, e.g. Net 79 in the example, to pretend to be connected to the client network (Net 78 in the example). Because the device does not serve decrypted data on the storage port, the rogue client does not have access to clear text data.
  • Fig. 5 shows only a single subnet on the client side. It is straighforward to extend this setup to allow more than a single subnet on the client side.
  • This deployment is similar to the Type-1 deployment.
  • the main difference is that the clients 11a, 11b are on the same subnet as the inventive device 20
  • Network 78 in the example in Fig. 6
  • the router 60 is assumed setup in a way that prevents a rogue client from pretending to be on Net 78 when it is not physically connected to this subnet.
  • the two client subnets (Net78 having clients 11 a, 11 b and Net 90 having clients 41 a, 41 b) are connected through a switch
  • VLAN 61 that supports VLANs (802.3p protocol).
  • Net-78 is mapped to VLAN-10 and Net-90 to VLAN-20.
  • the trunk carrying both VLANs connects the switch to the router.
  • FIG. 7 A basic setup for remote file sharing is shown in Fig. 7.
  • the example shows one main location 70 ("Headquarters") and one remote location 71.
  • the clients 11c, 11d at the remote location see the inventive device 20a as a file server. They access the files presented by the inventive device in the same way as they accesses any other NFS or CIFS server.
  • the client is required to authenticate to the (remote) inventive device 20a.
  • the authentication is performed in exactly the same way as when the NAS servers are directly accessed by the inventive device.
  • the remote device packages the request and forwards it through an IPSEC tunnel to the headquarters device 20b. In this example, it is assumed that the devices 20a and 20b have already authenticated and have created an IPSEC tunnel between them. 3.
  • the headquarters device 20b Upon receiving the request, the headquarters device 20b checks whether the remote device has the authority to execute the request.
  • headquarters device 20b reads the data from the NAS server, packages it appropriately, and forwards it through the IPSEC tunnel (shown by the numeric designator (1) on Fig. 7). Note that it does not decrypt the data.
  • the administrators of the remote devices define users that can access the Cryptainers.
  • the associated inventive device does not need to have any Cryptainer keys. In this case it serves only as an access controller.
  • This setup is shown in Fig. 8, in which the inventive device 20 operates in connection with access controllers 80.
  • the invention further comprises a device for NAS that supports private and shared remote secure mirroring.
  • the architecture is described in Fig. 12, which shows two companies connecting through a network to storage.
  • Company A has two clients 11 a and 11 b, while Company B has a single client 11 c.
  • Company A has two inventive devices 20a and 20b through which it connects to the shared storage, while Company B has a single device 20c.
  • Inventive device 20d serves as access controller in this setup, serving data only to devices 20a, 20b, and 20c; it does not decrypt the data.
  • Remote mirror storage device 120 is connected to a special port on the inventive device 20c and serves as a private (non shared) mirror of Company B.
  • Storage device 121 is connected to a similar port of inventive device 20d and can be setup to serve as a shared mirror for both companies. SBecause the data stored on this mirror are encrypted with keys available only to the inventive devices residing in the corresponding companies, one company can not read other company's data even though they share the mirror.
  • FIG. 10 A single-switch solution is shown in Fig 10. Assuming the switch 90 (or hub) is not zoned, the client sees both raw (original) disks and disks through the inventive device.
  • the servers do not see disks directly. The only way they can access the disk is through the inventive device.
  • the same configuration can be achieved by zoning a single switch, instead of using two switches 90a, 90b.
  • ports in one zone are used to connect the servers and the server side port of inventive device, while the other zone is used to connect the disk arrays and the storage side port of the inventive device.
  • Fig. 12 shows two companies connected to a shared storage site through a fibre channel network. Both companies use the shared mirror facility 121. Because they do not share the keys, neither company can access the data of the other one. In addition, company B is shown to have a private mirror 120 as well.
  • FIG. 13 A block schematic diagram of the inventive device 20 is shown in Fig. 13.
  • Storage traffic packets are disassembled by a disassembly modules 130, 135 the payload is encrypted or decrypted by respective modules 131 , 134 based on the command, i.e. read/write, and in view of key management module 136, the result is assembled back into a legal packet by an assembly module 132, 133 and sent forward.
  • FIG. 14 A hardware configuration of the inventive device is shown in Fig. 14.
  • the presently preferred embodiment of the invention is a device that is based on a standard dual-CPU 142, 143 architecture with dual PCI buses 140, 141. All of the encryption/decryption operations are done inside the Packet Processor, DPP 144. The only two places where secret data is stored in the system is inside DPP and inside the system Smart Card 145.
  • cryptainers can be, for example, an actual disk, a region on a disk, or several regions on one or more disks.
  • cryptainer is a collection of files and directories.
  • inventive device offers users and administrators a mechanism for creating secure Cryptainers. The following discussion describes details of a presently preferred implementation and method for creating Cryptainers in the context of NFS and CIFS.
  • a Cryptainer behaves as a physical device in a sense that it is forbidden to move files (mv) from one device to another and hard-link files across devices.
  • move By “move is forbidden”, we mean that the move will involve actual copy of the data followed by deletion of the original.
  • the inventive NFS device is installed with NFSBOX as the DNS name for the client-side interface.
  • the clients are able to reach this interface through the networking infrastructure.
  • the NFS server(s) are reachable from the server interface.
  • a management workstation is connected to the client side of the device and the appropriate software is installed.
  • Servers are allowed to export their shares to the server-side interface of the inventive device (NFSBOX).
  • Srvl exports Srvl :/srv1/home/a, Sn/1 :/srv1/home/b
  • Srv2 exports Srv2:/export1.
  • the inventive device is set to export all of the above three shares.
  • Every share exported by the inventive device has a name defined by the administrator.
  • the administrator is able to use arbitrary names. To make the description as general as possible, the use of non-canonical names is assumed, even though this may not be a preferred practice.
  • NFSBOX /home/b
  • NFSBOX /export
  • the names of the exported shares are independent of their original names, which may not be a good IT practice. It is assumed that the client has mounted the shares exported by device on /decru/a, /decru/b, /decru/c.
  • the mounts /decru/a,b,c behave exactly as regular NFS mounts.
  • the user can create directories, create files, and move files from one directory to another as long as both are under the same mount point.
  • a Cryptainer can be created by the user through CLI or a user-GUI. The process of the creation is described below.
  • An existing directory is converted to become a Cryptainer.
  • the user has a directory in /decru/a/examples/dir1.
  • the dirl directory becomes the new root of a Cryptainer. All existing data in dirl is encrypted.
  • a new Cryptainer is created in an existing directory. For example, assuming /decru/a/examples exists, the user can create /decru/a/examples/dir2.
  • a new directory, dir2 is created and ready for use as a Cryptainer. Any new file created in dir2 or copied there is immediately encrypted.
  • the user-GUI suggests to the user that a distinctive name be given to the Cryptainer.
  • the Cryptainer name is always clear text.
  • Cryptainer As a regular directory. For performance reasons, there are several restrictions on operations involving Cryptainers. In general, the restrictions are the same as if a Cryptainer is a separate mount point of a share: • It is impossible to "mv" Cryptainers from one share to another.
  • the user can apply all the regular file manipulation operations to directories and files within a Cryptainer. These operations include: mv, cp, rm, rmdir.
  • the solution supports common backup utilities and configurations. 6. Both initial encryption of a non-empty directory and re-encryption of an existing Cryptainer is supported.
  • a Cryptainer can be recovered to a destination different from the original destination.
  • CK Framework Cryptainer keys
  • the first block of each file contains:
  • Creation of a new Cryptainer results in creation of a directory with the Cryptainer name and a .decru file in this directory with meta-data about the Cryptainer. For example, creating a new Cryptainer named /decru/a/examples/dir2 results in creation of a directory named NFSBOX:/Srv1/home/a/examples/dir2.
  • Conversion of an existing directory into a Cryptainer leaves the files where they are on the server in terms of the directory path, encrypts them, and creates the .decru file under the root name.
  • the files are encrypted in-place and hence their NFS handles are not changed in this process.
  • the administrator provides the server name
  • the Device Manager adds the server to the list of virtualized servers
  • the Device Manager displays a list of shares for the server 4. Administrator selects shares to be exported through the inventive device 5. The Device Manager notifies the NFS Mount proxy of the new share information
  • the Device Manager creates a new CryptainerlD for the new Cryptainer 4.
  • the Device Manager gives the NFS Proxy (NP) the share, path,
  • the NP creates the Cryptainer directory (un-encrypted).
  • the NP informs the Device Manager upon completion and asks the DPP for a new Cryptainer Key. (It is returned encrypted)
  • the CryptainerlD is stored in the .decru file Assigning Permissions on a Cryptainer
  • the owner of the Cryptainer using the admin tools asks the Device Manager to edit permissions on the Cryptainer.
  • the updated information is stored in the Configuration DB (CDB).
  • Client procedures can be grouped into three categories for the purpose of determining a CryptainerlD:
  • the user provides a file handle and data
  • the NP looks in the file handle cache to determine the CryptainerlD
  • the NP reads the file meta-data (first block of the file) and gets the CryptainerlD
  • the NP passes the user's credentials + CryptainerlD to the Device Manager
  • the Device Manager checks the ACL and sends back the Cryptainer Key (CK) and a permission bit mask 6.
  • the CK, the random values, and the data are sent to the DPP for encryption if the operation requires encryption or decryption
  • the procedure for determining the CryptainerlD for an object given a parent directory and name is:
  • the client provides a file handle to parent directory and a filename
  • the NP looks in the file handle cache to determine the CryptainerlD
  • the NP looks for the .decru file in parent directory (handle to this directory was given) and extracts the CryptainerlD if file found. If the .decru file is missing the NP walks up the directory tree until it reaches the root directory, each time looking for .decru file and checking the directory handle against cache. If neither .decru found nor cache hit, the original file is assumed to be in clear text. Otherwise the CryptainerlD is extracted either from the cache or from the .decru file.
  • the system can maintain a cache data structure that holds all of the paths to Cryptainers and all of the file handles for the directories on these paths.
  • the NP passes the user's credentials + CryptainerlD to the Device Manager
  • the Device Manager checks the ACL and sends back the Cryptainer Key (CK, encrypted with Master Key) and a permission bit mask 4.
  • the NP asks the DPP for 2 random values (file keys) 5.
  • the NP sends the file name to DPP to be encrypted using the CK and creates the file
  • the NP writes the first record that contains Cryptainer ID and the encrypted R1/R2 values and some additional administrative information. 7. A handle to the file is returned to the user and saved in temporary cache
  • the user provides a file handle to the source directory and source name and a file handle to the destination directory and a destination name
  • the NP uses the procedure above to find CryptainerlDs for both source and the destination
  • the CryptainerlD of the destination directory is compared to the CryptainerlD of the source directory 4. If same CryptainerlD and if NFS allows a move, then a regular move is done
  • CIFS device is installed with CIFSBOX as the DNS name for the client- side interface. (This name can be arbitrary legal DNS name, CIFSBOX is used just as an example) • The clients are able to reach this interface through the networking infrastructure.
  • the CIFS server(s) are reachable from the server interface.
  • a management workstation is connected to the client side of the device and the appropriate software is installed. • Users, clients, and servers were defined by the administrator through a management interface.
  • the inventive device is set to export all of the above three shares.
  • Every share exported by the inventive device has a name defined by the administrator.
  • the administrator can use arbitrary names. To make the description as general as possible, the use of non-canonical names is assumed, even though this may not be a good practice.
  • the mounts ⁇ CIFSBOX ⁇ a,b,c behave exactly as regular CIFS mounts.
  • the user can create directories, create files, and move files from one directory to another as long as both are under the same mount point. Moves from one share to another share on device are converted by the client into copies. In particular, this is true when using drag-and-drop in Windows Explorer.
  • the command line "move" is converted into a copy+delete.
  • a Cryptainer can be created by the user through CLI or a user-GUI. The process of the creation is described above. There are two main choices:
  • An existing directory is converted to become a Cryptainer.
  • the user might have a directory ⁇ CIFSBOX ⁇ a ⁇ dir1.
  • the dirl directory becomes the new root of a Cryptainer. All existing data in dirl are encrypted.
  • a new Cryptainer is created in an existing directory. For example, assuming ⁇ CIFSBOX ⁇ a ⁇ examples exists, the user can create ⁇ CIFSBOX ⁇ a ⁇ examples ⁇ dir2.
  • a new directory, dir2 is created and ready for use as a Cryptainer. Any new file created in dir2 or copied there is immediately encrypted. (The file name is encrypted if user sets "encrypt file names" property during creation of the Cryptainer.)
  • Decru user-GUI suggests to the user that a distinctive name be given to the Cryptainer.
  • a Cryptainer is constructed with access rights given only to the user creating it, the "owner". Ownership can be passed to a different user using CLI or user-Gui.
  • the user can choose whether the encryption includes file and/or directory names.
  • the user is able to apply all the regular file manipulation operations to directories and files within a Cryptainer.
  • a Cryptainer can be recovered to a destination different from the original destination.
  • Cryptainer keys are used to encrypt data, filenames and directory names within a given Cryptainer.
  • the first block of each file contains:
  • Creation of a new Cryptainer results in creation of a directory with the Cryptainer name and a .decru file in this directory with some meta-data about the Cryptainer, including its handle/ID.
  • the administrator provides the server name
  • the Device Manager adds the server to the list of virtualized servers 3.
  • the Device Manager displays a list of shares for the server
  • the Device Manager notifies the NFS Mount proxy of the new share information
  • the Device Manager creates a new CryptainerlD for the new Cryptainer 4.
  • the Device Manager gives the CP the share, path, Cryptainer name and the CryptainerlD and asks the CP to create the new Cryptainer directory
  • the CP creates the Cryptainer directory (un-encrypted).
  • the CP informs the Device Manager upon completion and asks the DPP for a new Cryptainer Key. (It is returned encrypted) 7.
  • the CryptainerlD is stored in the .decru file Assigning Permissions on a Cryptainer
  • the owner of the Cryptainer using the admin tools asks the Device Manager to edit permissions of the Cryptainer 2.
  • the updated information is stored in the Configuration DB (CDB).
  • TREE_CONNECT In CIFS, a user must first connect to a specific ⁇ server ⁇ share via a TREE_CONNECT.
  • the server rely to a TREE_CONNECT includes a tlD that is used in all future commands sent to the server. All commands after the tree connect reference objects on the server in one of three possible ways:
  • NT_CREATE_ANDX has an optional parameter (RootDirectoryFid) that can be used in combination with a relative path.
  • the user provides a tlD and a path 2. Starting at the top of the path the proxy looks up the path in the CryptainerlD cache.
  • Proxy attempts to read ⁇ a ⁇ .decru from the server. If the file is found the Cryptainer handle is read from .decru and the path ⁇ CryptainerlD are put in the CryptainerlD cache.
  • the CP passes the user's credentials + CryptainerlD to the Device Manager
  • the Device Manager checks the ACL and sends back the Cryptainer Key (CK) and a permission bit mask 8.
  • the proxy calls the DPP to encrypt the partial path " ⁇ c" and creates ⁇ a ⁇ b ⁇ Enc[c]
  • the CP asks the DPP for two random values (file keys)
  • the CP encrypts the file name using the CK and creates the file 3.
  • the CP write the first record that contains
  • the FilelD in the server response is returned to the user and is saved in 5 temporary cache.
  • the command is passed through with the file/directory name modified to ' lO ⁇ a ⁇ b ⁇ Enc[c]
  • the create directory message is sent to create a new directory.
  • the appropriate TID and additional pathname are passed.
  • the directory must not exist for it to be created.
  • the delete directory message is sent to delete an empty directory.
  • the appropriate TID and additional pathname are passed.
  • the directory must be empty for it to be deleted.
  • CHECK_DIRECTORY Check Directory This SMB protocol is used to verify that a path exists and is a directory. No error is returned if the given path exists and the client has read access to it.
  • This command is used to create or open a file or a directory.
  • This message is sent to obtain a file handle for a data file.
  • This returned FID is used in subsequent client requests such as read, write, close,
  • This message is sent to create a new data file or truncate an existing data file to length zero, and open the file.
  • the handle returned can be used in subsequent read, write, lock, unlock and close messages.
  • the delete file message is sent to delete a data file.
  • the appropriate TID and additional pathname are passed. Read only files may not be deleted, the read-only attribute must be reset prior to file deletion.
  • QUERYJNFORMATION Get File Attributes This request is sent to obtain information about a file.
  • This message is sent to change the information about a file.
  • the server creates a data file in DIRECTORY relative to TID in the SMB header and assigns a unique name to it.
  • This message is sent to create a new data file or truncate an existing data file to length zero, and open the file.
  • This request is used to get information about a specific file or subdirectory.
  • This request is used to set information about a specific file or subdirectory
  • TRANS2_CREATE_DIRECTORY This requests the server to create a directory relative to TID in the SMB header, optionally assigning extended attributes to it.
  • the close message is sent to invalidate a file handle for the requesting process. All locks or other resources held by the requesting process on the file should be released by the server. The requesting process can no longer use FID for further file access requests.
  • the flush command is sent to ensure all data and allocation information for the corresponding file has been written to stable storage.
  • the FID has a value -1 (hex FFFF)
  • the server performs a flush for all file handles associated with the client and PID.
  • the response is not sent until the writes are complete.
  • the read message is sent to read bytes of a resource indicated by FID in the SMB protocol header.
  • WRITE, WRITE_ANDX, WRITE_AND_CLOSE Write Bytes The write message is sent to write bytes into the resource indicated by FID in the SMB protocol header.
  • the lock record message is sent to lock the given byte range. More than one non-overlapping byte range may be locked in a given file. Locks prevent attempts to lock, read or write the locked portion of the file by other clients or PIDs. Overlapping locks are not allowed. Offsets beyond the current end of file may be locked. Such locks do not cause allocation of file space.
  • This message is sent to unlock the given byte range.
  • OFFSET, COUNT, and PID must be identical to that specified in a prior successful lock. If an unlock references an address range that is not locked, no error is generated.
  • the seek message is sent to set the current file pointer for FID.
  • the SMB_COM_READ_RAW protocol is used to maximize the performance of reading a large block of data from the server to the client. This request can be applied to files and named pipes.
  • the Write Block Raw protocol is used to maximize the performance of writing a large block of data from the client to the server.
  • the Write Block Raw command's scope includes files, Named Pipes, and spooled output (can be used in place COM_WRITE_PRINT_FILE ).
  • SMB_COM_SET_INFORMATION2 sets information about the file represented by FID.
  • the target file is updated from the values specified.
  • a date or time value or zero indicates to leave that specific date and time unchanged.
  • This SMB gets information about the file represented by FID.
  • LOCKING_ANDX Lock or UnLock Bytes SMB_COM_LOCKlNG_ANDX allows both locking and/or unlocking of file range(s).
  • This request is used to get information about a specific file or subdirectory given a handle to it.
  • the source file is copied to the destination and the source is subsequently deleted.
  • OLDFILENAME is copied to NEWFILENAME, then OLDFILENAME is deleted.
  • Both OLDFILENAME and NEWFILENAME must refer to paths on the same server.
  • NEWFILENAME can refer to either a file or a directory. All file components except the last must exist; directories will not be created.
  • NEWFILENAME can be required to be a file or a directory by the Flags field.
  • the TID in the header is associated with the source while TID2 is associated with the destination. These fields may contain the same or differing valid values.
  • TID2 can be set to -1 indicating that this is to be the same TID as in the SMB header. This allows use of the move protocol with SMB_TREE_CONNECT_ANDX. COPY: Copy File
  • TID2 is associated with the source while TID2 is associated with the destination. These fields may contain the same or differing valid values. TID2 can be set to -1 indicating that this is to be the same TID as in the SMB header. This allows use of the move protocol with SMB_TREE_CONNECT_ANDX.
  • This command is used to determine the capacity and remaining free space on the drive hosting the directory structure indicated by TID in the SMB header.
  • Each file in the NFS/CIFS environment and each block in the FC environment is encrypted with a "strong" length key of 128, 192, or 256 bits.
  • the files are arranged into Cryptainers.
  • the Cryptainers represent encryption granularity.
  • a Cryptainer can be a file, a set of files, a directory, a volume, or a set of volumes.
  • a Cryptainer is identified by initiator id, target id, lun, and LBA range (block addresses). It is also possible to address Cryptainers by WWN. It is also possible to create a cryptainer that corresponds to several regions on one or more disks.
  • Strength Encryption is as strong as or stronger than ECB using 3DES or AES.
  • Block comparison It is impossible to check whether two different blocks have the same clear text data without decrypting them.
  • Bit flip It is cryptographically difficult to change ciphertext in a way that result in a flip of a specific bit in the output.
  • Files can be copied or renamed without re-encryption, as long as they are not moved from one Cryptainer to another.
  • Each data block B is associated with two BlockUniquelDs - ID1 , ID2.
  • Each file in NFS/CIFS and each Cryptainer in FC is associated with two randomly created values: R1 and R2.
  • ID1 and ID2 are created by XORing BlocklD with R1 and R2, respectively.
  • a different function can be used instead of XOR.
  • Each data block B (64b for 3DES; 128b for AES) is encrypted as follows:
  • ENC is the chosen encryption function
  • R1 and R2 are key material and are stored encrypted with CK
  • FC and SCSI block sizes must be a multiple of 512 bytes
  • Read requests should be manipulated by the system to be block aligned. The extra bytes should be removed before returning to the user.
  • the system reads the first and last blocks that contain the sb and eb of the write request (assuming that the write request is misaligned at both ends)
  • the preferred system uses two encryption algorithms: 3DES and AES (Rijndael).
  • 3DES uses a key of 168 bits and a block size of 64 bits.
  • the AES implementation uses a key of 128 bits and a block size of 128 bits.
  • AuthKey Private AuthKey signature of Message, verifiable with Public
  • the presently preferred embodiment comprises level 3 FIPS certification for DPP board and level 2 for the whole device.
  • the inventive device contains a mechanism to zeroize clear-text keys on demand.
  • At least three Hardware Tokens are provided with each device, one of each type.
  • the Hardware Token must support the following: PKI, authentication, enough memory to store the information described in section 4 below + some temporary space for the crypto operations.
  • a Cryptainer can be accessible through one or more devices. Each Cryptainer has a master device. Access control modifications are managed by the master. The Cryptainer becomes accessible through other devices only with the master's approval. • The user can disable remote configuration
  • the device Public Key is stored in the Hardware Token or the main board memory.
  • the Master Key (MK) is kept inside the DPP in clear-text.
  • the DPP stores two MKs: Incoming Data MK and Outgoing Data MK.
  • the Incoming MK is used to decrypt incoming key material; the Outgoing MK is used to encrypt outgoing key material. In normal operation both are the same.
  • CK Cryptainer Keys
  • ITKN Local Key Pair used to encrypt MK and sign DR Public Keys.
  • MK is stored in the file system encrypted using the ITKN local Public Key, and additionally saved via secret sharing.
  • Secret shares are stored encrypted with public keys of combinations of DRTKN cards, allowing recovery of MK using "m out of n" DRTKNs.
  • CK are persisted into the crypto config db, which is stored in the file system. The data is encrypted using the MK.
  • each key is modified by inserting zeros in several places in the key. After each decryption, existence of these zeroes is verified, providing error-detection capability
  • the "crypto config db" associates each CryptainerlD with a key.
  • the entire AKS is stored in the ITKN.
  • the DPP and MTKN each have their respective entries in the AKS.
  • the AKS in the DPP is stored in battery backed RAM or inside the microcontroller residing under physically secure cover on the DPP board.
  • the AKS is backed up to CryptoDB using Secret
  • the initial and local key pairs of the ITKN and DRTKN are stored on their respective smart cards.
  • DPP implements identity-based authentication, to comply with FIPS level 3
  • HW Token Some functions of the HW Token require authentication and a creation of a secure channel others do not. 2.
  • the HW Token enforces the defined security policy (it executes functions only if the right security settings exist).
  • the communication channel between the DPP and the ITKN is secured using a session key that is only known to them.
  • MTKN to ITKN session keys are derived from a different static AKS entry.
  • the communication channel between the DPP and the CPU is not secured - cryptographically sensitive information is not passed on this channel in . clear-text.
  • DRTKNs and ITKNs authenticate by trading signed public keys. They are capable of using these keys to create a secure channel, but generally do not.
  • the CPU 156, 159 asks the DPP to create an Authentication Message (the logic of the packet assembly can be handled by the CPU).
  • the Authentication Message is based on the AKS (or the IAKS during initialization).
  • the CPU sends the Message to the ITKN
  • the ITKN sends its reply and the CPU transfers that to the DPP 5.
  • the CPU transfers the DPP's response to the ITKN
  • the Mgmt Station 152 in the management PC 150 sends the right user/password to the crypto card 157, 160.
  • the Mgmt Station authenticates to the MTKN (see above)
  • the Mgmt Station asks the MTKN to create an Authentication Message 3.
  • the Mgmt Station sends the Message to the ITKN through the CPU
  • the ITKN sends its reply and the CPU transfers it to the Mgmt Station that transfers it to the MTKN
  • the MTKN response is sent back to the ITKN 6.
  • the ITKN and the MTKN have a secure way to communicate that the CPUs cannot access. This authentication is done using our implementation of the authentication protocol.
  • DRTKN sends ITKN DRAuth PubKey and [DRLocal PubKey] DRAuth
  • ITKN verifies DRAuth signed by the device, and DRLocal signed by DRAuth.
  • ITKN sends lAuth PubKey and [ILocal PubKey and hash(R1 ) and E DRLoca ⁇ (R1)], Auth to DRTKN.
  • R1 is random number generated each time for this operation.
  • DRTKN verifies lAuth Pub Key with its copy of the device Public Key and decrypts R1.
  • DRTKN sends hash(R2
  • DRTKN and ITKN have now traded local Public Keys. They trust them because of a chain Public Key -> Authentication Public Key -> Local Public Key, R1 and R2 prevent replay and establish a 3des session key (R1
  • MM asks ITKN to secret share Data among M DRTKNs, requiring N for recovery.
  • ITKN signs secret with Local Key Pair
  • the data saved to disk is secret concatenated with the signature.
  • ITKN creates N choose M secret parts (kept on card).
  • DRTKN-1 creates two Recover Secret requests, which are saved locally:
  • DRTKN-2 decodes Request 1 and returns E DR1
  • User-3 authenticates to DRTKN-3
  • DRTKN-3 decodes Request 2 and returns E DR1 , oca ,(Secret-3 and nonce) 9.
  • User-1 authenticates to DRTKN-1.
  • DRTKN-1 decrypts responses from 2and3, verifies nonces.
  • DRTKN-1 decrypts its own secret.
  • the client receives (at minimum) a device, three hardware tokens, and one hardware token reader that can be attached to a PC 150, which serves as a management station.
  • the device can be identified using a value derived from the IAKS.
  • the Mgmt Station authenticates to the device as described above. From now on all communication between the two is done using the secured channel.
  • the Mgmt Station asks the MTKN to start the Personalization Process. 7.
  • the MTKN generates an encrypted Personalization Request that is sent to the device.
  • the CPU on the device initiates an authentication between the DPP and the ITKN as described above.
  • the DPP generates a random number using its TRNG. This number is passed to the ITKN and seeds the PRNG.
  • the ITKN generates a new AKS and key pair, updates its own registry, and sends it to the DPP.
  • the ITKN and the DPP re-authenticate using the new AKS and establish a new session key.
  • the DPP generates the MK and passes it to the ITKN using the secure channel.
  • the ITKN encrypts it using its Public Key and saves it.
  • the CPU asks the ITKN for the ENC LPubK [MK] and persists it to the file system.
  • the ITKN is now in token data sync mode. 16. The user defines the username and password of the HW Token administrator. 17. All the new information (new AKS, user info) is sent from the ITKN to the initiating MTKN using the secure channel between them. The MTKN uploads the new information. 18. The user now chooses the parameters for secret sharing, and must initialize the number of DRTKN's indicated. 19. The DRTKN and ITKN authenticate using their device Authenticated Public Keys. Each DRTKN generates a local key pair and sends the public key to the ITKN during the synchronization process. That key is signed by the ITKN and then saved to disk. (See the Secret Sharing scenario for more information) 20. The ITKN considers itself initialized when it has updated at least one MTKN and however many DRTKNs are selected by the user.
  • Management Module asks ITKN to secret share MK, AKS. Secrets are saved to disk, along with E M K (IAuthPubKey and [ILocal
  • the device needs to be rebooted to start normal operation.
  • the CPU reads the E LpubK (MK) from the file system.
  • the encrypted MK is sent to the ITKN.
  • the CPU tells the DPP to ask the ITKN for the MK.
  • the ITKN sends the decrypted MK to the DPP over the secure channel.
  • the loaded MK is used for both incoming and outgoing key material traffic.
  • the CPU reads the E MK (CK), E MK (crypto config db), and the E MK (Cryptainer certificates) and stores them in memory in an encrypted form
  • the device checks with the Cryptainer masters if anything has changed via MK.
  • Uninitialized MTKN decrypts and loads MTKN-AKS.
  • MTKN-A establishes secure channel w/ ITKN. 3. MTKN-A requests AKS change.
  • ITKN changes MTKN entry in AKS.
  • MTKN establishes secure channel w/ ITKN
  • MTKN sends ITKN update request, using DR1 , DR2, DR3.
  • Management module sends secrets to ITKN, which creates secret recovery requests (this is the secret recovery, but initiated by ITKN):
  • DRTKN 1 checks ITKN Auth PubKey w/ Decru Public Key, and checks signature on ITKN local public key and secret.
  • DRTKN1 decrypts Secret-1 , and returns E ITKN , oca ,(nonce and Secretl) 11. Repeat process with DRTKN2 and DRTKN 3.
  • ITKN decrypts responses from DRTKNs, verifies nonce.
  • ITKN recovers MK by Secretl xor Secret2 xor Secret3.
  • ITKN enters DRTKN replacement mode.
  • ITKN signs and asks Management module to save DR Local PubKey.
  • Management Module and ITKN redo secret sharing (Basic Procedure 5)
  • New ITKN initializes new local key pair.
  • DRTKN-A sends AKS and MK to new ITKN, encrypted with ITKN Local Key.
  • ITKN saves new E LPubK (MK).
  • Management Module asks CryptoCard to send E SK (IAuthPubKey and [ILocal PubKey] IAuth ) to ITKN.
  • E SK IAuthPubKey and [ILocal PubKey] IAuth
  • ITKN verifies old ITKN certificate.
  • Management Module loads old signed DR Local Public Keys into ITKN
  • ITKN verifies and signs each with new ITKN Local Key Pair and MM saves to disk.
  • the user attaches the device's MTKN to a Mgmt Station
  • new Cryptainer can be created without the need for MTKN.
  • the MK needs to be decrypted using the old one and encrypted using the new one.
  • the CPU reads the ENC LPubK [MK] from the file system.
  • the encrypted MK is sent to the ITKN.
  • the CPU tells the DPP to ask the ITKN for the MK.
  • the ITKN sends the decrypted MK to the DPP over the secure channel.
  • the Administrator changes the DPP mode of operation to maintenance mode.
  • the MTKN tells the DPP to generate a new MK.
  • the DPP stores this new key as the Outgoing Master Key.
  • the device loads all the ENC 0 ⁇ d . M ⁇ [CK] into the DPP and reads the ENC New . MK [CK].
  • the Master notifies the slaves and access to the Cryptainer is blocked
  • the Master changes the Cryptainer Key and re-encrypts the Cryptainer using the new key Create Master/Slave Devices
  • Master fully initialized. Master DRTKNs are introduced to Slave ITKN.
  • Master DRTKNs recover Master MK and send to Slave ITKN.
  • MK can now be used for Master to send information to Slave.
  • Enc(CK) look the same in both dbs.
  • Master MTKN shuts off DB duplication to slave.
  • MTKN authorizes Cryptainer set to Personal SmartCard key store.
  • An uninitialized Personal SmartCard generates a key pair.
  • the Crypto Database (CDB) is used to store the relationship between users, Cryptainers, and keys.
  • the implementation should support the following features:
  • the CDB should either provide a key or deny access
  • the data in the CDB should be secure - the CPU on the motherboard should not be able to examine keys, modify keys, 3. Changes in Access Control should be done in a secure way
  • the CDB (Crypto Database) is stored in the general purpose ACL structure (the ACL structure has three DAG's: Principals, Objects, and Permissions). 1. Cryptainers are stored as objects, and Users are associated with the Cryptainer and are given the appropriate Permissions.
  • Cryptainer's properties is the CK - specifically, store ENC MK (CK) 3.
  • Each Cryptainer has an Owner. Only the Owner controls access rights to the Cryptainer. 4. Administrators are allowed to create Cryptainers, but are not allowed to modify them. After creation only the Owner can modify them.
  • the Cryptainer is added to the Objects DAG 2.
  • An owner is associated with the Cryptainer
  • the user's ACL is checked to see if the user has permission
  • the CDB (Crypto Database) is stored in the general purpose ACL structure (the ACL structure has three DAG's: Principals, Objects, and Permissions).
  • Cryptainers are stored as objects, and Users are associated with the Cryptainer and are given the appropriate Permissions. 2. Each User has a "Key Store” - the store associates Cryptainers available to the user with keys.
  • the keys in the Key Store are stored as ENC UserPubK (ENC MK (CK))
  • Each Cryptainer has an Owner. Only the Owner controls access rights to the Cryptainer. 5. Administrators are allowed to create Cryptainers, but are not allowed to modify them. After creation only the Owner can modify them. Scenarios - Advanced Features
  • the Cryptainer is added to the Objects DAG
  • the owner may select one or more Recovery Agents, and a Secret Sharing Schema.
  • the ENC MK (CK) secret is split according to the Secret Sharing Schema and added to the Key Stores of the Recovery Agents.
  • the Owner provides the CK encrypted with the MK
  • the Owner provides the CK encrypted with the MK
  • ENC UserPubK (ENC MK (CK)) for the Cryptainer is sent to the user.
  • the Owner provides the CK encrypted with the MK. Note: a User can be added to a group only by an Owner of the associated Cryptainers.
  • the necessary number of Recovery Agents (as defined in the Cryptainer's creation process) should provide their part of the shared secret.
  • the recovered ENC MK (CK) is added to the (new) owner's key store.
  • Each group has a key pair
  • a Cryptainer's Key should either be kept in the device or outside of the device. It does not make sense that some of the Cryptainer's Users keep the key on the device and some keep it on a smart card.
  • the system can operate in a range of security levels. Usually, there is a trade-off between administration effort and security and between cost and security.
  • the highest level of security requires separation of the keys from the data. This can be done by handing the keys to end-users as described in the "Advanced Crypto DB" framework.
  • PKI Smart card this smart card stores its owner's authentication information and a Key Pair, and is capable of running RSA internally.
  • the public key is used to encrypt the user's key on the device. Without the user's smart card reading the data is as difficult as breaking the block cipher.
  • This solution requires a smart card reader and a smart card for all the users who are interested in this solution.
  • Software must be installed on the users' PC's.
  • virtual smart card implementation e.g. RSA SecurelD+Web Passport.
  • Smart card - this smart card stores its owner's authentication information and a Key Pair. It is not capable of running RSA.
  • the RSA functions run on user's PC CPU. It is less secure than the first one because the user's private key is given in clear text to the user's CPU.
  • This smart card is much cheaper ( ⁇ $3 as opposed to ⁇ $18). As before, this solution requires a smart card reader and a smart card for all the users who are interested in this solution. Software needs to be installed on the users' PC's.
  • the secret key is shared between the crypto device and the key server.
  • the key server releases its part of the secret only after explicit permission from the user. This solution is easier to manage and it provides higher level of security compared to the solution without it.
  • Random bits are generated by a TRNG located on the DPP.
  • the bits are encrypted using the DPP's AKS (see below). Bits from the TRNG are used to seed any PRNG in the system ⁇
  • the goal of this document is to describe the process of checksum computation for both NFS and CIFS projects. To improve performance, it is preferred to offload checksum computation to hardware. Some of the computation can be offloaded to the Ethernet NIC. Other computation (in particular, for UDP packets) are offloaded to the DPP hardware.
  • TCP Used for CIFS 161 and NFS 162 over TCP 163.
  • NIC Checksum computed by the NIC. It is advantageous to check the checksum again, just on the payload. This requires an additional stream of information from the TCP layer upwards.
  • the checksum over the payload is computed by the DPP and saved inside MBufs that hold the UDP packet. After the UDP layer 164 has added the UDP headers, use the precomputed payload checksum to compute the complete UDP packet checksum, store the result in the packet, and forward it to the IP layer 165.
  • the result should be a checksum of the payload only. If necessary, also store the offset, i.e. whether the UDP header length is odd or even.
  • NFS calls the DPP to decrypt the payload and compute the checksum over the payload. It then compares the result with the checksum passed from the UDP layer.
  • the NFS proxy decrypts and encrypts data respectively. In either case, the NFS proxy makes the crypto hardware compute the post-crypto checksum
  • the UDP output function extracts the checksum from the mbuf that it received. Once it has the checksum for the udp payload, it fixes the checksum value taking into account the header fields including a pseudo-IP header. The checksum is computed including the src IP address and destination IP address. The headers for UDP and the 2 IP addresses are of even length. This correct checksum value is given by:
  • NewCksum ⁇ (Old_Cksum + sum of 16 bit words in the headers) where + is done with end around carry.
  • the new value is written to the right location in the UDP header and the packet is sent out just like any other normal packet.
  • the UDP input function which receives the packet, fixes the checksum to remove the effects of the UDP header by subtracting out the header sum as follows:
  • NewCksum ⁇ (Old_Cksum) - sum of 16 bit words in the headers where the - takes into account end around carry. Then, the UDP headers are stripped from the mbuf and the new checksum value is written into the mbuf. Then the mbuf is sent off to the so_recv function.
  • the nfs proxy extracts the checksum value from the mbuf. Now irrespective of whether the system is reading from or writing to disk, data are encrypted/decrypted only on the outgoing side.
  • the preferred embodiment employs b. above, i.e. compute both the pre and post crypto checksums simultaneously.
  • a non-aligned read request from the client is handled as follows (see Fig. 17):
  • a nonaligned write request to disk involves the following steps
  • the first goal is done in software and the last two are done with hardware support as shown in Fig. 18, where data from the client 180 are converted to plain text in a temporary buffer 181 and where encrypted data are written to disk 182.
  • a checksum process verifies the received data 183, fixing edge effects 184 as discussed above, using the pre crypto checksum 185 and post crypto checksum 186, which is the sent value 187.
  • the hardware must compute the pre and post checksum of all the data it is handling. It does not have to worry about starting or ending the check-summing process at specific locations.
  • the checksum for the encrypted data being sent to the disk is the post crypto checksum given by hardware.
  • Another solution is to pre-allocate a fixed area in memory where the hardware writes the 32-bit value into a location indexed by the descriptor number. The software should examine this location only after it is sure that the corresponding crypto operation has been completed.
  • the application layer computes the payload checksum using crypto hardware and writes it down as the first two bytes of the data field of the mbuf. It also writes the next two bytes of the mbuf data with a special status word that indicates that this is a packet whose checksum must be fixed.
  • the socket layer forwards the mbuf to the UDP layer.
  • the UDP layer computes the checksum for the payload only by subtracting out the effect of the UDP header. Then, while stripping the UDP headers, it leaves the last four bytes of the
  • the socket layer forwards the mbuf to the nfs layer, which strips the first four bytes of the mbuf data to retrieve the checksum and status.
  • the Mbuf structure has a 16-bit checksum field, which is used if checksum is computed by a hardware accelerator. Further, there is a flag bit in the Mbuf that indicates whether the checksum data in the mbuf is valid or not.
  • the application layer computes the payload checksum using crypto hardware and writes it down as the 2-byte csum_data field of the mbuf. It also sets the csum_valid bit of the mbuf data.
  • the socket layer forwards the mbuf to the UDP layer.
  • the UDP layer computes the checksum for the payload only, by subtracting out the effect of the UDP header. Then, after stripping the UDP headers, it writes the csum_data field of the mbuf and sets the valid bit. This mbuf is sent to the layer.
  • the socket layer forwards the mbuf to the nfs layer, which retrieves the checksum from the mbuf field.
  • Both the socket layer and the UDP layer below it accept a control mbuf parameter as part of their 'so send' and 'udp_output' and interface. Write the checksum in this control mbuf along with status.
  • the socket layer hands off the control mbuf to the layer below without examining it.
  • the UDP layer can examine this control mbuf to get the cecksum for the data, fix it, and then write the correct checksum value in the UDP header.
  • the so_recv interface also has a control mbuf parameter. So is for sending the checksum up the stack.
  • the udp layer creates this control mbuf and writes the payload checksum in it along with status.
  • the socket layer forwards this control I mbuf to the application.
  • the application layer reads the checksum and frees the control mbuf.
  • Methods a. and c. above allow a status word along with the checksum to be communicated across the layers. This is useful to turn on the checksum fix selectively only if the sender is the device proxy. It is possible to leave the checksum fix feature always on for all udp packets, if the device proxy is the only application using udp.
  • Method b. above also allows a limited form of status in the mbuf flags by setting or unsetting the csum__valid bit. It is possible to avoid the status bytes in a. and c. by examining the udp payload to check if it is from the device proxy.
  • nfs proxy to take into account hardware check summing and for implementing one of the above three methods to sending and receiving checksum values.
  • the udp layer more specifically the udp_usrreq.c file containing the udp input and output functions
  • Method b. is presently preferred because it is the easiest to implement.
  • the hardware is going to compute the checksum as:
  • level-3 certification requires identity-based authentication before execution of any crypto-related operation.
  • this means authentication is required for MK and AKS operations, CK operations including context setting, and encryption and decryption of data.
  • the preferred system includes an x86 board 190 with a PCI DPP 191.
  • the PCI card includes an FPGA 192 that contains the PCI core 193, a command FIFO 194, RAM 195, crypto engine 199, and interfaces to SRAM 196, Flash 197, and a Micro Controller 198.
  • the Micro Controller is a typical smart card controller. It contains a processing unit, PKI module, 3DES module, RAM, and EEPROM.
  • a (slow) serial communication line connects the FPGA to the Micro Controller.
  • a user can assume one of the following roles: i. Crypto Officer - this user is allowed to load MK, and modify users. ii. Crypto User - this user is allowed to do all operations except for MK load, and users modification, iii. Maintenance Role - this user is allowed to do maintenance work.
  • the DPP has several modes of operation: i. Un-initialized Mode - the module stays in this mode until a MK is loaded by a Crypto Officer ii. Initialized Mode - the module is in this mode after a valid MK was loaded iii. Maintenance Mode - when a user assumes a maintenance role. All key material is zeroized upon entering or exiting this mode. iv. In-session Mode - there is an active session (a user is logged in) v. No-session Mode - no active session (no user is logged in)
  • Micro Controller RAM ii This RAM is zeroized when necessary 10.
  • Device Public Key is loaded into the Micro Controller and cannot be modified after the card left the factory.
  • the FPGA doesn't initiate communication with the Micro Controller. The initiation is controlled by the DPP's user (client).
  • the Micro Controller output (see Table "A” below) is prefixed in such a way that the FPGA can direct the output to the right location
  • the DPP exposes a register that signals if the Micro Controller is busy or not. It is the client's responsibility not to send requests to the Micro Controller when it is busy.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système de protection fondé sur le cryptage pour le stockage des données de réseaux. Ce système sépare la capacité d'accès à la mémoire de la capacité d'accès aux données mémorisées. Sur le plan logique, l'invention comprend un dispositif qui possède deux interfaces de réseau, à savoir une interface de réseau en texte en clair qui se connecte à un ou plusieurs clients, et l'autre interface qui est une interface de réseau sécurisée qui est connectée à un ou plusieurs serveurs à mémoires persistantes. D'un point de vue fonctionnel, chaque interface de réseau supporte de multiples noeuds de réseau. En d'autres termes, l'interface de réseau en texte en clair supporte de nombreuses machines de clients et l'interface de réseau sécurisé supporte un ou plusieurs serveurs à mémoires.
PCT/US2002/015421 2001-05-17 2002-05-14 Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux WO2002093314A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US10/478,386 US8335915B2 (en) 2002-05-14 2002-05-14 Encryption based security system for network storage
AU2002305607A AU2002305607A1 (en) 2001-05-17 2002-05-14 Encryption based security system for network storage
EP02734438A EP1388061A4 (fr) 2001-05-17 2002-05-14 Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux
US11/350,047 US8423780B2 (en) 2002-05-14 2006-02-07 Encryption based security system for network storage

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29208801P 2001-05-17 2001-05-17
US60/292,088 2001-05-17

Publications (2)

Publication Number Publication Date
WO2002093314A2 true WO2002093314A2 (fr) 2002-11-21
WO2002093314A3 WO2002093314A3 (fr) 2003-05-15

Family

ID=23123156

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/015421 WO2002093314A2 (fr) 2001-05-17 2002-05-14 Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux

Country Status (3)

Country Link
EP (1) EP1388061A4 (fr)
AU (1) AU2002305607A1 (fr)
WO (1) WO2002093314A2 (fr)

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006030296A1 (fr) 2004-09-16 2006-03-23 Nokia Corporation Systemes et procedes d'utilisation de systeme de nom de domaine securise fonde sur une confiance preexistante
US7162647B2 (en) 2004-03-11 2007-01-09 Hitachi, Ltd. Method and apparatus for cryptographic conversion in a data storage system
US7272727B2 (en) 2005-04-18 2007-09-18 Hitachi, Ltd. Method for managing external storage devices
US7383462B2 (en) 2004-07-02 2008-06-03 Hitachi, Ltd. Method and apparatus for encrypted remote copy for secure data backup and restoration
US7428642B2 (en) 2004-10-15 2008-09-23 Hitachi, Ltd. Method and apparatus for data storage
US7801871B2 (en) 2005-08-09 2010-09-21 Nexsan Technologies Canada Inc. Data archiving system
US7886158B2 (en) 2005-09-08 2011-02-08 Hitachi, Ltd. System and method for remote copy of encrypted data
US8042155B1 (en) 2006-09-29 2011-10-18 Netapp, Inc. System and method for generating a single use password based on a challenge/response protocol
US8171307B1 (en) 2006-05-26 2012-05-01 Netapp, Inc. Background encryption of disks in a large cluster
US8190905B1 (en) 2006-09-29 2012-05-29 Netapp, Inc. Authorizing administrative operations using a split knowledge protocol
US8196182B2 (en) 2007-08-24 2012-06-05 Netapp, Inc. Distributed management of crypto module white lists
US8245050B1 (en) 2006-09-29 2012-08-14 Netapp, Inc. System and method for initial key establishment using a split knowledge protocol
US8255704B1 (en) 2006-08-24 2012-08-28 Netapp, Inc. Pool encryption with automatic detection
US8352726B2 (en) 2003-11-07 2013-01-08 Netapp, Inc. Data storage and/or retrieval
US8607046B1 (en) 2007-04-23 2013-12-10 Netapp, Inc. System and method for signing a message to provide one-time approval to a plurality of parties
US8611542B1 (en) 2007-04-26 2013-12-17 Netapp, Inc. Peer to peer key synchronization
US8824686B1 (en) 2007-04-27 2014-09-02 Netapp, Inc. Cluster key synchronization
US8898452B2 (en) 2005-09-08 2014-11-25 Netapp, Inc. Protocol translation
US9774445B1 (en) 2007-09-04 2017-09-26 Netapp, Inc. Host based rekeying

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4588991A (en) * 1983-03-07 1986-05-13 Atalla Corporation File access security method and means
US5065429A (en) * 1989-04-03 1991-11-12 Lang Gerald S Method and apparatus for protecting material on storage media
US5150407A (en) * 1991-12-16 1992-09-22 Chan Steve S C Secured data storage devices
US5235641A (en) * 1990-03-13 1993-08-10 Hitachi, Ltd. File encryption method and file cryptographic system
US5235642A (en) * 1992-07-21 1993-08-10 Digital Equipment Corporation Access control subsystem and method for distributed computer system using locally cached authentication credentials
US5720034A (en) * 1995-12-07 1998-02-17 Case; Jeffrey D. Method for secure key production
US5940507A (en) * 1997-02-11 1999-08-17 Connected Corporation Secure file archive through encryption key management
US6175924B1 (en) * 1997-06-20 2001-01-16 International Business Machines Corp. Method and apparatus for protecting application data in secure storage areas
US6185684B1 (en) * 1998-08-28 2001-02-06 Adobe Systems, Inc. Secured document access control using recipient lists

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6981141B1 (en) * 1998-05-07 2005-12-27 Maz Technologies, Inc Transparent encryption and decryption with algorithm independent cryptographic engine that allows for containerization of encrypted files

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4588991A (en) * 1983-03-07 1986-05-13 Atalla Corporation File access security method and means
US5065429A (en) * 1989-04-03 1991-11-12 Lang Gerald S Method and apparatus for protecting material on storage media
US5235641A (en) * 1990-03-13 1993-08-10 Hitachi, Ltd. File encryption method and file cryptographic system
US5150407A (en) * 1991-12-16 1992-09-22 Chan Steve S C Secured data storage devices
US5235642A (en) * 1992-07-21 1993-08-10 Digital Equipment Corporation Access control subsystem and method for distributed computer system using locally cached authentication credentials
US5720034A (en) * 1995-12-07 1998-02-17 Case; Jeffrey D. Method for secure key production
US5940507A (en) * 1997-02-11 1999-08-17 Connected Corporation Secure file archive through encryption key management
US6175924B1 (en) * 1997-06-20 2001-01-16 International Business Machines Corp. Method and apparatus for protecting application data in secure storage areas
US6185684B1 (en) * 1998-08-28 2001-02-06 Adobe Systems, Inc. Secured document access control using recipient lists

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1388061A2 *

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8352726B2 (en) 2003-11-07 2013-01-08 Netapp, Inc. Data storage and/or retrieval
US8250376B2 (en) 2004-03-11 2012-08-21 Hitachi, Ltd. Method and apparatus for cryptographic conversion in a data storage system
US7162647B2 (en) 2004-03-11 2007-01-09 Hitachi, Ltd. Method and apparatus for cryptographic conversion in a data storage system
US7240220B2 (en) 2004-03-11 2007-07-03 Hitachi, Ltd. Method and apparatus for cryptographic conversion in a data storage system
US7774618B2 (en) 2004-03-11 2010-08-10 Hitachi, Ltd. Method and apparatus for cryptographic conversion in a data storage system
US7383462B2 (en) 2004-07-02 2008-06-03 Hitachi, Ltd. Method and apparatus for encrypted remote copy for secure data backup and restoration
EP1790150A4 (fr) * 2004-09-16 2014-09-03 Nokia Corp Systemes et procedes d'utilisation de systeme de nom de domaine securise fonde sur une confiance preexistante
WO2006030296A1 (fr) 2004-09-16 2006-03-23 Nokia Corporation Systemes et procedes d'utilisation de systeme de nom de domaine securise fonde sur une confiance preexistante
US7428642B2 (en) 2004-10-15 2008-09-23 Hitachi, Ltd. Method and apparatus for data storage
US8301909B2 (en) 2005-04-18 2012-10-30 Hitachi, Ltd. System and method for managing external storage devices
US7908489B2 (en) 2005-04-18 2011-03-15 Hitachi, Ltd. Method for managing external storage devices
US7272727B2 (en) 2005-04-18 2007-09-18 Hitachi, Ltd. Method for managing external storage devices
US7801871B2 (en) 2005-08-09 2010-09-21 Nexsan Technologies Canada Inc. Data archiving system
US8843461B2 (en) 2005-08-09 2014-09-23 Nexsan Technologies Canada Inc. Data archiving system
US8086578B2 (en) 2005-08-09 2011-12-27 Nexsan Technologies Canada Inc. Data archiving system
US8898452B2 (en) 2005-09-08 2014-11-25 Netapp, Inc. Protocol translation
US7886158B2 (en) 2005-09-08 2011-02-08 Hitachi, Ltd. System and method for remote copy of encrypted data
US8171307B1 (en) 2006-05-26 2012-05-01 Netapp, Inc. Background encryption of disks in a large cluster
US8255704B1 (en) 2006-08-24 2012-08-28 Netapp, Inc. Pool encryption with automatic detection
US8190905B1 (en) 2006-09-29 2012-05-29 Netapp, Inc. Authorizing administrative operations using a split knowledge protocol
US8245050B1 (en) 2006-09-29 2012-08-14 Netapp, Inc. System and method for initial key establishment using a split knowledge protocol
US8042155B1 (en) 2006-09-29 2011-10-18 Netapp, Inc. System and method for generating a single use password based on a challenge/response protocol
US8607046B1 (en) 2007-04-23 2013-12-10 Netapp, Inc. System and method for signing a message to provide one-time approval to a plurality of parties
US8611542B1 (en) 2007-04-26 2013-12-17 Netapp, Inc. Peer to peer key synchronization
US8824686B1 (en) 2007-04-27 2014-09-02 Netapp, Inc. Cluster key synchronization
US8196182B2 (en) 2007-08-24 2012-06-05 Netapp, Inc. Distributed management of crypto module white lists
US9774445B1 (en) 2007-09-04 2017-09-26 Netapp, Inc. Host based rekeying

Also Published As

Publication number Publication date
AU2002305607A1 (en) 2002-11-25
EP1388061A2 (fr) 2004-02-11
EP1388061A4 (fr) 2010-11-03
WO2002093314A3 (fr) 2003-05-15

Similar Documents

Publication Publication Date Title
US8423780B2 (en) Encryption based security system for network storage
CA2525249C (fr) Extension de la securite d'un reseau de fichiers reparti
US8397083B1 (en) System and method for efficiently deleting a file from secure storage served by a storage system
JP5067771B2 (ja) セキュアネットワークファイルアクセス制御システム
JP4896400B2 (ja) セキュアなファイルシステムサーバーのアーキテクチャ及び方法
US7334124B2 (en) Logical access block processing protocol for transparent secure file storage
US7865741B1 (en) System and method for securely replicating a configuration database of a security appliance
EP1388061A2 (fr) Systeme de protection fonde sur le cryptage pour le stockage des donnees de reseaux
US8245050B1 (en) System and method for initial key establishment using a split knowledge protocol
US8196182B2 (en) Distributed management of crypto module white lists
EP2319225A2 (fr) Systèmes et procédés de base de données de sécurité à multiples niveaux haute performance sécurisée
US8190905B1 (en) Authorizing administrative operations using a split knowledge protocol
US6725370B1 (en) Sharing data safely using service replication
US9582676B2 (en) Adding or replacing disks with re-key processing
US8189790B2 (en) Developing initial and subsequent keyID information from a unique mediaID value
JP4133215B2 (ja) データ分割方法及びデータ復元方法並びにプログラム
Freeman et al. Design for a decentralized security system for network attached storage
Usharani Integrity and Privacy through Authentication Key Exchange Protocols for Distributed Systems
Blaze Transparent mistrust: OS support for cryptography-in-the-large
Che Designing and Implementing Kiwi: A Secure Distributed File System over HTTPS
Riedel et al. Paranoia vs. performance-a quantitative evaluation of storage system security
Luo et al. A security scheme for united storage network
Ofir Sharing and privacy using untrusted storage
Gharaibeh Integrating Security in FreeLoader Distributed File System

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002734438

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10478386

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2002734438

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP