Elpako (by Nevda) digital signature platform authentication vulnerability
Introduction
Elpako is “an electronic signature & digital services platform”, a product by Nevda. Part of its functionality is authentication and digital document signing using Lithuanian identity card.
The authentication part is also used as one of methods to sign in into Lithuanian E-Government Gateway epaslaugos.lt.
This article describes an issue I found concerning this authentication method.
How it works
Simplified outline:
┌─────────────────────┐ ┌───────────────┐ ┌─────────────┐ ┌──────────────┐
│Elpako authentication│<──>│Elpako desktop │<──>│mCard PKCS#11│<──>│Lithuanian EID│
│ gateway website │ │web service on │ │ module │ │in USB reader │
└─────────────────────┘ │localhost:38888│ └─────────────┘ └──────────────┘
└───────────────┘
Elpako authentication gateway talks to the local web service installed into
cardholders computer using so-called Local API. The API endpoint
/Signing/SelectCertificate starts the process by displaying cardholder
a dialog to select certificate to be used for authentication or document signature.
Then, endpoint /Signing/Sign is used to sign a token given via parameter dtbs.
During signing, cardholder is asked to enter card PIN.
Note: at the time of investigation value of dtbs was a longish random character
string, could have been a hash of something.
The certificate obtained via /Signing/SelectCertificate and signature of dtbs
obtained via /Signing/Sign is then used by the authentication gateway to identify
the cardholder.
The problem
Let’s name the card’s cryptographic ECDSA signature function - sign.
Then, a simplified view of what Elpako desktop service does is:
result(dbts) = sign(sha256(dbts))
It’s near direct access to the signature function without any scoping to a specific protocol or protocol domain (e.g. website performing authentication).
Also note, that the local web service neither limits access to API to specific
trusted sites using CORS, nor it uses browser sent Origin header
value to do any further validation.
It means a malicious actor could set up a website proxying dbts from
authentication gateway, sign it and proxy result back to impersonate
the cardholder. For example, this website could be something adult oriented
(e.g. selling electronic cigarettes) and ask cardholder to confirm age using
identity card.
All in all it’s a serious technical issue where only saving grace is unpopularity of identity card + USB reader authentication method in Lithuania. It’s highly unusual to use this method outside of gov websites. As a result, a convincing malicious website would be difficult to produce.
Demonstration
To demonstrate this I created this “malicious” website.
Source code: github.com/tadas-s/elpako-issue
And the demo recording:
Suggested fix
First simplest fix would be limiting access to the API using CORS and maintaining trusted website list. I can only speculate why it was not done before - maybe vendor found too cumbersome to maintain those lists, maybe software and authentication gateway gets also deployed to company intranets and, again, maintaining list is difficult.
If there’s a desire to keep API open to any origins - then the sign function
should be split into parameter spaces using browser provided Origin. E.g.
the simplified signature process should become something like this:
result(dbts, origin) = sign(sha256(dbts + "<..some separator>" + origin))
In that case authentication gateway, when verifying the signature, should independently form its own signed data string and insert target website domain.
Timeline
- Vendor notified: ~April 23rd, 2026.
- Fix released: ~May 8th, 2026
Other issues
Overall I wasn’t impressed by the quality of this piece of software. It does feel superfluous, given the government websites like epaslaugos.lt could have used browser PKCS#11 capabilities for authentication. E.g. authentication gateway ipasas.lt from another gov agency Registrų Centras has done this.
Certificate selection and PIN entry windows/dialogs also fail to adequately inform the cardholder which website initiates the process and the purpose of it (authentication or document signing). Again, with bit of social engineering cardholder could end up signing a document while thinking he/she is confirming their age.
Another security researcher has recently identified even worse issue with it - remote code execution.
Elpako package is also prepared for Linux systems - but it’s more of a government contract box-ticking exercise. At the time of testing it only worked on Ubuntu 20.04, while PKCS#11 mCard module by Softemia is only compatible with later versions of Ubuntu.
The main Linux package process also runs as root, without any confinement. It also starts from init.d script, when all modern popular distributions have migrated to systemd.
Related - issue with Estonian Web eID
About 5 years ago almost exact same issue was identified in Estonian Web eID system. Here’s a few links: