Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenSC 0.13.0 is not working correctly with Feitian cards formatted in Windows #173

Closed
samm-git opened this issue Jul 18, 2013 · 9 comments

Comments

@samm-git
Copy link

I found that OpenSC 0.13.0 opensc-pkcs11.so is not working correctly with Firefox. If i am compiling 0.13 - firefox asks for card PIN but not showing any certificates available. Also card fails with thunderbird and Java apps.

With 0.12.2 everything works as expected. I can provide additional information if needed.

@samm-git
Copy link
Author

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?

@samm-git
Copy link
Author

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

@viktorTarasov
Copy link
Member

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.

@samm-git
Copy link
Author

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

@viktorTarasov
Copy link
Member

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.

@samm-git
Copy link
Author

samm-git commented Aug 3, 2013

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

@viktorTarasov
Copy link
Member

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 .

@samm-git
Copy link
Author

samm-git commented Aug 3, 2013

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

@viktorTarasov
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants