-
Notifications
You must be signed in to change notification settings - Fork 710
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
MyEID: For the private key, use the ACLs that are defined in the prof… #3020
base: master
Are you sure you want to change the base?
Conversation
…ile. Another issue regarding setting the ACL to a private key was raised in issue OpenSC#2963. This patch removes a part of the code that makes it impossible to set the ACL according to the selected profile.
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? |
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. |
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?
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 I can create a PR with the code above, if you agree that the logic is correct. |
The user can set his own profile when generating/importing the key:
Edit
I admit, it's a bit of an overcomplicated solution. Using the |
pkcs15-init's help shows: 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. |
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
|
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. |
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. |
…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