Extend CI tests for OpenPGP and PIV with p11test

[xhanulik]

This PR expands the functionality of test-openpgp.sh and test-piv.sh to include the execution of p11test. The reference JSON files are in the src/tests/p11test/ directory.

[Jakuje]

Looking at the CI runs, there are some suspicious parts (probably not related to these changes, but worth investigating):

• Please, run the p11test in verbose mode (with -v). It prints more information what is it doing and it is easier to debug.
• In test-piv-sm run, I can see that even though you have EC keys, there are no EC mechanisms listed so they are not tested (neither signature nor derive) (not sure now how EC support is determined in the driver now)
• In test-openpgp, the old openpgp applet can not do ECC so the OpenPGP looks good

[dengert]

In test-piv-sm run, I can see that even though you have EC keys, there are no EC mechanisms listed so they are not tested (neither signature nor derive) (not sure now how EC support is determined in the driver now)

PIV driver determines key type and parameters from public key in the matching certificate. Now that we are using the cached certificate files, this could mean that the cached certificates do not match the certificates on the card or no certificates were written to the card.

See NIST sp800-73-4 "Part 1" "C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication"

The cached certificates files feature depends on the serial number from the token. Since NIST does not define a serial, the CHUID object is used to derive a unique serial. If this is not present then a zero serial number is returned. So in the test environment where multiple tests run as the same user, if one test cached a certificate read from the token, the next test might use this this cached certificate which is not the same as the one on the token.

Possible solution is to turn off cached certificates or delete ~/.cache/opensc before some tests.

Other possibility is the token is emulating some Yubico or other device which does not support EC.
grep for CI_NO_EC in card-piv.c

[dengert]

Is problem with test-piv:

https://github.com/OpenSC/OpenSC/actions/runs/6272264013/job/17033913611?pr=2872#step:5:10455

Caused by not defining any tests in piv_ref.json at lines 299-302:
"8a36b84#diff-58ecb3a10c647c4c82b16ff77be8e820f0fa0f823e5c431d810e83a5c1086848R299-R302"

[xhanulik]

I added running p11test in verbose mode and used EC also for key on 9D so the derive test should pass on it now. However, I haven't yet figured out what is causing no EC mechanisms to list.

Is problem with test-piv:

https://github.com/OpenSC/OpenSC/actions/runs/6272264013/job/17033913611?pr=2872#step:5:10455

Caused by not defining any tests in piv_ref.json at lines 299-302: "8a36b84#diff-58ecb3a10c647c4c82b16ff77be8e820f0fa0f823e5c431d810e83a5c1086848R299-R302"

I'm not sure what you mean - the JSON file is only a reference for test outputs, so it does not define any tests.

[xhanulik]

EC mechanisms on PIV fixed by enforcing different card type (without CI_NO_EC) via configuration file.

[dengert]

If the virtual card has an ATR, it could be added to card-piv.c so it does not set the CI_NO_EC. That should only be set for older Yubico devices.

[Jakuje]

If the virtual card has an ATR, it could be added to card-piv.c so it does not set the CI_NO_EC. That should only be set for older Yubico devices.

The ATR of PivApplet is very generic one and part of configuration (its already in the card-piv): https://github.com/arekinath/PivApplet/blob/master/test/jcardsim.cfg

I suggested to use the configuration to avoid need to invent a specific ATR for this test applet, but avoid mangling configuration of existing generic ATRs in the driver.

[dengert]

nit: I would put here a comment why we do this exercise (need to force avoid compat/bugs flags enforced in the PIV driver for this very generic ATR).

Or just write it as a comment to the conf file

com.licel.jcardsim.card.ATR=3B80800101

https://smartcard-atr.apdu.fr/parse?ATR=3B+80+80+01+01

Looks like generic contactless card with no historic bytes:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L5443-L5450
Since NFC does not define ATRs, PCSC make up ATRs like this and adds historic bytes if possible.

Best as I can tell, 3B+80+80+01 is an intermediate step in determine a card's ATR the would never end up in the actual ATR. Thus it was used by PCSC to make up an ATR for a contactless device.

NIST 800-73-4 Part 1, "Table 2. Data Model Containers" (and other 800-73 versions) basically say no PIN over contactless without SM and card will enforce it. Note X.509 Certificate for Card Authentication and 9E key do not require a PIN, so can be used over contactless.

Some Yubikey devices do not follow the NIST standard and will allow a PIN and crypto operations over contactless. card-piv will allow this for Yubikey devices, by checking historic bytes and reading the yubico_version number.
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L577

EC mechanisms on PIV fixed by enforcing different card type (without CI_NO_EC) via configuration file.
I don't see where CI_NO_EC or CI_NO_EC384 was being set? Do you have a debug log showing it set?

[dengert]

#2872 .github/test-piv.sh says:

# enforce the setting of different PIV type to support EC mechanisms
# which are disabled for the generic ATR mapping to older Yubico devices

Do you have a opensc-debug log level 3 that shows this is the case?

If it is true, it needs to be fixed in the driver and not just for for test-piv.sh

[dengert]

Looking closer,

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L533-L534
defines another card which uses the same generic "contactless" ATR
This was added fa2eab8

https://github.com/arekinath/PivApplet/tree/master#installing lists the SELECT_AID command and response:

== APDU
0000:  00 A4 04 00  09 A0 00 00
0008:  03 08 00 00  10 00 00
== Reply APDU
0000:  61 3D 4F 0B  A0 00 00 03
0008:  08 00 00 10  00 01 00 79
0010:  0D 4F 0B A0  00 00 03 08
0018:  00 00 10 00  01 00 50 09
0020:  50 69 76 41  70 70 6C 65
0028:  74 AC 14 80  01 03 80 01
0030:  06 80 01 07  80 01 11 80
0038:  01 F0 80 01  F1 06 00 90
0040:  00

The 50 09 50 69 76 41 70 70 6C 65 74 == Application tag len 9 "PivApplet"
Other card vendors also add the application tag

This could be tested for in card-piv.c. I will submit a PR. So this PR #2872 is good for now.

[Jakuje]

@dengert I read your last comment as we are good to go and we can resolve the generic ATR issue async in separate PR or after the release. I see you have some changes in https://github.com/dengert/OpenSC/compare/generic-atr but they look incomplete. Do you plan to submit them as a PR for this release or can this wait?

[dengert]

Yes https://github.com/dengert/OpenSC/compare/generic-atr it is incomplete. I have a note into PIVKey but no response. I also submitted arekinath/PivApplet#74 but no comments yet.
The issue is how to tell them apart or just assume they do not have any card_issues.

I have a number of PIVkey cards but not the generic ATR card.

Your #2872 is good for now.

You read it correctly:
"I read your last comment as we are good to go and we can resolve the generic ATR issue async in separate PR or after the release."

[Jakuje]

Thank you! If you think that something from the above discussion regarding the ATRs requires follow-up issue, please open one so it will not get lost.