New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support DNIe 3.0 #810

Closed
Yajo opened this Issue Jun 26, 2016 · 115 comments

Comments

Projects
None yet
@Yajo

Yajo commented Jun 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

  1. Insert your DNIe.
  2. Configure OpenSC's PKCS#11 module in Firefox.
  3. Visit a DNIe-enabled page, such as https://www1.agenciatributaria.gob.es/wlpl/DASR-CORE/AccesoCO2015RVlt

Logs

Not sure how to get those.

CC @miguel-cv @germanblanco

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

frankmorgner Jun 28, 2016

Member

Indeed @germanblanco wanted to look into this, see #655

Member

frankmorgner commented Jun 28, 2016

Indeed @germanblanco wanted to look into this, see #655

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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
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.

@Yajo

This comment has been minimized.

Show comment
Hide comment
@Yajo

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.

@miguel-cv

This comment has been minimized.

Show comment
Hide comment
@miguel-cv

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:
https://github.com/germanblanco/OpenSC/tree/dnie_dnie30/
It fails passing from one channel to another...

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

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.

Member

frankmorgner commented Aug 1, 2016

@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.

@emunicio

This comment has been minimized.

Show comment
Hide comment
@emunicio

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

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

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

frankmorgner Sep 20, 2016

Member

Are there any test cards available from somewhere?

Member

frankmorgner commented Sep 20, 2016

Are there any test cards available from somewhere?

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

frankmorgner Sep 20, 2016

Member

Is there a specification available?

Member

frankmorgner commented Sep 20, 2016

Is there a specification available?

@miguel-cv

This comment has been minimized.

Show comment
Hide comment
@miguel-cv

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

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.

@Yajo

This comment has been minimized.

Show comment
Hide comment
@Yajo

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 😉

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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:

http://blogs.nologin.es/rickyepoderi/index.php?/archives/137-Starting-to-play-with-DNIe-3.0-and-OpenSC.html

Contributor

rickyepoderi commented Oct 17, 2016

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:

http://blogs.nologin.es/rickyepoderi/index.php?/archives/137-Starting-to-play-with-DNIe-3.0-and-OpenSC.html

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

cameta Oct 17, 2016

I can access to a DNIe 2.0

cameta commented Oct 17, 2016

I can access to a DNIe 2.0

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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).

Contributor

rickyepoderi commented Oct 18, 2016

@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).

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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).

Contributor

rickyepoderi commented Oct 19, 2016

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).

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Oct 22, 2016

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.

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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.
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

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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
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:
/apps/opensc/bin$ ./pkcs11-tool -l -O
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

Contributor

rickyepoderi commented Oct 23, 2016

@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
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:
/apps/opensc/bin$ ./pkcs11-tool -l -O
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

This comment has been minimized.

Show comment
Hide comment
@cameta

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
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

This comment has been minimized.

Show comment
Hide comment
@cameta

cameta Oct 23, 2016

You might have a different version of the DNI 3.0 that mine.

cameta commented Oct 23, 2016

You might have a different version of the DNI 3.0 that mine.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Oct 23, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cameta

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?

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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
Contributor

rickyepoderi commented Oct 23, 2016

@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
@miguel-cv

This comment has been minimized.

Show comment
Hide comment
@miguel-cv

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 .
@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";
    }

@emunicio

This comment has been minimized.

Show comment
Hide comment
@emunicio

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
GETBN(key->iqmp, rsa->iqmp, iqmp);

Am I missing something? I'm compiling with g++ 4.9.2

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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?

Contributor

rickyepoderi commented Oct 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@emunicio

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

@rickyepoderi
I have: OpenSSL 1.1.0 25 Aug 2016
Anyway, thanks. I will try to find out what is happening with openssl

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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?

Member

dengert commented Oct 24, 2016

@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?

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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).

Contributor

rickyepoderi commented Oct 25, 2016

@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).

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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.)

Member

dengert commented Oct 25, 2016

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.)

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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

Member

dengert commented Oct 25, 2016

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

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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
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)

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert
Member

dengert commented Oct 26, 2016

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented 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:

./dnie-tool -V 2>out.txt

And attach the file here. Let's see if I see something.

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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.
outDNI20.txt
outDNI30.txt

@FeitianSmartcardReader

This comment has been minimized.

Show comment
Hide comment
@FeitianSmartcardReader

FeitianSmartcardReader Oct 27, 2016

Contributor

I saw the issue of this reader, check #201

Contributor

FeitianSmartcardReader commented Oct 27, 2016

I saw the issue of this reader, check #201

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

rickyepoderi Oct 27, 2016

Contributor

@cameta

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.

Contributor

rickyepoderi commented Oct 27, 2016

@cameta

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.

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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.

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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.

Member

dengert commented Oct 27, 2016

@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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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?

Contributor

rickyepoderi commented Oct 27, 2016

@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?

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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.

Member

dengert commented Nov 29, 2016

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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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).

Contributor

rickyepoderi commented Nov 29, 2016

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).

@germanblanco

This comment has been minimized.

Show comment
Hide comment
@germanblanco

germanblanco Nov 30, 2016

Contributor
Contributor

germanblanco commented Nov 30, 2016

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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?

Contributor

rickyepoderi commented Nov 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

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?

Member

frankmorgner commented Nov 30, 2016

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?

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Dec 1, 2016

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.

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

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:

  1. Force caching of the PIN (either by removing CKA_ALWAYS_AUTHENTICATE or by forcing pin_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.
Member

frankmorgner commented Dec 1, 2016

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:

  1. Force caching of the PIN (either by removing CKA_ALWAYS_AUTHENTICATE or by forcing pin_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.
@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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.

Member

dengert commented Dec 1, 2016

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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Dec 8, 2016

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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Dec 24, 2016

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.

@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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.

Member

dengert commented Dec 29, 2016

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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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...

Contributor

rickyepoderi commented Dec 29, 2016

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...

@davernos

This comment has been minimized.

Show comment
Hide comment
@davernos

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.
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.

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Jan 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@davernos

davernos Jan 12, 2017

Ok, heres the debug file. Please, let me know if I left any sensible information.
debug.zip

davernos commented Jan 12, 2017

Ok, heres the debug file. Please, let me know if I left any sensible information.
debug.zip

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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
Contributor

rickyepoderi commented Jan 12, 2017

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
@dengert

This comment has been minimized.

Show comment
Hide comment
@dengert

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

Member

dengert commented Jan 12, 2017

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

@davernos

This comment has been minimized.

Show comment
Hide comment
@davernos

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.

$ ./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.

frankmorgner added a commit to frankmorgner/OpenSC that referenced this issue Feb 27, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)

frankmorgner added a commit to frankmorgner/OpenSC that referenced this issue Feb 27, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)

frankmorgner added a commit to frankmorgner/OpenSC that referenced this issue Feb 27, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)
@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

frankmorgner Mar 3, 2017

Member

Can we close this issue?

Member

frankmorgner commented Mar 3, 2017

Can we close this issue?

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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).

Contributor

rickyepoderi commented Mar 3, 2017

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).

@frankmorgner

This comment has been minimized.

Show comment
Hide comment
@frankmorgner

frankmorgner Mar 3, 2017

Member

OK, thanks!

Member

frankmorgner commented Mar 3, 2017

OK, thanks!

@Yajo

This comment has been minimized.

Show comment
Hide comment
@Yajo

Yajo Mar 5, 2017

Sorry, in which version was this fixed?

Yajo commented Mar 5, 2017

Sorry, in which version was this fixed?

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Mar 5, 2017

No version yet. Right now it's in the master branch and it will be in 0.17 when it comes out.

frankmorgner added a commit to frankmorgner/OpenSC that referenced this issue Mar 20, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)

frankmorgner added a commit to frankmorgner/OpenSC that referenced this issue Mar 20, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)

frankmorgner added a commit that referenced this issue Mar 20, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see #810)

hamano added a commit to jpki/OpenSC that referenced this issue Apr 10, 2017

Added support for PIN commands via escape commands
As defined in BSI TR-03119 to issue SCardTransmit (with Uses
Pseudo-APDU) instead of SCardControl (with FEATURE_VERIFY_PIN_DIRECT).
It allows using a very basic PC/SC reader driver without special support
for PIN verification or modification (such as the default CCID driver on
Windows).

Also gets IFD vendor information via escape commands.

PC/SC's Get Uid command is now only triggered if enable_escape = true;
was set by the user to allow disabling wrapped commands on broken
readers (see OpenSC#810)
@Raulvo

This comment has been minimized.

Show comment
Hide comment
@Raulvo

Raulvo May 15, 2017

I am on Ubuntu 17.04 which ships with opensc 0.16 and testing with pkcs-tool (pkcs11-tool -t -l) returns the same error @davernos reported.
Are there any plans to release 0.17 in time for Ubuntu 17.10?

Raulvo commented May 15, 2017

I am on Ubuntu 17.04 which ships with opensc 0.16 and testing with pkcs-tool (pkcs11-tool -t -l) returns the same error @davernos reported.
Are there any plans to release 0.17 in time for Ubuntu 17.10?

@dcristob

This comment has been minimized.

Show comment
Hide comment
@dcristob

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

@cameta

This comment has been minimized.

Show comment
Hide comment
@cameta

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.
You can test your DNIE with this.
https://github.com/rickyepoderi/dnie-pkcs11-tester

@rickyepoderi

This comment has been minimized.

Show comment
Hide comment
@rickyepoderi

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.

Contributor

rickyepoderi commented Jun 22, 2017

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.

@ChuckDaniels87

This comment has been minimized.

Show comment
Hide comment
@ChuckDaniels87

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment