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.


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.