Separating key management from file system security

Paper by: D. Mazieres, M. Kaminsky, M. Kaashoek and E. Witchel

Presented by: Alfred Pang (+ Billy Cheung)


Presentation Slides(By Alfred Pang)
SFS Project page


Compilation of submitted questions:
  1. The paper seems not to talk about the recovery at all if the client or server crashes. Could you analyze such situation ?
  2. Supports varies security standards especially user defined security requests may weaken the security of file server. For example, if a malicious user compromises a file server through a week security, he may access other users’ files on the SFS server with higher security request. What is your idea ?
  3. I didn't see where they handled hash collisions. However unlikely, is it safe to completely ignore the possibility of two identical keys?
  4. How can agents decide if they should honor blocked HostIDs?
  5. How can we utilize the secure file system for web service? What should users do and what should server programmers implement when applying SFS to web services? In other words, does SFS make users convenient or programmers convenient? What is the most secure and convenient interaction between server and client using SFS among several ways the paper explains? How can we utilize SFS free software?
  6. What is the Rabin public key cryptosystem and how does SFS use it? Also what is XDR and how does SFS use it? Would you explain some jargons in the paper?
  7. The paper purports to work on a key management protocol that is sufficient for Internet wide use ... yet the testing involves two (2!) PCs. Is the protocol really scalable?
  8. In Feb 2005 it was shown that collisions in SHA-1 can be found in 2^69 computations (2^80 is brute force) ... which is just barely computationally feasible. Would it be easy to shift to higher grade hash functions (e.g. SHA-512) for SFS?
  9. Why is SFS not available for Windows? Is there any technical reason behind this? (I thought new file system protocol can be included just by changing the configuration file?)
  10. While the paper presents how SFS should be secure, why is there no real test on security? (I am not convinced by the fact that some members of the authors are using it.)
  11. If sysadmins are paranoiac and allow nothing in except ssh connections (which is what many institutions do), can SFS be of any use to them to increase security ?
  12. Key management is separated from the file system security by putting the keys (or a hash of them) inside the path names. Thus you can easily map a file to a hash of the key of the server that holds the file, by just looking at the first part of a path name. Why not just store the host name of the file server in the path and use the widely used public key authenticity services to authenticate the file server ?
  13. When authors discuss revocation they say that revocation certificates are self-authenticating and the idenetity of people submitting them is not checked. So, anyone can make a HostID block. This means that the path from a client to a server is blocked for every agent running on that client. Maybe I don't get this right, but if what I have said is correct this seems unfair to people running agents on the same client. What would you say?
  14. In the article the authors say that authserv keeps a local copy of the mapping of public keys to users. Would the synchronization between the mapping on the local list and centrally-mainained list be of importance for SFS? Would you say that there is a limit on the number of keys per user? (this is last paragraph on page 129)
  15. Would you say that 32 bit base HostID encoding is an overkill, just right, or not enough?
  16. In the performance section, the microbenchmarks show a large difference between the performance of SFS and the performance of NFS (SFS is four times slower than NFS) Why this difference is not reflected in the Andrew and Sprite benchmarks?
  17. A failure at the certification authority would result in unavailability of all the file servers that use that certification authority. Can we consider this as a weakness for their technique? What is the probability of a certification authority failure?
  18. A problem with secure systems in general is that the average user has little or no understanding of what makes them secure, which means that they are often easily fooled. As a simple example, many phishing websites display a lock symbol on the page to make novice users think they are accessing a secure site. Does this system suffer from that sort of problem? In particular, the use of symbolic links to self-certifying pathnames seems like a potential vulnerability.
  19. Is SFS in use today? If not, what factors have prevented it from being used?
  20. How does SFS deal with crash recovery? They don`t talk about crash recovery but it might be a problem when for example authsever crashes, as authentication is mostly dependent on authserver? Would making redundant copies on different authservers solve the problem or inroduce new security leaks?
  21. The server performs low on the benchmarks especially compared to bare NFS. Despite the performance issues is SFS being used to solve security issues on file systems today? Are users willing to sacrifice this much of performance for the sake of security?
  22. If a user compromises a file server through a week security, I guess [s]he can access other user's files on the SFS server with higher security request. This user defined security requests may weaken the security of file server. Is it a flaw of this paper or I misunderstand it?
  23. The certification authority store the SFS file name for a secure server, but certification authority failure could lead all file servers using that certification authority to be unavailable. I think this architecture for certification is not very practical. What do you think?
  24. One flaw of this paper is that it does not mention the recovery at all. I am wondering how the recovery work if client or server is down?
  25. One of Cryptographic protocols is SFS key negotiation protocol (Location, HostID, Ks, Kc, etc.) Do you there is any overhead for the key negotiation protocol?
  26. The paper says SFSs MAC is slower than alternatives such as MD5 HMAC. Why does the paper still use MAC rather than MD5? The motivation for the paper is to build a secure file system for the Internet. But doesn't basing SFS on NFS go against this? Or is it maybe possible to implement this without NFS?
  27. Separating the key management from the file system does make the system modular. But doesn't it make the system more complex? (agents, authserver, sfskey) Doesn't this affect the reliability/availability of the system?
  28. Do we really need a global file system at the Internet level?
  29. A failure at the certification authority would result in unavailability of sfs file names for all file servers. Isn't that a performance issue?
  30. Doesn't the SFS's user level implementation and software encryption affect the performance?
  31. How much change would you say would need to be done to go from 32 base HostID encoding to more than 32-base HostID encoding? Would you sooner go for larger base or more than 20-byte codes?
  32. Is there anything (concerning security) that can't be achieved by a standard method of placing a server's public key into its DNS record? (making the assumption that DNS entries are secure)
  33. SFS doesn't seem to solve this type of attack: "Verify your credit card info here: /sfs/v1sa.com:public_key_for_v1sa_com", where the user needs to decide whether the public key in the "self certifying pathname" is the one he wants.
  34. There is criticism on how SSL isn't flexible because it _requires_ a certificate signed by a trusted certificate authority (CA). My understanding is that SSL without a CA is still "secure" with the exception that it becomes the responsibility of the user to verify that the presented public key is correct. (Web browsers will show a prompt stating the certificate can't be verified, and allowing the user to verify the certificate) Is there anything SFS adds to this, other than removing the convention of using CAs, and moving the responsibility of public key verification onto the user?