Outline for Today’s Lecture Administrative: –Happy Thanksgiving –Sign up for demos. Objective: –Peer-to-peer file systems Mechanisms employed Issues Some examples

The Security Environment Threats Security goals and threats

Intruders Common Categories 1.Casual prying by nontechnical users 2.Snooping by insiders 3.Determined attempt to make trouble (or personal gain) 4.Commercial or military espionage

Accidental Data Loss Common Causes 1.Acts of God -fires, floods, wars 2.Hardware or software errors -CPU malfunction, bad disk, program bugs 3.Human errors -data entry, wrong tape mounted, rm *

Reliability Mechanisms (Redundancy) Replication of data, geographically distributed –As simple as backups –First-class replication (Coda) –Voting schemes Error detection-correction –Erasure codes (encode n blocks into >n blocks, requiring r blocks to recover original content of original n) –Parity bits, checksums

Basics of CryptographyCryptography Relationship between the plaintext and the ciphertext

Secret-key crypto called symmetric-key crypto –If keys are long enough there are OK algorithms –Secret key must be shared by both parties Secret-Key Cryptography

Public-Key Cryptography All users pick a public key/private key pair –publish the public key –private key not published Public key is (usually*) the encryption key Private key is (usually*) the decryption key RSA

One-Way Functions Function such that given formula for f(x) –easy to evaluate y = f(x) But given y –computationally infeasible to find x Example: Hash functions – produce fixed size result –MD5 –SHA

Digital Signatures (b) Computing a signature block –Hash is fixed length – apply private key as encryption key* What the receiver gets –Use public key as decryption key* on signature block to get hash back –Compute the hash of document part –Do these match? Assumes E(D(x)) = x when we usually want D(E(x))=x Public key must be known by receiver somehow – certificate

Distributing Public Keys Certificate authority –Trusted 3 rd party –Their public key known Send name and public key, digitally signed by ca

Byzantine Generals Problem Reaching consensus among geographically separated (distributed) players if some of them are compromised. Generals of army units need to agree on a common plan of attack (consensus) Traitorous generals will lie (faulty or malicious) Generals communicate by sending messages directly general-to-general through runners between units (they won’t all see the same intell) Solutions are for all loyal generals to reach consensus, in spite of liars (up to some % of generals being bad)

Solution with Digital Sigs Iteratively execute “rounds” of message exchanges As each message passes by, the receiving general digitally signs it and forwards it on. Each General maintains the set of orders received Inconsistent orders indicate traitor

Peer-to-peer File Systems

Issues Goal is to have no centralized server and to utilize desktop-level idle resources. Trust – privacy, security, data integrity –Using untrusted hosts Availability – –Using lower “quality” resources –Using machines that may regularly go off-line Fairness – freeloaders who just use and don’t contribute any resources –Using voluntarily contributed resources

Issues Goal is to have no centralized server and to utilize desktop-level idle resources. Trust – privacy, security, data integrity –Using untrusted hosts -- crypto solutions Availability – –Using lower “quality” resources -- replication –Using machines that may regularly go off-line Fairness – freeloaders who just use and don’t contribute any resources –Using voluntarily contributed resources – use economic incentives

Farsite Microsoft Research – intended to look like NTFS Desktops on LAN (not Internet-scale) 3 roles: client, member of directory group, file host Directory metadata managed by Byzantine replication File hosts store encrypted replicated file data Directory group stores secure hash of content to validate authenticity of file Multiple namespace tree roots with namespace certificate provided by CA File performance by local caching under leasing system

NTFS File Encryption Operation of the encrypting file system K retrieved user's public key

PAST Rice Univ. and MSR Cambridge UK Based on Internet-based overlay Not traditional file system semantics File is associated with fileID upon insertion into PAST and can have k replicas –fileID is secure hash of filename, owner’s public key, random salt # –K nodes whose nodeIDs are “closest” to msb of fileID Instead of directory lookup, retrieve by knowing fileID

PASTRY Overlay Network k Route k Nodes assigned 1- dimensional IDs in hash space at random (e.g., hash on IP address) Each node has log n neighbors & maintains routing table Lookup with fileID k is routed to live node with nodeID close to k

LOCKSS Lots of Copies Keeps Stuff Safe (HPLabs, Stanford, Harvard, Intel) Library application for L-O-N-G term archival of digital library content (deal with bit rot, obsolescence of format, malicious users). Continuous audit and repair of replicas based on taking polls of sites with copies of content (comparing digest of content and repairing my copy if it differs from consensus). Rate-limited and churn of voter lists to deter attackers from compromising enough copies to force a malicious “repair”.