3

Do passwords (or PINs) used for authentication of operators of a cryptographic module have to be protected (encrypted) when entered into the FIPS140-2 defined cryptographic boundary? Are the requirements for entry of PINs and passwords equivalent for all FIPS140-2 security levels?

Improve this question
7
  • I would hope you don't store anything used for authentication in plaintext ever.
    – Ramhound
    Jun 28, 2012 at 14:15
  • @Ramhound How do you store your SSL server and SSH server secret keys?
    – curiousguy
    Jun 28, 2012 at 15:02
  • @curiousguy - He is asking about user level authentication. This means pins or passwords.
    – Ramhound
    Jun 28, 2012 at 15:11
  • 1
    @Ramhound FIPS140-2 seems to allow CSPs (which seems to include authentication data) to be stored in plaintext within the cryptographic boundary.
    – Drew Lex
    Jun 28, 2012 at 17:45
  • 1
    @Ramhound "He is asking about user level authentication. This means pins or passwords." Yes, obviously. How would you manage your server SSL and SSH keys?
    – curiousguy
    Jun 29, 2012 at 16:08

1 Answer 1

Reset to default
1

Yes, authentication data can be entered in plain text. That is, in fact, usually the case: a very common type of authentication is that a human types the password on a keyboard or similar device. In most settings, there would be no way to protect the password: you would need another cryptographic module for that, which in turn you'd want to certify under FIPS 140…

You must take care that the authentication data cannot be leaked at the point of entry. This is embodied in rules about feedback provided to the operator entering the data (§4.3.3):

Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password). Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism.

The security level does not affect the rules regarding entry of authentication data, nor even the rules about authentication strength (at most 10-6 probability of one random attempt succeeding, at most 10-5 probability of succeeding with random attempts in under 1 minute). The security level only affects what kinds of authorization model the authentication data must be provided for (none at level 1, role-based at level 2, identity-based above that).

There are no additional requirements when initializing the authentication data (as in setting a password).

Once entered into the module, the requirements on authentication data vary depending on the security level (§4.6.1):

  • Level 1 doesn't put any requirements on authentication data even if it is present.
  • Level 2 requires that all attempts to access or modify authentication data be logged.
  • Level 3 requires that authentication data be communicated through a trusted mechanism.

No cryptography is required at any point: the authentication data can be protected by physical means alone. The requirements on stored authentication data are (from §4.3.3):

Authentication data within a cryptographic module shall be protected against unauthorized disclosure, modification, and substitution.

Improve this answer
6
  • You were absolutely correct. I overlooked this key piece of information "when entered into the FIPS140-2 defined cryptographic boundary." If outside the boundary, while still on the device it must not be plaintext, but if within the boundary, plaintext IS acceptable.
    – Purge
    Nov 29, 2012 at 22:11
  • I believe is worth mentioning that requirements of section 4.6.1 are only applicable if the module's operational environment is modifiable (software and firmware modules only). Additionally, how can a trusted path or mechanism be claimed without using encryption (FIPS140-2 Section 1.3 paragraph #3, PDF page 2)?
    – Drew Lex
    Dec 6, 2012 at 17:39
  • @DrewLex Indeed, §4.6.1 only applies when authentication data may travel around: if the entire software system is evaluated, then the only way authentication data could be transferred is by taking it outside the module boundary. Regarding trusted paths, when they are inside software, they can be logically isolated. For example, a trusted path can be established by dataflow analysis on the source code, or by a combination of dataflow analysis to show that legitimate paths do not carry authentication data and reliance on an MMU to establish that no illegitimate paths are possible.
    – Gilles 'SO- stop being evil'
    Dec 6, 2012 at 18:11
  • It seems that in FIPS140-2 DTR is implied that the authentication data is protected - TE03.22.01: The tester shall review the vendor documentation that describes the protection of authentication data. The tester shall verify that the documentation describes how the data will be protected against unauthorized disclosure, modification, and substitution. \n How can one guarantee that the "authentication data" (i.e. PIN, passwords,biometrics) meets these requirements if not entered encrypted?
    – Drew Lex
    Dec 13, 2012 at 19:08
  • In TE03.22.02 "modified" authentication data is entered and the module is supposed to be able to detect the modification. This tells me the requirements for protection goes beyond "within the module", and it includes the authentication data as it enters the module.
    – Drew Lex
    Dec 13, 2012 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .