3

I've recently been working on a number of A&A tasks for the RMF for a US Government entity, and I'm having a hard time properly understanding the IA-7 control of NIST SP 800-53 and the supplement guidance and 800-53A isn't providing me the clarity I require. For reference, this is the Control Description for IA-7:

The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.

Specifically, I'm having a hard time wrapping my head around what "authentication to a cryptographic module" entails. How does one authenticate to a module as opposed to simply have the necessary access rights to the module on the system? For a bit of background, we primarily utilize openssl, but we also leverage urandom and pgcrypto.

5

Waking the zombie at my own peril and for the benefit of people looking to understand this control. I did a fair amount of research on the subject and was able to find a pretty definitive answer. Stay with me because it isn't short, but it's pretty definitive.

As best I understand it, if you are an implementor of a cryptographic control module that provides an authentication mechanism or if your system provides access to a cryptographic control module that provides authentication then you must meet the authentication requirements "...of applicable laws...standards..." etc. This reference is calling out the requirements in FIPS 140-2 which refer to a human operator interacting with a FIPS 140-2 compliant cryptographic control module.

4.3.3 Operator Authentication Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module and to verify that the operator is authorized to assume the requested role and perform services within that role. Depending on the security level, a cryptographic module shall support at least one of the following mechanisms to control access to the module:

Role-Based Authentication: If role-based authentication mechanisms are supported by a cryptographic module, the module shall require that one or more roles either be implicitly or explicitly selected by the operator and shall authenticate the assumption of the selected role (or set of roles). The cryptographic module is not required to authenticate the individual identity of the operator. The selection of roles and the authentication of the assumption of selected roles may be combined. If a cryptographic module permits an operator to change roles, then the module shall authenticate the assumption of any role that was not previously authenticated.

Identity-Based Authentication: If identity-based authentication mechanisms are supported by a cryptographic module, the module shall require that the operator be individually identified, shall require that one or more roles either be implicitly or explicitly selected by the operator, and shall authenticate the identity of the operator and the authorization of the operator to assume the selected role (or set of roles). The authentication of the identity of the operator, selection of roles, and the authorization of the assumption of the selected roles may be combined. If a cryptographic module permits an operator to change roles, then the module shall verify the authorization of the identified operator to assume any role that was not previously authorized.

...so that's what this rule is talking about.

This control is only applicable if you're providing authentication to the cryptographic module for purposes of managing the cryptographic module. Evidence that it is not applicable in other cases can be found in a STIG (although not easily)...

https://www.stigviewer.com/stig/application_security_and_development/2018-09-13/finding/V-70159

Details Check Text ( C-70635r1_chk ) Review the application documentation and interview the application administrator.

Identify if the application provides access to cryptographic modules and if access is required in order to manage cryptographic modules contained within the application.

If the application does not provide authenticated access to a cryptographic module, the requirement is not applicable.

Review and identify the cryptographic module. Refer to the NIST website listing all FIPS-approved cryptographic modules.

It seems like an uncommon use case in the private sector but may be more common in government sectors like DoD.

  • I suppose my question to that would be what is considered authentication to the module specifically? Let's use openssl as an example. Is changing the config file for the ciphers going to be authentication to the module? Is running openssl commands to implement the crypto on a human, user-account considered authentication to the module? Based on that STIG, what if the application allows the user to change the SSH ciphers in OpenSSH? That's a somewhat common feature. Would that be applicable? – scjohnson Aug 5 at 12:43
1

A "cryptographic module" is defined as hardware, firmware or software that implements cryptographic functions such as encryption, decryption, digital signatures, authentication techniques and random number generation. So as you can see this is more vague and encompasses more than the technologies you mention. Also to be NIST compliant, the technologies that fall under this category need to be validated under FIPS, NIST has a validation program for cryptographic modules which you can find here: http://csrc.nist.gov/groups/STM/cmvp/index.html And a list of NIST validated cryptographics modules here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2017.htm

  • I understand the definition of the cryptographic modules; my question is relating to what is meant by "authentication" to a cryptographic module. I cited specific modules we use to potentially help with an example. I don't understand what qualifies as "authentication" to a module. Is it file access? Do certain modules allow for some type of additional login mechanism? – scjohnson Jun 5 '17 at 13:39
  • Ok, I think I understand your question now. For example, if you use openSSL then a cryptographic module would be your CAs. In this case, authentication to your servers where your CA are hosted need to be FIPS compliant. You can find more information on this PDF. nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf – Kotzu Jun 5 '17 at 20:44
  • I don't think that's necessarily correct. The cryptographic module is openssl, which specifically in our case is the Red Hat Enterprise Linux 6.6 OpenSSL Module. The CA (I'm assuming this is a Certificate Authority) is only an entity that provides a level of trust. I discussed this with a coworker and he said that this control effectively meant that you're required to use a module for authentication. I feel as if this is worded to somehow authenticate to a module itself. – scjohnson Jun 7 '17 at 13:58
  • I'm not familiar with RHEL OpenSSL so I can't say. I mentioned the CAs as an example only as CAs are also a cryptographic module. In your particular case I would look at making your server compliant and also wherever you are storing the private key used for your SSL connections (if it is a different place). You are right that authentication is a part of it. It is mentioned in the FIPS standard I linked to, but there is more to it than just authentication, for example you also need authorization roles. – Kotzu Jun 7 '17 at 20:09
  • I don't understand how a CA is cryptographic module. It's a trusted-related entity; a CA leverages cryptography, such as signing a certificate, but it is not a module itself. Regarding the security of keys, implementation of TLS, etc. those are all covered under 800-53, but under different controls. I'm still just stuck on this concept of what the intent/meaning of authentication to a module means. – scjohnson Jun 9 '17 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.