MyEID: For the private key, use the ACLs that are defined in the prof…

[popovec]

…ile.

Another issue regarding setting the ACL to a private key was raised in issue #2963. This patch removes a part of the code that makes it impossible to set the ACL according to the selected profile.

Checklist

• PKCS#11 module is tested

[Jakuje]

This exact code wast introduced in 8cf68bc by @hhonkanen describing it was fixing an issue that the key files were always created under PIN 1 regardless what was requested by the user. Is the original issue resolved in some other way or do we need a follow-up issue or fixes for the original issue?

[popovec]

8cf68bc introduced the use of '--id' as information under which ACL the key should be created. This breaks the normal way where ACLs are specified in the profile file.

Let's wait for the approval of this PR from @hhonkanen.

[hhonkanen]

The purpose of 8cf68bc is to be able to dynamically select, that for example PIN 1 is used with the authentication key, e.g. for login, and PIN 2 is used for e.g. signing documents, and associated with the signing key. This is still necessary, so seems like we must find a way to combine this functionality with the ability to customize the profile. Or does OpenSC now handle what 8cf68bc does in some generic way for all cards?

8cf68bc sets all security attributes to the value set in -a. Would it make sense to set only "USE" security attribute to the PIN set in object.auth_id, and take the rest (PUT DATA, GENERATE, DELETE) from the profile? This would at least resolve the use case we have now, where it is important that only SO can delete keys, while keys can be used with PIN 1. In pkcs15-init -a option is mandatory for key generation, unless -insecure switch is used to allow USE without a pin at all, therefore I think the logic would be ok: USE attribute is always provided by caller or user, and other security attributes would come from the profile.

Could something like this work?

if (file->sec_attrs_len >= 3)
    memcpy(sec_attrs, file->sec_attrs, 3);  /* take the security attributes set by the profile */

pin_reference = pkcs15_auth_info->attrs.pin.reference;

if (pin_reference >= 1 && pin_reference < MYEID_MAX_PINS) {
	sec_attrs[0] |= (pin_reference << 4);    /* set only USE ac to object.auth_id*/
	sc_file_set_sec_attr(file, sec_attrs, sizeof(sec_attrs));

I have some challenges building OpenSC, so I cannot test this right away. I don't have a Linux environment anymore, and I am trying to build it on Windows according to https://github.com/OpenSC/OpenSC/wiki/Compiling-on-Windows
but I still get various errors.

I can create a PR with the code above, if you agree that the logic is correct.

[popovec]

The user can set his own profile when generating/importing the key:

cp /usr/share/opensc/pkcs15.profile .
cp /usr/share/opensc/myeid.profile  myeid_local.profile 
echo -e "app default {\n profile_dir = .\n}\n "> opensc_test.conf

Edit myeid_local.profile as needed... and import the key with ACL according to the local profile:

OPENSC_CONF=./opensc_test.conf pkcs15-init -c myeid_local --store-private-key "keys/rsa2048-key.pem" --key-usage sign,decrypt  --auth-id=1 --pin 1111 --so-pin 0000

I admit, it's a bit of an overcomplicated solution.

Using the --auth-id switch could partially simplify the ACL setting for the generated/imported key, but this probably introduces inconsistency with respect to other cards supported in OpenSC. I would welcome more contributors to comment on this topic.

[hhonkanen]

pkcs15-init's help shows:
-a, --auth-id Specify ID of PIN to use/create
I think when creating a key, "use" can be understood to associate the pin with the new key. If we keep the feature, it could be made more clear in the help, though.

The feature to associate the auth-id with the key may be used by existing MyEID users, and removing it could cause problems to them. I know it is a very typical scenario among MyEID users to have a separate key+certificate combination for authentication and signing, and to associate them with different pins. Creating two profiles and switching between them would work too, but I agree users might find it a bit complicated, and its not obvious that you need to do this.

My code from 2017 seems faulty though, management permissions should be separate from the USE permission.

[Jakuje]

I agree that creating a separate profiles for setting different auth objects to created keys is probably overkill (unless we would provide some alternative myeid profile that would create this layout by default?).

I used pkcs15init only with the MyEID card, with the ePass (I think this one does not support multiple auth objects?) and sc-hsm (all mostly for testing) so I do not have huge experience with the smart card enrollment.

I see there are hints to use --auth-id in the wiki for Rutoken when creating keys as well as for OpenPGP (and in readme and in manual pages) so I would consider this as a supported use case that needs a better documentation (and some fix for MyEID, likely something like proposed in #3020 (comment) ) :

• https://github.com/OpenSC/OpenSC/wiki/Aktiv-Co.-Rutoken-ECP
• https://github.com/OpenSC/OpenSC/wiki/OpenPGP-card

• OpenSC/src/pkcs15init/README

  Line 13 in a007f3a

  Generate a 512 bit RSA key and store on card, protected by the above PIN

• OpenSC/doc/tools/pkcs15-init.1.xml

  Line 136 in a007f3a

  <command>pkcs15-init --generate-key "keyspec" --auth-id "nn"</command>

[hhonkanen]

I got my build environment mostly working, but I have still issues with pkcs15-init and OpenSSL.

I created a branch for the proposed changes here: https://github.com/hhonkanen/OpenSC/tree/key_permissions_from_profile

I will be on vacation next week, and may not be able to test it today, as I have to fix the build issues first to get pkcs15-init working. Feel free to test it meanwhile, if anybody has a chance.

This might not be the optimal solution. I think it would be better to handle it in higher level in a common way for all cards, but it would require some more work. myeid_create_key calls myeid_new_file, which calls sc_profile_get_file to get the sc_file object with ACLs set as defined in the profile. I couldn't find any card-independent function which would replace the USE permission with the auth-id.

[hhonkanen]

I finally had time to get my build environment working, and tested the above-mentioned patch, but it doesn't set the ACLs correctly. I have to debug it to understand how it works.