Hi
5 Minutes ago on a personally "historical 30th november 2023" I was able to digitally sign a pdf document using Adobe Acrobat on a macBookPro for the first time after I cloned the d-trust-fork, made a build and did a local install.
Seems like christmas for me today because I was trying to digitally sign my pdf's (EU certified!) on a mac since many years now and until today I always had to start a windows system with a "nexus client desktop" middleware (which I was not able to purchase somewhere for a mac) for this "just sign a pdf on my mac" use case.

Thank you, Thank you, Thank you very much @hamarituc - good job ! All thumbs up!

The code looks very good, thank you.

Please try to reuse the code formatting of the existing code base, see #1641 and #2017 for hints.

I applied clang-format with the style file of #2017. But had to tweak the result a little bit, as the indent of the static structures didn't match any other card driver.

@hamarituc can you rebase the PR on the current master. I think this is also ready for the release, but I would like to re-trigger the recent CI updates to avoid a need to fix it in the master afterward.

Hi,
I tried the code (installed it via ./bootstrap && ./configure --prefix=/usr/local --sysconfdir=/etc/opensc && make && sudo make install) and unfortunately, it does not work for me.

Before recent rebase (today in the morning) I got an error PKCS11 function C_SignFinal failed: rv = CKR_DATA_INVALID (0x20) when running echo "Sign me" | pkcs11-tool --slot 1 -a Signaturzertifikat -s -m RSA-PKCS -p xxx. The same happened when omitting the pin (-p xxx) on commandline and entering the pin on the pinpad of the smartcard reader.

After rebase there is now a memory access error when using pinpad, still same error as before when setting pin on commandline.

Reader and card info:

$ opensc-tool -n
Using reader with a card: Cherry GmbH SmartTerminal ST-2xxx [CCID Interface] (55952134200215) 00 00
D-TRUST Card 4.1 Std. RSA 2ca

Operating system is Linux Mint.

Please let me know if I should provide any more details.

Hi, I tried the code (installed it via ./bootstrap && ./configure --prefix=/usr/local --sysconfdir=/etc/opensc && make && sudo make install) and unfortunately, it does not work for me.

Before recent rebase (today in the morning) I got an error PKCS11 function C_SignFinal failed: rv = CKR_DATA_INVALID (0x20) when running echo "Sign me" | pkcs11-tool --slot 1 -a Signaturzertifikat -s -m RSA-PKCS -p xxx. The same happened when omitting the pin (-p xxx) on commandline and entering the pin on the pinpad of the smartcard reader.

Can you please retry it with a smart card reader without a pin pad please. I experience a problem with my Cherry Secure Board as well which implements a pin pad reader. I thought it was a problem with the keyboard since the driver worked well for all other readers I tested.

After rebase there is now a memory access error when using pinpad, still same error as before when setting pin on commandline.

Reader and card info:

$ opensc-tool -n
Using reader with a card: Cherry GmbH SmartTerminal ST-2xxx [CCID Interface] (55952134200215) 00 00
D-TRUST Card 4.1 Std. RSA 2ca

Interesting, a Cherry reader as well. We should first rule out it depends on the hardware.

Before recent rebase (today in the morning) I got an error PKCS11 function C_SignFinal failed: rv = CKR_DATA_INVALID (0x20) when running echo "Sign me" | pkcs11-tool --slot 1 -a Signaturzertifikat -s -m RSA-PKCS -p xxx. The same happened when omitting the pin (-p xxx) on commandline and entering the pin on the pinpad of the smartcard reader.

Please try with one of these mechanisms

• pkcs11-tool --slot 1 -a Signaturzertifikat -s -m SHA256-RSA-PKCS -p xxx
• pkcs11-tool --slot 1 -a Signaturzertifikat -s -m SHA384-RSA-PKCS -p xxx
• pkcs11-tool --slot 1 -a Signaturzertifikat -s -m SHA512-RSA-PKCS -p xxx

instead of RSA-PKCS. Only these Hashes are specified and implemented. Only these hashes are reported to libopensc, but for some reasong RSA-PKCS is offered for signature.

All remaining CI failures seem not to be related to the patch and also failing in master (https://github.com/OpenSC/OpenSC/actions/runs/7791817978/job/21248656682?pr=2943 and https://github.com/OpenSC/OpenSC/actions/runs/7791817970/job/21248654785?pr=2943) or code style issues in unchanged portions of the code (https://github.com/OpenSC/OpenSC/actions/runs/7791817987/job/21248654554?pr=2943).

From my point of view, all issues resulting from the rebase are fixed.

Thank you for the hints about hashes. Signing of piped string or file works fine when using the Hashes SHA256-RSA-PKCS, SHA384-RSA-PKCS and SHA512-RSA-PKCS when specifying the pin via -p xxx.

When omitting the -p and trying pinpad of the smartcard reader, there is still the memory access error.

Unfortunately, I do not have another card reader besides the cherry with pinpad. But I would be happy to buy one if you have a suggestion that you do not already own yourself.

Thank you for the hints about hashes. Signing of piped string or file works fine when using the Hashes SHA256-RSA-PKCS, SHA384-RSA-PKCS and SHA512-RSA-PKCS when specifying the pin via -p xxx.

When omitting the -p and trying pinpad of the smartcard reader, there is still the memory access error.

The D-Trust driver doesn't handle the PIN entry logic so it's very likely you hit some issue not related to this patch. To get more evidence I would like you to enable the debugging output and paste the debug trace so we have an idea where the Segfault comes from.

echo "Sign me" | OPENSC_DEBUG=9 pkcs11-tool --slot 1 -a Signaturzertifikat -s -m SHA256-RSA-PKCS

But I am unsure whether we should handle this issue in the Pull Request thread or if it is more appropriate to open a separate issue.

Unfortunately, I do not have another card reader besides the cherry with pinpad. But I would be happy to buy one if you have a suggestion that you do not already own yourself.

I have tested with:

• Alcor Micro AU9540
• SCM Microsystems Inc. SCR 335
• Gemalto IDBridge CT30
• CHERRY Secure Board 1.0 (but the pinpad entry didn't work)

I tested with proper hashes on master branch and it showed the same memory access error as on this pull request when omitting the pin on commandline. When specifying the pin on commandline it failed expectedly of course because that's what this pull request is about to fix.

Therefore, I will open a new issue regarding the memory problem. And I will order another reader to check.

Thanks for your support and sorry for the confusion.

I merged #3023 so if you rebase this on top of master, memory issues should be gone and you could verify this works also with your reader.

to whom it concerns....
on my macOS (14.3.1) even after building OpenSC 0.25.0 with D-Trust support from the latest master (commit eb984fc) I found the following issue using Adobe Acrobat (23.8.20470.0). Signing a PDF with the D-Trust Card 4.1 Std. works fine ONCE. Another try to sign another PDF always fails with the error shown in the attached picture (which arises before I have to enter the pin). After restarting Adobe Acrobat signing again works exactly once.

Note: I don't want to say that this is a NEW issue of the merge because since start of d-trust driver implementation I was not able to sign more than one pdf without restarting acrobat. Just my personal fault that I reported this finding not before. Sorry for that.

Attaching the /usr/local/lib/opensc-pkcs11.so to Acrobat ("PKCS#11-Module and Token") shows the following information ...

ID des Modulherstellers: OpenSC Project
Modulbeschreibung: OpenSC smartcard framework
Bibliotheksversion: 0.24
Cryptoki-Version: 2.20
Bibliothekspfad: /usr/local/lib/opensc-pkcs11.so

By the way: Hardware is a Reiner SCT cyberJack Komfort.

If this info is interesting and I could help analyzing the issue please let me know. As a regular user of OpenSC I think I am not able to provide more "technical" information without support from one of the professionals here.

to whom it concerns.... on my macOS (14.3.1) even after building OpenSC 0.25.0 with D-Trust support from the latest master (commit eb984fc) I found the following issue using Adobe Acrobat (23.8.20470.0). Signing a PDF with the D-Trust Card 4.1 Std. works fine ONCE. Another try to sign another PDF always fails with the error shown in the attached picture (which arises before I have to enter the pin). After restarting Adobe Acrobat signing again works exactly once.

Note: I don't want to say that this is a NEW issue of the merge because since start of d-trust driver implementation I was not able to sign more than one pdf without restarting acrobat. Just my personal fault that I reported this finding not before. Sorry for that.

Attaching the /usr/local/lib/opensc-pkcs11.so to Acrobat ("PKCS#11-Module and Token") shows the following information ...

ID des Modulherstellers: OpenSC Project Modulbeschreibung: OpenSC smartcard framework Bibliotheksversion: 0.24 Cryptoki-Version: 2.20 Bibliothekspfad: /usr/local/lib/opensc-pkcs11.so

By the way: Hardware is a Reiner SCT cyberJack Komfort.

If this info is interesting and I could help analyzing the issue please let me know. As a regular user of OpenSC I think I am not able to provide more "technical" information without support from one of the professionals here.

I think you should open a separate issue on this bug. A colleague of mine experienced a similar issue, but with the old version. We couldn't it reproduce with the new version. I would like to ask you to try the following when signing two documents.

1. Close Adobe between the signing operations, but keep the card inserted into the reader
2. Close Adobe between the signing operations and remove the card from the reader and reinsert it
3. Keep Adobe open between the signing operations, but remove the card from the reader an reinsert it
4. Keep Adobe open between the signing operations and keep the card inserted as well

Please tell in which cases you experience the error.

I think it has to do with the PIN caching. The card requires a PIN entry for each single signing operation. But OpenSC is able to cache that PIN an just transfers it to the card, when needed without querying the card holder again.

Please check the card's PKCS#15 profile (pkcs15-tool -D), this proberty should be reflected by setting the user_consent flag in the private key object.

FYI: 0x101 means CKR_USER_NOT_LOGGED_IN

Ok, issue created - see #3030 (comment)