Self-Certifying File Systems (SFS)Self-Certifying File Systems (SFS)

Presented byVishal Kher

January 29, 2004

2

ReferencesReferences

Self-certifying file system (SFS)– David Mazires and M. Frans Kaashoek. Escaping the

evils of centralized control with self-certifying pathnames. In Proceedings of the 8th ACM SIGOPS 1998

– D. Mazieres, M. Kaminsky, M. Kaashoek and E. Witchel. Separating key management from file system security. SOSP, December 1999

SFS-based read-only file system– K. Fu, M. Kaashoek and D. Mazieres. Fast and secure

distributed read-only file system. OSDI, October 2000

3

Introduction (2)Introduction (2)

FS like NFS and AFS do span the Internet– They do not provide seamless file access

Why is global file sharing (gfs) difficult?– Files are shared across administrative realms– Can you seamlessly access files on CS file server from a

machine outside CS administration?– Scale of Internet makes management a nightmare– Every realm might follow its own policy

4

Introduction (2)Introduction (2)

Is there any thing else that hinders gfs?– Centralized Control

No one controls the name space– Users cannot trust “a” centralized server

Further who will manage the keys?– A centralized authority cannot manage all the keys

• Scale of the Internet

– A key management mechanism does not satisfy all– Expensive

5

SFS GoalsSFS Goals

Provide global file system image– FS looks the same from every client machine

• No notion of administrative realm

– Servers grant access to users and not clients Separate key management from file system

– Various key management policies can co-exist– Key management will not hinder setting up new servers

Security– Authentication– Confidentiality and integrity of client-server

communication Verstality and modularity

6

SFS Overview (1)SFS Overview (1)

Key idea: self-certifying path names Every SFS file system is accessible as

– /sfs/location:HostID– Location is location of the file server e.g., IP address– HostID = (“Hostinfo”,Location,PublicKey)– Every pathname has a public key embedded in it

Self-certifying path-name– /sfs/sfs.umn.cs.edu:vefsdfa345474sfs35/foo– Access file foo located on sfs.umn.cs.edu

7

SFS Overview (1)SFS Overview (1)

Starting a file server is quite easy– We need IP address, generate HostID, public key, and

run sfs software

Automatic mounting– If user references a non-existent pathname in /sfs the

SFS client automatically mounts the remote file system

Symbolic link– /umn /sfs/sfs.umn.cs.edu:vefsdfa345474sfs35

Authentication– sfs provides server and user authentication (details later)

8

Key Management (1)Key Management (1)

sfs doesn’t really care– But it provides some useful key management techniques

Manual key distribution– Admin installs pathname on local disk

CAs– CAs are sfs servers serving symbolic links– /verisign/umn /sfs/sfs.umn.cs.edu:vefsdfa345474sfs35

– If user trusts Verisign’s public key he will trust the path to umn.cs.edu file server

9

Key Management (2)Key Management (2)

Using password– User stores hash of password with the server UMN– Server authenticates user based on the password and

downloads the pathname to his local /sfs directory– File access does not involve a central admin.

10

Agents and authserver interact for user authentication– Both are modular and can be replaced

Client program handles server authentication and other activities– Revocation, auto mounting etc.

System ComponentsSystem Components

NFS Client

NFS Server

SFS client

Agent

Agent

SFS server

MACed, EncryptedTCP Connection

Kernel

Kernel

User program Authserver

11

Protocols: Key Negotiation (1)Protocols: Key Negotiation (1)

sfs client initiates the following every time it sees a new self-certifying pathname– Pc, Ps indicate public keys of client and server resp.

SFS Client SFS serverLocation, HostID

Ps

Pc, Ps(Kc1,Kc2)

Pc(Ks1,Ks2)

Session keys

– Kcs = H(“KCS”, Ps, Ks1, Pc, Kc1)

–Ksc = H(“KSC”, Ps, Ks2, Pc, Kc2)

12

Key Negotiation (2)Key Negotiation (2)

Only server can generate Ksc, Kcs – Server posses private key S

Ksc, Kcs used to encrypt and MAC all communication

Pc is changed frequently (every hour)– Forward secrecy

Is this susceptible to replay?

13

Performed on user’s first access to a new FS SFS server has a database mapping user public

keys to credentials

User AuthenticationUser Authentication

SFS server

SFS Client

Agent

AuthInfoSeqNo

AuthMsg

SeqNo,AuthMsg

AuthNo

SeqNo,AuthMsgAuthId, SeqNo,

Credentials

AuthInfo = {Location, Host, SessionID}

SessionId = H(Ksc, Kcs)

Req = {H(Authinfo),SeqNo} AuthMsg = PU, SigU(Req)

All Communication is secure

Authserver

14

Revocation Revocation

How to revoke a server’s public key? Revocation certificate

– CR = SigK(Location, PK)

CA stores these certificates– /verisign/revocation/HostID– File named by HostID contains revocation certificate for

that HostID

Revocation certificates are self-authenticating– CA need not check the identity of submitters

15

PerformancePerformance

End-End performance– SFS is roughly 11 – 16% slower than NFS 3 over UDP

Sprite LFS– Small file create, read and unlink

• Read is 3 times slow

– Large file ~ 40 MB• Sequential write is 44% slower than NFS 3 over UDP• Sequential read is 145% slower than NFS 3 over UDP

16

SummarySummary

SFS separates key management from FS Provides secure global file system by using self-

certifying pathnames – Any user can start his file server without going through a

central authority

Implementation is quite modular Significant performance overhead

17

ReferencesReferences

Self-certifying file system (SFS)– David Mazires and M. Frans Kaashoek. Escaping the

evils of centralized control with self-certifying pathnames. In Proceedings of the 8th ACM SIGOPS 1998

– D. Mazieres, M. Kaminsky, M. Kaashoek and E. Witchel. Separating key management from file system security. SOSP, December 1999

SFS-based read-only file system– K. Fu, M. Kaashoek and D. Mazieres. Fast and secure

distributed read-only file system. OSDI, October 2000

18

MotivationMotivation

Internet users rely a lot on publicly available data– Software installation

Secure data distribution– Replication, mirror sites not secure– Security expensive to verify– Security holes– Poor or no revocation support

19

SolutionSolution

Consider problem subset read-only data distribution

Apply SFS Result secure, high performance, scalable read-

only file system

20

AssumptionsAssumptions

Untrusted distribution servers Trusted clients Public, read-only data

21

System ComponentsSystem Components

sfsrodb– Database generator—creation, updates

sfsrosd– Server—data distribution– Runs on server– Server is self-certifying file system

sfsrocd– Client—data acquirement, verification– Runs on client

22

System OverviewSystem Overview

sfsrosd

sfsrodb

Private key

FS

sfsrosd

sfsrosd

signed replica database

sfsrocd

NFS client

User App.

TCP Connection

23

Recursive Hashing (1)Recursive Hashing (1)

Each data block is hashed Fixed-size hash computed handle

– Used to lookup the block in database

Handles stored in file’s inode Directories store <name, handle> pairs Directories and inodes hashed rootfh is hash of root directory’s inode

24

Recursive Hashing (1)Recursive Hashing (1)

H(B0)

H(B1)

H(H(B7)..)

[…]

metadata

H(B7)

H(B8)

H

HFile Handle

B0 B1 B7 B8

H

H

Name, handle

Name, handle

Name, handle

[…]

metadata HSign

/

25

FeaturesFeatures

Data verification by default Data has expiry date –

– struct FSINFO stores {date, duration, rootfh}

Directories sorted lexicographically – reduced search time

Opaque directories

26

LimitationsLimitations

Database update inefficient– Re-compute handles– Client must keep up with updates

Verification– Walk up all the tree to the root

27

ConclusionsConclusions

Read-only data integrity Content verification costs offloaded to clients No confidentiality promise! High availability, performance, scalability