观点与分析

可治理加密基础上的移动数字身份系统如何构建?

本文提出一个用于评估符合 ISO/IEC 18013-5 的手机数字驾驶执照(mDL)系统的架构框架,重点关注信任边界、加密、离线运行和数据最小化。文章的核心观点是,购买 SDK 或验证服务并不会将架构责任从机构转移出去。

2026-10-16
2 分钟阅读
23 浏览量
certi.news Editorial Team
可治理加密基础上的移动数字身份系统如何构建?

将手机数字驾驶执照(mDL)集成起来的难点,不在于调用身份验证 API,而在于理解这一接口背后发生的事情:凭证存储在哪里,谁保护设备密钥,信任证书如何管理,以及在网络中断或服务提供商发生故障时,哪些功能仍能继续运行。本文发表于 InfoQ,介绍了一个按照 ISO/IEC 18013-5 构建的 mDL 系统架构构想,面向正在选择供应商、SDK、钱包平台或验证服务的机构。

区分身份核验与凭证签发

所提出的框架首先将身份生命周期中的两个不同阶段分开。在身份核验阶段,用户拍摄实体驾驶执照的照片并录制用于活体检测的视频,然后将证据和提取的数据发送至验证系统。主管机构(例如机动车管理部门)会在签发接受或拒绝决定之前,以自动或人工方式审查这些证据。

批准后进入配置阶段。设备在 Secure Enclave 或安全元件内部生成非对称密钥,并将公钥、证明证书和身份核验过程的引用发送给签发机构。签发机构将驾驶执照数据与密钥绑定在经过签名的 Mobile Security Object 中,然后加密凭证包并发送至钱包,以便将其存储在受硬件支持的存储区域中。

Advertisement

机构不一定要亲自执行这些步骤,但必须明确每一步由哪一方负责,以及哪一方拥有由此产生的信任决策权。

应当检查供应商接口背后的哪些内容?

文章认为,能够在试点中调用 verifyCredential() 或 requestPresentation() 等函数,并不足以评估供应商。评估应涵盖六个相互关联的方面:

  • 加密架构:密钥的生成与保护、设备证明、算法以及密钥生命周期。
  • 信任与公钥基础设施:信任锚、Document Signer 证书、信任列表和吊销列表。
  • 隐私与数据最小化:选择性披露、遥测、演示数据的保留,以及交易之间的关联风险。
  • 离线运行:缓存的材料、过时的吊销状态,以及网络中断期间的系统行为。
  • 互操作性:遵守 ISO/IEC 18013-5,以及与独立钱包和验证器进行交互的能力。
  • 运营韧性:供应商发生故障的影响、凭证的持续可用性,以及恢复和故障处理机制。

加密和证书并非实现细节

文章建议使用 RFC 9180 中规定的混合公钥加密(Hybrid Public Key Encryption),保护在线传输和 API 交换,并指定包括 DHKEM(P-256, HKDF-SHA256)、HKDF-SHA256 和 AES-128-GCM 在内的参数。但按照所提出的框架,加密不应被视为脱离信任模型的独立功能;必须了解加密从哪里开始、在哪里结束,谁生成并保护密钥,如何轮换密钥,以及哪些组件位于供应商的信任边界内。

钱包服务器、签发平台和验证系统之间的通信还需要通过 TLS 双向认证以及明确的证书架构来保护。文章介绍了不同的证书角色:从存储在离线硬件安全模块中的信任根,到短生命周期的 Document Signer 证书、mTLS 证书以及设备密钥证明证书。关键问题仍然是责任分配:哪些架构由供应商管理,哪些由机构控制,哪些信任关系仍由签发机构掌握。

服务中断时实际会发生什么变化?

该设计区分了验证过程中发生的同步操作,例如通过 NFC 交换数据或通过 API 直接验证;也区分了可以在后台执行的异步操作,例如身份核验审查、凭证配置、密钥轮换和信任列表同步。

这种划分使现有凭证能够在政策允许的情况下继续进行离线展示和验证,同时可以延后信任列表同步或吊销更新。文章建议测试无网络环境下的展示和验证、已过期凭证、过时的吊销列表、设备时钟偏差、连接恢复,以及供应商发生故障时的系统行为。即使供应商具有很高的可用性,只要每次验证都要求连接其后台服务,它仍可能成为单一故障点。

选择性披露与避免供应商锁定

不同场景所需的数据各不相同。机场检查点可能需要姓名、照片、出生日期、证件号码和签发机构,而商店可能只需一项逻辑声明,证明用户年龄超过 21 岁并提供照片,而不需要姓名、地址或证件号码。因此,不能只通过单一场景测试供应商;必须依据机构政策和实际交易类别对其进行衡量。

文章建议使业务逻辑独立于供应商架构,让应用表达诸如请求证明用户年龄超过 21 岁之类的政策,而不是在整个系统中发布供应商特有的数据结构。CBOR 序列、APDU 消息构建和加密库调用等细节可以被隐藏,但信任锚、签发机构身份、披露属性、证书和吊销状态、对供应商的依赖以及离线运行能力,都必须对机构保持可见。

certi.news 解读

文章强调的真正变化,是将 mDL 评估从 SDK 功能测试转变为对完整信任系统的审查。这种方法有助于安全、身份和采购团队确定哪些内容可以购买,以及哪些内容必须继续由机构治理:可以购买钱包实现、NFC 协议和加密库,但披露、授权和审计政策,以及密钥、证书、隐私、可用性和互操作性的治理,应当由机构建立。

不过,该框架本身并不能解决诸如当地合规要求,或签发机构与验证者之间治理模式等问题。即使能够保证签名有效,如果系统保留过多日志,或将展示操作与用户关联起来,也不能保证隐私。因此,在进入生产环境之前,追踪、保护隐私的吊销机制,以及供应商发生故障时的责任等问题,仍需要机构和监管层面的决策。

新闻来源
InfoQ - Architecture Articles
查看原始来源 ↗
c
作者

certi.news Editorial Team

你需要知道的

对手机数字驾驶证(mDL)的评估不应局限于测试 SDK 功能,还应涵盖信任模型、加密、密钥管理、隐私和离线运行能力。购买钱包或验证服务并不会将政策、证书、吊销和可用性的治理责任从机构转移出去。

  • 该框架基于 ISO/IEC 18013-5 标准,并将身份验证与数字凭证签发分开。
  • 设备密钥在 Secure Enclave 或安全元件中生成,签发机构在签名的 Mobile Security Object 中将驾驶证数据与密钥绑定。
  • 除保护密钥及其生命周期外,还应检查信任锚点、Document Signer 证书、信任列表和吊销列表。
  • 应测试离线验证、已过期凭证、过时的吊销列表、服务提供商中断以及连接恢复。
  • 选择性披露可减少所需数据;例如,只需证明已超过特定年龄,而无需披露姓名、地址或证件号码。
  • 机构政策、业务逻辑、隐私治理、审计和密钥管理应与服务提供商的具体实现保持独立。

常见问题

文章中的 mDL 系统设计基于哪项标准?

该设计基于 ISO/IEC 18013-5,即手机数字驾驶证相关标准。

verifyCredential() 等功能成功,是否足以评估 mDL 提供商?

不够。文章建议检查加密架构、信任与证书、隐私、离线运行、互操作性和运营韧性。

选择性披露有什么作用?

它允许每笔交易仅披露所需属性,例如证明年龄超过 21 岁,而无需披露姓名、地址或证件号码。

网络中断时应测试哪些内容?

应测试凭证的离线展示与验证、过时的吊销列表、已过期凭证、设备时钟偏差、连接恢复,以及提供商发生故障时系统的行为。

同一分类

你可能还喜欢

查看所有新闻