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. _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
