D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 99--104, May 2001.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....group. Under the assumption that strictly fewer than one third of the servers are compromised (a condition that is provably necessary [23] BFS guarantees the integrity of file data and directory metadata. However, it does not attempt to provide privacy of file or directory information. SUNDR [26] is a file system that offers strong integrity and privacy guarantees from the server that provides data storage. It does this by placing full trust in all client machines, which implement the entirety of the file system semantics on top of block level storage provided by the server. Since the ....

D. Mazires and D. Shasha, "Don't Trust Your File Server", 8th HotOS, May 2001, pp. 113-118.

....System Considerations No changes to File Server. SiRiUS must add security to existing network file systems with no change to the software or hardware of the servers. This consideration is fulfilled by layering SiRiUS over existing network file systems. Existing secure file systems (such as SUNDR [19]) that work at the file system block level require extensive modification to the file server. Therefore, SiRiUS should work at a higher level, using files as its atomic unit. Fulfilling this requirement makes it possible for users to install SiRiUS without the support of the file server ....

....with other users of the system. Existing cryptographic file systems [2, 35, 1, 7, 13] limit their own usefulness because they either provide very coarse sharing at the directory or file system level or fail to distinguish between read and write access. File systems that do provide per file sharing [24, 19, 29, 18] rely on a trusted authentication mechanism residing on the file server, which precludes their use in settings where users have no administrative control over the server. Minimal Client Software. A SiRiUS user should need to run only a user level daemon. Users should not be required to upgrade or ....

[Article contains additional citation context not shown here]

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the Eighth Workshop on Hot Topics in Operating Systems, pages 113--118, May 2001.

....secure against active adversaries. We have described how an on chip trusted cache can be used to significantly improve the e#ciency of the log hash scheme, and also described how the scheme can be generalized to a hierarchical scheme for further e#ciency improvement. Recent papers, 7] 5] [11], 10] describe systems in which a trusted program, running in a trusted computing base (TCB) uses hash trees to maintain the integrity of data stored on an untrusted storage. The untrusted storage is typically some arbitrarily large, easily accessible, bulk store in which the program regularly ....

....The untrusted storage is typically some arbitrarily large, easily accessible, bulk store in which the program regularly stores and loads data which does not fit in a cache in the TCB. In [7] the program runs on a trusted processor; the untrusted storage is the external random access memory (RAM) [11] and [10] describe a file system and database respectively, in which the program runs on a protected client and the data is maintained on an untrusted server. We have compared our log hash and hierarchical log hash schemes with the hash tree based schemes of [7] and a MAC scheme and shown that the ....

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th Workshop on Hot Topics in Operating Systems, May 2001.

....performing DMA. This class of bugs would be more difficult and time consuming to find without the effective use of the IO MMU. Note that buggy or malicious drivers can still corrupt data in I O buffers during the transfer between client and device. Techniques as they are proposed for SUNDR [MS01] could be used as a protection here. Furthermore, as there exists only one PCI address space which is shared by all PCI devices, one driver could corrupt or sniff another s buffers. However, this danger is minimised by sparsity: a driver would have to guess the location of other buffers in the ....

David Mazieres and Dennis Shasha. Don't trust your file server. In Proceedings of the 8th Workshop on Hot Topics in Operating Systems (HotOS), pages 113--118, Elmau, Germany, May 2001.

....as an online checker when integrity checks need to be performed frequently, and as an o#ine checker when checks can be performed less frequently. The performance of the checker is expected to be close to the better scheme for every checking period. 1 Introduction Recent papers, GSC 03] MS01] MVS00] describe systems in which a trusted program, running in a trusted computing base (TCB) maintains data stored on untrusted storage. The untrusted storage is typically some arbitrarily large, easily accessible, bulk store in which the program regularly stores and loads data which does ....

....storage is typically some arbitrarily large, easily accessible, bulk store in which the program regularly stores and loads data which does not fit in a cache in the TCB. In [GSC 03] the program runs on a trusted processor; the untrusted storage is the external random access memory (RAM) MS01] and [MVS00] describe a file system and database respectively, in which the program runs on a protected client and the data is maintained on an untrusted server. Each of the systems provides strong data integrity guarantees without trusting the storage. The systems use Merkle (hash) trees ....

[Article contains additional citation context not shown here]

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th Workshop on Hot Topics in Operating Systems, May 2001. 26

....is always susceptible to attacks mounted by revoked users in collusion with the server, unless a third (trusted) party is involved in each read and write access. Finally, the server could mount the following attack, which we consider very difficult for the system to handle. In a forking attack [31], a server forks the state of a file between users. That is, the server separately maintains file updates for the users. The forked users never see each other s changes, and each user believes its state reflects reality. A higher level Byzantine agreement protocol, which is potentially expensive, ....

D. Mazieres and D. Shasha. Don't trust your file server. In HotOS, pages 113--118, May 2001.

....group. Under the assumption that strictly fewer than one third of the servers are compromised (a condition that is provably necessary [23] BFS guarantees the integrity of file data and directory metadata. However, it does not attempt to provide privacy of file or directory information. SUNDR [26] is a file system that offers strong integrity and privacy guarantees from the server that provides data storage. It does this by placing full trust in all client machines, which implement the entirety of the file system semantics on top of block level storage provided by the server. Since the ....

D. Mai6res and D. Shasha, "Don't Trust Your File Server", 8th HotOS, May 2001, pp. 113-118.

....networked file systems have addressed one or more aspects of security. Blaze s Cryptographic File System [5] encrypts a single user s files on a client machine and stores the encrypted files on a server. BFS [8] replaces a single NFS server with a Byzantine faulttolerant replica group. SUNDR [27] guarantees file privacy, integrity, and consistency despite a potentially malicious server, but it does this by placing trust in all client machines (tinlike Farsite, which requires only that each user trust the client machine he is directly using) SFS [26] constructs self certifying pathnames ....

D. Mazires and D. Shasha, "Don't Trust Your File Server", 8th HotOS, May 2001.

....are embedded in the blocks [4] However, both PFS and TCFS do not detect replays of old blocks. Mazieres and Shasha described a design of Secure Untrusted Data Repository, SUNDR, which has a storage organization similar to SFSRO, but stores the root hash in a secure location (presumably a client) [13]. Unlike GnatDb, the main focus of the design of the above file systems is the ease of integration of secrecy and tamper detection to a file system. Consequently, their design is not optimized for low memory consumption and they do not support atomic and durable updates. Blum et al. considered ....

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th Workshop on Hot Topics in Operating Systems, May 2001. Schloss E1mau, Germany.

....For example, CFS [3] encrypts data, but does not easily permit authentication of data or sharing with other users. Systems such as SFS RO [18] and NASD [12, 13] use encryption to provide network security and authentication, but store data in the clear. Recently, systems such as TCFS [6] and SUNDR [19] have incorporated both authentication and encryption, but at a relatively high penalty to performance. We have developed a security system for networkattached storage that relies upon strong cryptography to protect data stored in a distributed storage system. Our system stores and transfers all ....

....requires that users trust file systems to store and return file data correctly. SFS RO [18] does not impose such a requirement, but it also forbids remote clients from writing to the file system, limiting writes to users on the server with access to the server s private key. The SUNDR file system [19] will address these issues by providing strong encryption and authentication for all file system users; however, its use of publickey encryption will subject it to the same performance issues we discuss in this paper. 2.2 Protecting Data on Disk While most file system security has focused on ....

[Article contains additional citation context not shown here]

D. Mazi eres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOSVIII) , pages 99--104, Schloss Elmau, Germany, May 2001.

....the minimum protection unit is a single file. 161 Some file systems, such as CFS [1] and Cryptfs [15] 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 [12] Other systems such as SNAD [7] SFS and SUNDR [6, 5], and NASD [3] 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 ....

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 99--104, Schloss Elmau, Germany, May 2001.

....interface or storage organization [20] It uses cryptographic hashes over all data and meta data blocks to detect any tampering with file system blocks. The block hashes are written to the same write ahead log as the meta data updates. PFS does not provide protection against replay attacks. SUNDR [11] is a network file system designed to run on untrusted servers. It supports both data encryption and verification using hash trees similar to SFS RO. TCSF [4] also supports both encryption and verification, but calculates a message digest on each block and cannot detect replay attacks. The ....

D. Mazieres and D. Shasha. Don't trust your file server. In In Proceedings of the 8th Workshop on Hot Topics in Operating Systems, May 2001. Schloss Elmau, Germany.

..... both systems use block level encryption (8 KB blocks for Cepheus, 4 KB for SNAD) to allow updates of the individual parts of larger files. A recent extension to Cepheus and SFS also assumes untrusted servers, and further seeks to detect attacks by the server on the integrity of stored data [Mazieres01]. For instance, one can detect when the server provides different versions of the same file to different users. 3.5 NASD Network Attached Secure Disks (NASD) Gobioff99a] proposes a distributed network of intelligent disks with a shared group server (that also handles metadata for directory ....

D. Mazieres and D. Shasha. Don't trust your file server. HotOS, May 2001.

....group, they are kept in lockboxes locked with the same group key. Thus users need to know only one key per group. long term keys are used to encrypt all files. A recent design also assumes untrusted servers, but further seeks to detect attacks by the server on the integrity of stored data [Mazieres01]. For instance, one can detect when the sever provides different versions of the same file to different users. 3.5 NASD Network Attached Secure Disks (NASD) Gobioff99a] proposes a distributed network of intelligent disks with a shared group server. Access for data objects on the disks is ....

D. Mazieres and D. Shasha. Don't trust your file server. HotOS, May 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 99--104, May 2001.

No context found.

David Mazieres, Dennis Shasha. Don't Trust Your File Server. In Proceedings of Workshop on Hot Topics in Operating Systems, 2001.

No context found.

David Mazieres and Dennis Shasha. Don't trust your file server. In 8th HotOS, pages 113--118, Elmau, Germany, May 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems, pages 99--104, 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems, pages 99--104, 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems, pages 99--104, 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII), pages 99--104, May 2001.

No context found.

D. Mazieres and D. Shasha. Don't trust your file server. In Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems, pages 99--104, 2001.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC