OpenSC 0.13.0 is not working correctly with Feitian cards formatted in Windows about opensc HOT 9 CLOSED

Ok, i did some debugging and found the source of the problem. I have Fetian PKI card formatted in Windows. Problem is with pin protected attributes and pin id. see this dump:

Using reader with a card: OMNIKEY CardMan 4321 00 00
PIN [User Pin]
    Object Flags   : [0x3], private, modifiable
    Auth ID        : ff
    ID             : ff
    Flags          : [0x933], case-sensitive, local, initialized, needs-padding, disable_allowed, exchangeRefData
    Length         : min_len:4, max_len:8, stored_len:8
    Pad char       : 0x00
    Reference      : 0 (0x00)
    Type           : ascii-numeric
    Path           : 3f005015

And now - keys:

samm@samm-Latitude-E6420:~$ /opt/smartcards/bin/pkcs15-tool --list-keys
Using reader with a card: OMNIKEY CardMan 4321 00 00
Private RSA Key [Peter Petrov's PostSignum Qualified CA 2 ID]
    Object Flags   : [0x3], private, modifiable
    Usage          : [0x2E], decrypt, sign, signRecover, unwrap
    Access Flags   : [0xD], sensitive, alwaysSensitive, neverExtract
    ModLength      : 2048
    Key ref        : 1 (0x1)
    Native         : yes
    Path           : 3f005015
    Auth ID        : ff00
    ID             : 506f73745369676e756d3100
    GUID           : {56e2a890-2391-a9dc-6a8f-e14c80789f77}

As you could see - Auth ID is 0xFF00, but id of the PIN is 0xFF. This makes associations of the KEY and PIN fail in pkcs11. Previous version was adding all non-matched key, thats why this bug was not seen.
Currently i solver problem for me by adding in _add_pin_related_objects this code, just before sc_pkcs15_compare_id() call:

        /* fix pin id size checking */
        if(obj->p15_object->auth_id.len > pin_info->auth_id.len)
            obj->p15_object->auth_id.len = pin_info->auth_id.len;

This fixing issue for me. Could you please review this bug?

from opensc.

Also i have found that card formatted in Linux (OpenSC) do not have such problems, auth id length is always one byte.

from opensc.

As far as I understand the reason of this bug is not in the OpenSC MW,
but in invalid on-card PKCS#15 data, created by native MW. Is it so?

Usually we are trying to avoid the card specific in the common part of OpenSC (common pkcs11 framework),
like the one that you propose in #174.

from opensc.

@viktorTarasov - yes, it is. I understand your concern and it would be great if you can help somehow to solve it inside card driver. Because now card formatted by native tool is unusable with OpenSC PKCS11, and it is clear regression from 0.12.x.

from opensc.

I do not see it as a clear regression.

Normally, for the non-standard PKCS#15 content you should implement the emulator of PKCS#15.
But, there is already precedent for the case similar to yours.

Grep sources for fix_starcos_pkcs15_card. This procedure is called on behalf of starcos card immediately after card is binded and thus allows to touch up the pkcs15 data after read-out the on-card data.

I propose you to implement some similar function, taking into account that it will be called at the same place as fix_starcos_pkcs15_card.

from opensc.

@viktorTarasov thank you for suggestions, i`ll try to do this next days. From user point of view regression is clear - it was working in .12 and not working in .13. But i am agree that proposed fix is much better.

from opensc.

Once more, for the most obstinate.

The vocation of generic part of the project is to support the standard PKCS#15 (and some others specifications) content.
If you tried the card with the non-standard content and it seemed to you that it works -- I'm happy for you and sorrow for your clients. OpenSC cannot give you any current or future guaranties .

from opensc.

@viktorTarasov as far as i could see fix_starcos_pkcs15_card is called before any data is actually read from card, and it is only settings some flags w/o modification of any real data. Sorry, i am a newbie in OpenSC source code and architecture, but it is unclear how to do this using method proposed by you.
What i can do - is to define some special flag to indicate buggy pin and use it later in the PIN compare function instead of driver name.

About regression and standards - i never read that OpenSC should support only 100% standard compliant cards (why do we have so many drivers then?). Term regression for user indicates that some hardware was working in version x.y, and not working in x+1.y without any other changes.

from opensc.

Please, read attentively what I'm wrote:

• vocation of generic part is to support the standard;
• for all that is not standard -- emulation. That's where from the great number of supported card that you appealing to.

You have used the non-standard card with generic procedures for your own risk and responsibility.
No-one feels obliged to maintain your hazardous experience.

from opensc.