Member states of the European Union shall soon implement the updated regulation on electronic identity and introduce digital identity wallets (EUDIW). The accompanying Architecture and Reference Framework (ARF), still under development, has been criticized for the lack of unlinkability of credential presentations. The rather straightforward linkability follows from the properties of common public-key signature schemes. Anonymous credentials and zero-knowledge proofs have repeatedly been suggested as a more suitable, or even the only practical way to achieve unlinkability. I propose confidential computing as a simpler, more practical and more secure alternative.

What's in a credential?

Consider the following simple credential:

Name:       Alice
Birth Year: 1979
Public Key: Rk1niLwVVXpCJtRBnqSZApUyrnKbE0DewbykoBps224=
Signature:  LLzVAAjLn1L2FwiMpbycrhk0c2dMzIgCQ3URVfUQU+A=

In addition to attributes describing the holder, the credential includes a public key. In order to bind the credential to a particular person, a presentation typically involves a proof of possession of the corresponding private key. The last value is a signature over the remaining entries of the credential computed by the issuer.

Real-world credentials may contain several attributes. It is reasonable (and sometimes required by law) to only reveal a subset of attributes relevant to a particular interaction. For example, one may want to reveal the name and keep the age private. The ability to perform such selective disclosure is a necessary (but not sufficient) condition for any meaningful unlinkability.

Imagine Alice presents her credential twice. Can the verifier(s) link the two presentations? If on both occasions all the attributes are disclosed, the presentations are likely linkable independent of the protocols used.

The ARF includes SD-JWT and salted hashes, an elegant way to achieve selective disclosure without restricting the choice of signature schemes the issuer may use. It is a feature of SD-JWT that two presentations of the same credential are linkable.

A credential typically remains usable if the holder and the relying party agree that a particular attribute is not needed and may remain hidden during a presentation. The public key used for holder binding and the issuer's signature are always needed to verify the validity of the credential. To prevent linking of presentations, both would need to be hidden.

Zero-knowledge proofs

When verifying a digital signature s over a message m against issuer's public key, one usually plugs the three values in a specific formula. It is not necessary that this particular computation be performed by the relying party. In a typical anonymous credential system, the holder instead presents a (randomized) proof of signature knowledge without revealing either s or (all of) m. Note that m contains all the credential attributes as well as the public key used for holder binding. The algorithm the issuer uses to sign the credential and the scheme the relying party uses to verify holder binding are fundamentally linked to proof protocols and vice versa.

Consider for example BBS signatures, sometimes proposed as an alternative basis for EUDIW. The scheme is carefully designed to permit "standard" zero-knowledge proofs of relations between discrete logarithms.

Hiding values in secure enclaves

It matters to the relying party whether the credential signature verifies and whether the holder controls the private key used for binding. The precise values of m or s are not that relevant. In addition to the attributes the holder has agreed to disclose, the relying party is really only after a single bit of information expressing validity. Observe that this is precisely what zero-knowledge proofs within anonymous credential systems are designed to achieve.

It is easy to write a program that verifies the signature and the holder binding and only outputs information the relying party is allowed to see. If such verification were executed on trusted hardware operated by the relying party, unlinkability of presentations would be easy to achieve:

1. The wallet establishes a secure communication channel with the module.
2. The module authenticates itself towards the wallet.
3. The wallet presents the credential.
4. The module verifies the credential.
5. The module reports the verification result, the disclosed attributes and no other information to the relying party.

This is a thought experiment, I do not propose to force hardware security modules upon all relying parties. The goal of unlinkability can also be achieved on commodity CPUs thanks to confidential computing. Typical server CPUs by Intel support SGX (Software Guard Extensions). Secure enclaves can assume the role of modules mentioned above and integrate with other systems operated by relying parties.

Compatible hardware can provide the (remote) wallet with a cryptographic attestation that the enclave was initialized with the expected compliant executable code. The source code of credential verification enclaves can be kept simple and public.

Digital identity wallets will be subject to certification by national conformity assessment bodies. Such assessment can easily be extended to verification enclaves operated by relying parties.

Benefits

Secure enclaves can enable unlinkable presentations of all sorts of credentials, including those proposed by the ARF. It does not matter what algorithm the issuer uses to sign credentials or how exactly holder binding works. One would not even need salted hashes from SD-JWT. It would be possible to reveal all the attributes to the enclave to let it verify the signature and selectively disclose a subset of the attributes to the relying party "surrounding" the enclave.

The chip manufacturer decides which algorithms secure the enclave. At the moment, SGX attestation relies on ECDSA, but could in principle work with any signature scheme. The issuers, wallet providers and relying parties remain flexible to use whatever algorithms they consider appropriate for the rest of the system. One could build a credential system that depends on SGX for unlinkability, on ML-DSA for unforgeability, on ECDSA for holder binding and on RSA for revocation. Such freedom is rather useful, given the need to store keys in hardware. In contrast, "real" anonymous credential systems limit the choice of available building blocks. Everything has to be compatible with practical zero-knowledge proofs.

For simplicity, my example omits expiration and revocation. Such checks contribute to the single bit of information expressing credential validity and can too be performed within the secure enclave. Secure enclaves could also be used to implement all sorts of predicates, such as "born on a Tuesday" or "age not divisible by 7", should the need arise.

Enclaves provide an easy way to obtain pseudonyms. Simply derive one within the enclave from any piece of data uniquely identifying the holder.

Risks

Secure Guard Extensions have not performed quite as advertised. Several attacks have been reported over the years, sometimes extracting secrets that should never leave an enclave. What would happen if an attacker could somehow forge an attestation and replace the code the enclave executes? Because the enclave outputs information on validity, a rogue enclave could lie to the relying party about the validity of a credential. This is not a risk, the relying party runs the enclave. They are free to trust any credential they please without the need to attack SGX. In a similar manner, the relying party is free to modify any output from the enclave, for example replace Alice by Bob.

Secure enclaves provide unlinkability. A successful attack could allow the relying party to obtain "secrets" such as the value of the credential signature and thus link repeated presentations, possibly colluding with other relying parties. Holder binding, revocation or unforgeability of credentials do not depend on the security of SGX. The impact of any attack would be rather limited.

Any bug in the code of the enclave or in the CPU microcode is a risk. Impact on past presentations is limited, most secrets are long gone. Once a bug is fixed, unlinkability is restored for all future presentations without the need to reissue credentials.

Should we use it then?

While I do value privacy, I consider unlinkability overrated. Any interaction with a relying party comprises more than a credential presentation. Even if the latter were "unlinkable", the complete interaction need not be. There will be plenty of other data available to the relying party, data they are not allowed to abuse. Compliance cannot be achieved by technology alone. Given the limited benefits of unlinkability, I am comfortable with the ARF as it is now. I would very much prefer not having to use any credential whenever possible.

If unlinkability matters, use SGX enclaves instead of anonymous credentials based on zero-knowledge proofs. The latter might be theoretically appealing, but the limited benefits do not outweigh the security risks and the extra complexity.