Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Li: Secure untrusted data repository.OSDI04
08-18-2009, 07:33 PM
Post: #1
Li: Secure untrusted data repository.OSDI04
Jinyuan Li, Maxwell Krohn, David Mazières, and Dennis Shasha. Secure Untrusted Data Repository (SUNDR). OSDI'04
Quote this message in a reply
09-08-2009, 09:45 PM
Post: #2
RE: Li: Secure untrusted data repository
http://www.usenix.org/events/osdi04/tech...http://www.usenix.org/events/osdi04/tech/full_papers/li_
Find all posts by this user
Quote this message in a reply
02-15-2011, 08:12 PM
Post: #3
RE: Li: Secure untrusted data repository.OSDI04
SUNDR stores data securely on untrusted servers over the network. The paper
organize the design of SUNDR into three level approaches step by step, which we
can learn in our work and paper writing.

SUNDR designed to be a network file system, but it is more convenient to be
implemented as a data store with simple interface like S3. And actually the
system calls are translated to series of fetch and modify operations. SUNDR is
more suitable to provide a library level interface to the applications rather
than a file system, although the application can implement the file system based
on the interface.

SUNDR is designed to as a data store on one server, its design makes it easy to
distribute the data store into multiple servers through the network. SUNDR makes
the server a kind of large hash table, which is natually suitable to be
distributed.

When solving the read-after-write conflict, SUNDR make the later reader to wait
for the fetched files to be committed. A faulty writer may slow down the other
readers, especially when there are lots readers. This problem may be more
serious when SUNDR is used over a slow network.
Quote this message in a reply
04-02-2011, 10:04 AM
Post: #4
RE: Li: Secure untrusted data repository.OSDI04
In this paper, the author designs a network file system to
store data securely on untrusted servers. The users are
granted the capability to detect the unauthorized file
modification. To achieve this, a fork consistency is
introduced.

Typically, if we want to store some data on the server, we
may attach a digit signature to the data. As long as our
signing algorithm is strong, the server or other users can
not forge a message and claims that it is our stored message
because the signature does not match. However, if we want
to share a piece of data and allow other users to update it,
the situation changes. For example, if A writes the data
and signs it. Then B writes it again. The server may cheat
A by claiming that it never received an update from B. The
fork consistency helps in this situation. The fetch and u
pdate of data in SUNDR are recorded as a history. When a
client performs these operations, it must sign the history.
If the server cheats A by saying that the data is never
updated by B. Then A may attach a signature on the data
without signing the update from B. Here, a conflict occurs
and the history of the data is separated into two branches.
The server must provide the clients with their branches.
When the branches grow, it is relatively hard for the
server to maintain it. Meanwhile, the clients are able to
communicate with each other to see whether they are getting
the consistent history data. In any event, the consequences
of an undetected server compromise are limited to
concealing users’ operations from each other after some
forking point; the server cannot tamper with, inject,
re-order, or suppress file writes in any other way.
Quote this message in a reply
Post Reply 


Forum Jump: