Add support for Slovenian eID

[craftbyte]

Hi,
I am trying to get the Slovenian eID (ATR: 3b:d5:18:ff:81:91:fe:1f:c3:80:73:c8:21:10:0a) working.

The chips are NXP P71 with JCOP 4.

So far I have been able to read EF.DIR to get the AID of E8:28:BD:08:0F:01:4E:58:50:31 (something ending NXP1). The app seems to be a PKCS#15 app.

All the files I could dump are in the gist

Is there a good driver I can already use to try exploring this with pkcs15-tools, as at the moment I get the error of Failed to connect to card: Card is invalid or cannot be handled?

[mikhailnov]

I think it would be better to first try to add USB IDs into ccid or another driver (e.g. acr38u), because the chip may be already supported, but the IDs may be unique. Here is an example patch for ccid:

--- a/readers/supported_readers.txt
+++ b/readers/supported_readers.txt
@@ -963,6 +963,8 @@
 # THRC
 0x062D:0x0001:THRC Smart Card Reader
 
+0x0483:0x00DF:SCAN BIO
+
 # VMware
 
 ##########################

[craftbyte]

I don't see why we would need to do this, since the eID is a smart card and not a USB token.

[dengert]

The tests so far have shown that the CCID driver is working fine. So adding it to supported_readers.txt is not needed.

"Failed to connect to card: Card is invalid or cannot be handled" means that the card was not recognized.

How did you produce the output in the gist listed above? Was this opensc-explorer?

Most OpenSC tools support the --card-driver parameter, to force the use of a specific driver.
Try using --card-driver default and try pkcs15-tool --card-driver default --dump

(Although there are many "pkcs15" cards, many need additional code to handle card specific issues or features.)

See: https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC to get a debug log which would help to see how far you can get.

"man opensc.conf" and https://github.com/OpenSC/OpenSC/blob/master/etc/opensc.conf.example.in to see what can be done. https://github.com/OpenSC/OpenSC/wiki/Environment-variables

If you can get it to work with an existing OpenSC driver by forcing the use of a specific driver, then the ATR could be added to that driver. If not, then see:https://github.com/OpenSC/OpenSC/wiki/Adding-a-new-card-driver

opensc-explorer and the --mf parameter might be helpful.

pkcs15-dnie.c and pkcs15-pteid.c use non default pkcs15 files structures.

[craftbyte]

Yes, the dumps were made with opensc-explorer. I cannot run pkcs15-tool with --card-driver as I get unrecognized option '--card-driver'. I tried setting the driver to the ATR in opensc.conf like so:

	card_atr "3b:d5:18:ff:81:91:fe:1f:c3:80:73:c8:21:10:0a"
 	{
		name = "Slovenian eID";
		driver = "default";
	}

This is the debug log of pkcs15-tool.exe -r 2 --dump --aid "E828BD080F014E585031": https://gist.github.com/craftbyte/20811c3fbb644588d6a2b8e0a9952e0e

If I set the driver to something that is not default I get the log of it just trying that driver. Why does this not happen if I used default and it goes ahead and tries all drivers?

[craftbyte]

Just as I posted, I found out I need to enable the driver with enable_default_driver = true; in opensc.conf.
Here is a dump: https://gist.github.com/craftbyte/c8a6b7c6f5f9f7e18f05a4347c0c0ed7

[dengert]

If I set the driver to something that is not default I get the log of it just trying that driver. Why does this not happen if I used default and it goes ahead and tries all drivers?

Not sure. But default is usually used to try and get a new card to work and write a new driver.

Your last dump looks promising. Using the modified opensc.conf, can you get pkcs11-tool --test --login to do anything?
(pkcs11-tool --test does not currently test ECC keys. but it would get far enough to show you are close.)

I see https://www.slovensko.sk/en/download has drivers for Windows, Mac and Gnu based linux. But this looks like for older cards and is not clear if it supports ECDSA or just RSA Does you government have downloads for the newer card?

How do you want to use this card? If its just on windows, use the government's drivers.

PKCS15 just defines a file structure, The actual APDUs sent to the card to do crypto operations vary by card and applet on the card. See if you can find any documentation or open source for their drivers. ISO 7816-4 and ISO 7816-8 define the APDUs, but these are so extensible, a new driver maybe needed.

If a new driver is needed sometimes running a USB trace or PCSC trace of their windows driver might help.

You can try using some of the pkcs15 tools to do a sign and openssl to do the verify.

The only way to develop a new driver is for someone with a card, like you, writes a new driver or modify an existing driver. https://github.com/OpenSC/OpenSC/tree/master/src/libopensc contains the drivers as card-* and pkcs15-\<card\>.c if needed to handle special cases.

[craftbyte]

The correct link would be https://www.si-trust.gov.si/sl/eoi/ (Slovenia, not Slovakia 😉).

Trying test login I get Please enter User PIN: error: PKCS11 function C_Login failed: rv = CKR_GENERAL_ERROR (0x5).

Since the official drivers are not out yet, looks like we will have to wait to advance further. I issued a FOIA request for the APDU specs but got denied with the reason that an NDA was signed between the government and the developer (even though the government posseses such specs). The drivers should be available on all platforms. I suggest we leave this issue open and I will try implementing a driver once I am able to reverse engineer/get the government to give me the APDU spec.

[dengert]

Sorry about the wrong link. a Google search for: slovenia eid smart card driver download returned https://www.slovensko.sk/en/download

Good luck with obtaining any documentation. Any idea who is the developer?
With some other cards, developers had taken OpenSC code (LGPL licensed source code) for a government issued card. See #1831

[craftbyte]

The developer is NXP (as can even be seen in the PKCS#15) through a local company (Cetis). The more interesting part was that the public tender had the requirement of either having the card supported in OpenSC or providing middleware and the provider selecting the worse option... Sadly, this is how politics works here. I am also looking at requesting a public interest balance test for the specifications, to be able to get them from the ministry.

It also seems that the app we have been testing is a PIN-less app for the low-assurance certificate. I believe the authentication for it is done via PACEv2 (see EF.DIR). The signing and high-assurance certificate seem to lie in an undocumented AID that I will no be able to access until we reverse the APDUs the official middleware will be sending.

[frankmorgner]

If it's running on Windows, Linux or macOS, you can easily debug the commands sent to card... But be aware, that reverse engineering a card driver is very time consuming without the lack of documentation and detailed knowledge....

[craftbyte]

Actually, at least for authentication, it looks like the auth may be done with PACE. How would I go implementing that?

[frankmorgner]

Actually, at least for authentication, it looks like the auth may be done with PACE. How would I go implementing that?

For quick testing, you could use npa-tool --can=123456 -vvv. For integration with the card driver, you should use perform_pace(), which also sets up the SM channel if PACE is successful.

[craftbyte]

OK, I have now received the official specs after a long FOIA request debacle. This is everything the government got from NXP (as far as I know). I will not comment on the length or thoroughness of it. I shall try to implement a client soon and report back if I need any help. I will also look into translating the document if necessary

TS -slo eID - navodila za uporabo v02.pdf

[craftbyte]

Ok, looking promising. After running npa-tool with the following -t script:

00A40000023F00
00A4040C0AE828BD080F014E585031
00A4020C02001D
00A4020C0200A1
002281B60491022221
002A9E9A30768412320f7b0aa5812fce428dc4706b3cae50e02a64caa16a782249bfe8efc4b7ef1ccb126255d196047dfedf17a0a9
0

I get the following:

.\npa-tool.exe --can=XXXXXX -t nopin.txt
Established PACE channel with CAN.
Unencrypted C-APDU (7 bytes):
00A40000023F00
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (18 bytes):
6F108102002882013883023F008603FF FFFF
======================================================================
Unencrypted C-APDU (15 bytes):
00A4040C0AE828BD080F014E585031
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (0 bytes)
======================================================================
Unencrypted C-APDU (7 bytes):
00A4020C02001D
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (0 bytes)
======================================================================
Unencrypted C-APDU (7 bytes):
00A4020C0200A1
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (0 bytes)
======================================================================
Unencrypted C-APDU (9 bytes):
002281B60491022221
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (0 bytes)
======================================================================
Unencrypted C-APDU (53 bytes):
002A9E9A30768412320F7B0AA5812FCE 428DC4706B3CAE50E02A64CAA16A7822 49BFE8EFC4B7EF1CCB126255D196047D
FEDF17A0A9
Decrypted R-APDU sw1=90 sw2=00
Decrypted R-APDU response data (96 bytes):
C0A4DD4CD07728D7C3E4A31B9155468D CF96228626852BF22C6C83D1B154783E 0AFF601C4B73782A225515F0002AD3CC
83BA2921DCE37AB303BFE5FFA7E17215 7450CBEB5CF2128AC253E0A0FFF426AB A8DD23FA0791063AB110DE0D020477C5
======================================================================
Thanks for flying with ccid

I don't know how to validate the signature, but the certificate is here

[craftbyte]

Further investigation:

• Over a contact interface, PACE is not needed. The low-trust authentication certificate can be used in an unencrypted channel. The 0022... APDU has to be sent to select the private key. PACE can also be done over contact interface.
• Over an NFC interface, PACE is needed to read the user certificate and to sign with the low-trust cert.

Since PACE requires the CAN, it would be nice to check if we can determine if we are communicating over NFC. The card sends response 0x6982 (Security status not satisfied) if we are not using PACE when we need to.

I am also unable to access the actual signature and high-trust certificates, as the card replies with 0x6283. The app is also not listed in my EF.DIR. I have a suspicion that they provision these when you personalize the card with an activation code.

[frankmorgner]

Congrats!

Since PACE requires the CAN, it would be nice to check if we can determine if we are communicating over NFC. The card sends response 0x6982 (Security status not satisfied) if we are not using PACE when we need to.

You most likely can use the ATR to detect the contactless mode. Alternatively, if you reader supports the UID command, you can also use the presence of an UID to see if it is connected via NFC (reader->uid).

[craftbyte]

OK, the official software got released today and it seems to just be a localized version of the NXP IDProtect for Athena. Is there any existing support for these?

I am also reverse engineering the card activation procedure, which seems to be quite simple, is there interest to add support for that in OpenSC as well?

[fdelapena]

Regarding NXP IDProtect with LASER applet used in other countries, found this that could be useful: #1988 (comment)