indexwritings › pki-in-lithuania

Digital signatures and PKI in Lithuania

This is a draft / notebook of sorts, in which I try to document the Lithuanian "qualified" PKI compatibility with Linux.


ADIC (identity card)

The ADIC, formerly NSC, issues national ID cards with two certificates preloaded – one for TLS client authen­tication (NQC-Authentication) and one for non-repudiable digital signatures (QC-DigitalSignature), both 2048-bit RSA. They are valid for 3 years; issuance and renewal is free.

As of 2012-07-04, ADIC issues CryptoTech cards, while older ones are Gemalto (GemXpresso R4). All official drivers and PKI roots are available at

As of 2017, the provided middleware is from

Skaitmeninio sertifikavimo centras (SSC)

Private company, with all the features that the word 'off-brand' brings to mind. In a longtime feud with RCSC regarding the presence of national identity numbers in certificate metadata; as a result, RCSC-managed websites generally do not accept SSC certificates.

They use Aladdin eTokens for certificates. SSC lost its qualified status in February 2018.

Registrų centras (RCSC) aka


Hardware (tokens)

Overall, smartcards work much better on Linux than they do on Windows. The general situation is that Windows middleware use deeper hooks, and tend to conflict with each other – if you need different software for cards A and B, you'd better hope one of them will support both. (As is fortunately the case with PWPW and CryptoTech.) On top of that, vendor middleware tend to mishandle cards which already had native support by Windows.

CryptoTech smartcards (national ID 2012)

Issued by ADIC as national ID cards from mid-2012. Drivers (CryptoCard Suite) for Windows and Linux are provided; a Mac OS X version is listed as "available on request".

The Linux driver is very minimal – just a single PKCS#11 library. On both operating systems, it also supports the older Gemalto cards. I have not tested with a recent card.

Gemalto smartcards (national ID 2009)

Issued by ADIC as national ID cards between 2009 and mid-2012. Officially ADIC only supported Windows and provided a slightly outdated (but working) Gemalto Classic Client. However, CryptoCard and PWPW middleware provided by ADIC from 2012 also supports these cards.

Gemalto Linux drivers can be found in various places, e.g. LuxTrust (who distribute rebranded Gemalto tokens), and the provided libclassicclient seems to work. (n Arch Linux it's repackaged in AUR as libclassicclient.) With it, the card can be managed via pkcs11-tool --module, and various other features seem to work.

These cards only support SHA-1 which causes many difficulties with e.g. TLS client authentication, as browsers expect to be able to use SHA-256 or even SHA-512 for TLSv1.2. (This is mentioned in the PWPW middleware's user guide.)

Gemalto (Aladdin; SafeNet) USB eTokens

Issued by SSC (and apparently by RC). They use SafeNet Authentication Client (eTPkcs11).

The available versions are Gemalto SAC 10.3 for Windows and 8.3 for Linux, neither of which I've tested yet. (Earlier, when I had just ordered the token, they were providing Aladdin SAC 8.0, which was a bit rusty, and the Linux version even required HAL.) For Arch Linux there is a sac-core package with minimal SAC 9.1.

(Both 72K JavaCard and 64K CardOS models are seen in the wild, and both work fine with the latest sac-core.)


Not yet investigated: Giesecke & Devrient cards and USB tokens sold by RC.

Online (web) usage

To my knowledge, certificates from all issuers have the "TLS Client Authentication" usage, which means they can be used with any program which speaks PKCS#11, including web browsers. However, some websites use their own custom plugins. (This is anyway unavoidable for digitally signing documents, since there's no native in-browser feature for that.)

Signa Web (MitSoft)

Digital signatures for ADOC documents, also used embedded by SoDra and VMI.
Status (2018-04-21): Works very well.

Invokes a standalone signing application. (Previous versions used a Java applet.) The new "Signa Browser Extension" is launched as an URL handler for signa:auth/<uuid> and performs everything out-of-band, while the webpage polls the server for status.

The software is reasonably cross-platform (Java-based), with Linux packages provided in addition to Windows .msi (the former repackaged for Arch as signa-browser-ext; a macOS version is supposed to be available as well). I'm not sure what architectures it works on, but the smart-card interface seems to be a bundled copy of generic javax.smartcardio and detects installed PKCS#11 libraries as it should.

Digital signatures and authentication, also used embedded.
Status (2018-04-21): Works well in supported browsers.

ISIGN offers a document signing website (supporting PDF, ASiC, Lithuanian ADOC, Estonian BDOC, Latvian EDOC), with paid plans. The same infrastructure is also used when selecting "National ID" card in some websites (e.g. "E-Government Gateway").

Communicates with a local backend through a browser extension and Native Messaging (official documentation). The extension works with Chrome as well as Firefox 50 (as of 1.2.0). The backend is available on Linux as a .deb package (repackaged for Arch as isign-chrome-signing) and is based on Qt5. It seems to have a hardcoded list of PKCS#11 modules to try, and does not support selecting between multiple connected tokens, but otherwise works well.


Selecting "Token (SSC)" in websites which offer this option (e.g. the E-Government Gateway) redirects to the SSC IdP website, which uses native (TLS) client authentication. (A Java-applet option is still available for Firefox, but is probably going to disappear soon.) Fortunately, at least the Linux "SafeNet eToken" PKCS#11 module from sac-core works with both Chromium and Firefox. (Registrų Centras)

Single sign-on for RC-managed websites.
Status (2018-04-21): Garbage.

Websites managed by "Registrų centras" use a SSO website, which supports native (TLS) authentication for both RCSC-issued tokens and national ID cards. (SSC token users used to get redirected to SSC's own website; now their certificates are merely rejected due to allegedly invalid profile, which really means "no national ID number found".)

Site requires TLSv1.2, but my old Gemalto card only supports SHA-1, so hardware token logins don't work for me; I have to use mobile signature. (Which, I suppose, will also stop working this July when mobile operators transition to EID-SK as the issuer.)

GoSign (Registrų Centras)

Digital signatures for PDF documents (PAdES), also used embedded by RC-managed websites.
Status (2018-04-21): Garbage.

Two options are provided for hardware tokens: Java and local service. The former, of course, no longer works in modern browsers – and yet it's the only option that works at all (using Firefox 52esr for Win32, that is).

The latter method (called "LocalSign") is only provided as a Windows installer. Upon installation it starts an API service on https://localhost:8000, which only works after manually adding a TLS certificate exception for localhost. (I think a compatible implementation could be easily written for Linux.) Additionally, the service only looks for eToken PKCS#11 modules suitable for RC-issued tokens, and doesn't support national ID cards by default. It can be tricked by copying the apropriate module to etpkcs11.dll or aetpkss11.dll.

However, even if LocalSign is installed and the apropriate signing method chosen, the website still doesn't actually use it. (The webpage contains all the required JavaScript code, but for some reason has data.forceLocalSign = "disable".)

Mobile signature works for now (but see EID-SK note).

Mobile signatures

Nearly all websites accepting digital signatures also offer a "mobile signature" option, which uses certificates embedded in one's mobile SIM card. The exact protocol is unknown, but the entire process works like this:

  1. Web server contacts operator (using an unknown API);
  2. Operator sends a special SMS message and returns a verification code (4 digits or alphanumerics);
  3. Website displays the verification code to user;
  4. Mobile phone receives the SMS message and passes it to an embedded "SIM Toolkit" (STK) applet;
  5. The STK applet shows a popup dialog with the same verification code, then a sPIN prompt;
  6. The STK applet signs the hash found in the original message, then sends another SMS message containing the signature;
  7. Website keeps polling the server for signature status until a success is received.

Overall, this is the most convenient and compatible option, although has the major downside of being usable only by the select few services. (Even viewing one's own public certificate requires a certain amount of trickery.)

Originally mobile signatures were provided by RC (Registrų centras). One major downside of their product was that all certificates were 1024-bit RSA, presumably due to SIM Toolkit limits. In April 2018, mobile operators have announced a plan to migrate to the Estonian CA "SK ID Solutions", bringing in security improvements. The migration has happened by now, and all old certificates were revoked on July 1st, 2018. (TODO: I have no information about the certificate format they use.) Some customers are still being issued RC-provided certificates, however, those now use ECDSA (secp256r1).


Android app developed by SK-EID (official site). Used for authentication by various banks (Swedbank, SEB).

Works in a similar manner to mobile signatures. The private key is split into two shares (phone and server-side HSM) and a special algorithm is used to create a combined signature.

Document signing is also possible – currently only through ISIGN, which recognizes such signatures as "advanced" but not "qualified", although the certificate is.

Signed document formats

To do. Format is ADOC-1.0 (also more documentation), online tool Signa Web.