OASIS PKCS 11 TC

FIPS 180-3 requires some indication that the current operation is running in FIPS mode. This isn't just that the algorithms are FIPS algorithms, but that the algorithms are being used in a FIPS compliant way for the given token, and the algorithms are algorithms that have the appropriate certificate. A lot of what has traditionally been handled in the module's security policy now has to exist in code. Modules can accomplish FIPS 180-3 in one of three ways: 1) Some call the indicates the current operation is running in a FIPS compliant way. 2) Any calls to the module with is outside the security policy always fails. 3) The application can query the function to see if a given operation will be FIPS compliant. In strategy 2, which is often used by hardware tokens, not changes to PKCS #11 are necessary. Failure of the operation itself inidicates it's not FIPS compliant. For NSS I needed something different. Proposal in Brief: To handle strategy 1, I propose a new FIPS indicator function C_GetFIPSStatus(). It can be called on a session to determine if the current operation is FIPS compliant. Single shot operations (like C_GenerateKey(), C_Derive(), C_UnwrapKey) return key objects. The key object will also record it's FIPS status, which can also be returned by C_GetFIPSStatus. If you use a key object that wasn't generated by a FIPS compliant method, then using that key in an operation will make the entire operation not-FIPS. More detail: I've written out a proposal, including how to incorporate it into NSS: https://docs.google.com/document/d/1Me9YksPE7K1Suvk9Ls5PqJXPpDmpAboLsrq0z54m_tA/edit I've implemented this in NSS here: https://hg.mozilla.org/projects/nss/rev/40edc4f4c1170398c1409a2c04a79fb59fe65df7 with the following differences: The state machine is on a per session class, rather than a per session bases. (class means encrypt/decrypt sign/verify/hash). The various session class states are combined as follows: unknown + unknown = unknown unknown + not fips = not fips unknown + fips = fips not fips + not fips = not fips not fips + fips = not fips fips + fips = fips Most of the time one of the states will be unknown. This varies from the global state machine in that if you C_Finalize a not FIPS operation before a FIPS operation, the state can swith from FIPS to not FIPS. session also keeps a state - last operation FIPS status. This gets on C_xxxFinal, or after a single shot operation. This is necessary to get the FIPS status of a C_WrapKey operation, which doesn't return a key object, so can't return FIPS status on that option C_GetFIPSStatus has a new type CKT_SESSION_LAST_CHECK. This is also necessary to handle non-FIPS operations on things like C_SignFinal, where the application requests too short a value from the hash function (I didn't specifically need this for NSS because NSS explicitly fails this case, but it might be necessary in other tokens). the block list is now a allow list, with the default being empty (since you need to get a FIPS validation to supply the list). This detail isn't relevant to the PKCS #11 spec as it's an implementation detail. The patch includes how NSS uses the function to rollup general FIPS compliance on a given operation (most notably SSL). Some questions for the committe: I did not try to address option 3. It seems an almost intractable problem since a FIPS compliance of a particular operation depends. My thought is you need to specify pretty much what you tell C_Initialize anyway, so your query could be C_Initialize C_GetFIPStatus C_Finalize. For NSS as a vendor supplied function, it comes from a vendor supplied interface, for FIPS it should be in the normal Function table, or in a set of FIPS specific interfaces. We need to decide. Spellings of the various states and types are certainly up for grabs at this point. What do you think about the modified state machine, and should there be cross-talk between the various states. Should the FIPS status of a key be an attribute? (and should it persist for token attributes -- for NSS I assume all token attributes are FIPS). Bob

Why would we need a new function for an FIPS indicator ? For a session could we use a flag that can be reported via the CK_SESSION_INFO ? Similarly a flag for CK_MECHANISM_INFO to indicate if the slot/token combination allows it to provide services in a FIPS 140 compatible way. Then for keys an attribute CKA_FIPS140_3 that takes an appropriate value, maybe similar to how CKA_ALWAYS_SENSITIVE works. What am I missing with the above that a new C_GetFIPSStatus() provides that the above doesn't ? Darren

On 5/27/21 2:46 AM, Darren J Moffat wrote: Why would we need a new function for an FIPS indicator ? For a session could we use a flag that can be reported via the CK_SESSION_INFO ? Similarly a flag for CK_MECHANISM_INFO to indicate if the slot/token combination allows it to provide services in a FIPS 140 compatible way. Then for keys an attribute CKA_FIPS140_3 that takes an appropriate value, maybe similar to how CKA_ALWAYS_SENSITIVE works. What am I missing with the above that a new C_GetFIPSStatus() provides that the above doesn't ? Hmm, I only thought about the attribute recently, Adding the new attribute would handle the object setting. I'll have to think about session info. It's likely we can do it with 2 flags (CKF_FIPS_OK, CKF_LAST_FIPS_OK). The rest of the document still applies, but that seems a reasonable addition (assuming we can extend CK_SESSION_INFO in a ABI compatible way). Darren

On 27/05/2021 22:50, Robert Relyea wrote: On 5/27/21 2:46 AM, Darren J Moffat wrote: Why would we need a new function for an FIPS indicator ? For a session could we use a flag that can be reported via the CK_SESSION_INFO ? Similarly a flag for CK_MECHANISM_INFO to indicate if the slot/token combination allows it to provide services in a FIPS 140 compatible way. Then for keys an attribute CKA_FIPS140_3 that takes an appropriate value, maybe similar to how CKA_ALWAYS_SENSITIVE works. What am I missing with the above that a new C_GetFIPSStatus() provides that the above doesn't ? Hmm, I only thought about the attribute recently, Adding the new attribute would handle the object setting. I'll have to think about session info. It's likely we can do it with 2 flags (CKF_FIPS_OK, CKF_LAST_FIPS_OK). The rest of the document still applies, but that seems a reasonable addition (assuming we can extend CK_SESSION_INFO in a ABI compatible way). My assumption was that adding a new flag value into the existing flags field should be ABI compatible.  A client of the PKCS#11 module that doesn't understand that flag shouldn't be confused by it. -- Darren J Moffat

On 5/28/21 1:32 AM, Darren J Moffat wrote: On 27/05/2021 22:50, Robert Relyea wrote: On 5/27/21 2:46 AM, Darren J Moffat wrote: Why would we need a new function for an FIPS indicator ? For a session could we use a flag that can be reported via the CK_SESSION_INFO ? Similarly a flag for CK_MECHANISM_INFO to indicate if the slot/token combination allows it to provide services in a FIPS 140 compatible way. Then for keys an attribute CKA_FIPS140_3 that takes an appropriate value, maybe similar to how CKA_ALWAYS_SENSITIVE works. What am I missing with the above that a new C_GetFIPSStatus() provides that the above doesn't ? Hmm, I only thought about the attribute recently, Adding the new attribute would handle the object setting. I'll have to think about session info. It's likely we can do it with 2 flags (CKF_FIPS_OK, CKF_LAST_FIPS_OK). The rest of the document still applies, but that seems a reasonable addition (assuming we can extend CK_SESSION_INFO in a ABI compatible way). My assumption was that adding a new flag value into the existing flags field should be ABI compatible. A client of the PKCS#11 module that doesn't understand that flag shouldn't be confused by it. As long as we know that old modules didn't set the flag improperly. bob -- Darren J Moffat