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. Cards themselves have good Linux support; all official drivers and PKI roots are available at http://www.nsc.vrm.lt/downloads.htm. (There is macOS support but so far all drivers are only available by request.)
From 2009, ADIC were issuing Gemalto GemXpresso R4 cards with RSA-2048 certificates. All remaining ones have been revoked in 2018-09 due to unspecified security issues.
From 2012-07, ADIC were issuing CryptoTech cards. Linux driver was available (libccpkip11.so).
As of 2017, ADIC are issuing cards by PWPW S.A. and the corresponding Linux driver is pwpw-card-pkcs11.so, but the CryptoTech one appears to work as well. (In fact, the libccpkip11 driver works slightly better.)
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. SSC lost qualified issuer status in February 2018.
They previously issued Aladdin eToken PRO 64K and 72K, later SafeNet eToken 5110 FIPS. The former work well on Linux using SafeNet Authentication Client (AUR: sac-core); the latter should in theory work with SAC 10.x or later.
Government company, keeper of various national registries. They previously sold Aladdin eToken PRO, but now sell Giesecke & Devrient tokens and smartcards, which officially have no Linux or macOS support at all (RCSC has claimed to have no plans whatsoever to provide Linux-compatible devices) although can be used if the SafeSign software is obtained from somewhere else.
RCSC have been the primary mobile-ID issuer until 2018-07, and still provide the service to at least one operator.
Estonian national ID company; probably one of the earliest certificate issuers for Lithuanian citizens as well. They provide qualified mobile ID (SIM card) certificates as of 2018-07, and have a "Smart-ID" Android/iOS app with similar capabilities.
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.
Also available are phone-based methods which do not require any dedicated token (instead using a smartphone app or SIM Toolkit). Due to ease of use they are the most common, although with the downside of being proprietary systems.
Issued by all mobile operators. They use a SIM Toolkit applet, therefore should be compatible with the majority of GSM phones. (The applet receives requests via SMS messages, pops up a confirmation prompt, then sends results back. The exact working mechanism is unknown, but at least older cards likely used WIB plugin as there is a old doc referencing this specification.)
The usage flow is discussed in more detail in the Online services section. Overall, the system is proprietary and closed, although access is available to companies under a contract. As of 2022 (approximately), the Mobile-ID API service is provided as a (paid) REST API by EID-SK, with public documentation.
Until 2018-07, all cards had a single RSA-1024 certificate by RCSC. Starting with 2018-07, old certificates have been revoked and most operators have migrated to EID-SK as the issuer, which now use two RSA-2048 certificates (signing and authentication). However, some cards are still provided by RCSC as before, but now with a single ECDSA-secp256r1 certificate instead.
The EID-SK cards use a new "on demand" provisioning process: the customer receives a blank SIM card and enters the ICCID into a special website to provision it for both the GSM/4G network itself and for the digital certificates. [2023: This was true briefly, but I don't know if it still is.]
Provided by EID-SK as a more modern alternative to mobile-ID, with Android and iOS versions available. Uses two RSA-2048 certificates (authentication and signing), with a split signature scheme where one share is computed by the app (SecureZone) and one by the cloud server (EID-SK HSM). As with mobile ID, direct access to this system is not free.
The app provides two account levels: "basic" (authentication only) if the user's identity was verified through online banking SSO, or "full" (authentication and signing) if the identity was verified using an existing certificate (ID card or mobile). With a full account, documents can be signed using Dokobit.
As of 2018-11, the Smart-ID app is a QSCD and all newly created "full" accounts will be issued qualified certificates. (Older certificates are only recognized as advanced and aren't upgraded automatically.)
Issued by ADIC as national ID cards since August 2021. Drivers for Windows/Linux/macOS are provided on the ADIC website as well as the developer's own website. I have not tested on Windows yet; the Linux driver is packaged on AUR as mcard-toolbox.
These cards have a 6-digit "Card Access Number" which is required to unlock the card as proof of having physical access; the "MaskTech Toolbox" app prompts for it once, then appears to derive a key and store it under ~/.mcard/ which is read by the PKCS#11 module on subsequent uses. This appears to be standad PACE2 CAN/MRZ authorization as mentioned here; the same directory has a debug log file that talks about it:
[ INFO ](token) EF.DIR SSCD entry: {"SSCD" OID = 'A0:00:00:00:63:50...' at 3F00DF02}
[ INFO ](token) EF.DIR ICAO entry: {"ICAO" OID = 'A0:00:00:02:47:10...' at 3F00DF01}
[ INFO ](card) Reading EF FID 0x011C
[ INFO ](token) EF.CardAccess: Card access [PaceInfo(0.4.0.127.0.7.2.2.4.2.2, V2, param id = 12)]
[ INFO ](pkcs11) This token is not authenticated and requires initial authentication. Will try to
look in cache for it's CAN.
[ INFO ](card) Preparing to peform PACE
[ INFO ](card) Preparing PACE environment for key ref 2 (CAN)
[ INFO ](token) EF.CiaInfo: { manufacturer = "MaskTech International GmbH", label = ... }
Documentation found within the software claims that the CAN "ensures that the certificates (and your identity) cannot be skimmed remotely and it protects the PINs from being blocked without your knowledge". This is apparently due to the new cards using the same software for both interfaces (wired as well as NFC) and therefore providing access to smartcard functionality via NFC (and likewise to ICAO data via wired interface), whereas previous cards had a completely separate NFC chip for ICAO that the "main" smartcard did not know about.
Issued by ADIC as national ID cards from approximately 2018 until 2021; mass-revoked in 2023. Drivers for Windows and Linux (pwpw-card-pkcs11.so) are provided on the ADIC website; a macOS version is listed as "available on request". The Linux driver is packaged in Arch AUR as pwpw-card. However, CryptoTech (CryptoCard Suite) drivers appear to be fully compatible with the new cards and might be the preferred option.
The Linux pwpw-card-pkcs11.so module appears to be a modified version of OpenSC-PKCS11, and for some reason is incompatible with OpenSC's own pkcs11-tool (always reporting an empty dummy slot) although still works with all other software. (Update: It makes other software segfault. This is fine, as all PWPW cards have been revoked as of 2023.)
Issued by ADIC as national ID cards from mid-2012. Drivers for Windows and Linux (CryptoCard Suite; libccpkip11.so) are provided on the ADIC website; a Mac OS X version is listed as "available on request". The Linux driver is very minimal – just a single PKCS#11 library; it is packaged in AUR as ccpkip11. However, these cards also work with the PWPW driver.
Issued by ADIC as national ID cards between 2009 and mid-2012. All certificates were revoked in 2018 due to unspecified security issues, and cards have been reissued for free.
The website only provided a slightly outdated Windows version (but working) of Gemalto Classic Client. More recent versions, including Linux PKCS#11 driver (libgclib.so) can be found in various places, e.g. LuxTrust (who distribute rebranded Gemalto tokens). In Arch Linux this driver is repackaged in AUR as libclassicclient.
However, these cards are also supported by both CryptoCard (ccpkip) and PWPW middleware provided by ADIC from 2012, so that's the preferred choice for Linux.
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.)
Previously issued by SSC and RCSC. 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.
Should work with sac-core 10.0.
Sold by RCSC. Untested. Officially there is no Linux or macOS support at all, and RCSC claims to have completely no interest in providing Linux-compatible products.
However, the required software (SafeSign Identity Client; libaetpkss) does have a Linux version and can be obtained from elsewhere; it is packaged on AUR.
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 by websites.
Status (2018-04-21): Works well in supported browsers.
Dokobit 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 practically a fork of that used by ID.EE; it is available on Linux as a .deb package (repackaged for Arch as dokobit-plugin) 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.
Status (2019-10-19): WFM.
The online banking page supports Smart-ID, Mobile ID, and "Identity card" authentication. The latter uses native (TLS client certificate) authentication and seems to work fine with my PWPW-manufactured ID card.
Single sign-on for RC-managed websites.
Status (2019-10-19): WFM.
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. Works fine with my PWPW-manufactured ID card; as well as EID-SK issued mobile signature.
(Old 2018 note: 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".)
Digital signatures for PDF documents (PAdES), also used embedded by RC-managed websites.
Status (2021-04-29): Still a garbage fire.
Website login goes through ipasas.lt and works well. Making digital signatures of course can't be done via TLS and requires a plugin.
Signing communicates with a local backend over HTTP, which previously was a Java service but the 2020 version has been rewritten on top of .NET Core. (In theory it should run on Linux dotnet-runtime, but seems to be far more annoying than it should be.) Upon installation it starts an API service on https://localhost:8000, which has a certificate issued by RCSC (although not by the same root that is in Microsoft's certificate store). The API seems simple and a native replacement for Linux could easily be written.
Overall it's a downgrade from last year – the previously distributed "LocalSign" backend ran on Java and as of 2019-10 worked surprisingly well on Linux, detecting both the OS and the correct PKCS#11 modules (if you could manage to extract it out of the two-layer Windows-only installer). Although it was made with only RCSC-issued tokens in mind, and was out of date regarding which PKCS#11 module was needed for the latest national ID cards (PWPW) and only happened to work if people still had CryptoTech ccpkip11 installed.
On the bright side, as of 2020, the installer is finally self-contained and delivered over HTTPS. (In 2019 it was still delivered over HTTP, and although Authenticode-signed it proceeded to download various auxiliary files (such as root CAs!) over plain HTTP. Surprisingly, the national digital signature authority website did not even support HTTPS in 2019!)
Mobile signature works, even with EID-SK SIM cards.
Nearly all websites accepting digital signatures also offer a "mobile signature" option, which uses certificates embedded in the cellphone's uSIM card. This system is based on GSM "SIM Toolkit" applications and provides great compatibility with various phones. The usage flow looks 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.)
Certificate types are documented in the Hardware section.
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 Dokobit. See the Hardware section for details on qualified signatures.
All formats are based on the eIDAS e-Signature standards.
The most common format and currently (2019-01) the only format approved for government use and mandatory to accept by organizations.
Uses .adoc container files which conform to the ODF Open Document Format (MIME type application/vnd.lt.archyvai.adoc-2008). Conforms to XAdES, which is a superset of XML-DSig. (Most documents use XAdES-EPES.)
ADOC is a container format, containing one primary document (OOXML, OpenDocument, PDF, JPEG, TIFF) plus any number of additional files, as well as various signable metadata (signing purpose, signer's role, etc. – can be seen in full extent via Signa Web).
Both Lithuanian ADOC-V2.0 and Estonian BDOC-2.x are national profiles for the European standard ASiC (ETSI TS 102 318), specifically the ASiC-E container format. (The single-file ASiC-S is not used.)
ASiC-E uses .asice, .sce, .adoc, .bdoc files conforming to the ODF Open Document Format spec (MIME type application/vnd.etsi.asic-e+zip). Conforms to XAdES and XML-DSig.
ASiC-E appears to be very similar to ADOC-V1.0 in many aspects. It is a container format like ADOC-V1.0, although I haven't collected any multiple-file samples, and I don't know of any software which would support the features like Signa Web currently does for ADOC.
The main difference between BDOC-2.x and ASiC appears to be that the former uses XAdES-EPES "time marks" (stapled OCSP response), while the latter uses XAdES-BES/XAdES-T "time stamps" (explicit RFC 3161 timestamp).
Support for ASiC-E is quite rare in Lithuania; although it was approved in 2016-06 as "mandatory starting with 2018-01", the approval was rescinded later in 2017-02. (It seems that a new LT ADOC-V3.0 profile will likely be required for conformance with eIDAS… or something like that, anyway.) Online this format is supported via Dokobit (online) and the Estonian DigiDoc4 (desktop).
Direct PAdES usage is rare. The PDF-LT-V1.0 standard specifies XMP tags for signing metadata (role, etc.) that the ADOC container would carry. Similar to ASiC-E (ADOC-V2.0), the format currently is not accepted for official government documents or archival.
Online, Dokobit supports PDF and GoSign uses it as the only format. Adobe Reader also supports PAdES signatures in general, though obviously only signing with a local hardware token (not mobile ID) is possible.