零知识证明学习笔记-EUDI 入门概念整理
零、从数字身份识别到数字钱包
EUDI介绍
根据《欧洲数字身份(EUDI)条例》(EU)910/2014, 欧盟成员国可自愿通知并承认国家电子身份证明 其成员国的计划。通知电子的识别 身份证明自2018年起成为强制要求。然而,没有要求 成员国应制定国家电子身份识别并制作 与其他成员国的系统互操作。这导致了差异 国家之间。
随后,欧盟条例2024/1183对该框架进行了修订,以解决这些不足,提升了该框架的有效性, 并将其利益延伸至私营部门。修订条例的制定 于2024年5月20日生效,每个成员国必须至少制作一个欧盟数字化版本 身份钱包将在2026年底前向公民和居民开放。 成员国将向公民和企业提供数字钱包,这些 能够连接其国家数字身份的各个方面。这些可能包括 由公共机构或私营部门提供,前提是他们被认可 成员国。
欧盟数字身份钱包将包括:
向任何想使用的人开放:任何希望使用欧盟数字身份的欧盟公民、居民和企业均可使用。
广泛使用:欧盟数字身份钱包将作为识别用户的方式,帮助他们访问欧盟范围内的公共和私人数字服务。
用户控制:欧盟数字身份钱包将使人们能够选择并跟踪与第三方共享的身份、数据和证书。任何不需要分享的内容都不会被分享。
消费者也应能够在线访问服务,无需使用私人平台或不必要地分享个人数据。他们将完全掌控所分享的数据。
为什么要做 EUDI?
传统电子身份(eID)主要用于证明:
“我是谁”
但随着数字服务发展,用户越来越需要证明:
年龄是否满足要求;
学历是否真实;
是否具有某种资格;
是否拥有某项属性。
传统身份认证存在三个问题:
- 信息过度披露
用户证明一个简单属性时,往往需要提交完整身份信息。
例如:
1 | 证明年龄 ≥ 18 岁 |
- 跨境和跨平台困难
欧洲各国已有不同电子身份系统,难以支持统一的数字服务生态。
- 用户缺少身份控制权
传统模式:
1 | 政府 / 平台 |
用户只是身份信息提供者。
eIDAS 1.0 的不足
eIDAS 1.0(2014)主要解决:
欧盟成员国电子身份互认问题。
模式:
1 | 国家 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 | Trust Infrastructure |
| 组件 | 职责 |
|---|---|
| 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 | Relying Party |
$$
\begin{aligned}
\text{Privacy Control}
&= \text{Requester Authentication}
- \text{Attribute Scope}\
&\quad + \text{User Consent}
\end{aligned}
$$
4. 数字凭证模型
PID 与属性化身份
PID(Person Identification Data)将个人身份拆分为可验证属性,常见属性包括:
1 | given_name |
这种“属性化身份”允许服务只请求当前业务所需的数据。例如年龄验证只需要:
1 | age_over_18 = true |
而不需要完整出生日期。数据最小化原则可以表示为:
$$
\text{Data Minimisation}
= \text{disclose only the claims required for the transaction}
$$
Selective Disclosure
Selective Disclosure(选择性披露)的目标是在一个包含多个身份属性的数字凭证中,只向验证方展示被请求的属性,其余属性保持隐藏。它是 EUDI 隐私模型的核心机制之一。
1 | 完整身份:姓名 + 出生日期 + 地址 + 证件号 + 照片 |
Qualified Electronic Signature
EUDI 还与 QES(Qualified Electronic Signature)能力结合,用于合同、政务文件和其他高可信电子签名场景。其基本密码学过程仍是对文档摘要执行受保护的数字签名,但实际系统还要求用户认证、签名激活、合格证书与可信服务体系。
$$
h=H(document)
$$
$$
\sigma=\operatorname{Sign}_{sk}(h)
$$
1 | Document |
二、核心协议与密码学基础
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 | Wallet Issuer |
最终结果是: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 | Verifier Wallet |
远程与近场 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 | mDoc |
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 | Wallet Application |
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 | Trust Anchor |
$$
\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}
$$