Backend
Fooling Relying Parties of the EUDI Wallet Architecture: Credential Pooling Attacks and CRESTA, a Standard-Compliant Countermeasure
arXiv cs.CR0 views
arXiv:2610.41655v1 Announce Type: new Abstract: The European Digital Identity (EUDI) Wallet will let millions of EU citizens prove who they are and what they are entitled to, disclosing only what is needed. Many services need several credentials at once, such as an identity card and a university degree, so combined presentations are essential. We present credential pooling attacks on relying parties of the EUDI Wallet reference architecture. Colluding users, each holding some credentials in their own wallet, cooperate through a proxy that acts as a single synthetic user and presents all the requested credentials, although no single user holds them all. Every signature is genuine and computed by certified hardware, and nothing is extracted or forged. We ran the attack against the European Commission's reference implementation, also on two Android phones. The attack would fail if all credentials of a user carried the same public key, but colluding relying parties could then link all presentations of that user. For this reason, the Architecture and Reference Framework (ARF) requires a fresh key for each credential and recommends batches of single-use copies, each with its own key: precisely what makes pooling possible. One might think that preventing pooling requires giving up unlinkability or adopting non-standard cryptography, such as zero-knowledge proofs. We show that this is not the case: we present CRESTA (CREdential STApling), an efficient countermeasure that uses only standard cryptography and credential formats and preserves unlinkability. In CRESTA, an ordinary issuer checks at issuance that a set of keys was generated in the same secure hardware, and certifies it in a binding attestation: a standard credential whose attributes can be selectively disclosed. CRESTA works entirely within the EUDI Wallet framework and costs a relying party one additional signature verification per presentation.
Source:https://arxiv.org/abs/2610.41655Related posts
Day 12: Cross-Node Invalidation for Definition and Data Caches
0dev.to
How to Brief an AI Copywriter: Three Practical Prompt Templates
0dev.to
9 Out of 10 Lose: The Real Odds in Retail Trading, and the Only Edge That Matters
0dev.to
Why Swiss Infrastructure Matters for Privacy
0dev.to
Before You Pay Kinsta More, Make Sure Hosting Is the Problem
0dev.to
Claude Code Env Vars Don't Persist: 3 of 80 Runs Fell Back to Prod
0dev.to