Overview of Privacy and Unlinkability
We are working on a proposal for a privacy-preserving eID in Switzerland, and we’re looking at various techniques which can help us. In Taxonomy of digital identity systems we mapped the most common terms used in the e-ID space. In this post we give a short overview of the potential privacy and unlinkability failures in the Swiyu system. We give a summary of how to make the system more privacy-preserving and unlinkable, while also taking into account the governments desire to minimize fraud.
The Swiss Identity Wallet already uses various techniques to guarantee the privacy and unlinkability of the users. For the purpose of this blog post, we define the following terms: Privacy is modeled as minimisation of Personally Identifiable Information (PII) exchanged between the owner and the verifier. Unlinkability prevents tracking of two usages of the same e-ID wallet, even if there is no PII exchanged.
Data leakage and linkability
If we look at the technology overview on the Swiyu website, we can identify the interactions which can leak information:
The following list is a summary of which data is known to whom. The participants are as described in 3.1 of [Taxonomy of digital identity systems], with the exception of the holder, which is described as the owner here. Then we show the current mitigation, and other possible mitigations.
Exchanged Data
Following the arrows in the above figure, we identify the following data on which we want to concentrate. The IP address of the owner allows some limited tracking of their activities. In mobile networks, the IP address of a cellphone is often changing, or hidden behind the NAT of the network provider.
- Issue credentials - exchange between the owner and the issuer
- The signature generated by the issuer is unique
- The public key of the owner sent to the issuer is unique
- Set trust anchor (registration of verifier) and check credentials -
exchange between the issuer and the register
- When revoking a certificate, a unique identifier is sent to the register
- Show credentials - exchange between the owner and the verifier
- One or more attributes from the credential are sent from the owner to the verifier
- Other PII which can lead to linkability:
- The issuer signature of the credential
- The owner device public key
- Any other unique data of the credential
- The IP address of the owner
- Set trust anchor and check credentials - exchange between the verifier and the register
- A unique ID from the credential must be verified against the list of revocations
- Verification of verifier - exchange between the owner and the register
- The verifier’s ID to check plus the owner’s IP give a unique access pattern
Possible Abuses
Here is a list of who can abuse the data if they don’t follow the original protocol. We suppose that the government is running both the Issuer and the Register service.
| Attack | Threat Actor | Element | Abuse |
|---|---|---|---|
| 1 | Verifier | 3.1 | Requesting too much information about the owner |
| 2 | Verifier | 2.1 | Detection of revocation after presentation |
| 3 | Multiple Verifiers | 3.1 + 3.2 | Profile creation of owners |
| 4 | Government | 4.1 | Full tracking of credential presentations: storing credential ID request |
| 5 | Government | 5.1 | Full tracking of credential presentations: government stores requests and de-anonymizes IP addresses |
| 6 | Government colludes with Verifier | 1 + 3.2 | De-anonymization: Storing data of 1, and comparing it with the data seen by the verifier in 3.2 |
| 7 | Owner | 1 | Collude with a malicious entity and sell a presentation of the owner’s credential through a “proof proxy” |
Current and Proposed Mitigations
Based on the possible abuses, the following mitigations are already in place as of October 2025. Most of them have some kind of shortcomings, which could be overcome by using other mitigations.
| Attack | Current Mitigation | Shortcomings | Other Mitigations |
|---|---|---|---|
| 1 | Trust Register and warnings in app | Slow flagging of malicious verifiers | Mandatory Trust Register |
| 2 | None | No protection | ZKP |
| 3 | Batch issuance | Complex, Issuance load - IP address still visible | ZKP, BBS, Tor |
| 4 | Revocation Lists | Anonymity depends on size of list | ZKP, PIR |
| 5 | Full download of verifiers list | Lots of data, slow | PIR + Tor, CA sent by verifier |
| 6 | None | Laws can change and allow access to this data | ZKP, BBS + Zk-Attest, Blind signatures, Tor |
| 7 | Propose to de-anonymize presentations with Attack #6 | Loss of anonymity, loss of trust | Threshold-decryption, service-specific pseudonyms |
Detailed Proposed Mitigation
Except attack #1, all other attacks have technical solutions for a better protection of the data. Here is an overview of these solutions, and how they fit into the different attacks.
ZKP - Zero Knowledge Proof
A Zero Knowledge Proof (ZPK) is a mathematical construct which allows a Prover to convince a Verifier of a statement without disclosing more information than is given by the statement. Examples include age verification (65 or older, between 18 and 25) or address verification (lives in a given commune). There are several ongoing research subjects with respect to ZKPs, the most important ones are: reducing the time to create and check the proof, and reducing the size of the proof. You can find more details in our blog post Comparing ZK systems.
The following three ZKP systems are noteworthy with respect to e-IDs:
ZK-Attest
ℹ️ ZKAttest is a research paper written by Cloudflare researchers. Part of its results have been used by Ubique to create a proof-of-concept how to integrate it in an e-ID system: ZKAttest-RS.
✅ Mitigates the Attack 6 by blinding the signature from the issuer. Furthermore it hides the public key of the holder, so even if the issuer colludes with the verifier, there is not enough information left to de-anonymize the owner.
❌️ It relies on a new credential format called BBS, which is not used in any of the current e-ID proposals.
Google Longfellow-zk
ℹ️ The Longfellow-zk system from Google was the first system to create a ZKP on a credential in mDoc format. This is remarkable and allowed them to promote their solution for existing systems without requiring new hardware. Longfellow is based on quantum-safe ZKPs and contains a lot of optimizations to make it usable even on consumer devices. Due to the very reasonable speed and size requirements of the proof, it is good ready to be used in consumer devices.
✅ Mitigates Attack 3 and Attack 6. Furhter work is announced to mitigate Attack 2 and Attack 7.
❌️ The system proposed by Google is very optimized and opaque. Even though it is proposed as Open Source, it is difficult to understand, and not easy to extend by non-experts.
Microsoft Crescent
ℹ️ Also in 2025, Microsoft presented Crescent with very similar goals as Google Longfellow-zk. It is much more modular, and has examples how to create proofs for other credentials than mDoc.
✅ Mitigates Attack 3 and Attack 6, and with further work also Attack 2 and Attack 7.
❌️ The proof generation requires a one-time setup with very long running time and big size (GBytes). While the code is very modular, the public code is not maintained, and issues opened by the community haven’t been addressed by the authors. Another downside is that the chosen ZKP systems are not quantum-safe, but this is also the case for ECDSA used in current e-ID systems.
BBS Signatures
ℹ️ This proposition is very mature, given its age and first proposal in 2004 by Dan Boneh et al in Short Group Signatures. It is based on bilinear groups, and allows the owner to create a blinded presentation of their credential.
✅ Mitigates Attack 3 and Attack 6.
❌️ While there are a lot of experimental systems using BBS signatures, to our knowledge, there are no eID systems in production using BBS. Also, we couldn’t find any hardware security models (HSM) supporting generation of BBS signatures, which is another hurdle for adoption in high level assurance systems.
PIR - Private Information Retrieval
ℹ️ Private Information Retrieval allows a client to query a database without the server knowing which entry has been requested. Recent proposals like Spiral make it possible to read big databases like the English version of Wikipedia.
✅ Mitigates Attack 4 and Attack 5, with some modifications it can also mitigate Attack 2.
❌️ Currently there are no security-reviewed libraries available.
Tor - Private Internet Communication
ℹ️ The Tor Project is a stable and mature solution to bring more privacy to internet users. It does so by relaying the traffic from one client through a random set of servers, in a way that it’s very difficult to follow the trace.
✅ Mitigates Attack 3, Attack 5, and Attack 6 by hiding the client’s IP address.
❌️ Some parties have negative feelings towards Tor, as it is believed to be mostly used by criminals to cover their tracks. Another problem is the bandwidth needed for the clients, which can be solved with libraries like LightArti.
CA - Certificate Authorities
ℹ️ Certificate Authorities (CA) already build the basis for TLS encryption used in all https connections. For e-ID, the CA can be built with the root given by the government issuer. The government can then sign certificates from verifiers to prove their reliability.
✅ Mitigates Attack 5 if the verifier sends their signed credential to the owner.
❌️ Needs some changes in the trust registry to put the verifier information in their credential.
Blind Signatures
ℹ️ A Blind Signature can hide information to be signed. This allows an owner to send their public key for certification to the issuer, while the issuer only sees a temporary version of the public key.
✅ Mitigates Attack 6 by making it impossible for the issuer to match signatures and public keys to a specific owner.
❌️ No standards, needs new cryptographic algorithms for which no hardware security modules exist.
Threshold Decryption
ℹ️ The question of Privacy-Preserving lawful surveillance is a common discussion from politicians. Some suggest a backdoor (special government-only entry), which has been shown to weaken the system overall and open the door to other hackers, too. One solution is to use an encryption where multiple parties need to participate in the decryption. If consumer protection agencies are part of the system, they could flag if the government requests too many decryptions and then request some accountability from the governmemnt.
✅ Mitigates Attack 7, but at the expense of a potential surveillance tool.
❌️ Handling these decryption requests can be quite complex, and it will be difficult to choose the parties participating in granting the decryption.
Service-Specific Pseudonyms
ℹ️ The Austrian e-ID has a Bereichsspezifische Personenkennzeichen which is a pseudonym bound to an owner and a group of services, like financial or health. A more holder-centric overview of possible solutions is given in A Brief Note on Cryptographic Pseudonyms for Anonymous Credentials by René Mayrhofer, Anja Lehmann, and abhi shelat. It is possible to generate a unique, unchangeable pseudonym, which is tied to a single service. This means that for one owner / service pair, the pseudonym is always the same, but if the owner or the service changes, the pseudonym also changes.
✅ Mitigates Attack 7 by allowing the services to refuse creating more than one account, while keeping the identity of the owner hidden.
❌️ Doesn’t allow full anonymity anymore, as a service will know if the owner is a recurrent user or a new one.