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

作者：Praveen Kumar Gopalakrishnan

移动驾驶证（mDL）集成表面简化，实则涉及存储、认证、设备信任、离线验证等多重架构变更。本文提出评估框架，聚焦抽象边界、密码学属性与互操作性要求的可验证性。强调外包实现不等于卸载架构责任。

需明确mDL集成中不可隐藏的信任边界；须验证密码学原语（如签名、零知识证明）是否满足合规要求；不同场景（在线/离线、B2C/B2B）对互操作性要求差异显著。

适合企业架构师、安全架构师、身份工程师、平台负责人、技术评估人员阅读。

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

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

引言：移动身份集成很容易被隐藏，架构设计却没那么简单

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

集成 mDL 的企业可能会发现，开发者体验看起来相当简单：

从应用程序的角度来看，这可能只是几个 API，但底层架构要复杂得多：

这种抽象很有用，但也带来了风险。

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

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

凭证存储在哪里？设备密钥如何受到保护？

谁负责管理签发方信任锚？证书如何验证和轮换？

如何处理凭证有效性和撤销问题，尤其是在验证方处于离线状态时？

哪些身份属性会被披露？企业能否强制执行数据最小化策略？

提供商会收集哪些遥测数据？凭证出示事件是否可能与具体用户关联起来？

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

即使相应功能由其他方实现，这些问题仍然属于架构层面的要求。

因此，本文介绍的架构可以有两种用途：

作为实现蓝图，供负责构建 mDL 生态系统部分组件的组织使用。

作为评估框架，供需要选择 mDL 提供商、SDK、钱包平台或验证库的组织使用。

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

本文如何分析 mDL 架构

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

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

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

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

谁应该阅读本文？

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

对于上述所有读者而言，核心问题并不是：

这个 SDK 能验证 mDL 吗？

更重要的问题是：

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

身份核验与凭证配置架构

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

阶段 1：身份核验

身份核验主要包括四个步骤：

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

提交载荷： 将采集的图像、提取的元数据和活体检测视频提交给验证系统。

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

核验决策： 验证引擎返回明确的状态响应：批准或拒绝。

阶段 2：身份凭证配置

身份凭证配置通过四个步骤完成：

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

组装证明材料包： 客户端提取生成的设备公钥以及硬件证明 X.509 证书。

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

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

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

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

因此，在评估提供商时，应建立一份职责分配图，明确每项必要功能由谁提供。例如：

架构功能

企业

提供商

签发方 / DMV

共享 / 外部

身份核验

设备密钥生成

✓ / SDK

设备证明

凭证签发

文档签名

钱包存储

✓ / 设备

凭证出示

✓ / 应用

✓ / SDK

验证

✓ / 依赖方

✓ / 服务

信任管理

撤销 / 状态管理

审计与遥测

'}}">

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

企业应该向 mDL 提供商提出哪些问题

黑盒式集成可以是合理的实现方式，但对于架构尽职调查而言，这还远远不够。

企业在评估 mDL 提供商时，应确保对方能够清楚解释以下六个方面：

密码学架构： 密钥生成与保护、设备证明、算法、签名和密钥生命周期。

信任与 PKI： 信任锚、文档签名者证书、信任列表、撤销机制和证书生命周期。

隐私与数据最小化： 选择性披露、遥测、凭证出示数据的保留、位置信息以及关联风险。

离线运行： 缓存的信任材料、撤销 / 状态同步、过期信息，以及网络中断时的行为。

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

运行韧性： 对提供商的依赖、服务中断时的行为、凭证连续性、恢复机制和故障处理。

目标并不是消除抽象，而是确保抽象能够隐藏实现复杂性，却不会掩盖架构风险。

详细的提供商尽职调查清单见附录 A。

凭证结构与数据模型

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

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

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

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

因此，企业应当确认实现方案是否能够：

正确验证签发方签名；

验证移动安全对象；

验证设备认证；

验证证书链；

支持选择性披露；

保护敏感凭证材料；

向应用程序提供充分的验证结果；

保持基于标准的互操作性。

从凭证结构到企业级验证

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

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

用户凭证出示的高级流程

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

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

安全与密码学：集成 HPKE

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

HPKE 参数

KEM：DHKEM(P-256, HKDF-SHA256)（ID：0x0010）

KDF：HKDF-SHA256（ID：0x0001）

AEAD：AES-128-GCM（ID：0x0001）

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

评估 mDL 提供商时，可以询问：

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

提供商应当能够说明：

加密从哪里开始；

加密在哪里终止；

哪些密钥由设备生成；