摘要

长期以来，人们一直信任中央机构来协调局域网上的安全协作。不幸的是，互联网没有提供个人组织提供的那种管理结构。因此，如果全球分布式系统依赖中央机构来确保安全，用户将面临痛苦的后果。幸运的是，安全不需要以集中控制为代价。为了证明这一点，我们提出了SFS，这是一个安全的、全局的、去中心化的文件系统，允许轻松的跨管理领域协作。通过一个简单的想法，自我认证的路径名，SFS让用户摆脱集中控制的弊端。

1 引言

随着分布式应用程序变得越来越普遍，我们必须面对一个严重的危险：未来的分布式基础设施可能会作为安全的条件，使其用户受到严格的集中控制，并带来令人窒息的后果。 跨局域网协作的人通常在同一个组织内工作，从而限制了恶意行为的动机，并使受信任的人协调协作变得合理。 在整个Internet上，情况并非如此。全球分布式应用程序现在必须处理以前不寻常的管理关系，从组织或家庭之间的文件共享到在本地机器上运行不受信任的外部代码。如果全球应用程序的开发人员使用适用于局域网的技术来处理这些情况，他们将迫使每个人服从不适当的集中式权威。幸运的是，可以避免集中控制的问题。本文介绍了SFS，一种安全且去中心化的全局文件系统。

必须对任何全局文件系统提出两个基本问题：谁控制名称空间，以及客户端如何信任远程机器为该名称空间的某些部分提供服务？集中控制的命名空间阻碍了部署；它会阻止新的文件服务器上线，直到它们获得命名机构的批准。另一方面，客户端需要加密来保证远程通信的完整性和保密性； 这些保证需要加密密钥和全局命名空间中的点之间的绑定。为了在不依赖命名机构的情况下提供这种绑定，SFS在文件的路径名中嵌入了服务器公钥的等效项。我们将此类路径名称为自证明路径名。

通过在自认证路径名中公开公钥，SFS设法允许在单个命名空间内使用任意密钥管理策略。SFS认识到没有单一名称到键绑定过程可以满足所有需求。证书颁发机构、分级授权、非正式密钥交换、“信任网络”，甚至硬编码的加密密钥都在不同的情况下占有一席之地。 本文的其余部分将展示一个安全的文件系统实际上可以支持所有这些情况。

下一节通过概述集中控制的弊端来激发SFS设计。其余部分展示了用户如何通过 SFS 摆脱这些邪恶，并解释SFS如何在不诉诸任何集中控制的情况下实现安全的跨管理领域协作。

2 集中控制的弊端

身份验证构成任何安全网络基础设施的主要部分。 未经身份验证就无法使用用户帐户或网络资源。 因此，谁控制了身份验证，谁就控制了新资源的创建。 将权力集中在中央机构手中会阻碍部署，扼杀创新，使跨行政领域协作复杂化，排除有效网络资源，造成单点故障，并且通常让每个人都受制于权威。

几种形式的集中控制可能会困扰分布式系统。最明显的是过度依赖认证机构。任何安全的全球基础设施都必须让组织将名称绑定到公钥，但任何系统都不应天生信任此类证书颁发机构或授予它们特殊特权或地位。没有特定认证机构就无法运行的系统会使用户受制于该机构。如果当局决定勒索高额费用，不承担任何责任，排除某些国家的人，甚至强制托管密钥，用户将别无选择，只能遵守。

例如，运行安全HTTP的协议SSL [5]过于依赖认证机构。Netscape Web客户端的早期版本只能使用一个证书颁发机构，即Verisign。如果不支付数百美元为服务器主机购买Verisign证书，就无法使用具有安全HTTP的Netscape，甚至调试Web服务器。更糟糕的是，特别是对于那些开发免费网络服务器的人，威瑞信拒绝向没有运行多个商业网络服务器之一的任何人颁发证书。现在Netscape浏览器允许用户选择他们信任的证书颁发机构，但它本质上授予所有颁发机构相同级别的信任。这意味着认证机构都要求同样严格的认证过程。这个过程的麻烦限制了安全HTTP服务器的传播。

另一种形式的集中控制来自以某种方式惩罚跨管理领域使用的系统。为了促进协作，此类系统的用户倾向于形成不方便的大型管理领域。Kerberos [15]身份验证系统正是遇到了这个问题。Kerberos管理领域通常跨越组织内的许多部门。在没有Kerberos管理员的情况下，负责购买和维护机器的人员通常无法创建帐户或设置服务器。 AFS [7]分布式文件系统有一个更严重的问题。不仅是基于Kerberos的身份验证，而且客户端计算机的管理员还必须枚举客户端可以与之通信的每一个文件服务器。 AFS客户端的非特权用户根本无法访问他的管理员不知道的文件服务器。本文的其余部分将描述避免这些问题的分布式文件系统。

3 自认证路径名 

通过自认证路径名，SFS提供了一个全局名称空间，没有任何权限对其进行控制。此外，此命名空间允许对与文件服务器的通信进行加密保证。

每个SFS文件系统都有一个“/sfs/Location:HostID”形式的名称。Location告诉SFS客户端与服务器通信的位置，HostID告诉它如何安全地通信。位置只是一个DNS主机名或IP地址。HostID是服务器公钥和主机名的加密哈希。SFS使用SHA-1 [4]计算HostID，这是一种不存在已知冲突的单向函数。因此，HostID指定了一个唯一的、可验证的公钥，客户端可以使用该公钥建立与服务器的安全通信通道。使用此方案，SFS文件系统的名称完全足以证明其服务器。因此，自我证明的路径名形成了一个平等的命名空间，确保每个SFS文件系统都有一个位置。

在用户访问文件系统之前，SFS客户端不需要知道文件系统。当用户在/sfs下引用不存在的正确格式的目录时，SFS客户端会尝试联系由Location命名的机器。如果该机器存在，运行SFS，并且可以证明拥有对应于HostID的私钥，则客户端透明地在/sfs/中创建引用目录并将远程文件系统挂载在那里。这种自动挂载保证了每个人都有权创建文件系统。给定网络上的主机，任何人都可以生成公钥，确定相应的 HostID，运行SFS服务器软件，并立即通过其在世界上任何客户端上的自认证路径名引用该服务器。

当然，没有人会想要输入HostID——160位加密哈希的十六进制表示。相反，人们可以通过符号链接为挂载点分配人类可读的名称。例如，如果Verisign充当SFS证书颁发机构，则客户端管理员可能会创建从/verisign到该证书颁发机构的挂载点的符号链接 - 一个路径名，例如/sfs/sfs.verisign.com:75b4e39a1b58c265f72d-ac35e7f940c6f093cb80。该文件系统将依次包含指向其他SFS挂载点的符号链接，例如，/verisign/mit可能指向/sfs/sfs.mit.edu:0f69f4a059c62b35f2bdac05feef610af052c42c。

任何拥有全域可读目录的人都可以创建其他人可以直接使用的公共链接。例如，/verisign/mit/lcs/dm/sfs-dist 可以是SFS分发服务器的路径。 这种路径名的认证链总是明确的。这是服务器称为dm/sfs-dist，服务器称为lcs，服务器称为mit，服务器本地称为/verisign。尽管它没有得到威瑞信的官方认证，但人们仍然可以访问sfs-dist服务器并了解名称的确切含义。

4 使用SFS 

每个SFS服务器、目录和文件在世界上的每台机器上都有相同的规范路径名。因此，SFS提供了一个真正的全局文件系统。我们将讨论用户如何看待SFS以及运行SFS服务器所涉及的内容。

4.1 用户视图 

如前一节所述，用户挂载远程SFS文件系统只需通过直接或通过符号链接引用自认证路径名即可。这种机制使每台服务器都可以从任何客户端机器访问，同时始终允许对文件系统内容进行加密验证。但是，需要第二种用户身份验证机制来访问非全域可读的文件。为此，SFS文件服务器有一个本地文件/etc/sfs用户，类似于UNIX密码文件。sfs用户将用户帐户映射到公钥。用户必须在该文件中注册公钥并证明拥有相应的私钥才能访问服务器上的受保护文件。

一旦用户设置为访问受保护的文件，身份验证就会通过文件访问透明地进行。SFS客户端计算机的每个用户都运行一个可以访问私钥的非特权身份验证代理进程。当用户第一次引用文件系统时，客户端软件会联系代理，允许它向远程服务器验证用户的身份 服务器向代理发送使用用户公钥加密的质询； 如果用户代理成功响应此质询，则允许访问。

SFS服务器的访问控制完全基于发送请求的用户的身份，而不是请求来自的机器。因此，SFS没有客户端机器的管理领域的概念。每个客户端的配置都是相同的，尽管个别用户可能会以不同的方式配置他们的代理，并且肯定会给他们的代理访问不同的私钥。这种架构保证用户可以从他们足够信任的任何客户端计算机访问他们的文件。

4.2 SFS服务器 

设置一个普通的读写SFS文件服务器相当简单。只需要编辑sfs用户等几个配置文件，生成服务器的公钥/私钥对，启动软件。任何客户端都可以通过其自认证路径名立即访问新服务器。

可以通过分发其自认证路径名或将指向该路径名的符号链接放置在已经可访问的目录中来通知用户新服务器。

某些SFS服务器（例如证书颁发机构）可能具有非常高的完整性、可用性和性能需求。为了满足这些需求，SFS允许服务器使用预先计算的数字签名来证明只读文件系统的内容。这使得只读服务器所需的加密计算量与文件系统的大小和变化率成正比，而不是与连接的客户端数量成正比。它还使只读服务器无需保留其私钥的任何在线副本，这反过来又允许在不受信任的机器上复制只读文件系统。

4.3 示例 

为了说明SFS跨行政领域的使用，假设某公司的某个人与大学的一个研究项目合作。这种协作通常需要通过高延迟网络进行手动文件传输或远程登录。但是，使用SFS，大学可以简单地为该用户创建一个帐户，并将他的公钥放入sfs用户中。然后，用户可以从同一本地客户端计算机透明地访问大学的文件服务器和他公司的文件服务器。

无需重新配置客户端或进行任何特殊安排即可访问大学的文件系统。用户只需要引用该文件系统来挂载它。他可以通过已经可以访问的目录中的符号链接来引用它，或者，如果需要，他可以在方便的位置创建自己的链接。当然，用户必须分别通过大学和公司的身份验证。但是，他的经纪人会自动处理。

5 SFS 实现 

SFS认证协议是SFS命名系统的核心。我们详细讨论了协议，然后简要概述了系统的其余部分。

5.1 身份验证协议 

SFS身份验证协议受到ssh [17]的启发，但有一些修复 [1] 和修改。它分两个阶段进行：首先，向客户端验证服务器，其次，通过客户端向服务器验证用户。涉及三方：SFS客户端软件C、SFS服务器软件S和用户的身份验证代理 A。代理软件的唯一当前实现将所有私钥保存在与C相同的机器上。每个用户可以选择运行他的代理实现。未来，我们设想通过加密登录连接将身份验证请求转发到智能卡甚至其他代理的哑代理，就像目前使用ssh所做的那样。

第一阶段，如图1所示，向客户端验证服务器，客户端启动交换。目标是就两个客户端选择的共享会话密钥$K_{sc}$和 $K_{sc}$达成一致，以加密和保护客户端和服务器之间未来数据通信的完整性。服务器向客户端发送两个公钥，P $K_s$和P $K_t$ ：第一个P $K_t$是长寿命密钥，其哈希在路径名中；第二个，P $K_t$ ，是一个临时公钥，每小时更改一次。使用临时公钥提供了前向保密性：即使长期存在的密钥S$K_s$被破坏，一旦S $K_t$ 被破坏，旧的通信也无法在不破坏P $K_t$ 的情况下被解密。

该协议中的主机ID是客户端从路径名中获取的哈希值。客户端在其第一条消息中将主机ID和主机名发送到服务器，因此同一台机器可以服务多个文件系统，而无需多个IP地址。会话ID是两个会话密钥、服务器的临时公钥和服务器选择的随机数$N_0$的哈希值，用于在未来的通信中识别会话。$N_0$的明文回显N0 的明文回显对正确的身份验证没有影响，但可以被服务器用来过滤某些拒绝服务攻击，否则这些攻击会由于公钥解密的费用而需要大量的CPU时间[8]。

host ID = $\{P{K}_s,hostname{\}}_{SHA-1}$

session ID =$\{K_{cs},K_{sc,}P{K}_{t,}{N}_0{\}}_{SHA-1}$

图1. 密钥交换和服务器身份验证。

图 2. 验证用户。

在这个初始阶段之后，从C到S的所有流量都使用$K_{cs}$进行加密和验证，从S到C的所有流量都使用$K_{sc}$进行加密和验证。客户端可以确定它正在与服务器对话，因为只有服务器才能解密这些会话密钥。此时，C可以使用匿名权限访问S。

协议的第二阶段通过客户端向服务器验证用户，如图 2 所示。此阶段是访问受保护文件所必需的。这里，$P$ $K_u$是用户的公钥。用户的代理A拥有用户私钥$S{K}_{u}SK\_u$的副本。$N_{u}N\_u$是服务器选择的随机数或挑战。请注意，客户端和服务器之间的所有消息都使用私有会话密钥$K_{sc}K\_\{sc\}$和$K_{cs}K\_\{cs\}$之一进行加密。

用户鉴权最后一步中的鉴权信息用于在本地和远程用户和组ID之间建立一些合理的对应关系.在第一步中，请注意代理可以访问主机名和主机ID，如果需要，允许它验证主机ID；但是，代理永远不会看到$K_{cs}K\_\{cs\}$或$K_{sc}K\_\{sc\}$ ，即加密所有客户端-服务器通信的会话密钥。

5.2 实现细节

SFS客户端和服务器都使用NFS在用户级实现。 通过新的异步RPC库、快速加密算法、积极的磁盘客户端缓存和回写缓存，SFS在标准应用程序工作负载上的性能与Sun的未加密NFS[13]相当，同时还提供了安全性和基于租约的一致性。我们实施的细节超出了本立场文件的范围；该系统在[10]中有详细描述。

6 相关工作 

SFS的平等命名空间在精神上类似于SPKI/SDSI[3, 12]安全基础设施。

在SPKI/SDSI 中，主体是公钥，每个主体都充当其自己命名空间的证书颁发机构。SFS有效地将文件系统视为公钥。然而，因为文件系统本质上代表一个命名空间，所以SFS不需要特殊的认证机制——普通的符号链接已经完成了这项工作。SDSI指定了一些特殊的根，例如Verisign!!，它们在每个命名空间中指定相同的公钥。 如果客户端都在其本地根目录中安装指向证书颁发机构的符号链接，则SFS按照惯例可以实现类似的结果。 然而，我们认为这样的标准链接应该由惯例确定，而不是硬编码到文件系统中。

AFS[7, 14]可能是迄今为止最成功的全局文件系统。与SFS一样，它通过将所有远程文件系统挂载在单个目录/afs下，在本地和全局命名空间之间提供了清晰的分离。然而，与SFS不同的是，AFS客户端计算机包含一个固定的可用服务器列表，只有特权管理员才能更新这些服务器。AFS使用 Kerberos [15] 共享机密来保护网络流量，因此不能保证用户没有帐户的文件系统的完整性。尽管可以编译AFS以加密与用户拥有帐户的服务器的网络通信，但广泛使用的商业二进制分发不提供任何保密性。DFS [9]是基于AFS的第二代文件系统，其中一个集中维护的数据库决定了所有可用的文件系统。

Truffles服务[11]是Ficus文件系统 [6] 的扩展，可在Internet上安全运行。Truffles提供了细粒度的访问控制，具有有趣的属性，即在策略允许的情况下，用户可以将文件导出到世界上的任何其他用户，而无需管理员参与。不幸的是，这种文件共享的界面有些笨拙，并且涉及交换使用PEM签名和加密的电子邮件消息。Truffles还依赖于集中的、分层的证书颁发机构，使用 X.500 可分辨名称命名用户，并要求所有用户和服务器都使用X.509证书。

WebFS [16]在HTTP协议之上实现了一个网络文件系统。具体来说，WebFS使用HTTP协议在用户级HTTP服务器和内核客户端文件系统实现之间传输数据。这允许通过文件系统访问现有URL的内容。WebFS尝试通过HTTP [2]上的分层协议提供身份验证和安全性；身份验证需要认证机构的层次结构。

7 结论

SFS证明具有统一命名空间的安全全局文件系统不需要任何集中的权限来管理该命名空间。通过自认证路径名，SFS允许在单个命名空间内使用任意密钥管理策略。

原文链接：https://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.43.8989&rep=rep1&type=pdf

---煤油灯科技victorlamp.com翻译整理---