Jakuje
commented
3 years ago The drivers define the PIN objects and handling of their lengths and padding so it might need some adjusting for your card/version.
Open the-docta opened 3 years ago
Jakuje
commented
3 years ago The drivers define the PIN objects and handling of their lengths and padding so it might need some adjusting for your card/version.
the-docta
commented
3 years ago the length and padding is actually of minor concern, as I have a working workaround here (though, I'd be willing to help if you let me know how)
Of major concern is the fact that I cant validate the second PIN request -- the cyberJack tells me PIN is correct in his display, but pkcs11-tool still claims a CKR_USER_NOT_LOGGED_IN (0x101) and aborts
Jakuje
commented
3 years ago Can you try with pin_cache_ignore_user_consent=yes in the opensc.conf? Debug log around the authentication would be also helpful. Note, the PIN might be visible in the log in plaintext and in hexadecimal encoding so you might want to redact that value.
the-docta
commented
3 years ago attached two logs at debug level 3 - the difference being pin_cache_ignore_user_consent being set to true in one and to false in the other. If set to true, the PIN is asked only once, but in the end, the process fails with same 0x101 error.
the respective places where the PIN was requested are marked with ###
PS: I would assume that the PIN (being entered on the pin pad) should not be contained in the logs.
dengert
commented
3 years ago The card keep sending the command 00 20 00 81 which is a test to see if the login session using pin 81 is still valid.
But the return value is 63 C3
ISO7816-4 " 7.5.6 VERIFY command" says:
"If INS = '20', the command data field is normally present for conveying verification data. The absence of
command data field is used to check whether the verification is required (SW1-SW2 = '63CX' where 'X'
encodes the number of further allowed retries), or not (SW1-SW2 = '9000')."
So 63 C3 says verification is required.
Some problems:
How do you tell the pin pad reader which PIN id to use?
the-docta
commented
3 years ago How do you tell the pin pad reader which PIN id to use?
I'm not sure what "pin id" is... I first call pkcs11-tool -L, which lists the slots, then I use the command pkcs11-tool --test --login --slot ...:
» pkcs11-tool -L Available slots:
Slot 0 (0x0): REINER SCT cyberJack RFID komfort
token label : D-TRUST Card V3.1 ... (Card-PIN)
token manufacturer : D-TRUST GmbH (C)
token model : PKCS#15 emulated
token flags : login required, PIN pad present, token initialized, PIN initialized
hardware version : 0.0
firmware version : 0.0
serial num : 003210500344147f
pin min/max : 6/12
Slot 1 (0x1): REINER SCT cyberJack RFID komfort
token label : D-TRUST Card ... (Signature-PIN)
token manufacturer : D-TRUST GmbH (C)
token model : PKCS#15 emulated
token flags : login required, PIN pad present, token initialized, PIN initialized
hardware version : 0.0
firmware version : 0.0
serial num : 003210500344147f
pin min/max : 6/12the card has a "card pin" and a "signature pin", both are currently set to the same value, while testing.
The driver does not handle the return correctly , but says: " cardos_check_sw: Unknown SWs; SW1=63, SW2=C3"
I assume driver of the card (or of the reader?) What can I do about it? is it safe to try other card drivers?
dengert
commented
3 years ago Being set tot the same value means it will verify either.
Most card drivers let the OpenSC pin routines check the status. It looks like your driver checks it first and considers `63 CX' as an error. (X=3 in your case.) This should be fixed, as it is not an error, just says the pin with ID '81' has not been verified. and you have 3 chances left to get it right before it will need to be reset.
You are using a pin pad reader? With PACE?
With most pin pad readers the driver or (opensc pin routines) recognize how to send a verify pin command template to tell the reader how to insert the pin in the template. So to the card the verify command looks the same as if the host sent the command with the PIN.
Keys and objects on the card have an ACL that says which pin is needed. PIN ID 80 and 81 are commonly used. The verify command P2 parameter says which PIN is being sent.
PKCS#11 only supports a concept of a user pin and SO pin type login. So OpenSC will allocate up to 4 slots when it sees the driver thinks there are multiple pins. I have not had to deal with the issue of how is the slot passed to the driver so it can sent the correct PIN ID in the verify.
If this is using PACE, I have no idea how the PIN ID is passed to PACE.
A pcscd trace might show the pin template being passed to the reader. Or a USB trace which might show what PACE and pcscd has done.
So in you case, it might be the card sees the PIN ID as '80` which verifies, but the driver thinks it should be using PIN ID '81' which is in the ACL for the key, so the card responds with 63 C3 to the test of the verify, and the card responses '69 82' which results in: "cardos_check_sw: required access right not granted"
the-docta
commented
3 years ago I had to google what PACE is (wireless rfid card like german personalausweis) => no, I use a "simple" smart card with a chip with contacts
It looks like your driver checks it first and considers ...
Also "my" driver is something that came with OpenSC (or so I think) 🙂
The card is a "D-Trust Card 3.1", contains a certificate that is signed bei an ETUL trusted CA ( https://helpx.adobe.com/document-cloud/kb/european-union-trust-lists.html ), my main intention is to sign PDF documents with it
I also have an old Gemalto reader, which I have been using for PDF signing with a different SmartCard (this one being limited to a single company with company-internal CA and trust) for about two years now, using different OpenSC versions.
The cyberJack is a new reader for me. That Gemalto reader has the same behaviour as the cyberJack - only difference, of course, is the missing pinpad - I enter the pin on the console.
so my main intention is to sign PDF documents. Acrobat reader also asks me for the PIN twice and reject signature after the second PIN attempt. So kinda same behaviour as with command line tools.
And I use pkcs11-tool to test what is wrong and to collect information that will pinpoint the actual issue and solve it...
about the driver: does this help to identify the used card driver?
» opensc-tool -an
P:13271; T:0x4622138880 08:32:20.453 [opensc-tool] ctx.c:724:process_config_file: Used configuration file '/Library/OpenSC/etc/opensc.conf'
Using reader with a card: REINER SCT cyberJack RFID komfort
3b:d2:18:00:81:31:fe:58:c9:01:14
Atos CardOSDoes anyone with a CardOS card have two PINs for the card? Do you have to use the onepin-pkcs11.dll or onepin-pkcs11.so?
@the-docta The reasons I asked about PACE, is because your logs in the first 24 lines show:
7 pcsc_add_reader: Adding new PC/SC reader 'REINER SCT cyberJack RFID komfort'
22 detect_reader_features: Reader supports pinpad PIN verification
23 detect_reader_features: Reader supports pinpad PIN modification
25 detect_reader_features: Reader supports PACEYou say it works with the Gemalto reader and but show Context Specific. This indicates the PKCS11 knows this is a signature operation, and wants a pin entered. But the card maybe asking for the second pin (which may be different) and the verify has to tell the card this is the second pin i.e. send a different PIN ID as the P2 byte in APDU when this is context sepecific.
You say: "only difference, of course, is the missing pinpad - I enter the pin on the console."
In both logs you have deleted to to much about the verify information.
Can you run a test using the GemAlto reader, without the SkipJack reader even plugged in.
You can then find every verify which may have your pin
A regex expression like "^00 20" and report the first 5 bytes i.e. APDU and length and blank out the pin.
And report the status returned it should be , '90 00' if verify worked, or the 63 C3 in your case.
I am looking to see if the card verifies the PIN.
and if different PIN IDs are used.
I think one problem is with the status of 63 CX not being recognized. In cardos_check_sw
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L489-L490
If it does not recognize the status it returns SC_ERROR_CARD_CMD_FAILED. (-1200)
If it does not recognize the status, it should do something like:
return iso_ops->check_sw(card, sw1, sw2);
to test the defaults.
This is related to https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L215 A debugger would show if every V5 or greater card has the same problem.
dengert
commented
3 years ago Also run pkcs15-tool to dump the objects, or to list the private keys. You are looking for two pins and looking for "user-consent" or "user consent" or "user_consent" this is mapped to PKCS11 context specific.
the-docta
commented
3 years ago got four pins (two pins and two puks)
» pkcs15-tool -D
Using reader with a card: Gemalto PC Twin Reader
PKCS#15 Card [D-TRUST Card V3.1 standard 2ce]:
Version : 0
Serial number : 9276003210500344147f
Manufacturer ID: D-TRUST GmbH (C)
Flags : Login required, EID compliant
PIN [Card-PIN]
Object Flags : [0x03], private, modifiable
Auth ID : 1a
ID : 11
Flags : [0x811], case-sensitive, initialized, exchangeRefData
Length : min_len:6, max_len:12, stored_len:12
Pad char : 0x00
Reference : 17 (0x11)
Type : UTF-8
PIN [Card-PUK]
Object Flags : [0x03], private, modifiable
ID : 1a
Flags : [0x859], case-sensitive, unblock-disabled, initialized, unblockingPin, exchangeRefData
Length : min_len:8, max_len:8, stored_len:8
Pad char : 0x00
Reference : 26 (0x1A)
Type : UTF-8
PIN [Signature-PIN]
Object Flags : [0x03], private, modifiable
Auth ID : 0a
ID : 01
Flags : [0x813], case-sensitive, local, initialized, exchangeRefData
Length : min_len:6, max_len:12, stored_len:12
Pad char : 0x00
Reference : 1 (0x01)
Type : UTF-8
Path : 3f001fff
PIN [Signature-PUK]
Object Flags : [0x03], private, modifiable
ID : 0a
Flags : [0x81B], case-sensitive, local, unblock-disabled, initialized, exchangeRefData
Length : min_len:8, max_len:8, stored_len:8
Pad char : 0x00
Reference : 10 (0x0A)
Type : UTF-8
Path : 3f001fff
... followed by various signatures ...the only line in debugoutput with "consent"
P:32442; T:0x4602732032 21:47:17.078 [pkcs15-tool] pkcs15.c:1206:sc_pkcs15_bind: called
P:32442; T:0x4602732032 21:47:17.078 [pkcs15-tool] pkcs15.c:1207:sc_pkcs15_bind: application(aid:'empty')
P:32442; T:0x4602732032 21:47:17.078 [pkcs15-tool] pkcs15.c:1244:sc_pkcs15_bind: PKCS#15 options: use_file_cache=0 use_pin_cache=1 pin_cache_counter=10 pin_cache_ignore_user_consent=1 private_certificate=0
P:32442; T:0x4602732032 21:47:17.078 [pkcs15-tool] card.c:473:sc_lock: calledboth PINs and both PUKs are verifiable correctly:
pkcs15-tool --verify-pin -a1
pkcs15-tool --verify-pin -a11
pkcs15-tool --verify-pin -a1a
pkcs15-tool --verify-pin -a 0aalso changing pins works as expected. Attached a log with debug level 9 of the following command: (i temporarily changed the pin for the test, so it is displayed plain text below, which is fine)
~ » pkcs11-tool --slot 1 --test --login basically, this sums up to:
...
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter User PIN:
Outgoing APDU (7 bytes):
00 A4 08 0C 02 1F FF .?....?
Incoming APDU (2 bytes):
90 00 ..
Outgoing APDU (17 bytes):
00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 . ...00000000000
31 1
Incoming APDU (2 bytes):
90 00 ..
... some more APDUs
Outgoing APDU (4 bytes):
00 20 00 81 . ..
Incoming APDU (2 bytes):
63 C3 c?
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter context specific PIN:
Outgoing APDU (7 bytes):
00 A4 08 0C 02 1F FF .?....?
Incoming APDU (2 bytes):
90 00 ..
Outgoing APDU (17 bytes):
00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 . ...00000000000
31 1
Incoming APDU (2 bytes):
90 00 ..
Outgoing APDU (7 bytes):
00 A4 08 0C 02 1F FF .?....?
Incoming APDU (2 bytes):
90 00 ..
Outgoing APDU (14 bytes):
00 22 41 B6 09 84 01 02 95 01 40 80 01 10 ."A?......@...
Incoming APDU (2 bytes):
69 82 i.so looks like the pin is verified just fine, but the security context is still not for satisfaction. (if I run the same command with pin_cache_ignore_user_consent=true, I am only asked for the PIN once, the same PIN is reused, and also pin check 0020... is successful, but the last command is greeted with 6982)
dengert
commented
3 years ago "Please enter context specific PIN" is from https://github.com/OpenSC/OpenSC/blob/master/src/tools/pkcs11-tool.c#L2073-L2074 CKA_ALWAYS_AUTHENTICATE is most likely coming from here: https://github.com/OpenSC/OpenSC/blob/master/src/pkcs11/framework-pkcs15.c#L3835-L3841
This may come in play when using a pin pad reader: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pin.c#L820-L829
in line 1447 in debug log:
P:33773; T:0x4739681792 22:37:18.452 [opensc-pkcs11] asn1.c:1514:asn1_decode_entry: decoding 'userConsent' returned 1 is where the user_consent is set for sign key.
But I think the problem is all the verify examples the verify is always for 00 20 00 81 but your card has two user PINS
and to use the signature key requires the use of the second PIN. But you have set the value of the pins to be the same, so that makes it harder to tell which pin the card is verifying.
The use of two pin maybe a feature of the D_Trust card and not of any of the other cards supported by this driver. (Other drivers they may take care of this situation.)
OpenSC pkcs11 assigns two slots, but based on your test, even with slot=1 it fails. This implies to me, that the first key key is always being used of the P2 parameter is wrong or you must first authenticate to the card using auth PIN, then to use the sign key you must authenticate again using sign PIN.
I found https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L1486-L1493 implies there is not a good understanding of what is going on.
Based on the output of
PIN [Card-PIN]
Object Flags : [0x03], private, modifiable
Auth ID : 1a
ID : 11
Flags : [0x811], case-sensitive, initialized, exchangeRefData
Length : min_len:6, max_len:12, stored_len:12
Pad char : 0x00
Reference : 17 (0x11)
Type : UTF-8
PIN [Signature-PIN]
Object Flags : [0x03], private, modifiable
Auth ID : 0a
ID : 01
Flags : [0x813], case-sensitive, local, initialized, exchangeRefData
Length : min_len:6, max_len:12, stored_len:12
Pad char : 0x00
Reference : 1 (0x01)
Type : UTF-8
Path : 3f001fffshows up in debug log:
1137: sc_pkcs15_decode_aodf_entry: decoded PIN(ref:1A,path:)
1212: sc_pkcs15_decode_aodf_entry: decoded PIN(ref:1,path:3f001fff)
1297: framework-pkcs15.c:1495:pkcs15_create_tokens: Flags:0x3; Auth User/Sign PINs 0x7fe491009800/0x7fe49100b000
1447: asn1.c:1514:asn1_decode_entry: decoding 'userConsent' returned 1the APDUs sent for a verify are:
00 A4 08 0C 02 1F FF
00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
I suspect the ADPU P2 should be: (80 rather then 81)
00 20 00 80 0C 30 30 30 30 30 30 30 30 30 30 30 31
I do not have one of these cards, and have no way to tell you hoe to fix this. But here is something to test with:
opensc-tool -s "00 20 00 80" \ -s "00 A4 08 0C 02 1F FF 00" \ -s "00 20 00 80 0C 30 30 30 30 30 30 30 30 30 30 30 31" \ -s "00 20 00 80" \ -s "00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00"
Try combinations of the P2 parameter with each key PIN having a different value . NOTE multiple failures may cause PIN be locked, and you will need to reset it. -s "00 20 00 80" will test login state before and after the verify. I suspect these will work as expected.
Note extra 00 on two of the above, as this is Le=256 as these expect a response other then just status Change the PIN in the second one to what ever is your pin.
Since OpenSC tries to use two slots for PKCS11 id there is more then one PIN, each slot may only see one PIN (and its PUK). So that may also work with Adobe Signatures, but id not there may be a way two allow the first slot to also have access to the second PIN in cases where the intent is to use a different PIN. We can discuss this if you can "pin down" (pun intended) how the card actually works.
dengert
commented
3 years ago Two other comments. If pin only works with max length, that may mean the padding is wrong. Driver does not set pad_char, so defaults to 0x00. More common is 0xFF. With PIN=123456 try opensc tool -s "00 20 00 80 0C 31 32 33 34 35 36 FF FF FF FF FF FF"
dengert
commented
3 years ago Any CardOS users seen this situation?
I should have asked, are there any other applications running that might access the card? ForFox, Thunderbird, OpenPGP TokenD some keyring application? Interference from other applications might cause the card to lose its login state, and this does not show up in opensc debug logs.
Looking at your comment: https://github.com/OpenSC/OpenSC/issues/2244#issuecomment-790110405 , card-cardos.c and your debug logs - here are some more observations.
This card may do something similar. After verify with the Sign PIN, the the Set Security Env `00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00' must be next, then the PSO command that we never got to. This can be tested with the:
opensc-tool -s "00 20 00 81" \
-s "00 A4 08 0C 02 1F FF 00" \
-s "00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31" \
-s "00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00"I would also be interested in seeing the output of pkcs11-tool --test --login --slot 0 to see what happens to when using the AUTH key when you have a 12 byte pin. (i.e. avoid the PIN padding and userConsent issues and test the signature.) It looks like 91 == 0x80 | 0x11 should be the P2 parameter for the AUTH pin.
As part of a group effort of developers and users with CardOS cards, commit db41cd9ab1033e0c63c894e2dcdd3da14edec3cf part of https://github.com/OpenSC/OpenSC/pull/1987 that fixed https://github.com/OpenSC/OpenSC/issues/1916 made many changes to the driver. The code to set SC_CARD_CAP_ISO7816_PIN_INFO was not changed, just moved and intended.
So if you can build from git and modify https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L213 by removing card->type == SC_CARD_TYPE_CARDOS_V5_0 || that would tell driver to not send the 00 20 00 81 commands. (This a test of your card only, not a general fix) But before you do this try the pkcs11-tool --test --login --slot 0 command, and get a log.
the-docta
commented
3 years ago Hi @dengert , thanks for the replies. will check what the commands do. few high level replies first: I had set both PINs to same value as long as verification wasn't working (which turns out to be a padding issue or similar) - when running the last test, I only had changed one of them (signature pin) to 000...0001, so I know I was asked for and I was entering the signature pin.
Building from source: I'd be more than willing, but would need some hints. I started here and ran ./bootstrap, which immediately failed with aclocal missing. After some googling I brew-installed automake, which was the missing pachage. now, bootstrapping ran fine. what now? looked around and found a build script in MacOS folder. changed to that folder, ran build, it expected bootstrap in same folder. so changed back to root folder of the repo and ran ./MacOS/buidl from here, which did a lot of stuff and was missing gengetopt, which I brew-installed. In the end,
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instancewill install full XCode now. but maybe the above couple of lines are worth considering adding as requirements to the wiki page
the-docta
commented
3 years ago Two other comments. If pin only works with max length, that may mean the padding is wrong. Driver does not set pad_char, so defaults to 0x00. More common is 0xFF. With PIN=123456 try
opensc tool -s "00 20 00 80 0C 31 32 33 34 35 36 FF FF FF FF FF FF"
this is verified - with padding 0xFF, shorter passwords work.
the-docta
commented
3 years ago I would also be interested in seeing the output of
pkcs11-tool --test --login --slot 0to see what happens to when using the AUTH key when you have a 12 byte pin. (i.e. avoid the PIN padding and userConsent issues and test the signature.) It looks like91 == 0x80 | 0x11should be the P2 parameter for the AUTH pin.
yes, the Card-PIN uses 0x91 as P2 parameter
I have set different values for Card-PIN and Signature PIN, both versions return successfully from verification (here with debug=0)
» opensc-tool -s "00 20 00 91" \
-s "00 A4 08 0C 02 1F FF 00" \
-s "00 20 00 91 0C 30 30 30 30 30 30 30 30 30 30 30 32" \
-s "00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00"
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 91
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 91 0C 30 30 30 30 30 30 30 30 30 30 30 32
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00
Received (SW1=0x69, SW2=0x82)
-----------------------------------------------------------------------------
» opensc-tool -s "00 20 00 81" \
-s "00 A4 08 0C 02 1F FF 00" \
-s "00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31" \
-s "00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00"
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00
Received (SW1=0x69, SW2=0x82)if I insert 00 20 00 xx between the last two lines, it immediately returns 63 C3
~ » opensc-tool -s "00 20 00 91" \
-s "00 A4 08 0C 02 1F FF 00" \
-s "00 20 00 91 0C 30 30 30 30 30 30 30 30 30 30 30 32" \
-s "00 20 00 91" \
-s "00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00"
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 91
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 91 0C 30 30 30 30 30 30 30 30 30 30 30 32
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 91
Received (SW1=0x63, SW2=0xC3)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00
Received (SW1=0x69, SW2=0x82)OK. The failure of 00 20 00 xx to return 90 00 means the card does not support SC_CARD_CAP_ISO7816_PIN_INFO but the driver says these cards do support it in line: https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L213-L215
The presence of the 00 20 00 xx might even cause the login state to be lost. So try the opensc-tool test again without any -s "00 20 00 XX" options.
One trick you can use is to set in opensc.conf a card_atr stanza and set type = 1008; which is SC_CARD_TYPE_CARDOS_M4_4.
If none work, you will need to set a new card type in cards.h for you card, as it is not a SC_CARD_TYPE_CARDOS_V5_0.
If card is really not a SC_CARD_TYPE_CARDOS_V5_0 card, then this code
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L982-L1023 that produced the 00 22 41 B6 09 84 01 02 95 01 40 80 01 10 00 may be wrong too. But 69 82 is security status not satisfied which sounds like it accepted the command then found security status not satisfied.
the-docta
commented
3 years ago setting type in the config file didnt seem to make a difference. But I manually went through all the variations of 00 22 41 B6 command (with length 3, length 6 and length 9), keyref being 0x02:
pkcs15-tool --dump:
...
Public RSA Key [Signaturschluessel]
Object Flags : [0x00]
Usage : [0x200], nonRepudiation
Access Flags : [0x00]
ModLength : 3072
Key ref : 2 (0x02)
Native : yes
Path : 3f001fff
Auth ID : 01
ID : 12here the results, always producing 9000 after providing pin, and 6982 after
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 03 83 01 02
Received (SW1=0x69, SW2=0x82)
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 06 84 01 02 95 01 40
Received (SW1=0x69, SW2=0x82)
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 00
Received (SW1=0x69, SW2=0x82)
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 10
Received (SW1=0x69, SW2=0x82)
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 20
Received (SW1=0x69, SW2=0x82)
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 20 00 81
Received (SW1=0x63, SW2=0xC3)
Sending: 00 A4 08 0C 02 1F FF 00
Received (SW1=0x90, SW2=0x00)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 41 B6 09 84 01 02 95 01 40 80 01 30
Received (SW1=0x69, SW2=0x82)
so the problem appears to be the set security env.
Does the card work on Windows using vendor drivers? Can you get a usb trace? You should see the apdus and data in the trace.
Also since this card may not be a SC_CARD_TYPE_CARDOS_V5_0, but more like a SC_CARD_TYPE_CARDOS_M4, so look at https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L1015-L1020
the-docta
commented
3 years ago The card works with SecSigner for Mac - if I only knew how to create a USB trace.
so look at https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L1015-L1020
that's the first block in the last comment (command 00 22 41 B6 with length 3)
the-docta
commented
3 years ago will have a look at usb tracing tonight. from a quick google search, it is apparently easier to usb-trace on windows.
dengert
commented
3 years ago Most smartcard software calls PCSC to a CCID driver to USB to your USB reader that talks to the card.
So a trace of PCSC is preferable but USB would do, but harder to read.
Google for: pcsc trace MacOS Which leads to: https://ludovicrousseau.blogspot.com/2018/
I don't think the problem is MacOS specific, so if you can not get a PCSC or USB trace try a different system. I use windows as a host with Ubuntu running under VirtualBox for most development. Also have Ubuntu on Intel and RaspberryPi.
https://seccommerce.com/en/downloads-secsigner-secsign-id/ has Windows and Linux (Ubuntu) drivers.
On linux: sudo /usr/sbin/pcscd -f -a -d will produce a lot of output. running opensc-tool --serial on a PIV has lines like:
APDU: 00 CB 3F FF 03 5C 01 7E 00 (GET DATA of the PIV object 7E)
SW: 7E 12 4F 0B A0 00 00 03 08 00 00 10 00 01 00 5F 2F 02 60 10 90 00
dengert
commented
3 years ago If you are going to try it on Windows, Google for: Windows PC/SC trace That would be a lot easier to read and smaller then a USB trace. USB trace is last resort.
the-docta
commented
3 years ago I should have checked this thread before I started usb sniffing... anyway, got a working trace:
» opensc-tool -s "00a4010c 02 1fff" \
-s "00200081 0c 303030303030303030303031" \
-s "0022f309" \
-s "002a9e9a0000 20 6adb...346e 0000"
Using reader with a card: Gemalto PC Twin Reader
Sending: 00 A4 01 0C 02 1F FF
Received (SW1=0x6A, SW2=0x82)
Sending: 00 20 00 81 0C 30 30 30 30 30 30 30 30 30 30 30 31
Received (SW1=0x90, SW2=0x00)
Sending: 00 22 F3 09
Received (SW1=0x90, SW2=0x00)
Sending: 00 2A 9E 9A 00 00 20 6A DB ... 34 6E 00 00
Received (SW1=0x90, SW2=0x00):
0A 50 E8 5F 95 2D EB 17 FC CE A6 99 86 5C 99 85 .P._.-.......\..
26 4C 85 66 BB 77 02 66 00 BC C3 67 81 DD 16 24 &L.f.w.f...g...$
...I also found that the command between the login and the signing command, corresponds to cardos_restore_security_env(card, 0x09);
will go through the driver (not today) and adjust the few places and try to check that other functions work as well...
you could give me a few hints, though:
im working on mac. if I start from a clean git repo, run Macos/build script, install the created dmg file, I get my new code.
if I modify the cardos driver, even running "make distclean" and then "MacOS/build" results in a dmg file, which contains the ond driver. What do I need to run to force the new modified C file to be taken into the package (ideally without rebuilding the full thing)
once the driver is in state "works forme" Id like to add as a new type or something, will need a few hints on that as well.
dengert
commented
3 years ago Interesting, look at: 915 sc_format_apdu(card, &apdu, SC_APDU_CASE_1, 0x22, 0, se_num); 916 apdu.p1 = (card->type == SC_CARD_TYPE_CARDOS_CIE_V1 ? 0xF3 : 0x03);
maybe your card is more like a SC_CARD_TYPE_CARDOS_CIE_V1? But I don't see where it is ever set. There is also a SC_CARD_TYPE_ITACNS_CIE_V1 Both used in ./pkcs15-itacns.c.
A card_atr stanza in opensc.conf can be used to set the card type.
Within git repro: git-clean --dry-run (and other options) helps.
When you git pull, fetch, update, you should run the ./bootstrap script.
I never build in the source. for two reasons:
rm -fr * to clean it out then ../OpenSC/configure ( I actually have some scrip that at add options to point at the different versions of OpenSSL and other things). Look at cards.h where the SC_CARD_TYPE_* are enumerated.
frankmorgner
commented
3 years ago What's the status of this topic, is there anything to do?
EVi1b7wO
commented
3 years ago Hi,
"D-Trust Card 3.1" is based on Atos CardOS 5.0 HW but customized to de*th, official Atos CardOS middleware (CSP, PKCS#11) is unable to talk to this card at all.
CC EAL Report may be found over here (if helpful). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte/Reporte08/0833b_pdf.pdf
There is 1) a qualified certificate (+ application) for digital signatures 2) an advanced certificate (+ application) for digital signatures available both protected by their own PIN and PUK, no SO-PIN of course.
Signatures are generated using RSA SSA-PSS utilizing PKCS#1 v.2.1 padding, the card itself seems to only accept hashed CMS SignedData.
"D-Trust Assistant" reveals the directory structure and PINs as
3F00 1FFE C001 + C00D (intermediate) + C00E (root) (qualified certificate + PIN 0x81)
3F00 1FFE C101 + C10D (intermediate) + C10E (root) (advanced certificate + PIN 0x11)
Signing CMS SignedData hash requires 1) SELECT of wanted PIN AID (or EF?) 2) followed by a VERIFY PIN DIRECT control command (using card reader w/ SPE) 3) the aforementioned MSE F3 09 4) and PSO 9E 9A to create the signature in the end
HTH
gh47110815
commented
1 year ago Hi,
Sorry for the maybe stupid question: What does that last post (EVi1b7wO commented on Nov 22, 2021) combined with the fact, that this issue seems still to be open mean?
Does it mean, that after 2 years there is still no chance of getting these German D-Trust-Cards integrated and running with OpenSC (OpenSC-0.23.0, rev: 5497519, commit-time: 2022-11-29 09:34:43 +0100) on a mac (macOS Ventura 13.3.1)? I am using the downloaded binary as a "normal" user, because I am not able to build such kind of specialized stuff or understanding HexCodes ;-)
From a user perspective same symthoms here on my tests ... Running "pkcs11-tool --test --login --slot 1" (slot 1 holds the "Signature-PIN")
asks me for the PIN on the CardReader (Reiner SCT cyberJack Komfort). After Entering the PIN on the CardReader it answers with "Korrekt" on the Display, BUT pkcs11-tool replies with ...
_C_SeedRandom() and C_GenerateRandom(): seeding (C_SeedRandom) not supported seems to be OK Digests: all 4 digest functions seem to work MD5: OK RIPEMD160: OK SHA-1: OK SHA256: OK Signatures (currently only for RSA) testing key 0 (Signaturschluessel) error: PKCS11 function C_SignFinal failed: rv = CKR_USER_NOT_LOGGED_IN (0x101) Aborting.
Signing a PDF-File with Adobe Acrobat seems to work (I can choose the qualified certificate from the card, I can mark the area where the signature should be positioned, Acrobat asks for a new filename, CardReader asks for the PIN which I entered correctly) until the last step, which also replies with an Adobe Error Dialog containing that 0x101 Error.
Thanks for a short "status update"?
frankmorgner
commented
1 year ago If someone is interested in fixing support for this card or adding a specific card driver for the D-Trust Card, I can provide the full technical specification (German). Unfortunately, I never had the time to look at this in depth.
ralfboernemeier
commented
1 year ago Hi, I have the same problem as described by @gh47110815 with a D-TRUST Card 4.1 Std. RSA 2ca and a ReinerSCT card reader (cyberJack RFID komfort USB 1) with CardOS V5.4. I also use OpenSC 0.23.0.
I tried to sign a document with the OpenSource tool DSS Signing Tool 5.12.1 (Nowina) and the MS CAPI Signature Token API. First there is a request to select a certificate, then there is a request to enter a secure PIN at the reader. After entering the PIN, which is acknowledged at the reader with "PIN correct", there is an error:
Unable to sign the digest: Unable to sign: An internal consistency check failed.Signing this way with another MS CAPI driver works. I use Windows 10 x64 as my operating system.
It would be very helpful if OpenSC would finally support the D-TRUST cards, one of the leading providers of signature cards in Germany, after such a long time.
frankmorgner
commented
10 months ago may be fixed with https://github.com/OpenSC/OpenSC/pull/2943
hamarituc
commented
10 months ago may be fixed with #2943
I think the code of #2943 won't work for 3.1 cards, as it checks the card type an version. From the error message I think the driver will work with some minor modifications. But currently I don't have access to the card specification (might change in the near future) nor to some test cards which makes it hard to implement this cards.
Furthermore the 3.1 card series was discontinued in favor of 4.1 and 5.1 cards. So there is little benefit of providing an implementation for them as no more cards are issued and all existing cards are approaching the end of their life-cycle.
frankmorgner
commented
8 months ago @hamarituc , the PIN-pad problem has also been reported for D-Trust Card 4.1, could you have a look at this?
hamarituc
commented
8 months ago @hamarituc , the PIN-pad problem has also been reported for D-Trust Card 4.1, could you have a look at this?
Is there a specific issue for a problem report for 4.1 cards?
Testing pin-pad readers is still on my todo list so I will do that.
But I don't have access to the readers in this issue. Currently my only pin-pad reader is a cherry secure board, which is unfortunately not working with my D-Trust card at the moment. In my case the keyboards request to enter the PIN. After entering the PIN the signature fails with an "incorrect PIN" error, but the fail counter is not decreased. I first need to solve the problem with my reader to rule out some other issues. Maybe then I will be able to get a cyberJack reader.
hamarituc
commented
2 months ago The two time input problem seems to be an issue of pkcs11-tool. It requests the PIN twice:
#0 0x00007ffff758663f in poll () at /lib64/libc.so.6
#1 0x00007ffff7ced75b in MessageReceive () at /usr/lib64/libpcsclite.so.1
#2 0x00007ffff7cea087 in SCardControl () at /usr/lib64/libpcsclite.so.1
#3 0x00007ffff7d8def7 in pcsc_internal_transmit (reader=0x5555555ce830,
sendbuf=0x7fffffffc550 "\036\036\202", sendsize=24, recvbuf=0x7fffffffc440 "X}
\364\367\377\177", recvsize=0x7fffffffc418, control=1107299762) at reader-
pcsc.c:267
#4 0x00007ffff7d94657 in pcsc_pin_cmd (reader=0x5555555ce830,
data=0x7fffffffc910) at reader-pcsc.c:2227
#5 0x00007ffff7d53b19 in iso7816_pin_cmd (card=0x5555555d04f0,
data=0x7fffffffc910, tries_left=0x5555555f1214) at iso7816.c:1328
#6 0x00007ffff7d44e4a in sc_pin_cmd (card=0x5555555d04f0,
data=0x7fffffffc910, tries_left=0x5555555f1214) at sec.c:212
#7 0x00007ffff7d6da8a in sc_pkcs15_verify_pin_with_session_pin
(p15card=0x5555555d1d10, pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0,
sessionpin=0x0, sessionpinlen=0x0) at pkcs15-pin.c:442
#8 0x00007ffff7d6d307 in _sc_pkcs15_verify_pin (p15card=0x5555555d1d10,
pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0) at pkcs15-pin.c:329
#9 0x00007ffff7d6d1ff in sc_pkcs15_verify_pin (p15card=0x5555555d1d10,
pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0) at pkcs15-pin.c:316
#10 0x00007ffff6f9b056 in pkcs15_login (slot=0x5555555cf9c0, userType=1,
pPin=0x0, ulPinLen=0) at framework-pkcs15.c:1907
#11 0x00007ffff6f84b6e in C_Login (hSession=93824992937888, userType=1,
pPin=0x0, ulPinLen=0) at pkcs11-session.c:388
#12 0x000055555556343d in login (session=93824992937888, login_type=1) at
pkcs11-tool.c:1962
#13 0x00005555555616a6 in main (argc=8, argv=0x7fffffffcfd8) at pkcs11-tool.c:
1369#0 0x00007ffff758663f in poll () at /lib64/libc.so.6
#1 0x00007ffff7ced75b in MessageReceive () at /usr/lib64/libpcsclite.so.1
#2 0x00007ffff7cea087 in SCardControl () at /usr/lib64/libpcsclite.so.1
#3 0x00007ffff7d8def7 in pcsc_internal_transmit (reader=0x5555555ce830,
sendbuf=0x7fffffffbe60 "\036\036\202", sendsize=24, recvbuf=0x7fffffffbd50 "X}
\364\367\377\177", recvsize=0x7fffffffbd28, control=1107299762) at reader-
pcsc.c:267
#4 0x00007ffff7d94657 in pcsc_pin_cmd (reader=0x5555555ce830,
data=0x7fffffffc220) at reader-pcsc.c:2227
#5 0x00007ffff7d53b19 in iso7816_pin_cmd (card=0x5555555d04f0,
data=0x7fffffffc220, tries_left=0x5555555f1214) at iso7816.c:1328
#6 0x00007ffff7d44e4a in sc_pin_cmd (card=0x5555555d04f0,
data=0x7fffffffc220, tries_left=0x5555555f1214) at sec.c:212
#7 0x00007ffff7d6da8a in sc_pkcs15_verify_pin_with_session_pin
(p15card=0x5555555d1d10, pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0,
sessionpin=0x0, sessionpinlen=0x0) at pkcs15-pin.c:442
#8 0x00007ffff7d6d307 in _sc_pkcs15_verify_pin (p15card=0x5555555d1d10,
pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0) at pkcs15-pin.c:329
#9 0x00007ffff7d6d1ff in sc_pkcs15_verify_pin (p15card=0x5555555d1d10,
pin_obj=0x5555555f04d0, pincode=0x0, pinlen=0) at pkcs15-pin.c:316
#10 0x00007ffff6f9b01d in pkcs15_login (slot=0x5555555cf9c0, userType=2,
pPin=0x0, ulPinLen=0) at framework-pkcs15.c:1904
#11 0x00007ffff6f84a35 in C_Login (hSession=93824992937888, userType=2,
pPin=0x0, ulPinLen=0) at pkcs11-session.c:369
#12 0x000055555556343d in login (session=93824992937888, login_type=2) at
pkcs11-tool.c:1962
#13 0x0000555555564d8a in sign_data (slot=5, session=93824992937888,
key=93824992881872) at pkcs11-tool.c:2470
#14 0x0000555555561c86 in main (argc=8, argv=0x7fffffffcfd8) at pkcs11-tool.c:
1490Kindly asked @jpwidera to troubleshoot this issue. Would be interesting if this problem is also related to other card types.
frankmorgner
commented
2 months ago Regarding the PIN that is asked twice, this is caused by a reauthentication of a PIN set to CKA_ALWAYS_AUTHENTICATE. PKCS#11 says the following:
The CKA_ALWAYS_AUTHENTICATE attribute can be used to force re-authentication (i.e. force the user to provide a PIN) for each use of a private key. “Use” in this case means a cryptographic operation such as sign or decrypt. This attribute may only be set to CK_TRUE when CKA_PRIVATE is also CK_TRUE.
Re-authentication occurs by calling C_Login with userType set to CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the key has been initiated (e.g. after C_SignInit). In this call, the actual user type is implicitly given by the usage requirements of the active key. If C_Login returns CKR_OK the user was successfully authenticated and this sets the active key in an authenticated state that lasts until the cryptographic operation has successfully or unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..). A return value CKR_PIN_INCORRECT from C_Login means that the user was denied permission to use the key and continuing the cryptographic operation will result in a behavior as if C_Login had not been called. In both of these cases the session state will remain the same, however repeated failed re-authentication attempts may cause the PIN to be locked. C_Login returns in this case CKR_PIN_LOCKED and this also logs the user out from the token. Failing or omitting to re-authenticate when CKA_ALWAYS_AUTHENTICATE is set to CK_TRUE will result in CKR_USER_NOT_LOGGED_IN to be returned from calls using the key. C_Login will return CKR_OPERATION_NOT_INITIALIZED, but the active cryptographic operation will not be affected, if an attempt is made to re-authenticate when CKA_ALWAYS_AUTHENTICATE is set to CK_FALSE.
In the backtrace you can observe userType=1 the first time (CKU_USER) and userType=2 the second time (CKU_CONTEXT_SPECIFIC). This property is propagated to the card driver in struct sc_pin_cmd_data's pin_type as SC_AC_CONTEXT_SPECIFIC.
It is true, that pkcs11-tool is somewhat lazy in that it is always performing C_Login, if a cryptographic operation is requested. Since CKA_ALWAYS_AUTHENTICATE forces to re-do this immediately before this very operation, pkcs11-tool needs to call C_Login a second time immediately before that with CKU_CONTEXT_SPECIFIC. However, we observed similar behavior from other applications (e.g. Firefox), because some cards require a PIN authentication before certificates with user data can be read without having to verify the PIN for a cryptographic operation (because READ BINARY doesn't reset the PIN state even with CKA_ALWAYS_AUTHENTICATE).
Long story short, if you want to avoid to enter the PIN twice, you need to handle CKU_CONTEXT_SPECIFIC within the card driver to check if an authentication is actually required. This is currently only done in card-piv.c, if you want to look at some example (search for context_specific).
frankmorgner
commented
2 months ago You could try if the following patch fixes the need for entering the PIN twice:
diff --git a/src/libopensc/card-cardos.c b/src/libopensc/card-cardos.c
index 595ec099e..8f0cba6f9 100644
--- a/src/libopensc/card-cardos.c
+++ b/src/libopensc/card-cardos.c
@@ -1521,6 +1521,18 @@ cardos_pin_cmd(struct sc_card *card, struct sc_pin_cmd_data *data,
if (data->pin2.max_length == 0)
data->pin2.max_length = 8;
+ if (data->pin_type == SC_AC_CONTEXT_SPECIFIC &&
+ data->flags & SC_PIN_CMD_USE_PINPAD &&
+ card->caps |= SC_CARD_CAP_ISO7816_PIN_INFO) {
+ /* try to avoid PIN queries at the PIN pad in case of re-authentication */
+ struct sc_pin_cmd_data info_data = *data;
+ info_data.cmd = SC_PIN_CMD_GET_INFO;
+ rv = iso_ops->pin_cmd(card, &info_data, tries_left);
+
+ if (info_data.pin1.logged_in == SC_PIN_STATE_LOGGED_IN)
+ LOG_FUNC_RETURN(ctx, rv);
+ }
+
rv = iso_ops->pin_cmd(card, data, tries_left);
LOG_FUNC_RETURN(ctx, rv);
}This could similarly implemented one layer above (sc_pkcs15_verify_pin_with_session_pin()) to enable this for every card or it could be implemented one layer below in the default driver (iso7816_build_pin_apdu()). However, I'm not sure whether this would be useful: After all, it is the application which requests re-authentication... maybe we should then fulfill this request.
jpwidera
commented
2 months ago I can confirm, that your idea on modifying sc_pkcs15_verify_pin_with_session_pin() works.
I tested it on "REINER SCT cyberJack RFID komfort" with DTrust-Card 4.1.
diff --git a/src/libopensc/pkcs15-pin.c b/src/libopensc/pkcs15-pin.c
index 120347826..2e9592c7a 100644
--- a/src/libopensc/pkcs15-pin.c
+++ b/src/libopensc/pkcs15-pin.c
@@ -439,6 +439,18 @@ int sc_pkcs15_verify_pin_with_session_pin(struct sc_pkcs15_card *p15card,
goto out;
}
+ if (data.pin_type == SC_AC_CONTEXT_SPECIFIC &&
+ data.flags & SC_PIN_CMD_USE_PINPAD &&
+ card->caps & SC_CARD_CAP_ISO7816_PIN_INFO) {
+ /* try to avoid PIN queries at the PIN pad in case of re-authentication */
+ struct sc_pin_cmd_data info_data = data;
+ info_data.cmd = SC_PIN_CMD_GET_INFO;
+ r = sc_pin_cmd(card, &info_data, &auth_info->tries_left);
+
+ if (info_data.pin1.logged_in == SC_PIN_STATE_LOGGED_IN)
+ LOG_FUNC_RETURN(ctx, r);
+ }
+However, I'm not sure whether this would be useful: After all, it is the application which requests re-authentication... maybe we should then fulfill this request.
Maybe I did not get this correct: There is this flag --always-auth which will force this behavior? Or is this behavior default? I did use pkcs11-tool --slot 0x9 -s -a Signaturzertifikat -m SHA256-RSA-PKCS -i testfile -o testfile.sig (thx to @hamarituc)
dengert
commented
2 months ago Main problem is PKCS15 user_consent is an integer where as PKCS11 CKA_ALWAYS_AUTHENTICATE is a bool. CKA_ALWAYS_AUTHENTICATE is an attribute of the key, which pkcs11 sets if user_consent > 0.
If the card driver or pkcs15 routines knew the user_consent and kept a count of usage of the key and only returned CKA_ALWAYS_AUTHENTICATE if the limit was about to be reached and the OpenSC pkcs11 routines only returned CKA_ALWAYS_AUTHENTICATE when the use count was down to one - the application would then not call prompt for the pin and calling CKA_ALWAYS_AUTHENTICATE for every operation. (When pin pad is used the prompt it to the pin pad internally in OpenSC when C_Login is called.)
Problem is applications may assume the CKA_ALWAYS_AUTHENTICATE does not change for specific key and only query it once.
From the PKCS11 view C_Login(CKU_CONTEXT_SPECIFIC) is only to be used after a crypto operation like C_SignInit but before it is finalized even though for most cards the pin is the same as the login pin.
The SC_CARD_CAP_ISO7816_PIN_INFO if not logged in, returns the number of failed pin attempts in a row till the card will lockup otherwise it returns that user is logged in for the card, not necessarily for a specific key.
An example is the PIV card has one key that requires a PIN verify APDU must be sent before the crypto operation APDU with no intervening APDUs. i.e. the user_consent is 1.
frankmorgner
commented
2 months ago is this behavior default?
To always authenticate is the default in this case, because the card's profile tells our middleware that this is needed. We propagate this information to the application, which in turn requests repeated authentication.
This can only be avoided, if there is some special treatment to check whether or not reauthentication is needed. This means to either check for the authentication status (my patch) or check whether a crypto operation has been used (as Doug described). Either way, I think this handling is better done in the card driver, as it may not be suitable for all types of cards that we are supporting.
jpwidera
commented
2 months ago Ok, makes sense. I'll take a look at the card driver.
dengert
commented
2 months ago You may want to read this comment from @hamarituc that says some of the Dtrust multicard cards allow for 100 usages of a key per pin verification: https://github.com/OpenSC/OpenSC/issues/3236#issuecomment-2367675677
The "user_consent" field in PKCS15 is called "userConsent" and is an optional common attribute for private objects. It may be present in the ASN1 on the card. OpenSC does check for this attribute. But in the one trace in #3236 it was not present.
dengert
commented
2 months ago Also note that if @hamarituc implements a pkcs15-dtrust.c, it and the card-dtrust.c could set the user_consent 1 or 100 for the signature key based on the card type. Many pkcs15 and card driver communicate via sc_card_ctl. See: cardctl.h
hamarituc
commented
2 months ago You may want to read this comment from @hamarituc that says some of the Dtrust multicard cards allow for 100 usages of a key per pin verification: #3236 (comment)
The "user_consent" field in PKCS15 is called "userConsent" and is an optional common attribute for private objects. It may be present in the ASN1 on the card. OpenSC does check for this attribute. But in the one trace in #3236 it was not present.
It is only present for the qualified signing key ("Signaturschluessel") of the "Multicard 100", but not for the advanced signing and encryption key ("Authentisierungsschluessel") and neither on both keys of the unlimited Multicard. See the line marked with the arrow -->
OpenSC [3F00/0104]> asn1 5001
A0 Context 0 (62 bytes)
30 SEQUENCE (35 bytes)
0C UTF8String (26 bytes): Authentisierungsschluessel
03 BIT STRING (2 bytes): 01
04 OCTET STRING (1 byte): 03 .
30 SEQUENCE (11 bytes)
04 OCTET STRING (1 byte): 03 .
03 BIT STRING (3 bytes): 100000100
02 INTEGER (1 byte): 131
A1 Context 1 (10 bytes)
30 SEQUENCE (8 bytes)
30 SEQUENCE (6 bytes)
04 OCTET STRING (4 bytes): 3F 00 01 02 ?...
A0 Context 0 (57 bytes)
30 SEQUENCE (30 bytes)
0C UTF8String (18 bytes): Signaturschluessel
03 BIT STRING (2 bytes): 01
04 OCTET STRING (1 byte): 07 .
--> 02 INTEGER (1 byte): 100
30 SEQUENCE (11 bytes)
04 OCTET STRING (1 byte): 02 .
03 BIT STRING (3 bytes): 1000000000
02 INTEGER (1 byte): 130
A1 Context 1 (10 bytes)
30 SEQUENCE (8 bytes)
30 SEQUENCE (6 bytes)
04 OCTET STRING (4 bytes): 3F 00 01 01 ?...For the RSA standard card the userConsent field of the qualified signature key is set to 1.
OpenSC [3F00/0104]> asn1 5001
30 SEQUENCE (66 bytes)
30 SEQUENCE (35 bytes)
0C UTF8String (26 bytes): Authentisierungsschluessel
03 BIT STRING (2 bytes): 01
04 OCTET STRING (1 byte): 03 .
30 SEQUENCE (11 bytes)
04 OCTET STRING (1 byte): 03 .
03 BIT STRING (2 bytes): 101110
02 INTEGER (2 bytes): 3
A1 Context 1 (14 bytes)
30 SEQUENCE (12 bytes)
30 SEQUENCE (6 bytes)
04 OCTET STRING (4 bytes): 3F 00 01 02 ?...
02 INTEGER (2 bytes): 3072
30 SEQUENCE (62 bytes)
30 SEQUENCE (30 bytes)
0C UTF8String (18 bytes): Signaturschluessel
03 BIT STRING (2 bytes): 01
04 OCTET STRING (1 byte): 07 .
--> 02 INTEGER (1 byte): 1
30 SEQUENCE (12 bytes)
04 OCTET STRING (1 byte): 02 .
03 BIT STRING (3 bytes): 1000000000
02 INTEGER (2 bytes): 2
A1 Context 1 (14 bytes)
30 SEQUENCE (12 bytes)
30 SEQUENCE (6 bytes)
04 OCTET STRING (4 bytes): 3F 00 01 01 ?...
02 INTEGER (2 bytes): 3072Also note that if @hamarituc implements a
pkcs15-dtrust.c, it and thecard-dtrust.ccould set theuser_consent1 or 100 for the signature key based on the card type. Many pkcs15 and card driver communicate viasc_card_ctl. See:cardctl.h
I submitted the PKCS#15 emulation in #3240 today. So this should be the base for fixing this userConsent issue.
hamarituc
commented
1 month ago Just for the records: The enter-PIN-twice-problem can be reproduced with pkcs11-tool like shown below. This may be obvious for experts, but helpful for newcomers to validate their patches. It happens only for the Signature PIN of the Standard Card and the Multicard 100, but not for the unlimited Multicard nor for the Card PIN of all cards (to sum up: all cards with userConsent tag is set).
Standard Card, Signature PIN, userConsent = 1 -> 2 queries
$ pkcs11-tool --slot 1 -a Signaturzertifikat -s -m SHA256-RSA-PKCS -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter User PIN:
Using signature algorithm SHA256-RSA-PKCS
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter context specific PIN: Standard Card, Card PIN, no userConsent -> 1 query
$ pkcs11-tool --slot 0 -a Authentisierungszertifikat -s -m SHA256-RSA-PKCS -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card 4.1 S... (Card-PIN)".
Please enter User PIN:
Using signature algorithm SHA256-RSA-PKCSMulticard 100, Signature PIN, userConsent = 100 -> 2 queries
$ pkcs11-tool --slot 1 -a Signaturzertifikat -s -m ECDSA-SHA256 -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter User PIN:
Using signature algorithm ECDSA-SHA256
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter context specific PIN: Multicard 100, Card PIN, no userConsent -> 1 query
$ pkcs11-tool --slot 0 -a Authentisierungszertifikat -s -m ECDSA-SHA256 -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card 4.1 M... (Card-PIN)".
Please enter User PIN:
Using signature algorithm ECDSA-SHA256Multicard, Signature PIN, no userConsent -> 1 query
$ pkcs11-tool --slot 1 -a Signaturzertifikat -s -m ECDSA-SHA256 -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card ... (Signature-PIN)".
Please enter User PIN:
Using signature algorithm ECDSA-SHA256Multicard, Card PIN, no userConsent -> 1 query
$ pkcs11-tool --slot 0 -a Authentisierungszertifikat -s -m ECDSA-SHA256 -i /tmp/hello.txt -o /tmp/hello.sig
Logging in to "D-TRUST Card 4.1 M... (Card-PIN)".
Please enter User PIN:
Using signature algorithm ECDSA-SHA256You could try if the following patch fixes the need for entering the PIN twice:
diff --git a/src/libopensc/card-cardos.c b/src/libopensc/card-cardos.c index 595ec099e..8f0cba6f9 100644 --- a/src/libopensc/card-cardos.c +++ b/src/libopensc/card-cardos.c @@ -1521,6 +1521,18 @@ cardos_pin_cmd(struct sc_card *card, struct sc_pin_cmd_data *data, if (data->pin2.max_length == 0) data->pin2.max_length = 8; + if (data->pin_type == SC_AC_CONTEXT_SPECIFIC && + data->flags & SC_PIN_CMD_USE_PINPAD && + card->caps |= SC_CARD_CAP_ISO7816_PIN_INFO) { + /* try to avoid PIN queries at the PIN pad in case of re-authentication */ + struct sc_pin_cmd_data info_data = *data; + info_data.cmd = SC_PIN_CMD_GET_INFO; + rv = iso_ops->pin_cmd(card, &info_data, tries_left); + + if (info_data.pin1.logged_in == SC_PIN_STATE_LOGGED_IN) + LOG_FUNC_RETURN(ctx, rv); + } + rv = iso_ops->pin_cmd(card, data, tries_left); LOG_FUNC_RETURN(ctx, rv); }This could similarly implemented one layer above (
sc_pkcs15_verify_pin_with_session_pin()) to enable this for every card or it could be implemented one layer below in the default driver (iso7816_build_pin_apdu()). However, I'm not sure whether this would be useful: After all, it is the application which requests re-authentication... maybe we should then fulfill this request.
I adapted this patch to the D-Trust driver in #3266. I furthermore included the patch into the new driver for D-Trust Cards 5.1/5.4 in #3137. I made the following observations:
pkcs11-toolcertutil -scinfo requires two PIN inputs for both card types| Application | 4.1/4.4 | 5.1/5.4 |
|---|---|---|
pkcs11-tool |
:white_check_mark: | :white_check_mark: |
certutil -scinfo |
:x: | :x: |
This are the logs for the Adobe test case:
Here is the relevant difference. For D-Trust 4.1/4.4 the SC_AC_CONTEXT_SPECIFIC is set and then the drivers checks if authentication is necessary:
P:1400; T:9260 2024-11-25 13:03:09.173 [cardmod] CardAuthenticateEx
P:1400; T:9260 2024-11-25 13:03:09.173 [cardmod] check_reader_status for CardAuthenticateEx
P:1400; T:9260 2024-11-25 13:03:09.174 [cardmod] MD_Function:check_card_status:404 called
P:1400; T:9260 2024-11-25 13:03:09.175 [cardmod] MD_Function:check_card_status:414 returning with: 0x00000000
P:1400; T:9260 2024-11-25 13:03:09.176 [cardmod] sizeof(size_t):4 sizeof(ULONG_PTR):4 sizeof(__int3264):4 sizeof pCardData->hSCardCtx:4
P:1400; T:9260 2024-11-25 13:03:09.177 [cardmod] pCardData->hSCardCtx:0xCD010002 hScard:0xEA020000
P:1400; T:9260 2024-11-25 13:03:09.180 [cardmod] sc.c:340:sc_detect_card_presence: called
P:1400; T:9260 2024-11-25 13:03:09.181 [cardmod] reader-pcsc.c:494:pcsc_detect_card_presence: called
P:1400; T:9260 2024-11-25 13:03:09.183 [cardmod] REINER SCT cyberJack RFID komfort (2011541641) 00 00 check
P:1400; T:9260 2024-11-25 13:03:09.363 [cardmod] reader-pcsc.c:403:refresh_attributes: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.364 [cardmod] reader-pcsc.c:502:pcsc_detect_card_presence: returning with: 5
P:1400; T:9260 2024-11-25 13:03:09.365 [cardmod] sc.c:351:sc_detect_card_presence: returning with: 5
P:1400; T:9260 2024-11-25 13:03:09.367 [cardmod] check_reader_status r=5 flags 0x00000005
P:1400; T:9260 2024-11-25 13:03:09.368 [cardmod] MD_Function:check_card_reader_status:489 returning with: 0x00000000
P:1400; T:9260 2024-11-25 13:03:09.369 [cardmod] CardAuthenticateEx: PinId=3, dwFlags=0x20000000, cbPinData=18, Attempts NO
P:1400; T:9260 2024-11-25 13:03:09.370 [cardmod] PIN pad=yes, pbPinData=1390C678, hwndParent=000201D4
P:1400; T:9260 2024-11-25 13:03:09.371 [cardmod] use magic session pin
P:1400; T:9260 2024-11-25 13:03:09.372 [cardmod] standard pin verification
P:1400; T:9260 2024-11-25 13:03:09.372 [cardmod] Setting SC_AC_CONTEXT_SPECIFIC cbPinData: 0 old auth_method: 1 auth_id:7
P:1400; T:9260 2024-11-25 13:03:09.373 [cardmod] pkcs15-pin.c:304:sc_pkcs15_verify_pin: called
P:1400; T:9260 2024-11-25 13:03:09.374 [cardmod] pkcs15-pin.c:351:sc_pkcs15_verify_pin_with_session_pin: called
P:1400; T:9260 2024-11-25 13:03:09.374 [cardmod] PIN(type:0; method:200; value(00000000:0)
P:1400; T:9260 2024-11-25 13:03:09.375 [cardmod] card.c:471:sc_lock: called
P:1400; T:9260 2024-11-25 13:03:09.376 [cardmod] card.c:513:sc_lock: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.376 [cardmod] called; type=2, path=3f000101
P:1400; T:9260 2024-11-25 13:03:09.377 [cardmod] apdu.c:550:sc_transmit_apdu: called
P:1400; T:9260 2024-11-25 13:03:09.378 [cardmod] card.c:471:sc_lock: called
P:1400; T:9260 2024-11-25 13:03:09.379 [cardmod] card.c:513:sc_lock: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.379 [cardmod] apdu.c:515:sc_transmit: called
P:1400; T:9260 2024-11-25 13:03:09.380 [cardmod] apdu.c:363:sc_single_transmit: called
P:1400; T:9260 2024-11-25 13:03:09.381 [cardmod] CLA:0, INS:A4, P1:8, P2:C, data(2) 005CDABE
P:1400; T:9260 2024-11-25 13:03:09.383 [cardmod] reader 'REINER SCT cyberJack RFID komfort (2011541641) 00 00'
P:1400; T:9260 2024-11-25 13:03:09.384 [cardmod] reader-pcsc.c:328:pcsc_transmit:
Outgoing APDU (7 bytes):
00 A4 08 0C 02 01 01 .......
P:1400; T:9260 2024-11-25 13:03:09.384 [cardmod] reader-pcsc.c:245:pcsc_internal_transmit: called
P:1400; T:9260 2024-11-25 13:03:09.421 [cardmod] reader-pcsc.c:337:pcsc_transmit:
Incoming APDU (2 bytes):
90 00 ..
P:1400; T:9260 2024-11-25 13:03:09.423 [cardmod] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.425 [cardmod] apdu.c:539:sc_transmit: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.427 [cardmod] card.c:523:sc_unlock: called
P:1400; T:9260 2024-11-25 13:03:09.429 [cardmod] iso7816.c:737:iso7816_select_file: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.431 [cardmod] card.c:885:sc_select_file: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:03:09.432 [cardmod] sec.c:203:sc_pin_cmd: calledFor D-Trust card 5.1/5.4 the Flag is missing and so the authentication check is skipped forcing an additional PIN prompt.
P:1400; T:9260 2024-11-25 13:05:29.513 [cardmod] CardAuthenticateEx
P:1400; T:9260 2024-11-25 13:05:29.513 [cardmod] check_reader_status for CardAuthenticateEx
P:1400; T:9260 2024-11-25 13:05:29.514 [cardmod] MD_Function:check_card_status:404 called
P:1400; T:9260 2024-11-25 13:05:29.515 [cardmod] MD_Function:check_card_status:414 returning with: 0x00000000
P:1400; T:9260 2024-11-25 13:05:29.516 [cardmod] sizeof(size_t):4 sizeof(ULONG_PTR):4 sizeof(__int3264):4 sizeof pCardData->hSCardCtx:4
P:1400; T:9260 2024-11-25 13:05:29.516 [cardmod] pCardData->hSCardCtx:0xCD020002 hScard:0xEA040000
P:1400; T:9260 2024-11-25 13:05:29.517 [cardmod] sc.c:340:sc_detect_card_presence: called
P:1400; T:9260 2024-11-25 13:05:29.518 [cardmod] reader-pcsc.c:494:pcsc_detect_card_presence: called
P:1400; T:9260 2024-11-25 13:05:29.519 [cardmod] REINER SCT cyberJack RFID komfort (2011541641) 00 00 check
P:1400; T:9260 2024-11-25 13:05:29.736 [cardmod] reader-pcsc.c:403:refresh_attributes: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.737 [cardmod] reader-pcsc.c:502:pcsc_detect_card_presence: returning with: 5
P:1400; T:9260 2024-11-25 13:05:29.738 [cardmod] sc.c:351:sc_detect_card_presence: returning with: 5
P:1400; T:9260 2024-11-25 13:05:29.739 [cardmod] check_reader_status r=5 flags 0x00000005
P:1400; T:9260 2024-11-25 13:05:29.740 [cardmod] MD_Function:check_card_reader_status:489 returning with: 0x00000000
P:1400; T:9260 2024-11-25 13:05:29.740 [cardmod] CardAuthenticateEx: PinId=1, dwFlags=0x20000000, cbPinData=18, Attempts NO
P:1400; T:9260 2024-11-25 13:05:29.741 [cardmod] PIN pad=yes, pbPinData=13C5D5F0, hwndParent=000201D4
P:1400; T:9260 2024-11-25 13:05:29.742 [cardmod] use magic session pin
P:1400; T:9260 2024-11-25 13:05:29.743 [cardmod] standard pin verification
P:1400; T:9260 2024-11-25 13:05:29.744 [cardmod] pkcs15-pin.c:304:sc_pkcs15_verify_pin: called
P:1400; T:9260 2024-11-25 13:05:29.744 [cardmod] pkcs15-pin.c:351:sc_pkcs15_verify_pin_with_session_pin: called
P:1400; T:9260 2024-11-25 13:05:29.745 [cardmod] PIN(type:0; method:1; value(00000000:0)
P:1400; T:9260 2024-11-25 13:05:29.746 [cardmod] card.c:471:sc_lock: called
P:1400; T:9260 2024-11-25 13:05:29.747 [cardmod] card.c:513:sc_lock: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.747 [cardmod] called; type=2, path=3f000101
P:1400; T:9260 2024-11-25 13:05:29.748 [cardmod] apdu.c:550:sc_transmit_apdu: called
P:1400; T:9260 2024-11-25 13:05:29.749 [cardmod] card.c:471:sc_lock: called
P:1400; T:9260 2024-11-25 13:05:29.750 [cardmod] card.c:513:sc_lock: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.750 [cardmod] apdu.c:515:sc_transmit: called
P:1400; T:9260 2024-11-25 13:05:29.752 [cardmod] apdu.c:363:sc_single_transmit: called
P:1400; T:9260 2024-11-25 13:05:29.752 [cardmod] CLA:0, INS:A4, P1:8, P2:C, data(2) 005CDABE
P:1400; T:9260 2024-11-25 13:05:29.753 [cardmod] reader 'REINER SCT cyberJack RFID komfort (2011541641) 00 00'
P:1400; T:9260 2024-11-25 13:05:29.754 [cardmod] reader-pcsc.c:328:pcsc_transmit:
Outgoing APDU (7 bytes):
00 A4 08 0C 02 01 01 .......
P:1400; T:9260 2024-11-25 13:05:29.755 [cardmod] reader-pcsc.c:245:pcsc_internal_transmit: called
P:1400; T:9260 2024-11-25 13:05:29.812 [cardmod] reader-pcsc.c:337:pcsc_transmit:
Incoming APDU (2 bytes):
90 00 ..
P:1400; T:9260 2024-11-25 13:05:29.813 [cardmod] apdu.c:382:sc_single_transmit: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.815 [cardmod] apdu.c:539:sc_transmit: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.815 [cardmod] card.c:523:sc_unlock: called
P:1400; T:9260 2024-11-25 13:05:29.817 [cardmod] iso7816.c:737:iso7816_select_file: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.817 [cardmod] card.c:885:sc_select_file: returning with: 0 (Success)
P:1400; T:9260 2024-11-25 13:05:29.819 [cardmod] sec.c:203:sc_pin_cmd: called@frankmorgner: Would it be a feasible solution to skip the check data->pin_type == SC_AC_CONTEXT_SPECIFIC entirely? I am not aware of the consequences and all the handling in the upper layers is still a mystery to me so this was my first guessing then thinking about it.
frankmorgner
commented
6 days ago This behavior was newly introduced with d336324c11f7c6acd3bad7e9b456b59af60bc857 by @dengert . Before that, the minidriver didn't have any capabilities of sending SC_AC_CONTEXT_SPECIFIC. The current implementation overloads this flag for a "slightly different purpose". I have sketched a different implementation for this "purpose", but we switched to the implementation that is now in master due to lack of side effects at the time. It seems that we now have to look closer...
frankmorgner
commented
6 days ago For 5.1/5.4, the PIN is flagged as user PIN instead of signature PIN in the minidriver, which causes the flag not to be set. You may try the following patch to be a little more relaxed:
diff --git a/src/minidriver/minidriver.c b/src/minidriver/minidriver.c
index 92dcceac3..8b27ac565 100644
--- a/src/minidriver/minidriver.c
+++ b/src/minidriver/minidriver.c
@@ -6014,7 +6014,7 @@ DWORD WINAPI CardAuthenticateEx(__in PCARD_DATA pCardData,
* conflicts with framework-pkcs15.c use of auth_method SC_AC_CONTEXT_SPECIFIC
* for a different purpose. But needs to be reviewed
*/
- if (PinId == MD_ROLE_USER_SIGN && vs->need_pin_always) {
+ if (vs->need_pin_always) {
logprintf(pCardData, 7, "Setting SC_AC_CONTEXT_SPECIFIC cbPinData: %lu old auth_method: %0x auth_id:%x \n",
(unsigned long) cbPinData, (unsigned int) auth_info->auth_method, (unsigned char) auth_info->auth_id.value[0]);
auth_info->auth_method = SC_AC_CONTEXT_SPECIFIC;This will basically always set auth_info->auth_method = SC_AC_CONTEXT_SPECIFIC; if at least one of the PINs does require user consent, which may have side effects (unlikely, I think). For more finegrained control, the the linked suggestion above needs to be implemented.
hamarituc
commented
5 days ago I have to correct myself: After a bit more testing I realized my initial tests were flawed in respect to the difference between the D-Trust 4.1/4.4 and 5.1/5.4 cards. It turned out, that both cards require two PIN inputs for the first signature in Adobe Reader. For the first PIN prompt a Windows timeout dialog appears which counts down 60 seconds to enter the PIN on the pin pad. This dialog doesn't appear for the second PIN prompt.
Signing this document subsequently again, requires just one PIN input and no timeout dialog appears.
After pulling the card out of the reader and inserting it again, two PIN inputs a required again for the first signature.
Problem Description
I have a brand new D-Trust Card 3.1 that is supposed to be usable for PDF signing (which is the ultimate goal)
I have access to the following two readers:
the card is currently inserted into the cyberJack (also brand new) and I also have the Gemalto, which I have been using for almost two years now with opensc
The Card-PIN and the Signature-PIN are initialized and I initially had set them both to a length 6 digits (card requires 6 - 12) digits. Initial setting was done using the "D-Trust card assistant tool", which is a windows tool provided by the card issuer.
Changing pins is possible using both the PIN pad on cyberjack and also using Gemalto and "input fields" on app level.
now, Open SC refused the pins on both readers - even if the pin was entered on the Pin pad of the cyberJack, the display of the reader said the PIN is incorrect.
Here I was using the cyberJack and a 6-digit PIN, showing the second and third try:
(same for slot 1, which uses Signature-PIN, same for Gemalto and for cyberJack) The irritating thing is that the cyberJack showed "PIN inkorrekt" in the device display, though I had changed the PIN using the device display => I definitely entered the correct PIN.
After I changed the pin to a full allowed length of 12 digits, this started working - well, almost.
I think, the above is one issue, the below is a different one, I'll put them both in one ticket, please let me know if we should split that in two separate ones.
Now, if I run the following commands, I am asked for the PIN twice in each of the runs.
Same result with cyberJack and with Gemalto readers. The only difference: Pin is entered for cyberJack on Pin Pad of the device, with Gemalto on the command prompt. When I enter the PIN in the Pin Pad of cyberJack, the display of the device confirms "PIN korrekt" each time. so PIN is correct... BUT:
As to my ultimate goal, if I try to sign a PDF using Acrobat reader, I get same error: 0x101 when trying to sign the PDF.
Another thing I just noticed is when I use the card in the Gemalto (and PIN is entered on the terminal prompt), I can see it asks for the context specific pin hwn asking for the pin second time:
PS: opensc version:
Steps to reproduce
see above
Logs
let me know if anything form the output and which OPENSC_DEBUG level is needed to understand, what is wrong