-
Notifications
You must be signed in to change notification settings - Fork 732
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
pkcs15-init: key generation and import for OpenPGP Card with different algorithms #1432
Comments
Is that really needed? why not use gnupg for initialization? The problem is that if you don't (find someone who) touch(es) the sourcecode, propably nobody ever will. @hongquan, what do you think? |
I remember pk15init can initial OpenPGP card with 4096-bit key. Could you please produce more verbose log? |
Sure, here is a log.
Well, that surely depends on how you like to see it. Why should one install gnupg just for initialization although it is not used afterwards. This issue is definitely not high priority, but having this working is surely much more convenient and less confusing for users...
Therefore I asked for a hint, what needs to be done/what pitfalls probably are there, so that I may can manage to do it myself, but I totally see that this is like fixing it yourself, so nevermind. |
I'm reading the log. Actually, last time I worked on OpenPGP, it was not necessary to use |
@alex-nitrokey Ok, from the log
It is that the parameter (of key size 4096) was rejected right from the pkcs15-lib layer, not even touch the underneath openpgp card driver (implemented by me). So, it may come from the behavior of pkcs15 that I noted:
One more note:
So, to use |
Hey @hongquan , thank you for your help! I am basically quite aware of the workaround and the reasons for this behaviour. I opened this issue for fixing this limitation of pkcs15-init. So while I've seen that "pkcs15-init requires new key length to be the same as existing key", I was wondering how I could change this so that pkcs15-init works straight away... |
Ok. I misunderstood your intention. Thank you. |
I created a solution which works fine. Please have a look here. I wasn't sure if I am supposed to create a PR right away and want to ask here first. I basically added all supported algorithms. Right now only the existing algorithm settings are saved in the card capabilities instead. Glad to hear your opinion! |
Now, |
Looks good. But the Gnuk card only supports 1 algorithm. |
Thanks for the heads up! I wasn't aware of that. |
Problem Description
It is currently not possible to use
pkcs15-init
for generating and/or importing keys with attributes which are not i) the default (rsa/2048) or ii) previously set with other tools.Thus, if one wants to generate e.g. a rsa/4096 key on a factory-reset OpenPGP Card, pkcs15-init will fail with:
As a workaround users need to generate a similiar key with
openpgp-tool
first, to make sure that the correct algorithm is set. (e.g.openpgp-tool --verify CHV3 --pin 12345678 --gen-key 3 --key-len 4096
. The import/creation of keys with pkcs15-init is possible afterwards.The algorithm at stake is checked here and here for a list of compatible algorithm for this card. The problem is, that this list is not correct. Instead it seems to be a known default (rsa/2048) and the currently set value as extracted through this code. Other than stated in the comment, it does not extract supported available algorithm, but the currently set.
Please read 4.4.3.7 of the specification which states
Proposed Resolution
I think pkcs15-init either needs a correct list of all compatible algorithm for the cards or should just try to set the requested algorithm.
The second option appears to be already done by
openpgp-tool
. It works just fine because of the fact that a card should (and does) reject incompatible algorithms anyway. For example, a OpenPGP Card v3 does not accept rsa/1024 (other than v2), thus the output is:I'd love to create a PR, but I had problems understanding the code to realize the first approach and the second approach is related to checks in pkcs15-libs.c that used by too many cards. I don't dare to touch this and I'd be happy about tips how I could fix this limitation :-)
PS: This issue is in some ways related to #1011
The text was updated successfully, but these errors were encountered: