移动身份系统的密码学基础：ISO/IEC 18013-5 企业架构蓝图

本文面向企业架构师、安全架构师、身份工程师、平台负责人、技术评估人员，以及负责集成或选型移动驾驶证（mDL）能力的产品团队。对于通过第三方提供商、SDK、钱包平台或验证服务接入 mDL 的组织而言，本文尤其具有参考价值，因为这些组织需要了解集成边界背后隐藏着什么。

本文提供了一个框架，帮助企业在决定采用某家 mDL 提供商或某个库之前，提出正确的架构问题。文章将说明哪些组件可以安全地进行抽象，哪些信任边界必须对企业保持可见，需要验证哪些密码学属性和互操作性特征，以及在不同的实际应用场景中，相关要求会发生怎样的变化。

从实体凭证转向数字移动驾驶证，不仅仅是用户界面的变化。它还改变了身份信息的存储位置、身份声明的认证方式、设备建立可信关系的方式、依赖方请求信息的方式，以及在网络连接不可用时执行验证的方式。

企业不一定需要自行实现每一个组件。在许多情况下，采用专业提供商或库才是正确的工程决策。然而，将实现工作外包，并不意味着可以将架构责任一并外包。

提供商可能成功地提供了诸如 verifyCredential()、requestPresentation() 和 issueCredential() 等操作的 API，但企业仍然需要做出几项关键决策，包括：

如果提供商不可用，会发生什么？企业能否在不重新设计集成方案的情况下迁移到其他提供商？

第二种用途尤为重要。评估提供商时，不应仅仅看其 SDK 能否成功完成一次演示交易。企业还应评估 SDK 背后隐藏的信任模型、密码学边界、互操作性、隐私控制、运行行为和故障模式。

本文将移动身份视为一个企业架构与信任边界问题，而不只是一个 SDK 集成问题。首先，文章将身份核验与凭证配置分开，因为这两个阶段涉及不同的参与方、信任决策和安全责任。由此便引出了评估提供商时需要考虑的问题：哪些职责可以委托给 mDL 提供商，哪些信任决策必须继续对企业保持可见？随后，文章将介绍凭证结构和数据模型，说明实际配置和验证的内容究竟是什么。

接下来，文章将沿着凭证在一次验证交易中的流转过程展开。高层级的凭证出示流程将说明钱包、依赖方、签发方信任、设备认证以及请求的属性如何相互作用。后续章节将进一步探讨如何通过密码学、双向 TLS（mTLS）和证书基础设施保护这一交易。随后，文章会区分必须立即可用的操作与可以在后台执行的操作，并通过讨论离线运行和状态协调，分析提供商故障、网络故障和信任列表故障等问题。

最后几节将探讨这些原则在不同依赖方应用场景中的变化、治理和隐私策略如何限制实现方案的选择，以及企业如何避免过度依赖提供商，同时确保重要的架构决策始终清晰可见。文章还将通过架构审查以及 Build、Buy 和 Govern 决策模型，将这些观点整合起来，帮助企业判断哪些能力应由企业自行掌控，哪些能力可以委托给专业提供商。

本文的目标是将这些主题整合到一个统一的架构视图中：了解信任的对象是什么、披露了哪些信息、如何进行验证、连接或提供商发生故障时会怎样，以及企业如何继续对实现方案进行治理和调整。

本文的主要读者包括：正在决定如何将 mDL 能力融入现有身份、API、移动、安全和数据架构的企业架构师与解决方案架构师；评估密钥管理、设备信任、证书基础设施、密码学边界、认证和隐私控制的安全架构师；负责将移动凭证与身份验证、依赖方应用程序、数字钱包和企业身份平台集成的身份与 IAM 工程师；负责评估商业 mDL 提供商、SDK、验证平台、钱包技术或托管身份服务的技术与供应商评估团队；需要决定哪些内容应当在内部构建、哪些可以委托给提供商，以及哪些架构控制必须由企业掌握的工程负责人；以及负责设计面向客户的应用程序、需要在包括在线和离线场景在内的多种环境中执行身份验证的产品与平台团队。

这个 SDK 背后具备怎样的信任、安全、隐私、互操作性和运行架构？它是否满足我所在企业的要求？

身份核验和凭证配置是凭证生命周期中的两个不同阶段。身份核验用于确认用户确实拥有相关身份声明，而凭证配置则负责建立硬件信任、签发加密载荷，并在设备上安装移动安全对象（Mobile Security Object，mSO）。

采集身份凭据： 用户直接在应用程序中拍摄实体驾驶证的正面和背面照片，同时录制一段实时人脸视频，用于活体检测。

授权检查： 机动车管理部门（DMV）或权威身份系统根据官方记录，使用自动人脸识别技术评估相关证据，并在必要时通过人工审核流程进行复核。

生成硬件密钥： 收到批准状态后，钱包客户端会请求 Secure Enclave 或硬件安全元件生成非对称设备密钥。

提交配置载荷： 钱包将设备公钥、公开证书、身份核验参考 ID 和设备元数据打包，并将其发送给签发方后端。

凭证摘要计算与加密： 签发机构对驾驶证身份属性进行摘要计算，将这些属性与设备公钥绑定到经过签名的移动安全对象中，对凭证包进行加密，然后将其发送回钱包。

存储与呈现： 钱包使用会话传输密钥解密收到的载荷，将经过签名的 mSO 数据和密钥写入由硬件保护的存储空间，并使凭证可以显示给用户。

企业不一定需要自行实现这九个步骤。不过，企业应当明确每个步骤由哪一方执行，以及最终的信任决策由哪一方控制。

具体的职责归属模式可能有所不同，但企业应当能够清楚解释信任边界，而不是简单接受提供商默认的抽象方式。

互操作性： 对 ISO/IEC 18013-5 的合规性、不同钱包与验证方之间的互操作性、标准化数据结构，以及提供商可替换性。

ISO/IEC 18013-5 使用结构化、紧凑的数据表示来承载由签发方签名的身份声明。凭证包含由签发方签名的命名空间、元素标识符、摘要、签发方认证信息、设备密钥信息和有效期信息。

从架构角度来看，重要的是：企业接收的并不只是“身份数据”，而是经过密码学结构化处理的声明。这些声明的真实性和完整性取决于签发方签名、数值摘要、设备密钥以及周围的信任基础设施。

附录 B 提供了一个具有代表性的凭证结构，其中包括签发方签名数据、移动安全对象（mSO）、设备认证和凭证有效性之间的关系。

这一区别也会影响企业对 mDL 提供商或库的评估方式。不能仅仅因为集成方案能够解析或反序列化凭证载荷，就认定其符合要求。它还必须能够暴露并正确执行该载荷所代表的安全属性。

理解凭证结构只是第一步。企业还必须了解凭证如何在在线和离线环境中出示、受到保护、得到验证并接受治理。

接下来的章节将沿着验证生命周期，逐步梳理这些问题，从凭证出示和密码学保护，到信任基础设施、可用性、离线状态协调和企业策略。

凭证出示流程展示了在一次验证交易中，mDL 如何从用户的钱包传递给依赖方。验证方发起凭证出示请求，钱包建立适当的安全通信通道，用户授权披露所请求的信息，随后验证方对返回的凭证数据、签发方信任、设备认证以及适用策略进行验证。

这一流程为后续架构主题提供了运行层面的背景。接下来的章节将探讨支持这类交易的安全机制，包括密码学保护、证书与信任基础设施、同步与异步交互，以及离线运行和状态协调机制，并说明这些机制如何影响企业集成和提供商评估。

RFC 9180 定义的混合公钥加密（HPKE）用于保护在线传输，以及验证方与钱包服务器之间直接进行的 API 交互。HPKE 将非对称密钥封装机制与带有关联数据的对称认证加密结合起来，从而实现低延迟加密。

关键的架构要点是：加密应当被视为更广泛信任模型的一部分，而不是一个独立的安全功能。

提供商只是宣称自己采用了“加密通信”，还是能够解释清楚密码学边界、密钥生命周期、算法选择、密钥存储和端点认证？

钱包服务器、签发方平台和验证系统之间的服务器到服务器通信，需要采用双向 TLS 认证，并结合 PKI 验证。

提供商应当能够解释证书生命周期管理、证书轮换、信任锚管理、故障时的行为，以及发生证书泄露或失陷时各方承担的责任。

企业级 mDL 架构不会对所有操作采用同一种交互模式。有些操作必须在面向用户的验证交易中完成，而另一些操作则可以在后台执行，不会延迟凭证出示。因此，架构设计的目标不是在同步处理和异步处理之间二选一，而是明确哪些操作需要立即可用，哪些操作可以容忍延迟、使用缓存或通过最终同步完成。

当企业依赖外部 mDL 提供商时，这一区别尤为重要。如果提供商变得不可用，影响程度取决于哪些操作在运行时与该提供商紧密耦合。设计良好的架构应当允许现有凭证和离线验证在适用的信任与策略要求允许的情况下继续运行，同时允许签发、凭证配置、在线验证和信任列表同步等操作在必要时依赖后端服务的可用性。

现场扫描： 通过近场通信（NFC）传输。验证方读取器通过 NFC 发起轻触交互，建立会话密钥，请求特定的身份命名空间，并通过安全 NFC 通道直接接收签名载荷响应。

直接 API 验证： 在线交易直接查询钱包验证 API。验证方发送凭证出示请求，用户完成身份认证，数据在单个 HTTP 请求—响应周期内返回。

身份核验评估： 身份证据验证，包括人工审核或查询 DMV 记录，可以异步运行。结果可用后，客户端会收到回调通知或通过轮询获取更新。

密钥轮换与信任列表同步： 验证方可以通过后台同步获取更新后的信任材料和撤销信息，而不必要求每次凭证出示交易都完成这些更新。

这一分类的目的是识别运行时对提供商的依赖，以及故障边界。企业不应因为提供商具有很高的可用性，就假定每笔 mDL 交易都必须依赖该提供商在线可达。

即使提供商具有很高的可用性，如果每笔验证交易都要求其在线基础设施参与，它仍然可能成为架构上的单点故障。反过来，如果架构有意将面向用户的验证与后台同步分离，那么即使提供商或网络暂时发生故障，也能保留关键的验证能力。

离线验证方： 终端缓存文档签名者证书和证书撤销列表。扫描完全通过本地 NFC 完成。网络恢复后，数据会同步到中央云端日志。

设备有效期强制检查： mSO 载荷包含 validFrom 和 validUntil 时间戳。如果离线手机的安全时钟显示的时间已超过 validUntil，读取器就会拒绝该凭证。

尽管 mDL 验证具有共同的技术基础，但不同的依赖方在保证级别、请求属性、运行限制和隐私预期方面存在差异。以下示例说明了这些区别：机场需要进行全面的身份验证，而零售场景中的年龄验证则应尽量减少信息披露。

请求的属性： 名字、姓氏、照片、出生日期、证件号码、签发机构，以及是否符合 Real ID 要求的标志。

运行集成： TSA 读取器提取相关属性，根据联邦信任列表验证文档签名者证书，并执行生物特征人脸匹配。

终端验证密码学签名，核实所需声明，在适当情况下显示肖像，并输出年龄验证通过的状态。

反过来，针对简单年龄验证优化的提供商，可能无法提供高保证级别身份验证所需的控制能力。

治理、隐私、安全和互操作性要求会影响 mDL 系统请求哪些属性、保留哪些信息、如何管理密码学材料，以及如何执行标准。以下策略将这些要求转化为适用于企业应用和第三方提供商的控制措施。

数据最小化要求： 验证方软件只能请求交易所必需的元素。除非适用法规规定了例外情况，否则商业验证方不得存储个人身份信息（PII）。

零追踪保证： 签发机构不得构建能够追踪用户何时或何地出示凭证的配置系统或状态系统。

密码学规范： 文档签名者密钥必须每隔 30 至 90 天轮换一次。系统必须使用 SHA-256 或 SHA-384 密码学原语。

硬件密钥绑定强制要求： 应用必须在安全硬件中配置密钥，并要求用户通过生物特征或 PIN 码进行身份认证。

互操作性合规： 所有钱包软件和验证方都必须通过 ISO/IEC 18013-5 标准合规性认证。

RequestAgeOver21()

复制代码

而不是在整个应用程序中嵌入特定提供商的凭证结构。

同样，验证结果应当被规范化为企业策略决策，而不是让特定提供商的专有响应贯穿整个应用程序。

在投入生产环境之前，企业必须验证 mDL 集成的信任边界、隐私、安全、韧性和互操作性，而不能仅仅确认验证是否成功。以下五个问题提供了一个实用框架，可用于审查这些责任并评估对提供商的依赖。

确定企业能否在不重写应用程序业务逻辑、不改变身份策略模型的情况下，替换 SDK 或提供商。

这一模型可以避免两个极端。第一个极端是试图在内部构建所有组件。第二个极端是将整个身份系统视为一个不透明的第三方服务。更合适的企业做法是：

如果移动身份验证逐渐转向密码学绑定、保护隐私且支持离线运行的模式，签发机构和商业依赖方应如何协调严格的监管审计要求与现代隐私法律？后者通常不鼓励不必要地保留敏感个人信息。

签发机构、提供商和依赖方应如何在不引入新的追踪机制、避免记录用户在何时何地出示移动身份的前提下，实现保护隐私的撤销与状态检查？

一个在技术上有效的身份系统，仍然可能因为遥测、集中式状态查询、过度保留数据或设计不当的提供商集成而产生隐私风险。

从实体卡片演进到符合 ISO/IEC 18013-5 标准的移动驾驶证，代表着企业信任模型的一次根本性转变。

提供商或 SDK 可以合理地抽象掉 CBOR 编码、NFC APDU 处理、密码学库调用、安全存储 API 以及其他实现细节。但企业仍然需要了解：谁控制签发方信任，设备密钥如何受到保护，选择性披露如何执行，撤销机制如何运作，离线时会发生什么，系统会收集哪些信息，以及提供商不可用时系统会如何运行。

高速 NFC 凭证出示、硬件保护的设备密钥、密码学签名、HPKE、PKI、选择性披露和离线验证，并不是彼此孤立的技术功能，而是企业信任模型中相互关联的组成部分。

真正出色的架构，是企业能够清楚回答以下问题的架构：我们信任谁？我们披露什么？我们如何验证？离线时会发生什么？提供商发生故障时会怎样？我们能否在不改变信任模型的情况下更换实现方案？

通过将 mDL 集成视为架构与治理问题，而不只是 SDK 集成问题，企业就可以在采用供应商能力的同时，继续掌控安全、隐私、互操作性和长期技术战略。

JSON{ "docType": "org.iso.18013.5.mDL", "issuerSigned": { "nameSpaces": { "org.iso.18013.5.1": [ { "digestID": 0, "random": "4F9A01B2C", "elementIdentifier": "family_name", "elementValue": "Smith" }, { "digestID": 1, "random": "8E12C3D4A", "elementIdentifier": "given_name", "elementValue": "Jane" }, { "digestID": 2, "random": "1F3A89C0D", "elementIdentifier": "birth_date", "elementValue": "1990-05-15" }, { "digestID": 3, "random": "7C6B54A21", "elementIdentifier": "issue_date", "elementValue": "2024-01-10" }, { "digestID": 4, "random": "9A8B7C6D5", "elementIdentifier": "expiry_date", "elementValue": "2029-05-15" }, { "digestID": 5, "random": "3E2D1C0B9", "elementIdentifier": "issuing_authority", "elementValue": "CA-DMV" }, { "digestID": 6, "random": "6F5E4D3C2", "elementIdentifier": "document_number", "elementValue": "D1234567" }, { "digestID": 7, "random": "0A1B2C3D4", "elementIdentifier": "portrait", "elementValue": "<JPEG_2000_BYTE_ARRAY>" }, { "digestID": 8, "random": "5E4D3C2B1", "elementIdentifier": "age_over_21", "elementValue": true } ] }, "issuerAuth": { "algorithm": "ES256", "signature": "<ISSUER_DIGITAL_SIGNATURE_BYTES>", "mSO": { "version": "1.0", "digestAlgorithm": "SHA-256", "valueDigests": { "org.iso.18013.5.1": { "0": "<SHA256_HASH_OF_ELEMENT_0>", "1": "<SHA256_HASH_OF_ELEMENT_1>", "2": "<SHA256_HASH_OF_ELEMENT_2>", "8": "<SHA256_HASH_OF_ELEMENT_8>" } }, "deviceKeyInfo": { "deviceKey": "<DEVICE_PUBLIC_KEY_COSE_KEY>" }, "validityInfo": { "signed": "2024-01-10T00:00:00Z", "validFrom": "2024-01-10T00:00:00Z", "validUntil": "2029-05-15T23:59:59Z" } } } }, "deviceSigned": { "nameSpaces": {}, "deviceAuth": { "signature": "<DEVICE_PRIVATE_KEY_SIGNATURE>" } }}

复制代码