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?

Drew Lex
  • 2,013
  • 2
  • 19
  • 24
  • I would hope you don't store anything used for authentication in plaintext ever. – Ramhound Jun 28 '12 at 14:15
  • @Ramhound How do you store your SSL server and SSH server secret keys? – curiousguy Jun 28 '12 at 15:02
  • @curiousguy - He is asking about user level authentication. This means pins or passwords. – Ramhound Jun 28 '12 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 '12 at 17:45
  • I removed my answer @DrewLex since I misinterpreted your question. I don't have a definitive answer for you. However, note that in the FIPS 140-2 reference that "Authentication data within a cryptographic module shall be protected against unauthorized disclosure, modification, and substitution." This may simply be a case of showing, by security architecture, that this clause is being upheld. – logicalscope Jun 28 '12 at 18:18
  • @logicalscope My question is in regards with the format the authentication data is entering the cryptographic module. I agree that once "within" the cryptographic boundary it has to meet the requirement you mention - protected against unauthorized disclosure, modification, and substitution. – Drew Lex Jun 28 '12 at 19:14
  • 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 '12 at 16:08

1 Answers1

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.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 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 '12 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 06 '12 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 06 '12 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 '12 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 '12 at 19:14
  • @DrewLex The protection against disclosure and modification does not have to rely on cryptography (though I would expect it to be involved more often than not). If you design an HSM where authentication data is stored in plaintext, that's ok. (Anyway cryptography will ultimately rely on some secret key which itself is not encrypted and which is inside the module.) – Gilles 'SO- stop being evil' Dec 13 '12 at 19:21