· 授权计策 – 一种或多种授权计策（譬喻 OAuth2、HTTP 签名或授权成果）可用于掩护对加密数据的会见。
系统利用的加密索引需要最洪流平地提高隐私性。因此，在搜索系统中存在很多无法利用加密索引的操纵，譬喻对加密文本字段举办部门匹配或在大范畴内举办检索。未来，大概会通过利用零常识方案来添加这些成果的支持。
当数据客栈的客户端发出请求，想要对数据客栈中数据举办存储、查询、修改或删除时，处事器需要验证该请求。由于任何给定请求中的实际数据和元数据都是加密的，因此这种验证肯定受到必然限制，而且很洪流平上取决于请求的协议和语义。
加密数据客栈协议的体系布局是自然分层的，基本层由具有最少成果的业务系统构成，而更高级的成果则位于其上。在实现的时候，既可以选择仅实现基本层，也可以选择实现由更富厚成果集构成的其它层，以实现更高级的用例。
数据存储提供商可以或许在变动耐久化数据时通知客户端会给系统实现带来很大辅佐。处事器可以选择实现一种机制，客户端可以通过该机制订阅数据客栈中的变动。
客户：资源布局（L1）
meta
https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/encrypted-data-vaults.md
多个设备（多个用户）加上云存储：将多个用户与云存储配对时，可以利用数据客栈在多个用户之间同步数据，并回收必然的复制和归并计策。
进一步阐明恶意处事器的潜在进攻面和相关缓解技能。
选择授权计策
通知/宣布订阅机制
二、扩展
这里将具体先容一般安详性和隐私留意事项，以及将加密数据仓险库陈设到出产情况中暗含的特定隐私需求。
添加、删除和修改加密数据
加密搜索（同态加密，零常识证明）有哪些时机？有哪些危险？
加密数据客栈可以或许存储很多差异范例的数据，包罗非布局化二进制数据等。这意味着对付单个记录巨细有限制的系统而言，将文件存储为单个条目将是一个挑战。譬喻，某些数据库可以存储的单个记录最大为16MB。因此，按照处事器本领，需要将大数据切割为易于打点的分块。客户端认真将每个资源的块巨细和数据分块。处事器会拒绝为高出它最大本领的块存储请求处事。
掩护小我私家数据时的一个安详假设是假定所有加密方案城市被攻破。因此，一个存储计策是：处事器不宜利用任何范例的民众存储网络来存储加密数据。
孝敬者（按字母顺序）：Daniel Bluhm 和 Kim Hamilton Duff
该设置答允客户端发明处事器利用的一些相关成果，好比授权、协议和复制机制等。
· 通知机制 – 一种或多种通知机制，可用于向客户端发送通知，表白数据客栈中的数据已变动。
固然大大都处事提供商不是恶意的，但相识恶意处事提供商可以做什么和不能做什么也很重要。假定恶意处事提供商大概会举办以下进攻：
如何使最终用户对数据客栈感想安心？
处事器：通知（L3）
1.2 处事器和客户端职责
凡是来说，处事器很难确定实体的身份以及该实体会见加密数据客栈的目标。可是，当某个实体会见数据客栈时，总会有一些信息泄漏，譬喻会见模式、大致的文件巨细以及一些其它信息。系统被设计成不泄露这些和隐私相关的信息， 这种要领在必然水平上可以防备处事器大概采纳的监督等行为，而这些行为并不是最切合数据客栈用户隐私权计策的。
3.7 恶意处事提供商的威胁模子
3.3 数据会见按时进攻
移动设备加云存储：移动设备饰演客户端的脚色，而处事器是基于云的长途处事提供商，该提供商通过基于网络的 API（譬喻，基于 HTTPS 的 REST 接口）开放存储。数据不会存储在移动设备上。
客户端：版本节制和复本节制（L2）
id （必选）
第2层由一个系统构成，该系统可以或许在多个实体之间共享数据，举办版本节制和复制，并可以或许以有效的方法执行隐私掩护搜索。
四、将来的事情
我们先容了加密存储系统的当前要领和体系布局，提供了衍生的要求和设计方针，并重点先容了在实现具有隐私掩护成果的数据存储系统时应意识到的危险。本文还探讨了这类系统的根基假设，譬喻提供用于存储、索引和检索加密数据的隐私掩护机制，以及数据可移植性。我们但愿在该偏向上继承尽力，实现本文提到的方针。不然，客户端将对数据举办分片成块（请参阅下一节），且每个块均被加密并发送随处事器。在这种环境下，content 包括指向各个块的 URI 清单列表（由 Hashlinks 完整性掩护）。
1.2.3 第3层（L3）职责
客户端：加密数据分块（L1）
3.4 民众网络上的加密数据
仅移动设备：处事器和客户端位于同一设备上。数据客栈是一个通过 API 提供相关成果的 library 库，利用当地存储来提供加密数据库。
作者（按字母顺序）：Amy Guy、David Lamers、Tobias Looker、Manu Sporny 和 Dmitri Zagidulin
本节先容了加密数据客栈协议的体系布局。在本文中，将数据客栈视为处事器，而客户端则是数据客栈举办交互的接口。
固然处事提供商无法读取加密数据客栈中的数据，可是处事提供商可以删除、添加或修改加密的数据。通过将数据的全局清单保存在数据保管库中，可以防备对加密数据举办删除、添加或修改。
块巨细
1.2.1 第1层（L1）职责
id
利用认证加密别离方案加密每个块。这样做可以防备处事器替换某个大文件中的一些块并在受害者发明前要求受害者解密这个文件。利用认证加密方案加密每个块可以确保客户端对每一个块都能验证。值得留意的是，别的被授权的客户端可以提倡雷同进攻，但处事器却不能。
查询具体信息、排序和分页
· 协议/ API -可以利用一种或多种协议（譬喻 library API、HTTPS、gRPC 或 Bluetooth）会见系统。
数据客栈具有一些全局设置：
按照文件巨细和会见模式猜测存储在数据客栈中的文件范例
数据的所有加解密都在客户端侧举办。数据（包罗元数据）对付处事器必需是不透明的，且该体系布局需要防备处事器对数据解密。
3.6 加密索引的部门匹配
index – 客户端筹备的加密索引标签（与加密资源上的隐私掩护查询共同利用）
处事器：验证请求（L1）
假如数据节制者（拥有解密密钥和适当授权凭证的实体）意外地将会见权限授予了进攻者，则加密数据客栈大概会受到损害。譬喻，受害者大概扩大了授权范畴，不小心授权进攻者利用了整个保险库，可能利用加密密钥不妥，均有大概造成数据泄密。一旦进攻者可以会见整个系统，他们便可以修改、删除或变动保管库的设置。
客户端：加密资源布局（L1）
关联会见数据客栈中信息的实体
五、结论
处事器：全局设置耐久化（L1）
要存储加密数据，首先客户端需要构建切合必然布局的资源。
客户端：数据客栈范畴此外完整性掩护（L3）
密钥打点
content – 整个有效负载，或雷同于各个块 Hashlinks 的清单列表
三、安详和隐私留意事项
按照用例，我们思量以下陈设拓扑：
客户端：加密搜索索引（L2）
一、体系布局
1.2.2 第2层（L2）职责
选择改观节制/斗嘴办理计策
客户：与其他实体共享（L2）
3.2 受威胁的保险柜
处事器必需至少支持一种版本节制机制。复本节制由客户端完成（因为客户端节制密钥，知道数据要复制到哪些其它处事器等）。假如一个加密数据客栈实现需要提供复本节制成果，则必需选择某个版本节制计策（因为复制一定涉及斗嘴办理）。某些版本节制计策是隐式的（“ 最后写入胜出” ，譬喻 rsync 或将文件上传到文件托管处事）。可是，复本计策始终意味着应引入某种斗嘴办理机制。
这资源包罗：
· 加密方案 – 可以利用一种或多种加密方案，譬喻利用 AES-GCM 或 XSalsa20Poly1305来加密数据。
处事器用于耐久化数据的机制（譬喻，将数据存储在当地、网络或漫衍式文件系统上）由实现方法确定。该耐久化机制需要满意数据存储的通用需求，如靠得住的存储和检索数据。
加密的资源有效负载 – 可编码为 jwe，cwe 或回收其他适当的机制
我们凡是会假设处事器的可信度较低，且处事器不能看到耐久化的用户数据。可是，纵然在此模子中，处事器仍然具有一组必需遵守的最根基职责。
第1层包括一个客户端-处事器系统，该系统可以或许实现对数据在传输和存储时举办加密。
本文源自于 Rebooting Web of Trust 组织在 RWOT IX — Prague, 2019集会会议上的论文《Encrypted Data Vaults》的最后一部门。继上一部门先容了数据存储系统的常见用例、需求阐明以及建树加密数据客栈的一些指导原则和设计方针，本部门我们将探讨加密数据客栈的架构及一些安详和隐私方面的问题。
meta.contentType MIME 范例
原文：
尽量系统会尽最大本领来加密内容和元数据，但仍有少数字段无法加密，以确保处事器可以提供本文中提到的成果。譬喻，与数据关联的版本号，这可以提供对数据修改频率的一些信息。与加密内容关联的标识符使处事器可以通过大概跨文档关联标识符来获取常识。因此，发起实现最小化未加密存储的信息量。
3.1 数据的恶意或意外修改
1.1 陈设拓扑
多个设备（单个用户）加上云存储：添加单个用户打点的多个设备时，该数据客栈可用于跨设备同步数据。
这是建设加密资源的进程。假如数据已经被分片成块，则在将各个块写入处事器后执行此操纵。
工具更新的汗青记录检索
单个数据客栈的授权机制选择抉择了客户端如何与其他实体共享资源（授权成果链或雷同机制）。
提供整个数据客栈范畴的完整性掩护，可以防备恶意存储提供商以无法检测的方法修改数据。譬喻，将文档还原为旧版本或删除数据。这种完整性掩护要求客户端存储所有属于用户的资源标识符的全局目次以及最新版本，并保持最新状态。一些客户端大概会在当地存储此目次的副本（并利用诸如 Hashlinks 等的完整性掩护机制），以防备处事器滋扰或删除。
关于数据加密客栈，在我们正在举办的和未来的事情中将会思量以下各项：
差池加密数据实施授权计策
· 版本节制计策和复本计策 – 可以利用一种或多种版本节制和复本计策，譬喻计数器、暗码学哈希或 CRDTs（无斗嘴复制数据范例）来同步数据。
其他设置元数据
3.5 处事器上的未加密数据
客户端认真提供会见处事器的接口，并按照实现要求为每个相关协议（譬喻 HTTP、RPC 或其它协议）绑定。
假如数据小于块巨细，则将其直接放入 content 中
为了启用隐私掩护查询（检索索引对付处事器而言是不透明的），客户端必需筹备一个加密索引标签列表（与加密数据一起存储在“加密资源”中）。
处事器：授权计策的实施（L1）
处事器：数据耐久化（L1）
版本化元数据 – 譬喻序列号，雷同 Git 的哈希值或其他机制
当客户端请求在数据客栈中存储、查询、修改或删除数据时，处事器将强制执行与该请求关联的任何授权计策。
加密数据客栈应支持一些扩展：
块巨细（假如与全局设置中的默认巨细差异）
将加密数据泄漏到未知的外部系统
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
