加密数据保管库v0.1（一种隐私保护的机密存储与共享机制）

DIF（去中心化身份基金会），于2022年06月22日非正式地提出了一种隐私保护的机密存储与共享机制：加密数据保管库v0.1。

内容来源于：加密数据保险库 v0.1 (identity.foundation)

由于本人精力和时间有限，翻译和整理存在不恰当和不正确之处，如有错误欢迎指出。

我们在网上存储了大量的敏感数据，如个人识别信息（PII）、商业秘密、家庭照片和客户信息。我们存储的数据往往没有得到适当的保护。
本规范描述了一种在存储提供者处存储、索引和检索加密数据的隐私保护机制。当个人或组织希望以存储提供商无法查看、分析、聚集或转售数据的方式保护数据时，它通常很有用。这种方法还确保应用程序数据是可移植的，并防止存储提供商的数据泄露。

文档状态

本文档是一个潜在规范的草案。它没有任何官方地位，也不代表任何标准组织的支持或共识。
该规范是W3C证书社区组和去中心化的身份基金会的联合工作项。该规范是这两个小组所做工作的和迭代的组合。在附录中可以找到尚未集成到规范中的输入文档或其部分。

引言

我们在网上存储了大量的敏感数据，如个人识别信息（PII）、商业秘密、家庭照片和客户信息。我们存储的数据往往没有得到适当的保护。
立法，如《一般数据保护条例》（GDPR），激励服务提供商更好地保护个人隐私，主要是通过让提供商在数据泄露的情况下承担责任。这种责任压力暴露了一种技术差距，即供应商往往没有能够适当保护其客户的技术。加密数据金库填补了这一空白，并提供了各种其他好处。
本规范描述了一种在存储提供者处存储、索引和检索加密数据的隐私保护机制。当个人或组织希望以存储提供商无法查看、分析、聚集或转售数据的方式保护数据时，它通常很有用。这种方法还确保应用程序数据是可移植的，并防止存储提供商的数据泄露。

为什么我们需要保密储存？

要求对所有数据和元数据进行客户端（边缘）加密，同时允许用户在多个设备上存储数据并与其他设备共享数据，同时拥有可搜索或可查询的数据，这在历史上一直很难在一个系统中实现。人们经常做出取舍，牺牲隐私以换取可用性，反之亦然。
由于大量成熟的技术和标准，我们希望这样的权衡不再是必要的，设计一种具有广泛实用吸引力的加密分布式数据存储隐私保护协议成为可能。

生态系统概述

分布式数据存储问题已经被从不同的角度来研究，而个人数据存储（PDS），无论分散与否，在商业和学术环境中都有着悠久的历史。不同的方法导致了术语和体系结构的变化。下图显示了正在出现的组件类型以及它们所扮演的角色。加密数据仓库实现了低级加密存储角色。

本节描述了核心参与者的角色以及他们之间的关系，在这个规范有望有用的生态系统中。角色是一种抽象，可以以许多不同的方式实现。角色的分离为标准化提供了可能的接口和协议。本规范中介绍了以下角***r />

数据保管库控制器
实体可以通过创建、管理和删除数据仓库来执行的角色。该实体还负责向其控制下的数据仓库的存储代理授予和撤销授权。
存储代理
实体通过在数据仓库中创建、更新和删除数据来执行的角色。该实体通常由数据仓库控制器授予访问数据仓库的授权。
存储提供商
实体可以通过向数据仓库控制器提供原始数据存储机制来执行的角色。这个实体不可能看到它所存储的数据，因为所有数据都是在静止状态下加密的，并且在与存储提供者之间传输。

需求

下面的部分详细阐述了从核心用例中收集到的需求。

该系统的主要目标之一是确保实体数据的隐私性，使其不能被未经授权的方（包括存储提供商）访问。
要做到这一点，数据必须在传输时（通过网络发送）和静止时（在存储系统上）都进行加密。
由于数据可以与多个实体共享，加密机制还需要支持对多方进行加密。

共享和授权

需要有一种机制能够在一个或多个实体之间授权共享加密信息。
预计该系统将指定一个强制授权方案，但也允许其他备用授权方案。授权方案的示例包括OAuth2和[断续器]s(授权功能)。

标识符

系统应与标识符无关。通常，首选作为 URN 或 URL 形式的标识符。虽然据推测[DID-Core]（分散标识符，DID）将被系统以几种重要的方式使用，将实现硬编码为DID将是一种反模式。

版本控制和复制

预计信息可以在连续的基础上得到备份。因此，系统必须至少支持一种强制版本控制策略和一种强制复制策略，但也允许其他替代版本控制和复制策略。

元数据和搜索

该系统预计将存储大量的数据，然后需要有效和有选择地检索这些数据。为此，加密搜索机制是该系统的一个必要特征。
对于客户端来说，能够将元数据与数据关联起来以便进行搜索是很重要的。同时，由于数据和元数据的隐私是一个关键需求，元数据必须以加密的状态存储，服务提供者必须能够以不透明和隐私保护的方式执行搜索，而不能看到元数据。

协议

由于该系统可以驻留在多种操作环境中，因此至少有一种协议是强制性的，但设计也允许其他协议，这一点很重要。协议的例子包括HTTP、gRPC、蓝牙和各种二进制在线协议。在#data-vault-https-api中定义了一个HTTPS API。

设计目标

本节详细阐述了塑造加密数据库的一些指导原则和设计目标。

分层模块化体系结构

分层体系结构方法用于确保系统的基础易于实现，同时允许在较低的基础上分层更复杂的功能。
例如，第1层可能包含最基本系统的强制功能，第2层可能包含对大多数部署有用的功能，第3层可能包含生态系统的一小部分子集所需的高级功能，第4层可能包含生态系统的一小部分子集所需的极其复杂的功能。

优先考虑隐私

该系统旨在保护实体的隐私性。当探索新功能时，总是问“这会如何影响隐私?”对隐私产生负面影响的新功能预计将经过严格审查，以确定这些权衡是否值得新功能。

将实现复杂性推给客户端

该系统中的服务器将提供侧重于加密数据存储和检索的功能。服务器知道的越多，存储数据的实体的隐私风险就越大，服务提供者可能对托管数据负有更多的责任。此外，将复杂性推给客户端使服务提供者能够提供稳定的服务器端实现，而创新可以由客户端进行。

一致性

除了标记为非规范的部分外，本规范中所有的编写指南、图表、示例和注释都是非规范的。本规范中的其他一切都是规范的。
本文档中的关键字可以、必须和不可以按照BCP 14 [RFC2119] [RFC8174]中的解释，当且仅当它们以所有大写字母出现时，如图所示。

术语

以下术语用于描述本规范中的概念。

实体
独立存在的事物，如在生态系统中扮演一个或多个角色的人、组织或设备。

用户代理
一种程序，如浏览器或其他Web客户端，它在此规范中的各种角色之间进行通信。
URI
由[RFC3986]定义的标识符。

实例
安全数据存储实例是满足EDV和/或Hub接口需求的软件部署。

控制器
加密数据保险库实例的控制器（在保险库创建时的保险库配置对象中指定）是控制该实例的实体。控制器通常表示为去中心化身份（DID），它对保险库中的所有加密资源（包括保险库配置对象）具有根授权，并可以将授权委托给其他实体(存储代理)。

加密的资源
存储在EDV实例中的加密对象（非结构化文本、结构化文档或二进制blob）。大小小于10MiB的JSON对象存储在结构化文档资源中。二进制对象或大于最大大小的JSON对象存储在流资源中。

复制
将一个实例(存储的加密对象和索引)的内容复制到另一个实例的过程。复制可以配置为单向或双向，并可以以几种模式(实时、全同步或两者都有)运行。

同步
复制和冲突解决的组合。

解决冲突
解决编辑冲突的过程，如果不同的客户端同时对同一资源进行不同的更改，就会发生编辑冲突。这些编辑可以发生在同一个实例上，也可以发生在设置为相互复制的不同实例上。解析可以是自动的（例如，Git合并），也可以是手动的（用户可能需要干预并选择保留哪个编辑，覆盖哪个编辑）。

双向复制
两个实例之间复制设置的配置属性。使用双向复制，两个实例将所有更改同步到其中一个内容。

单向复制
两个实例之间复制设置的配置属性。使用单向（单向）复制，只有对一个实例（源）的更改会传播到另一个实例（目标），反之则不行。

实时复制
一种复制模式，在这种模式下，一旦对源实例上的对象进行了更改，这些更改就“立即”（在网络连接的限制范围内）传播到目标实例。

完全同步复制
一种与实时模式互补的复制模式，通常在源实例和目标实例之间的连接中断时需要使用。使用全同步复制，实例比较它们的内容，以查看断开连接时发生了哪些更改，然后将所有这些更改复制到彼此。

过滤后的复制
一种复制模式，在这种模式下，仅根据某些筛选器或条件将源实例内容的子集复制到目标实例。例如，“仅复制索引标记为X的加密文档”的规则将被过滤复制。

下面几节概述了核心概念，例如构成本规范基础的加密存储。

加密存储

加密数据存储的一个重要考虑因素是体系结构的哪些组件可以访问（未加密的）数据，或者谁控制私钥。大致有三种方法:存储端加密、客户端（边缘）加密和网关端加密（这是前两种方法的混合）。
任何允许用户存储任意数据的数据存储系统也支持最基本级别的客户端加密。也就是说，它们让用户自己加密数据，然后存储数据。但这并不意味着这些系统针对加密数据进行了优化。对加密数据的查询和访问控制可能会很困难。
存储端加密通常以整个磁盘加密或文件系统级加密的方式实现。这得到了广泛的支持和理解，并且任何类型的托管云存储都可能使用存储端加密。在此场景中，私钥由存储服务器的服务提供者或控制器管理，该服务器可能是与存储数据的用户不同的实体。如果对存储硬件的物理访问被破坏，对存储在磁盘上的数据进行加密是一种有用的安全措施，但不能保证只有存储数据的原始用户有访问权限。
相反，客户端加密提供了高级别的安全性和隐私性，特别是在元数据也可以加密的情况下。加密是在单个数据对象级别进行的，通常由密钥链或钱包客户端辅助，因此用户可以直接访问私钥。然而，这是有代价的，因为密钥管理和恢复的重要责任完全落在最终用户身上。此外，当数据需要共享时，密钥管理问题变得更加复杂。
网关端加密系统采用一种结合存储端和客户端加密体系结构技术的方法。这些存储系统通常是在多服务器集群或一些“加密即平台”云服务提供商之间遇到的，它们认识到客户端密钥管理对一些用户和用例来说可能太困难，并提出以一种对客户端应用程序透明的方式自己执行加密和解密。同时，它们的目标是最小化能够访问私钥的组件（存储服务器）的数量。因此，密钥通常驻留在“网关”服务器上，在将数据传递给存储服务器之前，网关服务器对数据进行加密。加密/解密对客户端是透明的，数据对存储服务器是不透明的，实现了模块化/可插拔。与存储端系统相比，网关端加密提供了一些好处，但也有一些缺点：网关sysadmin控制密钥，而不是用户。

加密的资源

结构化文档资源

数据仓库中存储的基本单元是加密的结构化文档，解密后，它提供了一种数据结构，可以用JSON和cor等流行语法表示。文档可以存储结构化数据和关于结构化数据的元数据。

流资源

对于大于10MiB的文档或原始二进制数据格式（如音频、视频和办公生产力文件），提供了一个流API，使数据能够流到/从数据仓库。使用结构化文档描述流，但使用到加密内容的散列链接将数据存储与结构化文档分离。

索引和查询

数据仓库需要存储大量不同类型的文档。这意味着能够及时地搜索文档是很重要的，这给存储提供者带来了挑战，因为内容是加密的。为安全的数据仓库提供了一种加密的查询方案，使数据仓库客户端能够进行元数据索引，同时不会将元数据泄漏给存储提供者。

操作

数据仓库允许在其数据模型上执行经典的CRUD（创建、读取、更新和删除）操作集。

创建操作

创建保管库：通过指定结构创建/配置加密的数据仓库。这包括复制配置。
创建索引：为特定的保险库创建索引。
创建资源（文档或流）：在给定的仓库中创建资源。

读操作

读取保管库配置：返回给定保险库的对象。
读索引：返回索引配置对象。
读取资源（文档或流）：返回给定的资源。

更新保管库配置：修改给定保险库的对象。
更新索引：修改索引配置对象。
更新资源（文档或流）：更新加密的资源（注意这是一个“完全替换”操作）。

删除操作

删除保管库配置：删除一个保管库。
删除索引：删除一个索引。
删除资源（文档或流）：删除加密资源（注意，为了复制的目的，应该保留一个tombstone对象）。

查询操作

发送加密索引查询：根据已创建的索引查询给定数据仓库中的加密资源。

体系结构

本节以客户-服务器关系的形式描述加密数据仓库协议的架构。保险库被视为服务器，客户端充当与保险库交互的接口。
这种体系结构本质上是分层的，其中基础层由具有最少特性的操作系统组成，而更高级的特性则是分层的。实现可以选择只实现基础层，也可以选择实现由更高级用例的更丰富的特性集组成的附加层。

服务器和客户端的职责

假定服务器的信任度较低，并且必须对其保存的数据不可见。然而，即使在这个模型中，服务器仍然有一组它必须遵守的最低责任。
客户端负责提供到服务器的接口，根据实现的需要，为每个相关协议（HTTP、RPC或二进制over-the-wire协议）提供绑定。
数据的所有加密和解密都是在客户端边缘完成的。数据（包括元数据）对服务器来说必须是不透明的，这种架构被设计成防止服务器能够解密它。

第1层（L1）职责

第1层由客户机-服务器系统组成，能够对传输中的和静止的数据进行加密。

服务器：验证请求（L1）

当保险库客户端发出存储、查询、修改或删除保险库中的数据的请求时，服务器将验证该请求。由于任何给定请求中的实际数据和元数据都是加密的，因此这种验证必然受到限制，并且在很大程度上依赖于请求的协议和语义。

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

服务器用于持久化数据的机制（如存储在本地、网络或分布式文件系统上）由实现决定。持久性机制应该符合数据存储提供者的共同期望，例如数据的可靠存储和检索。

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

一个保险库有一个全局配置，它定义了以下属性：

• 流块大小
• 其他配置元数据

配置允许客户机执行关于服务器使用的授权、协议和复制机制等方面的功能发现。

服务器：执行授权策略（L1）

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

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

加密的数据仓库能够存储许多不同类型的数据，包括大型非结构化二进制数据。这意味着，将文件存储为单个条目将对对单个记录大小有限制的系统构成挑战。例如，一些数据库将单个记录的最大大小设置为16MB。因此，有必要将大数据分成易于由服务器管理的大小。客户端负责设置每个资源的块大小，并将大数据分成服务器可管理的块。服务器有责任拒绝存储大于1MiB的块的请求，1MiB是单个块的最大大小。
每个块使用认证加密单独加密。这样做可以防止攻击服务器替换大文件中的块，并要求受害者在确定文件被泄露之前下载整个文件并解密。使用认证加密加密每个块可以确保客户端在处理下一个块之前知道它有一个有效的块。请注意，另一个授权客户端仍然可以通过对块进行认证加密来执行攻击，但服务器不能发起相同的攻击。

客户端：资源结构（L1）

存储加密数据的过程从客户端创建资源开始，其结构如下。
资源：

• id（必需）
• meta：meta.contentType MIME类型
• content——完整的有效负载，或者到各个块的类似清单的散列链接列表

如果数据小于块大小，则直接嵌入到内容中。
否则，客户端将数据分片成块（参见下一节），每个块都被加密并发送到服务器。在本例中，内容包含一个清单式的uri列表，用于各个块（完整性由[HASHLINK]保护）。

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

创建加密资源的过程。如果数据被分片成块，这是在各个块被写到服务器之后完成的。

• id
• index——由客户端准备的加密索引标签（用于对加密资源进行隐私保护查询）
• 块大小（如果与全局配置中的默认值不同）
• 版本化元数据——例如序列号、类似git的散列或其他机制
• 加密资源负载——编码为jwe [RFC7516]

第二层（L2）职责

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

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

要启用隐私保护查询（搜索索引对服务器不透明），客户端必须准备一个加密索引标签列表（与加密数据内容一起存储在加密资源中）。

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

服务器必须支持至少一种版本控制/更改控制机制。复制是由客户端完成的，而不是由服务器完成的（因为客户端控制密钥，知道要复制到哪些其他服务器，等等）。如果加密的数据仓库实现旨在提供复制功能，那么它还必须选择版本控制/更改控制策略（因为复制必然涉及冲突解决）。一些版本策略是隐式的（例如“最后一次写获胜”。Rsync或上传文件到文件托管服务），但请记住，复制策略总是意味着应该涉及某种冲突解决机制。

客户端：与其他实体共享

单个保管库对授权机制的选择决定了客户端如何与其他实体共享资源（授权能力链接或类似机制）。

第3层（L3）职责

服务器：通知（L3）

如果数据存储提供者能够在持久化数据发生更改时通知客户机，则会很有帮助。服务器可以选择性地实现一种机制，通过这种机制，客户机可以订阅vault中的更改。

客户端：全金库完整性保护（L3）

提供了全库完整性保护，以防止各种存储提供商攻击，其中数据以不可检测的方式修改，例如文档恢复到旧版本或删除。这种保护要求客户端存储属于用户的所有资源标识符的全局目录，以及最新版本。一些客户端可能会在本地存储此目录的副本（并包括完整性保护机制，如[HASHLINK]，以防止服务器的干扰或删除）。

以下部分概述了数据保管库的数据模型。

数据仓库配置指定特定数据仓库将具有的属性。

属性	描述
序列	数据保管库的唯一计数器，以确保客户端正确地同步到数据仓库。该值是必需的，必须是无符号的64位数字。
控制器	控制数据保管库的实体或密码密钥。该值是必需的，并且必须是URI。
调用者	根实体或密码密钥被授权调用授权功能，以修改数据仓库的配置或对其进行读写。该值是可选的，但如果存在，则必须是URI或URI数组。当此值不存在时，controller属性的值将用于相同的目的。
授权者	根实体或密码密钥被授权授权权限，以修改数据仓库的配置或对其进行读写。该值是可选的，但如果存在，则必须是URI或URI数组。当此值不存在时，controller属性的值将用于相同的目的。
referenceId	用于表示特定于应用程序的引用标识符。该值是可选的，如果存在，则必须是字符串。
keyAgreementKey.id	密钥协商密钥的标识符。该值是必需的，并且必须是URI。密钥协商密钥用于派生一个密钥，然后用于为接收方生成一个密钥加密密钥。
keyAgreementKey.type	密钥协商密钥类型。该值是必需的，必须是或映射到URI。
hmac.id	HMAC密钥的标识符。该值是必需的，必须是或映射到URI。
hmac.type	HMAC密钥类型。该值是必需的，必须是或映射到URI。

Example data vault configuration
{
  "id": "https://example.com/edvs/z4sRgBJJLnYy",
  "sequence": 0,
  "controller": "did:example:123456789",
  "referenceId": "my-primary-data-vault",
  "keyAgreementKey": {
    "id": "https://example.com/kms/12345",
    "type": "X25519KeyAgreementKey2019"
  },
  "hmac": {
    "id": "https://example.com/kms/67891",
    "type": "Sha256HmacKey2019"
  }
}

StructuredDocument

结构化文档用于存储应用程序数据以及关于应用程序数据的元数据。这些信息通常被加密，然后存储在数据仓库中。

属性	描述
id	结构化文档的标识符。该值是必需的，必须是一个base58编码的128位随机值。
meta	与结构化文档关联的键值元数据。
content	结构化文档的键值内容。

Example structured document
{
  "id": "urn:uuid:94684128-c42c-4b28-adb0-aec77bf76044",
  "meta": {
    "created": "2019-06-18"
  },
  "content": {
    "message": "Hello World!"
  }
}

流

流可以用来存储图像、视频、备份文件和任何其他任意长度的二进制数据。这是通过使用stream属性和进一步标识被存储的流类型的附加元数据来执行的。下表提供了除了StructuredDocument中指定的值之外还要存储的元数据。

属性	描述
meta.chunks	指定流中数据块的数量。
stream.id	流的标识符。流标识符必须是引用同一数据仓库上的流的URI。一旦流被写入数据仓库，就必须更新内容标识符，使其成为有效的散列链接。为了允许流加密，假定流摘要的值在写入流之前是不可知的。哈希链接必须作为已写入数据仓库的流的内容哈希存在。

Example structured document containing a stream
{
  "id": "urn:uuid:41289468-c42c-4b28-adb0-bf76044aec77",
  "meta": {
    "created": "2019-06-19",
    "contentType": "video/mpeg",
    "chunks": 16
  },
  "stream": {
    "id": "https://example.com/edvs/zMbxmSDn2Xzz?hl=zb47JhaKJ3hJ5Jkw8oan35jK23289Hp"
  }
}

EncryptedDocument

加密文档用于存储结构化文档，确保任何实体在未经数据控制器同意的情况下都不能读取信息。加密文档的大小（以包含加密文档的HTTP正文的大小衡量）不能超过10MiB。

属性	描述
id	加密文档的标识符。该值是必需的，必须是一个base58编码的128位随机值。
sequence	数据仓库的唯一计数器，以确保客户端正确地同步到数据仓库。该值是必需的，必须是无符号的64位数字。
jwe	一个JSON Web加密对象，如果被解码，将产生相应的StructuredDocument。

Example encrypted document
{
  "id":"z19x9iFMnfo4YLsShKAvnJk4L",
  "sequence":0,
  "indexed":[
    {
      "hmac":{
        "id":"did:ex:12345#key1",
        "type":"Sha256HmacKey2019"
      },
      "sequence":0,
      "attributes":[
      ]
    }
  ],
  "jwe":{
    "protected":"eyJlbmMiOiJDMjBQIn0",
    "recipients":[
      {
        "header":{
          "kid":"urn:123",
          "alg":"ECDH-ES+A256KW",
          "epk":{
            "kty":"OKP",
            "crv":"X25519",
            "x":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs"
          },
          "apu":"d7rIddZWblHmCc0mYZJw39SGteink_afiLraUb-qwgs",
          "apv":"dXJuOjEyMw"
        },
        "encrypted_key":"4PQsjDGs8IE3Yqgco***PTuVG25MKjojx4HSZqcjfkhr0qhwqkpUUw"
      }
    ],
    "iv":"FoJ5uPIR6HDPFCtD",
    "ciphertext":"tIupQ-9MeYLdkAc1Us0Mdlp1kZ5Dbavq0No-eJ91cF0R0hE",
    "tag":"TMRcEPc74knOIbXhLDJA_w"
  }
}

扩展点

加密的数据仓库支持许多扩展点：

• 协议/API——可以使用一个或多个协议（如库API、HTTPS、gRPC或蓝牙）访问系统。
• 加密策略——可以使用一种或多种加密策略，如AES-GCM或XSalsa20Poly1305加密数据。
• 授权策略——可以使用一个或多个授权策略（如OAuth2、HTTP签名或授权能力）来保护对加密数据的访问。
• 版本控制策略和复制策略——可以使用一个或多个版本控制和复制策略（如计数器、密码散列或CRDTs（无冲突的复制数据类型））来同步数据。
• 通知机制——可以使用一个或多个通知机制向客户机发出数据仓库中数据已更改的信号。

隐私方面的考虑

本节详细介绍将此规范部署到生产环境中的一般隐私注意事项和具体隐私影响。

安全注意事项

在处理该规范所描述的数据时，实现者应该注意许多安全方面的考虑。忽略或不理解本节的含义可能会导致安全漏洞。
虽然本节试图强调一组广泛的安全注意事项，但它不是一个完整的列表。在使用本规范中概述的技术实现任务关键系统时，敦促实现者寻求安全和密码学专业人员的建议。

恶意或意外修改数据

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

保管库被盗用

如果数据控制器（持有解密密钥和适当授权凭证的实体）意外地授予攻击者访问权限，加密的数据仓库可能会被泄露。例如，受害者可能无意中授权攻击者访问整个保险库或错误处理他们的加密密钥。一旦攻击者能够访问系统，他们就可以修改、删除或更改保险库的配置。

数据访问定时攻击

虽然服务器通常很难确定实体的身份以及该实体访问加密数据仓库的目的，但当实体访问仓库时，总是会泄露与访问模式、粗略文件大小和其他信息相关的元数据。该系统被设计成不会泄露它所产生的有关隐私限制的信息，这种方法可以防止许多（但不是所有）监视策略被服务器所使用，这些监视策略可能不是按照保险库用户隐私的最佳利益行事的。

公共网络上的加密数据

在保护个人数据时，假设所有加密方案最终都会被破解是一个安全的假设。由于这个原因，不建议服务器使用任何类型的公共存储网络来存储加密的数据作为存储策略。

服务器上未加密的数据

虽然这个系统在加密内容和元数据方面花费了很大的精力，但是为了确保服务器能够提供本规范中概述的特性，有一些字段无法加密。例如，与数据相关联的版本号可以洞察数据修改的频率。与加密内容相关联的标识符使服务器能够通过可能的跨文档关联标识符来获取知识。建议实现尽量减少以非加密方式存储的信息量。

加密索引上的部分匹配

系统所使用的加密索引在设计上充分考虑了隐私保护。因此，在加密索引不可用的搜索系统中，有许多常见的操作，例如对加密文本字段进行部分匹配或在标量范围内进行搜索。未来可能通过使用零知识加密方案来增加这些特性。

恶意服务提供商威胁模型

虽然大多数服务提供者都不是恶意的，但了解恶意服务提供者能做什么和不能做什么也很重要。如果有恶意服务提供商，可能会遭受以下攻击：

• 在保管库中访问信息的实体的相关性
• 根据文件大小和访问模式推测存储在保险库中的文件类型
• 加密数据的添加、删除和修改
• 未对加密数据强制设置授权策略
• 将加密数据泄露到未知的外部系统

可访问性的考虑

在处理本规范中描述的数据时，实现者应该了解许多可访问性注意事项。与任何web标准或协议实现一样，忽略可访问性问题会使这些信息对大部分人来说无法使用。遵循无障碍指南和标准（如[WCAG21]）以确保所有人（无论能力如何）都可以使用这些数据是很重要的。在使用密码学建立系统时，这一点尤其重要，因为密码学在历史上给辅助技术带来了问题。
本节详细介绍在使用此数据模型时需要考虑的一般可访问性考虑事项。