This is a draft / notebook of sorts, in which I try to document the Lithuanian "qualified" PKI compatibility with Linux.
The ADIC, formerly NSC, issues national ID cards with two certificates preloaded – one for TLS client authentication (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 http://www.nsc.vrm.lt/downloads.htm.
As of 2017, the provided middleware is from PWPW.pl.
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.
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.
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.
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 libgclib.so, 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.)
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.
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.)
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.
Single sign-on for RC-managed websites.
Status (2018-04-21): Garbage.
Websites managed by "Registrų centras" use a SSO website ipasas.lt, 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.)
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
data.forceLocalSign = "disable".)
Mobile signature works for now (but see EID-SK note).
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:
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.) Another downside is that all currently issued certificates are 1024-bit RSA, presumably due to SIM Toolkit limits.
Originally mobile signatures were provided by RC (Registrų centras). In April 2018, mobile operators have announced a plan to migrate to the Estonian CA "SK ID Solutions", which hopefully will come with a switch to EC certificates.
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.
To do. Format is ADOC-1.0 (also more documentation), online tool Signa Web.