Presentation is loading. Please wait.

Presentation is loading. Please wait.

SUNDR: Secure Untrusted Data Repository Jinyuan LiN.Y.U. Maxwell KrohnM.I.T. David MazièresN.Y.U. Dennis ShashaN.Y.U. OSDI 2004.

Similar presentations


Presentation on theme: "SUNDR: Secure Untrusted Data Repository Jinyuan LiN.Y.U. Maxwell KrohnM.I.T. David MazièresN.Y.U. Dennis ShashaN.Y.U. OSDI 2004."— Presentation transcript:

1 SUNDR: Secure Untrusted Data Repository Jinyuan LiN.Y.U. Maxwell KrohnM.I.T. David MazièresN.Y.U. Dennis ShashaN.Y.U. OSDI 2004

2 NYUSecure Computer Systems Group2 Motivation File system integrity is critical sourceforge.net: 90,000+ projects, including kernel projects

3 NYUSecure Computer Systems Group3 Goal Prevent undetected tampering with your files!

4 NYUSecure Computer Systems Group4 Current approaches Trust system administrator to do a good job Keep up with latest security patches Restrict accesses as much as possible …

5 NYUSecure Computer Systems Group5 Not always reliable

6 NYUSecure Computer Systems Group6 SUNDR’s approach SUNDR is a network f/s designed for running on untrusted, or even compromised server Place trust in users authorized to modify particular files, not in server or admins maintaining server SUNDR properties: Unauthorized operations will be immediately detected If server drops operations, can be caught eventually

7 NYUSecure Computer Systems Group7 Talk Outline Motivation Design A strawman file system SUNDR design Implementation Evaluation

8 NYUSecure Computer Systems Group8 Ideal File system semantics File system calls can be mapped to fetch/modify operations Fetch – client downloads new data Modify – client makes new change visible to others “Fetch-modify” consistency: A fetch reflects exactly the modifications that happen before it Impossible without online trusted parties Goal: Get as close to possible to “fetch-modify” consistency without online trusted parties

9 NYUSecure Computer Systems Group9 Strawman File System A Modify f2 sig3 A Modify f1 sig1 B Fetch f4 sig2 A Modify f2 sig3 B Fetch f2 sig4 A Modify f1 sig1 B Fetch f4 sig2 A Modify f1 sig1 B Fetch f4 sig2 A Modify f1 sig1 B Fetch f4 sig2 sig1 sig2 A Modify f2 sig3 File server A: echo “A was here” >> /share/aaa B: cat /share/aaa userA userB

10 NYUSecure Computer Systems Group10 An ordering relation A Modify f1 sig1 B Fetch f4 sig2 A Modify f2 sig3 B Fetch f2 sig4 A Modify f1 sig1 B Fetch f4 sig2 A Modify f2 sig3 We define ≤ relation: Log A ≤ Log B iff Log A is prefix of Log B A’s latest log: B’s latest log: Log A Log B

11 NYUSecure Computer Systems Group11 Detecting attacks by the server A Modify f2 sig3 A Modify f1 sig1 B Fetch f4 sig2 B Fetch f2 sig3 A: echo “A was here” >> /share/aaa A Modify f1 sig1 B Fetch f4 sig2 A Modify f1 sig1 B Fetch f4 sig2 A Modify f1 sig1 B Fetch f4 sig2 A Modify f2 sig3 A B B: cat /share/aaa(stale result!) File server

12 NYUSecure Computer Systems Group12 A Modify f1 sig1 B Fetch f4 sig2 B Fetch f2 sig3b A Modify f1 sig1 B Fetch f4 sig2 A Modify f2 sig3a A’s log and B’s log can no longer be ordered: Log A ≤ Log B, Log B ≤ Log A A’s latest log: B’s latest log: Detecting attacks by the server Log A Log B sig1 sig2 sig3a

13 NYUSecure Computer Systems Group13 Properties of Strawman FS  High overhead, no concurrency A bad server can’t make up operations users didn’t perform A bad server can conceal users’ operations from each other, however, it will be detected if users check with each other.  Call this property “fork consistency”

14 NYUSecure Computer Systems Group14 Fork Consistency: A tale of two worlds File Server A’s view B’s view … …

15 NYUSecure Computer Systems Group15 Implications of fork consistency Closest possible consistency to “fetch-modify” without online trusted parties Can be leveraged with online trusted parties to detect violations of “fetch-modify” consistency users periodically gossip to check violations or deploy a trusted online “timestamp” box

16 NYUSecure Computer Systems Group16 Talk Outline Motivation Design Strawman FS SUNDR approach Implementation Evaluation

17 NYUSecure Computer Systems Group17 SUNDR architecture block server stores blocks retrievable by content-hash consistency server orders all events Untrusted Network Untrusted Network consistency server block server SUNDR server-side SUNDR client SUNDR client userA userB

18 NYUSecure Computer Systems Group18 SUNDR data structures (I) Strawman FS problem: High bandwidth and storage consumption Need to reconstruct the whole file system Each file is writable by one user or group Partition inodes by allowed writer Hash each partition down to a 20-byte digest

19 NYUSecure Computer Systems Group19 Hash tree (1): File handle Each file is hashed into a 20-byte value using a hash tree Blocks are stored and indexed by their content-hash on the block server data1 Metadata H(data1) H(data2) H(iblk1) data2 data3 data4 H(data3) H(data4) iblk1 20-byte File Handle i-node

20 NYUSecure Computer Systems Group20 Hash tree (2): FS digest Hash all files writable by each user/group to a 20-byte digest From this digest, client can retrieve and verify any block of any file (SFSRO, CFS, Pond …) 220-byte3 4 i-table i-node 2 i-node 3 i-node 4 20-byte digest i-num

21 NYUSecure Computer Systems Group21 SUNDR FS 220-byte 3 4 digest 220-byte 3 4 digest Superuser: UserA: SUNDR State How to fetch “/share/aaa”? /: Dir entry: (share, Superuser, 3) Lookup “/” /share: Dir entry: (aaa, UserA, 4) Lookup “/share” Fetch “/share/aaa” digest UserB: … digest GroupG:

22 NYUSecure Computer Systems Group22 SUNDR data structure (II) Want server to order users’ fetch/modify operations Goal: Expose server’s failure to order operations properly Sign version vector along with digest Version vectors will expose ordering failures

23 NYUSecure Computer Systems Group23 Version structure Each user has its own version structure (VST) Consistency server keeps latest VSTs of all users Clients fetch all other users’ VSTs from server before each operation and cache them We order VST A ≤ VST B iff all the version numbers in VST A are less than or equal in VST B VST A Signature A A Digest A A - 1 B - 1 G - 1 VST B ≤ Signature B B Digest B A - 1 B - 2 G - 2

24 NYUSecure Computer Systems Group24 Updating VST: An example Consistency Server B A A-0 B-0 A: echo “A was here” >> /share/aaa B: cat /share/aaa Dig A A A-1 B-1 Dig A A A-1 B-1 Dig A A A-1 B-1 Dig A A A-0 B-1 Dig B B A-1 B-2 Dig B BA-1 B-2 Dig B BA-0 B-1 Dig B B VST A ≤ VST B

25 NYUSecure Computer Systems Group25 Detecting attacks Consistency Server B A: echo “A was here” >> /share/aaa B: cat /share/aaa (stale!) A A-1 B-1 Dig A A A-0 B-0 Dig A A A-0 B-1 Dig A B A-1 B-1 Dig A A A-0 B-1 Dig B B A-0 B-2 Dig B B A-0 B-2 Dig B B A’s latest VST and B’s can no longer be ordered: VST A ≤ VST B, VST B ≤ VST A ≤ A-0 B-0 Dig A A

26 NYUSecure Computer Systems Group26 Supporting concurrent operations Two clients may issue operations concurrently How does second client know what vector to sign? If operations don’t conflict, can just include first user’s forthcoming version number in VST But how do you know if concurrent operations conflict? Solution: Pre-declare operations in signed updates Server returns latest VSTs and all pending updates, thereby ordering them before current operation User computes new VST including pending updates User signs and commits new VST

27 NYUSecure Computer Systems Group27 Concurrent update of VSTs Consistency Server A B update: B-2 update: A-1 A: echo “A was here” >>/share/aaa B: cat /share/bbb A-0 B-0 Dig A A A-1 A-0 B-1 Dig B B A-0 B-1 Dig B B A-1B-2 A-0 B-0 Dig A A VST A ≤ VST B A-1 B-1 Dig A A A-1 B-1 Dig A A A-1 B-2 Dig B B A-1B-2 A-1 B-2 Dig B B A-1B-2

28 NYUSecure Computer Systems Group28 Talk Outline Motivation Design Straw-man FS SUNDR approach Implementation Evaluation

29 NYUSecure Computer Systems Group29 SUNDR Implementation SUNDR client daemon Kernel User Client Machine Domain xfs.ko redirector VFS FS operations consistency server block server SUNDR server-side setup

30 NYUSecure Computer Systems Group30 Block server implementation bstore Index System Permanent Log Temporary Log Stripe 1 Stripe 3 Stripe 2 SCSI EIDE (cf. Venti)

31 NYUSecure Computer Systems Group31 Evaluation Running on FreeBSD 4.9 PentiumIV 3G, 3G RAM, LAN Two configurations: SUNDR : write updates to disk synchronously SUNDR/NVRAM : simulates effects of NVRAM Block server benchmark STORE: 18.4MB/s (peak), 11.9MB/s (sustained) FETCH: 1.2MB/s (random), 25.5MB/s (sequential) Esign cryptographic overhead Sign: 155us Verify: 100us

32 NYUSecure Computer Systems Group32 LFS small file benchmark Seconds

33 NYUSecure Computer Systems Group33 LFS multiple clients CREATE Seconds Number of users

34 NYUSecure Computer Systems Group34 Emacs installation performance Seconds

35 NYUSecure Computer Systems Group35 Emacs multiple clients untar Seconds Number of users

36 NYUSecure Computer Systems Group36 Conclusion SUNDR provides file system integrity with untrusted servers Users detect unauthorized operations immediately Users can detect consistency violations eventually Yes, SUNDR is a practical file system performance is close to NFS

37 NYUSecure Computer Systems Group37 A working example (3) /share A-1 B-1 A – 2 (fa, A, 2) A-2 B-1 A-1 B-1 A – 2 (fa, A, 2) B – 2 (fb, B, 5) A – 2 (fa, A, 2) B – 2 (fb, B, 5) A-2 B-2 /share/fa A-2 B-1 Server A B /share/fa /share/fb A-2 B-2


Download ppt "SUNDR: Secure Untrusted Data Repository Jinyuan LiN.Y.U. Maxwell KrohnM.I.T. David MazièresN.Y.U. Dennis ShashaN.Y.U. OSDI 2004."

Similar presentations


Ads by Google