Open the-docta opened 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 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
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.
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.
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?
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/12
the 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?
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"
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 CardOS
Does 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 PACE
You 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.
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.
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: called
both 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 0a
also 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)
"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 : 3f001fff
shows 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 1
the 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.
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"
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.
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 instance
will install full XCode now. but maybe the above couple of lines are worth considering adding as requirements to the wiki page
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.
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 like91 == 0x80 | 0x11
should 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.
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 : 12
here 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 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)
will have a look at usb tracing tonight. from a quick google search, it is apparently easier to usb-trace on windows.
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
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.
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.
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.
What's the status of this topic, is there anything to do?
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
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"?
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.
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.
may be fixed with https://github.com/OpenSC/OpenSC/pull/2943
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.
@hamarituc , the PIN-pad problem has also been reported for D-Trust Card 4.1, could you have a look at this?
@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.
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