SFS === What are the high-level goals of SFS? Allow anyone to set up a secure file server. Don't involve Verisign or other centralized authorities. Allow anyone to use my file server. And get useful security guarantees, even for anonymous use. How does secure HTTP work? Is that sufficient? Get certificate from Verisign Problem: $300 + not everyone authorized How does AFS/kerberos work? Is that sufficient? All servers centrally registered at NYU NYU exchanges keys with MIT Problem: I don't want to have to register file server (cf. seb server) Problem: What if you aren't at NYU or MIT? What about SSH? Is that sufficient? Problem: Man-in-the-middle attacks What do you need for security? User needs *something* in common with server! Classically a shared authority (Verisign, Athena's Kerberos DB). Let's just talk about secure anonymous access. Problem is proviving server's authenticity to user. What's a self-certifying path name? How can a client use a self-cert path name? See's file access: /sfs/foo:hostid/README Uses hostid to negotiate session key Then sets up an ordinary secure channel. Where do self-certifying path names come from? SFS doesn't care! I could write one on a business card. Can I do that w/ Verisign or Kerberos? Here's where the "separating" of the paper title applies. SFS defines crypto protocol and key format. User (or something external) provides keys. How can we make use of that? Why is it useful? How can you connect your laptop to a file server? Could type out /sfs/ludlow.scs.cs.nyu.edu:u2..fc/u1/dm Or can use "symbolic link" Make ~/ludlow point to /sfs/ludlow...fc/u1/dm Or user password (SRP) Easy to add new ones as I learn about other file servers. I can manage my own *secure* file system access. And name space. As I learn about various servers' public keys. A lot like ssh_known_hosts, which I can control. But it's not convenient (when used securely). I would have to add entries by hand. Where do I learn about server public keys? My friends write them on scraps of paper. My system administrator tells me. (/nyu) I read them in the Wall Street Journal. --> sources I trust tell me. Can we automate and generalize this process? How can users easily share knowledge of self-cert pathnames? Make links to /sfs/... in sfs-accessible file systems. ~dm/links/schedule, classnotes, etc. Then if I know just my friend's pathname, I can easily get at all his or her links. I still have to trust him/her. But *I* can decide that myself. No software can do it for me. This is a lot like PGP's web of trust. Perhaps better since it's on-line. What about Verisign? Does Verisign provide a useful service if you have SFS? Globally-agreed-on name space. So we can use convenient *names*, not awkward public keys. Ability for servers to change or expire keys. Can't do that if built into lots of links. Expiration, a substitute for revocation. How can we emulate Verisign using SFS? Convention: /verisign -> /sfs/sfs.verisign.com:xxxx And /verisign/cnn -> /sfs/cnn.com:yyy Means "whoever Verisign thinks CNN is". Nothing very unique about verisign! Then I can send you e-mail saying "I read it on /verisign/cnn" And you would know exactly what I meant. Verisign can revoke x's key by deleting or modifying /verisign/x. But the cost is Verisign processes every name lookup! Could you use idea of separating to web security? Page author puts public key of link's server in URL on page. So viewers talk to the server the author intended. Make pages of trusted links. From manufacturer's page to vendor's page What's the equivalent guarantee in SSL/https? Problem: Cannot link to a link Verisign's web page might say "click here for NYU" I can copy link, but won't reflect changes by Verisign No way to link through verisign A notion of links is important. Allows you to build chains of trust. Hard in a non-file-system-like context. Is revocation a critical part of a secure file system? Under what circumstances can we do a perfect job? Would we be willing to tolerate mistakes? How can we know that revocations are not faked? Revocation certificate. Must be signed by original private key. How does SFS handle revocation in general? I.e. for names that don't go through /sfs/verisign. User's agent is involved in every /sfs lookup. Can do whatever it likes. In general, consults lists of signed revocation certificates. For example, check /verisign/revocations/key. What are the principals in SFS? File servers Users Clients Clients have temporary public key. Are they authenticated? sfs seems to get away w/o authenticating the workstation. How does user/client authentication work? Agent signs hash(server/client nonces) with user private key. Proves possesion of user private key. Proves freshness. Proves association with client session. I.e. client speaksfor user. Server returns "authentication number" to client. Why secure? Can't client fake these? Yes, but we trust sfsrwcd, and can only fake users that that client has authenticated. Why not have user set up secure connection to server? Sharing of client file cache.