It looks like the only use of this is to generate an RSA key and retrieve the public key.
Can you give an example of how you call this?

Does not look like you are using piv-tool. piv-tool will only generate key for 9A, 9C, 9D and 9E.

Why did you have to change the size of the exponent? piv-tool and piv cards assume the card uses a default exponent as defined by the card and return it and gets passed as a long in the keydata. Your changed still left "if (tag != NULL && taglen <= 4) {" which limits the size returned to 4 bytes.

Can you get a debug log and show the APDU sent and its response?

You define both SC_CARD_TYPE_PIV_II_SWISSBIT and SC_CARD_TYPE_PIV_II_SWISSBIT_DUAL_CAC but treat them the same in all cases. The "_DUAL_CAC" was meant to be used for cards that have both a PIV and CAC applet on the card and the PIV part is non standard. Can this card also have a CAC applet on the card?
If not please only use SC_CARD_TYPE_PIV_II_SWISSBIT.

Please change PIV_OBJ_PRIV something like PIV_OBJ_PRIV_SWISSBIT_5015 for readability.

In:
https://github.com/OpenSC/OpenSC/pull/2671/files#diff-14d802e467876e00ece49c8d6621ec74eaf7d02384642ac0694de83397d9bbfcL3452-R3484
Is this really needed. See line: "piv-tool can still do this, just don't tell PKCS#11"

If you are only changing the driver and piv-tool to generate this one key and don't expect the driver, pkcs15, pkcs11 the other option to use the piv-tool to authenticate to the card, then use the -s option to send the generate key APDU and retrieve the response.

Are you using https://fidoalliance.org/specs/fido-uaf-v1.2-ps-20201020/fido-uaf-apdu-v1.2-ps-20201020.html
in some code, to do the authentication? So are your changes to the piv-tool and card-piv.c only used to create an RSA key on the card?

When you create the key on the card, do you need to authenticate to the card using the PIV 9B key or some other way for example user pin?

I am trying to understand why changes are needed in the PIV code. PIV applet is selected using SELECT command:
0x00 0xA4 0x04 0x0C 0x09 0xA0 00 00 03 08 00 00 10 00

FIDO spec above use 4.2.3 APDU Command "SELECT" command:
0x00 0xA4 0x04 0x0C 0x08 0xA0 00 00 06 47 AF 00 01

In other words how do you use the key you are creating on the PIV card, without using PIV commands?

Do you work for Swissbit?
What is missing from the software provided by Swissbit that requires modifications to OpenSC?

How does Swissbit code create the FODO RSA key you are trying to create?

Yubico provides tokens with FIDO and PIV, and they don't need any changes in PIV code to use FIDO . Do you really need to changes OpenSC ?

The more I have read today about FIDO, the less I like this modification to OpenSC.

PIV and FIDO are separate applets. PIV can do authentication, sign and encryption using 3 keys with certificates. So the same key and certificate are used for all sites.

FIDO has a different key and public key for each site stored on the token, so the user can not be tracked across sites.
See https://fidoalliance.org/how-fido-works/

Windows has built-in FIDO routines that do not depend on PIV. Ubuntu has the fido-tools package that appears to do what you want. Redhat has many docs on using FIDO. Token vendors such as Yubikey and NitroKey have similar tools. There are multiple site showing how to use FIDO with or without tokens.

https://github.com/topics/fido2 shows there are 198 repositories dealing with FIDO, including: Google, Nitrokey, Solkeys and
Yubikey.

The more I have read today about FIDO, the less I like this modification to OpenSC.

If I understand correctly, then the token in question works similar to the Yubikey. The changes suggested here are related to the PIV applet only, and don't have anything to do with the FIDO authentcation.

Yes, @frankmorgner is right. Like the Yubikey, the Swissbit iShield FIDO2 Authenticator comes also with the PIV applet installed.
All changes suggested here are connected to the PIV but not the FIDO applet on the token.

Yubico provides their own minidriver, the Swissbit token, however, can be managed via the native Windows user interface using the OpenSC minidriver and a custom PIV module that is integrated via the OpenSC configuration. For certificate enrollment via the minidriver, we also want to enable key generation using PKCS#11 for our token.

The suggested changes are required to install the OpenSC minidriver for the iShield FIDO2 Authenticator and to enable key generation using an external module instead of the built-in PIV module and PKCS#11.

Please drop the use of SC_CARD_TYPE_PIV_II_DUAL_CAC as this deals with official PIV and CAC cards.

I'm a bit puzzled... where do you draw the line between a Yubikey and the swissbit token? Is it that you don't want to add proprietary functionality to the PIV driver (i.e. something not specified by NIST)?

I'm a bit puzzled... where do you draw the line between a Yubikey and the swissbit token?

Sorry, SC_CARD_TYPE_PIV_II_DUAL_CAC should be SC_CARD_TYPE_PIV_II_SWISSBIT_DUAL_CAC.
There was no mention of the SwissBit having a CAC applet. It looks like it was copied, but not really used.
When a gov issued PIV with CAC is issued, there are some fields that indicate it is a DUAL card and does not follow strict PIC specs.

But changes like { PIV_OBJ_PRIV, "Priv key ", "", 0, "", "\x50\x15", 0} may effect other PIV card and could be handled in a better way, and only work when the card is identified as SwissBit.

When a key is generated is the only time the public key is returned. The code to generate the key is in card-piv.c and called from piv-tool which saves it off card, so it can be included in a CSR. Yubikey tool actually creates a dummy certificate and writes it to the card right away. piv-tool or card-piv.c could be modified to save the public key in a dummy certificate too.

To write objects, or generate key requires some type of authentication, normally not done by PIN and not known by user. It is not clear what the SwissBit code is doing for authentication to write objects.

See https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L692
where code could be added to write dummy certificate if requested.

I did ask for a debug log showing failure when { PIV_OBJ_PRIV, "Priv key ", "", 0, "", "\x50\x15", 0} is not present.

Sorry, this is a log with { PIV_OBJ_PRIV, "Priv key ", "", 0, "", "\x50\x15", 0} not being present. I had the private key of my card's profile key-domain for PKCS#15 emulation defined as BSO, so the private key was selected by the path of the app DF. I changed my profile, defined another path for the private key and included it in PIV_OBJ_PRIV_SWISSBIT_2900, so other PIV card should not be affected by this change. Also, I removed SC_CARD_TYPE_PIV_II_SWISSBIT_DUAL_CAC.

I am not using the piv-tool for key generation but the OpenSC minidriver with a custom PIV module instead of the built-in one. The code for authentication and key generation of card-piv.c is called from this module.

It looks like from the log, you have your own: C:\Program Files\OpenSC Project\OpenSC\profiles\PIV-II.profile
and C:\FIDO\ishield_piv_module\src\pkcs15-piv.c Is this a replacement for libopensc/pkcs15-piv.c, or is this really a pkcs15init/pkcs15-piv.c

Do you plans on submitting these to OpenSC?

The card-piv.c provides its own piv_select_file, piv_read_binary and piv_write_binary which replace the iso7816 routines so they can cache objects and read and write PIV objects. The list of PIV objects is defined in NIST documents and fixed tables and piv_find_obj_by_containerid is used map the iso7816 path to a known PIV object and return error if the object is not found in the list of objects or it in known that it can not exist on the card. priv->selected_obj keeps of the current object's enumtag. priv->rwb_state keeps track of waiting to first r/w operation and last r/w operation.

What your code appears to do is circumvent piv_find_obj_by_containerid by adding an entry for one file.

What I would like to propose, is the piv_select_file, piv_read_binary and piv_write_binary be modified so if the path is not for a PIV object, i.e. not found by piv_find_obj_by_containerid the iso7816 select_file, read_binary and write_binary be called instead. This would then allow binary access to any file accessible via the card applet.

Thus you could read or write any iso7816 files if present on the card. Other cards that have additional files could also take advantage of this too.

See https://github.com/dengert/OpenSC/tree/non-piv-files and aaad966

I don't have any PIV cards with non piv files so needs testing.

How does you custom PIV module for card administration, would it make sense to integrate this into OpenSC, i.e. pkcs15-init? Where are your tools published?

pkcs15init/pkcs15-piv.c is part of our PIV module and we also do have a card profile PIV-II.profile. Our PIV module is still in development and currently shipped with sample tokens to customers.

The PIV applet does not support object selection by path (instruction code 0xA4 is not supported), so calling iso7816 select_file fails. Also, as PIV cards are non-PKCS#15 cards, there is no actual private key file with known path that could be selected. So I tried to extend the selectable PIV objects as it is done for the non standard public key objects used by the piv-tool.

However, when using a private key, enabling file selection by path is not required for empty private key paths. In order not to set the path of a new private key based on the card profile with select_object_path, I introduced a new init driver operation for object path selection. For PIV cards, one wants to select an empty path for private key objects. This way, present private key objects are not overwritten due to path mismatch in sc_pkcs15_find_prkey_by_reference during key reference selection (present private key paths are set in src\libopensc\pkcs15-piv.c:sc_pkcs15emu_piv_init).

Have you looked at https://github.com/dengert/OpenSC/tree/non-piv-files and aaad966 yet?
It could be added to allow a caller to access IOS files on a PIV applet, if the file is not one of the emulated files supported by piv_find_obj_by_containerid. It allows both read binary and write binary to work.

If I understand your overall problem with PIV generation of private keys, is that the public key is returned as part of the GENERATE ASYMMETRIC KEY PAIR command done in card-piv.c:piv_generate_key, which is called from from piv-tool via card control SC_CARDCTL_PIV_GENERATE_KEY This returns the public key. As best I can tell, you must be using this in your pkcs15init/card-piv.c At which point you could write the public key. (The piv-tool save the public key as a disk file, to be used if no certificate is found on the card when trying to create a certificate request).

Another possibility is to have card-piv.c:piv_generate_key delete any existing certificate, generate the key and create a dummy certificate with the new public key and write this to the card and add it to the PIV cache of objects. Thus the public key would then be immediately accessible at the pkcs15 layer or available later for generating a certificate request.

I believe Yubikey does something like this. I am willing to write this for card-piv.c and simplify piv-tool.

I'll tap out for now. Please let me know when you have finalized pkcs15init/pkcs15-piv.c so that it can be integrated in this pull request as well.

I am already calling card-piv.c:piv_generate_key in our PIV modules pkcs15init/card-piv.c. My problem is not the creation of a certificate from the returned public key but I rather have the following problems without my code changes:

Key reference selection during key generation does not work as expected: It is iterated through key references, and for each key reference, it is checked if a private key object of that key reference and path coinciding with the path selected for the private key to be generated already exists. If the path of the private key is selected by select_object_path, it won't be empty and never match a present private key path. The path selected by select_object_path will match or be prefixed by the application DF path of the cards or general PKCS#15 profile. Hence, the first checked key reference will be used for key generation and eventually present key pairs are overwritten. So with the current implementation of pkcs15-piv.c:sc_pkcs15emu_piv_init, one wants to select an empty path for new private keys for PIV cards.

Choosing an empty path for newly generated private keys also solves my problem when using this key e.g. for signing. With an empty key path the usage of a new key proceeds as for a key that was already present at card binding. If the key path is not empty, the private key file needs to be selectable by piv_select_file. I had a look at https://github.com/dengert/OpenSC/tree/non-piv-files but as I commented previously I did not succeed to select an object by its path. Also this does not really help my problem to "select" a private key object by its path.

@frankmorgner Our PIV module is and will stay continuously tailored to our products. So at least for the moment we need to keep our module separate and proprietary in order to remain flexible and fully traceable with our deliveries. Currently, it is not planned to submit pkcs15init/pkcs15-piv.c.

Key reference selection during key generation does not work as expected: It is iterated through key references, and for each key reference, it is checked if a private key object of that key reference and path coinciding with the path selected for the private key to be generated already exists.

NIST 800-78-4 does not define a "private key object". The OpenSC piv driver emulates one for each asymmetric key by reading the associated certificate object (Part 1 Table 7. PIV Data Containers), extracting the SPKI from the certificate to get the key type and size. See Part 1 C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication)

So it might be possible to have multiple keys with the same reference on the card, (For example Key reference 9A RSA 2048 and 9A ECC p-256), the discovery process uses a single certificate (Part 1 Table 7. "X.509 Certificate for PIV Authentication (Key Reference '9A')" which can only define one key type and size.

So with the current implementation of pkcs15-piv.c:sc_pkcs15emu_piv_init, one wants to select an empty path for new private keys for PIV cards.

PIV does not have any concept of: "an empty path for new private keys for PIV cards."
The NIST 800-73-4 defines a fixed set of keys: 9A, 9C, 9D, 9E, 82-95 with matching certificates.

PIV does define "ContainerID" for some backwards compatibility but only for data objects, not private keys. The OpenSC piv driver uses these for known objects to emulate pkcs15 paths between pkcs15-piv.c and card-piv.c as paths. It goes further and for certificates uses the certificate's ContainerID + CECE so pkcs15 can read either the full object or just the certificate contained on the object. (certificates may be zipped, so card-piv.c also unzips the certificate)

And to emulate pkcs15 private keys, OpenSC piv driver https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L439-L497 fills these in from the SPKI in a certificate (or from ENV set by piv-tool), and does not try and read from the card.

I had a look at https://github.com/dengert/OpenSC/tree/non-piv-files but as I commented previously I did not succeed to select an object by its path.

The commit was designed to let you try select, read binary and write binary any path other then the ones defined as "ContainerID".

Do you have any debug log showing how it failed?

After per some offline clearification, I realized that even a driver for pkcs15init can be loaded using a shared library. This should be fine according to the LGPL licensing, I think. However, please have the technical restrictions in mind:

• Binary compatibility for internal libraries in OpenSC is typically not kept from release to release, which means that an external module likely needs to be recompiled as well
• Currently, external initialization module is loaded iff no internal module can be found and this will use the card driver's name as library name. This may lead to problems in the future, when some other initialization code for a PIV token is added (Yubikey support has at least been requested in the past, for example).
• Also, please note that we may decide to avoid structural changes to OpenSC if it doesn't benefit the FOSS project.

The PKCS#15 layer uses sc_pkcs15_read_file() to get certificates and objects from the card. This function uses a combination of sc_select_file and sc_read_binary/sc_read_record to actually get this from the card. If I'm not mistaken, then this is the reason for the file emulation with piv_select_file.

The same problem arises when accessing the objects from pkcs15init. In particular, sc_pkcs15init_init_prkdf selects a path, which is not known by piv_select_file.

I think the original approach of adding a dummy object(s) to card-piv.c with the path of the PRKDF does the least harm. Now, with the additional callback in sc_pkcs15init_operations we see modifications in all other drivers without any real benefit. However, I don't have a complete picture which other paths/objects need to be selectable and which other problems may still be present.

@swissbit-okaufmann , could you point to the exact pieces of code that are returning an error if neither PIV_OBJ_PRIV nor the callbacks would be present? Maybe @dengert can then suggest some alternative solution.

The main problem I have with

• Some field in the historic bytes in the ATR. Yubikey cards are identified https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L3118
• The response to SELECT AID can have a Application Label (tag 50) Oberthur/IDEMIA returns "ID-One PIV"

Sending: 00 A4 04 00 09 A0 00 00 03 08 00 00 10 00 00 
Received (SW1=0x90, SW2=0x00):
61 2C 4F 0B A0 00 00 03 08 00 00 10 00 01 00 50 a,O............P
0A 49 44 2D 4F 6E 65 20 50 49 56 61 09 79 07 4F .ID-One PIVa.y.O
05 A0 00 00 03 08 AC 06 80 01 27 06 01 00 7F 66 ..........'....f
08 02 02 03 F8 02 02 7F FF                      .........

The default would then be something like:
{ PIV_OBJ_PRIV_SWISSBIT_2900, "Priv key ", "", 0, "", "\x29\x00", PIV_OBJ_NOT_DEFINED }
And if it is a SWISSBIT card, the PIV_OBJ_NOT_DEFINED bit would set to 0.
piv_find_obj_by_containerid would then test for this flag.

I still don't see how you use PIV_OBJ_PRIV other then to trick piv_find_obj_by_containerid https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-piv.c#L2525

I would also like to see a debug log showing why the https://github.com/dengert/OpenSC/tree/non-piv-files did not work for you.

@dengert Please find the debug log using https://github.com/dengert/OpenSC/tree/non-piv-files. As you can see, the card does not support selection of files by their path. Also it is not the case that I have non PIV objects on my card but with the current implementation of OpenSC, when signing with a newly generated private key (with nonempty path), private key selection is required. This is the case as for a new private key a path based on the card's profile is selected by select_object_path called from sc_pkcs15init_init_prkdf. From my point of view, there are two approaches to resolve this: Either the path selected for a new private key is empty so when signing no selection is attempted. This is what happens when signing with a private key that was already present at card binding (path is assigned in sc_pkcs15emu_piv_init). Or the private key path is set by select_object_path but selection is enabled by modification of piv_select_file or piv_find_obj_by_containerid.

In the log without my modifications, i.e. without extension of the piv_objects array in libopensc/card-piv.c and without callbacks, two problems can be seen: use_key fails for the above explained reasons and key reference selection for a new key pair to be generated does not work as expected. I logged the attempt to create a self-signed certificate via the OpenSC Minidriver. As you can see from the log line 4027ff, there was already a certificate and corresponding key pair present on the card in PIV slot 9A. Prior to key generation (line 1048), the key reference 9A is selected for the new key pair (line 950ff). So the key pair in the slot 9A is just overwritten as the slot is assumed to be empty due to a path mismatch of the key to be generated and the key present of the card before card binding (see https://github.com/OpenSC/OpenSC/blob/master/src/pkcs15init/pkcs15-lib.c#L1329-L1350). (The certificate in 9A was present before key reference selection: no data was written to the slot using 00 DB 3F FF <data length> <data>.)

In order to avoid affecting the other card drivers, I would go back to the approach using PIV_OBJ_PRIV_SWISSBIT_2900 unless you have another idea.

(See last lines that may be the best solution.)

Thanks for the dump.
From the previous discussion, I was under the impression that your card has a PKCS15 file structure. Does it?

The "non-piv-files" appears in line 1244 to have sent: 00 A4 08 00 04 50 15 49 46 00 from your code, but it fails. So "non-piv-files" appears to be working as expected. But your card does not have the file or the path is wrong, or you need to access the pkcs15 via some other applet with its AID. (But changing AIDs may drop the login state of a PIV applet.)

Another approach...
I also see in line 250, the response to a PIV SELECT AID

Incoming APDU (65 bytes):
61 3D 4F 0B A0 00 00 03 08 00 00 10 00 01 00 79 a=O............y
0D 4F 0B A0 00 00 03 08 00 00 10 00 01 00 50 09 .O............P.
50 69 76 41 70 70 6C 65 74 AC 14 80 01 03 80 01 PivApplet.......
06 80 01 07 80 01 11 80 01 F0 80 01 F1 06 00 90 ................
00 

If the 0x50 tag value was something like: "Swissbit iShield FIDO2" or at least start with "Swissbit"
the OpenSC card-piv.c could use that to turn on the { PIV_OBJ_PRIV, "Priv key ", "", 0, "", "\x50\x15", 0}, only for Swissbit.

I would prefer the above, but It is also possible to use the ATR. Do you have plans for any other cards that need { PIV_OBJ_PRIV, "Priv key ", "", 0, "", "\x50\x15", 0},?

@frankmorgner may still have license issues. Is all your the code changes in the PR?

The PR hit a lot of OpenSC files. If I recall, only card-piv.c and cards.h really needed a mod.

In regard to:

In the log without my modifications, i.e. without extension of the piv_objects array in libopensc/card-piv.c"

The OpenSC PIV code was written to NIST specs that left up to the vendors how to provision a card. NIST did include some capability to generate a key on card and write some objects, and these are done via the piv-tool for testing.
Vendors who allow user provisioned cards also provide tools and/or minidriver to do this.

I think what you are seeing is NIST only allows one key per reference. With admin privileges a generate key command will over write any existing key. It is up to the provisioning software to make sure a certificate is written. NIST does not support writing a private key to the card.
(The OpenSC wiki appears to have dropped the examples use of piv-tool, but man piv-tool has the parameters.

The way to do this with piv-tool is something like:

• Write dummy cert: piv-tool -A "$PIV_AUTH" -s 00:DB:3F:FF:07:5C:03:5F:C1:$OIT:53:00 ($OIT is cert)

• Generate key: piv-tool -A "$PIV_AUTH" -G $KEYID:$ALGID -o cards/$1.$KEYID (saves pubkey in cards/$1.$KEYID)

• Generate CSR and sign: export PIV_$KEYID_KEY=cards/$1.$KEYID; req $SSLEAY_CONFIG -engine pkcs11 -sha256 -new -keyform engine -key $KEY_ID -out cards/$1.myreq.$KEYID.pem -text

• Get CSR signed by CA , save in cards/$1.cert.$KEYID.pem

• Load cert: piv-tool -v -A "$PIV_AUTH" -C $KEYID -i cards/$1.cert.$KEYID.pem

The key to above - when card-piv.c looks for cert but does not find one, it will read pubkey from env PIV_$KEYID_KEY=path to saved pubkey.

There are hints in card-piv.c how it could save the pubkey on the card in the certificate object when the key is generated, so it could be used immediately (or later as the pubkey would be on the card.) But after almost 20 years no one has asked for this.

                                    .




                                      .

@frankmorgner may still have license issues. Is all your the code changes in the PR?

With respect to the license, a loadable and proprietary pkcs15init module should be fine in my opinion. Only the technical limitations as stated above should be kept in mind.

The Swissbit iShield FIDO2 key is a non-PKCS15 PIV card but needs emulation as started in piv_select_file.

From my point of view, the object path selection for private keys is a general problem that does not only affect the Swissbit PIV card, so we decided to handle it in our external PKCS15init module and not to go back to the previous approach of extending the piv objects array in card-piv.c.

Does any other card vendor use OpenSC for card provisioning? Maybe no one encountered the inconsistency as other tools were used for administration.

Thanks, @frankmorgner! If we reconsider our solution and file handling, I'll come back to your offer and would be happy to discuss ideas with you.

@dengert Is there anything missing that needs to be addressed before this PR can get merged?

https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/discovery-process One way around this it to remove PIV ATR from registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\PIV Device ATR Cache

Thanks for the info, I think this can be tracked in a seperate issue/pr, which allows @swissbit-okaufmann to reproduce/test this. I think the solution could be straight forward by removing the iShield Authenticator's ATR from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\PIV Device ATR Cache via the OpenSC installer.

Only comment is with minidriver. If this card responds to PIV AID, Microsoft may use internal Microsoft PIV driver and never get to the OpenSC minidriver. i.e. if user inserts card before the OpenSC minidriver is installed.

https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/discovery-process One way around this it to remove PIV ATR from registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\PIV Device ATR Cache

Thanks for your review. As @frankmorgner suggested, I can try to reproduce this behaviour in a separate issue.

I just rebased to the current state of the master and updated the product name in two places.

Can this be merged?

Perfect, thanks a lot 🥳