上期在 星际文件系统 IPFS 中讲到 IPFS 的底层技术里有一项自认证文件系统（Self-Certified Filesystems - SFS）。这周继续在这个主题里下钻探索，国内的网站里，仅有基础原理的描述，而且都是抄来抄去，技术、源码的解析分享完全没有找到。如需想了解技术、源码的部分，可参考最后章节的链接（可能需要翻墙）。
什么是 SFS
自验证文件系统（Self-Certifying File System，SFS）是由David Mazieres和他的导师M. Frans Kaashoek在其博士论文中提出的。SFS 是为了设计一套整个互联网共用的文件系统，全球的 SFS 系统都在同一个命名空间下。在 SFS 中，分享文件会变得十分简单，只需要提供文件名就行了。任何人都能像 Web 一样，搭建起 SFS 服务器，同时任意一个客户端都能连接网络中任意一个服务器。
SFS 设计
安全性
SFS 系统的安全性可以由两部分定义：文件系统本身的安全性和密钥管理的安全性。换句话说，安全性意味着攻击者未经许可不能读取或者修改文件系统；而对于用户的请求，文件系统一定会给用户返回正确的文件。
文件系统本身的安全性
SFS 除非明确指明允许匿名访问，否则用户如果需要读取、修改、删除或者对文件进行任何篡改，都需要提供正确的密钥。客户端与服务器始终在加密的安全通道中进行通信，通道需要确保双方的身份，以及数据完整性和实时性（避免攻击者截获数据包，并将其重新发送，欺骗系统，这称为重放攻击）。密钥管理的安全性
仅仅依靠文件系统的安全保护并不能满足用户的各类需求，用户可以使用密钥管理来达到更高级别的安全性。用户可以使用预先设置的私钥，或使用多重加密，再或者使用由第三方公司提供的文件系统来访问经过认证的文件服务器。用户可以从中灵活、轻松地构建各种密钥管理机制。
可扩展性
因为 SFS 定位是全球范围共享的文件系统，所以 SFS 应该具有良好的可扩展性能。无论用户是希望以密码认证方式读取个人文件，还是浏览公共服务器上的内容，SFS 都应该能很好地兼容。
在 SFS 系统的设计中，任何在 Internet 网络内拥有域名或 IP 地址的服务器，都能部署为 SFS 服务器，并且过程十分简单，甚至无须请求注册权限。SFS 通过 3 个属性实现它的扩展：全网共享的命名空间，用于实现密钥管理的原语集， 以及模块化设计。
全局命名空间
在任意一个客户端登录的 SFS 都具有相同的命名空间。虽然 SFS 中在每个客户端都会共享相同的文件，但是没有任何人能控制全局的命名空间；每个人都能添加新的服务器到这个命名空间里。密钥管理的原语集
SFS 还允许用户在文件名解析期间使用任意算法来查找和验证公钥。不同的用户可以采用不同的技术认证相同的服务器；SFS 允许他们安全地共享文件缓存。模块化设计
客户端和服务器在设计时就大量使用了模块化设计，程序之间大多使用设计好的接口进行通信。这样，更新迭代系统各个部分，或者添加新的功能特性会非常简单。
自验证文件路径
自验证文件系统的一个重要的特性，就是在不依赖任何外部信息的条件下，利用加解密来控制权限。这是因为，如果 SFS 使用本地配置文件，那么显然这与全局文件系统的设计相悖；如果使用一个中心化服务器来辅助连接，用户可能产生不信任。那么，如何在不依赖外部信息的情况下，来安全地获取文件数据呢？SFS 提出了一种新的方式，即通过可以自我证明身份的路径名实现。
SFS 路径中包含了构成与指定服务器构建连接的需要的全部信息，例如网络地址和公钥。SFS 文件路径包含 3 部分：
服务器位置
告知 SFS 客户端文件系统服务器的地址，它可以是 IP 地址或者 DNS 主机名。
HostID
告知 SFS 如何与服务器构建安全的连接通道。为了确保连接的安全性，每个 SFS 客户端都有一个公钥，而 Host ID 通常设置为主机名与公钥的哈希。通常情况下，SFS 会按照 SHA-1 函数计算。
HostID = SHA-1("HostInfo",Location,PublicKey)使用 SHA-1 主要考虑了计算的简易性，以及一个能接受的安全等级。SHA-1 的输出是固定的 20 字节，它比公钥短得多。同时 SHA-1 能为 SFS 提供足够的密码学保护，找到一对合法的服务器位置与公钥对来满足要求，它的构造难度非常大。
在远程服务器上文件的地址
前面两个信息是为了找到目标服务器并构建安全连接，最后只需要提供文件的位置、定位需求的文件即可。整个自验证文件路径的形式如下：
即给定一个 IP 地址或域名作为位置，给定一个公钥/私钥对，确定相应的 Host ID，运行 SFS 服务器软件，任何一个服务器都能通过客户端将自己加入 SFS 中，而无须进行任何的注册过程。
用户验证
自验证的路径名能帮助用户验证服务器的身份，而用户验证模块则是帮助服务器验证哪些用户是合法的。与服务器身份验证一样，找到一种能用于所有用户身份验证的方法同样是很难达到的。因此 SFS 把用户身份验证与文件系统分开。外部软件可以根据服务器的需求来设计协议验证用户。
SFS 引入了 Agent 客户端模块来负责用户认证工作。当用户第一次访问 SFS 文件系统时，客户端会加载访问并通知 Agent 这一事件。然后，Agent 会向远程服务器认证这个用户。从服务器角度来看，这部分功能从服务器搬到了一个外部认证的通道。Agent 和认证服务器之间通过 SFS 传递信息。如果验证者拒绝了验证请求，Agent 可以改变认证协议再次请求。如此一来，可以实现添加新的用户验证信息却不需要修改实际的真实文件系统。如果用户在文件服务器上没有注册过，Agent 在尝试一定次数以后拒绝用户的身份验证，并且将授权用户以匿名方式文件系统。另外，一个 Agent 也能方便地通过多种协议连接任意给定的服务器，这些设计都会非常方便、快捷和灵活。
密钥撤销机制
有些时候服务器的私钥可能会被泄露，那么原有的自验证文件路径可能会错误地定位到恶意攻击者设置的服务器。为了避免这种情况发生，SFS 提供了两种机制来控制： 密钥撤销指令和 Host ID 阻塞。密钥撤销指令只能由文件服务器的拥有者发送，它的发送目标是全部的用户。这一指令本身是自验证的。而 Host ID 阻塞是由其他节点发送的，可能与文件服务器拥有者冲突，每一个验证的 Agent 可以选择服从或者不服从 Host ID 阻塞的指令。如果选择服从，对应的 Host ID 就不能被访问了。