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.

  1. Certificate issuers
  2. Signing hardware
  3. Online usage
  4. Document formats

Certificate issuers

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. 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.)

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. 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.

Registrų centras (RCSC) aka elektroninis.lt

Government company, keeper of various national registries. They previously sold Aladdin eToken PRO, but now sell Giesecke & Devrient tokens and smartcards, which infamously have no Linux or macOS support at all (or at least, not for free). RCSC has claimed to have no plans whatsoever to provide Linux-compatible devices.

RCSC have been the primary mobile-ID issuer until 2018-07, and still provide the service to at least one operator.

EID-SK aka SK ID Solutions aka AS Sertifitseerimiskeskus (SK.EE)

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.

Hardware

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.

Mobile-ID uSIM cards

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.

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.

Smart-ID application

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.)

PWPW smartcards (national ID 201x)

Issued by ADIC as national ID cards from approximately 2018. 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.

CryptoTech smartcards (national ID 2012)

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.

Gemalto smartcards (national ID 2009)

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.)

Aladdin eToken PRO USB tokens

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.

SafeNet eToken 5110 FIPS USB tokens

Sold by SSC. Untested, but should work with SafeNet Authentication Client 10.x or later.

Giesecke & Devrient smartcards and USB tokens

Sold by RCSC. Untested, but apparently there is no Linux or macOS support at all, and RCSC claims to have completely no interest in providing Linux-compatible products. Avoid.

Online 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.

Dokobit (previously ISIGN)

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.

SSC

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.

ipasas.lt (Registrų Centras)

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.)

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 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:

  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.)

Certificate types are documented in the Hardware section.

Smart-ID

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.

Document formats

All formats are based on the eIDAS e-Signature standards.

LT ADOC-V1.0

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).

ASiC-E (LT ADOC-V2.0, EE BDOC 2.x)

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).

PDF (PAdES)

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.