D-Trust card 3.1 + Reiner SCT cyberJack Komfort + OpenSC + Mac => Pin only works if it has max length?? + Asking for PIN twice #2244
Comments
|
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 |
|
Can you try with |
|
attached two logs at debug level 3 - the difference being 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 So
How do you tell the pin pad reader which PIN id to use? |
I'm not sure what "pin id" is... I first call the card has a "card pin" and a "signature pin", both are currently set to the same value, while testing.
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. 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. 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
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 about the driver: does this help to identify the used card driver? |
|
Does anyone with a CardOS card have two PINs for the card? @the-docta The reasons I asked about PACE, is because your logs in the first 24 lines show: You say it works with the Gemalto reader and but show Context Specific. This indicates the PKCS11 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. I think one problem is with the status of This is related to https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L215 |
|
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) the only line in debugoutput with "consent" both PINs and both PUKs are verifiable correctly: also changing pins works as expected. Attached a log with debug level 9 of the following command: basically, this sums up to: so looks like the pin is verified just fine, but the security context is still not for satisfaction. |
|
"Please enter context specific PIN" is from https://github.com/OpenSC/OpenSC/blob/master/src/tools/pkcs11-tool.c#L2073-L2074 This may come in play when using a pin pad reader: in line 1447 in debug log: But I think the problem is all the verify examples the verify is always for 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. OpenSC pkcs11 assigns two slots, but based on your test, even with slot=1 it fails. I found https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-cardos.c#L1486-L1493 Based on the output of shows up in debug log: the APDUs sent for a verify are: I suspect the ADPU P2 should be: (80 rather then 81) 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" Try combinations of the P2 parameter with each key PIN having a different value . Note extra 00 on two of the above, as this is Le=256 as these expect a response other then just status 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 |
|
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: #2244 (comment) , 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 I would also be interested in seeing the output of As part of a group effort of developers and users with CardOS cards, commit db41cd9 part of #1987 that fixed #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 |
|
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 will install full XCode now. but maybe the above couple of lines are worth considering adding as requirements to the wiki page |
this is verified - with padding 0xFF, shorter passwords work. |
yes, the Card-PIN uses I have set different values for Card-PIN and Signature PIN, both versions return successfully from verification (here with debug=0) if I insert |
|
OK. The failure of The presence of the One trick you can use is to set in opensc.conf a card_atr stanza and set 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 |
|
setting type in the config file didnt seem to make a difference. But I manually went through all the variations of here the results, always producing 9000 after providing pin, and 6982 after |
|
so the problem appears to be the set security env. Does the card work on Windows using vendor drivers? Also since this card may not be a SC_CARD_TYPE_CARDOS_V5_0, but more like a SC_CARD_TYPE_CARDOS_M4, |
|
The card works with SecSigner for Mac - if I only knew how to create a USB trace.
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. I don't think the problem is MacOS specific, so if you can not get a PCSC or USB trace try a different system. 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 |
|
If you are going to try it on Windows, Google for: Windows PC/SC trace |
|
I should have checked this thread before I started usb sniffing... anyway, got a working trace: I also found that the command between the login and the signing command, corresponds to 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:
|
|
Interesting, look at: maybe your card is more like a SC_CARD_TYPE_CARDOS_CIE_V1? A Within git repro:
Look at |
|
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, CC EAL Report may be found over here (if helpful). There is
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) 3F00 1FFE C101 + C10D (intermediate) + C10E (root) Signing CMS SignedData hash requires
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 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(): 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 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: Signing this way with another MS CAPI driver works. 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 #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? |
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. |
and others
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
The text was updated successfully, but these errors were encountered: