Support DNIe 3.0

[yajo]

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]

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

[cameta]

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]

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]

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]

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

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]

Are there any test cards available from somewhere?

[frankmorgner]

Is there a specification available?

[miguel-cv]

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:https://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]

You can find everything about it in http:https://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]

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:https://blogs.nologin.es/rickyepoderi/index.php?/archives/137-Starting-to-play-with-DNIe-3.0-and-OpenSC.html

[cameta]

I can access to a DNIe 2.0

[rickyepoderi]

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

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]

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]

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]

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

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]

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

[rickyepoderi]

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

My identity card works in the machine of the police. Could the fault be in my reader?

[rickyepoderi]

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

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]

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

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

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

[dengert]

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

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

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]

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 [email protected]

[rickyepoderi]

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]

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]

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]

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]

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

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

[rickyepoderi]

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]

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]

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]

Can we close this issue?

[rickyepoderi]

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]

OK, thanks!

[yajo]

Sorry, in which version was this fixed?

[rickyepoderi]

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

[Raulvo]

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]

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]

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]

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.

[ismaelgv]

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!