Support D-Trust Card 5.1 (Std. RSA CardOS6.0) with CAN

[janknieling]

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

$ echo "Sign me" | pkcs11-tool --slot 1 -a Signaturzertifikat -s -m RSA-PKCS -p XXXXXXXX

error: PKCS11 function C_GetTokenInfo failed: rv = CKR_TOKEN_NOT_RECOGNIZED (0xe1)
Aborting.

Debug log:
log.txt

Logs

➜  ~ opensc-tool --version
OpenSC-<version not available>, rev: 0a4b772, commit-time: 2024-04-04 16:21:38 +0200
P:94404; T:0x140704682469312 22:40:04.528 [opensc-tool] ctx.c:747:process_config_file: scconf_parse failed: Line 2: not expecting 'default'

P:94404; T:0x140704682469312 22:40:04.529 [opensc-tool] ctx.c:981:sc_context_create: ===================================
P:94404; T:0x140704682469312 22:40:04.529 [opensc-tool] ctx.c:982:sc_context_create: OpenSC version: 0.25.1
P:94404; T:0x140704682469312 22:40:04.529 [opensc-tool] ctx.c:983:sc_context_create: Configured for opensc-tool (/Library/OpenSC/bin/opensc-tool)
P:94404; T:0x140704682469312 22:40:04.530 [opensc-tool] ctx.c:858:sc_openssl3_init: Failed to load OpenSSL Legacy provider
P:94404; T:0x140704682469312 22:40:04.530 [opensc-tool] reader-pcsc.c:897:pcsc_init: PC/SC options: connect_exclusive=0 disconnect_action=0 transaction_end_action=0 reconnect_action=0 enable_pinpad=1 enable_pace=1
P:94404; T:0x140704682469312 22:40:04.546 [opensc-tool] reader-pcsc.c:1397:pcsc_detect_readers: called
P:94404; T:0x140704682469312 22:40:04.546 [opensc-tool] reader-pcsc.c:1410:pcsc_detect_readers: Probing PC/SC readers
P:94404; T:0x140704682469312 22:40:04.546 [opensc-tool] reader-pcsc.c:1463:pcsc_detect_readers: Establish PC/SC context
P:94404; T:0x140704682469312 22:40:04.594 [opensc-tool] reader-pcsc.c:1346:pcsc_add_reader: Adding new PC/SC reader 'REINER SCT cyberJack one'
P:94404; T:0x140704682469312 22:40:04.594 [opensc-tool] reader-pcsc.c:361:refresh_attributes: REINER SCT cyberJack one check
P:94404; T:0x140704682469312 22:40:04.596 [opensc-tool] reader-pcsc.c:407:refresh_attributes: current  state: 0x00000022
P:94404; T:0x140704682469312 22:40:04.596 [opensc-tool] reader-pcsc.c:408:refresh_attributes: previous state: 0x00000000
P:94404; T:0x140704682469312 22:40:04.596 [opensc-tool] reader-pcsc.c:463:refresh_attributes: card present, changed
P:94404; T:0x140704682469312 22:40:04.804 [opensc-tool] reader-pcsc.c:1564:pcsc_detect_readers: REINER SCT cyberJack one:SCardConnect(SHARED): 0x00000000
P:94404; T:0x140704682469312 22:40:04.804 [opensc-tool] reader-pcsc.c:1145:detect_reader_features: called
P:94404; T:0x140704682469312 22:40:04.805 [opensc-tool] reader-pcsc.c:1147:detect_reader_features: Requesting reader features ... 
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1165:detect_reader_features: Reader feature 06 found
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1165:detect_reader_features: Reader feature 07 found
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1165:detect_reader_features: Reader feature 08 found
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1185:detect_reader_features: Reader feature 08 is not supported
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1165:detect_reader_features: Reader feature 09 found
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1185:detect_reader_features: Reader feature 09 is not supported
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1193:detect_reader_features: Reader supports pinpad PIN verification
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1203:detect_reader_features: Reader supports pinpad PIN modification
P:94404; T:0x140704682469312 22:40:04.806 [opensc-tool] reader-pcsc.c:1125:part10_get_vendor_product: id_vendor=ffffffff id_product=ffffffff
P:94404; T:0x140704682469312 22:40:04.807 [opensc-tool] reader-pcsc.c:1293:detect_reader_features: Reader supports sending 1014 bytes of data
P:94404; T:0x140704682469312 22:40:04.807 [opensc-tool] reader-pcsc.c:1306:detect_reader_features: Reader supports receiving 1014 bytes of data
P:94404; T:0x140704682469312 22:40:04.809 [opensc-tool] reader-pcsc.c:1579:pcsc_detect_readers: returning with: 0 (Success)
P:94404; T:0x140704682469312 22:40:04.809 [opensc-tool] ctx.c:1066:sc_release_context: called
P:94404; T:0x140704682469312 22:40:04.809 [opensc-tool] reader-pcsc.c:978:pcsc_finish: called

$ cardos-tool -i
Using reader with a card: REINER SCT cyberJack one
Card type FFFFFFFF: not a CardOS card

Debug log:
cardostool.txt

$ opensc-tool --name
Using reader with a card: REINER SCT cyberJack one
Unsupported card

Debug log:
opensctool--name.txt

$ pkcs11-tool -T 
Available slots:
No slots.

Debug log:
pkcs11-tool.txt

$ pkcs15-tool -D   
Using reader with a card: REINER SCT cyberJack one
Failed to connect to card: Card is invalid or cannot be handled

Debug log:
pkcs15-tool.txt

$ dtrust-tool 
Using reader with a card: REINER SCT cyberJack one
Failed to connect to card: Security status not satisfied

Debug log:
dtrust-tool.txt

$ opensc-tool -a 
Using reader with a card: REINER SCT cyberJack one
3b:d2:18:00:81:31:fe:58:cb:01:16

[frankmorgner]

Just to check whether PACE of the card is compatible with OpenSC's implementation, could you please try npa-tool --can=123456?

[janknieling]

➜  ~ npa-tool --can=XXXXXX -v
Using reader with a card: REINER SCT cyberJack one
Connecting to card in reader REINER SCT cyberJack one...
Using card driver Default driver for unknown cards.
Established PACE channel with CAN.

[frankmorgner]

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

[hamarituc]

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.

[hamarituc]

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

According to the developer docs a PACE channel is necessary for:

• PIN operations
• private key operations
• even for querying the vendor and product information of the card

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?

[frankmorgner]

even for querying the vendor and product information of the card

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.

Is this behavior implementable in the PKCS#11 workflow at all?

Not exactly, no.

If I understand the ePA driver correctly, the CAN is statically configured in the configuration file.

Correct.

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?

First, you will always need to request the CAN via a propriatery PIN dialog, because of the PKCS#11 limitations. Read src/libopensc/card-dnie.c and search for ENABLE_DNIE_UI - there you will find PIN dialogs for Windows, macOS and Linux. By default, this code is not enabled so please use with care. If you have a reader capable of doing PACE when inputting the CAN on the pin pad, then you may even do so without spawning a dedicated window and just use sc_notify().

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 RegSetValueEx() in the user context (see src/minidriver/minidriver.c for example). The other option which works on any OS, is to use sc_pkcs15_cache_file() to cache the CAN on disk using a virtual file path. This virtual file will be associated with the serial number of your card and should work even with using multiple cards (with different CANs) for a single user.

[janknieling]

@frankmorgner @hamarituc if you need some help with debugging/testing I am happy to assist you with my signature card

[hamarituc]

@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.

[janknieling]

My primary operating system is macOS (x86 and Apple Silicon/ARM architecture). But I have windows and linux machines too

[frankmorgner]

Establishing PACE channels for a hard coded CAN is implemented here (according to the specification) if you want to try:
frankmorgner@80349e2