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

本文源自于 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 Duff

一、体系结构

本节介绍了加密数据仓库协议的体系结构。在本文中，将数据仓库视为服务器，而客户端则是数据仓库进行交互的接口。

加密数据仓库协议的体系结构是自然分层的，基础层由具有最少功能的业务系统组成，而更高级的功能则位于其上。在实现的时候，既可以选择仅实现基础层，也可以选择实现由更丰富功能集组成的其它层，以实现更高级的用例。

扫描二维码关注公众号，回复： 8489474 查看本文章

                                                                                                图 | 网络

1.1 部署拓扑

根据用例，我们考虑以下部署拓扑：

• 仅移动设备：服务器和客户端位于同一设备上。数据仓库是一个通过 API 提供相关功能的 library 库，使用本地存储来提供加密数据库。             

• 移动设备加云存储：移动设备扮演客户端的角色，而服务器是基于云的远程服务提供商，该提供商通过基于网络的 API（例如，基于 HTTPS 的 REST 接口）开放存储。数据不会存储在移动设备上。             

• 多个设备（单个用户）加上云存储：添加单个用户管理的多个设备时，该数据仓库可用于跨设备同步数据。             

• 多个设备（多个用户）加上云存储：将多个用户与云存储配对时，可以使用数据仓库在多个用户之间同步数据，并采用一定的复制和合并策略。             

1.2 服务器和客户端职责

我们通常会假设服务器的可信度较低，且服务器不能看到持久化的用户数据。但是，即使在此模型中，服务器仍然具有一组必须遵守的最基本职责。

客户端负责提供访问服务器的接口，并根据实现要求为每个相关协议（例如 HTTP、RPC 或其它协议）绑定。

数据的所有加解密都在客户端侧进行。数据（包括元数据）对于服务器必须是不透明的，且该体系结构需要防止服务器对数据解密。

1.2.1 第1层（L1）职责

第1层包含一个客户端-服务器系统，该系统能够实现对数据在传输和存储时进行加密。

• 服务器：验证请求（L1）

当数据仓库的客户端发出请求，想要对数据仓库中数据进行存储、查询、修改或删除时，服务器需要验证该请求。由于任何给定请求中的实际数据和元数据都是加密的，因此这种验证必定受到一定限制，并且很大程度上取决于请求的协议和语义。

• 服务器：数据持久化（L1）

服务器用于持久化数据的机制（例如，将数据存储在本地、网络或分布式文件系统上）由实现方式确定。该持久化机制需要满足数据存储的通用需求，如可靠的存储和检索数据。

• 服务器：全局配置持久化（L1）

数据仓库具有一些全局配置：

• 块大小             

• 其他配置元数据             

该配置允许客户端发现服务器使用的一些相关功能，比如授权、协议和复制机制等。

• 服务器：授权策略的实施（L1）

当客户端请求在数据仓库中存储、查询、修改或删除数据时，服务器将强制执行与该请求关联的任何授权策略。

• 客户端：加密数据分块（L1）

加密数据仓库能够存储许多不同类型的数据，包括非结构化二进制数据等。这意味着对于单个记录大小有限制的系统而言，将文件存储为单个条目将是一个挑战。例如，某些数据库可以存储的单个记录最大为16MB。因此，根据服务器能力，需要将大数据切割为易于管理的分块。客户端负责将每个资源的块大小和数据分块。服务器会拒绝为超过它最大能力的块存储请求服务。

使用认证加密分别方案加密每个块。这样做可以防止服务器替换某个大文件中的一些块并在受害者发现前要求受害者解密这个文件。使用认证加密方案加密每个块可以确保客户端对每一个块都能验证。值得注意的是，另外被授权的客户端可以发起类似攻击，但服务器却不能。

• 客户：资源结构（L1）

要存储加密数据，首先客户端需要构建符合一定结构的资源。

这资源包括：

• id （必选）

• meta    

• • meta.contentType MIME 类型     

• content - 整个有效负载，或类似于各个块 Hashlinks 的清单列表             

• 如果数据小于块大小，则将其直接放入 content 中

否则，客户端将对数据进行分片成块（请参阅下一节），且每个块均被加密并发送到服务器。在这种情况下，content 包含指向各个块的 URI 清单列表（由 Hashlinks 完整性保护）。

• 客户端：加密资源结构（L1）

这是创建加密资源的过程。如果数据已经被分片成块，则在将各个块写入服务器后执行此操作。

• id          

• index - 客户端准备的加密索引标签（与加密资源上的隐私保护查询配合使用）             

• 块大小（如果与全局配置中的默认大小不同）             

• 版本化元数据 - 例如序列号，类似 Git 的哈希值或其他机制             

• 加密的资源有效负载 - 可编码为 jwe，cwe 或采用其他适当的机制             

1.2.2 第2层（L2）职责

第2层由一个系统组成，该系统能够在多个实体之间共享数据，进行版本控制和复制，并能够以有效的方式执行隐私保护搜索。

• 客户端：加密搜索索引（L2）

为了启用隐私保护查询（检索索引对于服务器而言是不透明的），客户端必须准备一个加密索引标签列表（与加密数据一起存储在“加密资源”中）。

• 客户端：版本控制和复本控制（L2）

服务器必须至少支持一种版本控制机制。复本控制由客户端完成（因为客户端控制密钥，知道数据要复制到哪些其它服务器等）。如果一个加密数据仓库实现需要提供复本控制功能，则必须选择某个版本控制策略（因为复制必然涉及冲突解决）。某些版本控制策略是隐式的（“ 最后写入胜出” ，例如 rsync 或将文件上传到文件托管服务）。但是，复本策略始终意味着应引入某种冲突解决机制。

• 客户：与其他实体共享（L2）

单个数据仓库的授权机制选择决定了客户端如何与其他实体共享资源（授权功能链或类似机制）。

1.2.3 第3层（L3）职责

• 服务器：通知（L3）

数据存储提供商能够在更改持久化数据时通知客户端会给系统实现带来很大帮助。服务器可以选择实现一种机制，客户端可以通过该机制订阅数据仓库中的更改。

• 客户端：数据仓库范围别的完整性保护（L3）

提供整个数据仓库范围的完整性保护，可以防止恶意存储提供商以无法检测的方式修改数据。例如，将文档还原为旧版本或删除数据。这种完整性保护要求客户端存储所有属于用户的资源标识符的全局目录以及最新版本，并保持最新状态。一些客户端可能会在本地存储此目录的副本（并使用诸如 Hashlinks 等的完整性保护机制），以防止服务器干扰或删除。

二、扩展

加密数据仓库应支持一些扩展：

• 协议/ API -可以使用一种或多种协议（例如 library API、HTTPS、gRPC 或 Bluetooth）访问系统。             

• 加密方案 - 可以使用一种或多种加密方案，例如使用 AES-GCM 或 XSalsa20Poly1305来加密数据。             

• 授权策略 - 一种或多种授权策略（例如 OAuth2、HTTP 签名或授权功能）可用于保护对加密数据的访问。             

• 版本控制策略和复本策略 - 可以使用一种或多种版本控制和复本策略，例如计数器、密码学哈希或 CRDTs（无冲突复制数据类型）来同步数据。             

• 通知机制 - 一种或多种通知机制，可用于向客户端发送通知，表明数据仓库中的数据已更改。  

三、安全和隐私注意事项

这里将详细介绍一般安全性和隐私注意事项，以及将加密数据仓险库部署到生产环境中暗含的特定隐私需求。

3.1 数据的恶意或意外修改

虽然服务提供商无法读取加密数据仓库中的数据，但是服务提供商可以删除、添加或修改加密的数据。通过将数据的全局清单保留在数据保管库中，可以防止对加密数据进行删除、添加或修改。

3.2 受威胁的保险柜

如果数据控制者（拥有解密密钥和适当授权凭证的实体）意外地将访问权限授予了攻击者，则加密数据仓库可能会受到损害。例如，受害者可能扩大了授权范围，不小心授权攻击者使用了整个保险库，或者使用加密密钥不当，均有可能造成数据泄密。一旦攻击者可以访问整个系统，他们便可以修改、删除或更改保管库的配置。

3.3 数据访问定时攻击

通常来说，服务器很难确定实体的身份以及该实体访问加密数据仓库的目的。但是，当某个实体访问数据仓库时，总会有一些信息泄漏，例如访问模式、粗略的文件大小以及一些其它信息。系统被设计成不泄露这些和隐私相关的信息， 这种方法在一定程度上可以防止服务器可能采取的监视等行为，而这些行为并不是最符合数据仓库用户隐私权策略的。

3.4 公共网络上的加密数据

保护个人数据时的一个安全假设是假定所有加密方案都会被攻破。因此，一个存储策略是：服务器不宜使用任何类型的公共存储网络来存储加密数据。

3.5 服务器上的未加密数据

尽管系统会尽最大能力来加密内容和元数据，但仍有少数字段无法加密，以确保服务器可以提供本文中提到的功能。例如，与数据关联的版本号，这可以提供对数据修改频率的一些信息。与加密内容关联的标识符使服务器可以通过可能跨文档关联标识符来获取知识。因此，建议实现最小化未加密存储的信息量。

3.6 加密索引的部分匹配

系统使用的加密索引需要最大程度地提高隐私性。因此，在搜索系统中存在许多无法使用加密索引的操作，例如对加密文本字段进行部分匹配或在大范围内进行检索。将来，可能会通过使用零知识方案来添加这些功能的支持。

3.7 恶意服务提供商的威胁模型

虽然大多数服务提供商不是恶意的，但了解恶意服务提供商可以做什么和不能做什么也很重要。假定恶意服务提供商可能会进行以下攻击：

• 关联访问数据仓库中信息的实体             

• 根据文件大小和访问模式推测存储在数据仓库中的文件类型             

• 添加、删除和修改加密数据             

• 不对加密数据实施授权策略             

• 将加密数据泄漏到未知的外部系统

四、未来的工作

关于数据加密仓库，在我们正在进行的和将来的工作中将会考虑以下各项：

• 查询详细信息、排序和分页             

• 密钥管理             

• 选择授权策略             

• 选择变更控制/冲突解决策略             

• 通知/发布订阅机制             

• 在授权模型中，数据仓库仅执行授权规则还是充当授权服务器？             

• 如何使最终用户对数据仓库感到放心？             

• 进一步分析恶意服务器的潜在攻击面和相关缓解技术。             

• 加密搜索（同态加密，零知识证明）有哪些机会？有哪些危险？             

• 对象更新的历史记录检索     

五、结论

我们介绍了加密存储系统的当前方法和体系结构，提供了衍生的要求和设计目标，并重点介绍了在实现具有隐私保护功能的数据存储系统时应意识到的危险。本文还探讨了这类系统的基本假设，例如提供用于存储、索引和检索加密数据的隐私保护机制，以及数据可移植性。我们希望在该方向上继续努力，实现本文提到的目标。