Nelson B Bolyard wrote: > 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?"
Thank you. That makes a lot of sense. My understanding is that there doesn't really need to be a difference in the way the FIPS mode works compared to the non-FIPS mode, as long as the Security Policy document only documents usage of the API that would result in FIPS-140-compliant behavior. For example, the FIPS mode *could* allow C_CreateObject to import keys from outside the module in plaintext form, as long as it wasn't documented as being allowed in the Security Policy document. That is why Softoken allows the application to do some unsafe things but not others. > 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." Interestingly, I saw at least one older version of Softoken had a security policy with this statement in the security rules: "In the FIPS Approved mode of operation, the cryptographic module shall enforce rules specific to FIPS 140-2 requirements." This kind of statement would seem to put Softoken on the hook for making sure that non-conformant actions were impossible, which is quite unrealistic when you consider that Softoken operates in the same address space as the application. I guess that's why more recent versions of Softoken have removed this statement from their security policies and modified similar ones to offer much weaker guarantees. I noticed that NIST SP800-38D, which defines the GCM mode of operation, places strict requirements on the management of IVs for that mode in FIPS-140-validated cryptographic modules--AFAICT, much stricter than required for IV management in other modes like CBC. I am having trouble seeing how the draft PKCS#11 CKM_AES_GCM mechanism can be implemented in a way that enforces the requirements given in SP800-38D. Right now I am thinking that a FIPS-140-compliant AES-GCM implementation for Softoken would require a new mechanism to be defined. (I noticed that Microsoft's AES-GCM implementation, with an API similar to CKM_AES_GCM, is specifically listed as non-conformant on their FIPS-140 certificates.) Also, new mechanisms are required for TLS 1.2. Do you think these new mechanisms should attempt to enforce proper key management in a way that is analogous to the way that NIST seems to want cryptographic modules to enforce proper IV usage in their AES-GCM implementations? Such an interface would be much different than the interface for the SSL 3.0 and TLS 1.0/1.1 mechanisms. Regards, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
