Issues with Secure Messaging, opensc.conf and opensc.conf.example

[dengert]

Problem Description

In previous versions, opensc.conf was a large file with examples and options for many cards. c003f38 changed that to be a minimal version in response to #1102 which introduced opensc.conf.example.

(Comments at that time said at least one distro (redHat) would not overwrite any users changes.
But this has problems too which are not the point of this issue.)

But some of the entries in the larger opensc.conf were not just comments. One example of many from an older opensc.conf from an Ubuntu installed opensc.conf:

       # IAS/ECC cards
       card_atr 3B:7F:96:00:00:00:31:B9:64:40:70:14:10:73:94:01:80:82:90:00 {
               type = 25001;
               driver = "iasecc";
               name = "Gemalto MultiApp IAS/ECC v1.0.1";
               secure_messaging = local_gemalto_iam;
               # secure_messaging = local_adele;
               md_read_only = false;
               md_supports_X509_enrollment = true;
       }

card.c calls sc_card_sm_check: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card.c#L1608-L1611
that will fail to load an SM module because their is no card_atr in opensc.conf.

So in effect we have turned off secure messaging be default in new installs and maybe on older installs
depending on how opensc.conf is updated by distro.

Steps to reproduce

opensc.conf:

        # IDEMIA ID-One PIV 2.4.1 */
#               card_atr 3b:d6:96:00:81:b1:fe:45:1f:87:80:31:c1:52:41:12:22 {
#               driver = "PIV-II";
#               name = "TEST OF LOADING SM";
#               secure_messaging = local_piv;
#       }
    
        secure_messaging local_piv  {
                module_name = libsmm-local.so;
                module_path = /opt/ossl-1.1.1k/lib;
                #module_data = ""; 
                type = acl;             # transmit, acl 
        }

with the above commented out gdb shows:

1609		atrblock = _sc_match_atr_block(ctx, card->driver, &card->atr);
(gdb) n
1610		if (atrblock == NULL)
(gdb) p atrblock
$13 = (scconf_block *) 0x0

with the above uncommented,

P:5663; T:0x140737345214272 10:28:42.704 [opensc-tool] ../../../src/src/libopensc/card-piv.c:5752:piv_init: returning with: 0 (Success)
P:5663; T:0x140737345214272 10:28:42.704 [opensc-tool] ../../../src/src/libopensc/card.c:382:sc_connect_card: card info name:'TEST OF LOADING SM', type:14000, flags:0x0, max_send/recv_size:255/256P:5663; T:0x140737345214272 10:29:01.356 [opensc-tool] ../../../src/src/libopensc/card.c:1606:sc_card_sm_check: called
P:5663; T:0x140737345214272 10:29:54.555 [opensc-tool] ../../../src/src/libopensc/card.c:1230:match_atr_table: ATR     : 3b:d6:96:00:81:b1:fe:45:1f:87:80:31:c1:52:41:12:22
P:5663; T:0x140737345214272 10:29:54.555 [opensc-tool] ../../../src/src/libopensc/card.c:1241:match_atr_table: ATR try : 3b:d6:96:00:81:b1:fe:45:1f:87:80:31:c1:52:41:12:22
P:5663; T:0x140737345214272 10:30:18.027 [opensc-tool] ../../../src/src/libopensc/card.c:1617:sc_card_sm_check: secure_messaging configuration block 'local_piv'
P:5663; T:0x140737345214272 10:32:22.969 [opensc-tool] ../../../src/src/libopensc/card.c:1636:sc_card_sm_check: SM module 'libsmm-local.so' in  '/opt/ossl-1.1.1k/lib'
P:5663; T:0x140737345214272 10:32:30.151 [opensc-tool] ../../../src/src/libopensc/card.c:1509:sc_card_sm_load: called
P:5663; T:0x140737345214272 10:32:30.151 [opensc-tool] ../../../src/src/libopensc/card.c:1528:sc_card_sm_load: SM module 'libsmm-local.so' located in '/opt/ossl-1.1.1k/lib'
P:5663; T:0x140737345214272 10:32:30.152 [opensc-tool] ../../../src/src/libopensc/card.c:1542:sc_card_sm_load: try to load SM module '/opt/ossl-1.1.1k/lib/libsmm-local.so'
P:5663; T:0x140737345214272 10:32:30.186 [opensc-tool] ../../../src/src/libopensc/card.c:1580:sc_card_sm_load: SM handler 'test' not exported -- ignored
P:5663; T:0x140737345214272 10:32:30.186 [opensc-tool] ../../../src/src/libopensc/card.c:1593:sc_card_sm_load: returning with: 0 (Success)

It got far enough to load the module for this card, to show a missing card_atr will not even try and load the module.

Proposed Resolution

Partial sollution:
#1453 which was rejected just removed comments from opensc.conf

Better would be have card drivers which know what SM module its cards can support, by default. without the need for opensc.conf changes, opensc.conf may still be needed in special cases.

Use of a the atr will not work for drivers that support a specific applet based on its AID and not on the atr.

Problem found while looking at how PIV driver could use loaded SM module rather then the proposed one in #2053

[Jakuje]

The problem with #1453 is that you can use opensc-tool to update the configuration file with new values. If you add or remove some blocks, you will lose probably more formatting than necessary. I am not happy with the sconf either but changing this to something with same context information that would be more memory-friendly would likely mean to write it from scratch. Some non-destructive improvements are welcomed though.

Since you are the first one noticing this after three years, I do not think anyone heavily depended on this functionality.

We already noticed that configuration based on atr only is not flexible enough so it might make sense to provide per-driver configuration, with something like the following (would require plugging some more code to get this working though):

driver PIV-II {
  secure_messaging = local_piv;
  ...
}

Or make these defaults somehow configurable inside of the driver with possibility to override in configuration (which would be less memory demanding than processing the configuration file on every init).

All the translations strings from #1126 also did some work with the memory footprint some years back.

Certainly it would be great to document what to do with the example configuration file and how to use SM in the manual pages/wiki with some examples as clearly you are not the only one learning something new here :)

[dengert]

Since you are the first one noticing this after three years, I do not think anyone heavily depended on this functionality.

I would look at it as a regression. Users may have checked that SM worked for their tokens, but have not noticed that SM may not be working as expected.

[frankmorgner]

AFAIK, the previously hard coded SM parameters were related to test cards. For the cards in productive use, a specific version of opensc.conf was distributed anyway. We can assume that a tester or an administrator of such cards is capable of supplying a proper configuration file.

I personally prefer to have in opensc.conf only the stuff that is important for most user without too many distractions rather than catching all corner cases.

[dengert]

As far as I can tell, many people turn to OpenSC when they have a card (usually issued by their government) that works on windows but the issuer does not provide drivers for linux. These users are their own administrators.

I too like a small opensc.conf, so why can't the driver supply its own defaults for SM?

The " catching all corner cases" include using the security expected by the card issuer.

Do you have an answer to the question from the last line of the Problem Description:
"Problem found while looking at how PIV driver could use loaded SM module rather then the proposed one in #2053"

i.e. how to let the driver use SM if card supports it, without having to add another card-atr to opensc.conf

[frankmorgner]

As said before, I think having SM as seperate module is not the best option. If I were you, I'd keep the SM configuration at the card driver level (i.e. keep the pairing code a card driver option), so that the card driver sets SM_MODE_TRANSMIT and initializes both card->sm_ctx.ops.get_sm_apdu and card->sm_ctx.ops.free_sm_apdu; you don't need an SM module for that. I think this is the direction you're already going with your PIV implementation.

[frankmorgner]

Closing this since the original question was solved...

• SM is still enabled by default.
• For some cards, the local SM module is still used. This will work also with an empty opensc.conf.
• Also, there is no problem with having card driver specific options. However, an empty opensc.conf should use reasonable defaults so that everything works as expected.