A « QWAC » in the eiDAS directive revision

New eiDAS revision introduces changes « dramatically weakening web security » stated 35 cyber security experts from industry (1). It seems paradoxical from the European Parliament to introduce such concern in a framework aiming to strengthen the security.

Context

In June 2021 the European commission published a revision proposal of the European Digital Identity framework (2). The former version issued on 2014 has proof unable to reach the objective of unified framework across European countries.

This revision aims to ensure the 2030 target where 80% of European citizen could benefit from a digital identity within a digital wallet offering various services such as digital signature, strong authentication and service appliance. It is then necessary to foster the technical deployment and to ensure the solution interoperability.

The members shall apply the revised version, eiDAS 2.0, in 2023 (3). The pilot phase should end in 2025 with a global evaluation. Many European countries such as France (4) started the integration of the eiDAS 2.0 regulation within their national law.

A web security pillar

Currently a browser leverages on the Transport Layer Security (TLS) protocol (6) to encrypt the communication with a web server. This encryption guaranties the user privacy and the data security.

The concept is based on asymmetric cryptography (7) and a chain of trust (8). The server owns a private key. The associated public key is shared to the browser.

But how the browser can be sure this public key really belongs to the targeted server?

The server wrapped the public key within a X.509 (9) certificate containing additional data such as the domain name. Therefore, the browser can access additional data and establish a trust.

But … how to verify if this certificate is not forged by a malicious actor?

This is where the chain of trust concept takes place. The server certificate is signed by a trusted certificate authority‘s private key. The signature is included within the server certificate. This authority is also signed by another one until reaching the root authority.

In order to validate this signature the browser accesses a secured store containing a list of trusted root authorities’ public key (also embedded in a x/509 certificate).

The browser needs then to validate the entire chain before establishing the secure channel with the web server.

Why these root authorities are trustable?

Secured stores containing a root certificate authority (CA) are subject to a strong security process. Independent audits of security and compliance controls achieving certifications against global industry standards (such as webTrust -10) ensure the required trust.

By doing so since decades, the web is secured against tampering or spoofing attack.

What is the problem with eiDAS ?

The major concern from the industry is the revised article 45 (5) stating that web browsers SHALL recognize a new type of certificate to perform web server authentication.

A “QWAC”

The eiDAS regulation introduces a qualified website authentication certificate (QWAC) which differ from TLS certificate. Where TLS purpose is to create a secure channel between the client and the server, the QWAC purpose is to provide an identity about the server’s owner.

The industry already tried to tie a legal identity to a TLS certificate without a clear success. Extended Validation Certificate (EV) was bringing more confusion for the end user and their visual indicator has been removed from browsers (12,13).

The eiDAS regulation reopens the door with the legal identity binding.

Industry concerns

Browser providers (Apple, Google, Microsoft, Mozilla, Opera, and Vivaldi) raised main concerns about the eiDAS QWAC proposition (14). In a nutshell, they blame this solution for being

Incompatible with how browsers load web pages and resources. Browsers rely on complex mechanism composed of cache and multi-connections to load a web page. QWAC requires a unique connection bound to the owner identity. Whilst current TLS mechanism allows multiple connections as long as the origin remains, the QWAC limits the browser interaction to one connection. It would lead to serious performance and functionality issues.
Incompatible with how websites use and deploy TLS. Web server may have several certificates for different resources deployed behind subdomains (e.g. fonts.server.com, img.server.com). As wildcard certificate is discouraged for security reasons web server mainly rely on their hosting provider to manage their certificates rotation automatically (expiration, renewal, issuance…). With QWAC the certificate issuance requires manual validation by two independent approvers and needs to be done by the web server provider. (15) These requirements would impair current practices and disturb the entire web.
Incompatible with how users browse the web. Before being transmitted to the browser, a TLS protected http message could be intercepted by a security component such as firewall or antivirus scanner. This inspection works by intercepting network traffic and performing a man-in-the-middle (MiTM) attack on the connection. Once checked, the http message is encrypted by the inspector certificate (16). By doing so the QWAC certificate will no longer be bound to the TLS.
Not technologically neutral. QWAC are bound to TLS server authentication. Therefore, if TLS is not used, QWAC is not used. Moreover if other TLS based protocol are used, such as mutual authentication (mTLS) or SMTP then QWAC will not work neither.
Problematic with respect to user privacy. In order to ensure the user privacy the browser have been conceived to separate the connection from the resource loaded. In another words it is impossible for a website to determine information about the connection the user used to fetch one or more resources. Then it is difficult to track the user or identify the device used. However, QWAC validation requires to reveal the user browsing activity to a third party which is in contradiction with the browser security and privacy architecture.
Inconsistent with the text of the Regulation and the stated requirements and goals

The major security risk raised by the 35 security experts (1) is more alarming. In order to be trusted by a browser a QWAC certificate issued by a trust service provider (TSP) needs to be added into its store. Unlike root certificate authority, The Digital Identity framework mandates browsers accept QWACs issued by Trust Service Providers, regardless of the security characteristics of the certificates or the policies that govern their issuance (11). In another words, a TSP would be able to deploy a root certificate into a browser store without the rigorous security audit described below. In such context, a malicious certificate could be deploy and deceive users.

Therefore, it will make it more difficult to protect individuals from cybercriminals as security mechanism in place to prevent such attack are revised downwards.

Proposed alternative

The industry already pushed for a decoupled approach allowing the QWAC certificate to be fetch independently from the TLS protocol (17). This solution, called nt-QWAC for non-TLS QWAC, relies on different delivery mechanisms such as