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 |
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]> 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 |
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 |
In reply to this post by Frank Morgner
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 |
In reply to this post by Douglas E Engert
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 |
In reply to this post by 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 |
In reply to this post by Douglas E Engert
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 |
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 |
In reply to this post by Douglas E Engert
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 |
Free forum by Nabble | Edit this page |