Thanks once again for detailed explanation of NSS infrastructure. > Now, one well known technique, used by applications that do not wish to > achieve FIPS compliance but are nonetheless constrained (for some reason) > to use a FIPS crypto module, is this: generate a symmetric key in the > FIPS module. Use it to encrypt the plain symmetric key that the application > holds, just as if that symmetric key were mere data. Then use it a second > time to unwrap the encrypted key into the module. Then discard the symmetric > key. This gets around the requirement of the FIPS module that > the key must be imported by unwrapping it. Most (not all) FIPS modules > allow this.
I have generated symmetric key in NSS FIPS module. I have another predefined plain symmetric key (AES/CBC/NoPadding) in my application. Now I want to encrypt (wrap) the plain symmetric key with the generated one and then to unwrap it into the module. I use SunPKCS11 jce provider in order to achieve this target. Can someone tell me whether I should use Cipher.wrap and Cipher.unwrap API, and if so, what are the supported algorithms for ciphers in WRAP and UNWAP modes by SunPKCS11 provider and how the unwrap function should put the key into the module (I didn't find any relation between Cipher and PKCS#11 module)? Perhaps there is no other way than using JSS? If JSS is the only solution, what is the right way in JSS to unwrap the key into the PKCS#11 module. Thanks in advance for any assistance. -----Original Message----- From: Nelson B Bolyard [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2008 18:31 To: mozilla's crypto code discussion list Subject: Re: Importing symmetric keys to NSS from Java code Yevgeniy Gubenko wrote, On 2008-08-07 07:12: > Thanks a lot for your answer. > I still need some clarifications: > 1. If I understand you right, when I have to use a predefined persistent > key to do a crypto with it, there is no way, other than importing the key > into a PKCS#11 token as a token object in NSS db? If the key is held outside of the token in wrapped form, you could unwrap it, creating a session object, each time your application runs. > (Even if the key is an input from third party application). So, I wonder. What is your objective here? Is it: a) to have a fully FIPS compliant application? or b) to have an application that works with some FIPS compliant crypto device, but is not necessarily a fully compliant application, and may attempt to "get around" the restrictions imposed by the FIPS device in order to "work"? A FIPS compliant application never holds any plain (not wrapped) keys except public keys (e.g. RSA). Any plain keys, other than public keys, only exist inside a FIPS module, at all times. An application that holds a plain (not wrapped) symmetric key outside of a FIPS token is simply not a FIPS compliant application, not even if it uses a FIPS token to do the encryption and decryption work. Such an application doesn't become FIPS compliant merely by using a FIPS certified crypto device. Given that such an application is not FIPS compliant, one wonders, what is the value of using a FIPS compliant device with it? If FIPS compliance is not the objective, then it is much easier to use a crypto module that does not impose the FIPS requirements. (NSS can operate either in FIPS mode or not, as you wish.) > 2. As you noticed, in FIPS mode symmetric keys may not be imported in > plain non-encrypted form. But if they should be encrypted before the > import act, there must be another key to encrypt the imported key with > it. But this key also must be stored in PKCS#11 token, right? If So, it > should generated by NSS or be imported by itself? Well, generally the unwrapping key will be either a private key (e.g. RSA) or a symmetric key (e.g. AES). That key has to get into the token somehow. It can be generated in the token, or it can be unwrapped into the token (which necessitates yet another unwrapping key), or it can be derived in the token (e.g. Diffie Hellman). The last of those options (derivation) is generally only relevant when the key is being transported from one token to another (which, in a true FIPS environment, is the only way that keys are ever transported). Now, one well known technique, used by applications that do not wish to achieve FIPS compliance but are nonetheless constrained (for some reason) to use a FIPS crypto module, is this: generate a symmetric key in the FIPS module. Use it to encrypt the plain symmetric key that the application holds, just as if that symmetric key were mere data. Then use it a second time to unwrap the encrypted key into the module. Then discard the symmetric key. This gets around the requirement of the FIPS module that the key must be imported by unwrapping it. Most (not all) FIPS modules allow this. (I have often wondered why the FIPS specifications do not explicitly forbid this. It would be possible to define the wrapping and unwrapping functions in a way that made it difficult to do this using a technique similar to the block formats used in PKCS#1.) > 3. Some other related question: when I try to export some symmetric Key > from NSS to datafile by: > symkeyutil -E -n testaes -k aestest.txt -d . > I get an exception: symkeyutil: Failure to load dynamic library. > > Any idea what can be wrong? Maybe my NSS libraries should be located in > the some specific folder which is transparent to symkeyutil command? Sounds like you're missing some shared libraries. All of NSS's shared libraries must be installed together in the same directory. NSS looks for the dynamically loaded components in the same directory as the rest of NSS's shared libraries. I'd guess you're missing some freebl library. This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
