Re: [pkcs11] PKCS#11 FIPS Indicator proposal review

[Robert Relyea <rrelyea@redhat.com>]

On 10/22/21 5:02 AM, Daniel Minder wrote:

Bob, all,

Â

Dieter and I have reviewed and discussed the proposal extensively. Here is our feedback:

Â

• Section 4.13.2: Definition of CKA_VALIDATION_LEVEL : an ULONG type fits well to specify a FIPS Level like 1,2, 3 or 4. It doesnât fit that well to specify a Common Criteria Evaluation Assurance Level which may be 4+ for example. A type CK_UTF8CHAR might fit better for CC, and for other certification schemes as well?

    CK_UTF8CHAR is probably most general. This is likely an
    informational (pass through to your UI) type interface. CK_ULONG is
    easier for matching, but CK_UTF8CHAR means we won't have to define
    any special defines for non-integer levels (but it also means it's
    likely one vendor puts '4+' and another puts '4plus') as well..

• 
  
• Table 27: Typo CA_VALIDATION_VERSION -> CKA_VALIDATION_VERSION

    ack.

• 
  
• Section 1.1.3: CKR_VALIDATION_INVALID may be misleading (in the sense âthe validation of the cryptographic module is not validâ). We suggest CKR_OPERATON_NOT_VALIDATED or CKR_OPERATION_NOT_APPROVED.

    I like both of these better than my proposed CKR_ value.

• 
  
• Error code CKR_VALIDATION_INVALID vs. validation indicators: Section 1.1.3 defines CKR_VALIDATION_INVALID as âthe requested operation violates one or more of the tokenâs validation policiesâ. Probably today, CKR_MECHANISM_INVALID is returned by the token. With the error code, the reason can be expressed more clearly. However, this supports only case 3) any non-FIPS compliant call will always fail as described by Bob in his introduction, but this error would not be returned in case 2) a special call or indicator the the current operation is FIPS compliant. Case 2) must use the FIPS indicator. Could or should case 3) return the error code and optionally use the validation indicator in addition, or can the validation indicator only be used if the operation returned CKR_OK? The description should be clear when to expect which return code or indicator.

In the case you are failing, CKR_MECHANISM_INVALID would still comply. I don't know if other vendors would want to continue using the later, or use the validation status error code to give more detail. This error code is mostly an afterthought on my part since I'm likely to just use the indicator in my token. If it's used, then when NSS updates, it will return an error related to the mechanism being unvalidated rather then unknown or invalid.

• 
  
• New section âValidation indicatorsâ: We havenât understood yet why we need to distinguish between current operation flags and last operation flags? Couldnât a single âoperation flagâ indicate the status of the last function call in a sequence C_xxxInit â [ C_xxxUpdate â ] C_xxxFinal ?

    It's not "needed" for Cxxx - CxxxFinal. It is needed for C_WrapKey()
    which no active 'operation' you can access (unless you break pkcs11
    rules and try to read the session on another thread), nor any object

• • Assume a sequence of C_Derive calls: there is no current operation, thus the last operation flag must be queried. And it must be queried immediately after each C_Derive call, otherwise it will be overwritten by the last operation flag of the next C_Derive call.

That is absolutely positively correct (for that session). I have three comments about this: 1) the application controls is sessions and access to the token, so the application knows which C_Derive operation it called on that session. 2) C_Derive also returns a key object which receives the CKA_VALIDATION_FLAG attribute that doesn't change on the second Derive, 3) C_WrapKey has the same issue, except it doesn't return a key object, so it *must* be queried right after the operation.

It is the C_WrapKey operation I am trying to solve with last. Given you need it for C_WrapKey, I see no reason not to allow it for other session queries as well. Again the application is the manager of his sessions, not one else can use his sessions without violating the PKCS #11 spec (because you need to guarrentee thread sequencing on the application level to the session...e.i. you can't call the same session twice from multiple threads at the same time).

• • 
    
  • Assume a sequence of encryption operations, where each encryption applies to large documents and thus calls C_EncryptInit followed by 1..n C_EncryptUpdate followed by C_EncryptFinal. FIPS compliance may be determined during C_EncryptInit (e.g. when selecting a key with too short key size), or during some C_EncryptUpdate (e.g. when exceeding the number of blocks for a triple DES encryption operation after a while), or during C_EncryptFinal (because the provider always returns FIPS status with the final operation). For most operations, the FIPS state will not change with C_EncryptUpdate calls. And which/how many applications will query FIPS status after every single call to the crypto provider? Thus: Shouldnât we simplify the FIPS status handling by leaving out the current operations flag, and accept that the FIPS status can only be queried after the final operation?

Hmm that's interesting. You aren't arguing for removing last state, you are arguing for removing current state.

I think there's a slight complication with overlapping operations (C_EncryptDigest). but that complication exists in the current state as well.. I think my only objection is my current prototype implementation in NSS is able to tell you that your current ssl connection has all FIPS indicators because I'm able to query the current ssl state (before the connection finishes), so there is a real world application use for the current state.

• • This assumes that an ongoing operation stays non-conforming until it is finished once it gets into non-conforming state; but it seems safe to assume this.

    I'm pretty sure it's required.

• • 
    
  • On the other side we have message-based functions, where a single C_MessageâInit and C_MessageâFinal encloses multiple message operations; and where FIPS compliance would rather be queried at the end of a message encryption, but not after the C_Final call (C_Final will probably âneverâ be called for e.g. an OCSP responder up-and-running 24x7). Thus a last-operation flag linked to a C_Final call is not providing the necessary information, we need the current-operation flag.

    yup, that's the current issue I also have with my SSL FIPS
    indicators.

• • 
    
  • Ergo: expecting that an application queries the current-operation flag for some calls/operations but the last-operation flag for other calls/operations may be confusing and is error prone. Canât we just define a single flag which is set by each function call, i.e. the same indicator flag for C_...Init, C_...Update , C_...Final, C_Derive, message based functions, etc. Itâs then up to the application [developer] to check the FIPS flag either after every single call (to recognize a Non-FIPS operation already during Update) or at the end (i.e. after C_Final or after the last message block for a message-based operation) or after the only operation (C_Derive).

    Unfortunately I think we've just argued that we need both and have
    to deal with the potential ambiguity.

• • 
    
• For optimization purposes an API might not call the token for every API call (examples are C_...Init, or C_...Update if the data size does not fill an algorithmâs block). Since the token must tell if an operation is compliant the API certainly cannot return CKR_VALIDATION_INVALID and the current operation flag also shows that itâs compliant (or there is an indicator âcanât tell yetâ). The specification must not make any assumption when the failing validation is returned, except for that the indication is correct when the operation has been completed.

So in practice the CKR_VALIDATION_INVALID* call and the FIPS indicator will likely be mutually exclusive. That is an application that return CKR_VALIDATION_INVALID won't update the FIPS indicator because the function never executed. I envision tokens like NSS would never return CKR_VALIDATION_INVALID, but would just update the FIPS indicator. Some tokens will always return CKR_VALIDATION_INVALID for invalid mechanism, and always return FIPS indicator on (this is using 'implicit indicator method' of NIST). There may be tokens that do a mix. In that case the effect of the mechanism the was CKR_VALIDATION_INVALID would be null on the FIPS indicators.

BTW, I don't expect the application would call the API every call. It *could* in principle, but in general applications really only care if this macro operation was completed using properly FIPS validated modules. So, my SSL chaining example. NSS doesn't call the FIPS indicator every call, only when the application asks 'hey is the current thing I'm doing fips'. In the case of SSL we can query just the state of the two encryption session (and two mac session in the case on non-AEAD) and merge those into a single indicator. The FIPS Validation state flows from the key agreement to the key derive to the actual encryption (through the key's validation status flag)), making it unnecessary to query each step along the way.

Bob

*I'm still using the old name, but I like your new names better.

Â

Weâre looking forward to the next TC call.

Â

Regards,

Daniel

Â

---

Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen â Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.