Having tried almost all permutations is there anyway on this planet to use the Nitrokey with AES…
While it is obvious nitrokey is very limited and hence cannpt encrypt large data blobs ( why key wrap was invented) but also does not appear to work…
So lets start with something that MUST work to make AES keys of any usage…
iv= Jose.Arrays.Random(128);
data = Jose.Arrays.Random(256);
// Specify key generation mechanism, with initialization vector as parameter
ICkGcmParams parms = session.Factories.MechanismParamsFactory.CreateCkGcmParams(iv, 128, data, 256);
IMechanism mechanism = session.Factories.MechanismFactory.Create(CKM.CKM_AES_GCM, parms);
// Let fail agaain…
return session.Encrypt(mechanism, keyhandle,data)
Is there anyone who have managed to make this basic funtion work?
My recommendation is to follow the advice given in this forum.
You are trying to use CKM_AES_GCM which is not supported by the HSM. The mechanism is neither reported in the mechanism list nor specified anywhere in the documentation.
Your documentation is a collate mess and incomprehensible by anyone…
Your statement suggest nitro key has never used a HSM and is clueless about how they are used by your customers…
CKM_AES_GCM is NOT a mechanism its a CKM type, please understand the difference and your have no documentation regarding any support for CKM types…
One must spend endless hrs trying and see what does not fail… Please note there is no support listed for CKM_AES_CBC, and after wasting many hrs it is the ONLY AES mode that appears to work!!!
Please remove ALL reference to OpenSC support from your website and all documentation, so your customers do not waste their time and money going down rat holes.
What has been proven to work…
a) CKM_AES_KEY_GEN but not with the published openScc but with the CardContact pkcs11 drive. The midriver is useless and will not even load in Win 11…
b) The HSM design is flawed as there is no support for CKM_AES_KEY_WRAP ( proven), the best one can achieve is a HACK using the undocumented “CreateCkAesCbcEncryptDataParams” this will only take 16 byte aligned data hence one can hack a 23 byte key though this hole… Yes as expected it fails if some undocumented max value is added, but will work for an AES CEK…
THIS IS NOT THE INDUSTRY STANDARD WAY TO WRAP A KEY…
Support for CKM_AES_KEY_WRAP is mandatory for a device that cannot actually encrypt date due to its internal buffer limitations…
c) EC support, for Sign is ONLY supported, all else is soft, which is fine. Note the none standard returned signature result, but one of the two standards for R,S , even if the industry standard is ASN.1 encoding.
d) ED for anything other than Sig is useless and so poorly documented to be un-usable…
The industry standard fully documented as JweAlgorithm.ECDH_ES_A256KW is not implement even if there are references to the related mechanisms, hence like key wrap, results in a totally unusable ECDH_ES solution, as nothing can create a AES wrapped key as there no support for the foundational AES wrap mechanism as defined in RFC 3394 AES Key Wrap Algorithm".
I have used industry HSMs for over 20 years, from the original nCipher days, and have never seen such unprofessional product as this device…
I will not bother you further, this post is simple to prevent future purchases of your product from wasting the many days I have done,
PS: I did not bother with any RSA tests as these have essentially been deprecated in modern crypto world, especially with key size constrained devices… a RSA 2048 is ~ 112 bits, totally useless…as it can be factored in ~ 8hs…
Nitro key is the little engine which could not, please be true full about the product you are selling…
Thanks and Good bye…
Then we both have a different perspective at HSMs. I started using HSMs in the old RACAL days and used devices like the good old ERACOM Protect Server Orange. nCipher at that time was nothing more than a SSL accelerator. Today we work a lot with Utimaco HSMs.
PKCS#11 is just one - but not a good - interface to access HSMs. That’s pretty much the reason why most - if not all - HSMs have their own proprietary mechanisms beside PKCS#11, in particular for key management. No HSM implements all of PKCS#11, so when buying a device - in particular a device based on constrained SmartCard technology - you would expect certain limitation. That said, the Nitrokey HSM has a focus on asymmetric crypto operations using RSA and EC. AES was added later to help with certain key management functions that are based on symmetric ciphers (in particular key derivation). It has the characteristic of a HSM, as it supports sophisticated key management mechanisms like key domains or public key authentication using n-of-m schemes. All mechanisms not even remotely supported by PKCS#11.
The native interface of the Nitrokey HSM is not PKCS#11, it’s based on ISO7816-4. OpenSC is a middleware that tries to translate the semantics of PKCS#11 into the ISO7816-4 APDU format. It does that in particular to allow applications to access asymmetric primitives on a SmartCard. It does no try to implement a full PKCS#11 interface.
OpenSC supports a variety of SmartCards and thus indicates mechanisms that might not be available in the card at hand. On the other hand a card might support additional mechanisms not exposed in OpenSC. That is one of the reasons a dedicated PKCS#11 module was developed to implement features that OpenSC - due to it’s layered design - could not support.
I try to understand your frustration, but based on your bold statements in this support forum I tend to believe that your are not looking for a constructive dialog. You may have some points, but I guess they will go unheard.
