Separating key management from

1
Separating key management from file system
security
David Mazieres, Michael Kaminsky, M. Frans
Kaashoek and Emmett Witchel MIT Laboratory for
Computer Science, 99
Presented by Phil Huynh
2
The problem

• Users from different administrative domains want
  to share files.
• Different authentication protocols can be used
  corresponding various security needs
• Global key management is difficult
• Motivation to have some sort of plug-n-play
  security mechanism

3
Secure File System (SFS)

• Self-certifying pathname
• Authenticate file servers to clients without
  performing key management
• Separate key management from file system
• Modules of ltagent, authserver, protocolgt

4
Secure File System (SFS)
5
Self-certifying pathname

• Names for files on servers
• HostID SHA-1(HostInfo, Location, Public Key)
• Effectively specifies a unique, verifiable
  location and public key (instead of using CA
  issued by the trustful 3rd party)
• Enough info initiate a secure conversation to
  server

6
Self-certifying pathname

• How users manage to remember the long path?
• /sfs/sfs.cs.umd.eduvefvsv8wd9jxisc3r....

7
Self-certifying pathname

• How users manage to remember the long path?
• /sfs/sfs.cs.umd.eduvefvsv8wd9jxisc3r....
• Symbolic link
• /cs ? /sfs/sfs.cs.umd.eduvefvsv8wd9jxisc3r....
  

8
Key negotiation
Kc short-lived clients Public Key
Ks SFS servers Public Key kc1, kc2 random
key-halves ks1,ks2 random
key-halves
9
Key negotiation
Session Keys
10
Session Keys

• Provide
• Secure channel to the desired server
• Anonymous access
• Not provide user authentication

11
User authentication

• On first access to an SFS file system, the client
  notifies the agent of the event
• Agent signs authentication request using users
  public key and sends it to SFS server
• FSF server forwards the request to authserver to
  verify. Authserver has a mapping of clients
  public key to credentials (e.g. list of groud ID)
• Authserver returns credentials to SFS server

12
User authentication protocol
13
User authentication protocol
14
User authentication protocol
15
Properties

• Design
• Modular
• User authentication separates from the file
  system
• Security
• Users trust clients
• Attacker can do no worse than delay the file
  systems operation
• Users cannot read, write files without possessing
  a validated secret key (kept in authserver)
• Can add new user authentication protocols to SFS
  without modifying the file system

16
Revocation

• When servers private key is compromised...
• Key revocation
• HostID blocking
• Key revocation certificate K,
• Clients obtain revocation certificates from
• Servers when SFS first connect to a server, the
  server could respond with a revocation
  certificate
• Agents when clients first access a
  self-certifying pathname, agents check if the
  path has been revoked
• Users agents decide whether or not to honor
  blocked HostIDs

17
Performance
18
Performance
19
Conclusion

• Good stuffs
• Modular design
• Self-certifying pathname
• Dislike
• Paper was hard to read though its not supposed
  to be hard
• Previously claimed that global key management is
  difficult, but did not explain how authserver
  manage users public keys and map those keys to
  corresponding credentials
• Scalability? Tested on 2 PCs, number of users was
  not mentioned (!)

20
Decentralized User Authentication in a Global
File System
Michael Kaminsky, George Savvides, M. Frans
Kaashoek and David Mazieres MIT Laboratory for
Computer Science, 03
Presented by Phil Huynh
21
The problem

• Users from different administrative domains want
  to share files.
• Provide ACLs that work with remote principals
• AFSs ACL does not accept remote principals
• Chains of CAs, Chains of KDCs approaches can
  solve the problem, but the process of generating
  the chains is complicated

22
The problem

• Users from different administrative domains want
  to share files.
• Provide ACLs that work with remote principals
• AFSs ACL does not accept remote principals
• Chains of CAs, Chains of KDCs approaches can
  solve the problem, but the process of generating
  the chains is complicated
• Hmm... Didnt we have SFS solve the problem?

23
Recall
24
Recall
What missed?
25
Recall
What missed?
26
Use case

• Charles at UMD wants to share /courseware to his
  coworkers

27
Use case

• Charles at UMD wants to share /courseware to his
  coworkers
• Step1 On the local authentication server (local
  to Charles), he creates a personal group

28
Use case

• Charles at UMD wants to share /courseware to his
  coworkers
• Step1 On the local authentication server (local
  to Charles), he creates a personal group

• Step2 Add members to this group

29
Use case (cont.)

• Step3 Make his friend, George, as a co-owner

30
Use case (cont.)

• Step3 Make his friend, George, as a co-owner

• Step4 Construct an ACL and put it under the
  shared directory

31
Use case (cont.)

• What will be after that?

32
Use case (cont.)

• What will be after that?

33
Use case (cont.)

• What will be after that?
• User A accesses the file system the first time.
  The file server sends a request to its local
  authserver to authenticate A
• Authserver server returns As credential
• A is a local user trivial
• A is a remote user has to learn from remote
  authservers ltlt main point of the paper
• The file server match As credential with the
  files ACL to make the final decision whether A
  can have access to the file

34
User authentication (UA)

• Task Given a users public key, return the
  corresponding credential (e.g. local groupIDs)
• Goal authentication server can respond to an
  authentication request without contacting any
  remote authentication servers
• Solution local authentication server caches
  remote user and group definitions
• (for public key, credential mapping)

35
UA Solution

• Local user ltUser Namegt e.g. alice
• Remote user ltUser Name, self-certifying hostname
  of the authentication server that maintains the
  user recordgt

36
UA Solution
37
UA Solution
38
UA Solution

• Effectively convert the membership relationship
  to a graph

39
UA Solution

• Once having the graph, the translation from a
  public key to local groups ( issuing credential)
  is trivial

40
UA Solution

• Once having the graph, the translation from a
  public key to local groups ( issuing credential)
  is trivial
• But...

41
UA Solution

• Building the membership graph is challenging
• Groups may contain remote users and groups
• Traversing through remote hosts is costly
• The graph can change at anytime

42
UA Solution

• Split the UA task into 2 parts
• Part 1 Construct the membership graph in the
  background and periodically update the graph
• (freshness vs efficiency)
• Part 2 Do the public key local groups
  translation based on the current graph

43
UA Solution

• Optimization
• Cache authserver-authserver connections for later
  use
• Transfer only changes
• Make the shortcut
• G?user?public_key TO G?public_key

44
Revocation

• Revoke users key find the groups that contain
  this key and delete it
• Revoke authentication servers key is a pain!
• Authentication servers maintain Key Revocation
  List
• Authentication servers exchange self-certifying
  revocation certificates

45
Scalability

• Up to tens of thousands of users and groups

46
Evaluation
47
Conclusion

• Good stuffs
• Answer the left part in the 1st paper (user
  authentication)
• A sample implementation of the plug-n-play key
  management module for SFS
• Concern
• Is the given user authentication scheme less
  complicated than Chain of CAs or Chain of
  KDCs approaches?

48

• Thank you! ?