【8】安全考虑

8. 安全考虑

本节为非规范性。

本节包含了一系列安全考虑，建议使用去中心化标识符（DID）的人在将此技术部署到生产环境之前进行考虑。DID旨在在许多IETF标准所使用的威胁模型下运行，且已在[RFC3552]中进行了文档记录。本节详细阐述了[RFC3552]中的多个考虑因素，以及一些DID架构特有的其他考虑因素。

8.1 选择DID解析器

DID规范注册表[DID-SPEC-REGISTRIES]包含了一份DID方法名称及其相应的DID方法规范的信息性列表。实施者需记住，没有中央权威机构规定特定的DID方法规范与任何特定的DID方法名称一起使用。如果对某个特定的DID解析器是否正确实现了DID方法有疑问，可以使用DID规范注册表查找注册的规范，以便做出明智的选择。

8.2 证明控制和绑定

在数字世界或物理世界中将实体绑定到DID、DID文档或加密材料时，需要使用本规范所考虑的安全协议。以下部分描述了一些可能的场景，以及其中的实体如何证明对DID或DID文档的控制，以用于身份验证或授权。

证明对DID和/或DID文档的控制

证明对DID和/或DID文档的控制在更新或与远程系统进行身份验证时非常有用。加密数字签名和可验证时间戳使与DID文档相关的某些安全协议在加密上可验证。为此，本规范在5.3.1 身份验证和5.3.4 能力调用中定义了有用的验证关系。与验证方法关联的秘密加密材料可用于在身份验证或授权安全协议中生成加密数字签名。

注：签名的DID文档

一些DID方法允许在DID文档或元数据结构中包含数字签名和其他证明。然而，这些证明本身并不一定能证明对DID的控制，或保证DID文档是该DID的正确文档。为了获取正确的DID文档并验证对DID的控制，有必要执行根据DID方法定义的DID解析过程。

绑定到物理身份

DID和DID文档本身不携带任何个人数据，强烈建议非公开实体不要在DID文档中发布个人数据。

以一种可以由可信任的权威（如政府）证明的方式，将DID绑定到个人或组织的物理身份可能是有用的。本规范提供了5.3.2 断言的验证关系以实现这一目的。此功能可以促进私密的互动，并在一个或多个管辖区下被视为具有法律约束力；建立这样的绑定必须谨慎平衡隐私考虑（见9. 隐私考虑）。

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

将DID绑定到物理世界中的某个事物（例如，通过使用与该DID具有相同主题的可验证凭证）的过程在本规范中得到了考虑，并在可验证凭证数据模型[VC-DATA-MODEL]中进一步定义。

8.3 身份验证服务端点

如果DID文档发布了一个服务，旨在验证或授权DID主题（见第5.4节服务），那么服务端点提供者、主题或请求方有责任遵循该服务端点支持的身份验证协议的要求。

8.4 不可否认性

DID和DID文档更新的不可否认性得到支持，如果：

可验证数据注册表支持可验证时间戳。有关可在DID解析过程中使用的有用时间戳的信息，请参见[DID-RESOLUTION]中的"DID文档元数据"。
主题正在监控未授权更新，正如在8.5节 DID文档更改通知中详细说明的那样。
主题有足够的机会根据DID方法的授权机制撤销恶意更新。

8.5 DID文档更改通知

对DID文档未授权更改的一种缓解措施是监控并主动通知DID主题有更改。这类似于通过向文件上的电子邮件地址发送密码重置通知，帮助防止传统用户名/密码帐户的账户接管。

在DID的情况下，没有中介注册机构或帐户提供商来生成此类通知。然而，如果注册DID的可验证数据注册表直接支持更改通知，则可以为DID控制者提供订阅服务。通知可以直接发送到现有DID中列出的相关服务端点。

如果DID控制者选择依赖于第三方监控服务（而非可验证数据注册表本身），这就引入了另一种攻击向量。

8.6 密钥和签名过期

在去中心化标识符架构中，可能没有中央机构来强制执行加密材料或加密数字签名过期政策。因此，依赖于支持软件（如DID解析器和验证库）来验证请求方在使用时加密材料是否未过期。请求方可能会在其验证过程中应用自己的过期政策。例如，一些请求方可能接受五分钟前的身份验证，而其他具有高精度时间源的请求方可能要求身份验证在过去的500毫秒内进行时间戳。

有些请求方合法地需要延长已过期加密材料的使用，例如验证遗留加密数字签名。在这些情况下，请求方可能会指示其验证软件忽略加密密钥材料的过期，或确定加密密钥材料在使用时是否过期。

8.7 验证方法轮换

轮换是一种管理过程，使现有验证方法关联的秘密加密材料可以在添加新验证方法到DID文档后停用或销毁。此后，任何控制者使用旧的秘密加密材料生成的新证明现在可以改为使用新的加密材料生成，并可以通过新的验证方法进行验证。

轮换是防止验证方法被妥协的有用机制，因为控制者频繁轮换验证方法可以减少单一被妥协验证方法对攻击者的价值。立即在轮换后进行撤销对于控制者指定的短期验证（如加密消息和身份验证）是有用的。

以下考虑可能在考虑使用验证方法轮换时有帮助：

验证方法轮换是一项主动安全措施。
通常建议定期进行验证方法轮换。
高安全环境往往会更频繁地进行验证方法轮换。
验证方法轮换只在当前或最新版本的DID文档中表现为变化。
当验证方法已使用较长时间，或执行了许多操作时，控制者可能希望执行轮换。
验证方法的频繁轮换可能会使被迫持续更新或刷新相关凭证的方感到沮丧。
依赖于未在最新版本的DID文档中存在的验证方法的证明或签名不受轮换的影响。在这些情况下，验证软件可能需要额外的信息，例如某个特定验证方法的有效时间，以及访问包含历史记录的可验证数据注册表，以确定证明或签名的有效性。并非所有DID方法都可能提供此选项。
DID方法操作

人员的能力、以及验证方法本身的复杂性（例如，是否需要具有自我主权能力），会影响轮换的复杂性。

8.8 验证方法撤销

撤销是一个管理过程，使与现有验证方法相关的秘密加密材料被停用，从而不再有效用于创建新的数字签名证明。

撤销是应对验证方法被攻破的有效机制。立即在轮换后执行撤销对控制者指定用于短期验证的验证方法特别有用，例如涉及加密消息和身份验证的验证方法。

与验证方法相关的秘密被攻破后，攻击者可以根据控制者在DID文档中表达的验证关系使用它们，例如用于身份验证。攻击者对这些秘密的使用可能与合法控制者的使用难以区分，从验证方法注册之时起，到撤销之时。

在考虑使用验证方法撤销时，以下几点可能有用：

验证方法撤销是一种反应性安全措施。
支持密钥撤销被视为最佳实践。
控制者应立即撤销已知被攻破的任何验证方法。
验证方法撤销只能体现在最新版本的DID文档的更改中；它无法追溯调整以前的版本。
如5.2.1 验证材料所述，缺少验证方法是适用于所有支持撤销的DID方法的唯一撤销形式。
如果验证方法不再仅限于控制者或被信任的代表控制者的各方访问，预计应立即撤销以降低冒充、盗窃和欺诈等风险。
撤销应被理解为控制者表示与撤销的验证方法相关的证明或签名在撤销后应视为无效。这也可能暗示存在担忧，即现有的证明或签名可能由攻击者创建，但这并不一定是事实。然而，验证者可能仍然选择自行决定接受或拒绝任何此类证明或签名。
关于DID方法操作的部分规定了DID操作，支持DID方法规范，包括更新和停用，可以用于从DID文档中删除验证方法。
不是所有的DID方法都支持验证方法撤销。
即使验证方法出现在DID文档中，额外信息，如公钥撤销证书或外部允许或拒绝列表，可能用于确定验证方法是否已被撤销。
依赖于被攻破的验证方法的任何软件的日常操作，例如个人的操作系统、杀毒软件或终端保护软件，可能会受到影响，当验证方法被公开撤销时。

撤销语义

尽管验证者可能选择不接受来自撤销的验证方法的证明或签名，但判断验证是否是通过撤销的验证方法进行的并不像看起来那么简单。一些DID方法提供回溯到DID在某一时间点的状态，或DID文档的特定版本的能力。当这样的特性与可靠的方法结合以确定在加密可验证声明做出时的时间或DID版本时，撤销并不撤销该声明。这可以作为使用DIDs进行约束承诺的基础；例如，签署抵押贷款。

如果满足这些条件，撤销不是追溯性的；它仅使该方法的未来使用失效。

然而，为了使这些语义安全，第二个条件——能够知道在断言做出时DID文档的状态——应适用。没有这一保证，某人可能会发现一个被撤销的密钥并使用它在过去的模拟日期做出加密可验证的声明。

一些DID方法仅允许检索DID的当前状态。当这种情况发生时，或者当在某个时间点无法可靠地确定DID在加密可验证声明时的状态时，唯一安全的做法是禁止任何考虑与时间相关的DID状态，除了现在这一时刻。DID生态系统采取这种方法，本质上将加密可验证的声明视为可以在任何时候被DID控制者作废的短暂令牌。

在无信任系统中的撤销

无信任系统是指所有信任源自于可加密证明的声明的系统，尤其是没有其他元数据被纳入到信任确定中。为了验证在无信任系统中已撤销的验证方法的签名证明，DID方法需要支持versionId或versionTime，以及DID文档元数据属性updated和nextUpdate。验证者只有在以下所有情况都为真时，才能验证已撤销密钥的签名或证明：

证明或签名包含在创建签名或证明时使用的DID文档的versionId或versionTime。
验证者能够确定签名或证明的制作时间点；例如，它是锚定在区块链上的。
对于解析的DID文档元数据，updated时间戳在签名或证明制作的时间点之前，nextUpdate时间戳在之后。

在愿意在没有此保证的情况下处理撤销的场

景中，可能会导致错误地接受或拒绝签名或证明。

8.9 DID恢复

恢复是一种反应性安全措施，使失去执行DID操作能力的控制者（例如因设备丢失）能够重新获得执行DID操作的能力。

在考虑使用DID恢复时，以下几点可能有用：

定期以不频繁的方式主动进行恢复，有助于确保未失去控制。
被视为最佳实践，切勿将与恢复相关的加密材料用于其他任何目的。
恢复通常与验证方法轮换和验证方法撤销同时进行。
当控制者或信任的服务无法独占执行DID操作时，建议进行恢复，如7.2 方法操作所述。
DID方法规范可能选择支持可信方的法定人数来促进恢复。有关如何实现的建议见5.1.2 DID控制器。
并非所有DID方法规范都会承认使用其他DID方法注册的DIDs的控制，并且可能将第三方控制限制为使用相同方法的DIDs。
DID方法规范中的访问控制和恢复也可以包括时间锁定功能，以防止通过保持恢复的控制第二轨道来保护密钥被攻破。
当前没有适用于所有DID方法的常见恢复机制。

8.10 人类友好标识符的角色

DID 实现全球唯一性而无需中央注册机构，但这会牺牲人类可记忆性。能够生成全球唯一标识符的算法生成的是没有人类意义的随机字符字符串。这种权衡通常被称为 Zooko’s Triangle。

在某些情况下，从人类友好标识符出发发现 DID 是可取的。例如，自然语言名称、域名或传统地址（如移动电话号码、电子邮件地址、社交媒体用户名或博客 URL）都可以作为 DID 控制者的标识符。然而，将人类友好标识符映射到 DID 的问题，以及以可验证和可信的方式进行映射的问题，超出了本规范的范围。

针对这一问题的解决方案在其他规范中定义，例如 [DNS-DID]，这些规范引用了本规范。强烈建议此类规范仔细考虑以下内容：

许多基于误导用户关于目标实体真实人类友好标识符的安全攻击。
使用人类友好标识符所带来的隐私后果，特别是在它们本质上是可关联的，尤其是如果它们是全球唯一的。

8.11 DIDs 作为增强的 URN

如果 DID 控制者希望，DID 或 DID URL 可以作为持久、位置独立的资源标识符。这类标识符被归类为统一资源名称（URN），并在 [RFC8141] 中定义。DID 是一种增强的 URN，提供加密安全的、位置独立的数字资源标识符，同时提供可用于检索的元数据。由于 DID 文档和 DID 之间的间接关系， DID 控制者可以在不调整 DID 的情况下调整资源的实际位置，甚至直接提供资源。此类 DID 可以确认证明所检索的资源确实是被识别的资源。

意图将 DID 用于此目的的 DID 控制者被建议遵循 [RFC8141] 中的安全考虑。特别是：

DID 控制者应选择一种满足其持久性要求的 DID 方法。去中心化特性评估表 [DID-RUBRIC] 是帮助实施者选择最合适的 DID 方法的工具之一。
DID 控制者应公开其操作政策，以便请求方可以确定他们在多大程度上可以依赖于该 DID 的持久性。在没有此类政策的情况下，请求方不应假设某个 DID 是同一 DID 主题的持久标识符。

8.12 不可变性

许多网络安全滥用行为利用现实与理性、善意参与者的假设之间的差距。DID 文档的不可变性可以提供一些安全利益。各个 DID 方法应考虑采取限制措施，以消除不必要的行为或语义。一个 DID 方法越是“锁定”，同时提供相同的功能，就越不容易被恶意参与者操控。

例如，考虑对 DID 文档的一次编辑可以改变文档中除根 id 属性外的任何内容。但是，服务在定义后是否真的希望更改其 type？或者密钥更改其值？或者在某些基本属性发生变化时，要求使用新的 id 是否更好？恶意接管网站的攻击往往旨在实现一个结果，即网站保持其主机名称标识符，但在内部却悄然发生变化。如果网站某些属性，例如与其 IP 地址相关联的 ASN 被要求遵循不可变性规范，那么异常检测将变得更容易，攻击将更加困难且代价更高。

对于与全球真实来源相关的 DID 方法，始终可以直接、即时地查找最新版本的 DID 文档。然而，似乎最终会有多层缓存位于 DID 解析器和真实来源之间。如果是这样，相信 DID 文档中某个对象的属性具有某种状态，而它们实际上微妙地不同，这可能会引发利用。这一点在某些查找完整 DID 文档的情况下尤为真实，而其他查找仅涉及部分数据，假设更大的上下文。

8.13 DID 文档中的加密数据

加密算法因加密学和计算能力的进步而可能失败。实施者应假设，放置在 DID 文档中的任何加密数据最终可能会向与加密数据相同的受众以明文形式提供。这在 DID 文档是公共的情况下尤其重要。

加密整个或部分 DID 文档不是保护数据的适当手段。同样，将加密数据放入 DID 文档也不是保护个人数据的适当方式。

考虑到上述警告，如果在 DID 文档中包含加密数据，建议实施者不要关联任何可以用来推断加密数据与相关方之间关系的可关联信息。可关联信息的例子包括接收方的公钥、已知在接收方控制下的数字资产的标识符或接收方的可读描述。

8.14 等价性属性

由于 equivalentId 和 canonicalId 属性是由 DID 方法本身生成的，因此适用于 DID 文档中 id 字段的相同安全性和准确性保证也适用于这些属性。alsoKnownAs 属性不保证是等价性陈述的准确表达，且不应在未进行超出 DID 文档解析的验证步骤的情况下依赖。

equivalentId 和 canonicalId 属性表达对同一 DID 变体的等价性声明，这些变体是由相同的 DID 方法生成的，可以被信任，前提是请求方信任 DID 方法和符合标准的生成者及解析者。

alsoKnownAs 属性允许对不受同一 DID 方法管辖的 URI 进行等价性声明，但在未进行超出治理 DID 方法的验证步骤之前，不能被信任。请参见 5.1.3 也称为的额外指导。

与 DID 文档中的任何其他安全相关属性一样，依赖于 DID 文档中任何等价性声明的各方应防范这些属性的值在进行适当验证后被攻击者替换。任何对存储在内存或磁盘上的 DID 文档的写入访问都是一种攻击向量，可能会绕过验证，除非对 DID 文档进行重新验证。

8.15 内容完整性保护

包含指向外部机器可读内容（如图像、网页或模式）的链接的 DID 文档易受篡改。强烈建议使用哈希链接 [HASHLINK] 等解决方案保护外部链接的完整性。如果外部链接无法得到完整性保护，而 DID 文档的完整性又依赖于该外部链接，则应避免使用外部链接。

一个外部链接的例子是 JSON-LD 上下文 [JSON-LD11]，其可能影响 DID 文档本身的完整性。为了防止被攻击，建议 DID 文档的使用者缓存 JSON-LD 上下文的本地静态副本和/或验证外部上下文的完整性，以确保与安全版本的外部 JSON-LD 上下文关联的密码学哈希相匹配。

8.16 持久性

DID 的设计目的是持久的，这样控制者不必依赖单一的受信任第三方或管理员来维护其标识符。在理想情况下，没有管理员可以从控制者手中夺走控制权，管理员也不能阻止其标识符用于任何特定目的，例如身份验证、授权和证明。任何第三方都无法代表控制者删除或使实体的标识符失效，除非得到控制者的同意。

然而，重要的是要注意，在所有启用密码学控制证明的 DID 方法中，证明控制权的手段始终可以通过转移秘密密码材料转移给另一方。因此，依赖于标识符持久性的系统需要定期检查，以确保该标识符实际上仍然在预定方的控制之下。

不幸的是，单凭密码学无法确定与给定验证方法关联的秘密密码材料是否被泄露。预期的控制者可能仍然能够访问秘密密码材料，因此可以在验证过程中执行控制证明，同时，一个恶意行为者也可能访问这些相同的密钥或其副本。

因此，密码学控制证明预期仅作为评估高风险场景所需身份保证级别的一个因素。基于 DID 的身份验证提供了比用户名和密码更大的保证，得益于能够在不在系统之间传输该秘密的情况下确定对密码秘密的控制。然而，这并不是万无一失的。涉及敏感、高价值或生命关键操作的场景预计将根据需要使用其他因素。

除了不同控制者使用可能带来的潜在歧义外，通常也无法保证在任何给定时刻某个特定 DID 正在被用于指代同一主题。从技术上讲，控制者可以将某个 DID 重新用于不同的主题，更微妙的是，主题的确切定义可能随时间变化或被误解。

例如，考虑一个用于个体经营的 DID，接收用于金融交易的各种凭证。对控制者来说，该标识符指代业务。随着业务的发展，最终以有限责任公司形式注册。控制者继续使用同一个 DID，因为对他们而言，该 DID 指的是该业务。然而，对国家、税务机关和地方政府而言，该 DID 不再指代同一实体。信贷提供商或供应商是否在意这种微妙的意义变化，必然取决于他们自己。在许多情况下，只要账单能按时支付，催款就能得到执行，这种变化就是无关紧要的。

由于这些潜在的歧义，DID 应被视为有效的 上下文性 而非绝对的。它们的持久性并不意味着它们指代确切相同的主题，也不意味着它们在同一控制者的控制之下。相反，人们需要理解 DID 创建时的上下文、它的使用方式，并考虑其含义的可能变化，同时采取程序和政策来应对潜在和不可避免的语义漂移。

8.17 保障级别

关于身份验证事件安全上下文的附加信息通常因合规原因而需要，尤其是在金融和公共部门等受监管领域。这些信息通常被称为保障级别（LOA）。示例包括对秘密密码材料的保护、身份验证过程以及身份验证器的形态。

支付服务（PSD 2）和 eIDAS 引入了对安全上下文的要求。保障级别框架由法规和标准（如 eIDAS、NIST 800-63-3 和 ISO/IEC 29115:2013）分类和定义，包括其对安全上下文的要求，并对如何实现这些要求提出建议。这可能包括强用户身份验证，其中 FIDO2/WebAuthn 可以满足该要求。

某些受监管的场景要求实施特定的保障级别。由于在这些情况下，诸如 assertionMethod 和 authentication 的验证关系可能会被使用，因此有关所应用安全上下文的信息可能需要向 验证者 表达和提供。在 DID 文档数据模型中是否以及如何编码这些信息超出了本规范的范围。有兴趣的读者可以注意到：1）该信息可以使用可验证凭证 [VC-DATA-MODEL] 进行传输，2）可以扩展 DID 文档数据模型以包含此信息，如 4.1 可扩展性中所述，并且 9. 隐私考虑适用于此类扩展。

8.18 评估竞争考虑