entersafe driver: sanitize PIN code

[jmpoure]

Due to a recent fix in SVN, the way that PIN code is handled has change in entersafe driver.

With the SVN version, existing cards should be reinitialized! This is probably not acceptable from a user point of view, as some users do not have a backup of their keys.

See discussion here:  http://www.opensc-project.org/pipermail/opensc-devel/2010-May/014288.html

Viktor explained:

Normally no, but one can imagine some tool that re-writes the AODF 
(default file-id '4401') and keeps existing objects.

and proposed:

Once more, one can imagine:
to add one more pkcs15init operation, say "sanity_check";
in the card's pkcs15init driver (entersafe) implement its card specific 
version;
add 'sanity-check' operation to the 'pkcs15-init' tool.

Would it be possible for Feitian team to add a sanitize function to avoid reinitialization of all Feitian cards.

Kind regards, Jean-Michel

[jmpoure]

Please note that currently cards initialiazed with OpenSC 0.11.13 have all kinds of problems, like:

526 0x7f42984e66f0 13:43:09.974 [opensc-tool] reader-pcsc.c:721:pcsc_detect_readers: called
527 0x7f42984e66f0 13:43:09.974 [opensc-tool] reader-pcsc.c:728:pcsc_detect_readers: Probing pcsc readers
528 0x7f42984e66f0 13:43:09.974 [opensc-tool] reader-pcsc.c:750:pcsc_detect_readers: Establish pcsc context
529 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:798:pcsc_detect_readers: Found new pcsc reader 'Cherry ST1044U 00 00'
530 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:824:pcsc_detect_readers: Requesting reader features ...
531 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:830:pcsc_detect_readers: Cherry ST1044U 00 00:SCardConnect: 0x00000000
532 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:837:pcsc_detect_readers: Cherry ST1044U 00 00:SCardBeginTransaction: 0x00000000
533 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:862:pcsc_detect_readers: Reader feature 0a detected
534 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:862:pcsc_detect_readers: Reader feature 12 detected
535 0x7f42984e66f0 13:43:11.648 [opensc-tool] reader-pcsc.c:878:pcsc_detect_readers: Reader feature 12 is not supported
536 0x7f42984e66f0 13:43:11.649 [opensc-tool] reader-pcsc.c:915:pcsc_detect_readers: Returned PIN properties structure has bad length (4/8)
537 0x7f42984e66f0 13:43:11.656 [opensc-tool] reader-pcsc.c:265:refresh_attributes: Cherry ST1044U 00 00 status check
538 0x7f42984e66f0 13:43:11.656 [opensc-tool] reader-pcsc.c:284:refresh_attributes: event: 0x0022
539 0x7f42984e66f0 13:43:11.656 [opensc-tool] reader-pcsc.c:285:refresh_attributes: state: 0x0000
540 0x7f42984e66f0 13:43:11.657 [opensc-tool] reader-pcsc.c:295:refresh_attributes: card present
541 0x7f42984e66f0 13:43:11.657 [opensc-tool] reader-pcsc.c:950:pcsc_detect_readers: returning with: 0

[martin]

Replying to jmpoure:

Please note that currently cards initialiazed with OpenSC 0.11.13 have all kinds of problems, like:

All the log lines deal with smart card readers (specifically PC/SC) not smart cards.

The problem comes from different revisions of the PC/SC v2 specification because the sizes of structures have changed. The problem *could* be fixed by using the system provided reader.h on Linux, which would result (hopefully) in same structures being used by both OpenSC and the CCID driver, but that would not fix it for Windows or OS X.

The problem has been addressed in the latest revision of the PC/SC spec by changing the fixed C structures to generic TLV structures. But the availability of all the features can not be guaranteed - thus, if a feature (like a pinpad) can not reliably be detected, it will be disabled.

Yes, reader-pcsc.c should be upgraded to support the TLV feature detection as well. But this does not relate to smart cards.

[martin]

OpenSC initialization deals with two things concurrently: creating actual in-card objects (like PIN codes and private keys) and writing the PKCS#15 ASN.1 structures to enable compatible software help find the objects. The working file fix-up must not be associated with the PKCS#15 initialization (even though it would be good and would allow if not automatic then at least semi-automatic fixing of the on-card structures. As changing the files can require different types of authentication (different PIN-s, several times), it might not be possible to do it transparently.

[jmpoure]

Okay, there are two seperate issues then:

• PC/SC v2 specification because the sizes of structures have changed.
• Entersafe initialization might be needed.

Turning this ticket into defect, so everyone can have a look at it.

I am getting a little bit lost !

[martin]

The problem of *this* ticket is the wrong information in the PKCS#15 structures on the card, which can be fixed by:

• upgrading the internal API with a "fixup-possibly-broken-on-card-structures" hook and implementing one such fixer for entersafe and either evaluating the possibility to upgrade automatically or add an option to pkcs15-init or pkcs15-tool to do it.
• creating a small utility (or documenting the changing process) "fixup-entersafe-files".

[martin]

Replying to jmpoure:

536 0x7f42984e66f0 13:43:11.649 [opensc-tool] reader-pcsc.c:915:pcsc_detect_readers: Returned PIN properties structure has bad length (4/8)

The issue with PC/SC reader feature detection is #230

[jmpoure]

To avoid double report, I am closing this bug with "duplicate" tag. People interested should focus on  http://www.opensc-project.org/opensc/ticket/230

[martin]

I'm sorry, you're mixing things up. This is a valid issue for Entersafe cards that has *nothing* to do with PC/SC feature detection.

[jmpoure]

Feitian sent a patch on the mailing list and I will report shortly.

[jmpoure]

A patch was kindly proposed by Feitian here:  http://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg06051.html

I was not able to apply the patch, which fails on current trunk:

patch -p0 < /home/jmpoure/Desktop/trunk.4390.pin_flags.diff 
patching file src/tools/pkcs15-init.c
Hunk #1 FAILED at 134.
Hunk #2 FAILED at 195.
Hunk #3 FAILED at 223.
Hunk #4 FAILED at 251.
Hunk #5 FAILED at 307.
Hunk #6 FAILED at 348.
Hunk #7 FAILED at 1330.
Hunk #8 FAILED at 1343.
Hunk #9 succeeded at 1419 with fuzz 1 (offset 54 lines).
Hunk #10 succeeded at 1443 with fuzz 2 (offset 64 lines).
Hunk #11 FAILED at 2352.
Hunk #12 succeeded at 2691 with fuzz 2 (offset 65 lines).
9 out of 12 hunks FAILED -- saving rejects to file src/tools/pkcs15-init.c.rej

[jmpoure]

Patch by Xiaoshuo WU

[jmpoure]

Please test the attached patch by Xiaoshuo WU.

I applied the patch by hand on latest trunk and this gave me: pkcs15-init -A pin --pin-flags local -i 01

value:local vp:02 User PIN [User PIN] required. Please enter User PIN [User PIN]:

Failed to change attribute(s): Authentication method blocked

Will attach the patch to the corresponding thread: Failed to change attribute(s): Authentication method blocked

[jmpoure]

This works!

First I unblocked my card as I suspected something wrong: pkcs15-tool -u

Then I could run: pkcs15-init -A pin --pin-flags local -i 01

Cool!

[jmpoure]

Do you think the patch is acceptable? I would very much like this in 0.12 milestone.

[martin]

See the  thread on opensc-devel - as it currently is, it is out of balance with the rest.

As the problem of updating on-card structures can happen again in the future (for whatever reasons), the current pkcs15-tool -T/-U (which, by definition should be in pkcs15-init, as they deal with writing to the card) could be extended with a card driver callback to detect any on-card inconsistencies and provide a one-way method for updating them.

[viktor.tarasov@…]

sanity_check for feitian card that updates PinFlags?

[viktor.tarasov@…]

I've added the proposal of the 'sanity check' for Feitian card that if needed updates PinFlags?.

[jmpoure]

I saw your change in SVN with great pleasure. Thank you very much for this Viktor. I really appreciate and entersafe users too. Without this updating, there was a real problem with PIN code. I feel releaved. Thanks !!!

[viktor.tarasov@…]

If no objections from Entersafe driver's mainteners, I'll commit the proposed 'sanity-check' implementation.

[Xiaoshuo]

Thank you very much, please commit it.

[viktor.tarasov@…]

resolved in r4516