OpenSCToken
OpenSCToken copied to clipboard
frankmorgner
TKAuthenticationHintsProvider error -11
Hallo, I have a Nitrokey Pro 2 with cacert keys and certificate:
pkcs15-init --delete-objects privkey,pubkey --id 3 --store-private-key myprivate.p12 --format pkcs12 --auth-id 3 --verify-pin
openssl pkcs12 -in myprivate.p12 -nocerts -out mykey.pem
pkcs15-init --delete-objects privkey,pubkey --id 2 --store-private-key mykey.pem --auth-id 3 --verify-pin --id 2
sc_auth identities returns Unpaired identities: 49A94D744FC40BEB79A5438838990C1738B4742D Cardholder certificate (CAcert WoT User)
When I pair the identity sudo sc_auth pair -h 49A94D744FC40BEB79A5438838990C1738B4742D, I get following error:
Cannot pair user (public key hash: 49A94D744FC40BEB79A5438838990C1738B4742D). The operation couldn’t be completed. (TKAuthenticationHintsProvider error -11 - Initialisierungsfehler des SmartCard-Algorithmus.)
What am I doing wrong?
Hello, meanwhile I updated to macOS Catalina 10.15.2 and OpenSC-0.20.0-rc4 but I still get the same error. It would really be helpful to get some feedback if I'm doing something wrong, it is a bug in OpenSCToken or just not possible? Thank you very much in advance!
@bottee Which version of OpenSC do you use? In general, using the latest from master (not released yet) is advised because it contains fixes for several issues.
@jans23 I tried to build OpenSC from master but it didn't work. I created https://github.com/frankmorgner/OpenSCToken/issues/22
Only some documentation issues caused #22.
Now I was able to build and debug. The problem with the Nitrokey Pro 2 seems to be located in TokenSession.m in supportsOperation:
alg_info->flags is for the Nitrokey Pro 2 0x80000102 which means:
#define SC_ALGORITHM_ONBOARD_KEY_GEN 0x80000000
#define SC_ALGORITHM_RSA_HASH_NONE 0x00000100 /* only applies to PKCS1 padding */
#define SC_ALGORITHM_RSA_PAD_PKCS1 0x00000002 /* PKCS#1 v1.5 padding */
and the following condition always leads to return NO:
if (!alg_info || ((alg_info->flags & minimum_flags) != minimum_flags))
return NO;
Maybe the following TODO is relevant?
/* TODO in addition with inspecting the card's flags we should check the
* TokenInfo's and the private key's supported PKCS#11 mechanisms, see
* pkcs15_prkey_can_do() in src/pkcs11/framework-pkcs15.c
*/
I do not understand which Mechanisms the Nitrokey Pro 2 supports and how to determine them.
It's normal to only support a small subset of the algorithms available. If you're interested what your application requests, you should break here https://github.com/frankmorgner/OpenSCToken/blob/84e0052e15b63fe87841187a413cdc42c0da6bb1/OpenSCToken/TokenSession.m#L32-L63
Currently, we're only checking the card's capabilities (card->algorithms). The comment with pkcs15_prkey_can_do() means that we could additionally check whether the requested key supports the algorithm, which would be even more restrictive.
Please check
- which algorithm the application requests
- if there are any card->algorithms that would fulfil the requirement, but are not evaluated since they are at the end of the list...
For a nitrokey (which is a sc-hsm), all algorithm flags are added as SC_ALGORITHM_RSA_RAW|SC_ALGORITHM_RSA_PAD_PSS
or SC_ALGORITHM_ECDSA_RAW| SC_ALGORITHM_ECDH_CDH_RAW| SC_ALGORITHM_ECDSA_HASH_NONE| SC_ALGORITHM_ECDSA_HASH_SHA1| SC_ALGORITHM_ECDSA_HASH_SHA224| SC_ALGORITHM_ECDSA_HASH_SHA256, which means that your card should only support kSecKeyAlgorithmRSAEncryptionRaw or kSecKeyAlgorithmRSASignatureRaw... This is something I've already tested with sc-hsm (not nitrokey)
Just to clarify and to avoid a potential confusion: The description of this ticket states that a Nitrokey Pro is used. The Nitokey Pro is independent of sc-hsm. Nitrokey HSM is based on sc-hsm. Both Nitrokey Pro 2 and Nitrokey HSM 2 support RSA and ECC.
@jans23 what's the underlying smart card technoligy of Nitrokey Pro? I.e. which card driver is used with OpenSC, OpenPGP? What's the output of opensc-tool -n?
OpenPGP card only announces SC_ALGORITHM_RSA_PAD_PKCS1| SC_ALGORITHM_RSA_HASH_NONE on the card level, which could be used when the application requests kSecKeyAlgorithmRSAEncryptionPKCS1.
For a different card, the easiest solution was to support SC_ALGORITHM_RSA_RAW on the card level. I'm not sure, however, if this is possible for OpenPGP.
Maybe we need some local mapping to support the other mechanisms. We have this in PKCS#11 already, but I'm afraid I don't have time to implement this in OpenSCToken.
I just tested the support of SC_ALGORITHM_RSA_RAW on the card level as @frankmorgner suggested. It is not working for Nitrokey Pro 2, sc_pkcs15_compute_signature failed.
So it seems there is no solution for RSA at the moment. I'm not able to implement the suggested mapping.
I tried to use ECC keys instead:
https://www.nitrokey.com/documentation/elliptic-curves-ecc-support-nitrokey-storage-2-and-pro-2
To get them signed I tried:
gpgsm --gen-key -o temporary.cert
gpgsm (GnuPG/MacGPG2) 2.2.17; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Bitte wählen Sie, welche Art von Schlüssel Sie möchten:
(1) RSA
(2) Vorhandener Schlüssel
(3) Vorhandener Schlüssel auf der Karte
Ihre Auswahl? 3
Karten-Seriennummer: zzz...
Vorhandene Schlüssel:
(1) aaaa... OPENPGP.1 brainpoolP256r1
(2) bbbb... OPENPGP.2 brainpoolP256r1
(3) cccc... OPENPGP.3 brainpoolP256r1
Ihre Auswahl? 3
Mögliche Vorgänge eines RSA-Schlüssels:
(1) signieren, verschlüsseln
(2) signieren
(3) verschlüsseln
Ihre Auswahl? 2
Bitte geben sie den Namen des X.509 Subjekts ein: CN=xxx yyy
Email-Adresse eingeben (Beenden mit einer leeren Zeile):
> [email protected]
>
DNS Namen eingeben (Optional. Beenden mit einer leeren Zeile):
>
Bitte geben Sie die URIs ein (Optional. Beenden mit einer leeren Zeile):
>
Ein eigenbeglaubigtes Zertifikat erzeugen? (j/N) j
Verwendete Parameter:
Key-Type: card:OPENPGP.3
Key-Length: 1024
Key-Usage: sign
Serial: random
Name-DN: CN=xxx yyy
Name-Email: [email protected]
Proceed with creation? (y/N) y
Das eigenbeglaubigte Zertifikat wird erzeugt. Dies kann einen Moment dauern ...
gpgsm: error setting the siginfo: Wrong public key algorithm
gpgsm: error creating certificate request: Wrong public key algorithm <GpgSM>
Does anyone have a hint what is going wrong?
Your using GPG, which is not related to OpenSC. Maybe GPG doesn't support the Brainpool curves, but I cannot say more about GPG.
I am not sure, if I can add anything useful here, because I don't know if I fully understand the problem.
But I saw the Unpaired identities output and that you imported the very same key to the second slot although this should not necessary for the Pro 2 anymore. This is a deprecated behavior from older cards which could not decrypt with slot 3. So what I would do is to try the very same of the original post while only importing the p12 to slot 3.
Why the ECC is not announced I can not see.
If only slot 3 should be exported to PKCS#11, CTK or Minidriver, you need to change pkcs15-openpgp.c, but I think that is covered in https://github.com/OpenSC/OpenSC/issues/1843
Maybe this is the reason for the original problem, maybe not. I think it's more likely that we need better compatibility to Apple's encryption flags (or support of SC_ALGORITHM_RSA_RAW in OpenPGP)...
I have the exact same error when trying to pair my Estonian Identity Card with my user account :/
esteid only supports ecdsa, which is implemented, but untested. Feel free to extend the implementation.
OK, I’ll look into it. @frankmorgner do you have any pointers on where to start poking around in the code?
Great, I appreciate your initiative!
My guess is that algorithmToFlags() is performing a bad mapping to your card's flags. Maybe you need to add kSecKeyAlgorithmECDSASignatureDigestX962 here, which could then be mapped to SC_ALGORITHM_ECDSA_RAW, which is supported by your card.
Previous bug reports show that only kSecKeyAlgorithmRSASignatureRaw is working, so I assume that there's also a problem with the other mappings from Apple's RSA flags to OpenSC's RSA flags as well. Unfortunately, Apple's flags are not well documented so one could start by checking the input data to determine the signature format (i.e. OpenSC's signature flags)...
https://github.com/frankmorgner/OpenSCToken/pull/40 fixes this same issue I was seeing using a Yubikey 5 OpenPGP with an ECDSA key/cert.
OK, I'll merge the PR soon as it at least fixes some problems even though not all situations may be covered.