The final text of the update to the eIDAS regulation (establishing a framework for a European Digital Identity) has been agreed upon. In a last minute effort to improve the text, we wrote an open letter criticising the proposal on weakening the security of the web, and providing too few safeguards protecting users of the proposed European Identity Wallet. Were we successful?
Looking at the text, it is clear this is a compromise (and an amendment to an existing regulation). In particular the structure is a mess, with new articles introducing the identity wallet running as far as four levels deep. This is a tough read. (Also, someone at the Commission needs to carefully cross-check all references because e.g. Article 45a-1.4 refers to Article 17(3)(c) that appears to no longer to exist.) I guess that’s life when regulating a hotly contested topic.
Let’s study the two topics we addressed in our open letter: web security, and wallet privacy.
We were concerned about the phrasing of Article 45, that lays down a requirement for browsers to recognise any certificate that satisfies some criteria specified in an annex to the regulation, without any other requirements to be imposed by the browsers. We were especially concerned that browsers were prevented from running additional security checks when such certificates were being used to authenticate a website, depending on how you would read Article 45a.
Why would this be a problem?
For a browser to ‘recognise’ a certificate means that the issuer of the certificate (the party that signs the contents of the certificate) is added to the trusted root list of a browser. When a browser visits a website, it asks the website to provide a valid certificate (i.e. one signed by any of the issuers in its trusted root list). The certificate contains the domain name of the website (which the browsers checks against the domain name in the link for the website it is visiting) and a public key for that domain. The issuer has verified that the public key indeed belongs to that website. And the browser verifies the signature on the certificate it just received to ensure correctness of this information. It then challenges the website to prove it knows the private key corresponding to the public key found in the certificate, while at the same time establishing a session key to encrypt the communication between the browser and the website.
This complex protocol proves authenticity of the website and
guarantees confidentiality of the communication between the browser
and the website, provided that all issuers in the trusted root
list refrain from issuing rogue certificates that link the wrong
public key to a website domain. If not, a malicious entity
(say a law enforcement agency in a member state) could mount a man-in-the-middle
attack pretending to be the actual website at domain
suspicious-forum.net by sending a rogue certificate for
that domain (that it forced one of the issuers in the member state to
sign), thus getting hold of the encryption key used to protect the
communication, and thus being able to eavesdrop on that communication.
This would break the end-to-end encryption guarantee for websites, and
would allow law enforcement to surreptitiously surveil visitors of
websites.
Security mechanisms currently implemented in browsers (like certificate transparency) would detect and prevent such an abuse - but browsers might not be allowed to act upon it depending on how you would read Article 45 and 45a.
Unfortunately, Article 45 itself has not changed since we published our letter. However, the following was added to Recital 32:
The obligation of recognition, interoperability and support of QWACs is not to affect the freedom of web-browser providers to ensure web security, domain authentication and the encryption of web traffic in the manner and with the technology they consider most appropriate.
This still means that browsers have to unilaterally recognise certificates that satisfy the requirement specified in the annex to the regulation, which could be much weaker than those typically imposed ex ante by browsers. In practice this means that issuers of such certificates have to be added to the trusted root list in the browser, creating a less secure PKI for the web.
But given the changes to recital 32 I am much less worried about the actual risk of breaking the end-to-end encryption for websites by e.g. law enforcement. In particular, with the text added to recital 32, I believe that Article 45a.2
By way of derogation to paragraph 1 and only in case of substantiated concerns related to breaches of security or loss of integrity of an identified certificate or set of certificates, web-browsers may take precautionary measures in relation to that certificate or set of certificates.
allows browsers to continue to use the security mechanism (like certificate transparency) to detect and prevent such attacks to end-to-end encryption, by refusing to accept such a rogue certificate.
Moreover, article 45a.3 requires the browser (vendor) to notify the competent supervisory authority in the member state and the Commission of such attacks taking place. Even though article 45a.4 puts the sole authority to investigate and decide on the final withdrawal of such a certificate on the competent authority (of the member state whose law enforcement agency in the example above initiated the wilful subversion of the end-to-end encryption of the web), I simply cannot believe that any competent authority could claim there is nothing wrong and that the certificate should be reinstated: they would be very clearly and publicly be caught red-handed in subverting global web security.
Regarding the identity wallet, we were concerned about the lack of privacy guarantees when using it to reveal certain non-identifying attributes (like age) to service providers. In particular, we were worried that users would not be sufficiently protected against service providers asking for more information than necessary for offering their service (i.e. over-authentication). Also, we were worried that the use of the wallet and the use of the attribute certificates contained in it could be ‘linkable’, i.e. that visits by a particular user to different websites could be linked (by the issuer or the websites).
It appears that our concerns have been addressed, somewhat.
Regarding the risk of over-authentication, I am quite happy to see that the registration process of relying parties has been strengthened.
Article 6a.4.(ba) requires that “the identity of relying parties can be validated by implementing authentication mechanisms in accordance with Article 6b”. Moreover, the attributes relying parties are allowed to request from wallet users must be specified upfront and be made “available online in electronically signed or sealed form suitable for automated processing” (Article 6b.1e). Wallets shall use this information to “implement the appropriate mechanism to inform that the requesting relying party or the requesting user of European Digital Identity Wallets have the permission to access [these attributes]” (Article 6a.4.(ca).
Together these provide some technically enforced mechanism to prevent ‘over-authentication’ by relying parties.
The situation regarding unlinkability is less clear. Article 6a.4.(a).(4e) says that
European Digital Identity Wallets shall, in particular support common protocols and interfaces for relying parties to verify the authenticity and validity of European Digital Identity Wallets
and Article 6a.5.5a says that
Member States shall provide means to revoke the validity of [a specific] European Digital Identity Wallet
Both requirements seem to imply that the validity of specific wallets can individually be checked by relying parties, which is hard (though not impossible, see below) to align with any unlinkability requirement.
Article 6a.7b.(a) on the other hand says that
The technical framework of the European Digital Identity Wallet shall not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows for tracking, linking, correlating or otherwise obtain knowledge of transactions or user behaviour unless explicitly authorised by the user.
The problem is that the most recent public version (i.e. version 1.0) of the Architecture Reference Framework (ARF) only allows the use of standardised ‘boring’ cryptographic primitives that do not allow the implementation of truly multi-show unlinkable attribute certificates (ABCs). As far as I understand, wallets work around this by requiring issuers to issue several one-time use certificates in one go. Users can use each of these only once and then throw them away. Clearly, this reveals the number of times you reveal a particular attribute to the issuer because you need to request new ones once your current stack in the wallet is empty. Also, issuers and relying parties can collude to track the use of such traditional certificates and link them back to you, which seems to contradict the language in 6a.7b.(a) “shall not allow…”.
Now this might all very well mean that the ARF needs to be updated to actually include cryptographic primitives that allow multi-show ABCs to be implemented. If that’s the case: hurray! To satisfy the requirement to verify the authenticity of wallets and to revoke specific wallets, so-called blacklistable credentials could be used. In any case, protocols to revoke ABCs in a privacy friendly fashion exist.
For my earlier commentary on the eIDAS proposal, see