Integration with an OBSD File System
Although IFS may be used in any type of file system, we present a design to implement intra-file security for a file system based on Object Based Storage Devices (OBSDs). We are proposing the use of OBSDs for high-performance network-attached storage devices; this approach has similarities to Network-Attached Secure Disks (NASD). An OBSD-based file system is designed for high-performance computing workloads precisely the kinds of applications that benefit from intra-file security. Because OBSDs require strong security in order to keep data safe in storage and transit, we expand the end-to-end encryption capabilities by incorporating IFS.
OBSD-based storage systems have the potential to improve both file system performance and functionality by building a high-performance storage system from inexpensive storage components connected by high-speed networks. The main hardware component of the storage system is an object-based storage device—one or more disks (or other storage devices) managed by a single CPU and seen by the file system as a single device. Data is distributed across many OBSDs, with high bandwidth coming from large numbers of concurrently operating OBSDs.
Each OBSD is responsible for managing and allocating its own storage; requests to an OBSD are of the form “write (or read) this range of bytes from file X,” with low-level placement of the data and free space management left to the OBSD. High-level
information such as the striping pattern across OBSDs and translation of names to file identifiers are left to a metadata server (MS), which is accessed by the user only when a file is opened or closed. This file system design is shown in Figure 3.
The key advantage of OBSDs in a high-performance environment is the ability to delegate low-level block allocation and synchronization for a given segment of data to the device on which it is stored, leaving the file system to decide only on which OBSD a particular segment should be placed. In such a distributed file system, s-nodes are stored physically near the blocks they describe, avoiding extra traffic to central servers on distributed storage systems and amortizing I/O usage among the devices. OBSDs use their own allocation policies to manage local data, including file and s-node data, placing them for efficiency within
Figure 3: OBSD storage system architecture.
physical storage devices. Because s-nodes do not contain secrets, end-to-end encryption is provided to users without any extra involvement of the OBSD—the OBSD sends all file data and s-nodes in the clear on insecure networks. The security of encrypted data lies with the key management policy.
Authentication and Key Management
An authentication system is required for file system security, regardless of end-to-end encryption capabilities. Since we are focusing on support for intra-file encryption. However, we rely on an authentication system for distribution of encryption keys, so we briefly describe how such a system may be implemented.
A major role of a metadata server (MS) is to control access to the file system. When users wish to open a file, the MS checks file permissions before granting access. As a first step, client software authenticates a user’s identity, using standard authentication techniques such as Kerberos or cryptographic hashes. The MS proceeds to check permission for a requested file operation using the file system’s access control mechanism.
However, OBSDs handle read and write requests directly; in order to enforce access rights, OBSDs must also check identities and permissions as well. The overhead of maintaining and checking access permissions at each OBSD defeats the high-performance requirement, so an OBSD uses a more efficient method to check the validity of a client’s request. The MS generates tokens containing encoded access rights during open requests, and sends them to clients along with the file’s metadata. Clients present these tokens with their requests to OBSDs. By checking the permissions encoded in the token, an OBSD determines the validity of the request. Tokens are equivalent to capabilities used in NASD for the same purpose. In IFS, security information is included in the forwarded tokens. Access to encrypted segments is based on IFS group permissions, which we call s-groups.
An s-group contains a list of users and/or groups that may use the key for an encrypted segment; the creator of an encrypted segment specifies s-group members during the initial write. A key server (KS) manages s-groups separately from file-access group permissions normally associated with file services; the goal is to remove management of encryption from traditional file system administration. The KS is responsible for checking s-group permissions, and generating and storing keys. From a user’s viewpoint, calls to the MS involve both the MS and the KS, whether they reside on single or concurrent machines.
File I/O Interface
IFS uses standard POSIX file semantics by instrumenting interface libraries to handle security operations transparently. However, supporting encryption requires some new functions that allow writing of encrypted segments. Applications writing only unencrypted data and reading any data use the normal write and read function interfaces.
Reading encrypted data is transparent to the user. When reading data, users with a key see decrypted data when they read data; thus, applications reading data stored with IFS do not need any modifications, though they must be capable of dealing with garbage data in the data file—reads from encrypted segments of a file appear as random bits if the user lacks the proper key. If the user has the necessary key, the file system client transparently decrypts the file using keys supplied with authentication tokens. Only users with the proper key may decrypt secure segments and view the contents; the encoding of the token tells the OBSD whether or not to send s-nodes with data, so extra traffic is avoided when possible. Under IFS, the interface to the file system is extended to support encrypted writes. Encrypted segments remain read-only unless the user has encrypted write access, which is granted through IFS s-group permissions. Even for users with permission, encrypted writes are explicit. Two new system calls support encrypted writes. One function translates an s-group specification into an integer identifier. The identifier is used in subsequent calls to the secure write function, which is identical to the standard ‘C’ write function except for this additional argument. When writing encrypted segments, the file system client creates s-nodes for the corresponding blocks, and sends the s-nodes to the OBSD along with the blocks. When over-writing data in blocks already allocated to the file, the client must fetch and update the existing s-node (read-modify-write operation).
Unencrypted write requests to file blocks containing encryption must be carefully con-trolled, because users without encryption rights cannot overwrite the encrypted region of the block. To protect the integrity of encrypted data, it is impossible for users to write to encrypted segments using the traditional write function call. In order to minimize the latency of unencrypted writes, the OBSD quickly caches all data on writes, and during periods of inactivity discards changes to encrypted segments before committing the write. Essentially, this makes all encrypted segments read-only unless invoking the secure write function. This policy does not impact blocks without encrypted segments, but it effects the coherency of blocks that do—until the write is fully committed, multiple copies of a block reside in the file system. As a trade-off between performance and safety, we prefer that writes to encrypted segments do not occur unless made explicit, even for users with a key.
FILE SYSTEM SECURITY Applications
To support encryption of data within existing unencrypted files that have been migrated to an IFS file system or written with non-IFS legacy applications, an IFS-capable copy program can be provided to encrypt the appropriate portions of the file. This program would take as input an unencrypted file and a specification of the regions to be encrypted.
Databases that use a single large flat-file could easily benefit from IFS by encrypting those fields of the database that must be kept secret, while still maintaining single-file semantics for the whole database. Most databases support encrypted fields by simply supplying keys for particular fields; however, this approach requires a reasonable amount of support from the database system or the database queries to remain transparent to users. By using IFS, this process could be made transparent, particularly if databases exchanged information with the file system.
Many very large files used in military and government scientific work will also benefit from IFS. Removing the need to fragment files that naturally require multiple levels of security will simplify applications as well as data management; no longer will users need to create several files with different encryption levels and keep track of which ones are related and how. Eliminating fragmentation ensures high-performance sequential and random access.
Importantly, legacy applications can transparently be made IFS-capable, since the data formats and locations within the files remain unchanged even as portions of the data itself are encrypted.
IFS may also be used to transfer partial files in a distributed file system, as suggested by Muthitacharoen et al. By integrating IFS into a low-bandwidth distributed file system, users could gain secure access to their files even from slow clients.
Related Work
There have been many file systems and storage systems that provide higher security by encrypting files and metadata. Reidel, et al. provide a good framework for evaluating secure file systems; their work discusses file systems and the security that each provides.
Intra-file security is not one of their criteria; although they do discuss the granularity of key protection, the minimum protection unit is a single file.
Some file systems, such as CFS and Cryptfs, require users to manage their own
keys. This approach is simple, but is not suitable for IFS because of the sheer number
of keys required. Other systems such as SNAD, SFS and SUNDR, and
NASD automatically manage encryption keys, though they do not permit partial-file
encryption. Moreover, many of these systems, including NASD and SFS, store data on
the disk in an unencrypted form, using encryption only for authentication. The techniques
described in this paper are based on those used in SNAD—it provides strong protection by encrypting data end-to-end, leaving it in the clear only on the client.Intra-file security is particularly important for large, distributed file systems such as those enabled by NASD and object-based storage devices (OBSDs). Reed, et al. provide a method for strong authentication in such an environment in SCARED, providing an excellent platform for both standard security and the intra-file security proposed in this paper.
Conclusions
Secure file systems and distributed storage networks currently permit encryption only on a per-file or per-directory basis. However, there are many applications that would benefit from the ability to encrypt data in smaller pieces, using different keys to permit parts of a file to be read and written by different groups of users.
This paper presents a solution to this problem, by introducing a concept called intra-file security, and provides a high-level design for implementing it in a distributed file system and on individual servers within such a file system. Intra-file security uses additional metadata to maintain information about secure segments, allowing blocks of a file to be encrypted and decrypted individually on the client. A key management system provides group management facilities that are well adapted to the hierarchical nature of access to classified materials present in organizations requiring security.
0 comments:
Post a Comment
Thanks for your Valuable comment