On 2010-08-22 16:44 PDT, Brian Smith wrote: > When NSS Softoken is in FIPS mode, it refuses to create keys with > C_CreateObject.
What means that it refuses to import secret or private key material that is being kept "in the clear" outside of the security module boundary into the security module, and treat it as if it had always been securely kept inside that boundary. The idea of FIPS mode is that secret keys and private keys NEVER leave the boundary of the security module "in the clear" (in plain form) Ideally they are generated or derived inside that boundary, and NEVER leave that boundary, except possibly wrapped in the public key that has come from another security module (key transport). > The same method works fine in regular (non-FIPS) mode. Sure. If you're not trying to keep sensitive keys in a secured boundary, then the API doesn't need to try to remind you to do so. > But, it is possible to achieve the exact same effects using either any of > the procedures outlined below. So, what is the motivation for prohibiting > the key creation with C_CreateObject in FIPS mode? Ultimately, the > application, not Softokenm is responsible for enforcing the FIPS key > management requirements. It is precisely to get developers who are unaware of the objectives of FIPS mode protections to stumble over these obstacles and ask these questions, and learn about the FIPS mode objectives. The real question is: If you care about FIPS mode, then why do you have secret or private key material outside of a security module boundary, in the clear, that you are now trying to import into such a boundary? The real problem began LONG before the point where you ran into a problem importing it. It began at the point where you somehow got that key material out of the boundary in the first place. > Similar reasoning applies to using the enforcement of > CKA_SENSITIVE/CKA_EXTRACTABLE. There appear to be ways of circumventing > it as well. It's all about making it difficult enough that people start to ask "why is this obviously more difficult than the casual developer thinks it must be?" > Thanks, Brian There are lots more methods than the ones you described. Is some sense, this shows that the inventors of PKCS#11 were not as careful as (say) the inventors of ANSI X9.17-1985 to define their system to avoid circumventions. Perhaps that's unfortunate, but I think it merely shows that the purpose of FIPS mode is not to make it impossible to circumvent, but merely to make it difficult enough that people ask "why is it necessary to circumvent?" and then learn that the answer is "because if you're trying to circumvent it, you're fundamentally not doing things in a FIPS compliant way. If you were doing things in a FIPS compliant way, no circumvention would ever be necessary." -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
