Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Support DNIe 3.0 #810
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Indeed @germanblanco wanted to look into this, see #655 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Jul 25, 2016
With the old DNIe (personal data have been edited)
tux cameta # dnie-tool -a
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
DNIe Number: 00000000A
SurName: ESPAÑOL
Name: ESPAÑOL
IDESP: AGR148953
DNIe Version: DNIe 01.13 B11 H 4C34 EXP 1-((4.2-5))
Serial number: 06CFC2227A398A
with a DNIe 3.0
tux cameta # dnie-tool -a
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
Error: Get info failed: Unsupported CLA byte in APDU
With the old DNIe
cameta@tux ~ $ opensc-tool -a
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
3b:7f:38:00:00:00:6a:44:4e:49:65:20:02:4c:34:01:13:03:90:00
cameta@tux ~ $ opensc-tool -n
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
dnie
cameta@tux ~ $ opensc-tool --serial
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
06 CF C2 22 7A 39 8A ..."z9.
With a DNIe 3.0
cameta@tux ~ $ opensc-tool -a
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
3b:7f:96:00:00:00:6a:44:4e:49:65:20:01:01:55:04:10:03:90:00
cameta@tux ~ $ opensc-tool -n
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
dnie
cameta@tux ~ $ opensc-tool --serial
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
sc_card_ctl(*, SC_CARDCTL_GET_SERIALNR, *) failed
It also should be noted that this corrupts the pcscd service and it becomes unable to read any card until I restart it.
cameta
commented
Jul 25, 2016
|
With the old DNIe (personal data have been edited) tux cameta # dnie-tool -a with a DNIe 3.0 tux cameta # dnie-tool -a With the old DNIe cameta@tux ~ $ opensc-tool -a cameta@tux ~ $ opensc-tool -n cameta@tux ~ $ opensc-tool --serial With a DNIe 3.0 cameta@tux ~ $ opensc-tool -a cameta@tux ~ $ opensc-tool -n cameta@tux ~ $ opensc-tool --serial It also should be noted that this corrupts the pcscd service and it becomes unable to read any card until I restart it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Yajo
Jul 26, 2016
Keep in mind that DNIe 3.0 disables the "open session once and use many times" behavior. It requires PIN for each use.
Yajo
commented
Jul 26, 2016
|
Keep in mind that DNIe 3.0 disables the "open session once and use many times" behavior. It requires PIN for each use. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
miguel-cv
Jul 27, 2016
DNIe 3.0 has to establish a "pin channel" before entering "secure channel" . There's some initial work here:
https://github.com/germanblanco/OpenSC/tree/dnie_dnie30/
It fails passing from one channel to another...
miguel-cv
commented
Jul 27, 2016
|
DNIe 3.0 has to establish a "pin channel" before entering "secure channel" . There's some initial work here: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
frankmorgner
Aug 1, 2016
Member
@miguel-cv as far as I know, the SM channel is created using PACE. I have a complete implementation of EAC in #831 including PACE. The implementation is tested with various implementations in various situations, so I think it should meet your requirements. A quick way of checking if you can perform PACE with your PIN is to use npa-tool --pin.
My efforts to include EAC and PACE in OpenSC date back to 2012, so don't expect #831 to be final.
|
@miguel-cv as far as I know, the SM channel is created using PACE. I have a complete implementation of EAC in #831 including PACE. The implementation is tested with various implementations in various situations, so I think it should meet your requirements. A quick way of checking if you can perform PACE with your PIN is to use My efforts to include EAC and PACE in OpenSC date back to 2012, so don't expect #831 to be final. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
emunicio
Aug 23, 2016
Hi,
Same here with the DNIe 3.0. I get:
# dnie-tool -a
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
Error: Get info failed: Unsupported CLA byte in APDU
And when trying to read, it starts a loop that hungs Firefox.
With the old DNIe was working perfectly.
Kind regards
emunicio
commented
Aug 23, 2016
•
edited
Edited 1 time
-
emunicio
edited Aug 23, 2016
edited
-
Aug 23, 2016
|
Hi, Same here with the DNIe 3.0. I get: And when trying to read, it starts a loop that hungs Firefox. Kind regards |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Are there any test cards available from somewhere? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Is there a specification available? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
miguel-cv
Sep 20, 2016
As of today, we are missing the command manual for dni 3.0 . A command manual for the previous version is available (in spanish) at http://myslide.es/documents/20100930-manual-de-comandos-del-dnie-tractis.html
There is also a working driver at https://www.sede.fnmt.gob.es/descargas/descarga-software
and source for that at https://www.sede.fnmt.gob.es/documents/11614/4531260/MultiPKCS10_Fuentes+v_1_4_0.rar
In this last file, in comm_dnie.cpp is the code related to secure channel.
Will try npa-tool this weekend.
miguel-cv
commented
Sep 20, 2016
•
edited by frankmorgner
Edited 1 time
-
frankmorgner
edited Sep 20, 2016
edited by frankmorgner
-
Sep 20, 2016
|
As of today, we are missing the command manual for dni 3.0 . A command manual for the previous version is available (in spanish) at http://myslide.es/documents/20100930-manual-de-comandos-del-dnie-tractis.html |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Yajo
Sep 26, 2016
You can find everything about it in http://www.dnielectronico.es/, although everything is in Spanish. Be sure you use links for DNIe 3.0 (previous versions are different). If you need us to translate anything, just paste it here and ask for it
Yajo
commented
Sep 26, 2016
|
You can find everything about it in http://www.dnielectronico.es/, although everything is in Spanish. Be sure you use links for DNIe 3.0 (previous versions are different). If you need us to translate anything, just paste it here and ask for it |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 17, 2016
Contributor
Hi,
I have started to work in the DNIe 3.0 integration (I have a first working version that can sign but very shoddy). Besides I have the impression that there is something very wrong in the last versions of opendnie/opensc. I had to move to a previous version of opensc in order to make it work.
Can anybody test the last OpenSC code with a DNIe 2.0? Sorry, but I have now 3.0 and nobody I have asked for knows his damned pin. Please clone, compile and try to sign with the pkcs11-tool:
pkcs11-tool -d <auth_key_id> -s
I wrote a little entry in my blog with the major changes needed for 3.0 if you want to review what I'm doing:
|
Hi, I have started to work in the DNIe 3.0 integration (I have a first working version that can sign but very shoddy). Besides I have the impression that there is something very wrong in the last versions of opendnie/opensc. I had to move to a previous version of opensc in order to make it work. Can anybody test the last OpenSC code with a DNIe 2.0? Sorry, but I have now 3.0 and nobody I have asked for knows his damned pin. Please clone, compile and try to sign with the pkcs11-tool: pkcs11-tool -d <auth_key_id> -s I wrote a little entry in my blog with the major changes needed for 3.0 if you want to review what I'm doing: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
commented
Oct 17, 2016
|
I can access to a DNIe 2.0 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 18, 2016
Contributor
@miguel-cv told me yesterday that current opensc implementation of the DNIe is working with 2.0. So there should be something else here. I'll try to figure out what the hell is happening with the getResponse. This weekend I'll try to move all the changes again to the current opensc branch and I'll check it twice. I deeply worry that I'm going to need a DNIe 2.0 (besides my time this thing is going to cost me some beers and snacks).
|
@miguel-cv told me yesterday that current opensc implementation of the DNIe is working with 2.0. So there should be something else here. I'll try to figure out what the hell is happening with the getResponse. This weekend I'll try to move all the changes again to the current opensc branch and I'll check it twice. I deeply worry that I'm going to need a DNIe 2.0 (besides my time this thing is going to cost me some beers and snacks). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 19, 2016
Contributor
OK, I have the current OpenSC branch working now. The problem about the getResponse was that now we need to send something in the Le (>0) in order to force the getResponse to be called.
@germanblanco I see that you changed several apdus (for example in dnie_pin_verify) this way:
- dnie_format_apdu(card, &apdu, SC_APDU_CASE_3_SHORT, 0x22, p1, p2, 0, length,
- NULL, 0, buffer, length);
+ dnie_format_apdu(card, &apdu, SC_APDU_CASE_4_SHORT, 0x22, p1, p2, 255, length,
+ resp, MAX_RESP_BUFFER_SIZE, buffer, length);
So, you changed an APDU with no Le=0 (no response data) to another with Le>0 (now some response data is expected). Did you changed the APDUs for that reason?
Because now the secure channel is executed over the pin channel, and therefore I needed to change some other calls doing the same trick (cwa_verify_cvc_certificate, cwa_set_security_env,...).
Just a silly question, why not doing that in the wrapping method? Because the plain APDU has no return data expected (it is OK with Le=0), it is changed when wrapped cos the new apdu is of type 4 (the encoded response is the response data).
|
OK, I have the current OpenSC branch working now. The problem about the getResponse was that now we need to send something in the Le (>0) in order to force the getResponse to be called. @germanblanco I see that you changed several apdus (for example in dnie_pin_verify) this way: So, you changed an APDU with no Le=0 (no response data) to another with Le>0 (now some response data is expected). Did you changed the APDUs for that reason? Because now the secure channel is executed over the pin channel, and therefore I needed to change some other calls doing the same trick (cwa_verify_cvc_certificate, cwa_set_security_env,...). Just a silly question, why not doing that in the wrapping method? Because the plain APDU has no return data expected (it is OK with Le=0), it is changed when wrapped cos the new apdu is of type 4 (the encoded response is the response data). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 22, 2016
Contributor
Hi,
I have uploaded a first version for DNIe 3.0 in my repo. You can test it:
https://github.com/rickyepoderi/opensc/tree/dnie30
As you know I don't have easy access for a DNIe 2.0 so, if you can test it with both, it would be much appreciated. I'm going to try to understand why it is needed to send CASE 4 apdus instead of 3 now. Because I think it should be possible to send a SC_APDU_CASE_3_SHORT without any problems.
|
Hi, I have uploaded a first version for DNIe 3.0 in my repo. You can test it: https://github.com/rickyepoderi/opensc/tree/dnie30 As you know I don't have easy access for a DNIe 2.0 so, if you can test it with both, it would be much appreciated. I'm going to try to understand why it is needed to send CASE 4 apdus instead of 3 now. Because I think it should be possible to send a SC_APDU_CASE_3_SHORT without any problems. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 22, 2016
I have tested it with both.
DNI 2.0
mestres@tux ~/dni30/bin $ ./pkcs11-tool -l -O
Using slot 0 with a present token (0x0)
error: PKCS11 function C_Login failed: rv = CKR_ARGUMENTS_BAD (0x7)
Aborting.
mestres@tux ~/dni30/bin $ ./dnie-tool -V
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
DNIe Version: DNIe 01.13 B11 H 4C34 EXP 1-((4.2-5))
DNI 3.0
mestres@tux ~/dni30/bin $ ./pkcs11-tool -l -O
Using slot 0 with a present token (0x0)
Segmentation fault
mestres@tux ~/dni30/bin $ ./dnie-tool -V
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
Failed to connect to card: Card is invalid or cannot be handled
Error: Cannot connect with card
cameta
commented
Oct 22, 2016
|
I have tested it with both. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 23, 2016
Contributor
@cameta I can believe you with DNIe 2.0 because I haven't tested anything with it. But with DNIe 3.0 it's weird because it's working for me:
ricky@magneto:/apps/opensc/bin$ ./dnie-tool -V/apps/opensc/bin$ ./pkcs11-tool -l -O
Using reader with a card: Broadcom Corp 5880 Contacted SmartCard 00 00
DNIe Version: DNIe 04.10 B5 H 0155 EXP 2-(5.2-0)
ricky@magneto:
Using slot 0 with a present token (0x0)
Logging in to "PIN1 (DNI electrónico)".
Please enter User PIN:
Private Key Object; RSA
label: KprivAutenticacion
ID: 4130323035424244453037304631423230313631303130303835363237
Usage: sign
Certificate Object, type = X.509 cert
label: CertAutenticacion
ID: 4130323035424244453037304631423230313631303130303835363237
Public Key Object; RSA 2048 bits
label: CertAutenticacion
ID: 4130323035424244453037304631423230313631303130303835363237
Usage: encrypt, verify
Certificate Object, type = X.509 cert
label: CertCAIntermediaDGP
ID: 5330323035424244453037304631423230313631303130303835363237
Public Key Object; RSA 2048 bits
label: CertCAIntermediaDGP
ID: 5330323035424244453037304631423230313631303130303835363237
Usage: encrypt, verify
Private Key Object; RSA
label: KprivFirmaDigital
ID: 4630323035424244453037304631423230313631303130303835363237
Usage: sign, non-repudiation
Certificate Object, type = X.509 cert
label: CertFirmaDigital
ID: 4630323035424244453037304631423230313631303130303835363237
Public Key Object; RSA 2048 bits
label: CertFirmaDigital
ID: 4630323035424244453037304631423230313631303130303835363237
Usage: encrypt, verify
Data object 14532512
label: 'DG1'
application: ''
app_id:
flags: modifiable
Data object 14532608
label: 'DG11'
application: ''
app_id:
flags: modifiable
Data object 14532704
label: 'DG13'
application: ''
app_id:
flags: modifiable
Data object 14526976
label: 'DG2'
application: ''
app_id:
flags: modifiable
Data object 14527072
label: 'DG7'
application: ''
app_id:
flags: modifiable
Data object 14527168
label: 'DG3'
application: ''
app_id:
flags: modifiable
Data object 14527264
label: 'DG14'
application: ''
app_id:
flags: modifiable
Data object 14527360
label: 'EFCOM'
application: ''
app_id:
flags: modifiable
Data object 14527456
label: 'EFSOD'
application: ''
app_id:
flags: modifiable
|
@cameta I can believe you with DNIe 2.0 because I haven't tested anything with it. But with DNIe 3.0 it's weird because it's working for me: ricky@magneto: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 23, 2016
My DNI 2.0 is working with opensc-0.16.0
dnie-tool -V
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
DNIe Version: DNIe 01.13 B11 H 4C34 EXP 1-((4.2-5))
cameta
commented
Oct 23, 2016
|
My DNI 2.0 is working with opensc-0.16.0 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
commented
Oct 23, 2016
|
You might have a different version of the DNI 3.0 that mine. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 23, 2016
Contributor
@cameta dni-tool works for DNIe 3.0 even in the 0.16 version. The only problem is that you cannot login. It works with 0.16.0 debian testing. So I think you have something weird with your DNIe 3.0:
ricky@magneto:~/apps/opensc/bin$ which dnie-tool
/usr/bin/dnie-tool
ricky@magneto:~/apps/opensc/bin$ dpkg -l | grep opensc
ii opensc 0.16.0-1 amd64 Smart card utilities with support for PKCS#15 compatible cards
ii opensc-pkcs11:amd64 0.16.0-1 amd64 Smart card utilities with support for PKCS#15 compatible cards
ricky@magneto:~/apps/opensc/bin$ dnie-tool -V
Using reader with a card: Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00
DNIe Version: DNIe 04.10 B5 H 0155 EXP 2-(5.2-0)
With DNIe 2.0 I suppose that something is broken in my branch. I will need one to check what happens. I'll try to figure it out but it is going long because I have no easy access to a 2.0.
|
@cameta dni-tool works for DNIe 3.0 even in the 0.16 version. The only problem is that you cannot login. It works with 0.16.0 debian testing. So I think you have something weird with your DNIe 3.0: With DNIe 2.0 I suppose that something is broken in my branch. I will need one to check what happens. I'll try to figure it out but it is going long because I have no easy access to a 2.0. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 23, 2016
My identity card works in the machine of the police. Could the fault be in my reader?
cameta
commented
Oct 23, 2016
|
My identity card works in the machine of the police. Could the fault be in my reader? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 23, 2016
Contributor
@cameta Don't forget to checkout the branch dnie30 (master is just default OpenSC a few days ago, and now DNIe 3.0 is directly excluded in default):
git clone https://github.com/rickyepoderi/OpenSC.git
cd OpenSC
git checkout dnie30
./bootstrap
./configure --enable-dnie-ui --prefix=/donde/quieras
|
@cameta Don't forget to checkout the branch dnie30 (master is just default OpenSC a few days ago, and now DNIe 3.0 is directly excluded in default): |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
miguel-cv
Oct 24, 2016
tested, works well for me with 2.0 and 3.0 .
@cameta remember to enable_pinpad = false in opensc.conf
and
card_driver dnie {
# Disable / enable warning message when performing a
# signature operation with the DNIe.
# Only used if compiled with --enable-dnie-ui
user_consent_enabled = yes;
# Specify the pinentry application to use if warning
# is configured to be displayed using pinentry.
# Default: /usr/bin/pinentry
# Only used if compiled with --enable-dnie-ui
user_consent_app = "/usr/bin/pinentry";
}
miguel-cv
commented
Oct 24, 2016
|
tested, works well for me with 2.0 and 3.0 . |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
emunicio
Oct 24, 2016
@rickyepoderi I get the error when compiling:
pkcs15-lib.c:2214:23: error: dereferencing pointer to incomplete type
GETBN(key->iqmp, rsa->iqmp, iqmp);
Am I missing something? I'm compiling with g++ 4.9.2
emunicio
commented
Oct 24, 2016
|
@rickyepoderi I get the error when compiling: pkcs15-lib.c:2214:23: error: dereferencing pointer to incomplete type Am I missing something? I'm compiling with g++ 4.9.2 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 24, 2016
Contributor
@emunicio Not related to my changes (I haven't modified anything in pkcs15) but it sounds related to openssl. Which version do you have?
|
@emunicio Not related to my changes (I haven't modified anything in pkcs15) but it sounds related to openssl. Which version do you have? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
emunicio
Oct 24, 2016
@rickyepoderi
I have: OpenSSL 1.1.0 25 Aug 2016
Anyway, thanks. I will try to find out what is happening with openssl
emunicio
commented
Oct 24, 2016
•
edited
Edited 1 time
-
emunicio
edited
Oct 24, 2016
edited
-
Oct 24, 2016
|
@rickyepoderi |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Oct 24, 2016
Member
@emunicio
Try using at least OpenSSL 1.1.0.a I don't get the error with:
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
OpenSSL 1.1.0a 22 Sep 2016
In my source from github master 0362439
GETBN(key->iqmp, rsa->iqmp, iqmp); is line 2213, not 2214. Do you have and extra line in your source?
|
@emunicio In my source from github master 0362439 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 25, 2016
Contributor
@emunicio @dengert In my branch is at line 2214 because I updated it when I started the work in 3.0 (two or three weeks ago):
https://github.com/rickyepoderi/OpenSC/blob/dnie30/src/pkcs15init/pkcs15-lib.c#L2214
I suppose some new change was made to that file during thatperiod. As I said, "pkcs15-lib.c" isn't modified in my dnie30 branch (indeed changes are exclusively related to DNIe files).
|
@emunicio @dengert In my branch is at line 2214 because I updated it when I started the work in 3.0 (two or three weeks ago): https://github.com/rickyepoderi/OpenSC/blob/dnie30/src/pkcs15init/pkcs15-lib.c#L2214 I suppose some new change was made to that file during thatperiod. As I said, "pkcs15-lib.c" isn't modified in my dnie30 branch (indeed changes are exclusively related to DNIe files). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Oct 25, 2016
Member
Looking closer pkcs15init/pkcs15-lib.c , It looks like it had problems before converting to OpenSSL-1.1.0.
These two line a a clue to what may be going on:
2209 /* Not thread safe, but much better than a memory leak /
2210 / TODO put on stack, or allocate and clear and then free */
There are 3 GETBN macro calls. Your compiler flagged only the last one.
key->iqmp is calculated in the routine and set to point at a static u8 iqmp[256];
That may be why the third GETBN gets the error and not the other two.
This routine needs to be rewritten and tested. (I can rewrite it, but someone else who uses it needs to test it.) (I will look at it tommorrow.)
|
Looking closer pkcs15init/pkcs15-lib.c , It looks like it had problems before converting to OpenSSL-1.1.0. These two line a a clue to what may be going on: This routine needs to be rewritten and tested. (I can rewrite it, but someone else who uses it needs to test it.) (I will look at it tommorrow.) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Oct 25, 2016
Member
The problem could be in SM code in OpenSC, in combination with the
reader and the card. The APDU code looks at the protocol being used
T=0 or T=1. T=1 is block mode and Le is sent to the card so it can
return the first block without requiring a getResponse In T=0 all
data is returned via getResponses
What readers are each of you using?
Some only do T=0 some can do T=1.
Some cards can only do T=0.
OpenSC debugging traces would show if T=0 or T=1 is being used.
With SM encrypting the APDU, when using T=1 might require the Le to
be sent and a buffer provided.
(I could be all wrong, but debugging traces would help a lot.)
On 10/23/2016 2:04 PM, cameta wrote:
My identity card works in the machine of the police. Could the
fault be in my reader?
—
You are receiving this because you are subscribed to this
thread.
Reply to this email directly, view
it on GitHub, or mute
the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/OpenSC/OpenSC","title":"OpenSC/OpenSC","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/OpenSC/OpenSC"}},"updates":{"snippets":[{"icon":"PERSON","message":"@cameta in #810: My identity card works in the machine of the police. Could the fault be in my reader? "}],"action":{"name":"View Issue","url":"https://github.com/OpenSC/OpenSC/issues/810#issuecomment-255607376"}}}
--
Douglas E. Engert DEEngert@gmail.com
Douglas E. Engert DEEngert@gmail.com |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 25, 2016
The code (after the edit of opensc.conf) now works for me with a DNI 2.0
mestres@tux ~/DNIE/bin $ ./pkcs11-tool -l -O
Using slot 0 with a present token (0x0)
Logging in to "PIN1 (DNI electrónico)".
Please enter User PIN:
mestres@tux ~/DNIE/bin $ ./dnie-tool -V
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
DNIe Version: DNIe 01.13 B11 H 4C34 EXP 1-((4.2-5))
The code doesn't work with a DNI 3.0
mestres@tux ~/DNIE/bin $ ./pkcs11-tool -l -O
error: PKCS11 function C_GetSlotInfo failed: rv = CKR_GENERAL_ERROR (0x5)
Aborting.
mestres@tux ~/DNIE/bin $ ./dnie-tool -V
Using reader with a card: C3PO LTC31 v2 (00509883) 00 00
Error: Get info failed: Unsupported INS byte in APDU
My card reader is a : USB SMARTCARD READER
usb 3-1: Manufacturer: C3PO (the manufacturer is out of business for bankruptcy)
cameta
commented
Oct 25, 2016
|
The code (after the edit of opensc.conf) now works for me with a DNI 2.0 My card reader is a : USB SMARTCARD READER |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 26, 2016
Contributor
@cameta Very strange that even the dnie-tool -V gives you an error (all the modifications are inside the channel creation and dnie-tool does not initiate a login).
Put debug=9 in the opensc.conf file and execute the dnie-tool command to save the stderr to a file:
./dnie-tool -V 2>out.txt
And attach the file here. Let's see if I see something.
rickyepoderi
commented
Oct 26, 2016
•
edited
Edited 1 time
-
rickyepoderi
edited Oct 26, 2016
edited
-
Oct 26, 2016
|
@cameta Very strange that even the dnie-tool -V gives you an error (all the modifications are inside the channel creation and dnie-tool does not initiate a login). Put debug=9 in the opensc.conf file and execute the dnie-tool command to save the stderr to a file: And attach the file here. Let's see if I see something. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 26, 2016
I think the problem is with the card reader. Such as you have asked me here is the debug from both the 2.0 and the 3.0 DNI.
outDNI20.txt
outDNI30.txt
cameta
commented
Oct 26, 2016
|
I think the problem is with the card reader. Such as you have asked me here is the debug from both the 2.0 and the 3.0 DNI. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
I saw the issue of this reader, check #201 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 27, 2016
Contributor
The problem is in the APDU when reading the file "3F0050156004" (the first APDU inside dnie_get_info function). In DNI 3.0 when the file is read the card return an error (6D means "Instruction code not programmed or invalid"):
`Outgoing APDU (16 bytes):
00 A4 04 00 0B 4D 61 73 74 65 72 2E 46 69 6C 65 .....Master.File
0x7f0ce7195700 23:43:11.421 [dnie-tool] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7f0ce7195700 23:43:11.422 [dnie-tool] reader-pcsc.c:279:pcsc_transmit:
Incoming APDU (2 bytes):
6D 00 m.
Nevertheless the same APDU in 2.0 (same APDU and same reader) returns OK (61XX is good and means get_response to be called):
Outgoing APDU (16 bytes):
00 A4 04 00 0B 4D 61 73 74 65 72 2E 46 69 6C 65 .....Master.File
0x7fb13b342700 23:42:50.972 [dnie-tool] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7fb13b342700 23:42:50.991 [dnie-tool] reader-pcsc.c:279:pcsc_transmit:
Incoming APDU (2 bytes):
61 1B a.
It's the same APDU and before any of my changes. I would say that something is wrong with your DNIe physical card because 2.0 works and it's the same reader and the same code, but I really don't know.
|
The problem is in the APDU when reading the file "3F0050156004" (the first APDU inside dnie_get_info function). In DNI 3.0 when the file is read the card return an error (6D means "Instruction code not programmed or invalid"): Nevertheless the same APDU in 2.0 (same APDU and same reader) returns OK (61XX is good and means get_response to be called): It's the same APDU and before any of my changes. I would say that something is wrong with your DNIe physical card because 2.0 works and it's the same reader and the same code, but I really don't know. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Oct 27, 2016
I'll test again the DNI in the police station and I'll buy another card reader. Thanks for all.
cameta
commented
Oct 27, 2016
|
I'll test again the DNI in the police station and I'll buy another card reader. Thanks for all. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Oct 27, 2016
Member
@cameta Looking at https://github.com/OpenSC/OpenSC/files/554497/outDNI20.txt and https://github.com/OpenSC/OpenSC/files/554498/outDNI30.txt
The ATR in the first is: 3b:7f:38:00:00:00:6a:44:4e:49:65:20:02:4c:34:01:13:03:90:00
and ATR in second is: 3b:7f:96:00:00:00:6a:44:4e:49:65:20:01:01:55:04:10:03:90:00
The DNIe 3 code is testing in may places for:
(card->atr.value[15] >= DNIE_30_VERSION) that is defined as 4
Is this the same card?
You said you changed the opensc.conf did you force an ATR?
If you did, the code is assuming a DNIe 3.0 card.
A pcscd debug output would show the ATR before OpenSC code gets control.
|
@cameta Looking at https://github.com/OpenSC/OpenSC/files/554497/outDNI20.txt and https://github.com/OpenSC/OpenSC/files/554498/outDNI30.txt The DNIe 3 code is testing in may places for: Is this the same card? A pcscd debug output would show the ATR before OpenSC code gets control. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Oct 27, 2016
Contributor
@cameta I have just tested with my DNIe 3.0 and that APDU is sent exactly as in your 2.0 (no problem):
Outgoing APDU (16 bytes):
00 A4 04 00 0B 4D 61 73 74 65 72 2E 46 69 6C 65 .....Master.File
0x7ff89b2b8700 19:27:19.473 [dnie-tool] reader-pcsc.c:199:pcsc_internal_transmit: called
0x7ff89b2b8700 19:27:19.481 [dnie-tool] reader-pcsc.c:279:pcsc_transmit:
Incoming APDU (2 bytes):
61 1B a.
@dengert The ATR is ok, the atr.value[15] is 01 in DNIe 2.0 and 04 in DNIe 3.0. So it's as expected. Think that dnie-tool does not even use any of the changes required for DNIe 3.0, as I said in a comment above, opensc 0.16 can do a dnie-tool with a DNIe 3.0 (because it was excluded from the match later).
@miguel-cv has tested my changes OK with 2.0 and 3.0. And I have changed my mind and I think now that changing something for the CASE 4 apdus is a mess and I would require changes in non dnie code. So I think is better to first add support to 3.0 and re-think that later.
My idea is the following: give more time (some days) and let other people test my changes (I'm waiting the confirmation from some friends) and then submit a pull request. How do you see it?
|
@cameta I have just tested with my DNIe 3.0 and that APDU is sent exactly as in your 2.0 (no problem): @dengert The ATR is ok, the atr.value[15] is 01 in DNIe 2.0 and 04 in DNIe 3.0. So it's as expected. Think that dnie-tool does not even use any of the changes required for DNIe 3.0, as I said in a comment above, opensc 0.16 can do a dnie-tool with a DNIe 3.0 (because it was excluded from the match later). @miguel-cv has tested my changes OK with 2.0 and 3.0. And I have changed my mind and I think now that changing something for the CASE 4 apdus is a mess and I would require changes in non dnie code. So I think is better to first add support to 3.0 and re-think that later. My idea is the following: give more time (some days) and let other people test my changes (I'm waiting the confirmation from some friends) and then submit a pull request. How do you see it? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Nov 29, 2016
Member
Note on that web page, it also says:
"Plug & play on Windows and GNU / Linux."
"GNU / Linux that incorporate OpenSC."
I agree with @frankmorgner
I would also look close at the keyUsage extensions of the certificates to see if the AUTH key does not have non-repudiation and the SIGN key does.
If there are other certificates/keys on the card, such as a key management key used for encrypted traffic, does it also have the same issue? What are the keyUsage bits in its certificate?
Also look closer that some how the SM channel is not getting reset and causing the card security state to change.
|
Note on that web page, it also says: I agree with @frankmorgner I would also look close at the keyUsage extensions of the certificates to see if the AUTH key does not have non-repudiation and the SIGN key does. If there are other certificates/keys on the card, such as a key management key used for encrypted traffic, does it also have the same issue? What are the keyUsage bits in its certificate? Also look closer that some how the SM channel is not getting reset and causing the card security state to change. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Nov 29, 2016
Contributor
I would also look close at the keyUsage extensions of the certificates to see if the AUTH key does not have non-repudiation and the SIGN key does.
Yes, it's exactly like this, You can see it above in my output of pkcs11-tool -l -O
label: KprivAutenticacion
ID: 4130323035424244453037304631423230313631303130303835363237
Usage: sign
label: KprivFirmaDigital
ID: 4630323035424244453037304631423230313631303130303835363237
Usage: sign, non-repudiation
If there are other certificates/keys on the card, such as a key management key used for encrypted traffic, does it also have the same issue? What are the keyUsage bits in its certificate?
No more private keys, just those two.
Also look closer that some how the SM channel is not getting reset and causing the card security state to change.
I'll try tomorrow to test if I can verify (with a Public Key) a lot of times and just perform one signature with the authentication private key. But @miguel-cv has also confirmed that the problem happens with both keys (and remember the bug in official implementation was also with the authentication key in firefox).
Yes, it's exactly like this, You can see it above in my output of pkcs11-tool -l -O label: KprivAutenticacion
No more private keys, just those two.
I'll try tomorrow to test if I can verify (with a Public Key) a lot of times and just perform one signature with the authentication private key. But @miguel-cv has also confirmed that the problem happens with both keys (and remember the bug in official implementation was also with the authentication key in firefox). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
germanblanco
Nov 30, 2016
Contributor
|
I go with the idea of caching credentials for authentication and requesting
the pin again for signing. I also would prefer to use the standard
configuration options of opensc to handle caching, instead of doing this
internally in dnie code. So that is Option 3.
In my view, this complies with the document EN 14890.
If I recall correctly the official driver on Windows requests confirmation
for every signature process, but it doesn't require confirmation for
authentication in every action. I think we should mimic their behavior to
ensure that we are compliant with the rules of use of DNIe.
…On Tue, Nov 29, 2016 at 11:10 PM, rickyepoderi ***@***.***> wrote:
I would also look close at the keyUsage extensions of the certificates to
see if the AUTH key does not have non-repudiation and the SIGN key does.
Yes, it's exactly like this, You can see it above in my output of
pkcs11-tool -l -O
label: KprivAutenticacion
ID: 4130323035424244453037304631423230313631303130303835363237
Usage: sign
label: KprivFirmaDigital
ID: 4630323035424244453037304631423230313631303130303835363237
Usage: sign, non-repudiation
If there are other certificates/keys on the card, such as a key management
key used for encrypted traffic, does it also have the same issue? What are
the keyUsage bits in its certificate?
No more private keys, just those two.
Also look closer that some how the SM channel is not getting reset and
causing the card security state to change.
I'll try tomorrow to test if I can verify (with a Public Key) a lot of
times and just perform one signature with the authentication private key.
But @miguel-cv <https://github.com/miguel-cv> has also confirmed that the
problem happens with both keys (and remember the bug in official
implementation was also with the authentication key in firefox).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#810 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADw7Izjn31TrGSVf1r75vn65rbdFo21Rks5rDKLTgaJpZM4I-hbl>
.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Nov 30, 2016
Contributor
@frankmorgner
I tried today to do a little test to the recommended solution (sign key CKA_ALWAYS_AUTHENTICATE=1 and the authentication not) but the pin cache doesn't work in that case. The pin is not stored cos there is another key which is CHA_ALWAYS_AUTHENTICATE. See this line:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pin.c#L675
Indeed this is a double check cos when doing the sc_pkcs15_pincache_revalidate it is again checked if the key is CKA_ALWAYS_REVALIDATE. I tried to put the keys in different authid but in that case I cannot see both keys doing C_FindObjects. Am I missing something?
|
@frankmorgner https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pin.c#L675 Indeed this is a double check cos when doing the sc_pkcs15_pincache_revalidate it is again checked if the key is CKA_ALWAYS_REVALIDATE. I tried to put the keys in different authid but in that case I cannot see both keys doing C_FindObjects. Am I missing something? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
frankmorgner
Nov 30, 2016
Member
Do you have a single PIN that protects both, the authentication and the signature key? The code you referenced refuses to cache the PIN if there is some key that requires consent, although there may be others that don't require consent. Although this approach is very sane, it's also very inflexible.
An alternative could be to evaluate the consent property when the key is actually used and not when the pin is about to be cached. This approach seems to be taken by your "official" implementation... Do you think the latter approach could be mimicked within your card driver?
|
Do you have a single PIN that protects both, the authentication and the signature key? The code you referenced refuses to cache the PIN if there is some key that requires consent, although there may be others that don't require consent. Although this approach is very sane, it's also very inflexible. An alternative could be to evaluate the consent property when the key is actually used and not when the pin is about to be cached. This approach seems to be taken by your "official" implementation... Do you think the latter approach could be mimicked within your card driver? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Dec 1, 2016
Contributor
Do you have a single PIN that protects both, the authentication and the signature key? The code you referenced refuses to cache the PIN if there is some key that requires consent, although there may be others that don't require consent. Although this approach is very sane, it's also very inflexible.
Yes, DNIe has only one pin for everything. And that part of code avoids the use of the pin cache if there's one key with CKA_ALWAYS_AUTHENTICATE. Therefore the option (3) is not an option anymore.
An alternative could be to evaluate the consent property when the key is actually used and not when the pin is about to be cached. This approach seems to be taken by your "official" implementation... Do you think the latter approach could be mimicked within your card driver?
it is indeed like this right now, if the key is marked as CKA_ALWAYS_AUTHENTICATE in the revalidate the use of the cache is avoided if not explicitly set in the pin_cache_ignore_user_consent (that's why I said it is double checked):
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pin.c#L718
In summary, right now we cannot go for the option (3). Only 1, 2 or 4.
Yes, DNIe has only one pin for everything. And that part of code avoids the use of the pin cache if there's one key with CKA_ALWAYS_AUTHENTICATE. Therefore the option (3) is not an option anymore.
it is indeed like this right now, if the key is marked as CKA_ALWAYS_AUTHENTICATE in the revalidate the use of the cache is avoided if not explicitly set in the pin_cache_ignore_user_consent (that's why I said it is double checked): https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pin.c#L718 In summary, right now we cannot go for the option (3). Only 1, 2 or 4. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
frankmorgner
Dec 1, 2016
Member
As said above, you could also check whether you can mimic the official behavior in the DNIe card driver.
Anyway, there is (yet) an other approach:
- Force caching of the PIN (either by removing
CKA_ALWAYS_AUTHENTICATEor by forcingpin_cache_ignore_user_consent) and explicitly ask the user for consent when using the non-repudiation key. DNIe already has this logic for user interaction already.
|
As said above, you could also check whether you can mimic the official behavior in the DNIe card driver. Anyway, there is (yet) an other approach:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Dec 1, 2016
Member
This is a little off topic, but does the DNIe3 and the SM allow for creating a session PIN? I think Windows has such a concept, but don't know of any cards that support this. I forgot what Windows calls it, but it sounds like it is to avoid caching the real PIN, caching the session PIN instead. This would allow for using the card with a PIN PAD reader.
|
This is a little off topic, but does the DNIe3 and the SM allow for creating a session PIN? I think Windows has such a concept, but don't know of any cards that support this. I forgot what Windows calls it, but it sounds like it is to avoid caching the real PIN, caching the session PIN instead. This would allow for using the card with a PIN PAD reader. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Dec 8, 2016
Contributor
I interchanged some emails with @germanblanco and @miguel-cv and we decided to finally go without any CKA_ALWAYS_AUTHENTICATE and reuse the opensc pin cache for both keys. This way opensc will use the same solution that the official implementation is using after the fix.
The three of us agree with the idea of using CKA_ALWAYS_AUTHENTICATE in the non-repudiation key and the cache for the other but that option is complicated right now and we'll try to go for it later. Besides I personally think that option 4 (using our own cache) is a nonsense.
So I'm going to recheck my dnie30b branch with both DNIe types (today I have access to a 2.0 DNIe) and submit another pull request.
|
I interchanged some emails with @germanblanco and @miguel-cv and we decided to finally go without any CKA_ALWAYS_AUTHENTICATE and reuse the opensc pin cache for both keys. This way opensc will use the same solution that the official implementation is using after the fix. The three of us agree with the idea of using CKA_ALWAYS_AUTHENTICATE in the non-repudiation key and the cache for the other but that option is complicated right now and we'll try to go for it later. Besides I personally think that option 4 (using our own cache) is a nonsense. So I'm going to recheck my dnie30b branch with both DNIe types (today I have access to a 2.0 DNIe) and submit another pull request. |
frankmorgner
referenced this issue
Dec 12, 2016
Closed
Lost change in the previous pull request and disable sm mode too. #914
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Dec 24, 2016
Contributor
Once the #914 request is merged the DNIe 3.0 should work with current default branch (I have tested with 3.0 and 2.0 and everything looks fine). I think this issue is finished and future enhancements or bugs will be dealt in new issue numbers. Thanks everybody involved here.
Nevertheless I wanted to continue with the idea of making the non-repudiation key CKA_ALWAYS_AUTHENTICATE...
@frankmorgner @dengert What do you think about the idea of the three configuration values for the pin_cache_ignore_user_consent option? (Explained in the pull request). I will implement and test it if you think it is valuable.
|
Once the #914 request is merged the DNIe 3.0 should work with current default branch (I have tested with 3.0 and 2.0 and everything looks fine). I think this issue is finished and future enhancements or bugs will be dealt in new issue numbers. Thanks everybody involved here. Nevertheless I wanted to continue with the idea of making the non-repudiation key CKA_ALWAYS_AUTHENTICATE... @frankmorgner @dengert What do you think about the idea of the three configuration values for the pin_cache_ignore_user_consent option? (Explained in the pull request). I will implement and test it if you think it is valuable. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Dec 29, 2016
Member
Some of the flags should be on a card bases. For some cards, CKA_ALWAYS_AUTHENTICATE is used to enforce a policy, and the card may also enforce it. I would not like to see us add too many flags that make it easy to violate the policies of the card issuer. But for the DNIE, it sounds like the card has set CKA_ALWAYS_AUTHENTICATE by mistake for all keys.
If you can call it something like pin_cache_ignore_user_consent_for_buggy cards, and then only use it for the buggy cards i.e. DNIE 3.0 that would be OK with me.
|
Some of the flags should be on a card bases. For some cards, CKA_ALWAYS_AUTHENTICATE is used to enforce a policy, and the card may also enforce it. I would not like to see us add too many flags that make it easy to violate the policies of the card issuer. But for the DNIE, it sounds like the card has set CKA_ALWAYS_AUTHENTICATE by mistake for all keys. If you can call it something like pin_cache_ignore_user_consent_for_buggy cards, and then only use it for the buggy cards i.e. DNIE 3.0 that would be OK with me. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Dec 29, 2016
Contributor
Take in mind that adding a third option helps in a case that is possible with a perfect (not buggy) card. Imagine a card with two or more keys under the same pin, and only one of them is CKA_ALWAYS_AUTHENTICATE, then the cache cannot be used for all the normal keys (if pin_cache_ignore_user_consent=false cache is forbidden for all the keys, if pin_cache_ignore_user_consent=true cache is admitted for all). So the new option is intended to cover that workable case (the new option would store the pin in the cache but only would be permitted its use for the non CKA_ALWAYS_AUTHENTICATE keys). Nevertheless I understand your reservations about this point, that's why I'm asking...
|
Take in mind that adding a third option helps in a case that is possible with a perfect (not buggy) card. Imagine a card with two or more keys under the same pin, and only one of them is CKA_ALWAYS_AUTHENTICATE, then the cache cannot be used for all the normal keys (if pin_cache_ignore_user_consent=false cache is forbidden for all the keys, if pin_cache_ignore_user_consent=true cache is admitted for all). So the new option is intended to cover that workable case (the new option would store the pin in the cache but only would be permitted its use for the non CKA_ALWAYS_AUTHENTICATE keys). Nevertheless I understand your reservations about this point, that's why I'm asking... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
davernos
Jan 11, 2017
Ubuntu 16.10 & opensc 0.16.0-1ubuntu2. Firefox 50 keeps asking for password on DNIe 3.
I've downloaded and compiled the DNIe tester. This is the result:
./dnie-pkcs11-tester -l
password:
Starting check_dnie_inserted...
Found 1 slots...
Found slot: 0 - "Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00 Cherry GmbH "
�"Found token: "DNI electrónico (PIN1) DGP-FNMT PKCS#15 emulated0205A10016130F
Found DNIe at slot 0
Starting check_login...
Session status: CKS_RW_PUBLIC_SESSION
Error in C_Login [CKR_GENERAL_ERROR]
The password is correct, tested on Windows 10 w/o problems.
davernos
commented
Jan 11, 2017
|
Ubuntu 16.10 & opensc 0.16.0-1ubuntu2. Firefox 50 keeps asking for password on DNIe 3. ./dnie-pkcs11-tester -l The password is correct, tested on Windows 10 w/o problems. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Jan 12, 2017
Contributor
@davernos Thanks for testing, we need more people doing it.
I would need the debug, put the level debug to 9 in opensc.conf and execute the tester redirecting the error to a file:
./dnie-pkcs11-tester -l 2>/path/to/file.dump
And attach the file here. Please be aware that there are some sensible information in the file (dnie, names, password,...). I recommend you to change that information for asterisks or something similar.
|
@davernos Thanks for testing, we need more people doing it. I would need the debug, put the level debug to 9 in opensc.conf and execute the tester redirecting the error to a file: And attach the file here. Please be aware that there are some sensible information in the file (dnie, names, password,...). I recommend you to change that information for asterisks or something similar. |
davernos
commented
Jan 12, 2017
|
Ok, heres the debug file. Please, let me know if I left any sensible information. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Jan 12, 2017
Contributor
Ok, the error is just after the sc_reset:
0x7fec9f630700 12:35:29.520 [opensc-pkcs11] reader-pcsc.c:228:pcsc_internal_transmit: Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00:SCardTransmit/Control failed: 0x80100068
This happens to me from time to time (although it is very rare). That is why I was investigating removing the sc_reset. Can you try with this branch? (This one has no sc_reset.)
https://github.com/rickyepoderi/opensc/tree/new-sm
It's the same but using my repo and the new-sm branch:
git clone https://github.com/rickyepoderi/OpenSC.git
cd OpenSC
git checkout new-sm
# compile and so on
|
Ok, the error is just after the sc_reset: This happens to me from time to time (although it is very rare). That is why I was investigating removing the sc_reset. Can you try with this branch? (This one has no sc_reset.) https://github.com/rickyepoderi/opensc/tree/new-sm It's the same but using my repo and the new-sm branch: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dengert
Jan 12, 2017
Member
debug.zip was against 0.16.0. But master has a number of changes to improve PC/SC debugging and to handling of failures of any PC/SC SCard command.
There is some question as to how soon after a reset is done can the next PC/SC command be done. The reset may have been from a processs that does not show up in the debug log.
I see:
Line 13194: 0x7fec9f630700 12:35:28.696 [opensc-pkcs11] cwa14890.c:1088:cwa_create_secure_channel: Resseting card
with what appears to be the next PC/SC operation being:
line 13228: 0x7fec9f630700 12:35:29.520 [opensc-pkcs11] reader-pcsc.c:463:pcsc_reconnect: Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00:SCardReconnect failed: 0x80100066
|
debug.zip was against 0.16.0. But master has a number of changes to improve PC/SC debugging and to handling of failures of any PC/SC SCard command. There is some question as to how soon after a reset is done can the next PC/SC command be done. The reset may have been from a processs that does not show up in the debug log. I see: |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
davernos
Jan 13, 2017
Ok, I can confirm its working now with the "new-sm" branch.
$ ./dnie-pkcs11-tester -l 2> dnietester.dump
password:
Starting check_dnie_inserted...
Found 1 slots...
Found slot: 0 - "Cherry GmbH SmartBoard XX44 [Smart Card Reader USB] 00 00 Cherry GmbH "
�"Found token: "PIN1 (DNI electrónico) DGP-FNMT PKCS#15 emulated0205A10016130F
Found DNIe at slot 0
Starting check_login...
Session status: CKS_RW_PUBLIC_SESSION
Session status: CKS_RW_USER_FUNCTIONS
login OK
Firefox is now accepting my password and certificate is working correctly.
Let me know if you need more debug info or more tests.
Thanks for your time and effort.
davernos
commented
Jan 13, 2017
|
Ok, I can confirm its working now with the "new-sm" branch. Firefox is now accepting my password and certificate is working correctly. Let me know if you need more debug info or more tests. |
rickyepoderi
referenced this issue
Jan 13, 2017
Closed
Use struct sm_cwa_session from sm.h in dnie #930
added a commit
to frankmorgner/OpenSC
that referenced
this issue
Feb 27, 2017
added a commit
to frankmorgner/OpenSC
that referenced
this issue
Feb 27, 2017
added a commit
to frankmorgner/OpenSC
that referenced
this issue
Feb 27, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Can we close this issue? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Mar 3, 2017
Contributor
IMHO yes, you can. I think that dnie is working and, if some bug appears, I'll fix it opening another issue (like I'm already doing).
|
IMHO yes, you can. I think that dnie is working and, if some bug appears, I'll fix it opening another issue (like I'm already doing). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
OK, thanks! |
frankmorgner
closed this
Mar 3, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Yajo
commented
Mar 5, 2017
|
Sorry, in which version was this fixed? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Mar 5, 2017
Contributor
No version yet. Right now it's in the master branch and it will be in 0.17 when it comes out.
|
No version yet. Right now it's in the master branch and it will be in 0.17 when it comes out. |
added a commit
to frankmorgner/OpenSC
that referenced
this issue
Mar 20, 2017
added a commit
to frankmorgner/OpenSC
that referenced
this issue
Mar 20, 2017
added a commit
that referenced
this issue
Mar 20, 2017
added a commit
to jpki/OpenSC
that referenced
this issue
Apr 10, 2017
Raulvo
commented
May 15, 2017
|
I am on Ubuntu 17.04 which ships with opensc 0.16 and testing with pkcs-tool ( |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dcristob
Jun 10, 2017
I have cloned master branch, built it successfully but I still have the same issue with a dnie 3.0 (recurring window pin entry). Can anyone point me to the correct branch to use? Thanks
dcristob
commented
Jun 10, 2017
|
I have cloned master branch, built it successfully but I still have the same issue with a dnie 3.0 (recurring window pin entry). Can anyone point me to the correct branch to use? Thanks |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
cameta
Jun 10, 2017
I have a working DNIE 3.0 witjh the master branch.
You can test your DNIE with this.
https://github.com/rickyepoderi/dnie-pkcs11-tester
cameta
commented
Jun 10, 2017
|
I have a working DNIE 3.0 witjh the master branch. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rickyepoderi
Jun 22, 2017
Contributor
Hey,
It seems that opensc is trying to release the new 0.17 version, see bug #1055. Testing has been requested for several platforms. Right now I can only test DNIe 3.0 on linux but in two/three weeks I'll be able to test DNIe 2.0/3.0 in linux/windows. But not a Mac guy at all, so if someone wants to test the MacOS bundle it 'd be much appreciated.
|
Hey, It seems that opensc is trying to release the new 0.17 version, see bug #1055. Testing has been requested for several platforms. Right now I can only test DNIe 3.0 on linux but in two/three weeks I'll be able to test DNIe 2.0/3.0 in linux/windows. But not a Mac guy at all, so if someone wants to test the MacOS bundle it 'd be much appreciated. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ChuckDaniels87
Jul 18, 2017
DNIe 3.0 Working fine on ArchLinux using master branch.
I had the recurring pin entry window bug and using the current master branch fixed the issue. Thank you!
ChuckDaniels87
commented
Jul 18, 2017
|
DNIe 3.0 Working fine on ArchLinux using master branch. I had the recurring pin entry window bug and using the current master branch fixed the issue. Thank you! |
Yajo commentedJun 26, 2016
Expected behaviour
I should be able to use DNIe 3.0 with Firefox after configuring it.
Actual behaviour
Dialog asks for the PIN again and again endlessly, no matter if you enter the right PIN or you press Cance.
Steps to reproduce
Logs
Not sure how to get those.
CC @miguel-cv @germanblanco