self-certifying file systems (sfs)
DESCRIPTION
Self-Certifying File Systems (SFS). Presented by Vishal Kher January 29, 2004. References. 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 - PowerPoint PPT PresentationTRANSCRIPT
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