SFS means Self-Certified Filesystem

[WingT]

No description provided.

[daijiale]

@WingT Thanks your issue @yihen SFS解读有误，这边我帮你修正一下：

2.4 自验证文件系统（SFS）

自验证文件系统是由David Mazieres和他的导师M. Frans Kaashoek在其博士论文中提出的。 SFS（Self-Certifying File System）是为了设计一套整个互联网共用的文件系统，全球的SFS系统都在同一个命名空间下。在SFS中，分享文件会变得十分简单，只需要提供文件名就行了。任何人都能像Web一样，搭建起SFS服务器，同时任何一个客户端都能连接网络中任何一个服务器。

直觉上，我们可以感受到，要实现一个全球共享的文件系统，最大的一个障碍莫过于如何让服务端为客户端提供认证。在使用文件系统时，用户是可以匿名进入服务器的，任何一个客户端在任何时候都有可能进入任何一个服务端。那么问题就在于如何合理进行密钥管理。一个思路我们能想到的，就是每个服务器使用非对称加密，生成一对私钥和公钥。客户端使用服务器的公钥来验证服务器的安全连接。那么这样又来了一个新问题，如何让客户端在最初获得服务器的公钥呢？对于不同的需求场景下，用户对密钥管理的要求是不同的，又如何实现密钥管理的可扩展性呢？

SFS则使用了一种解决方案，一种新的方式，它将公钥信息嵌入到文件名中，将这个做法命名为'自验证文件名'。那么显然，这样做以后我们就无需在文件系统内部实现密钥管理了。这部分密钥管理的功能可以加入到用户对文件命名的规则中。这样一来给用户的加密方式带来很多便利，用户可以根据需求，自行选择自己需要的加密方式。

SFS核心思想有如下几点：

1. SFS文件系统具备自验证路径名称，不需要在文件系统内部实现密钥管理。
2. 在SFS上易于架设各种密钥管理机制，包括各类组合机制。
3. SFS将密钥撤销与密钥分发分离开，防止影响密钥的恢复。
4. 实现全球范围的文件系统。

SFS设计

安全性

对于SFS系统，安全性可以由两部分定义：1. 文件系统本身的安全性， 2. 密钥管理的安全性。换句话说，安全性意味着攻击者未经许可不能读取或者修改文件系统；而对于用户的请求，文件系统一定会返回给用户正确的文件。

文件系统本身的安全性： SFS除非明确指明允许匿名访问，用户如果需要读取，修改，删除或者对文件进行任何篡改，都需要提供正确的密钥。客户端于服务器始终在加密的安全通道进行通信，通道需要确保双方的身份，数据完整性和实时性。（避免攻击者截获数据包，并将其重新发送，欺骗系统。称为重放攻击）

密钥管理的安全性： 仅仅依靠文件系统的安全保护并不能满足用户的个类需求，用户可以使用密钥管理来达到更高级别的安全性。用户可以使用预先设置的私钥，或是使用多重加密，再或者由第三方公司提供的文件系统来访问经过认证的文件服务器。用户可以从中灵活，轻松地构建各种密钥管理机制。

可扩展性

因为SFS定位是全球范围共享的文件系统，那么SFS应该具有良好的可扩展性能。无论用户是希望以密码认证读取到个人文件，或者是浏览公共服务器上的内容，SFS都应该能很好兼容。在新服务器的部署上，SFS必须要尽可能简单方便。

在SFS系统中，任何在Internet网络内拥有域名或地址的服务器，都能部署成为SFS服务器，并且过程十分简单，甚至无需请求注册权限。SFS通过三个属性实现它的扩展性能：全网共享的命名空间，用于实现密钥管理的原语集， 以及模块化设计。

1. 全局命名空间：在任何一台客户端登陆的SFS都具有相同的命名空间。虽然SFS中在每个客户端都会共享相同的文件，但是没有任何人能控制整个全局的命名空间；每个人都能添加新的服务器到这个命名空间里。
2. 密钥管理的原语集：SFS还允许用户在文件名解析期间使用任意算法来查找和验证公钥。不同的用户可以采用不同的技术认证相同的服务器; SFS允许他们安全地共享文件缓存。
3. 模块化设计：客户端和服务器在设计时就大量使用了模块化设计，程序之间大多使用设计好的接口进行通信。这样，更新替代系统各个部分，或者添加新的功能特性会非常简单。

自验证文件路径

自验证文件系统一个重要的特性，就是在不依赖任何外部信息的条件下，利用加密控制权限。这是因为，如果SFS使用本地配置文件，那么显然这与全局文件系统的设计相违背；如果使用一个中心化服务器来辅助连接，用户可能产生不信任。那么，如何在不依赖外部信息下，来安全地获取文件数据呢？SFS提出了一种新的方式，即通过可以自我证明身份的路径名达到。

SFS路径中包含了构成与指定服务器构成连接的全部需要的信息，例如网络地址和公钥。 SFS文件路径包含三部分：

1. 服务器位置: 告知SFS客户端文件系统服务器的地址，它可以是IP地址或者是DNS主机名。
2. HostID：告知SFS如何与服务器构建安全的连接通道。为了确保连接的安全性，每个SFS客户端都有一个公钥，而HostID，通常设置为主机名字与公钥的哈希。通常情况，SFS会按照SHA-1函数计算。

HostID = SHA-1 ("HostInfo", Location, PublicKey, "HostInfo", Location, PublicKey)

使用SHA-1主要考虑到了计算的简易性，以及一个能接受的安全等级。SHA-1的输出是固定20字节，它比公钥短的多。同时SHA-1能为SFS提供足够的密码学保护，找到一对合法的服务器位置与公钥对来满足要求，它的够造难度非常大。

3. 在远程服务器上，文件的地址：前面两个信息是为了找到目标服务器并构建安全连接，最后只需要提供文件的位置，定位需求的文件即可。 整个自验证文件路径的形式就形如下。

Location      HostID (specifies public key)    path on remote server
/sfs/sfs.lcs.mit.edu: vefvsv5wd4hz9isc3rb2x648ish742h/pub/links/sfscvs

SFS系统，给定一个Internet地址或域名作为位置，给定一个公钥私钥对，确定相应的HostID，运行SFS服务器软件，任何一个服务器都能通过客户端，将自己加入到SFS中，而无需进行任何的注册过程。

用户验证

自验证的路径名，能帮助用户验证服务器的身份，而用户验证模块则是帮助服务器验证哪些用户是合法的。与服务器身份验证一样，找到一种能适合所有服务器的服务器的用户验证方法，同样是很难达到的。 SFS因此把用户身份验证与文件系统分开。外部软件可以根据服务器的需求来设计协议验证用户。

在客户端，Agent负责用户认证工作。当用户第一次访问SFS文件系统时，客户端会加载访问并向Agent通知这一事件。然后，Agent会向远程服务器认证这个用户。从服务器角度上看，这部分功能从服务器搬到了一个外部认证的通道。Agent和认证服务器之间通过SFS传递信息。如果验证者拒绝了验证请求，Agent可以改变认证协议再次请求。如此一来，可以实现添加新的用户验证信息却不需要修改实际的真实文件系统。如果用户在文件服务器上没有注册过，Agent在尝试一定次数以后拒绝用户的身份验证，并且将用户授权匿名权限访问文件系统。另外，一个agent也能方便地通过多种协议连接任意给定的服务器，这些设计都会非常方便便捷，十分灵活。

密钥撤销机制

有些时候服务器的私钥可能会被泄漏，那么原有的自验证文件路径可能会错误地定位到恶意攻击者设置的服务器。为了避免这种情况发生，SFS提供了两种机制来控制： 密钥撤销指令和HostID阻塞。 密钥撤销指令只能由文件服务器的拥有者发送，它的发送目标是全部的用户。这一指令本身是自验证的。而HostID阻塞是由其他节点发送，可能与文件服务器拥有者冲突，每一个验证的Agent可以选择服从或者不服从HostID阻塞的指令。如果选择服从，对应的HostID将会不能被访问了。

密钥撤销指令的形式： Revoke message = {"PathRevok e", Location, K, NULL}K^-1 在这里 "PathRevoke" 字段是一个常量，Location是需要撤销密钥的自验证路径名称，NULL是为了保持转发指针指令的统一性，在这里将转发指针指向一个空路径，意味着原有指针失效了。这里K是失效前的公钥，K^-1是私钥。这一条信息能够确保撤销指令是由服务器所有者签发的。

当SFS客户端软件看到吊销证书时，任何要求访问撤销地址的请求都会被禁止。服务端会通过两种方式获取密钥撤销指令：1.SFS连接到服务器的时侯，如果访问到已经撤销的地址或路径，他会收到由服务器返回的密钥撤销指令。2.用户初次进行自认证路径名时，客户端会要求Agent检查是否已经被撤销，那么Agent会返回相应的结果。撤销指令是自验证的，正因此分发撤销指令并不是那么重要，我们可以很方便的请求其他源头发送的撤销指令。