Lost change in the previous pull request and disable sm mode too. #914

wants to merge 3 commits into


None yet

2 participants


In the previous commit a conflicting section was not pushed. Besides another little change to fix re-login after a DNIe SM channel error. In DNIe 3.0 is used a lot because both keys are CKA_ALWAYS_AUTHENTICATE although not tagged as that.

@rickyepoderi rickyepoderi Lost change in the previous pull request and disable sm mode too.

When the cache counter reaches its maximum, does the user need to re-enter his PIN -- and is it what you want?

Asking the user for giving consent when his signature key is used with a cached PIN is not an option?


When the cache counter reaches its maximum, does the user need to re-enter his PIN -- and is it what you want?

When the counter reaches it maximum it fails, sometimes the pin is requested again and sometimes some error is displayed (usually something like the card was removed from the slot or similar).

Asking the user for giving consent when his signature key is used with a cached PIN is not an option?

This option needs to put pin_caching=true and pin_cache_ignore_user_consent=true and has several problems:

  1. In the default configuration ( pin_caching=true and pin_cache_ignore_user_consent=false ) DNIe 3.0 gives a lot of problems, for example in firefox. It is exactly the same situation that happens when the limit is reached (pin is requested again, errors displayed and so on).

  2. In the working configuration ( pin_caching=true and pin_cache_ignore_user_consent=true ) the cache is used for the authentication key and for the signature one is dependent, if the application supports CKA_ALWAYS_AUTHENTICATE it is ok but if not the cache is used inevitable. So, in my opinion, this option is very similar to the selected option.

  3. This option has the maximum limit problem too. But the limit is only a problem if you browse a lot of different pages that need the client certificate (in my case I should go to three different sites that requested the client cert) with the default 10. Besides you can also increase the number to 100. We can implement a trick to not increase the number but the problem is rare in the common use of the DNIe (10 tries is usually enough) and has an easy solution is you browse a lot for those type of pages.

IMHO the first issue (not working in the default configuration) is a stopper. We decided to go with the cache for both keys option because it works with the default configuration. We think the proper solution is having cache for the auth key (but it should work in the default configuration) and no cache in the sign key (by default it should not admit caching for the non-repudiation key, it would be nice something like pin_cache_ignore_user_consent=true to force caching). I want to check the possibilities of that behavior but, for sure, it is going to be long. That's why we decided to pull this request first to give an initial support that works with the default config.


Strictly speaking I don't really care which route you are going, since I'm not using such a card. All I can tell is that from a user's perspective I'd prefer if:

  1. everything works smoothly with the default configuration
  2. I don't want to be annoyed more than needed since smartcards are already clumsy enough
  3. I don't want to issue a non-repudiation signature (qualified signature?) without being notified, because of the legal implications

If you need, say, PIN caching for you card to work out of the box, then simply change the default configuration inside your card driver. Although I'd discourage modifying the settings outside ctx.c, it's clearly justified in your case. Please document this behavior in opensc.conf and your fine. Same goes for maximum number of caches, which may set to a high value by your card driver if it's documented.


😆 Perfect, we all want the same thing.

Let me summarize if I'm understanding you correctly:

  1. The non-repudiation key is tagged as CKA_ALWAYS_AUTHENTICATE programmatically (pkcs15-dnie.c).
  2. Some extra configuration will be placed inside the card_driver dnie.
  3. With this extra information the pkcs15 cache is initialized differently in pkcs15-dnie.c (I suppose it's here).
  4. This way the dnie card overwrites the general opensc configuration.

Am I right?

My main problem is that we need a special behavior for pin_cache_ignore_user_consent, there is no possible configuration for what we want for DNIe right now. We need something like this:

  • pin_cache_ignore_user_consent: no/false -> Same as current false, caching not used for any key if any CKA_ALWAYS_AUTHENTICATE inside the same auth id.
  • pin_cache_ignore_user_consent: yes/true -> Same as current true, caching used for all the keys.
  • pin_cache_ignore_user_consent: onlysafe (or whatever) -> Caching used only for non CKA_ALWAYS_AUTHENTICATE.

The new third option let us cache the pin even if a CKA_ALWAYS_AUTHENTICATE and only use it for the authentication key. I think we need something new for DNIe. This is the part that makes the whole solution quite invasive. This is just a proposal, there are more solutions for our problem (but similar in general).

Maybe I'm missing something but I don't see any other solution.


Well, I'd go with 1.-4. and simply ignore pin_cache_ignore_user_consent. If I understood correctly, this will give a good user experience in the default configuration (with pin_cache_ignore_user_consent left at false, by default).

Users may configure all kind of nonsense stuff (with or without an extra value for pin_cache_ignore_user_consent), I don't see us testing/preparing for every possible configuration.

I think as a quick hack, you could simply use the following snipplet to change the default configuration in sc_pkcs15emu_dnie_init:

p15card->opts.use_pin_cache = 1;
p15card->opts.pin_cache_counter = 30000;
rickyepoderi commented Dec 14, 2016 edited

Ok, understood. Then I'll force caching and tries if DNIe version is 3.0 in the pkcs15-dnie.c and both keys remain without CKA_ALWAYS_AUTHENTICATE (option 1 + forced configuration). I just need this little change over this same pull request.

It seems not very complicated so I'll try to do it this weekend. Thanks!

@rickyepoderi rickyepoderi Force caching of pin if DNIe is version 3.0

Change submitted. The caching of pin is forced if DNIe 3.0 is found.

@rickyepoderi rickyepoderi cwa-dnie is empty if openssl not defined
@rickyepoderi rickyepoderi referenced this pull request Dec 24, 2016

Support DNIe 3.0 #810

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