-
Notifications
You must be signed in to change notification settings - Fork 733
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support D-Trust Card 5.1 (Std. RSA CardOS6.0) with CAN #3131
Comments
Just to check whether PACE of the card is compatible with OpenSC's implementation, could you please try |
|
Thanks, so mechanisms are in place, but we need to correctly look at the metadata. I'll try to get some developer information from D-Trust. Maybe this is also interesting for @hamarituc |
Today in the morning I received my account to access the developer docs. I will check it tomorrow and contact you if there are any questions, so you don't need to waste time. |
According to the developer docs a PACE channel is necessary for:
Whilst it is evident to protect the communication via PACE for contactless usage, it is even required when using the contact based interface. This makes the driver implementation a bit complicated, because up to two separate PINs have to be queried: the CAN at least for the first time and then signature PIN every time in case of a standard card. @frankmorgner: You developed the PACE implementation and the ePA-driver. Is this behavior implementable in the PKCS#11 workflow at all? If I understand the ePA driver correctly, the CAN is statically configured in the configuration file. This would not be an option in my use case so it needs a way to query the CAN through regular usage from the end user. Is the ePA driver a good candidate to build upon or do we need a different approach? |
That's not exactly true. DF.Certs, which holds all certificates is ALWAYS readable as well as, for example, EF.GDO with the serial number. So there should be enough meta data available to identify the card.
Not exactly, no.
Correct.
First, you will always need to request the CAN via a propriatery PIN dialog, because of the PKCS#11 limitations. Read Second, once you collected the CAN, you may want to cache this on disk to avoid prompting the user too often (remember that the user always needs to enter PIN.AUT or PIN.QES as well!). (Only) On Windows, you could use |
@frankmorgner @hamarituc if you need some help with debugging/testing I am happy to assist you with my signature card |
Which operating system do you use? I can only test Linux and Windows. Finding a Mac user would be helpful. But to be honest, it seems to be a lot work to be done because of the PACE encryption required by these cards. I cannot make an estimate when I am able to deliver a first test candidate. |
My primary operating system is macOS (x86 and Apple Silicon/ARM architecture). But I have windows and linux machines too |
Establishing PACE channels for a hard coded CAN is implemented here (according to the specification) if you want to try: |
@frankmorgner Thank for the sample code. I was able to get PACE authentication working in @janknieling If you already initialized your card with the D-Trust provided Card Assistant I would be happy if you could provide me the output of |
@hamarituc yes my card is already initialized.
The CI/CD pipeline has the same problem (https://github.com/OpenSC/OpenSC/actions/runs/9227516607/job/25389623718#step:4:12322) |
dtrust-tool needs to be compiled with OpenPACE... Implementing the sample, I also noticed some other problems:
|
@frankmorgner is there a documentation for compiling with openpace on macOS available? |
|
Unfortunately ./MacOSX/build drops the same error. |
src/tools/Makefile.am needs to add |
...
I will add it. Strictly speaking OpenPACE is only necessary for D-Trust Card 5, but not for version 4. So at least the D-Trust Card 4 should should still be supported without enabling OpenPACE. Is adding
unconditionally OK? The variables should be empty i think, when OpenPACE is disabled, weren't they? In the D-Trust driver the parts which are specific to OpenPACE should not be compiled when OpenPACE support is disabled. Is #ifdef ENABLE_OPENPACE
#endif sufficient or does it need to be? #if defined(ENABLE_SM) && defined(ENABLE_OPENPACE)
#endif |
just add cflags and libs. as long as you don't use any openpace specific header files or function calls, sm/eac.h will handle non-availability of openpace. |
@hamarituc here is the output of
|
@hamarituc just write me if you need further debugging assistance |
Problem Description
The D-Trust Signature Card 5.1 Std. (EIDAS QES signature certificate for signing and encryption certificate on card) with CardOS6.0 is currently not supported by OpenSC.
To connect to the card/use the card a CAN number is needed (the CAN is printed on the card).
It seems that OpenSC hasn't the possibility to provide/submit a CAN.
Proposed Resolution
It would be great if this card type is supported by OpenSC. This is merely a feature request than a bug report.
Steps to reproduce
Debug log:
log.txt
Logs
Debug log:
cardostool.txt
Debug log:
opensctool--name.txt
Debug log:
pkcs11-tool.txt
Debug log:
pkcs15-tool.txt
Debug log:
dtrust-tool.txt
The text was updated successfully, but these errors were encountered: