Best way to implement Italian CNS card_ctl function with SC_CARDCTL_GET_SERIALNR

[Roberto Resoli-2]

Hello,

I am referring to this post:
http://sourceforge.net/p/opensc/mailman/message/32982604/

I succeded in build and test the minidriver, but i need to refine the
implementation of the new itacns card_ctl  function (only for
SC_CARDCTL_GET_SERIALNR, atm).

A little preamble: itacns driver currently is more or less a wrapper for
implementing the CNS specification for some different underlying cards.

To my knowledge, these are some of the different CNS manufacturer -
opensc driver incarnations:

- Incard - incrypto34
- Siemens - cardos
- Athena - asepcos

The latter two are very widespread as there are used as European Health
Insurance Card in many italian Regions. I own currently a cardos one,
and waiting for a test sample of asepcos one.

According to CNS filesystem specification there is an EF "IDCarta" (16
bytes) which seems the best candidate for an interoperable serial number.

The file id is 1003 under DF 1000:

OpenSC [3F00]> cd 1000
OpenSC [3F00/1000]> cat 1003
00000000: 36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37 6042100941441607
OpenSC [3F00/1000]>

Which is the best way to extract this content? I guess that all I have
to do is a "select file" followed by a "read binary". Are there some
high level functions for that or it is better to send raw apdus?

bye,
rob


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Frank Morgner]

On Wednesday, November 05 at 03:50PM, Roberto Resoli wrote:

> Hello,
>
> I am referring to this post:
> http://sourceforge.net/p/opensc/mailman/message/32982604/
>
> I succeded in build and test the minidriver, but i need to refine the
> implementation of the new itacns card_ctl  function (only for
> SC_CARDCTL_GET_SERIALNR, atm).
>
> A little preamble: itacns driver currently is more or less a wrapper for
> implementing the CNS specification for some different underlying cards.
>
> To my knowledge, these are some of the different CNS manufacturer -
> opensc driver incarnations:
>
> - Incard - incrypto34
> - Siemens - cardos
> - Athena - asepcos
>
> The latter two are very widespread as there are used as European Health
> Insurance Card in many italian Regions. I own currently a cardos one,
> and waiting for a test sample of asepcos one.
>
> According to CNS filesystem specification there is an EF "IDCarta" (16
> bytes) which seems the best candidate for an interoperable serial number.
>
> The file id is 1003 under DF 1000:
>
> OpenSC [3F00]> cd 1000
> OpenSC [3F00/1000]> cat 1003
> 00000000: 36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37 6042100941441607
> OpenSC [3F00/1000]>

To my knowledge it is not very common to have an ASCII encoded ICCSN.
Did you check the Specification? There may also be a serial number in
EF.TokenInfo (It is printed with pkcs15-tool -D)

> Which is the best way to extract this content? I guess that all I have
> to do is a "select file" followed by a "read binary". Are there some
> high level functions for that or it is better to send raw apdus?

*If* you know that this is the right place to look, a plain
sc_read_binary is just fine. The card driver defines what to do with
SC_CARDCTL_GET_SERIALNR.

--
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Douglas E Engert]

There are 33 card-*.c drivers and only 22 reference SC_CARDCTL_GET_SERIALNR.
card-itacns.c is not one of them, and SC_CARDCTL_GET_SERIALNR (or a get_guid routine) is needed
for a card to work with Microsoft applications on Windows. So 22 cards won't work on Windows
with the minidriver.

[cardmod] pkcs15.c:2728:sc_pkcs15_get_object_guid: 'GET_SERIALNR' failed: -1408
#define SC_ERROR_NOT_SUPPORTED -1408

card-incrypto34.c does not support SC_CARDCTL_GET_SERIALNR, but card-cardos.c and
card-asepcos.c do. But these are not being used,  card-itacns.c is and it does not support
SC_CARDCTL_GET_SERIALNR.

The Microsoft code needs a GUID representing the card, (or the application on the card)
that does not change. Microsoft will read certificates and store them in the certificate store,
along with the GUID, so when a certificate is selected, a prompt can be issued to insert the card,
and the GUID is checked to make sure it is the correct card.

If you go with the "CNS application" serial number, as suggested by reading the "IDCarta"
that would work for any card supporting the CNS application. (A get_guid routine could also
be used, but this is only for the minidriver. This is similar to the PIV application that can
run on a dozen cards. The PIV specs does not define a serial number. The PIV reads an object (CHUID) off the card,
and uses the GUID or FASC-N in the CHUID to derive a serial number.)

This is starting to show the issues between supporting an application that can run on many cards,
vs supporting a specific card, or OS on a card.



On 11/5/2014 12:14 PM, Frank Morgner wrote:

> On Wednesday, November 05 at 03:50PM, Roberto Resoli wrote:
>> Hello,
>>
>> I am referring to this post:
>> http://sourceforge.net/p/opensc/mailman/message/32982604/
>>
>> I succeded in build and test the minidriver, but i need to refine the
>> implementation of the new itacns card_ctl  function (only for
>> SC_CARDCTL_GET_SERIALNR, atm).
>>
>> A little preamble: itacns driver currently is more or less a wrapper for
>> implementing the CNS specification for some different underlying cards.
>>
>> To my knowledge, these are some of the different CNS manufacturer -
>> opensc driver incarnations:
>>
>> - Incard - incrypto34
>> - Siemens - cardos
>> - Athena - asepcos
>>
>> The latter two are very widespread as there are used as European Health
>> Insurance Card in many italian Regions. I own currently a cardos one,
>> and waiting for a test sample of asepcos one.
>>
>> According to CNS filesystem specification there is an EF "IDCarta" (16
>> bytes) which seems the best candidate for an interoperable serial number.
>>
>> The file id is 1003 under DF 1000:
>>
>> OpenSC [3F00]> cd 1000
>> OpenSC [3F00/1000]> cat 1003
>> 00000000: 36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37 6042100941441607
>> OpenSC [3F00/1000]>
>
> To my knowledge it is not very common to have an ASCII encoded ICCSN.
> Did you check the Specification? There may also be a serial number in
> EF.TokenInfo (It is printed with pkcs15-tool -D)
>
>> Which is the best way to extract this content? I guess that all I have
>> to do is a "select file" followed by a "read binary". Are there some
>> high level functions for that or it is better to send raw apdus?
>
> *If* you know that this is the right place to look, a plain
> sc_read_binary is just fine. The card driver defines what to do with
> SC_CARDCTL_GET_SERIALNR.
>
>

>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05 novembre 2014 19:14:20 CET, Frank Morgner <[hidden email]> ha scritto:
>On Wednesday, November 05 at 03:50PM, Roberto Resoli wrote:
>> Hello,
>>
...

>> The file id is 1003 under DF 1000:
>>
>> OpenSC [3F00]> cd 1000
>> OpenSC [3F00/1000]> cat 1003
>> 00000000: 36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37
>6042100941441607
>> OpenSC [3F00/1000]>
>
>To my knowledge it is not very common to have an ASCII encoded ICCSN.
>Did you check the Specification?

Yes, it is in in italian language, and basically says that EF_ID_Carta follows Netlink specification, and:

Byte1: type of card (citizen) and distribution level (regional);
Byte 2,3,4: region code;
Byte 5: if CNS Is a National Health Card the value is greater or equal to 1.
Bytes 5-13: progressive number.
Remaining bytes are check digits

There is also a sample value for CNS "issued from Lombardia Region under SISS project".

Taken from "Chapter 4.2 ID_Carta" in this document:

http://www.agid.gov.it/sites/default/files/documentazione_trasparenza/filesystemcns_20131216.pdf

> There may also be a serial number in
>EF.TokenInfo (It is printed with pkcs15-tool -D)

will try that

>
>> Which is the best way to extract this content? I guess that all I
>have
>> to do is a "select file" followed by a "read binary". Are there some
>> high level functions for that or it is better to send raw apdus?
>
>*If* you know that this is the right place to look, a plain
>sc_read_binary is just fine. The card driver defines what to do with
>SC_CARDCTL_GET_SERIALNR.

Ok, Thanks.

rob


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05 novembre 2014 20:11:06 CET, Douglas E Engert <[hidden email]> ha scritto:
>There are 33 card-*.c drivers and only 22 reference
>SC_CARDCTL_GET_SERIALNR.
>card-itacns.c is not one of them, and SC_CARDCTL_GET_SERIALNR (or a
>get_guid routine) is needed
>for a card to work with Microsoft applications on Windows. So 22 cards
>won't work on Windows
>with the minidriver.

Yes, implementing that card_ctl function in a general manner, applicable to all cns, is the aim of my patch.

rob


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05/11/2014 20:34, Roberto Resoli ha scritto:

> Il 05 novembre 2014 19:14:20 CET, Frank Morgner <[hidden email]> ha scritto:
>> On Wednesday, November 05 at 03:50PM, Roberto Resoli wrote:
>>> Hello,
>>>
> ...
>>> The file id is 1003 under DF 1000:
>>>
>>> OpenSC [3F00]> cd 1000
>>> OpenSC [3F00/1000]> cat 1003
>>> 00000000: 36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37
>> 6042100941441607
>>> OpenSC [3F00/1000]>
>>
>> To my knowledge it is not very common to have an ASCII encoded ICCSN.
>> Did you check the Specification?
>
> Yes, it is in in italian language, and basically says that EF_ID_Carta follows Netlink specification, and:
>
> Byte1: type of card (citizen) and distribution level (regional);
> Byte 2,3,4: region code;
> Byte 5: if CNS Is a National Health Card the value is greater or equal to 1.
> Bytes 5-13: progressive number.
> Remaining bytes are check digits
>
> There is also a sample value for CNS "issued from Lombardia Region under SISS project".
>
> Taken from "Chapter 4.2 ID_Carta" in this document:
>
> http://www.agid.gov.it/sites/default/files/documentazione_trasparenza/filesystemcns_20131216.pdf
>
>> There may also be a serial number in
>> EF.TokenInfo (It is printed with pkcs15-tool -D)
>
> will try that

$ pkcs15-tool -D
Using reader with a card: ACS ACR38U 00 00
PKCS#15 Card [ROBERTO RESOLI]:
        Version        : 0
        Serial number  : 6042100941441607
        Manufacturer ID: IC: Infineon; mask: Siemens

I think we got the right candidate.

rob


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05/11/2014 20:11, Douglas E Engert ha scritto:
...
> card-incrypto34.c does not support SC_CARDCTL_GET_SERIALNR, but card-cardos.c and
> card-asepcos.c do. But these are not being used,  card-itacns.c is and it does not support
> SC_CARDCTL_GET_SERIALNR.

yes, forcing cardos driver on my cardos CNS works indeed:

opensc-tool -c cardos --serial
Using reader with a card: ACS ACR38U 00 00
21 14 E0 11 12 2B !....+

> The Microsoft code needs a GUID representing the card, (or the application on the card)
> that does not change. Microsoft will read certificates and store them in the certificate store,
> along with the GUID, so when a certificate is selected, a prompt can be issued to insert the card,
> and the GUID is checked to make sure it is the correct card.
>
> If you go with the "CNS application" serial number, as suggested by reading the "IDCarta"
> that would work for any card supporting the CNS application. (A get_guid routine could also
> be used, but this is only for the minidriver. This is similar to the PIV application that can
> run on a dozen cards. The PIV specs does not define a serial number. The PIV reads an object (CHUID) off the card,
> and uses the GUID or FASC-N in the CHUID to derive a serial number.)
>
> This is starting to show the issues between supporting an application that can run on many cards,
> vs supporting a specific card, or OS on a card.

Ok, will try to improve the patch right now; stay tuned ...

Thanks,
rob

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05/11/2014 21:06, Roberto Resoli ha scritto:
>> If you go with the "CNS application" serial number, as suggested by reading the "IDCarta"
>> >that would work for any card supporting the CNS application. (A get_guid routine could also
>> >be used, but this is only for the minidriver. This is similar to the PIV application that can
>> >run on a dozen cards. The PIV specs does not define a serial number. The PIV reads an object (CHUID) off the card,
>> >and uses the GUID or FASC-N in the CHUID to derive a serial number.)
>> >
>> >This is starting to show the issues between supporting an application that can run on many cards,
>> >vs supporting a specific card, or OS on a card.

> Ok, will try to improve the patch right now; stay tuned ...

Seems to work:

both with the Siemens CNS (Health Card)

$ opensc-tool --serial
Using reader with a card: ACS ACR38U 00 00
36 30 34 32 31 30 30 39 34 31 34 34 31 36 30 37 6042100941441607

and with another CNS I own, from Incard (not an Health Card):

$ opensc-tool --serial
Using reader with a card: ACS ACR38U 00 00
31 32 30 35 31 30 30 30 30 30 37 34 34 34 38 32 1205100000744482

I have submitted a pull request:

https://github.com/OpenSC/OpenSC/pull/321

rob

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Roberto Resoli-2]

Il 05 novembre 2014 20:11:06 CET, Douglas E Engert <[hidden email]> ha scritto:

>There are 33 card-*.c drivers and only 22 reference
>SC_CARDCTL_GET_SERIALNR.
>card-itacns.c is not one of them, and SC_CARDCTL_GET_SERIALNR (or a
>get_guid routine) is needed
>for a card to work with Microsoft applications on Windows. So 22 cards
>won't work on Windows
>with the minidriver.
>
>[cardmod] pkcs15.c:2728:sc_pkcs15_get_object_guid: 'GET_SERIALNR'
>failed: -1408
>#define SC_ERROR_NOT_SUPPORTED -1408
>
>card-incrypto34.c does not support SC_CARDCTL_GET_SERIALNR, but
>card-cardos.c and
>card-asepcos.c do. But these are not being used,  card-itacns.c is and
>it does not support
>SC_CARDCTL_GET_SERIALNR.

I have checked better, and it seems that latest Health Insurance CNS cards are not Athena - asepcos, manufacturer appears to be ST Microelectronics, with incrypto34 os.

I'm currently waiting for a sample, and rapidly checked a card owned by a collegue, and, coherently, it appears that itacns is currently relying on incrypto34 and cardos drivers only.

>The Microsoft code needs a GUID representing the card, (or the
>application on the card)
>that does not change. Microsoft will read certificates and store them
>in the certificate store,

Actually for having the certificate stored and flagged as "private key coupled", running "certuti -scinfo" is needed, clicking on "details" link in the certificate dialog and then clicking on the "install" button. I tested this procedure  successfully on W7 64bits, both with 32 and 64 bit minidriver.

I was unable to test on windows xp, because the "details" dialog was lacking an "install" button.  certutil has to be installed on xp, it is part of the w2k3 admin pack.

>along with the GUID, so when a certificate is selected, a prompt can be
>issued to insert the card,
>and the GUID is checked to make sure it is the correct card.

Yes, when the right card is inserted a prompt for providing PIN appears, and after that the usage of private key for authentication unlocked. Interestingly, it seems that "Microsoft Base Smart Card Provider" behaves better than other proprietary CSP i used in the past, when the card is removed; further authentication trials correctly trigger an "insert smart card" prompt.

>If you go with the "CNS application" serial number, as suggested by
>reading the "IDCarta"
>that would work for any card supporting the CNS application. (A
>get_guid routine could also
>be used, but this is only for the minidriver. This is similar to the
>PIV application that can
>run on a dozen cards. The PIV specs does not define a serial number.
>The PIV reads an object (CHUID) off the card,
>and uses the GUID or FASC-N in the CHUID to derive a serial number.)
>
>This is starting to show the issues between supporting an application
>that can run on many cards,
>vs supporting a specific card, or OS on a card.

Yes; in Italy Health Insurance CNS Cards are very common, and are deployed by Regions, but procured at national level. Any new procurement process typically brings in new card, new CA and new proprietary middleware, even if all cards support CNS specification.

Enabling full spectrum usage of OpenSC could  at last put an end to this Babel - like situation.

bye,
rob




------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel