[Opensc-commits] [OpenSC/OpenSC] d952a9: support for Slovak eID cards (#2672)

[Juraj Š. <no...@gi...>]

  Branch: refs/heads/master
  Home:   https://github.com/OpenSC/OpenSC
  Commit: d952a9fa3d0e2becc684c3a2529173d3d151f817
      https://github.com/OpenSC/OpenSC/commit/d952a9fa3d0e2becc684c3a2529173d3d151f817
  Author: Juraj Šarinay <ju...@sa...>
  Date:   2023-03-22 (Wed, 22 Mar 2023)

  Changed paths:
    M src/libopensc/Makefile.am
    M src/libopensc/Makefile.mak
    A src/libopensc/card-skeid.c
    M src/libopensc/cards.h
    M src/libopensc/ctx.c
    A src/libopensc/pkcs15-skeid.c
    M src/libopensc/pkcs15-syn.c
    M src/libopensc/pkcs15-syn.h

  Log Message:
  -----------
  support for Slovak eID cards (#2672)

## Driver

The card runs CardOS 5.4, the new driver is therefore a stripped-down version of ```card-cardos.c``` The only place where I have to diverge from the original driver is ```set_security_env```, because the card expects ```MSE RESTORE``` instead of ```MSE SET```. I abuse ```key_ref``` to store the corresponding ```seIdentifier```, as our pkcs\#15 structures do not include the entry.

Because the card shares the ATR with other CardOS 5.4 cards, the new driver precedes ```cardos-driver``` within ```internal_card_drivers[]```.

## PKCS\#15 emulation

Within EF.DIR there are 5 applications. The last two carry (apparently not entirely usable) PKCS\#15 structures. 

```pkcs15-skeid.c``` binds the _fourth_ application in the list. Otherwise ```sc_pkcs15_bind_internal``` would get called and create an unusable token. In the case of the fifth application this is prevented by ```SC_PKCS11_FRAMEWORK_DATA_MAX_NUM = 4```.

Because there is no point in calling ```sc_pkcs15_bind_internal``` for this card, I added it to ```sc_pkcs15_is_emulation_only```. This does not prevent ```sc_pkcs15_bind_internal``` from [getting called](https://github.com/OpenSC/OpenSC/blob/70771735ae10180bb039043b9a1b00b66bf00fc1/src/libopensc/pkcs15.c#L1296
) though (if synthetic binding was unsuccessful).

I consider this behaviour a bit counterintuitive. I mention it here to report on and justify what I have done, it has no noticeable effect on my driver (any more). Let me know if ```sc_pkcs15_is_emulation_only``` warrants a separate GitHub issue.

## PINs

There is a global User PIN labeled BOK. The qualified certificate (key) requires user consent and a separate (local) Signature PIN labeled KEP. The "official" proprietary PKCS\#11 module requires both the codes for every signature. Fortunately, the card is happy with the Signature PIN only, as there seems to be no convenient way to have multiple PIN codes per slot. 

I considered emulating (parts of) the "official" behaviour wihtin a custom ```pin_cmd``` that contained the following:

```C
    if (data->pin_reference == 0x87 && data->cmd != SC_PIN_CMD_CHANGE && data->pin_type != SC_AC_CONTEXT_SPECIFIC)
        {
               sc_log(card->ctx, "Non-specific KEP PIN encountered, handling it as BOK instead.");
               data->pin_reference = 0x03;
       }

```
I ultimately decided against the idea. It adds complexity (or confusion) and provides little benefit. I mention the issue because it is connected to a failure in ```pkcs11-tool --test --slot 1 --login```: [log](https://github.com/OpenSC/OpenSC/files/10326667/pkcs11-tool_test_slot_1.log).

Because the local Signature PIN is used for the session, ```test_verify()``` fails [here](https://github.com/OpenSC/OpenSC/blob/70771735ae10180bb039043b9a1b00b66bf00fc1/src/tools/pkcs11-tool.c#L6639).

The card enforces CKA_ALWAYS_AUTHENTICATE and therefore reports that the Signature PIN is (no longer) verified, apparently because signatures have been computed during ```test_signature()```. The only effect of this is that the built-in test fails even though the token works (reasonably) well.

The above ```pin_cmd``` hack would result in a passed ```pkcs11-tool --test --slot 1 --login```.

I include this information mainly to justify a PR with a failed test attached. If the behaviour of ```pkcs11-tool --test``` in the context of a local Signature PIN and ```user_consent``` warrants a separate GitHub issue, do please let me know.

For completeness,  [here](https://github.com/OpenSC/OpenSC/files/10326703/pkcs11-tool_test_slot_0.log) is the output of ```pkcs11-tool --test --slot 0 --login```.