隐私注意事项
选择性披露与数据泄漏
选择性披露允许持有方根据特定目的最小化向验证方披露的信息。在设计支持选择性披露的整体系统时，必须注意尽量减少未计划向验证方披露的额外信息。这种泄漏可能通过系统的工件发生。这些工件可能来自系统的更高层（例如数据结构）或更低层的密码学原语。
例如，BBS签名方案是一种极其高效的方案，用于对多个消息生成签名，即发送给持有方的密码学签名的大小是固定的，与消息的数量无关。持有方随后可以选择性地向验证方披露这些消息中的任意部分，但作为加密方案的一部分，签发方签署的消息总数必须向验证方披露。如果需要避免此类信息泄漏，建议按照[[CFRG-BBS-SIGNATURE]]隐私注意事项部分的建议，将消息数量填充到一个通用长度。
在更高层次上，如何将数据映射到适合选择性披露的单个声明（即BBS消息）可能是数据泄漏的潜在来源。此加密套件能够通过使用JSON-LD处理将输入转换为RDF，消除许多可能泄漏信息的JSON数据结构工件（如嵌套、映射或数组位置等）。RDF可以被表达为规范化的、简单的主体-属性-值声明（在可验证凭证数据模型[[VC-DATA-MODEL-2.0]]中称为声明）。在以下内容中，我们将研究RDF规范化，这是一种将JSON-LD格式的可验证凭证映射为一组声明（BBS消息）的通用方案，用于选择性披露。我们将展示在执行此过程后，仍然存在可能的信息泄漏来源，并展示如何通过使用密钥伪随机函数（PRF）来缓解这种泄漏。
RDF规范化可用于将JSON-LD可验证凭证扁平化
为一组声明。该算法依赖于可验证凭证的内容，并使用密码学哈希函数帮助对声明进行排序。本质上，这一过程是将JSON对象（表示JSON-LD文档中声明的主体）分配一个id（如果未定义`@id`字段）。这些id被称为空白节点id。这些id用于将声明表达为简单的主体-属性-值声明，以便可以区分每个声明中的主体。id值根据[[RDF-CANON]]的规范化算法以及文档中的数据和密码学哈希函数（如SHA-256）的输出确定。
以下展示了两组稍有不同的风帆可验证凭证及其规范化为一组可用于选择性披露的声明。通过更改6.1尺寸风帆的年份，我们可以看到这两组凭证之间的声明排序发生了重大变化。如果持有方仅披露其较大尺寸的风帆（7.0和7.8）的信息，验证方可能会发现风帆集合发生了变化，即信息泄漏。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
{
"@vocab": "https://windsurf.grotto-networking.com/selective#"
}
],
"type": [
"VerifiableCredential"
],
"credentialSubject": {
"sails": [
{
"size": 5.5,
"sailName": "Kihei",
"year": 2023
},
{
"size": 6.1,
"sailName": "Lahaina",
"year": 2023 // 将更改此处以查看对规范化的影响
},
{
"size": 7.0,
"sailName": "Lahaina",
"year": 2020
},
{
"size": 7.8,
"sailName": "Lahaina",
"year": 2023
}
]
}
}
上述可验证凭证的规范化形式。空白节点id的分配（即_:c14nX
标签）依赖于可验证凭证的内容，这也会影响声明的排序。
_:c14n0 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n0 <https://windsurf.grotto-networking.com/selective#size> "7.8E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n0 <https://windsurf.grotto-networking.com/selective#year> "2023"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n1 <https://www.w3.org/2018/credentials#credentialSubject> _:c14n4 .
_:c14n2 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n2 <https://windsurf.grotto-networking.com/selective#size> "7"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n2 <https://windsurf.grotto-networking.com/selective#year> "2020"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n3 <https://windsurf.grotto-networking.com/selective#sailName> "Kihei" .
_:c14n3 <https://windsurf.grotto-networking.com/selective#size> "5.5E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n3 <https://windsurf.grotto-networking.com/selective#year> "2023"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n4 <https://windsurf.grotto-networking.com/selective#sails> _:c14n0 .
_:c14n4 <https://windsurf.grotto-networking.com/selective#sails> _:c14n2 .
_:c14n4 <https://windsurf.grotto-networking.com/selective#sails> _:c14n3 .
_:c14n4 <https://windsurf.grotto-networking.com/selective#sails> _:c14n5 .
_:c14n5 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n5 <https://windsurf.grotto-networking.com/selective#size> "6.1E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n5 <https://windsurf.grotto-networking.com/selective#year> "2023"^^<http://www.w3.org/2001/XMLSchema#integer> .
更新后的风帆集合，即6.1尺寸的风帆已更新为2024型号。这通过空白节点id的分配改变了声明的排序。
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
{
"@vocab": "https://windsurf.grotto-networking.com/selective#"
}
],
"type": [
"VerifiableCredential"
],
"credentialSubject": {
"sails": [
{
"size": 5.5,
"sailName": "Kihei",
"year": 2023
},
{
"size": 6.1,
"sailName": "Lahaina",
"year": 2024 // 新风帆以更新旧型号，改变了规范化
},
{
"size": 7.0,
"sailName": "Lahaina",
"year": 2020
},
{
"size": 7.8,
"sailName": "Lahaina",
"year": 2023
}
]
}
}
上述可验证凭证的规范化形式。注意空白节点id分配和声明排序的差异。
_:c14n0 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n0 <https://windsurf.grotto-networking.com/selective#size> "6.1E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n0 <https://windsurf.grotto-networking.com/selective#year> "2024"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n1 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n1 <https://windsurf.grotto-networking.com/selective#size> "7.8E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n1 <https://windsurf.grotto-networking.com/selective#year> "2023"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://www.w3.org/2018/credentials#VerifiableCredential> .
_:c14n2 <https://www.w3.org/2018/credentials#credentialSubject> _:c14n5 .
_:c14n3 <https://windsurf.grotto-networking.com/selective#sailName> "Lahaina" .
_:c14n3 <https://windsurf.grotto-networking.com/selective#size> "7"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n3 <https://windsurf.grotto-networking.com/selective#year> "2020"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n4 <https://windsurf.grotto-networking.com/selective#sailName> "Kihei" .
_:c14n4 <https://windsurf.grotto-networking.com/selective#size> "5.5E0"^^<http://www.w3.org/2001/XMLSchema#double> .
_:c14n4 <https://windsurf.grotto-networking.com/selective#year> "2023"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n0 .
_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n1 .
_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n3 .
_:c14n5 <https://windsurf.grotto-networking.com/selective#sails> _:c14n4 .
为了防止这些空白节点id的分配及其对声明排序的影响导致的信息泄漏，会对空白节点id运行基于HMAC的伪随机函数（PRF）。HMAC密钥仅在签发方和持有方之间共享，并且每个由签发方生成的基础证明都会使用一个新的HMAC密钥。可以在[[DI-ECDSA]]的规范化HMAC测试向量中看到此示例。
如下一节所述，为了使BBS保持不可链接性，我们不使用基于HMAC的空白节点id，而是基于HMAC生成打乱
版本的排序，如测试向量所示。请注意，与ECDSA-SD方法相比，这种方法在空白节点id方面提供的信息隐藏较少，因为空白节点id的数量可能会泄漏，但通过对空白节点id应用HMAC生成的本质上唯一的标识符，可以防止链接攻击。
选择性披露与不可链接性
在某些可验证凭证（VC）的使用场景中，为了保护持有方的隐私，防止多个不同验证方交互的跟踪或关联可能非常重要。特别是，我们考虑两种重要情况：(i) 验证方与签发方串通，以及 (ii) 验证方与验证方串通。在第一种情况下，如所示，验证方向凭证的原始签发方报告与持有方的交互。在这种情况下，签发方可以通过已签发的VC跟踪持有方与各种验证方的所有交互。在第二种情况下，如所示，多个验证方串通共享他们与持有方交互的信息。
我们使用术语不可链接性来描述VC系统防止此类“关联攻击”对持有方隐私的能力。尽管“不可链接性”这一术语相对较新，但[[NISTIR8053]]的第3.3节讨论并提供了一个关于通过关联攻击重新识别
的案例研究。关于数据隐私关联攻击
的知识系统化可以在[[Powar2023]]中找到。最广泛使用的用户隐私关联攻击发生在网络浏览器指纹识别的实践中，其调查可以在[[Pugliese2020]]中找到。
为了量化关联的概念，[[Powar2023]]引入了匿名集的概念。在我们关心的VC场景中，匿名集将包含特定VC的持有方以及与特定签发方相关的其他持有方。匿名集越小，持有方越可能被验证方跟踪。由于签名的VC包含对签发方公钥的引用，对于持有特定签发方VC的持有方来说，匿名集的初始大小是该签发方使用特定公/私钥对签发的VC数量。非恶意的签发方应尽量减少用于签发VC的公/私钥对的数量。请注意，匿名集的概念类似于[[vc-bitstring-status-list]]中的群体隐私概念。当我们在此使用“关联”一词时，通常是指任何导致匿名集大小减少的机制。
支持选择性披露的VC系统中的关联来源：
- 密码学原语的工件。
- 将VC映射为适合选择性披露的一组声明的工件。
- VC中证明选项和强制披露信息的工件。
- VC中选择性披露的信息。
- 基于外部VC系统的关联。
我们将在下文中讨论这些内容。
通过密码学工件的关联
密码学哈希、HMAC和数字签名本质上会生成高度唯一的标识符。诸如SHA-256之类的哈希函数的输出，由于其抗碰撞特性，保证在不同输入下本质上是唯一的，从而导致强关联，即将匿名集大小减少为1。同样，诸如Ed25519和确定性ECDSA之类的确定性签名算法会为不同输入生成本质上唯一的输出，并导致强关联。
这意味着持有方可以通过VC中的数字签名、HMAC或哈希工件轻松地在验证方之间被跟踪，因此容易受到验证方-验证方串通和验证方-签发方串通的攻击。某些形式的ECDSA等随机化签名算法可以允许签发方为相同输入生成许多不同的签名，并将这些签名发送给持有方以供不同的验证方使用。这种方法可以用来防止基于验证方-验证方串通的跟踪，但无法防止验证方-签发方串通。
要实现不可链接性，需要专门设计的密码学签名方案，允许持有方生成所谓的签名知识的零知识证明
（ZKPKS）。这意味着持有方可以在此类方案中从签发方获取签名，计算一个ZKPKS并将其发送给验证方。此ZKPKS无法链接回原始签名，但具有签名的所有理想属性，即验证方可以使用它来验证消息是否由签发方的公钥签名，以及消息是否未被篡改。此外，持有方可以为不同的验证方生成任意数量的ZKPKS，这些ZKPKS本质上是独立且不可链接的。BBS是一种支持此功能的签名方案。
尽管文档中称为BBS证明的ZKPKS具有保证的不可链接性属性，但BBS在与选择性披露一起使用时有两个工件可能导致关联。这些工件是最初签名的消息总数和披露声明的索引值。有关讨论和缓解技术，请参阅[[CFRG-BBS-SIGNATURE]]中的隐私注意事项。
如[[CFRG-BBS-SIGNATURE]]的签发方的公钥
部分所述，存在一种潜在威胁，即签发方可能使用多个公钥，其中一些用于通过验证方-签发方串通跟踪特定用户子集。由于签发方的公钥必须对验证方可见，即它在BBS证明（派生证明）中被引用，如果签发方有许多不同的公钥，特别是如果它对一小部分用户（持有方）使用这些公钥的子集，这可能被用作关联点。
通过VC处理的关联
我们在信息泄漏部分看到，RDF规范化使用哈希函数对声明进行排序，并基于HMAC对声明的顺序进行进一步的打乱
。这可能会留下指纹，从而允许某种程度的关联。关联的强度取决于VC中空白节点（本质上是JSON对象）的数量以及披露的索引数量。给定n个空白节点和k个披露的索引，在最坏情况下，这将导致匿名集大小减少一个因子C(n, k)，即从n个元素的集合中选择大小为k的组合数。通过减少VC中的空白节点数量，例如保持VC简短和简单，可以将此数字保持在较低水平。
通过JSON-LD节点标识符的关联
JSON-LD是一种基于JSON的格式，用于序列化关联数据。因此，它支持为文档中的每个对象（在JSON-LD术语中称为“节点”）分配一个全局唯一的`@id`属性（节点标识符）。这允许关联数据的链接
，从而使关于同一实体的信息可以被关联。这种关联可能是可取的，也可能是不可取的，具体取决于使用场景。
在使用BBS的不可链接性功能时，不能为个人或其个人身份信息使用全局唯一的节点标识符，因为它们提供的强关联是不可取的。请注意，当表达关于非个人信息的声明时（例如，使用全局唯一标识符来标识一个大国或一场音乐会活动），使用此类标识符是可以接受的。另外请注意，JSON-LD使用的`@context`，将术语映射到IRI，通常不会影响不可链接性。
通过证明选项和强制披露的关联
在[[vc-data-integrity]]规范中，给出了VC的`proof`属性的许多属性。需要注意的是，可选字段不应在验证方之间提供强关联。这些可选字段包括：id、created、expires、domain、challenge和nonce。例如，可选的created字段是一个`dateTimeStamp`对象，可以指定证明的创建日期，精确到任意的亚秒级粒度。如果存在此类信息，可能会大大减少匿名集的大小。如果签发方希望包含此类信息，则应尽可能使其粒度较粗，相对于一段时间内签发的VC数量。
签发方还可以通过在创建基础证明时使用的`mandatoryPointers`输入，强制持有方向验证方披露某些声明。请参阅、和部分。通过强制
，我们指的是生成的派生证明在未向验证方披露这些声明时将无法验证。应注意，如果要求披露此类信息，匿名集应保持足够大。
通过持有方选择性披露的关联
如[[Powar2023]]所述，有许多关于通过关联攻击重新识别个人的案例。因此，建议持有方尽可能少地披露信息，以帮助保持匿名集的大小。此外，已经多次证明，看似无害的信息可能具有高度的唯一性，从而导致重新识别或跟踪。请参阅[[NISTIR8053]]，了解关于马萨诸塞州前州长的一个特别著名案例的详细说明，以及[[Powar2023]]中对94个此类公开案例的进一步分析和分类。
通过外部VC系统的关联
需要指出的是，保持不可链接性（即匿名性）需要在持有和传输VC的系统中小心处理。网络工件（如IP地址（第3层）或以太网/MAC地址（第2层））是众所周知的关联来源。例如，如果移动电话的MAC地址在重新访问特定接入点时被使用，这可能会导致用户被跟踪，这促使移动电话制造商提供了MAC地址随机化功能。公共IP地址通常提供足够的信息，可以将个人定位到一个城市或国家内的区域，从而可能大大减少匿名集的大小。