ICMC: Questions to CMVP (NIST/CSEC) on ISO 19790 Standard, 140-4 or Other

 Carolyn Finch, Manager, CMVP, CSEC
Randall Easter, NIST, Security Testing, Validation and Management Group
Allen Roginsky, Mathematician, NIST
Sharon Keller, Director, Cryptographic Algorithm Validation Program (CAVP), NIST

This panel is entirely questions and answers. I'll do my best to capture them.

Q: About bug fixing and patches. Is there an expedited way, once we get our validation, if there's a non security patch, is there a non-painful/easy way for us to update the validation?

A: Randy: Yes, we have a process, but whether it's painless or not... Even if the changes are not security relevant, you will have to go back to the lab. They will decide if it is security relevant or not, and they can do an electronic submission to NIST. It may require re-doing your algorithm testing and updating your certificate.  If there are no issues, we can usually do the update within a week - once we get the paperwork from the lab.

Q: What happens with a datacenter that is always doing critical functions, it can never give up. How can they do more tests?

A: Randy: If there is critical work being done, this can be deferred until the next time period. It doesn't say "after 42 deferrals you have to interrupt work".  There may be time when the processor is doing non crypto, then the checks can be run. The processor, in my experience, is not 100% busy on crypto.

Q: So, it can be indefinite?

A: Randy: Yes.

Q: Will CAVP now be testing and verifying all of the SHALL statements? Or is that a documentation thing?

A:  Sharon: CAVP tests all the things that are testable.  Back in the day, they all just gave tests for the algorithm - but then things got more complicated, like making sure vulnerabilities aren't introduced. For example, it's a good thing if the IV is never repeated, but that thing is not testable.

Randy: One good example is 800-90A. There are quite a bit of SHALLs in there, but there are some things that are difficult to test, so thing fall through the cracks. 

Q: In CC, we have the concept of Flaw Remediation. There are sometimes fixes we can make judegement calls ourselve. The time and money it costs to go back to the lab for FIPS makes it prohibitive for us to maintain validation

A: Randy: I  can't speak to CC, but once you open the box to make changes, then we need the lab to validate you only changed what you said you changed.  Not every change has to be revalidated, there can be judgment there.  This has been the policy in CMVP since 1995, every change has to be verified by the lab.  My experience in development, it's possible to think you've only made a small change, only later discover that it had unforeseen consequences.

A: Moderator: Working at a lab that does CC, there are vendors that abuse Flaw Remediation.

[VAF: Note: who better to judge how relevant a change is, than the developers who are intimately familiar with the codebase?]

Q: Is there a rough estimate when ISO 19790 will be adopted?

A: Randy: I honestly do not know. Hopefully mid next year, but just don't know. There will be a transition date from FIPS 140-2. But we don't know how long that will be. In the past, it was a 6 month transition period, but depending how this goes - we may need more time?

Q: Given the last public review of FIPS 140-3 was more than 5 years ago, are you ready to go forward with this standard?

A: Carolyn: This is a different process. The ISO process is different.  They don't have that type of review.

Randy: We could have a review of sorts about whether or not we want to move to the ISO standard. We won't pick up the old FIPS 140-3, as there are no DTRs and there won't be. The only path forward is with ISO 19790.

Q: Randy mentioned earlier that we'll still have Implementation Guidance. The current IGs are getting very large and difficult to navigate. How will this work with an international standard?

A: Randy: We work with Canada already and have a non-binding agreement with the Japanese guidance. We circulate the guidance with the labs before we post. The guidance is big, because we've been using FIPS 140-2 for nearly 13 years. It's only large because time has gone on for so long.  As the program has grown, the vendors and the users have gotten more sophisticated and therefor require particular guidance to address.  Hopefully we'll refresh more often and be able to better manage this.

Q: If I went down the ISO road right now, and in 18 months from now I'm ready to validate - but the new standard hasn't been adopted, yet, I won't pass FIPS 140-2, will I?

A: Randy: That's right. You could get this validated by JCVP, but the US doesn't recognize this standard at this time.  We would like a decision to get made. Yes, I said that last year, too.

Q: Elliptic Curve Cryptography has  come up significantly over the last year, particularly around NSA Suite B. Do you have plans to standardize any other curves that did not come from the NSA?

A: Allen: I am not aware of any work in this area. I am not aware of any weaknesses in the current curves. In general, one is good enough, the strength is not in the curve (as long as it meats the requirements) - the strength is in the key. Some are over the binary fields, some are over the primary fields. You can choose one or the other.  One problem with ECC is with the DUAL ECDRBG algorithm.  The problem is not with EC, but is in this particular algorithm. There was a guard in EC to protect against this, but you can't stop a problematic implementation or use.  There are no known issues with the existing curves.

Q: Our hardware now has partial implementations of crypto algorithms. We have software that can do the rest and work on the older processors, so it doesn't require the hardware but will use it if it's there.

A: Carolyn: If it can do everything in software, it's not a hybrid module.

Q: We had anticipated RSA 4096 being approved, but now it isn't.

A: Allen: It has been in FIPS 186-2, but it is no longer there. It is not allowed now for signature generation. The reason is to facilitate the transition to EC. It's very difficult to be sure that all of the floating point arithmetic is done correctly when you're dealing with these numbers. It can be done, but it's error prone. The decision was made to move to technology where the keys are shorter, like in EC. Some people have complained about this, but this is the decision. I think it's the correct one.

Q: Do you know of anything in the ISO standard that will impact current validations?

A: Randy: There is nothing that is retroactive. Existing validations should stand. New modules, though, will have to meet the new requirements once it's in place.

Q: ISO being international, but you haven't mentioned CAVS. There's no requirement that they are international.

A: Randy: It's an international standard, but CAVP will still be a US program. We'll be using an international standard. We're working on an ISO standard on how to do algorithm testing.