Ok, this stuff cannot be this hard…
- Init via Open CSP
- Gen EC P256 DSA key
Open CSP…
CngProvider p = CngProvider.MicrosoftSmartCardKeyStorageProvider;
CngKey.Open(“mykey”, p);
Fails…
ITS AN OPEN COMMAND
What gives…
It is hard, because you are on Windows.
This typically means, that a 32-bit application is trying to access a 64-bit OpenSC installation or vice versa. What does certutil -scinfo say ?
Beware, that certutil is also available as 32-bit and 64-bit version.
1 Like
Nothing to do with 32/64 bit everything in most modern systems is 64 bit these days…
The card is pretty hopeless for everything other than an ECC sign as has no (read absolute zero) symmetric key support and hence all derive functions are useless as the key must be extracted into the clear which makes the HSM useless…
All of the pretend PKcs11 drives do everything is software so no need for any HSM… just fake stuff…
It is only good for a ECDSA sign nothing else even RSA is useless for the same reasons as above…
hence a very expensive ECC signer ( yet verify must be done off card which is not a problem…
Don’t try and use any standard Windows support the card simply has no functionally to make it usable other than sign… essentially what the screen shot is stating…
Live and learn the hard way…
.Will try and see if the SmartCard-HSM 4K can do a symmetric key operation in card?
At half the cost of nitrokey, cannot be any less functionality…
The idea with symmetric encryption using HSM is one of these two methods:
- Generate a random symmetric key and wrap the key using an asymmetric key only known to a key domain (one or more linked HSMs)
- Use the ECDH algorithm to derive a shared secret by only exchanging public information and reversing the process using the private key on the HSM.
https://python-pkcs11.readthedocs.io/en/latest/opensc.html?highlight=ecdh#ecdh
The other party can only decrypt when in possession of a HSM in the same key domain or when part of the ECDH key exchange.
Of course does the HSM support RSA, ECC and AES key types and crypto operations.
It does not support hybrid schemes, where RSA or ECC is used to obtain a symmetric key. The reason is, that the processing power required to do substantial encryption and decryption is not available in those small devices.
1 Like
FALSE…
Here is a dump of the nitro key KSM ( I purchased a week ago so the latest!
Supported mechanisms:
SHA-1, digest
SHA224, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
ECDSA, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA384, keySize={192,521}, sign, verify
ECDSA-SHA512, keySize={192,521}, sign, verify
ECDSA-SHA1, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA224, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA256, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDH1-COFACTOR-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
ECDH1-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-KEY-PAIR-GEN, keySize={192,521}, hw, generate_key_pair, EC F_P, EC parameters, EC OID, EC uncompressed
RSA-X-509, keySize={1024,4096}, hw, decrypt, sign, verify
RSA-PKCS, keySize={1024,4096}, hw, decrypt, sign, verify
SHA1-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA224-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA256-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA384-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA512-RSA-PKCS, keySize={1024,4096}, sign, verify
MD5-RSA-PKCS, keySize={1024,4096}, sign, verify
RIPEMD160-RSA-PKCS, keySize={1024,4096}, sign, verify
RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA224-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA384-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA512-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
One will not the complete absence of any AES mechanism, and all tests confirm no such mechanism exists in the nitro key HSM…
Also not the first “hw” prefix in the mechanisms report…
ECDH1-DERIVE, is unspecified and suspect makes use of SHA1 but have give up trying to second guess what the card does as drive constantly fails ( refer to the numerous reports about nitrokey) todate I have not found anyone who has made it work, and as hw AES support is non existent there is no point…
AES does not have substantial processing requirements and the HSM uses AES internally just blocks all user access, this is a proven fact as above, please cease claiming support for AES as it simply doe snot exist in the nitrokey reported mechanisms…
I have wasted my money based upon false claims.
" Technical Details
- Cryptographic algorithms: RSA, ECC, AES"
Please remove all references to AES mechanisms…
Note my tests conform support for this mechanism, and the documentation is correct…
But be careful the hw is for sign only no HSM does has based verify for ECDSA-SHA256 as there is no point. Also no idea why the card appears to store the EC pubkey X,Y values? just a waste of storage space?.
If the CEK is exposed then no point to a HSM…
As the nitro key HSM does not support AES then all pointless and might as well just use a Soft CSP…
The essence of ES-ECDH is key exchange of a KEK wrapped CEK…
ECDH can also be used with ephemeral keys on one side so that every new message can only be decrypted when in possession of the ECC key in the HSM. The key will be known if one ECDH is calculated outside HSM. But as you mentioned, it can also be used to exchange a key between HSMs. And then, if understood correctly, you could do the following:
Small amounts of data can be encrypted via AES using the generated AES key on the HSM, no?
Which middleware did you install ? OpenSC or the CardContact middleware ?
OpenSC does indeed not support AES operations, but that is an OpenSC issue and can not be blamed on the product. Our own module supports AES, as you can see in the tests.
The sc-hsm-pkcs11 module reports:
Using slot 0 with a present token (0x5)
Supported mechanisms:
RSA-X-509, keySize={1024,4096}, hw, encrypt, decrypt, sign, verify
RSA-PKCS, keySize={1024,4096}, hw, encrypt, decrypt, sign, verify
RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
SHA1-RSA-PKCS, keySize={1024,4096}, hw, sign, verify
SHA256-RSA-PKCS, keySize={1024,4096}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
ECDSA, keySize={192,521}, hw, sign, verify
ECDSA-SHA1, keySize={192,521}, hw, sign, verify
RSA-PKCS-OAEP, keySize={1024,4096}, hw, encrypt, decrypt
SHA-1, digest
SHA224, digest
SHA256, digest
SHA384, digest
SHA512, digest
ECDSA-KEY-PAIR-GEN, keySize={192,521}, hw, generate_key_pair
RSA-PKCS-KEY-PAIR-GEN, keySize={1024,4096}, hw, generate_key_pair
AES-KEY-GEN, keySize={128,256}, hw, encrypt, decrypt, generate, derive
mechtype-0x80000001, keySize={1024,4096}, hw, sign, verify
mechtype-0x80000003, keySize={1024,4096}, hw, sign, verify
mechtype-0x80000010, keySize={192,521}, hw, sign, verify
mechtype-0x80000011, keySize={192,521}, hw, sign, verify
Please note that for asymmetric key pairs, the public key operation is always performed in software, while the private key operation is performed in the HSM. For AES all operations are performed in the HSM. But once again, this works for small amounts of clear text, but not for large files due to processing constraints (I/O and CPU power).
Please refer to the sc-hsm-pkcs11-test.c module to see how individual mechanisms can be used. Not all functions of the HSM are actually exposed on the PKCS#11 interface, because there are no matching mechanisms in the standard. The same is true for the CSP Minidriver that does not support symmetric crypto at all.
2 Likes
Here is PKCS11
PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 3.0
5.18.1 C_GenerateKey
5.8.2 C_Encrypt
5.5.5 C_GetMechanismList
** One will note that PKCS11 does not limit or restrict ANY mechanisms supported by the HSM…
ANY SUGGETION PKCS11 limits any mechanism is FALSE…
*** Here is the report from your card, I have no idea where your report comes from but NOT your HSM 2 card…
– One more time
Supported mechanisms:
SHA-1, digest
SHA224, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
ECDSA, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA384, keySize={192,521}, sign, verify
ECDSA-SHA512, keySize={192,521}, sign, verify
ECDSA-SHA1, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA224, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-SHA256, keySize={192,521}, hw, sign, verify, EC F_P, EC parameters, EC OID, EC uncompressed
ECDH1-COFACTOR-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
ECDH1-DERIVE, keySize={192,521}, hw, derive, EC F_P, EC parameters, EC OID, EC uncompressed
ECDSA-KEY-PAIR-GEN, keySize={192,521}, hw, generate_key_pair, EC F_P, EC parameters, EC OID, EC uncompressed
RSA-X-509, keySize={1024,4096}, hw, decrypt, sign, verify
RSA-PKCS, keySize={1024,4096}, hw, decrypt, sign, verify
SHA1-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA224-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA256-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA384-RSA-PKCS, keySize={1024,4096}, sign, verify
SHA512-RSA-PKCS, keySize={1024,4096}, sign, verify
MD5-RSA-PKCS, keySize={1024,4096}, sign, verify
RIPEMD160-RSA-PKCS, keySize={1024,4096}, sign, verify
RSA-PKCS-PSS, keySize={1024,4096}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA224-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA384-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
SHA512-RSA-PKCS-PSS, keySize={1024,4096}, sign, verify
Here is the test case for PKCS11 and your card…
objectAttributes.Add(session.Factories.ObjectAttributeFactory.Create(CKA.CKA_CLASS, CKO.CKO_SECRET_KEY));
objectAttributes.Add(session.Factories.ObjectAttributeFactory.Create(CKA.CKA_KEY_TYPE, CKK.CKK_AES));
// Specify key generation mechanism
IMechanism mechanism = session.Factories.MechanismFactory.Create(CKM.CKM_AES_KEY_GEN);
// Generate key
return session.GenerateKey(mechanism, objectAttributes);
THERE IS NOTHING MISSING IN PKCS11
The issue is nitrokey is missing the HSM support for CKK_AES and CKM_AES_KEY_GEN
I use this on other PKCS11 HSM's not rocket science..Please post the OpenSC code to produce more than 33 mechanisms
You list is impossible to reproduce…
I have tried several commercial Admin tools (Thales) plus a public domain (attached) my own code and your list does not exist!
THERE IS NO `AES-KEY-GEN
Note my sole requirement is to use AES to wrap a AES CEK so there is zero issues with any HSM…
To be clear, here is the code snipet to run, which will always return 33 object and there is NO AES support
"
using (IPkcs11Library pkcs11Library = Settings.Factories.Pkcs11LibraryFactory.LoadPkcs11Library(Settings.Factories, Settings.Pkcs11LibraryPath, Settings.AppType))
{
// Find first slot with token present
ISlot slot = GetUsableSlot(pkcs11Library);
// Get supported mechanisms
List mechanisms = slot.GetMechanismList();
All out of the box standard PKCS11 stuff…
There is NO limitations with PKCS11
Here is a commercial HSM report
0x00000001 - CKM_RSA_PKCS
0x00000003 - CKM_RSA_X_509
0x00000000 - CKM_RSA_PKCS_KEY_PAIR_GEN
0x00000006 - CKM_SHA1_RSA_PKCS
0x00000046 - CKM_SHA224_RSA_PKCS
0x00000040 - CKM_SHA256_RSA_PKCS
0x00000041 - CKM_SHA384_RSA_PKCS
0x00000042 - CKM_SHA512_RSA_PKCS
0x00000009 - CKM_RSA_PKCS_OAEP
0x0000000a - CKM_RSA_X9_31_KEY_PAIR_GEN
0x0000000c - CKM_SHA1_RSA_X9_31
0x0000000d - CKM_RSA_PKCS_PSS
0x0000000e - CKM_SHA1_RSA_PKCS_PSS
0x00000047 - CKM_SHA224_RSA_PKCS_PSS
0x00000043 - CKM_SHA256_RSA_PKCS_PSS
0x00000044 - CKM_SHA384_RSA_PKCS_PSS
0x00000045 - CKM_SHA512_RSA_PKCS_PSS
0x00000010 - CKM_DSA_KEY_PAIR_GEN
0x00000011 - CKM_DSA
0x00000012 - CKM_DSA_SHA1
0x00000134 - CKM_DES3_MAC
0x00000135 - CKM_DES3_MAC_GENERAL
0x00000130 - CKM_DES2_KEY_GEN
0x00000131 - CKM_DES3_KEY_GEN
0x00001082 - CKM_AES_CBC
0x00001085 - CKM_AES_CBC_PAD
0x00001081 - CKM_AES_ECB
0x00001104 - CKM_AES_ECB_ENCRYPT_DATA
0x00001105 - CKM_AES_CBC_ENCRYPT_DATA
0x00001083 - CKM_AES_MAC
0x00001084 - CKM_AES_MAC_GENERAL
0x00001080 - CKM_AES_KEY_GEN
0x00000220 - CKM_SHA_1
0x00000221 - CKM_SHA_1_HMAC
0x00000222 - CKM_SHA_1_HMAC_GENERAL
0x00000255 - CKM_SHA_224
0x00000256 - CKM_SHA_224_HMAC
0x00000257 - CKM_SHA_224_HMAC_GENERAL
0x00000250 - CKM_SHA_256
0x00000251 - CKM_SHA_256_HMAC
0x00000252 - CKM_SHA_256_HMAC_GENERAL
0x00000260 - CKM_SHA_384
0x00000261 - CKM_SHA_384_HMAC
0x00000262 - CKM_SHA_384_HMAC_GENERAL
0x00000270 - CKM_SHA_512
0x00000271 - CKM_SHA_512_HMAC
0x00000272 - CKM_SHA_512_HMAC_GENERAL
0x00000005 - CKM_MD5_RSA_PKCS
0x00000020 - CKM_DH_PKCS_KEY_PAIR_GEN
0x00000021 - CKM_DH_PKCS_DERIVE
0x00000122 - CKM_DES_CBC
0x00000125 - CKM_DES_CBC_PAD
0x00000121 - CKM_DES_ECB
0x00001100 - CKM_DES_ECB_ENCRYPT_DATA
0x00001101 - CKM_DES_CBC_ENCRYPT_DATA
0x00000123 - CKM_DES_MAC
0x00000124 - CKM_DES_MAC_GENERAL
0x00000120 - CKM_DES_KEY_GEN
0x00000102 - CKM_RC2_CBC
0x00000105 - CKM_RC2_CBC_PAD
0x00000101 - CKM_RC2_ECB
0x00000103 - CKM_RC2_MAC
0x00000104 - CKM_RC2_MAC_GENERAL
0x00000100 - CKM_RC2_KEY_GEN 0x00000111 - CKM_RC4
0x00000110 - CKM_RC4_KEY_GEN
0x00000332 - CKM_RC5_CBC
0x00000335 - CKM_RC5_CBC_PAD
0x00000331 - CKM_RC5_ECB
0x00000333 - CKM_RC5_MAC
0x00000334 - CKM_RC5_MAC_GENERAL
0x00000330 - CKM_RC5_KEY_GEN
0x00000302 - CKM_CAST_CBC
0x00000305 - CKM_CAST_CBC_PAD
0x00000301 - CKM_CAST_ECB
0x00000303 - CKM_CAST_MAC
0x00000304 - CKM_CAST_MAC_GENERAL
0x00000300 - CKM_CAST_KEY_GEN
0x00000315 - CKM_CAST3_CBC_PAD
0x00000312 - CKM_CAST3_CBC
0x00000311 - CKM_CAST3_ECB
0x00000313 - CKM_CAST3_MAC
0x00000314 - CKM_CAST3_MAC_GENERAL
0x00000310 - CKM_CAST3_KEY_GEN
0x00000322 - CKM_CAST5_CBC
0x00000325 - CKM_CAST5_CBC_PAD
0x00000321 - CKM_CAST5_ECB
0x00000323 - CKM_CAST5_MAC
0x00000324 - CKM_CAST5_MAC_GENERAL
0x00000320 - CKM_CAST5_KEY_GEN
0x00000200 - CKM_MD2
0x00000391 - CKM_MD2_KEY_DERIVATION
0x000003a0 - CKM_PBE_MD2_DES_CBC
0x00000210 - CKM_MD5
0x00000380 - CKM_SSL3_MD5_MAC
0x00000211 - CKM_MD5_HMAC
0x00000212 - CKM_MD5_HMAC_GENERAL
0x00000390 - CKM_MD5_KEY_DERIVATION
0x000003a1 - CKM_PBE_MD5_DES_CBC
0x000003a2 - CKM_PBE_MD5_CAST_CBC
0x000003a3 - CKM_PBE_MD5_CAST3_CBC
0x000003a5 - CKM_PBE_SHA1_CAST5_CBC
0x00000371 - CKM_SSL3_MASTER_KEY_DERIVE
0x00000372 - CKM_SSL3_KEY_AND_MAC_DERIVE
0x00000370 - CKM_SSL3_PRE_MASTER_KEY_GEN
0x00000381 - CKM_SSL3_SHA1_MAC
0x00000360 - CKM_CONCATENATE_BASE_AND_KEY
0x0000800d - CKM_CONCATENATE_KEY_AND_BASE_OLD_XXX
0x00000362 - CKM_CONCATENATE_BASE_AND_DATA
0x00000363 - CKM_CONCATENATE_DATA_AND_BASE
0x00000364 - CKM_XOR_BASE_AND_DATA
0x8000001b - CKM_XOR_BASE_AND_KEY
0x00000365 - CKM_EXTRACT_KEY_FROM_KEY
0x00000350 - CKM_GENERIC_SECRET_KEY_GEN
0x00000392 - CKM_SHA1_KEY_DERIVATION
0x00000396 - CKM_SHA224_KEY_DERIVATION
0x00000393 - CKM_SHA256_KEY_DERIVATION
0x00000394 - CKM_SHA384_KEY_DERIVATION
0x00000395 - CKM_SHA512_KEY_DERIVATION
0x000003a6 - CKM_PBE_SHA1_RC4_128
0x000003a7 - CKM_PBE_SHA1_RC4_40
0x000003a8 - CKM_PBE_SHA1_DES3_EDE_CBC
0x000003a9 - CKM_PBE_SHA1_DES2_EDE_CBC
0x000003aa - CKM_PBE_SHA1_RC2_128_CBC
0x000003ab - CKM_PBE_SHA1_RC2_40_CBC
0x000003b0 - CKM_PKCS5_PBKD2
0x00000562 - CKM_ARIA_CBC
0x00000565 - CKM_ARIA_CBC_PAD
0x00000561 - CKM_ARIA_ECB
0x00000566 - CKM_ARIA_ECB_ENCRYPT_DATA
0x00000567 - CKM_ARIA_CBC_ENCRYPT_DATA
0x00000563 - CKM_ARIA_MAC
0x00000564 - CKM_ARIA_MAC_GENERAL
0x00000560 - CKM_ARIA_KEY_GEN
0x80000105 - CKM_SEED_CBC
0x80000106 - CKM_SEED_CBC_PAD
0x80000104 - CKM_SEED_ECB
0x80000107 - CKM_SEED_MAC
0x80000103 - CKM_SEED_KEY_GEN
0x80000100 - CKM_HAS160
0x80000101 - CKM_KCDSA_KEY_PAIR_GEN
0x80000102 - CKM_KCDSA_HAS160
0x80000109 - CKM_KCDSA_SHA1
0x00001050 - CKM_ECDH1_DERIVE
0x00000133 - CKM_DES3_CBC
0x00000136 - CKM_DES3_CBC_PAD
0x00000132 - CKM_DES3_ECB
0x00001102 - CKM_DES3_ECB_ENCRYPT_DATA
0x00001103 - CKM_DES3_CBC_ENCRYPT_DATA
0x00001040 - CKM_ECDSA_KEY_PAIR_GEN
0x00001041 - CKM_ECDSA
0x00001042 - CKM_ECDSA_SHA1
One can observe there is NO PKCS11 limitations on mechanisms only the HSM support…
Could you please answer my question which middleware you installed ?
The PKCS#11 interface is provided by the crypto middleware, not the HSM. The HSM interface is using ISO 7816-4 command APDUs and the crypto middleware translates information from the HSM into the PKCS#11 API.
There are functions available at the low-level interface that are not exposed in the crypto middleware. That is why it makes a difference, if you install OpenSC or the native PKCS#11 module of the HSM. The OpenSC middleware does not support AES, so it will not indicate AES support in the mechanism list. The CardContact modul does support the AES implementation in the HSM, so its indicated that in the mechanism list.
The list of mechanism in my previous post was generated with
pkcs11-tool --module /usr/local/lib/libsc-hsm-pkcs11.so -M
1 Like
-
As per your documentation OpenSC is installed…
-
OpenSC does support both CKM_AES_KEY_GEN and CKM_AES_KEY_WRAP…
"extarcted from the OpenSC source code- new for v2.11 */
public static final int CKM_AES_KEY_GEN = 0x00001080;"
- new for v2.11 */
-
The point of the Nitrokey is to map the hardware top the openSc interface, and produce the result that a call as below does NOT return unsupported…
IMechanism mechanism = session.Factories.MechanismFactory.Create(CKM.CKM_AES_KEY_GEN);// Generate key return session.GenerateKey(mechanism, objectAttributes); }
Otherwise what is the point of the nitro key if no funtion can be accessed without error…
The code is the same code I use via Pkcs11 to generate and wrap an AES key on my thales HSM withtu problem…
The anser is pure gooblygook…
Please fix the defective interface between nitrokey and the OpenSC implementation of Pkcs11 or remove all reference and support for AES and OpenSC…
Not happy…