Secure Untrusted Data Repository SUNDR

1
Secure Untrusted Data Repository (SUNDR)

• Jinyuan Li, Maxwell Krohn, David Mazieres, and
  Dennis Shasha
• NYU Department of Computer Science

2
Motivation

• Data integrity vs. Accessibility
• Unsatisfactory fences
• Fences are always not high enough
• Inconvenient or even impractical
• Has to manually assess damages after attack
• Protect users files while reduce the need to
  trust storage server

3
SUNDR secure network file system

• Remote file storage like NFS
• Cryptographic file protection
• Vesting the authority to write files in users
  publics keys
• Distinction between server administration and
  file administration
• Avoiding complete administrative control
• Benefits
• More secure
• Neednt worry about mistakes of administrator
• Server may behave maliciously
• Recovery from untrusted clients file caches

4
SUNDR Architecture
5
Consistency

• Fetch-modify consistency (correct server)
• A fetch reflects exactly the authorized
  modifications that happened before it
• Fork consistency (dishonest server)
• fork entire history and multiple file system
• Honest clients will discover the attack if they
  communicate with each other
• Fork consistency is fairly useful
• Trusted consistency server
• Time stamp box

6
Straw-man file system

• Global lock
• Complete ordered list of every fetch or modify
  operation ever performed
• Every signature contains not just the operation
  but the complete history of all operations before
  it

7
Serialized SUNDR
8
Protocol for consistency

• Start
• Acquire global lock and download latest version
  structure for each user and group (version
  structure list, or VSL)
• Compute a new version structure
• i-handle
• Fetch simply copy previous i-handle
• Modify computes and includes new i-handles
• Version vector
• Zp?Ypp, for each principal p
• Zu?Zu1, Zg?Zg1
• Check for consistency
• VSL contain us previous version structure
• Totally ordered
• Commit

9
(No Transcript)
10
Concurrent SUNDR

• Client pre-declare a fetch or modify operation
  before receiving VSL
• us next version number
• Hash of us VSL entry
• List of modification (possibly)
• Server reply the pending version list (PVL)
• Honest totally order operations
• Client verifying for no conflict
• Conflict occurs only in read-after-write case

11
References

• Secure distributed file systems
• http//www-users.cs.umn.edu/vkher/sec.html