If you're planning to make a contribution to the project, we'd love to add a new card to OpenSC. We would be happy to get you going and to comment on your code. However, please have in mind that in lack of hardware, documentation and manpower, we can't do this on our own.

I'm a hobby coder at best and I lack the technical background to write any code for smartcard projects. I am, however, more than willing to do any debugging or tests required. I could also provide temporary ssh access to a machine with a card reader and the card inserted.
The software which the Population Register provides for Linux is pretty buggy and barely usable. I will also point them to the project and specifically this issue. Maybe they are interested in helping.

Email sent to [email protected] on 11Oct2018 at 14:03 EEST:

Hi,

the mPollux client for Linux is very buggy and pretty unusable. The version 1 and version 2 ID cards worked flawlessly under Linux with the opensource project OpenSC. Unfortunately, OpenSC does not support the Version 3 cards yet.

OpenSC is included in any modern Linux distribution, means, if OpenSC supports the Finnish ID card, pretty much every Linux user can use it. On the other hand, mPollux is supported only for a very small selection of Linux distributions.

I would therefore like to suggest and request that the population register supports the implementation of the Version 3 ID card and any following generation in the the OpenSC project.

I have raised an issue for implementation of the Version 3 ID Card which can be found here: #1504

--
Kind regards / ystävällisin terveisin,
Stefan Gofferje

maybe adding an additional ATR in the old driver would be enough. What's the output of opensc-tool -n -vvv for your old card?

This is the output for my Version 2 (two) card which was issued 2013. That card works perfectly fine with opensc-onepin.
debug.log

You could try your new card with the old driver by adding this to your opensc.conf:

app default {
	card_atr 3B:7F:96:00:00:80:31:B8:65:B0:85:03:00:EF:12:00:F6:82:90:00 {
		type = 6006;
		driver = "setcos";
		name = "SetCOS";
	}
}

The types 6003 and 6004 are also worth a try...

Nope, all three types give me this

root@enterprise:~# pkcs11-tool -L
Available slots:
Slot 0 (0x0): REINER SCT cyberJack pp_a (8608604444) 00 00
C_GetTokenInfo() failed: rv = CKR_TOKEN_NOT_PRESENT

debug6006.log
debug6004.log
debug6003.log

bad news is that your opensc.conf setting didn't work...

good news is that your cards is somewhat detected without it. Try the following patch:

diff --git a/src/libopensc/card-setcos.c b/src/libopensc/card-setcos.c
index f0ed4343..3ee19f81 100644
--- a/src/libopensc/card-setcos.c
+++ b/src/libopensc/card-setcos.c
@@ -130,8 +130,7 @@ static int setcos_match_card(sc_card_t *card)
                                card->type = SC_CARD_TYPE_SETCOS_EID_V2_1;
                        else {
                                buf[sizeof(buf) - 1] = '\0';
-                               sc_debug(card->ctx, SC_LOG_DEBUG_NORMAL, "SetCOS EID applet %s is not supported", (char *) buf);
-                               return 0;
+                               sc_debug(card->ctx, SC_LOG_DEBUG_NORMAL, "SetCOS EID applet %s is unknown", (char *) buf);
                        }
                        return 1;
                }

A quick look at the documentation looks like there are some nice new features, like contactless PIN verification via PACE. But there's not much talk about what OS (Setcos?) is actually used. This could require some more work...

The Estonian smartcard implementation next door (https://github.com/open-eid) already supports the Finnish v3 cards. Maybe somebody with a good eye for code can go and get it from there.

We use provided proprietary binaries

Sorry for the delay. First of all, the Population Register didn't even bother to answer my email itself but dumped my request to 1st level tech support who replied

We are not currently pursuing OpenSC options, however we will keep this in mind when deciding our policies in the future. For now we will fix bugs in our Digisign Linux client when we get more information about them.

Regarding @frankmorgner 's patch, I haven't gotten around to set up the build environment yet. Have to find some time for that.

What binaries do you need?

The version 3 cards apparently use Gemalto MultiApp 3.0. This is according to this: http:https://digisaatio.fi/wiki/Tekniikka/Henkil%C3%B6kortti in Finnish only, unfortunately, and I don't where that information is from since there are no sources listed. Although this would make sense as Setec has been a part of Gemalto for a while.

According to the page the cards are supposed to have an "IAS Classic V4" applet and I tried to add the ATR to card-iasecc.c (on line 73 to static const struct sc_atr_table iasecc_known_atrs[]) but I could not get the driver to use this ATR for matching.

Correct direction is to have the card config as:

app default {

        # Finnish FINeID version 3
        # Gemalto MultiApp 3.0 (javacard) with ISO/IEC 7816
        card_atr 3b:7f:96:00:00:80:31:b8:65:b0:85:03:00:ef:12:00:f6:82:90:00 {
                type = 25001;
                driver = "iasecc";
                name = "Gemalto MultiApp IAS/ECC v1.0.1";
                # secure_messaging = local_gemalto_iam;
                # secure_messaging = local_adele;
                # secure_messaging = local_amos;
                # secure_messaging = local_amos_eid;
                md_read_only = true;
                md_supports_X509_enrollment = false;
        }
}

None of the available secure_messaging schemes work though and are commented out above.

Next thing to try out is to create a correct secure_messaging scheme and if that is not enough, also modify source code where needed. All helping hands are welcome as I don't have too much free time atm either.

OpenSC (IAS-ECC)

• https://github.com/OpenSC/OpenSC/wiki/IAS-ECC

FINeID (FINEID S1 - Electronic ID Application, v3.0)

• https://eevertti.vrk.fi/en/fineid-specifications

As you see lot of APDU request-response cycles works already but next obstacle is...

iso7816.c:121:iso7816_check_sw: Incorrect parameters P1-P2
card-iasecc.c:1021:iasecc_select_file: iasecc_select_file() check SW failed: -1205 (Incorrect parameters in APDU)

In an effort to get Tieto / Fujitsu to actually fix their official client I opened a not successful support request with them. They did make me capture a ton of debug logs. If those could help in any way, I'd be happy to provide them. Otherwise, my schedule is still to tight to get deeper into this.

The P1:9 command seems to be "Select from the current DF", and takes the relative path of a file from the current DF, according to http:https://www.unsads.com/specs/IASECC/IAS_ECC_v1.0.1_UK.pdf (pages 144-145, table 30). The FINEID card doesn't seem to support relative paths for EFs but wouldn't it be relatively easy to construct the absolute path and use P1:8 instead?

Also P2:0 is said to be "unsupported" for SELECT in the IAS-ECC spec (p. 26) but it's still used here? I wonder what an IAS-ECC card returns there, because a FINEID card would return a FCI while the IAS-ECC spec says it doesn't support FCIs. If FCP is used, a FINEID card would return it with P2:4. The FCPs are different in a couple of ways:

• File length for EFs, which has tag '80' in IAS-ECC but '81' in FINEID
• Life cycle status byte is applicable to DFs in IAS-ECC but not in FINEID
• File termination doesn't seem to be supported in FINEID
• DF name is specified to be 5 to 16 bytes long in IAS-ECC but 1 to 16 bytes in FINEID
• Security attributes (tags '8C' and '9C') are nested under tag 'A1' in IAS-ECC but are not nested (ie. on the same level as all the other tags in the FCP) in FINEID
  (Annex A in S1v30.pdf and p. 26 to 28 in IAS-ECC spec)

I'm going to poc a bit around in my fork, let us see where things end up here.. https://github.com/enyone/OpenSC/tree/fineid-dev

Next obstacle is EF ATR at 2F01 contains only 5 bytes of data (only tag present is CARD_CAPABILITIES) and tag PRE_ISSUING not present in data. This obviously terminates init process at iasecc driver.

It may end up the card is too "loosely coupled" with IAS-ECC v.1.0.1 spec and a completely new driver is a better option. Continuing with iasecc still.

The data that would be there on an IAS-ECC card would be "IC manufacturer", "Type of the IC", "OS Version" and "Discretionary data" (IAS-ECC version), but this info seems to just be logged and not used since, at least I couldn't find any usages skimming/grepping through. If they are used though, at least manufacturer and os version can be found in EF.CIAInfo. I'm not sure what "Type of IC" is supposed to contain (contact/contactless?), and I'd think IAS-ECC version is not applicable.

FINEID is also missing a field called "IO buffer size", which would contain maximum lengths for APDU commands and responses. The maximum response length is apparently 256 bytes for FINEID, with a fragmentation scheme for larger amounts of data, but that info doesn't seem to be included anywhere on the card. Also for secure messaging, max command/response lengths are 239 bytes for DES PACE and 231 bytes for AES PACE.

If I remove the checks for pre-issuing data and issuer data lenghts in card-iasecc.c, pcsc-tool -n completes and returns the driver name.

Thanks @ple21108

Card detection now functional with https://github.com/enyone/OpenSC/tree/fineid-dev

Here is some information about the official closed-source client library for FINeID v3 cards developed by Fujitsu (it's Finnish subsidiary) for Väestörekisterikeskus.

https://eevertti.vrk.fi/documents/2634109/0/Fujitsu+mPollux+DigiSign+Technical+References.pdf

Glad to be able to help. Now, with opensc-tool everything apart from listing files seems to work, but there is not much info other than "Not supported" in the debug output. There are some unlock functions called, but those seem to exit successfully and pin is not asked.

I also tried OPENSC_DEBUG=9 pkcs11-tool --list-slots and that fails because opensc expects a "CHOICE" type (whatever that means) of item in the "Parameters" field for supported algorithms. All the ones parsed prior to crash have "NULL" in that field, and the crashing one has an empty "SEQUENCE" array. I don't know why this is done, but FINEID spec does have some algorithms that have extra information stored there. Also pkcs15.c line 67: in src/libopensc/types.h SC_MAX_SUPPORTED_ALGORITHMS defined as 8, FINEID has 21.

Where do you think we should be moving next? I can keep reading the specs and testing, but C is not really my strong suit.

At least we can make communication a bit faster with

And then flood this chat when there is something about our progress to share.

Moved iasecc flop to https://github.com/enyone/OpenSC/tree/fineid-iasecc (fineid v3 does not obey iasecc)

Continuing with a completely new separate driver at https://github.com/enyone/OpenSC/tree/fineid-oberthur

Now asking review before actual PR to upstream OpenSC/OpenSC
enyone@fbca962

Closing this issue due to inactivity. Please re-open the ticket if more input is available.

They seem to be issuing these now:

ATR: 3B 7F 96 00 00 80 31 B8 65 B0 85 04 02 1B 12 00 F6 82 90 00
+ TS = 3B --> Direct Convention
+ T0 = 7F, Y(1): 0111, K: 15 (historical bytes)
  TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
    250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = 00 --> Extra guard time: 0
+ Historical bytes: 80 31 B8 65 B0 85 04 02 1B 12 00 F6 82 90 00
  Category indicator byte: 80 (compact TLV data object)
    Tag: 3, len: 1 (card service data byte)
      Card service data byte: B8
        - Application selection: by full DF name
        - BER-TLV data objects available in EF.DIR
        - BER-TLV data objects available in EF.ATR
        - EF.DIR and EF.ATR access services: by READ BINARY command
        - Card with MF
    Tag: 6, len: 5 (pre-issuing data)
      Data: B0 85 04 02 1B
    Tag: 1, len: 2 (country code, ISO 3166-1)
      Country code: 00 F6
    Tag: 8, len: 2 (status indicator)
      SW: 9000

Possibly identified card (using /home/pyllyukko/.cache/smartcard_list.txt):
3B 7F 96 00 00 80 31 B8 65 B0 85 04 02 1B 12 00 F6 82 90 00
	Finnish ID-card v5.0(?) (eID)
	https://dvv.fi/en/fineid-specifications