Arnis Parsovs is greatest single researcher who has found and helped to fix many security vulnerabilities around Estonian eID card scheme. I can only assume that other countries have all kinds of issues still present.
Latest published discovery shows how it is possible to login into freely chosen website that is protected with mutual TLS handshake client certificate authentication.
It works because it used to be possible to sign arbitrary digest values using the ID card software. This was widely used as failsafe and browser independent way to read the ID card. During Client certificate authentication TLS handshake bytes are signed on the smart card. Now if someone tries to login to your “malicious” site and you present the user digest from target site TLS handshake then after getting the signature you are able to access the target site on behalf of the victim. Here is the video showing this scenario.
What to keep in mind regarding mutual TLS authentication
While Client Certificate Authentication is relatively easy then developer must know exactly what he is doing not to introduce any serious vulnerabilities.
Most important things to keep in mind
- Check certificate revocation and validity every time. If CRL is used then these need to be updated often enough
- Disable TLS cache if more security needed
- New CA certificates are added periodically. You need to update them to keep the service working.
ID card reading works using client certificate authentication during TLS handshake. Digest of handshake bytes are signed with the private key on the smart card. Generated signature will be sent to the webserver (Apache2/ngix/etc) where server validates the signature. If all checks pass then server will make public certificate info available for the applications. This happens in a very low level in openssl libraries.
Often people forget to check certificate validity. It is mandatory that CRL or OCSP is used to check every Client certificate of stolen cards can be used to login to the systems. CRL-s must be regularly updated multiple times per day. National eID schemes new Root Certificates could be issued every month and others are expired. Thus ID card login needs constant maintenance.
HTTP protocol is in essence stateless where every image loading and pageview makes connection to the server. To avoid TLS handshakes for every pageview then webservers have implemented SSL session cache which in Apache2 webserver case is up to 5 minutes. This means that if the ID card and PIN were already checked within 5 minutes in this computer in this browser then no new TLS session is generated and the same available information is presented to the application.
If the SSL cache is not disabled completely then chance exists for somebody else to login to your account without card in reader and without PIN entry if you have logged out and the TLS cache in server side is not expired yet.
There are some other things to remember regarding browser caching. During ID card login browser will at first prompt user for 2 inputs. Firstly which certificate to use and secondly what is the PIN code. Unlike digital signature certificate with PIN2 the ID card authentication certificates policy allows PIN1 to be cached by the browser. This means that if you logged into the site already one then next time same certificate and PIN will be used. If you login to some other site then certificate choice prompt will be presented to user and if same certificate is used then PIN is taken from the cache.
This means that if you have logged out and have not removed the smart card from reader then other people can login to your account without knowing the PIN code if they have physical access to the computer.
