Secure Untrusted Data Repository (SUNDR)

Secure Untrusted Data Repository (SUNDR)

• Notation Legend
• Pre-Read Thoughts
• Introduction
• Setting
• The SUNDR protocol
  • A straw-man file system
  • Implications of fork consistency
  • Serialized SUNDR
    • Data Structures & Protocol
• Post-Read Thoughts
• Further Reading

Notation Legend

#something : number of something
→ : excerpt from paper
() : an opinion or some information that’s not present in paper

---

Pre-Read Thoughts

Nothing much apart from the info that, a property called Fork Consistency is involved in SUNDR implementation

From the title Secure Untrusted Data Repository, Data Repository ⇒ Data Storage, Secure & Untrusted are self explanatory. So something related to securely storing on untrusted environments

Introduction

→ SUNDR is a network file system designed to store data securely on untrusted servers.

→ SUNDR cryptographically protects all file system contents so that clients can detect any unauthorized attempts to change files.

→ In contrast to previous Byzantine-fault-tolerant file systems that distribute trust but assume a threshold fraction of honest servers, SUNDR vests the authority to write files entirely in users’ public keys

→ Even a malicious user who gains complete administrative control of a SUNDR server cannot convince clients to accept altered contents of files he lacks permission to write.

Setting

SUNDR is like an RPC interface above NFS which manages security

As seen in architecture, there’s fetch and modify op.s before security layer, where fetch is to get some file or validate local cached copy, modify is change file, where other users can observe

SUNDR server can host multiple FS

Per FS, admin creates public and private keys, gives public to server and keeps private key to sign content or access

admin or SuperUser SU maintains lists of users and their membership along with their own public and private keys (for communicating with SU)

not only users are entities solely, they can be grouped and assigned permissions

The SUNDR protocol

→ SUNDR’s protocol lets clients detect unauthorized attempts to modify files, even by attackers in control of the server. When the server behaves correctly, a fetch reflects exactly the authorized modifications that happened before it. We call this property fetch-modify consistency.

Fork Consistency

a type of consistency where all the forks/copies should be consistent, can be merged when conflicts

A straw-man file system

(straw-man ⇒ early design)

In this fs, there will be a lock, which will be held by a client/user when they make changes

with lock, operations will be totally ordered

additionally, a digital sign is made when making an op, which includes history of previous op.s

so at any point of time/operation, order of operations can be observed

when making an op, client gets this history and validates recent op.s of other users, creates a local copy of this then makes op, then finally releases lock

now if some malicious server made an operation, the signature mismatch which appear to op making client, thus client won’t consider it legit

Implications of fork consistency

→ Suppose user A comes on line, modifies a file, and goes off line. Later, B comes on line and reads the file. If B doesn’t know whether A has accessed the file system, it cannot detect an attack in which the server simply discards A’s changes.

→ Fork consistency implies this is the only type of undetectable attack by the server on file integrity or consistency.

→ Moreover, if A and B ever communicate or see each other’s future file system operations, they can detect the attack.

Serialized SUNDR

Problems w/ straw-man fs

• bandwidth, storage overhead to store op history
• global lock limiting the concurrency

to tackle first problem, SUNDR makes a snapshot and signs it

files writable by user are aggregated into a single hash value, i-handle, using hash tree/merkle tree

i-handles are connected with other latest i-handles using version vectors

Data Structures & Protocol

→ SUNDR names all on-disk data structures by cryptographic handles. The block store indexes most persistent data structures by their 20-byte SHA-1hashes, making the server a kind of large, high-performance hash table.

→ Every file is identified by a ⟨principal, i-number⟩ pair, where principal is the user or group allowed to write the file, and i-number is a per principal inode number.

this picture shows a merkle tree structure, what’s happening when a data block of some file is getting updated

with the advantage of merkle tree, it’s easy to make changes at leaf node level which is holding data block in thisdata block ==$d_0$==, which is at very right, is going through process of updation by updating it’s complete chain it formed from i-handle at left

Post-Read Thoughts

Theme slightly moved towards cryptography (as anyone can expect, there’s Secure in title)

Good buildup for SUNDR protocol with replicated log and participant’s signing it

(Though I read until the start of § 3.4 “Concurrent SUNDR” for 21. Fork Consistency, SUNDR, handling this concurrently but not sequentially is very good challenge, will come back to this sometime later)

Further Reading