科普 | 隐私保护堪忧？加密数据仓库大显身手

本文源自于 Rebooting Web of Trust 组织在 RWOT IX — Prague, 2019会议上的论文《Encrypted Data Vaults》的部分章节。

原文：

https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/encrypted-data-vaults.md

作者（按字母顺序）：Amy Guy、David Lamers、Tobias Looker、Manu Sporny 和 Dmitri Zagidulin

贡献者（按字母顺序）：Daniel Bluhm 和 Kim Hamilton Duffy

我们在线上存储了大量敏感数据，例如个人识别信息（PII）、商业机密、家庭照片和客户信息，而这些数据通常没有得到应有的保护。

一般来说，人们主要通过立法，如《通用数据保护条例》（GDPR）等来约束服务提供商，以确保他们在发生数据泄露事件时承担责任，激励其更好地保护个人隐私。这种责任压力暴露了技术上的短板，服务供应商通常没有完善的技术来保护其客户的隐私。而加密数据仓库弥补了这一空白，并具有诸多其他的优势。

本文介绍了当前的方法和体系结构、派生的要求、设计目标以及开发者在实现数据存储时应意识到的风险。同时还探讨了这类系统的基本假设，如提供用于存储、索引和检索加密数据的隐私保护机制以及数据的可移植性。

 

当前的生态系统和现有工作

去中心化数据存储的问题已从不同的角度实现，去中心化或其它方式的个人数据存储（PDS）在商业和学术背景中都有着悠长的历史。不同的方法导致了术语和体系结构的差异。下图显示了已有的组件类型以及其作用。不难看出，加密数据仓库主要提供存储的功能。

 

 

接下来我们将简述一些现有的实现方案之间的共性和差异。可能并不全面，但我们试图选择一些作者最熟悉，代表不同方法类型的项目。

 

架构和部署

许多体系结构都是围绕将数据存储与使用存储数据的应用程序层分开的想法设计的。我们可以将这些应用程序视为具有不同复杂度的客户端，并将数据存储视为服务器。一些项目期望建立具有多样应用的生态系统，并根据这一点来设计其协议。NextCloud、Solid 和 DIF's Identity Hubs 都描述了用于将终端用户程序与数据存储解耦的体系结构。这样的应用程序可以是用于浏览或共享数据的通用文件管理接口，也可以是为特定任务（例如日历）设计的专用领域的某种工具。而 Datashards、Tahoe-LAFS 和 IPFS 仅与数据存储和检索有关。

对于 Solid、NextCloud 和 Identity Hubs，终端用户可以选择在他们自己控制的设备上安装并运行数据存储的服务器部分，或者注册到受信第三方（例如商业提供商，关联机构或朋友）托管的已配置实例上。对于 Datashards 和 Tahoe-LAFS，终端用户在其控制的一个或多个设备上安装应用程序，并且将这些数据存储于设备的本地。IPFS 是点对点的，因此终端用户仅安装读/写客户端，而数据存储在公共网络上。

Identity Hubs 除了负责数据存储，还具有其他作用，例如终端用户资料的管理、传输人或机器可读的消息及指向外部服务。

 

 

加密策略

加密数据存储的一个重要考虑因素是架构中的哪些组件可以访问（未加密的）数据，或者由谁来控制私钥。大致有三种方法：存储侧加密、客户端（边缘）加密和网关侧加密（是前两种的混合）。

任何允许用户存储任意数据的数据存储系统基本上都支持客户端加密。也就是说，它们允许用户自己加密数据，然后将其存储。但是，这并不意味着这些系统针对加密数据进行了优化，查询和访问加密数据可能很困难（例如，Solid、NextCloud、Identity Hubs 和 IPFS 就是这种情况）。

存储侧加密通常表现为全盘加密或文件系统级加密。这得到了广泛的支持和理解，任何类型的托管云存储都可能使用存储侧加密。在这种情况下，私钥由存储服务器的服务提供商或控制器管理，它们可以是多种实体，并可以和存储数据的用户不同。存储侧加密是一种有效的安全措施，尤其当存储硬件能被直接物理访问时十分奏效。但这种方法不能保证只有存储数据的原始用户才可以访问。

相反，客户端加密（与 Datashards 一样）提供了高度的安全性和隐私性，尤其是在元数据也可以加密的情况下。该方法中，加密通常在 keychain 或钱包客户端的协助下，于单个数据对象这一级别进行。因此，用户可以直接访问私钥。但代价是，密钥管理和恢复的责任直接落在了终端用户身上。另外，当需要共享数据时，密钥管理的问题变得更加复杂。

像 Tahoe-LAFS 这样的网关侧加密系统采用了一种结合存储侧加密和客户端加密技术的方法。这些存储系统在多服务器集群或某些加密云服务提供商平台中经常遇到。这些服务商认识到对于某些用户和用例而言，客户端密钥管理可能太难了，并愿意以对客户端应用程序透明的方式提供加解密服务。同时，它们试图最大程度地减少可访问私钥的组件（存储服务器）数量。基于这样的考虑，密钥通常位于“ 网关” 服务器上，该服务器在将数据传递到存储服务器之前对其进行加密。加解密对客户端是透明的，而数据对存储服务器是不透明的。因此，存储服务器可以模块化或可拔插化设计。网关侧加密具备一些强于存储侧加密的优点，但也存在一些缺点，即控制密钥的是网关系统管理员，而不是用户。

 

加密的元数据

 

We kill people based on metadata.

- General Michael Hayden, former director of the NSA and the CIA

 

元数据是否可以（或要求被）加密对系统的隐私、安全性和可用性存在一定的影响。

某些系统，包括 Solid、NextCloud 和 Identity Hubs，支持在二进制数据上包含任意元数据，而 IPFS、Datashards 和 Tahoe-LAFS 则没有。Solid 中，客户端使用 RDF 按资源编写元数据。Identity Hubs 将 JWT 用于每个对象的元数据，并将 JSON 文档用于 Collections 中的其他元数据（这也是客户的责任）。NextCloud 客户端可以使用 WebDAV 自定义属性将元数据添加到文档中，但这些都没有涉及到元数据加密。

 

访问接口和控制

无论是通过网络还是在本地设备上访问数据，数据对象都倾向于需要全局唯一的标识符。在不同的实现中，用于读取数据和写入数据的存储接口，以及限制或授权这么做的机制会有所不同。

NextCloud 和 Solid 都利用现有的 Web 标准。NextCloud 使用 WebDAV 技术，允许其客户端应用程序可以使用目录结构来读取、写入和搜索服务器文件系统上的数据，并支持用于身份验证的自定义登录流。Solid 将 LDP 与 OpenID Connect 身份验证以及 Web 访问控制相结合，允许用户登录客户端应用程序后读取或写入数据。Solid 服务器上的资源（数据对象）由 HTTP URI 表示，Solid 服务器接收包含 RDF 有效负载的 HTTP 请求，并相应地创建或修改目标 URI。

Identity Hubs 使用 JSON Web 令牌（JWT）和指定的服务端点。这需要多个请求，首先要检索所需数据对象的元数据，然后要检索构成实际数据的 commit 序列。其身份认证机制仍在开发中，而访问控制是通过“权限”接口来执行的。

Tahoe-LAFS 使用客户端网关存储服务器架构，客户端将数据传递到网关服务器进行加密和分块，网关依次将各个块存储在存储服务器集群中。同时，数据会进行多副本存储，以提高可用性，并有助于数据恢复。服务使用 Foolscap URI 进行标识，并且可以将客户端配置为使用 HTTP 、(S)FTP 或侦听本地目录（“ magic folder ” ）以创建、更新和删除数据。数据以类似文件系统的目录结构进行组织，并利用其进行访问控制。

IPFS 是一种分布式的内容寻址存储机制，可将数据分解到 Merkle-DAG 中。IPFS 使用 IPLD 为内容中的数据生成 URI，并将内容链接到网络上，使用 DHT 在网络上发现内容。

 

索引和查询

由于加密数据对存储服务器而言不透明，这会给数据索引和搜索带来挑战。一些系统通过将一定数量的未加密元数据附加到数据对象上来解决此问题。另一种可能性是使用未加密指针列表，指向过滤后的数据子集。

Solid 旨在为文件系统提供可通过 Web 访问的界面。资源（RDF 文档或任意文件）被组织到类似文件夹的容器中，在实现上需要考虑数据存储的粒度（例如，文件系统或数据库）。Solid 没有指定搜索接口，但是某些实现可能会采用 SPARQL 或者 TPF。

Identity Hubs 同样使用 Collections 接口进行索引。客户端负责将适当的元数据写入自身未加密的集合中，从而使 Hub 能够响应查询。

NextCloud 将数据对象分类到目录中，客户端可以使用 WebDAV 的 SEARCH 和 PROPFIND 方法查询数据和元数据。

Tahoe-LAFS、Datashards 和 IPFS 是低级存储协议，不提供索引或搜索数据。

 

可用性，复制和冲突解决

跨多个存储位置进行数据复制可以为系统提供快速恢复的能力，增强系统安全性。支持对等复制的系统必须提供诸如 CRDTs 之类的冲突解决机制，或者要求终端用户干预以合并不同步的文件。NextCloud 作为商业企业产品，可使得数据在多个实例中流动，以实现可伸缩性。不同的 NextCloud 服务器不会直接相互通信，但是可以通过用户安装的应用程序进行通信。类似地，Solid 服务器的不同实例也不会相互通信。客户端应用程序可以在存储服务器之间执行任何必要的通信，但是这些服务器通常属于不同用户，而不是存储相同数据的副本。

IPFS、Tahoe-LAFS 和 Datashards 通过使用内容可寻址的链接对数据进行分块，并存储许多分块副本来实现高可用性。由于它们是低级协议，且数据对于服务器来说并不透明，因此它们不进行冲突解决。

Identity Hubs 中，Hub 实例之间更改同步和冲突解决方案正在开发中。

 

总结

上面概述了个人数据存储方面中一些活跃项目的特点。这些项目旨在使终端用户无需中心化权威机构或专有技术即可控制其数据。

从目前来看，很难在一个系统中同时实现所有数据和元数据的客户端（边缘）加密，以使用户能够将数据存储在多个设备上并与其他实体共享数据，同时还可被搜索或查询。从该调查中我们可以看出，通常需要进行取舍，比如需要牺牲隐私权以提高可用性，反之亦然。

由于现在许多技术和标准正在走向成熟，我们希望不再需要这种折衷的办法，并探寻为加密的去中心化数据存储设计一种具有广泛实用性的隐私保护协议的可能。

本体在去中心化的身份和个人数据隐私保护等方面进行了大量的探索，欢迎各位技术伙伴加入我们共同探讨。后期我们将会为大家提供该论文的下半部分，探讨这类系统的基本假设，如提供用于存储、索引和检索加密数据的隐私保护机制以及数据的可移植性。