零、从数字身份识别到数字钱包

EUDI介绍

根据《欧洲数字身份(EUDI)条例》(EU)910/2014, 欧盟成员国可自愿通知并承认国家电子身份证明 其成员国的计划。通知电子的识别 身份证明自2018年起成为强制要求。然而,没有要求 成员国应制定国家电子身份识别并制作 与其他成员国的系统互操作。这导致了差异 国家之间。

随后,欧盟条例2024/1183对该框架进行了修订,以解决这些不足,提升了该框架的有效性, 并将其利益延伸至私营部门。修订条例的制定 于2024年5月20日生效,每个成员国必须至少制作一个欧盟数字化版本 身份钱包将在2026年底前向公民和居民开放。 成员国将向公民和企业提供数字钱包,这些 能够连接其国家数字身份的各个方面。这些可能包括 由公共机构或私营部门提供,前提是他们被认可 成员国。

欧盟数字身份钱包将包括:

  • 向任何想使用的人开放:任何希望使用欧盟数字身份的欧盟公民、居民和企业均可使用。

  • 广泛使用:欧盟数字身份钱包将作为识别用户的方式,帮助他们访问欧盟范围内的公共和私人数字服务。

  • 用户控制:欧盟数字身份钱包将使人们能够选择并跟踪与第三方共享的身份、数据和证书。任何不需要分享的内容都不会被分享。

消费者也应能够在线访问服务,无需使用私人平台或不必要地分享个人数据。他们将完全掌控所分享的数据。

为什么要做 EUDI?

传统电子身份(eID)主要用于证明:

“我是谁”

但随着数字服务发展,用户越来越需要证明:

  • 年龄是否满足要求;

  • 学历是否真实;

  • 是否具有某种资格;

  • 是否拥有某项属性。

传统身份认证存在三个问题:

  1. 信息过度披露

用户证明一个简单属性时,往往需要提交完整身份信息。

例如:

1
2
3
4
5
6
7
8
9
证明年龄 ≥ 18 岁

传统方式:
提交身份证
→ 暴露姓名、身份证号、生日等信息

EUDI:
只证明 Age > 18
→ 不泄露额外信息
  1. 跨境和跨平台困难

欧洲各国已有不同电子身份系统,难以支持统一的数字服务生态。

  1. 用户缺少身份控制权

传统模式:

1
2
3
4
5
政府 / 平台

保存用户身份数据

用户请求使用

用户只是身份信息提供者。


eIDAS 1.0 的不足

eIDAS 1.0(2014)主要解决:

欧盟成员国电子身份互认问题。

模式:

1
2
3
4
5
国家 eID

跨境认证

公共服务

主要局限:

  • 主要面向政府公共服务;

  • 私营企业接入不足;

  • 身份证明粒度较粗;

  • 用户无法主动管理身份数据。


UDI 相比旧 eID 的核心变化

一、概念与目标

核心角色关系:

$\text{Issuer} \rightarrow \text{Wallet / Holder} \rightarrow \text{Verifier}$

1. 概念与定位

EUDI Wallet(European Digital Identity Wallet,欧洲数字身份钱包)是一套面向欧盟数字身份体系的身份基础设施。它不是数字货币钱包,而是用于安全持有、管理与出示数字身份凭证的钱包体系。

其目标是让用户在移动设备中持有由政府、学校、银行、可信服务提供商等主体签发的数字凭证,并在业务场景中只披露必要的身份信息。

缩写 名称 说明
PID Person Identification Data 个人身份数据,数字身份体系中的基础身份凭证
mDL Mobile Driving Licence 移动驾驶证,典型 mDoc 应用
EAA Electronic Attestation of Attributes 电子属性证明
QEAA Qualified Electronic Attestation of Attributes 合格电子属性证明
QES Qualified Electronic Signature 合格电子签名
RP Relying Party 请求并验证身份信息的服务方

EUDI 的可信身份可概括为:

$$
\begin{aligned}
\text{Trusted Identity}
&= \text{Trusted Issuer}

  • \text{Signed Credential}\
    &\quad + \text{Holder Control}
  • \text{Verifier Trust}
    \end{aligned}
    $$

2. 整体架构

EUDI Wallet 不是单一应用,而是由钱包、凭证签发方、验证方、信任基础设施、安全硬件与协议层共同构成的数字身份生态。

1
2
3
4
5
6
7
8
9
10
Trust Infrastructure


Issuer
│ Credential

EUDI Wallet
│ Presentation

Verifier
组件 职责
Wallet 保存凭证、管理密钥、处理签发与出示、执行用户授权
Issuer 核验主体身份并签发 PID、mDL、EAA 等数字凭证
Verifier / RP 请求特定属性并验证凭证、设备绑定及信任链
Trust Infrastructure 维护可信实体、证书、信任锚与列表
WSCA / WSCD 执行密码学操作并保护不可导出的私钥
Attestation 证明钱包实例、设备密钥与安全环境可信

基本身份模型为:

$\text{Issuer} \rightarrow \text{Holder} \rightarrow \text{Verifier}$

该模型的关键变化是:身份凭证签发后主要由用户持有,验证方通过密码学证明和信任链验证凭证,而不是把“每次认证都查询中心数据库”作为唯一信任来源。

3. Relying Party 信任与数据访问控制

EUDI 不仅要求服务端验证用户,也强调 Wallet 对 Relying Party 的识别与授权。核心原因是数字钱包中保存了高价值身份属性,恶意网站不应能够任意索取敏感字段。

1
2
3
4
5
6
7
8
9
10
Relying Party
├── identity / access certificate
├── registration information
└── declared attribute scope


Wallet

└── compare requested claims
with identity / policy / consent

$$
\begin{aligned}
\text{Privacy Control}
&= \text{Requester Authentication}

  • \text{Attribute Scope}\
    &\quad + \text{User Consent}
    \end{aligned}
    $$

4. 数字凭证模型

PID 与属性化身份

PID(Person Identification Data)将个人身份拆分为可验证属性,常见属性包括:

1
2
3
4
5
6
given_name
family_name
birth_date
nationality
age_over_18
...

这种“属性化身份”允许服务只请求当前业务所需的数据。例如年龄验证只需要:

1
age_over_18 = true

而不需要完整出生日期。数据最小化原则可以表示为:

$$
\text{Data Minimisation}
= \text{disclose only the claims required for the transaction}
$$

Selective Disclosure

Selective Disclosure(选择性披露)的目标是在一个包含多个身份属性的数字凭证中,只向验证方展示被请求的属性,其余属性保持隐藏。它是 EUDI 隐私模型的核心机制之一。

1
2
3
4
完整身份:姓名 + 出生日期 + 地址 + 证件号 + 照片

▼ 选择性披露
年龄验证:age_over_18 = true

Qualified Electronic Signature

EUDI 还与 QES(Qualified Electronic Signature)能力结合,用于合同、政务文件和其他高可信电子签名场景。其基本密码学过程仍是对文档摘要执行受保护的数字签名,但实际系统还要求用户认证、签名激活、合格证书与可信服务体系。

$$
h=H(document)
$$

$$
\sigma=\operatorname{Sign}_{sk}(h)
$$

1
2
3
4
5
6
7
8
9
10
11
12
13
Document


Hash


User Authentication


QSCD / Remote Signing


Signature

二、核心协议与密码学基础

1. 核心协议

EUDI 的远程数字凭证生命周期主要围绕 OpenID4VCI 与 OpenID4VP 展开:前者负责签发,后者负责出示。近场证件交互则大量依赖 ISO/IEC 18013-5。

阶段 协议或标准
Issuance OpenID4VCI
Presentation OpenID4VP
Proximity ISO/IEC 18013-5

OpenID4VCI:凭证签发

OpenID for Verifiable Credential Issuance 定义 Issuer 如何向 Wallet 安全签发可验证凭证。它通常与 OAuth 2.0、授权码、访问令牌、DPoP、JWT Proof、Key Attestation 等机制组合。

1
2
3
4
5
6
7
8
9
Wallet                                  Issuer
│ │
│◄──────── Credential Offer ─────────────│
│──────── Authorization Request ────────►│
│◄──────── Authorization Code ───────────│
│──────── Token Request + Proof ────────►│
│◄──────── Access Token ─────────────────│
│──────── Credential Request ───────────►│
│◄──────── Signed Credential ────────────│

最终结果是:Wallet 获得一个由可信 Issuer 签名、并可进一步绑定设备密钥的数字凭证。

DPoP:密钥持有证明

DPoP(Demonstrating Proof of Possession)用于降低 Bearer Token 被窃取后的重放风险。客户端不仅要持有 Access Token,还要证明自己拥有与会话绑定的私钥。

$$
(sk_D, pk_D) \leftarrow \operatorname{KeyGen}()
$$

$$
\begin{aligned}
\text{Authorization}
&\approx \text{Access Token}\
&\quad + \operatorname{ProofOfPossession}(sk_D)
\end{aligned}
$$

因此攻击者即使获得令牌,只要没有对应私钥,也不能简单复制令牌完成相同请求。

OpenID4VP:凭证出示

OpenID for Verifiable Presentations 定义 Verifier 如何提出身份属性请求,以及 Wallet 如何在用户授权后返回可验证的 Presentation。

1
2
3
4
5
6
7
8
Verifier                            Wallet
│ │
│────── Presentation Request ─────►│
│ │ User Consent
│◄──── Verifiable Presentation ────│
│ │
└─ Verify signature / nonce / audience /
trust / device binding

远程与近场 Presentation

模式 主要协议或标准 典型场景
Remote Presentation OpenID4VP 网站登录、银行、在线政务、远程年龄验证
Proximity Presentation ISO/IEC 18013-5 移动驾照检查、线下验证、门禁、酒店、执法

近场模式通常还涉及 QR、NFC、BLE 等通道以及 Session Transcript / Device Authentication 等绑定机制,重点是确保设备间会话和出示的数据属于同一次真实交互。

验证过程通常包括:

  • Issuer Signature:验证凭证确由目标签发方签发。

  • Nonce:防止旧 Presentation 被直接重放。

  • Audience / Client Binding:限制 Presentation 的目标验证方。

  • Expiration / Status:检查有效期与状态。

  • Device Binding:验证出示者确实持有凭证绑定密钥。

  • Trust Chain:判断 Issuer 是否属于可信实体。

2. 凭证格式

EUDI 体系中最重要的两类凭证表达是 mso_mdoc 与 SD-JWT VC。前者与 ISO mDoc 和移动证件生态结合紧密,后者适合 JSON、JWT 与 Web 身份协议环境。

格式 核心技术 典型特点
mso_mdoc CBOR / COSE / X.509 / ECDSA 结构紧凑,适合移动证件、近场与高可信身份场景
SD-JWT VC JWT / JWS / Hash-based Disclosure Web 生态友好,支持按 Claim 选择性披露

mDoc(特点:移动证件、线下、高可信)

mDoc 主要来源于 ISO/IEC 18013-5,典型应用是 mDL。它以 CBOR 表达数据,以 COSE 承载签名,并使用证书链建立签发方信任。

1
2
3
4
5
6
mDoc
├── issuerSigned
│ ├── data elements
│ ├── Mobile Security Object (MSO)
│ └── issuerAuth
└── deviceSigned / device authentication

Issuer 对 Mobile Security Object 签名:$\sigma_I = \operatorname{Sign}_{sk_I}(MSO)$

Verifier 使用 Issuer 公钥验证:$\operatorname{Verify}_{pk_I}(MSO, \sigma_I)=1$

MSO 还绑定数据元素的摘要,因此对姓名、年龄、证件属性等内容进行修改会破坏摘要或签名验证。

SD-JWT VC(Web 生态、在线身份)

SD-JWT(Selective Disclosure JWT)在 JWT 体系中引入选择性披露。其核心做法是对属性与随机盐计算摘要,由 Issuer 对摘要相关结构签名;Holder 只在需要时提供特定属性及其 Disclosure。

$$
d_i = H(salt_i \parallel claim_i)
$$

$$
\sigma_I

\operatorname{Sign}_{sk_I}(d_1,d_2,\ldots,d_n,metadata)
$$

当 Holder 披露某个属性时,Verifier 使用给出的 $salt_i$ 与 $claim_i$ 重新计算摘要,并检查该摘要是否属于 Issuer 签名保护的数据:

$$
H(salt_i \parallel claim_i) \stackrel{?}{=} d_i
$$

随机盐的作用之一是降低低熵属性被直接字典反推的风险。

3. 密码学主要技术

技术 在 EUDI 中的作用
ECDSA / 公钥签名 凭证签名、设备认证、协议 Proof
Hash 摘要、Claim Disclosure、文档签名、完整性绑定
X.509 / PKI Issuer、RP、信任锚与证书链验证
COSE / CBOR mDoc 的签名封装与紧凑二进制表达
JWT / JWS Web 协议、Proof、Credential / Presentation 相关对象
SD-JWT Claim 级选择性披露
ZKP Predicate 级隐私证明,如证明年龄条件而不公开生日
Attestation 证明软件实例、密钥和安全环境属性

三、安全与隐私保护机制

1. Selective Disclosure 与零知识证明

选择性披露只能决定“披露已有 Claim 还是隐藏已有 Claim”。如果需要证明关于私密数据的关系,而又不公开原始数据,则需要 Zero-Knowledge Proof(ZKP)。

例如凭证只包含 birth_date,希望证明年龄不少于 18 岁,同时不泄露具体生日。此时可将生日作为秘密 witness,把年龄条件作为公开 statement:

$$
w=\text{birth date},\qquad x=\text{policy / current date}
$$

$$
C(w,x)

[\operatorname{Age}(w,x)\ge 18]
\land
[\text{credential is valid}]
$$

$$
\pi \leftarrow \operatorname{Prove}(w,x),
\qquad
\operatorname{Verify}(\pi,x)=1
$$

EUDI 的技术规范已经专门覆盖 ZKP,并出现面向 mDoc 的 Longfellow / circuit-based 实现方向。其价值在于把“最小披露”从 Claim 级提升到 Predicate 级。

2. Device Binding

仅有 Issuer Signature 不能阻止凭证被完整复制。如果凭证文件可以被拷贝到另一台设备并直接使用,则“复制凭证”可能接近“复制身份”。Device Binding 用于把 Credential 与特定设备或钱包私钥绑定。

$$
(sk_D,pk_D)\leftarrow\operatorname{KeyGen}()
$$

$$
\text{Credential}\leftrightarrow pk_D
$$

Presentation 阶段,Wallet 必须通过签名或协议证明自己持有 $sk_D$。因此:

$$
\text{Credential Copy}
\neq
\text{Identity Copy},
\quad
\text{if } sk_D \text{ remains non-exportable}
$$

3. Attestation

WSCA 与 WSCD

EUDI 将钱包密码能力与安全密钥存储抽象为:

  • WSCA(Wallet Secure Cryptographic Application):钱包安全密码应用或接口。

  • WSCD(Wallet Secure Cryptographic Device):受保护的执行环境与密钥存储设备。

1
2
3
4
5
6
7
8
9
10
Wallet Application


WSCA - cryptographic application / interface


WSCD - protected execution / key storage


non-exportable private key

WSCD 可由 Secure Element、TPM、TEE、Android StrongBox、eSIM、Apple Secure Enclave 或 Remote HSM 等实现。核心要求是私钥不应以普通应用可读取的形式导出。

$$
\text{Security Goal: } sk_D
\text{ is usable for signing but not readable as raw key material}
$$

Wallet 与 Key Attestation

仅由 Wallet 自我声明“密钥位于安全硬件”没有安全意义,因此需要可验证的 Attestation。

机制 证明对象 目标
WIA Wallet Instance 证明当前钱包实例的身份、状态与可信属性
Key Attestation Device / Credential Key 证明某公钥对应私钥由特定可信环境生成和保护
Wallet Unit Attestation Wallet Unit 将钱包实例与密钥、安全环境的可信性组合表达

其安全思想与 Android Hardware-backed Key Attestation 类似:Issuer 不仅验证“你给了我一个公钥”,还希望验证“这个公钥对应的私钥是否真的存在于满足要求的安全边界内”。

4. PKI 与信任模型

EUDI 的身份安全最终依赖密码学验证与治理信任共同成立。数字签名只能证明“某个私钥签过这个数据”,不能自动证明“这个私钥属于合法政府或可信机构”。

1
2
3
4
5
6
7
8
9
10
Trust Anchor


Intermediate / Trusted Entity Infrastructure


Issuer Certificate


Credential Signature

$$
\text{Cryptographic Validity}
\neq \text{Identity Trust}
$$

$$
\begin{aligned}
\text{Trust}
&= \text{Signature Verification}

  • \text{Certificate Validation}\
    &\quad + \text{Trusted Entity Evaluation}
    \end{aligned}
    $$

因此 Verifier 需要检查证书链、信任锚、可信实体列表、Issuer 身份与凭证类型授权关系,而不能只执行一次 Verify(signature)

四、现有问题与研究需求

1. 应用场景

类别 示例 核心能力
身份认证 政务登录、银行开户、电信实名 Prove Identity
属性证明 年龄验证、资格验证 Prove Attribute
数字证件 mDL、数字身份证、学生证、职业证书 Digital Credential
电子签名 合同、政务文件、金融协议 Qualified Electronic Signature

2. 安全攻击面

从密码学与移动安全研究视角,EUDI 的风险并不只存在于密码算法本身,更大量分布在协议组合、证书验证、实现解析器、安全硬件接口和信任配置中。

攻击面 典型问题
Wallet Root / Hook、Key Extraction、Keystore Bypass、Attestation Bypass、恶意请求处理
Issuer OAuth 配置错误、身份核验绕过、错误 Claim 签发、Token / Proof 验证缺陷
Verifier RP 冒充、请求篡改、Replay、Callback 验证错误、证书链验证错误
Protocol Nonce 重用、Redirect URI 问题、JWT / JWK Confusion、Downgrade、Audience Binding 缺失
Credential Format CBOR / COSE 解析差异、SD-JWT Disclosure 混淆、Claim Substitution、Device Binding 错误
ZKP Integration Statement 绑定错误、电路语义错误、验证上下文缺失、Proof 与 Credential 未正确绑定

总结

协议层:

$$
\begin{aligned}
\text{Protocol}
&= \text{OpenID4VCI}

  • \text{OpenID4VP}\
    &\quad + \text{ISO/IEC 18013-5}
    \end{aligned}
    $$

密码学层:

$$
\begin{aligned}
\text{Crypto}
&= \text{ECDSA}

  • \text{Hash}
  • \text{PKI}
  • \text{X.509}\
    &\quad + \text{COSE}
  • \text{JWT}
  • \text{SD-JWT}
  • \text{ZKP}
    \end{aligned}
    $$

平台安全层:

$$
\begin{aligned}
\text{Platform Security}
&= \text{Device Binding}

  • \text{Secure Key Storage}
  • \text{Attestation}
    \end{aligned}
    $$

最终安全模型可概括为:

$$
\begin{aligned}
\text{Trusted Digital Identity}
&= \text{Trusted Issuer}

  • \text{Signed Credential}\
    &\quad + \text{Device-bound Key}
  • \text{Secure Hardware}\
    &\quad + \text{Authenticated Verifier}
  • \text{Selective Disclosure}
    \end{aligned}
    $$

参考资料