Advanced Card Systems CryptoMate64: lockout after failed PIN attempts

[kzyapkov]

Problem Description

I just got a Bulgarian "Qualified Electronic Signature" device from Stampit. Following the instructions in Arch Wiki installed ccid and opensc. pcsc_scan immediately found

0: ACS CryptoMate64 00 00
 
Sat Nov 18 00:02:35 2017
 Reader 0: ACS CryptoMate64 00 00
  Card state: Card inserted, 
  ATR: 3B BE 96 00 00 41 05 20 00 00 00 00 00 00 00 00 00 90 00

ATR: 3B BE 96 00 00 41 05 20 00 00 00 00 00 00 00 00 00 90 00
+ TS = 3B --> Direct Convention
+ T0 = BE, Y(1): 1011, K: 14 (historical bytes)
  TA(1) = 96 --> Fi=512, Di=32, 16 cycles/ETU
    250000 bits/s at 4 MHz, fMax for Fi = 5 MHz => 312500 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TD(1) = 00 --> Y(i+1) = 0000, Protocol T = 0 
-----
+ Historical bytes: 41 05 20 00 00 00 00 00 00 00 00 00 90 00
  Category indicator byte: 41 (proprietary format)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B BE 96 00 00 41 05 20 00 00 00 00 00 00 00 00 00 90 00
3B BE .. 00 00 41 05 20 00 .. .. .. .. .. .. 00 00 90 00
	CryptoMate64 USB Cryptographic token
	http://www.acs.com.hk/en/products/18/cryptomate64-cryptographic-usb-tokens/
	ACS ACOS5-64 V2.00
	http://www.acs.com.hk/en/products/17/acos5-64-cryptographic-smart-card/


$ lsusb -d 072f:90db
 ID 072f:90db Advanced Card Systems, Ltd CryptoMate64

The rest of the story is here, in short: using pkcs11-tool --login --test always resulted in CKR_PIN_INCORRECT. At the issuer's office I had a chat with their tech guy, who immediately knew opensc doesn't support this card and installed libcmP11.so from their OEM tool instead. It works.

Proposed Resolution

Don't attempt to PIN-unlock the device, give a meaningful error instead, or support it.

Steps to reproduce

1. Buy a Bulgarian electronic signature
2. Try to use it with opensc
3. Fail by locking it with too many wrong PIN attempts
4. Suffer

Logs

I didn't gather any, but can reproduce it, for science.

[frankmorgner]

Well, obviously OpenSC supports some variant of the card. If you want us to block your type of card we need something to identify your card (the ATR is not sufficient, obviously), otherwise we can't do much for you.

If you want us to fix some more specific problem in OpenSC, you need to give us more details (i.e. a debug log)

[kzyapkov]

Sure, I can gather the logs, as well as a sniff of the successful communication from libcmP11.so. I'd rather not publish those on a public website though. Let me know what is a good channel. I am kiril dot zyapkov at gmail dot com.

[carblue]

Hi,
I can shed some light on this issue as I have the same card/token as kzyapkov (CryptoMate64) and produced an opensc-debug.log for "pkcs11-tool --login --test", based on the internal driver acos5 (though I don't recommend to use driver acos5 for CryptoMate64 !):
https://github.com/carblue/acos5_64/blob/master/info/log_pkcs11-tool--login--test__with_internal_driver_acos5

The underlying problem is the match for CryptoMate64 in internal driver card-acos5.c !

Beginning with opensc version 0.15.0 or 0.16.0, driver acos5/card-acos5.c was added to the internal drivers (contrary to https://github.com/OpenSC/OpenSC/wiki/ACOS5, which states that it does not (yet) support ACOS5), and this driver claims to support ATR 3b:be:96:00:00:41:05:20:00:00:00:00:00:00:00:00:00:90:00 (==ACS CryptoMate64/ACOS5-64 V2.00 smart card) and 3b:be:18:00:00:41:05:10:00:00:00:00:00:00:00:00:00:90:00 (==ACS ACOS5 "ACOS5-32-G" dual card).
The driver implementation card-acos5.c is rudimentary and lacks support for any on-token-cryptographic/RSA usage (at least for CryptoMate64), relying for almost everything on iso7816.c, which isn't enough, as shown by the log. It suffices only for select and list files, get_serialnr, even iso7816_pin_cmd does work for SC_PIN_CMD_VERIFY, if suitable AODF information and a local pin file is available on the card.
The last "if" is probably the reason, why my test didn't fail with CKR_PIN_INCORRECT.
ACOS5-64 and ACOS5-32 are different card operating systems and difficult, probably not recommended to implement within one driver.
Also note, that CryptoMate64/ACOS5-64 brings 4096 bit RSA keys to the table which require specialized card commands for compute_signature and decipher.

My recommendation is to remove ATR 3b:be:96:00:00:41:05:20:00:00:00:00:00:00:00:00:00:90:00 (==ACS CryptoMate64/ACOS5-64 V2.00) from card-acos5.c, as this is the current state of affair:
opensc doesn't support CryptoMate64/ACOS5-64 smart card for any serious/cryptographic/RSA usage !

Imitating my recommendation by configuring opensc.conf: card_drivers = default;
sc_connect_card will run through "trying driver 'default'/ignore 'default' card driver/unable to find driver for inserted card" and return with: -1210 (Card is invalid or cannot be handled), and of course not try any attempt to PIN-verify and the user will see this:

user@host:$ pkcs11-tool --login --test
No slot with a token was found.
user@host:$

[frankmorgner]

Partial support for CryptoMate64 would be OK, but the things that are not working should give more reasonable errors. @carblue please make a PR either disabling the card or disabling the calls that are not working.

[carblue]

@frankmorgner
My impression is, that card-acos5.c, started in 2007 when there was ACOS5-32 only and no ACOS5-64, in it's actual state is dedicated to the outdated ACOS5-32 (which I know only a little bit theoretically from a reference manual as a reduced version of ACOS5-64) and a candidate for project 'Remove old card drivers' or 'implement much more to cover ACOS5-64'. It lacks so much, as stated already and also lacks e.g. the complicated ACS file access control handling. By accident, the ATR of CryptoMate64/ACOS5-64 V2.00 was included (potentially raising this # 1204 issue and more to come in the future) . Thus I assess the driver to a large extent incomplete (even for ACOS5-32), and IMHO it was an error to incorporate this state as internal driver.
If Your intent "disabling the card" means remove this internal driver, You probably know better than me what to do for a PR. I opted for a less invasive solution by removing the accidental ATR of CryptoMate64/ACOS5-64 V2.00 again (removing lines 31 and 32 of card-acos5.c is easy for You too), but this probably makes no big difference to removing this internal driver, as it was added lately and presumably has only few users if any at all.
"disabling calls" means analyzing my log file, studying in depth the opensc inner workings and whether/why something went wrong, distinguish disabling calls depending on which ATR matched, a huge undertaking to make CryptoMate64 partially (error) supported by opensc, and this probably for no users, just prevent most actions being used by ACOS5-64:
No option for me, I won't touch card-acos5.c.