[PATCH] support for Italian CNS

[ep]

This patch adds seemingly working support for the Italian CNS (eID and more) card.

[ep]

README and patches

[ep]

NOTE: if you test this, do not forget to edit opensc.conf and enable "itacns" for "builtin_emulators" in the "framework pkcs15" section.

[alonbl]

Is it ready for merge? No opened issues? Why did you not enable the driver is opensc.conf?

[ep]

Replying to alonbl:

Is it ready for merge? No opened issues? Why did you not enable the driver is opensc.conf?

I forgot that it can/should be enable in the default configuration; thanks for reminding me!

I'd like to get some more testing/reports, but I guess that I'd get them more easily if it's in trunk, and it should not hurt anyone. I'll post here an updated version with a couple of enhancements (PUK, more standard data objects, detection of the official ID card) and a couple of fixes (the configuration and PIN retries, as soon as I figure it out). That will be ready for merge, in my opinion.

Thanks!

[ep]

Updated patch

[ep]

itacns-0.2.tar.gz is ready for merge, IMO. No open issues that I could detect.

[ep]

Version 0.3, with Secure Messaging

[ep]

Version 0.3 has some more important changes, all related to the implementation of Secure Messaging; I'll soon post a message onto the mailing list rather than explain them here.

[ep]

Version 0.3 is being actively tested and developed by a team. Interested parties can download the latest version of the patches from the Mercurial repository at  http://itacns.corp.it/hg/itacns/ .

[martin]

Milestone 0.11.7 deleted

[martin]

In addition to the small things this patch does, it adds support for secure messaging, which design might not be the only and best solution.

[viktor.tarasov@…]

Martin Paljak wrote:
Can you have a look and see if:
a) parts of it can be integrated anyway
b) some of the code could be re-used for a better SM implementation
c) some parts of the design can be upgraded on the way

I take this ticket.

[viktor.tarasov@…]

I've been too optimistic, it'll be hardly possible to integrate these patchs without having CNS card .

I would like to do it in the two stages: first of all the support of CNS card without secure messaging; then some more general support of SM.

Afais, in the CNS card the SM protects qualified signature and associated PINs. So, at the first stage, the support of CNS card without Q-Sign key and SignPIN should be implemented.

Proposed patch make some touchs of the core sources, imho, not always justified; it uses deprecated PRKEY access; Sign PIN flags, defined in CNS emulator, imho, should be corrected... that's what I've seen at the first glance. It'll be difficult to make a changes to this patch without card.

So, I propose to postpone CNS ard support untill the better times.

[ep]

Replying to viktor.tarasov@…:

I've been too optimistic, it'll be hardly possible to integrate these patchs without having CNS card .

I do and I'm willing to do the work :)

I would like to do it in the two stages: first of all the support of CNS card without secure messaging; then some more general support of SM.

That's the path I took. I agree completely with your view.

Proposed patch make some touchs of the core sources, imho, not always justified;

IIRC, they were needed workarounds; I feel that we could at least conditionally include those of them that are really needed.

it uses deprecated PRKEY access; Sign PIN flags, defined in CNS emulator, imho, should be corrected... that's what I've seen at the first glance.

Please give me a pointer or two, if you have time. The PRKEY issue completely escapes me right now (couldn't dig up anything in the mailing list).

Otherwise, I'll try to keep the patches in sync with OpenSC.

Thanks!

[viktor.tarasov@…]

About PRKEY: I've seen in the patch a new SC_PKCS15_PRKEY_ACCESS_SIGN_WITH_DECRYPT flag, that I confounded with recently deprecated SC_PKCS15_CARD_FLAG_SIGN_WITH_DECRYPT .

About SignPIN flags: the both SignPIN and SignPUK have the SC_PKCS15_PIN_FLAG_UNBLOCKING_PIN flag.

[mike3050]

Replying to ep:

Replying to viktor.tarasov@…:

I've been too optimistic, it'll be hardly possible to integrate these  auto insurance quotes patchs without having CNS card .

I do and I'm willing to do the work :)

I would like to do it in the two stages: first of all the support of CNS card without secure messaging; then some more general support of SM.

That's the path I took. I agree completely with your view.

Proposed patch make some touchs of the core sources, imho, not always justified;

IIRC, they were needed workarounds; I feel that we could at least conditionally include those of them that are really needed.

it uses deprecated PRKEY access; Sign PIN flags, defined in CNS emulator, imho, should be corrected... that's what I've seen at the first glance.

Please give me a pointer or two, if you have time. The PRKEY issue completely escapes me right now (couldn't dig up anything in the mailing list).

Otherwise, I'll try to keep the patches in sync with OpenSC.

Thanks!

Thank you.

[ep]

The last patch is aligned with the current trunk.

[soujak]

Replying to ep:

The last patch is aligned with the current trunk.

Just thanks. I'm going to test it in the next weeks.

[ep]

Updated patch against current trunk.

[ep]

Updated; further clean-up performed.

[ep]

Cardholder name is now included in the PKCS #15 label

[LorenzoM]

Support for CNS seems to fails on certain cards. With my old (expired) CNS/CRS card from Regione Lombardia with ST mask test is ok:

lorenzo@castor:~$ pkcs11-tool --login --module /opt/opensc/usr/lib/pkcs11/opensc-pkcs11.so --test
Using slot 1 with a present token (0x1)
Logging in to "######## ######## (PIN CNS0)".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only RSA signatures)
  testing key 0 (CNS0) 
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
Verify (currently only for RSA):
  testing key 0 (CNS0)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
    MD5-RSA-PKCS: OK
    RIPEMD160-RSA-PKCS: OK
Unwrap: not implemented
Decryption (RSA)
  testing key 0 (CNS0)  -- can't be used to decrypt, skipping
No errors

With my new (current) card with Athena mask the test fails:

lorenzo@castor:~$ pkcs11-tool --login --module /opt/opensc/usr/lib/pkcs11/opensc-pkcs11.so --test
Using slot 1 with a present token (0x1)
Logging in to "####### ######## (PIN CNS0)".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only RSA signatures)
  testing key 0 (CNS0) 
error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)

Aborting.

Also, authentication to government websites with the new card and the opencs cryptographic module fails. I a unable to compare with the old card, since it is expired.

It seems there is something new and unsupported in the new card, since it works right with the official software in Windows, but it fails with the official bit4id library in linux. The old card used to work with the official bit4id library. Needless to say, technical support from Regione Lombardia was unable to help even with the official linux library.

[ep]

Hi there -- I've just seen your update to #235. My e-mail system had inadvertently thrown some messages into the Spam folder, including your updates to #177.

Have you tried to use OpenSC r4978 or later? You've probably run into the bug that was fixed in that changeset.

If you have already tried r4978 or later with no joy, then let me know. I have an Athena test card graciously donated by Aruba -- I'll re-test w/the latest updates and then ask you to retest with any updates I can make, or ask you for further details and/or logfiles if possible.

Thanks!

[LorenzoM]

Hi,

thanks for your reply!

The result above was obtained using RC2 release. Yesterday, after reading #177 I retested with latest trunk from SVN (r4992), but I still get CKR_GENERAL_ERROR with pkcs11-tool --test. Needless to say, also website authentication by pkcs#11 fails.

I'm quite new to OpenSC but I'm available to provide any information and testing that can be useful.

[ep]

I'm currently away from the office, but I'll re-test next week with the Athena ASEPCOS-based test card I have, and check the results.

In the meantime, if you have a dozen minutes to spare, it would be very helpful if you could do again the pkcs11-tool --test run, but enabling the generation of a detailed debug/log file. You can follow the directions in the last part of  http://www.opensc-project.org/opensc/wiki/ReportingBugs.

Beware that the log file will contain your PIN and, most likely, your personal data. You may want to change the PIN before testing and to clean up your personal data before sharing the generated log file.

Thanks!

[LorenzoM]

Log of pkcs11-tool -test failing with Regione Lombardia CRS card issued by Actalis

[LorenzoM]

I attached the requested  logfile. Drop me a line if you need further detail.

[ep]

Thanks!

May I ask you to share:

• the distribution you are using, and architecture (i386/amd64)
• the version of PCSC you are using (pcscd -v)
• the version of the ACS ACR38U driver that you are using (it is often found as /usr/lib64/pcsc/drivers/ACR38UDriver.bundle/Contents/Linux/ACR38UDriver or /usr/lib/pcsc/drivers/ACR38UDriver.bundle/Contents/Linux/ACR38UDriver; you may include a ls -l of that file as well if you can).

Thanks again!

[LorenzoM]

I'm using Debian Lenny 5.0.7 i386. Further detail below:

castor:/home/lorenzo# uname -a
Linux castor 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux
castor:/home/lorenzo# pcscd -v
pcsc-lite version 1.4.102.
Copyright (C) 1999-2002 by David Corcoran <corcoran@linuxnet.com>.
Copyright (C) 2001-2008 by Ludovic Rousseau <ludovic.rousseau@free.fr>.
Copyright (C) 2003-2004 by Damien Sauveron <sauveron@labri.fr>.
Report bugs to <muscle@lists.musclecard.com>.
Enabled features: Linux libhal usbdropdir=/usr/lib/pcsc/drivers confdir=/etc ipcdir=/var/run/pcscd
castor:/home/lorenzo# dpkg -l |grep acr38
ii  libacr38u   1.7.9-3   PC/SC driver for the ACR38U smart card reader

Thanks again for your collaboration.

[ep]

Thanks again.

Would you mind trying with the update ACR38 package from sid? It has solved a few issues for me. I'm thinking (after looking at Matteo Nastasi's issues as well) of uploading somewhere an "approved" lenny backport for those of us who are stuck with the ACR38 reader.

[LorenzoM]

Hi again, instead of risking dependency problems I rebuilt r4992 on a Debian Squeeze partition that I have on the same machine, so that libacr38u is version 1.7.10-1 (same as sid). Now I have pcsc-lite version 1.5.5.

Even with this setup I get the same error.

As I already pointed out, I think there is some change in the card implementation, since also the official linux library libbit4spki.so (and also others, like the one from DikeL) stopped working with the new card, while they used to be ok with the old card. Seems like official libraries for linux haven't been updated for a while, while Win32 official libraries (which are more up to date) work ok.

About backporting libacr38u for Lenny: Squeeze is going to be released in some weeks (hopefully), some maybe it's not worth the effort.

[ep]

I can confirm that there is a problem in the ACR38 driver. I prepared this  small patch that apparently solved the problem for me (and for Matteo as well). I guess the bug went unnoticed because earlier CNS cards based on ST Incard or Siemens operating systems worked with the T=0 protocol, while these Athena cards work with T=1.

If it is not a problem for you, you may want to try recompiling the ACR38 driver after applying the patch and see how it works for you.

I'd also like to bring this discussion to a more appropriate venue (it isn't a problem with OpenSC) but I can't really find one at this time, so if nobody minds and if it winds down to a close, I'd just keep it here.

[martin]

As a side note: for those who can't patch the reader driver for some reason, it is possible to force a certain card to use T=0 only. The ATR of the card needs to be listed like other similar cards in opensc.conf:

	card_atr 3b:fe:18:00:00:80:31:fe:45:80:31:80:66:40:90:a4:16:2a:00:83:01:90:00:e1 {
		force_protocol = t0;
	}

[ep]

Thanks for the heads-up: I, for one, had forgotten about this.

Still, this particular card - or at least the test card I have, with ATR 3b:df:18:00:81:31:fe:7d:00:6b:15:0c:01:80:01:01:01:43:4e:53:10:31:80:f9 - does not appear to work at all with T=0.

The CNS cards are only required to support T=1. I seem to recall that other CNS cards do work fine with T=0, but sadly this one doesn't seem to, at least with this reader (ACR38U, non-CCID version).

I'll try to contact the supplier about this matter; perhaps they can at least talk their reader distributor into providing "official" patched driver releases to the local governments that in turn prepare download pages and/or software kits for final users. (Both the Linux and the OS X drivers are affected by this issue.)

[LorenzoM]

I'll try and confirm ASAP.

In the meanwhile, can I suggest to report the issue and upload your patch  here, so that Debian (or Ubuntu) world can benefit from it?

[ep]

Thanks for your suggestion; I'll do so, still hoping that it can be integrated upstream.

By the way, I'd also like to drop the first line change in the patch. (Edit: it has already been dropped; the  patch has been updated and looks as intended, now.) The reader works even without it, I'm not sure it is correct, and I can't be unless I dig up some sufficiently accurate rendition of the ISO 7816 standard.

[LorenzoM]

I confirm that the problem was with the acr38 driver; everything works well with your patch.

Thanks much for your collaboration!