Menu
▾
▴
opensc-devel — discussion of developement of OpenSC and related projects
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(26) |
Feb
(64) |
Mar
(78) |
Apr
(36) |
May
(51) |
Jun
(40) |
Jul
(43) |
Aug
(102) |
Sep
(50) |
Oct
(71) |
Nov
(42) |
Dec
(29) |
| 2014 |
Jan
(49) |
Feb
(52) |
Mar
(56) |
Apr
(30) |
May
(31) |
Jun
(52) |
Jul
(76) |
Aug
(19) |
Sep
(82) |
Oct
(95) |
Nov
(58) |
Dec
(76) |
| 2015 |
Jan
(135) |
Feb
(43) |
Mar
(47) |
Apr
(72) |
May
(59) |
Jun
(20) |
Jul
(17) |
Aug
(14) |
Sep
(34) |
Oct
(62) |
Nov
(48) |
Dec
(23) |
| 2016 |
Jan
(18) |
Feb
(55) |
Mar
(24) |
Apr
(20) |
May
(33) |
Jun
(29) |
Jul
(18) |
Aug
(15) |
Sep
(8) |
Oct
(21) |
Nov
(5) |
Dec
(23) |
| 2017 |
Jan
(3) |
Feb
|
Mar
(17) |
Apr
(4) |
May
|
Jun
(5) |
Jul
(1) |
Aug
(20) |
Sep
(17) |
Oct
(21) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(62) |
Feb
(4) |
Mar
(4) |
Apr
(20) |
May
(16) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(11) |
Nov
|
Dec
(9) |
| 2019 |
Jan
(1) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(5) |
Nov
|
Dec
(5) |
| 2020 |
Jan
(11) |
Feb
(14) |
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(14) |
Feb
(21) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(12) |
Dec
|
| 2023 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(8) |
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Douglas E E. <dee...@gm...> - 2015-11-10 14:53:51
|
You may also want to look at NIST 800-56A http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf "6 Key Agreement" In effect a PIV card has a static key pair. OpenSC derive is just enough to use the key from the card and ECC CDH http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf "A.5.2.1 ECDH with the PIV KMK" On 11/10/2015 6:10 AM, klc klc wrote: > Hi, > > I tried to derive key with opensc v14.0 pkcs11-tool on PIV card. > > First I generated ec key with openssl using these commands: > > * openssl ecparam -in secp384r1param.pem -genkey -noout -out secp384r1key.pem > * openssl ec -in secp384r1key.pem -out secp384r1key.der -pubout -outform der > * pkcs11-tool.exe --module opensc-pkcs11.dll --derive -l -pin #### -id 03 -i secp384r1key.der > > This gave me error: > > * Cannot open n: m > > Which basically says that it can't open the file. [origin: pkcs11-tool->derive_key()->BIO_read_filename(bio_in, opt_input)] > > I tried with pem format & it gave me error: Cannot read EC key from secp384r1.pem > > My question is > > * whether the format in which I am passing key to opensc is right? > * Is there anything else I am missing to provide as an input to tool? > * Is my operation correct? > > Basically I am trying to write my own application with help of OpenSC implementation to derive a key. Following is the overview of the process I am trying to implement: > > * Application will receive x & y coordinate for EC public key. > * Calculated EC key length with help of getEC_POINT() (modified received length as (length - 3) * 8 to adjust to EC key size (in this case 384 bits, I receive 51)). > * Generated eckey according to key length with EC_KEY_new by_curve_name(NID_secp384r1) function. > * Then called function EC_KEY_generate_key(eckey) function > * ecgroup = EC_KEY_get0_group(eckey) > * pub = EC_POINT_new(ecgroup) > * Converted coordinates to big number with BN_bin2bn() function. > * Computed octet string with EC_POINT_point2oct(ecgroup, pub, POINT_CONVERSION_UNCOMPRESSED, str_buf, str_buf_len, NULL). [Please note till this point execution goes successfully & I receive octet > string]. > * Then according to opensc derive_key() function I coded new key template & ECDH parameters. I tried both mechanisms: CKM_ECDH1_COFACTOR_DERIVE, CKM_ECDH1_DERIVE > * Till this point everything goes smoothly. > * When call to C_DeriveKey() is made I get error as "/Security status not satisfied/" (Login is performed right before derive operation). > * Transmitted APDU conforms to the NIST specification: 00 87 14 9D 67 7C 65 82 00 85 61 04 X-coordinate Y-coordinate (48 bytes each). > * Received APDU is 69 82. > > Also the private key field_length parameter in opensc is set to half of the EC key size. I get 192 bits for 384 bits EC key. Is this right? Is there any other function to retrieve actual value of EC > key; as now I am modifying received value to drive successful execution (source: pkcs15-sec.c) > > I tried to find help on this but to no avail. Can you please guide me on what might be the issue. > > PS: I generated EC keys through Charismathics security token configurator & performing derive operation with key Management key. > > Thanks, > K > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-11-10 13:38:29
|
On 11/10/2015 6:10 AM, klc klc wrote: > Hi, > > I tried to derive key with opensc v14.0 pkcs11-tool on PIV card. > > First I generated ec key with openssl using these commands: > > * openssl ecparam -in secp384r1param.pem -genkey -noout -out secp384r1key.pem > * openssl ec -in secp384r1key.pem -out secp384r1key.der -pubout -outform der I think that is OK. An openssl asn1parse of the secp384r1key.der would help. > * pkcs11-tool.exe --module opensc-pkcs11.dll --derive -l -pin #### -id 03 -i secp384r1key.der single letter options have a single - Multiple letter options have -- -pin should be --pin -id should be --id or -d You also need -m ECDH1-COFACTOR-DERIVE Or leave the pin out and let it prompt for the pin. This may be the problem of Cannot open n: m Can you use OpenSC-0.15.0 or the source from git? I have used two PIV cards A and B to demonstrate that the same secret material can be returned by OpenSC when card A is given card B's public key and card B is given card A's public key. The public key is really the SPKI from the certificate. I will post a test script after this. > > This gave me error: > > * Cannot open n: m > > Which basically says that it can't open the file. [origin: pkcs11-tool->derive_key()->BIO_read_filename(bio_in, opt_input)] > > I tried with pem format & it gave me error: Cannot read EC key from secp384r1.pem > > My question is > > * whether the format in which I am passing key to opensc is right? > * Is there anything else I am missing to provide as an input to tool? > * Is my operation correct? > > Basically I am trying to write my own application with help of OpenSC implementation to derive a key. Following is the overview of the process I am trying to implement: > > * Application will receive x & y coordinate for EC public key. > * Calculated EC key length with help of getEC_POINT() (modified received length as (length - 3) * 8 to adjust to EC key size (in this case 384 bits, I receive 51)). Not sure if this is correct. is 51 decimal or hex? > * Generated eckey according to key length with EC_KEY_new by_curve_name(NID_secp384r1) function. > * Then called function EC_KEY_generate_key(eckey) function > * ecgroup = EC_KEY_get0_group(eckey) > * pub = EC_POINT_new(ecgroup) > * Converted coordinates to big number with BN_bin2bn() function. > * Computed octet string with EC_POINT_point2oct(ecgroup, pub, POINT_CONVERSION_UNCOMPRESSED, str_buf, str_buf_len, NULL). [Please note till this point execution goes successfully & I receive octet > string]. > * Then according to opensc derive_key() function I coded new key template & ECDH parameters. I tried both mechanisms: CKM_ECDH1_COFACTOR_DERIVE, CKM_ECDH1_DERIVE > * Till this point everything goes smoothly. > * When call to C_DeriveKey() is made I get error as "/Security status not satisfied/" (Login is performed right before derive operation). > * Transmitted APDU conforms to the NIST specification: 00 87 14 9D 67 7C 65 82 00 85 61 04 X-coordinate Y-coordinate (48 bytes each). That sounds correct. > * Received APDU is 69 82. Do you have an opensc-debug.log showing the verify and derive APDUs and responses? > > Also the private key field_length parameter in opensc is set to half of the EC key size. I get 192 bits for 384 bits EC key. Is this right? Is there any other function to retrieve actual value of EC > key; as now I am modifying received value to drive successful execution (source: pkcs15-sec.c) > > I tried to find help on this but to no avail. Can you please guide me on what might be the issue. > > PS: I generated EC keys through Charismathics security token configurator & performing derive operation with key Management key. > > Thanks, > K > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: klc k. <klc...@gm...> - 2015-11-10 12:10:36
|
Hi, I tried to derive key with opensc v14.0 pkcs11-tool on PIV card. First I generated ec key with openssl using these commands: - openssl ecparam -in secp384r1param.pem -genkey -noout -out secp384r1key.pem - openssl ec -in secp384r1key.pem -out secp384r1key.der -pubout -outform der - pkcs11-tool.exe --module opensc-pkcs11.dll --derive -l -pin #### -id 03 -i secp384r1key.der This gave me error: - Cannot open n: m Which basically says that it can't open the file. [origin: pkcs11-tool->derive_key()->BIO_read_filename(bio_in, opt_input)] I tried with pem format & it gave me error: Cannot read EC key from secp384r1.pem My question is - whether the format in which I am passing key to opensc is right? - Is there anything else I am missing to provide as an input to tool? - Is my operation correct? Basically I am trying to write my own application with help of OpenSC implementation to derive a key. Following is the overview of the process I am trying to implement: - Application will receive x & y coordinate for EC public key. - Calculated EC key length with help of getEC_POINT() (modified received length as (length - 3) * 8 to adjust to EC key size (in this case 384 bits, I receive 51)). - Generated eckey according to key length with EC_KEY_new by_curve_name(NID_secp384r1) function. - Then called function EC_KEY_generate_key(eckey) function - ecgroup = EC_KEY_get0_group(eckey) - pub = EC_POINT_new(ecgroup) - Converted coordinates to big number with BN_bin2bn() function. - Computed octet string with EC_POINT_point2oct(ecgroup, pub, POINT_CONVERSION_UNCOMPRESSED, str_buf, str_buf_len, NULL). [Please note till this point execution goes successfully & I receive octet string]. - Then according to opensc derive_key() function I coded new key template & ECDH parameters. I tried both mechanisms: CKM_ECDH1_COFACTOR_DERIVE, CKM_ECDH1_DERIVE - Till this point everything goes smoothly. - When call to C_DeriveKey() is made I get error as "*Security status not satisfied*" (Login is performed right before derive operation). - Transmitted APDU conforms to the NIST specification: 00 87 14 9D 67 7C 65 82 00 85 61 04 X-coordinate Y-coordinate (48 bytes each). - Received APDU is 69 82. Also the private key field_length parameter in opensc is set to half of the EC key size. I get 192 bits for 384 bits EC key. Is this right? Is there any other function to retrieve actual value of EC key; as now I am modifying received value to drive successful execution (source: pkcs15-sec.c) I tried to find help on this but to no avail. Can you please guide me on what might be the issue. PS: I generated EC keys through Charismathics security token configurator & performing derive operation with key Management key. Thanks, K |
|
From: Ferdinand R. <ra...@we...> - 2015-11-10 05:20:47
|
Ok. I will investigate and report back in a couple of days. Ferdinand On 11/09/2015 14:36 AM, Andreas Schwier <and...@ca...> wrote: > Hi Ferdinand, > > I can't see any interaction with the card other than using the random > number generator (00 84 00 00 APDUs in the log). I'm not sure what > Thunderbird is trying to do. > > > > On 11/09/2015 09:51 AM, Ferdinand Rau wrote: >> Dear Andreas, >> >> Please find here the requested output of OpenSC: >> https://www.dropbox.com/s/9boccale15atwkd/OPENSC_DEBUG.txt.zip?dl=1 >> (The file was too large for direct mailing) >> >> It was recorded with OPENSC_DEBUG=9 during the following actions: >> Starting Thunderbird, connecting the reader, inserting the smart card, trying to send an encrypted e-mail, waiting for error message, killing Thunderbird. >> >> Note that with OPENSC_DEBUG set to 9, Thunderbird freezes before presenting the previously mentioned error message. It may be related to the enormous 500000 lines of DEBUG output OpenSC had to process :-) >> I hope the log file is helpful anyway. >> >> I have had issues with this particular card reader and CTAPI. If there is no other way to make this work, I can still try the sc-hsm-embedded alternative, but currently, I prefer to stay with pcscd >> >> Best, >> Ferdinand >> >> >> >> On 11/08/2015 10:21 PM, Andreas Schwier <and...@ca...> wrote: >>> Hi Ferdinand, >>> >>> can you set OPENSC_DEBUG=9 so we can see what is going on ? >>> >>> As an alternative you could try [1], which has been tested with D-Trust >>> 3.0 cards. >>> >>> Andreas >>> >>> [1] https://github.com/CardContact/sc-hsm-embedded/wiki/PKCS11 >>> >>> On 11/08/2015 09:08 PM, Ferdinand Rau wrote: >>>> Dear all, >>>> >>>> I am trying to get PDF signatures to work with LibreOffice 5.0 and my D-TRUST card 3.0, which requires a properly set up Mozilla NSS, which in turn requires OpenSC. I access the card via an USB smart card reader "ReinerSCT cyberJack RFID komfort" on Debian Jessie Linux with OpenSC 0.15.0. >>>> The card is listed here, but not explicitly marked as supported: https://github.com/OpenSC/OpenSC/wiki/German-ID-Cards >>>> >>>> The card is (probably) a Starcos 3.4 type card, therefore, I compiled OpenSC 0.15.0 with the following patch: >>>> https://github.com/OpenSC/OpenSC/pull/357 >>>> >>>> The result is as follows: >>>> 1. I can see the certificates on the card in Mozilla NSS after entering my PIN number on the reader's pinpad. >>>> >>>> 2. I can select a certificate for signing in LibreOffice. Then, I am asked for my PIN both in a dialog on screen and again on the reader's pinpad. The reader's display says "PIN correct" and there is no error message, but no signature is applied to the document. >>>> >>>> 3. Alternatively, I tried signing an e-mail in Thunderbird. The result is slightly different: When sending the e-mail, I am prompted to enter my PIN on the reader's pinpad. The reader's display says "PIN correct", but the signing fails with the following error message: "Sending message failed. You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroups Account Settings, or the certificate has expired." Needless to say, the certificate has not expired. >>>> >>>> Please find below the output of serveral common commands. Could someone please confirm that >>>> a) the card suitable for this kind of digital signatures in principle >>>> b) the card is not supposed to work with OpenSC 0.15.0 without the aforementioned patch >>>> c) the card is supposed to work with OpenSC 0.15.0 with the patch and all future versions including the patch >>>> >>>> If someone can help with the troubleshooting, that would be awesome. Just getting definitve answers to the above a),b),c) would be a real good starting point, though. >>>> >>>> Best regards, and thanks in advance, >>>> Ferdinand >>>> >>>> >>>>> $ opensc-tool -i >>>>> OpenSC 0.15.0 [gcc 4.9.2] >>>>> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) >>>> >>>> ---------------------- >>>> >>>>> $ opensc-tool --list-readers >>>>> # Detected readers (pcsc) >>>>> Nr. Card Features Name >>>>> 0 Yes PIN pad REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> >>>> ---------------------- >>>> >>>>> $ opensc-tool --name >>>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> STARCOS SPK 3.4 >>>> >>>> ---------------------- >>>> >>>>> $ opensc-tool --atr >>>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61 >>>> >>>> ---------------------- >>>> >>>>> $ pkcs11-tool --list-slots >>>>> Available slots: >>>>> Slot 0 (0xffffffff): Virtual hotplug slot >>>>> (empty) >>>>> Slot 1 (0x1): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> token label : D-TRUST Card V3.0 standard 2ga ( >>>>> token manufacturer : D-TRUST GmbH (C) >>>>> token model : PKCS#15 >>>>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>>>> hardware version : 0.0 >>>>> firmware version : 0.0 >>>>> serial num : >>>>> Slot 2 (0x2): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> token label : D-TRUST Card V3.0 standard 2ga ( >>>>> token manufacturer : D-TRUST GmbH (C) >>>>> token model : PKCS#15 >>>>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>>>> hardware version : 0.0 >>>>> firmware version : 0.0 >>>>> serial num : >>>> >>>> ---------------------- >>>> >>>>> $ pkcs11-tool --list-objects >>>>> Using slot 1 with a present token (0x1) >>>>> Public Key Object; RSA 2048 bits >>>>> label: D-TRUST Authentication Key >>>>> ID: 11 >>>>> Usage: encrypt, verify, wrap >>>>> Certificate Object, type = X.509 cert >>>>> label: D-TRUST Authentication Key >>>>> ID: 11 >>>>> Certificate Object, type = X.509 cert >>>>> label: >>>>> ID: 2d333730343631303735333036303830313534 >>>>> Public Key Object; RSA 2048 bits >>>>> label: >>>>> ID: 2d333730343631303735333036303830313534 >>>>> Usage: encrypt, verify >>>>> Certificate Object, type = X.509 cert >>>>> label: >>>>> ID: 2d32303036363939383139343731343534393238 >>>>> Public Key Object; RSA 2048 bits >>>>> label: >>>>> ID: 2d32303036363939383139343731343534393238 >>>>> Usage: encrypt, verify >>>> >>>> ---------------------- >>>> >>>>> $ pkcs15-tool -D >>>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> PKCS#15 Card [D-TRUST Card V3.0 standard 2ga]: >>>>> Version : 0 >>>>> Serial number : >>>>> Manufacturer ID: D-TRUST GmbH (C) >>>>> Flags : Login required, EID compliant >>>>> >>>>> PIN [PIN1] >>>>> Object Flags : [0x3], private, modifiable >>>>> Auth ID : 03 >>>>> ID : 01 >>>>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>>>> Length : min_len:6, max_len:8, stored_len:8 >>>>> Pad char : 0xFF >>>>> Reference : 1 (0x01) >>>>> Type : iso 9664-1 >>>>> Path : a000000063504b43532d3135:: >>>>> >>>>> PIN [PUK1] >>>>> Object Flags : [0x3], private, modifiable >>>>> ID : 03 >>>>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>>>> Length : min_len:8, max_len:8, stored_len:8 >>>>> Pad char : 0xFF >>>>> Reference : 1 (0x01) >>>>> Type : iso 9664-1 >>>>> Path : a000000063504b43532d3135:: >>>>> >>>>> PIN [PIN2] >>>>> Object Flags : [0x3], private, modifiable >>>>> Auth ID : 04 >>>>> ID : 02 >>>>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>>>> Length : min_len:6, max_len:8, stored_len:8 >>>>> Pad char : 0xFF >>>>> Reference : 129 (0x81) >>>>> Type : iso 9664-1 >>>>> Path : 3f000604 >>>>> >>>>> PIN [PUK2] >>>>> Object Flags : [0x3], private, modifiable >>>>> ID : 04 >>>>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>>>> Length : min_len:8, max_len:8, stored_len:8 >>>>> Pad char : 0xFF >>>>> Reference : 129 (0x81) >>>>> Type : iso 9664-1 >>>>> Path : 3f000604 >>>>> >>>>> Private RSA Key [D-TRUST Authentication Key] >>>>> Object Flags : [0x1], private >>>>> Usage : [0x2E], decrypt, sign, signRecover, unwrap >>>>> Access Flags : [0x0] >>>>> ModLength : 2048 >>>>> Key ref : 1 (0x1) >>>>> Native : yes >>>>> Path : a000000063504b43532d3135::3f000fff0f01 >>>>> Auth ID : 01 >>>>> ID : 11 >>>>> MD:guid : {a8abd012-eb59-b862-bf9b-c1ea443d2f35} >>>>> :cmap flags : 0x0 >>>>> :sign : 0 >>>>> :key-exchange: 0 >>>>> >>>>> Private RSA Key [SigG Signature Key] >>>>> Object Flags : [0x1], private >>>>> Usage : [0x200], nonRepudiation >>>>> Access Flags : [0x0] >>>>> ModLength : 2048 >>>>> Key ref : 4 (0x4) >>>>> Native : yes >>>>> Path : a000000063504b43532d3135::3f0006040f01 >>>>> Auth ID : 02 >>>>> ID : 12 >>>>> MD:guid : {c4f87a62-90ae-e1ac-fc1f-26083974ce94} >>>>> :cmap flags : 0x0 >>>>> :sign : 0 >>>>> :key-exchange: 0 >>>>> >>>>> Public RSA Key [D-TRUST Authentication Key] >>>>> Object Flags : [0x2], modifiable >>>>> Usage : [0xD1], encrypt, wrap, verify, verifyRecover >>>>> Access Flags : [0x0] >>>>> ModLength : 2048 >>>>> Key ref : 1 (0x1) >>>>> Native : yes >>>>> Path : a000000063504b43532d3135::3f000fff0e01 >>>>> Auth ID : 01 >>>>> ID : 11 >>>>> >>>>> Public RSA Key [SigG Signature Key] >>>>> Object Flags : [0x2], modifiable >>>>> Usage : [0x204], sign, nonRepudiation >>>>> Access Flags : [0x0] >>>>> ModLength : 2048 >>>>> Key ref : 4 (0x4) >>>>> Native : yes >>>>> Path : a000000063504b43532d3135::3f0006040e01 >>>>> Auth ID : 02 >>>>> ID : 12 >>>>> >>>>> X.509 Certificate [D-TRUST Authentication Key] >>>>> Object Flags : [0x2], modifiable >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c100 >>>>> ID : 11 >>>>> Encoded serial : 02 03 168A81 >>>>> X.509 Certificate [SigG Signature Key] >>>>> Object Flags : [0x2], modifiable >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c103 >>>>> ID : 12 >>>>> Encoded serial : 02 03 168A82 >>>>> X.509 Certificate [] >>>>> Object Flags : [0x0] >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c102 >>>>> ID : 2d32303036363939383139343731343534393238 >>>>> Encoded serial : 02 03 030E96 >>>>> X.509 Certificate [] >>>>> Object Flags : [0x0] >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c101 >>>>> ID : 2d333730343631303735333036303830313534 >>>>> Encoded serial : 02 03 097D43 >>>>> X.509 Certificate [] >>>>> Object Flags : [0x0] >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c105 >>>>> ID : 37353738323838313038333736373637303437 >>>>> Encoded serial : 02 03 159923 >>>>> X.509 Certificate [] >>>>> Object Flags : [0x0] >>>>> Authority : no >>>>> Path : a000000063504b43532d3135::3f001501c104 >>>>> ID : 38323832353936323735353833303736353131 >>>>> Encoded serial : 02 03 159924 >>>> >>>> ---------------------- >>>> >>>>> $ pcsc_scan >>>>> PC/SC device scanner >>>>> V 1.4.23 (c) 2001-2011, Ludovic Rousseau <lud...@fr...> >>>>> Compiled with PC/SC lite version: 1.8.11 >>>>> Using reader plug'n play mechanism >>>>> Scanning present readers... >>>>> 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> >>>>> Sat Nov 7 01:39:47 2015 >>>>> Reader 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>>> Card state: Card inserted, >>>>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>>> >>>>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>>> + TS = 3B --> Direct Convention >>>>> + T0 = D8, Y(1): 1101, K: 8 (historical bytes) >>>>> TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU >>>>> 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s >>>>> TC(1) = FF --> Extra guard time: 255 (special value) >>>>> TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 >>>>> ----- >>>>> TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 >>>>> ----- >>>>> TA(3) = FE --> IFSC: 254 >>>>> TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5 >>>>> TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following >>>>> ----- >>>>> TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V >>>>> + Historical bytes: 80 64 04 1A B4 03 81 05 >>>>> Category indicator byte: 80 (compact TLV data object) >>>>> Tag: 6, len: 4 (pre-issuing data) >>>>> Data: 04 1A B4 03 >>>>> Tag: 8, len: 1 (status indicator) >>>>> LCS (life card cycle): 05 >>>>> + TCK = 61 (correct checksum) >>>>> >>>>> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): >>>>> 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>>> D-Trust multicard advanced 3.1 >>>>> German public health insurance card ("Gesundheitskarte"), issuer SBK "Siemens Betriebskrankenkasse" >>>> >>>> Note: This is not fully correct. This type of card is used for the German health insurance, but also for other uses, such as my QES signautre card. The name is incorrectly hardcoded in the list that ships with pcsc_scan. >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Opensc-devel mailing list >>>> Ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> >> >> >> ------------------------------------------------------------------------------ >> Presto, an open source distributed SQL query engine for big data, initially >> developed by Facebook, enables you to easily query your data on Hadoop in a >> more interactive manner. Teradata is also now providing full enterprise >> support for Presto. Download a free open source copy now. >> http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel |
|
From: Andreas S. <and...@ca...> - 2015-11-09 13:36:23
|
Hi Ferdinand, I can't see any interaction with the card other than using the random number generator (00 84 00 00 APDUs in the log). I'm not sure what Thunderbird is trying to do. On 11/09/2015 09:51 AM, Ferdinand Rau wrote: > Dear Andreas, > > Please find here the requested output of OpenSC: > https://www.dropbox.com/s/9boccale15atwkd/OPENSC_DEBUG.txt.zip?dl=1 > (The file was too large for direct mailing) > > It was recorded with OPENSC_DEBUG=9 during the following actions: > Starting Thunderbird, connecting the reader, inserting the smart card, trying to send an encrypted e-mail, waiting for error message, killing Thunderbird. > > Note that with OPENSC_DEBUG set to 9, Thunderbird freezes before presenting the previously mentioned error message. It may be related to the enormous 500000 lines of DEBUG output OpenSC had to process :-) > I hope the log file is helpful anyway. > > I have had issues with this particular card reader and CTAPI. If there is no other way to make this work, I can still try the sc-hsm-embedded alternative, but currently, I prefer to stay with pcscd > > Best, > Ferdinand > > > > On 11/08/2015 10:21 PM, Andreas Schwier <and...@ca...> wrote: >> Hi Ferdinand, >> >> can you set OPENSC_DEBUG=9 so we can see what is going on ? >> >> As an alternative you could try [1], which has been tested with D-Trust >> 3.0 cards. >> >> Andreas >> >> [1] https://github.com/CardContact/sc-hsm-embedded/wiki/PKCS11 >> >> On 11/08/2015 09:08 PM, Ferdinand Rau wrote: >>> Dear all, >>> >>> I am trying to get PDF signatures to work with LibreOffice 5.0 and my D-TRUST card 3.0, which requires a properly set up Mozilla NSS, which in turn requires OpenSC. I access the card via an USB smart card reader "ReinerSCT cyberJack RFID komfort" on Debian Jessie Linux with OpenSC 0.15.0. >>> The card is listed here, but not explicitly marked as supported: https://github.com/OpenSC/OpenSC/wiki/German-ID-Cards >>> >>> The card is (probably) a Starcos 3.4 type card, therefore, I compiled OpenSC 0.15.0 with the following patch: >>> https://github.com/OpenSC/OpenSC/pull/357 >>> >>> The result is as follows: >>> 1. I can see the certificates on the card in Mozilla NSS after entering my PIN number on the reader's pinpad. >>> >>> 2. I can select a certificate for signing in LibreOffice. Then, I am asked for my PIN both in a dialog on screen and again on the reader's pinpad. The reader's display says "PIN correct" and there is no error message, but no signature is applied to the document. >>> >>> 3. Alternatively, I tried signing an e-mail in Thunderbird. The result is slightly different: When sending the e-mail, I am prompted to enter my PIN on the reader's pinpad. The reader's display says "PIN correct", but the signing fails with the following error message: "Sending message failed. You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroups Account Settings, or the certificate has expired." Needless to say, the certificate has not expired. >>> >>> Please find below the output of serveral common commands. Could someone please confirm that >>> a) the card suitable for this kind of digital signatures in principle >>> b) the card is not supposed to work with OpenSC 0.15.0 without the aforementioned patch >>> c) the card is supposed to work with OpenSC 0.15.0 with the patch and all future versions including the patch >>> >>> If someone can help with the troubleshooting, that would be awesome. Just getting definitve answers to the above a),b),c) would be a real good starting point, though. >>> >>> Best regards, and thanks in advance, >>> Ferdinand >>> >>> >>>> $ opensc-tool -i >>>> OpenSC 0.15.0 [gcc 4.9.2] >>>> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) >>> >>> ---------------------- >>> >>>> $ opensc-tool --list-readers >>>> # Detected readers (pcsc) >>>> Nr. Card Features Name >>>> 0 Yes PIN pad REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> >>> ---------------------- >>> >>>> $ opensc-tool --name >>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> STARCOS SPK 3.4 >>> >>> ---------------------- >>> >>>> $ opensc-tool --atr >>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61 >>> >>> ---------------------- >>> >>>> $ pkcs11-tool --list-slots >>>> Available slots: >>>> Slot 0 (0xffffffff): Virtual hotplug slot >>>> (empty) >>>> Slot 1 (0x1): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> token label : D-TRUST Card V3.0 standard 2ga ( >>>> token manufacturer : D-TRUST GmbH (C) >>>> token model : PKCS#15 >>>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>>> hardware version : 0.0 >>>> firmware version : 0.0 >>>> serial num : >>>> Slot 2 (0x2): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> token label : D-TRUST Card V3.0 standard 2ga ( >>>> token manufacturer : D-TRUST GmbH (C) >>>> token model : PKCS#15 >>>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>>> hardware version : 0.0 >>>> firmware version : 0.0 >>>> serial num : >>> >>> ---------------------- >>> >>>> $ pkcs11-tool --list-objects >>>> Using slot 1 with a present token (0x1) >>>> Public Key Object; RSA 2048 bits >>>> label: D-TRUST Authentication Key >>>> ID: 11 >>>> Usage: encrypt, verify, wrap >>>> Certificate Object, type = X.509 cert >>>> label: D-TRUST Authentication Key >>>> ID: 11 >>>> Certificate Object, type = X.509 cert >>>> label: >>>> ID: 2d333730343631303735333036303830313534 >>>> Public Key Object; RSA 2048 bits >>>> label: >>>> ID: 2d333730343631303735333036303830313534 >>>> Usage: encrypt, verify >>>> Certificate Object, type = X.509 cert >>>> label: >>>> ID: 2d32303036363939383139343731343534393238 >>>> Public Key Object; RSA 2048 bits >>>> label: >>>> ID: 2d32303036363939383139343731343534393238 >>>> Usage: encrypt, verify >>> >>> ---------------------- >>> >>>> $ pkcs15-tool -D >>>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> PKCS#15 Card [D-TRUST Card V3.0 standard 2ga]: >>>> Version : 0 >>>> Serial number : >>>> Manufacturer ID: D-TRUST GmbH (C) >>>> Flags : Login required, EID compliant >>>> >>>> PIN [PIN1] >>>> Object Flags : [0x3], private, modifiable >>>> Auth ID : 03 >>>> ID : 01 >>>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>>> Length : min_len:6, max_len:8, stored_len:8 >>>> Pad char : 0xFF >>>> Reference : 1 (0x01) >>>> Type : iso 9664-1 >>>> Path : a000000063504b43532d3135:: >>>> >>>> PIN [PUK1] >>>> Object Flags : [0x3], private, modifiable >>>> ID : 03 >>>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>>> Length : min_len:8, max_len:8, stored_len:8 >>>> Pad char : 0xFF >>>> Reference : 1 (0x01) >>>> Type : iso 9664-1 >>>> Path : a000000063504b43532d3135:: >>>> >>>> PIN [PIN2] >>>> Object Flags : [0x3], private, modifiable >>>> Auth ID : 04 >>>> ID : 02 >>>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>>> Length : min_len:6, max_len:8, stored_len:8 >>>> Pad char : 0xFF >>>> Reference : 129 (0x81) >>>> Type : iso 9664-1 >>>> Path : 3f000604 >>>> >>>> PIN [PUK2] >>>> Object Flags : [0x3], private, modifiable >>>> ID : 04 >>>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>>> Length : min_len:8, max_len:8, stored_len:8 >>>> Pad char : 0xFF >>>> Reference : 129 (0x81) >>>> Type : iso 9664-1 >>>> Path : 3f000604 >>>> >>>> Private RSA Key [D-TRUST Authentication Key] >>>> Object Flags : [0x1], private >>>> Usage : [0x2E], decrypt, sign, signRecover, unwrap >>>> Access Flags : [0x0] >>>> ModLength : 2048 >>>> Key ref : 1 (0x1) >>>> Native : yes >>>> Path : a000000063504b43532d3135::3f000fff0f01 >>>> Auth ID : 01 >>>> ID : 11 >>>> MD:guid : {a8abd012-eb59-b862-bf9b-c1ea443d2f35} >>>> :cmap flags : 0x0 >>>> :sign : 0 >>>> :key-exchange: 0 >>>> >>>> Private RSA Key [SigG Signature Key] >>>> Object Flags : [0x1], private >>>> Usage : [0x200], nonRepudiation >>>> Access Flags : [0x0] >>>> ModLength : 2048 >>>> Key ref : 4 (0x4) >>>> Native : yes >>>> Path : a000000063504b43532d3135::3f0006040f01 >>>> Auth ID : 02 >>>> ID : 12 >>>> MD:guid : {c4f87a62-90ae-e1ac-fc1f-26083974ce94} >>>> :cmap flags : 0x0 >>>> :sign : 0 >>>> :key-exchange: 0 >>>> >>>> Public RSA Key [D-TRUST Authentication Key] >>>> Object Flags : [0x2], modifiable >>>> Usage : [0xD1], encrypt, wrap, verify, verifyRecover >>>> Access Flags : [0x0] >>>> ModLength : 2048 >>>> Key ref : 1 (0x1) >>>> Native : yes >>>> Path : a000000063504b43532d3135::3f000fff0e01 >>>> Auth ID : 01 >>>> ID : 11 >>>> >>>> Public RSA Key [SigG Signature Key] >>>> Object Flags : [0x2], modifiable >>>> Usage : [0x204], sign, nonRepudiation >>>> Access Flags : [0x0] >>>> ModLength : 2048 >>>> Key ref : 4 (0x4) >>>> Native : yes >>>> Path : a000000063504b43532d3135::3f0006040e01 >>>> Auth ID : 02 >>>> ID : 12 >>>> >>>> X.509 Certificate [D-TRUST Authentication Key] >>>> Object Flags : [0x2], modifiable >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c100 >>>> ID : 11 >>>> Encoded serial : 02 03 168A81 >>>> X.509 Certificate [SigG Signature Key] >>>> Object Flags : [0x2], modifiable >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c103 >>>> ID : 12 >>>> Encoded serial : 02 03 168A82 >>>> X.509 Certificate [] >>>> Object Flags : [0x0] >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c102 >>>> ID : 2d32303036363939383139343731343534393238 >>>> Encoded serial : 02 03 030E96 >>>> X.509 Certificate [] >>>> Object Flags : [0x0] >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c101 >>>> ID : 2d333730343631303735333036303830313534 >>>> Encoded serial : 02 03 097D43 >>>> X.509 Certificate [] >>>> Object Flags : [0x0] >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c105 >>>> ID : 37353738323838313038333736373637303437 >>>> Encoded serial : 02 03 159923 >>>> X.509 Certificate [] >>>> Object Flags : [0x0] >>>> Authority : no >>>> Path : a000000063504b43532d3135::3f001501c104 >>>> ID : 38323832353936323735353833303736353131 >>>> Encoded serial : 02 03 159924 >>> >>> ---------------------- >>> >>>> $ pcsc_scan >>>> PC/SC device scanner >>>> V 1.4.23 (c) 2001-2011, Ludovic Rousseau <lud...@fr...> >>>> Compiled with PC/SC lite version: 1.8.11 >>>> Using reader plug'n play mechanism >>>> Scanning present readers... >>>> 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> >>>> Sat Nov 7 01:39:47 2015 >>>> Reader 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>>> Card state: Card inserted, >>>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>> >>>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>> + TS = 3B --> Direct Convention >>>> + T0 = D8, Y(1): 1101, K: 8 (historical bytes) >>>> TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU >>>> 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s >>>> TC(1) = FF --> Extra guard time: 255 (special value) >>>> TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 >>>> ----- >>>> TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 >>>> ----- >>>> TA(3) = FE --> IFSC: 254 >>>> TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5 >>>> TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following >>>> ----- >>>> TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V >>>> + Historical bytes: 80 64 04 1A B4 03 81 05 >>>> Category indicator byte: 80 (compact TLV data object) >>>> Tag: 6, len: 4 (pre-issuing data) >>>> Data: 04 1A B4 03 >>>> Tag: 8, len: 1 (status indicator) >>>> LCS (life card cycle): 05 >>>> + TCK = 61 (correct checksum) >>>> >>>> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): >>>> 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>>> D-Trust multicard advanced 3.1 >>>> German public health insurance card ("Gesundheitskarte"), issuer SBK "Siemens Betriebskrankenkasse" >>> >>> Note: This is not fully correct. This type of card is used for the German health insurance, but also for other uses, such as my QES signautre card. The name is incorrectly hardcoded in the list that ships with pcsc_scan. >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Opensc-devel mailing list >>> Ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > ------------------------------------------------------------------------------ > Presto, an open source distributed SQL query engine for big data, initially > developed by Facebook, enables you to easily query your data on Hadoop in a > more interactive manner. Teradata is also now providing full enterprise > support for Presto. Download a free open source copy now. > http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Ferdinand R. <ra...@we...> - 2015-11-09 08:51:35
|
Dear Andreas, Please find here the requested output of OpenSC: https://www.dropbox.com/s/9boccale15atwkd/OPENSC_DEBUG.txt.zip?dl=1 (The file was too large for direct mailing) It was recorded with OPENSC_DEBUG=9 during the following actions: Starting Thunderbird, connecting the reader, inserting the smart card, trying to send an encrypted e-mail, waiting for error message, killing Thunderbird. Note that with OPENSC_DEBUG set to 9, Thunderbird freezes before presenting the previously mentioned error message. It may be related to the enormous 500000 lines of DEBUG output OpenSC had to process :-) I hope the log file is helpful anyway. I have had issues with this particular card reader and CTAPI. If there is no other way to make this work, I can still try the sc-hsm-embedded alternative, but currently, I prefer to stay with pcscd Best, Ferdinand On 11/08/2015 10:21 PM, Andreas Schwier <and...@ca...> wrote: > Hi Ferdinand, > > can you set OPENSC_DEBUG=9 so we can see what is going on ? > > As an alternative you could try [1], which has been tested with D-Trust > 3.0 cards. > > Andreas > > [1] https://github.com/CardContact/sc-hsm-embedded/wiki/PKCS11 > > On 11/08/2015 09:08 PM, Ferdinand Rau wrote: >> Dear all, >> >> I am trying to get PDF signatures to work with LibreOffice 5.0 and my D-TRUST card 3.0, which requires a properly set up Mozilla NSS, which in turn requires OpenSC. I access the card via an USB smart card reader "ReinerSCT cyberJack RFID komfort" on Debian Jessie Linux with OpenSC 0.15.0. >> The card is listed here, but not explicitly marked as supported: https://github.com/OpenSC/OpenSC/wiki/German-ID-Cards >> >> The card is (probably) a Starcos 3.4 type card, therefore, I compiled OpenSC 0.15.0 with the following patch: >> https://github.com/OpenSC/OpenSC/pull/357 >> >> The result is as follows: >> 1. I can see the certificates on the card in Mozilla NSS after entering my PIN number on the reader's pinpad. >> >> 2. I can select a certificate for signing in LibreOffice. Then, I am asked for my PIN both in a dialog on screen and again on the reader's pinpad. The reader's display says "PIN correct" and there is no error message, but no signature is applied to the document. >> >> 3. Alternatively, I tried signing an e-mail in Thunderbird. The result is slightly different: When sending the e-mail, I am prompted to enter my PIN on the reader's pinpad. The reader's display says "PIN correct", but the signing fails with the following error message: "Sending message failed. You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroups Account Settings, or the certificate has expired." Needless to say, the certificate has not expired. >> >> Please find below the output of serveral common commands. Could someone please confirm that >> a) the card suitable for this kind of digital signatures in principle >> b) the card is not supposed to work with OpenSC 0.15.0 without the aforementioned patch >> c) the card is supposed to work with OpenSC 0.15.0 with the patch and all future versions including the patch >> >> If someone can help with the troubleshooting, that would be awesome. Just getting definitve answers to the above a),b),c) would be a real good starting point, though. >> >> Best regards, and thanks in advance, >> Ferdinand >> >> >>> $ opensc-tool -i >>> OpenSC 0.15.0 [gcc 4.9.2] >>> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) >> >> ---------------------- >> >>> $ opensc-tool --list-readers >>> # Detected readers (pcsc) >>> Nr. Card Features Name >>> 0 Yes PIN pad REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> >> ---------------------- >> >>> $ opensc-tool --name >>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> STARCOS SPK 3.4 >> >> ---------------------- >> >>> $ opensc-tool --atr >>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61 >> >> ---------------------- >> >>> $ pkcs11-tool --list-slots >>> Available slots: >>> Slot 0 (0xffffffff): Virtual hotplug slot >>> (empty) >>> Slot 1 (0x1): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> token label : D-TRUST Card V3.0 standard 2ga ( >>> token manufacturer : D-TRUST GmbH (C) >>> token model : PKCS#15 >>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>> hardware version : 0.0 >>> firmware version : 0.0 >>> serial num : >>> Slot 2 (0x2): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> token label : D-TRUST Card V3.0 standard 2ga ( >>> token manufacturer : D-TRUST GmbH (C) >>> token model : PKCS#15 >>> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >>> hardware version : 0.0 >>> firmware version : 0.0 >>> serial num : >> >> ---------------------- >> >>> $ pkcs11-tool --list-objects >>> Using slot 1 with a present token (0x1) >>> Public Key Object; RSA 2048 bits >>> label: D-TRUST Authentication Key >>> ID: 11 >>> Usage: encrypt, verify, wrap >>> Certificate Object, type = X.509 cert >>> label: D-TRUST Authentication Key >>> ID: 11 >>> Certificate Object, type = X.509 cert >>> label: >>> ID: 2d333730343631303735333036303830313534 >>> Public Key Object; RSA 2048 bits >>> label: >>> ID: 2d333730343631303735333036303830313534 >>> Usage: encrypt, verify >>> Certificate Object, type = X.509 cert >>> label: >>> ID: 2d32303036363939383139343731343534393238 >>> Public Key Object; RSA 2048 bits >>> label: >>> ID: 2d32303036363939383139343731343534393238 >>> Usage: encrypt, verify >> >> ---------------------- >> >>> $ pkcs15-tool -D >>> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> PKCS#15 Card [D-TRUST Card V3.0 standard 2ga]: >>> Version : 0 >>> Serial number : >>> Manufacturer ID: D-TRUST GmbH (C) >>> Flags : Login required, EID compliant >>> >>> PIN [PIN1] >>> Object Flags : [0x3], private, modifiable >>> Auth ID : 03 >>> ID : 01 >>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>> Length : min_len:6, max_len:8, stored_len:8 >>> Pad char : 0xFF >>> Reference : 1 (0x01) >>> Type : iso 9664-1 >>> Path : a000000063504b43532d3135:: >>> >>> PIN [PUK1] >>> Object Flags : [0x3], private, modifiable >>> ID : 03 >>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>> Length : min_len:8, max_len:8, stored_len:8 >>> Pad char : 0xFF >>> Reference : 1 (0x01) >>> Type : iso 9664-1 >>> Path : a000000063504b43532d3135:: >>> >>> PIN [PIN2] >>> Object Flags : [0x3], private, modifiable >>> Auth ID : 04 >>> ID : 02 >>> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >>> Length : min_len:6, max_len:8, stored_len:8 >>> Pad char : 0xFF >>> Reference : 129 (0x81) >>> Type : iso 9664-1 >>> Path : 3f000604 >>> >>> PIN [PUK2] >>> Object Flags : [0x3], private, modifiable >>> ID : 04 >>> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >>> Length : min_len:8, max_len:8, stored_len:8 >>> Pad char : 0xFF >>> Reference : 129 (0x81) >>> Type : iso 9664-1 >>> Path : 3f000604 >>> >>> Private RSA Key [D-TRUST Authentication Key] >>> Object Flags : [0x1], private >>> Usage : [0x2E], decrypt, sign, signRecover, unwrap >>> Access Flags : [0x0] >>> ModLength : 2048 >>> Key ref : 1 (0x1) >>> Native : yes >>> Path : a000000063504b43532d3135::3f000fff0f01 >>> Auth ID : 01 >>> ID : 11 >>> MD:guid : {a8abd012-eb59-b862-bf9b-c1ea443d2f35} >>> :cmap flags : 0x0 >>> :sign : 0 >>> :key-exchange: 0 >>> >>> Private RSA Key [SigG Signature Key] >>> Object Flags : [0x1], private >>> Usage : [0x200], nonRepudiation >>> Access Flags : [0x0] >>> ModLength : 2048 >>> Key ref : 4 (0x4) >>> Native : yes >>> Path : a000000063504b43532d3135::3f0006040f01 >>> Auth ID : 02 >>> ID : 12 >>> MD:guid : {c4f87a62-90ae-e1ac-fc1f-26083974ce94} >>> :cmap flags : 0x0 >>> :sign : 0 >>> :key-exchange: 0 >>> >>> Public RSA Key [D-TRUST Authentication Key] >>> Object Flags : [0x2], modifiable >>> Usage : [0xD1], encrypt, wrap, verify, verifyRecover >>> Access Flags : [0x0] >>> ModLength : 2048 >>> Key ref : 1 (0x1) >>> Native : yes >>> Path : a000000063504b43532d3135::3f000fff0e01 >>> Auth ID : 01 >>> ID : 11 >>> >>> Public RSA Key [SigG Signature Key] >>> Object Flags : [0x2], modifiable >>> Usage : [0x204], sign, nonRepudiation >>> Access Flags : [0x0] >>> ModLength : 2048 >>> Key ref : 4 (0x4) >>> Native : yes >>> Path : a000000063504b43532d3135::3f0006040e01 >>> Auth ID : 02 >>> ID : 12 >>> >>> X.509 Certificate [D-TRUST Authentication Key] >>> Object Flags : [0x2], modifiable >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c100 >>> ID : 11 >>> Encoded serial : 02 03 168A81 >>> X.509 Certificate [SigG Signature Key] >>> Object Flags : [0x2], modifiable >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c103 >>> ID : 12 >>> Encoded serial : 02 03 168A82 >>> X.509 Certificate [] >>> Object Flags : [0x0] >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c102 >>> ID : 2d32303036363939383139343731343534393238 >>> Encoded serial : 02 03 030E96 >>> X.509 Certificate [] >>> Object Flags : [0x0] >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c101 >>> ID : 2d333730343631303735333036303830313534 >>> Encoded serial : 02 03 097D43 >>> X.509 Certificate [] >>> Object Flags : [0x0] >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c105 >>> ID : 37353738323838313038333736373637303437 >>> Encoded serial : 02 03 159923 >>> X.509 Certificate [] >>> Object Flags : [0x0] >>> Authority : no >>> Path : a000000063504b43532d3135::3f001501c104 >>> ID : 38323832353936323735353833303736353131 >>> Encoded serial : 02 03 159924 >> >> ---------------------- >> >>> $ pcsc_scan >>> PC/SC device scanner >>> V 1.4.23 (c) 2001-2011, Ludovic Rousseau <lud...@fr...> >>> Compiled with PC/SC lite version: 1.8.11 >>> Using reader plug'n play mechanism >>> Scanning present readers... >>> 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> >>> Sat Nov 7 01:39:47 2015 >>> Reader 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >>> Card state: Card inserted, >>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>> >>> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>> + TS = 3B --> Direct Convention >>> + T0 = D8, Y(1): 1101, K: 8 (historical bytes) >>> TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU >>> 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s >>> TC(1) = FF --> Extra guard time: 255 (special value) >>> TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 >>> ----- >>> TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 >>> ----- >>> TA(3) = FE --> IFSC: 254 >>> TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5 >>> TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following >>> ----- >>> TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V >>> + Historical bytes: 80 64 04 1A B4 03 81 05 >>> Category indicator byte: 80 (compact TLV data object) >>> Tag: 6, len: 4 (pre-issuing data) >>> Data: 04 1A B4 03 >>> Tag: 8, len: 1 (status indicator) >>> LCS (life card cycle): 05 >>> + TCK = 61 (correct checksum) >>> >>> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): >>> 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >>> D-Trust multicard advanced 3.1 >>> German public health insurance card ("Gesundheitskarte"), issuer SBK "Siemens Betriebskrankenkasse" >> >> Note: This is not fully correct. This type of card is used for the German health insurance, but also for other uses, such as my QES signautre card. The name is incorrectly hardcoded in the list that ships with pcsc_scan. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel |
|
From: Andreas S. <and...@ca...> - 2015-11-08 21:21:38
|
Hi Ferdinand, can you set OPENSC_DEBUG=9 so we can see what is going on ? As an alternative you could try [1], which has been tested with D-Trust 3.0 cards. Andreas [1] https://github.com/CardContact/sc-hsm-embedded/wiki/PKCS11 On 11/08/2015 09:08 PM, Ferdinand Rau wrote: > Dear all, > > I am trying to get PDF signatures to work with LibreOffice 5.0 and my D-TRUST card 3.0, which requires a properly set up Mozilla NSS, which in turn requires OpenSC. I access the card via an USB smart card reader "ReinerSCT cyberJack RFID komfort" on Debian Jessie Linux with OpenSC 0.15.0. > The card is listed here, but not explicitly marked as supported: https://github.com/OpenSC/OpenSC/wiki/German-ID-Cards > > The card is (probably) a Starcos 3.4 type card, therefore, I compiled OpenSC 0.15.0 with the following patch: > https://github.com/OpenSC/OpenSC/pull/357 > > The result is as follows: > 1. I can see the certificates on the card in Mozilla NSS after entering my PIN number on the reader's pinpad. > > 2. I can select a certificate for signing in LibreOffice. Then, I am asked for my PIN both in a dialog on screen and again on the reader's pinpad. The reader's display says "PIN correct" and there is no error message, but no signature is applied to the document. > > 3. Alternatively, I tried signing an e-mail in Thunderbird. The result is slightly different: When sending the e-mail, I am prompted to enter my PIN on the reader's pinpad. The reader's display says "PIN correct", but the signing fails with the following error message: "Sending message failed. You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroups Account Settings, or the certificate has expired." Needless to say, the certificate has not expired. > > Please find below the output of serveral common commands. Could someone please confirm that > a) the card suitable for this kind of digital signatures in principle > b) the card is not supposed to work with OpenSC 0.15.0 without the aforementioned patch > c) the card is supposed to work with OpenSC 0.15.0 with the patch and all future versions including the patch > > If someone can help with the troubleshooting, that would be awesome. Just getting definitve answers to the above a),b),c) would be a real good starting point, though. > > Best regards, and thanks in advance, > Ferdinand > > >> $ opensc-tool -i >> OpenSC 0.15.0 [gcc 4.9.2] >> Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) > > ---------------------- > >> $ opensc-tool --list-readers >> # Detected readers (pcsc) >> Nr. Card Features Name >> 0 Yes PIN pad REINER SCT cyberJack RFID komfort (4694896162) 00 00 > > ---------------------- > >> $ opensc-tool --name >> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> STARCOS SPK 3.4 > > ---------------------- > >> $ opensc-tool --atr >> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61 > > ---------------------- > >> $ pkcs11-tool --list-slots >> Available slots: >> Slot 0 (0xffffffff): Virtual hotplug slot >> (empty) >> Slot 1 (0x1): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> token label : D-TRUST Card V3.0 standard 2ga ( >> token manufacturer : D-TRUST GmbH (C) >> token model : PKCS#15 >> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >> hardware version : 0.0 >> firmware version : 0.0 >> serial num : >> Slot 2 (0x2): REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> token label : D-TRUST Card V3.0 standard 2ga ( >> token manufacturer : D-TRUST GmbH (C) >> token model : PKCS#15 >> token flags : rng, login required, PIN initialized, PIN pad present, token initialized >> hardware version : 0.0 >> firmware version : 0.0 >> serial num : > > ---------------------- > >> $ pkcs11-tool --list-objects >> Using slot 1 with a present token (0x1) >> Public Key Object; RSA 2048 bits >> label: D-TRUST Authentication Key >> ID: 11 >> Usage: encrypt, verify, wrap >> Certificate Object, type = X.509 cert >> label: D-TRUST Authentication Key >> ID: 11 >> Certificate Object, type = X.509 cert >> label: >> ID: 2d333730343631303735333036303830313534 >> Public Key Object; RSA 2048 bits >> label: >> ID: 2d333730343631303735333036303830313534 >> Usage: encrypt, verify >> Certificate Object, type = X.509 cert >> label: >> ID: 2d32303036363939383139343731343534393238 >> Public Key Object; RSA 2048 bits >> label: >> ID: 2d32303036363939383139343731343534393238 >> Usage: encrypt, verify > > ---------------------- > >> $ pkcs15-tool -D >> Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> PKCS#15 Card [D-TRUST Card V3.0 standard 2ga]: >> Version : 0 >> Serial number : >> Manufacturer ID: D-TRUST GmbH (C) >> Flags : Login required, EID compliant >> >> PIN [PIN1] >> Object Flags : [0x3], private, modifiable >> Auth ID : 03 >> ID : 01 >> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >> Length : min_len:6, max_len:8, stored_len:8 >> Pad char : 0xFF >> Reference : 1 (0x01) >> Type : iso 9664-1 >> Path : a000000063504b43532d3135:: >> >> PIN [PUK1] >> Object Flags : [0x3], private, modifiable >> ID : 03 >> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >> Length : min_len:8, max_len:8, stored_len:8 >> Pad char : 0xFF >> Reference : 1 (0x01) >> Type : iso 9664-1 >> Path : a000000063504b43532d3135:: >> >> PIN [PIN2] >> Object Flags : [0x3], private, modifiable >> Auth ID : 04 >> ID : 02 >> Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData >> Length : min_len:6, max_len:8, stored_len:8 >> Pad char : 0xFF >> Reference : 129 (0x81) >> Type : iso 9664-1 >> Path : 3f000604 >> >> PIN [PUK2] >> Object Flags : [0x3], private, modifiable >> ID : 04 >> Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData >> Length : min_len:8, max_len:8, stored_len:8 >> Pad char : 0xFF >> Reference : 129 (0x81) >> Type : iso 9664-1 >> Path : 3f000604 >> >> Private RSA Key [D-TRUST Authentication Key] >> Object Flags : [0x1], private >> Usage : [0x2E], decrypt, sign, signRecover, unwrap >> Access Flags : [0x0] >> ModLength : 2048 >> Key ref : 1 (0x1) >> Native : yes >> Path : a000000063504b43532d3135::3f000fff0f01 >> Auth ID : 01 >> ID : 11 >> MD:guid : {a8abd012-eb59-b862-bf9b-c1ea443d2f35} >> :cmap flags : 0x0 >> :sign : 0 >> :key-exchange: 0 >> >> Private RSA Key [SigG Signature Key] >> Object Flags : [0x1], private >> Usage : [0x200], nonRepudiation >> Access Flags : [0x0] >> ModLength : 2048 >> Key ref : 4 (0x4) >> Native : yes >> Path : a000000063504b43532d3135::3f0006040f01 >> Auth ID : 02 >> ID : 12 >> MD:guid : {c4f87a62-90ae-e1ac-fc1f-26083974ce94} >> :cmap flags : 0x0 >> :sign : 0 >> :key-exchange: 0 >> >> Public RSA Key [D-TRUST Authentication Key] >> Object Flags : [0x2], modifiable >> Usage : [0xD1], encrypt, wrap, verify, verifyRecover >> Access Flags : [0x0] >> ModLength : 2048 >> Key ref : 1 (0x1) >> Native : yes >> Path : a000000063504b43532d3135::3f000fff0e01 >> Auth ID : 01 >> ID : 11 >> >> Public RSA Key [SigG Signature Key] >> Object Flags : [0x2], modifiable >> Usage : [0x204], sign, nonRepudiation >> Access Flags : [0x0] >> ModLength : 2048 >> Key ref : 4 (0x4) >> Native : yes >> Path : a000000063504b43532d3135::3f0006040e01 >> Auth ID : 02 >> ID : 12 >> >> X.509 Certificate [D-TRUST Authentication Key] >> Object Flags : [0x2], modifiable >> Authority : no >> Path : a000000063504b43532d3135::3f001501c100 >> ID : 11 >> Encoded serial : 02 03 168A81 >> X.509 Certificate [SigG Signature Key] >> Object Flags : [0x2], modifiable >> Authority : no >> Path : a000000063504b43532d3135::3f001501c103 >> ID : 12 >> Encoded serial : 02 03 168A82 >> X.509 Certificate [] >> Object Flags : [0x0] >> Authority : no >> Path : a000000063504b43532d3135::3f001501c102 >> ID : 2d32303036363939383139343731343534393238 >> Encoded serial : 02 03 030E96 >> X.509 Certificate [] >> Object Flags : [0x0] >> Authority : no >> Path : a000000063504b43532d3135::3f001501c101 >> ID : 2d333730343631303735333036303830313534 >> Encoded serial : 02 03 097D43 >> X.509 Certificate [] >> Object Flags : [0x0] >> Authority : no >> Path : a000000063504b43532d3135::3f001501c105 >> ID : 37353738323838313038333736373637303437 >> Encoded serial : 02 03 159923 >> X.509 Certificate [] >> Object Flags : [0x0] >> Authority : no >> Path : a000000063504b43532d3135::3f001501c104 >> ID : 38323832353936323735353833303736353131 >> Encoded serial : 02 03 159924 > > ---------------------- > >> $ pcsc_scan >> PC/SC device scanner >> V 1.4.23 (c) 2001-2011, Ludovic Rousseau <lud...@fr...> >> Compiled with PC/SC lite version: 1.8.11 >> Using reader plug'n play mechanism >> Scanning present readers... >> 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> >> Sat Nov 7 01:39:47 2015 >> Reader 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 >> Card state: Card inserted, >> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >> >> ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >> + TS = 3B --> Direct Convention >> + T0 = D8, Y(1): 1101, K: 8 (historical bytes) >> TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU >> 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s >> TC(1) = FF --> Extra guard time: 255 (special value) >> TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 >> ----- >> TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 >> ----- >> TA(3) = FE --> IFSC: 254 >> TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5 >> TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following >> ----- >> TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V >> + Historical bytes: 80 64 04 1A B4 03 81 05 >> Category indicator byte: 80 (compact TLV data object) >> Tag: 6, len: 4 (pre-issuing data) >> Data: 04 1A B4 03 >> Tag: 8, len: 1 (status indicator) >> LCS (life card cycle): 05 >> + TCK = 61 (correct checksum) >> >> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): >> 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 >> D-Trust multicard advanced 3.1 >> German public health insurance card ("Gesundheitskarte"), issuer SBK "Siemens Betriebskrankenkasse" > > Note: This is not fully correct. This type of card is used for the German health insurance, but also for other uses, such as my QES signautre card. The name is incorrectly hardcoded in the list that ships with pcsc_scan. > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Ferdinand R. <ra...@we...> - 2015-11-08 20:08:57
|
Dear all, I am trying to get PDF signatures to work with LibreOffice 5.0 and my D-TRUST card 3.0, which requires a properly set up Mozilla NSS, which in turn requires OpenSC. I access the card via an USB smart card reader "ReinerSCT cyberJack RFID komfort" on Debian Jessie Linux with OpenSC 0.15.0. The card is listed here, but not explicitly marked as supported: https://github.com/OpenSC/OpenSC/wiki/German-ID-Cards The card is (probably) a Starcos 3.4 type card, therefore, I compiled OpenSC 0.15.0 with the following patch: https://github.com/OpenSC/OpenSC/pull/357 The result is as follows: 1. I can see the certificates on the card in Mozilla NSS after entering my PIN number on the reader's pinpad. 2. I can select a certificate for signing in LibreOffice. Then, I am asked for my PIN both in a dialog on screen and again on the reader's pinpad. The reader's display says "PIN correct" and there is no error message, but no signature is applied to the document. 3. Alternatively, I tried signing an e-mail in Thunderbird. The result is slightly different: When sending the e-mail, I am prompted to enter my PIN on the reader's pinpad. The reader's display says "PIN correct", but the signing fails with the following error message: "Sending message failed. You specified that this message should be digitally signed, but the application either failed to find the signing certificate specified in your Mail & Newsgroups Account Settings, or the certificate has expired." Needless to say, the certificate has not expired. Please find below the output of serveral common commands. Could someone please confirm that a) the card suitable for this kind of digital signatures in principle b) the card is not supposed to work with OpenSC 0.15.0 without the aforementioned patch c) the card is supposed to work with OpenSC 0.15.0 with the patch and all future versions including the patch If someone can help with the troubleshooting, that would be awesome. Just getting definitve answers to the above a),b),c) would be a real good starting point, though. Best regards, and thanks in advance, Ferdinand > $ opensc-tool -i > OpenSC 0.15.0 [gcc 4.9.2] > Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) ---------------------- > $ opensc-tool --list-readers > # Detected readers (pcsc) > Nr. Card Features Name > 0 Yes PIN pad REINER SCT cyberJack RFID komfort (4694896162) 00 00 ---------------------- > $ opensc-tool --name > Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 > STARCOS SPK 3.4 ---------------------- > $ opensc-tool --atr > Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 > 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61 ---------------------- > $ pkcs11-tool --list-slots > Available slots: > Slot 0 (0xffffffff): Virtual hotplug slot > (empty) > Slot 1 (0x1): REINER SCT cyberJack RFID komfort (4694896162) 00 00 > token label : D-TRUST Card V3.0 standard 2ga ( > token manufacturer : D-TRUST GmbH (C) > token model : PKCS#15 > token flags : rng, login required, PIN initialized, PIN pad present, token initialized > hardware version : 0.0 > firmware version : 0.0 > serial num : > Slot 2 (0x2): REINER SCT cyberJack RFID komfort (4694896162) 00 00 > token label : D-TRUST Card V3.0 standard 2ga ( > token manufacturer : D-TRUST GmbH (C) > token model : PKCS#15 > token flags : rng, login required, PIN initialized, PIN pad present, token initialized > hardware version : 0.0 > firmware version : 0.0 > serial num : ---------------------- > $ pkcs11-tool --list-objects > Using slot 1 with a present token (0x1) > Public Key Object; RSA 2048 bits > label: D-TRUST Authentication Key > ID: 11 > Usage: encrypt, verify, wrap > Certificate Object, type = X.509 cert > label: D-TRUST Authentication Key > ID: 11 > Certificate Object, type = X.509 cert > label: > ID: 2d333730343631303735333036303830313534 > Public Key Object; RSA 2048 bits > label: > ID: 2d333730343631303735333036303830313534 > Usage: encrypt, verify > Certificate Object, type = X.509 cert > label: > ID: 2d32303036363939383139343731343534393238 > Public Key Object; RSA 2048 bits > label: > ID: 2d32303036363939383139343731343534393238 > Usage: encrypt, verify ---------------------- > $ pkcs15-tool -D > Using reader with a card: REINER SCT cyberJack RFID komfort (4694896162) 00 00 > PKCS#15 Card [D-TRUST Card V3.0 standard 2ga]: > Version : 0 > Serial number : > Manufacturer ID: D-TRUST GmbH (C) > Flags : Login required, EID compliant > > PIN [PIN1] > Object Flags : [0x3], private, modifiable > Auth ID : 03 > ID : 01 > Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData > Length : min_len:6, max_len:8, stored_len:8 > Pad char : 0xFF > Reference : 1 (0x01) > Type : iso 9664-1 > Path : a000000063504b43532d3135:: > > PIN [PUK1] > Object Flags : [0x3], private, modifiable > ID : 03 > Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData > Length : min_len:8, max_len:8, stored_len:8 > Pad char : 0xFF > Reference : 1 (0x01) > Type : iso 9664-1 > Path : a000000063504b43532d3135:: > > PIN [PIN2] > Object Flags : [0x3], private, modifiable > Auth ID : 04 > ID : 02 > Flags : [0x833], case-sensitive, local, initialized, needs-padding, exchangeRefData > Length : min_len:6, max_len:8, stored_len:8 > Pad char : 0xFF > Reference : 129 (0x81) > Type : iso 9664-1 > Path : 3f000604 > > PIN [PUK2] > Object Flags : [0x3], private, modifiable > ID : 04 > Flags : [0x873], case-sensitive, local, initialized, needs-padding, unblockingPin, exchangeRefData > Length : min_len:8, max_len:8, stored_len:8 > Pad char : 0xFF > Reference : 129 (0x81) > Type : iso 9664-1 > Path : 3f000604 > > Private RSA Key [D-TRUST Authentication Key] > Object Flags : [0x1], private > Usage : [0x2E], decrypt, sign, signRecover, unwrap > Access Flags : [0x0] > ModLength : 2048 > Key ref : 1 (0x1) > Native : yes > Path : a000000063504b43532d3135::3f000fff0f01 > Auth ID : 01 > ID : 11 > MD:guid : {a8abd012-eb59-b862-bf9b-c1ea443d2f35} > :cmap flags : 0x0 > :sign : 0 > :key-exchange: 0 > > Private RSA Key [SigG Signature Key] > Object Flags : [0x1], private > Usage : [0x200], nonRepudiation > Access Flags : [0x0] > ModLength : 2048 > Key ref : 4 (0x4) > Native : yes > Path : a000000063504b43532d3135::3f0006040f01 > Auth ID : 02 > ID : 12 > MD:guid : {c4f87a62-90ae-e1ac-fc1f-26083974ce94} > :cmap flags : 0x0 > :sign : 0 > :key-exchange: 0 > > Public RSA Key [D-TRUST Authentication Key] > Object Flags : [0x2], modifiable > Usage : [0xD1], encrypt, wrap, verify, verifyRecover > Access Flags : [0x0] > ModLength : 2048 > Key ref : 1 (0x1) > Native : yes > Path : a000000063504b43532d3135::3f000fff0e01 > Auth ID : 01 > ID : 11 > > Public RSA Key [SigG Signature Key] > Object Flags : [0x2], modifiable > Usage : [0x204], sign, nonRepudiation > Access Flags : [0x0] > ModLength : 2048 > Key ref : 4 (0x4) > Native : yes > Path : a000000063504b43532d3135::3f0006040e01 > Auth ID : 02 > ID : 12 > > X.509 Certificate [D-TRUST Authentication Key] > Object Flags : [0x2], modifiable > Authority : no > Path : a000000063504b43532d3135::3f001501c100 > ID : 11 > Encoded serial : 02 03 168A81 > X.509 Certificate [SigG Signature Key] > Object Flags : [0x2], modifiable > Authority : no > Path : a000000063504b43532d3135::3f001501c103 > ID : 12 > Encoded serial : 02 03 168A82 > X.509 Certificate [] > Object Flags : [0x0] > Authority : no > Path : a000000063504b43532d3135::3f001501c102 > ID : 2d32303036363939383139343731343534393238 > Encoded serial : 02 03 030E96 > X.509 Certificate [] > Object Flags : [0x0] > Authority : no > Path : a000000063504b43532d3135::3f001501c101 > ID : 2d333730343631303735333036303830313534 > Encoded serial : 02 03 097D43 > X.509 Certificate [] > Object Flags : [0x0] > Authority : no > Path : a000000063504b43532d3135::3f001501c105 > ID : 37353738323838313038333736373637303437 > Encoded serial : 02 03 159923 > X.509 Certificate [] > Object Flags : [0x0] > Authority : no > Path : a000000063504b43532d3135::3f001501c104 > ID : 38323832353936323735353833303736353131 > Encoded serial : 02 03 159924 ---------------------- > $ pcsc_scan > PC/SC device scanner > V 1.4.23 (c) 2001-2011, Ludovic Rousseau <lud...@fr...> > Compiled with PC/SC lite version: 1.8.11 > Using reader plug'n play mechanism > Scanning present readers... > 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 > > Sat Nov 7 01:39:47 2015 > Reader 0: REINER SCT cyberJack RFID komfort (4694896162) 00 00 > Card state: Card inserted, > ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 > > ATR: 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 > + TS = 3B --> Direct Convention > + T0 = D8, Y(1): 1101, K: 8 (historical bytes) > TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU > 129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s > TC(1) = FF --> Extra guard time: 255 (special value) > TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 > ----- > TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1 > ----- > TA(3) = FE --> IFSC: 254 > TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5 > TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface bytes following > ----- > TA(4) = 03 --> Clock stop: not supported - Class accepted by the card: (3G) A 5V B 3V > + Historical bytes: 80 64 04 1A B4 03 81 05 > Category indicator byte: 80 (compact TLV data object) > Tag: 6, len: 4 (pre-issuing data) > Data: 04 1A B4 03 > Tag: 8, len: 1 (status indicator) > LCS (life card cycle): 05 > + TCK = 61 (correct checksum) > > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt): > 3B D8 18 FF 81 B1 FE 45 1F 03 80 64 04 1A B4 03 81 05 61 > D-Trust multicard advanced 3.1 > German public health insurance card ("Gesundheitskarte"), issuer SBK "Siemens Betriebskrankenkasse" Note: This is not fully correct. This type of card is used for the German health insurance, but also for other uses, such as my QES signautre card. The name is incorrectly hardcoded in the list that ships with pcsc_scan. |
|
From: Douglas E E. <dee...@gm...> - 2015-10-29 20:38:08
|
Good to hear. LatviaEid_AID is incorrectly named. Its in not an AID, but the string the vendor put in the ATR. On 10/29/2015 3:30 PM, Kaspars Dambis wrote: > Looks like the LatviaEid_AID is used for ATR matching only while the actual AID is the GlobalPlatform_CardManager_AID. I fixed my issue by adding SC_CARD_TYPE_IASECC_LATVIAEID to iasecc_select_file() > (L993 of card-iassecc.c) where it uses card->type to verify a valid card type: > > https://github.com/kasparsd/OpenSC-Latvia-eID/commit/0c86db2e9731edcc306cbce1fecfea73f680729f > > $ ./opensc-tool -a -v > Using reader with a card: OMNIKEY AG Smart Card Reader > Connecting to card in reader OMNIKEY AG Smart Card Reader... > Using card driver IAS-ECC. > Card ATR: > 3B DD 18 00 81 31 FE 45 90 4C 41 54 56 49 41 2D ;....1.E.LATVIA- > 65 49 44 90 00 8C eID... > > > Here is dump from pkcs15-tool: > https://gist.github.com/kasparsd/ed3a874173cbfc6d3981 > > Thank you once again! > Kaspars > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-10-29 20:35:11
|
I see: https://github.com/eID-LV was created in 2014 by http://www.pmlp.gov.lv This looks like the Lativa gov published the code. It is based on OpenSC-0-12.2 Looks like no change have ever been made. So this may be you best source of information. On 10/29/2015 2:02 PM, Kaspars Dambis wrote: > Thanks for that explanation, Douglas! I really appreciate it! > > My understanding is that all of the init functions do the following: > > 1. Set a few card specific flags > 2. Parse the ATR iasecc_parse_ef_atr(card) to confirm ATR card match > 3. Select the AID > 4. Select the MF file Yes sort of. But first there are the match routines. This look for card ATRs or AIDs and then set the driver. The Init functions then setup for using the driver. There are some drivers that only look for the AID in the match functions, and don't look at the ATR other then to handle bugs between different card and/or applet inplementations. The AID should define the applet, or the specifications of the applet. This then allows for the same AID to be used for different implementations of the applet and on different cards. > > while the legacy init for Latvia eID (which works) does the following: > > 1. Piggy back on iasecc_init_oberthur() which does everything for its spec. > 2. Shortcircuits iasecc_oberthur_match() with iasecc_LATVIA_EID_match() which matches the ATR value and then sets OberthurIASECC_AID (!) > 3. Selects the MF file > > My question is -- what is the MF file and how does it relate to the selected AID. What should happen after the AID has been selected when running "opensc-tools -a", for example. Applets with the same AID should use the same file structure on the card. But an applet controls the location data. It should be in the applets specs or readable from the card. (PKCS#15 for example defines how to store certs, keys and other objects and attributes on a card.) (AIDs are registered and the 0xA0,0x00,0x00,0x00,0x77,0x01.0x08 appears to be registerd to Operthur.) ISO 7816-4 defines all the commands, and path info. MF is like the root directory of the file system. Google for: iso78160-4 The Cardwerk.com is fairly good. You can also purchase a copy from ISO. See: Section 5.1.1 File organization Back to the eID-LV... That code was from 2010, placed in github.com in 2014 and never modified. Since then they may have started using a different card or card vendor. So it is not clear if it still works or not. I would assume that if you used the Oberthur AID it will still work. (AIDs are registered and the 0xA0,0x00,0x00,0x00,0x77,0x01.0x08 appears to be registered to Oberthur.) > > Thanks! > Kaspars > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Kaspars D. <ka...@da...> - 2015-10-29 20:30:36
|
Looks like the LatviaEid_AID is used for ATR matching only while the actual AID is the GlobalPlatform_CardManager_AID. I fixed my issue by adding SC_CARD_TYPE_IASECC_LATVIAEID to iasecc_select_file() (L993 of card-iassecc.c) where it uses card->type to verify a valid card type: https://github.com/kasparsd/OpenSC-Latvia-eID/commit/0c86db2e9731edcc306cbce1fecfea73f680729f $ ./opensc-tool -a -v > Using reader with a card: OMNIKEY AG Smart Card Reader > Connecting to card in reader OMNIKEY AG Smart Card Reader... > Using card driver IAS-ECC. > Card ATR: > 3B DD 18 00 81 31 FE 45 90 4C 41 54 56 49 41 2D ;....1.E.LATVIA- > 65 49 44 90 00 8C eID... Here is dump from pkcs15-tool: https://gist.github.com/kasparsd/ed3a874173cbfc6d3981 Thank you once again! Kaspars |
|
From: Kaspars D. <ka...@da...> - 2015-10-29 19:02:40
|
Thanks for that explanation, Douglas! I really appreciate it! My understanding is that all of the init functions do the following: 1. Set a few card specific flags 2. Parse the ATR iasecc_parse_ef_atr(card) to confirm ATR card match 3. Select the AID 4. Select the MF file while the legacy init for Latvia eID (which works) does the following: 1. Piggy back on iasecc_init_oberthur() which does everything for its spec. 2. Shortcircuits iasecc_oberthur_match() with iasecc_LATVIA_EID_match() which matches the ATR value and then sets OberthurIASECC_AID (!) 3. Selects the MF file My question is -- what is the MF file and how does it relate to the selected AID. What should happen after the AID has been selected when running "opensc-tools -a", for example. Thanks! Kaspars |
|
From: Douglas E E. <dee...@gm...> - 2015-10-29 16:16:39
|
Basic answer is OpenSC used to assume one one application per card, and the ATR determined the driver. Modern approach is to use an application AID to select the application on the card. On 10/29/2015 9:15 AM, Kaspars Dambis wrote: > Hello! > > I'm trying to understand why this legacy version of OpenSC [1] is able to recognize my Latvia eID card (IAS/ECC) while my efforts of porting the support for the card to the latest version of OpenSC > [2] is currently failing. > > Here is the relevant debug log from both versions: > https://gist.github.com/kasparsd/66cf8b145b7e3ae8d120 > > It appears that iasecc_select_mf is using the wrong file path after having received the same APDU response. The working version selects the following: > > > card-iasecc.c:603:iasecc_select_file: iasecc_select_file(card:0x1018005e0) path.len 16; path.type 1; aid_len 0 > > card-iasecc.c:604:iasecc_select_file: iasecc_select_file() path:a000000077010800070000fe00000100:: > > while the non-working version does this: > > > card-iasecc.c:943:iasecc_select_file: iasecc_select_file(card:0x7ffd94801000) path.len 10; path.type 1; aid_len 0 > > card-iasecc.c:944:iasecc_select_file: iasecc_select_file() path:4c41545649412d654944:: This looks like 100 //proprietary ATR to match 101 static struct sc_aid LatviaEid_ATR_MATCH = { 102 {0x4C,0x41,0x54,0x56,0x49,0x41,0x2D,0x65,0x49,0x44}, 10 103 }; A ATR is a not path to a file. The above looks like "LATVIA-Eid" what code called select_file with 4c41545649412d654944? An ATR may have historic bytes that may contain an AID. But a vendor can put anything in the historic bytes. > > I would appreciate any tips or suggestion on where to put debug pointers to be able to resolve this. Here are the complete logs [3] if that would help. > > Thanks! > Kaspars > > p.s. please note that I've spent only a few month looking into smart cards and have a very basic understanding of C. > > [1] https://github.com/kasparsd/latvian-eid-opensc/commit/d615c91843f04d2df09a275cd6e513920a8fc497 > [2] https://github.com/kasparsd/OpenSC-Latvia-eID > [3] https://gist.github.com/kasparsd/acea5c71f543bda88b5e > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@gm...> |
|
From: Kaspars D. <ka...@da...> - 2015-10-29 14:47:31
|
Hello! I'm trying to understand why this legacy version of OpenSC [1] is able to recognize my Latvia eID card (IAS/ECC) while my efforts of porting the support for the card to the latest version of OpenSC [2] is currently failing. Here is the relevant debug log from both versions: https://gist.github.com/kasparsd/66cf8b145b7e3ae8d120 It appears that iasecc_select_mf is using the wrong file path after having received the same APDU response. The working version selects the following: > card-iasecc.c:603:iasecc_select_file: iasecc_select_file(card:0x1018005e0) path.len 16; path.type 1; aid_len 0 > card-iasecc.c:604:iasecc_select_file: iasecc_select_file() path:a000000077010800070000fe00000100:: while the non-working version does this: > card-iasecc.c:943:iasecc_select_file: iasecc_select_file(card:0x7ffd94801000) path.len 10; path.type 1; aid_len 0 > card-iasecc.c:944:iasecc_select_file: iasecc_select_file() path:4c41545649412d654944:: I would appreciate any tips or suggestion on where to put debug pointers to be able to resolve this. Here are the complete logs [3] if that would help. Thanks! Kaspars p.s. please note that I've spent only a few month looking into smart cards and have a very basic understanding of C. [1] https://github.com/kasparsd/latvian-eid-opensc/commit/d615c91843f04d2df09a275cd6e513920a8fc497 [2] https://github.com/kasparsd/OpenSC-Latvia-eID [3] https://gist.github.com/kasparsd/acea5c71f543bda88b5e |
|
From: Vincent Le T. <vin...@my...> - 2015-10-27 15:12:47
|
For the Windows side: To be sure the dll is correct (the nightly build has a problem with the inclusiong of OpenSSL), I'll suggest to run "depends.exe" with the dll. You'll be able to check that all dependancies are OK; Then use processmonitor.exe => you'll be able to be sure if the dll get loaded or not. For the java side; Have you called .load function I see in the opensc-testing code ? https://github.com/Emergya/opensc-testing/blob/a63c2db24108d28f669eda34e407072b74824d5c/opensc-testing-core/src/main/java/org/opensc/testing/SecurityUtils.java#L142 vincent 2015-10-27 15:41 GMT+01:00 Anders Rundgren <and...@gm...>: > On 2015-10-27 15:35, Anders Rundgren wrote: > > On 2015-10-27 15:28, Ernie Kovak wrote: > > Ernie, > > > > Oracle/SUN never ported the PKCS #11 wrapper to Windows... > > They do have a CAPI wrapper though (but never tested). > > I was wrong. For JDK 8 they have finally shipped a 64-bit version, yay! > > Anders > > > > > Anders > > > >> Hello - > >> > >> I'm new to OpenSC and just trying it out. My goal is CAC authentication > from a Java thick client on Windows 7 using NSS in FIPS mode. I imagine > it'll take some work to put all those things together. :) > >> > >> My first step was to verify the Java PKCS#11 provider, without NSS. > I've installed the nightly Windows build, > opensc-0.15.0g20150914124137-win64.msi, and the opensc tools are able to > access my card both through a built-in reader and a USB reader. > >> > >> I'm using some example code from > https://github.com/emergya/opensc-testing: > >> > >> Provider p = new sun.security.pkcs11.SunPKCS11("opensc-cfg.txt"); > >> Security.insertProviderAt(p, 0); > >> KeyStore cac = KeyStore.getInstance("PKCS11", p); > >> > >> The call to KeyStore.getInstance throws this exception and cause: > >> > >> java.security.KeyStoreException: PKCS11 not found > >> java.security.NoSuchAlgorithmException: no such algorithm: PKCS11 for > provider SunPKCS11-OpenSC > >> > >> When I list the provider's services there are none. > >> > >> Here's my config file contents (based on example at opensc-testing): > >> > >> name = OpenSC > >> library = C:/Windows/System32/opensc-pkcs11.dll > >> slot = -1 > >> attributes = compatibility > >> attributes(*,*,*)= > >> { > >> CKA_TOKEN=true > >> CKA_LOCAL=true > >> } > >> > >> I've turned up the OpenSC debug level, and the call to the SunPKCS11 > constructor invokes OpenSC and writes a lot of output to my log (attached). > >> > >> I've read everything I could find, and I think my setup and code is > correct. Did I miss something? > >> > >> Any help will be appreciated - thanks in advance! > >> > >> Ernie > >> > >> > >> > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> > >> > >> > >> _______________________________________________ > >> Opensc-devel mailing list > >> Ope...@li... > >> https://lists.sourceforge.net/lists/listinfo/opensc-devel > >> > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
|
From: Nikos M. <n.m...@gm...> - 2015-10-27 14:45:47
|
Next FOSDEM [1] will, again, have a security devroom, this time on the topic of "Security and Privacy in modern software". We'd like to invite submissions of talks and presentations from developers, security researchers and other interested representatives of open source and free software and hardware projects. This is the call for talks and presentations that will take place in the Security devroom at FOSDEM 2016. Our topic this year: Cryptography has been the foundation of modern crypto software, however, it is only a small fraction of the technology required to achieve security and privacy for users. Thus this year's topic is to focus on the other parts that make software secure: usability, the protection against side-channels, message length analysis, fingerprinting, secure coding practices, code review processes etc. We welcome presentations of security software and hardware which take into account these factors, and presentations that analyze other's solutions. For up-to-date submission and event information: https://github.com/security-devroom/fosdem-2016 The security devroom will be held on Sunday 31st of January 2016 in Brussels, Belgium at ULB. Feel free to forward this announcement to any relevant FOSS project mailing list. [1] https://fosdem.org/2016/ [2] https://github.com/security-devroom/fosdem-2016 |
|
From: Anders R. <and...@gm...> - 2015-10-27 14:41:32
|
On 2015-10-27 15:35, Anders Rundgren wrote: > On 2015-10-27 15:28, Ernie Kovak wrote: > Ernie, > > Oracle/SUN never ported the PKCS #11 wrapper to Windows... > They do have a CAPI wrapper though (but never tested). I was wrong. For JDK 8 they have finally shipped a 64-bit version, yay! Anders > > Anders > >> Hello - >> >> I'm new to OpenSC and just trying it out. My goal is CAC authentication from a Java thick client on Windows 7 using NSS in FIPS mode. I imagine it'll take some work to put all those things together. :) >> >> My first step was to verify the Java PKCS#11 provider, without NSS. I've installed the nightly Windows build, opensc-0.15.0g20150914124137-win64.msi, and the opensc tools are able to access my card both through a built-in reader and a USB reader. >> >> I'm using some example code from https://github.com/emergya/opensc-testing: >> >> Provider p = new sun.security.pkcs11.SunPKCS11("opensc-cfg.txt"); >> Security.insertProviderAt(p, 0); >> KeyStore cac = KeyStore.getInstance("PKCS11", p); >> >> The call to KeyStore.getInstance throws this exception and cause: >> >> java.security.KeyStoreException: PKCS11 not found >> java.security.NoSuchAlgorithmException: no such algorithm: PKCS11 for provider SunPKCS11-OpenSC >> >> When I list the provider's services there are none. >> >> Here's my config file contents (based on example at opensc-testing): >> >> name = OpenSC >> library = C:/Windows/System32/opensc-pkcs11.dll >> slot = -1 >> attributes = compatibility >> attributes(*,*,*)= >> { >> CKA_TOKEN=true >> CKA_LOCAL=true >> } >> >> I've turned up the OpenSC debug level, and the call to the SunPKCS11 constructor invokes OpenSC and writes a lot of output to my log (attached). >> >> I've read everything I could find, and I think my setup and code is correct. Did I miss something? >> >> Any help will be appreciated - thanks in advance! >> >> Ernie >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> > |
|
From: Anders R. <and...@gm...> - 2015-10-27 14:35:14
|
On 2015-10-27 15:28, Ernie Kovak wrote: Ernie, Oracle/SUN never ported the PKCS #11 wrapper to Windows... They do have a CAPI wrapper though (but never tested). Anders > Hello - > > I'm new to OpenSC and just trying it out. My goal is CAC authentication from a Java thick client on Windows 7 using NSS in FIPS mode. I imagine it'll take some work to put all those things together. :) > > My first step was to verify the Java PKCS#11 provider, without NSS. I've installed the nightly Windows build, opensc-0.15.0g20150914124137-win64.msi, and the opensc tools are able to access my card both through a built-in reader and a USB reader. > > I'm using some example code from https://github.com/emergya/opensc-testing: > > Provider p = new sun.security.pkcs11.SunPKCS11("opensc-cfg.txt"); > Security.insertProviderAt(p, 0); > KeyStore cac = KeyStore.getInstance("PKCS11", p); > > The call to KeyStore.getInstance throws this exception and cause: > > java.security.KeyStoreException: PKCS11 not found > java.security.NoSuchAlgorithmException: no such algorithm: PKCS11 for provider SunPKCS11-OpenSC > > When I list the provider's services there are none. > > Here's my config file contents (based on example at opensc-testing): > > name = OpenSC > library = C:/Windows/System32/opensc-pkcs11.dll > slot = -1 > attributes = compatibility > attributes(*,*,*)= > { > CKA_TOKEN=true > CKA_LOCAL=true > } > > I've turned up the OpenSC debug level, and the call to the SunPKCS11 constructor invokes OpenSC and writes a lot of output to my log (attached). > > I've read everything I could find, and I think my setup and code is correct. Did I miss something? > > Any help will be appreciated - thanks in advance! > > Ernie > > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Ernie K. <ern...@gm...> - 2015-10-27 14:28:09
|
Hello - I'm new to OpenSC and just trying it out. My goal is CAC authentication from a Java thick client on Windows 7 using NSS in FIPS mode. I imagine it'll take some work to put all those things together. :) My first step was to verify the Java PKCS#11 provider, without NSS. I've installed the nightly Windows build, opensc-0.15.0g20150914124137-win64.msi, and the opensc tools are able to access my card both through a built-in reader and a USB reader. I'm using some example code from https://github.com/emergya/opensc-testing: Provider p = new sun.security.pkcs11.SunPKCS11("opensc-cfg.txt"); Security.insertProviderAt(p, 0); KeyStore cac = KeyStore.getInstance("PKCS11", p); The call to KeyStore.getInstance throws this exception and cause: java.security.KeyStoreException: PKCS11 not found java.security.NoSuchAlgorithmException: no such algorithm: PKCS11 for provider SunPKCS11-OpenSC When I list the provider's services there are none. Here's my config file contents (based on example at opensc-testing): name = OpenSC library = C:/Windows/System32/opensc-pkcs11.dll slot = -1 attributes = compatibility attributes(*,*,*)= { CKA_TOKEN=true CKA_LOCAL=true } I've turned up the OpenSC debug level, and the call to the SunPKCS11 constructor invokes OpenSC and writes a lot of output to my log (attached). I've read everything I could find, and I think my setup and code is correct. Did I miss something? Any help will be appreciated - thanks in advance! Ernie |
|
From: Andreas S. <and...@ca...> - 2015-10-20 10:46:00
|
Yes, that caused the problem. The code did not reject the key import but returned SC_SUCCESS when writing the private key, thus the meta data was written for key id 0 (the device authentication key). Andreas On 10/20/2015 12:34 PM, Marek Szuba wrote: > On 2015-10-20 12:04, Andreas Schwier wrote: > >> The file identifier CC00 is reserved for the device >> authentication key and can not be removed. > Would this mean that the attempted import resulted in metadata of > the imported private key getting attached to the > device-authentication key? > > Either way, thanks for your help. > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ Opensc-devel > mailing list Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Marek S. <scr...@wp...> - 2015-10-20 10:34:46
|
On 2015-10-20 12:04, Andreas Schwier wrote: > The file identifier CC00 is reserved for the device authentication key > and can not be removed. Would this mean that the attempted import resulted in metadata of the imported private key getting attached to the device-authentication key? Either way, thanks for your help. -- MS |
|
From: Andreas S. <and...@ca...> - 2015-10-20 10:04:09
|
On 10/20/2015 11:54 AM, Marek Szuba wrote: > On 2015-10-19 11:30, Andreas Schwier wrote: > I've just managed to delete 0xC400 using opensc-explorer (I did not know > how to do it using opensc-tool) and, as expected, the imported key has > disappeared from the pkcs15-tool -D output. Thanks! I couldn't delete > 0xCC00 though, even if I verify the SO PIN instead of the user PIN I get > the "not allowed" error. Will the presence of a key object without the > corresponding metadata on the card cause problems in the future? The file identifier CC00 is reserved for the device authentication key and can not be removed. A key object without meta data is not a problem: The key will simply not show up at the PKCS#11 interface. The meta data is only required for the PKCS#11 module and is not used internally in the device. > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com |
|
From: Marek S. <scr...@wp...> - 2015-10-20 09:55:11
|
On 2015-10-19 11:30, Andreas Schwier wrote: > What does pkcs15-tool -D show ? It shows a private-key object with the label I gave it during the import attempt, key ref 0 and usage flags 0x4 (the import source had more) but otherwise identical to the card-generated keys. Yes, including "native" set to yes. > You can manually erase the key file and/or meta data file after PIN > verification using opensc-tool or a script for the Smart Card Shell. I've just managed to delete 0xC400 using opensc-explorer (I did not know how to do it using opensc-tool) and, as expected, the imported key has disappeared from the pkcs15-tool -D output. Thanks! I couldn't delete 0xCC00 though, even if I verify the SO PIN instead of the user PIN I get the "not allowed" error. Will the presence of a key object without the corresponding metadata on the card cause problems in the future? -- MS |
|
From: Frank M. <mo...@in...> - 2015-10-19 22:12:05
|
Hi all! OpenSC compiles right out of the box with the nacl_sdk. The commands I used are the following: env PATH=$NACL_SDK/pepper_45/toolchain/linux_x86_glibc/bin:$PATH ./configure CXXFLAGS=--sysroot=$NACL_SDK/pepper_45/toolchain/linux_x86_glibc/x86_64-nacl/ --host=x86_64-nacl --target=x86_64-nacl --with-pcsc-provider=x86_64-nacl_libpcsclite.so env PATH=$NACL_SDK/pepper_45/toolchain/linux_x86_glibc/bin:$PATH make -j4 V=1 install DESTDIR=`pwd`/x86_64-nacl Some things to note: - $NACL_SDK points to the directory with the nacl sdk, obviously - The configure script recognizes the system's PCSC-Lite headers, which don't play a role during the actual compilation process. - x86_64-nacl_libpcsclite.so is the cross compiled PCSC-Lite library that is dlopen'ed at runtime by OpenSC - I compiled without zlib and OpenSSL, but that should be possible, because both libraries have been ported to nacl, see https://code.google.com/p/naclports/wiki/PortList - I used nacl in favour of pnacl so that I did not have to change the calls to dlopen (dlopen is not possible with pnacl). Statically linking against PCSC-Lite (read: pnacl compatibility) is easily possible, but I currently don't have the cross compiled binaries of PCSC-Lite available. - I disabled creation of shared PKCS#11 libraries (see https://github.com/frankmorgner/OpenSC/commit/54f28db695eb38765cf6550c7e976360ea2ed481), because libtool thinks that we can't create shared libraries on x86_64-nacl. This can, however, easily be done by hand with x86_64-nacl-gcc (I avoided patching libtool...) I have not tested any of the resulting binaries. This should be done with a generic PKCS#11 wrapper feeding the certificateProvider API. I guess this is already available at Google since gemalto tokens have been reported to be working. Currently, I'm not expecting someone to write the missing boiler plate for an OpenSC extension. @David will it be possible to integrate OpenSC into your PKCS#11 wrapper extension? Greets, Frank. Am Montag, dem 19. Oktober, um 14:11 Uhr schrieb Douglas E Engert: > Any interest in writing an OpenSC version of this for Chrome OS? > OpenSC supports a "a myriad others". (Sounds like another minidriver or tokend module. > > > > -------- Forwarded Message -------- > Subject: Re: Issue 220971 in chromium: Req - smartcard support for federal CAC and PIV cards, bank cards > Date: Mon, 19 Oct 2015 18:45:25 +0000 > From: chr...@go... > To: dee...@gm... > > > Comment #122 on issue 220971 by ds...@go...: Req - smartcard support > for federal CAC and PIV cards, bank cards > https://code.google.com/p/chromium/issues/detail?id=220971 > > The API to provide system support is already available > <https://developer.chrome.com/extensions/certificateProvider> as of Chrome > 46. > > Middleware providers will have to code against this. We have a working > version for Gemalto cards. Working on getting PIV and CAC support (and > hopefully a myriad others) at the moment. > > -- > You received this message because you starred the issue. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > Reply to this email to add a comment. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- 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 |
|
From: Vincent Le T. <vin...@my...> - 2015-10-19 19:38:50
|
I think it is quite simple to implement: (much more than the minidriver) * Implement in an extension onCertificatesRequested to return all certificates having a private key * Implement onSignDigestRequested to prompt a dialog asking for a PIN and sign a digest info. However this API seems to be limited to ChromeOS 2015-10-19 21:11 GMT+02:00 Douglas E Engert <dee...@gm...>: > Any interest in writing an OpenSC version of this for Chrome OS? > OpenSC supports a "a myriad others". (Sounds like another minidriver or > tokend module. > > > > -------- Forwarded Message -------- > Subject: Re: Issue 220971 in chromium: Req - smartcard support for federal > CAC and PIV cards, bank cards > Date: Mon, 19 Oct 2015 18:45:25 +0000 > From: chr...@go... > To: dee...@gm... > > > Comment #122 on issue 220971 by ds...@go...: Req - smartcard > support > for federal CAC and PIV cards, bank cards > https://code.google.com/p/chromium/issues/detail?id=220971 > > The API to provide system support is already available > <https://developer.chrome.com/extensions/certificateProvider> as of Chrome > 46. > > Middleware providers will have to code against this. We have a working > version for Gemalto cards. Working on getting PIV and CAC support (and > hopefully a myriad others) at the moment. > > -- > You received this message because you starred the issue. > You may adjust your notification preferences at: > https://code.google.com/hosting/settings > > Reply to this email to add a comment. > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- -- Vincent Le Toux My Smart Logon www.mysmartlogon.com |
5 messages has been excluded from this view by a project administrator.
