Re: FIPS 140-2, PRNGs, and entropy sources
On Mon, Jul 09, 2007 at 04:08:33PM -0600, Darren Lasko wrote: However, it seems pretty nebulous about how they expect you to measure the number of operations required to compromise the security of the key generation method. Do you know what kind of documentation the labs require? The requirements are broadly worded, which means that just about any detectable security problem in the RNG seeding should result in the module being non-compliant. This broad wording also makes formulating (and evaluating) arguments for compliance with this requirement fairly difficult. The entropy requirements in section 8 of SP800-90 are (sadly) not enforced (as per IG 1.12). There is no CMVP-wide requirement for describing the computational resistance to attack of the RNG seed using min-entropy, though this entropy measure is well suited to the task. (Should I perform some sort of ritual to ward off the If it's not Shannon entropy, it's not entropy discussion?) An excellent way of approaching these requirements is to: 1) Understand the underlying physical process that produces uncertainty, and develop a statistical model for this process. 2) Use this statistical model to calculate the min-entropy of the source. 3) Test bulk data output from your system to verify that the data supports your min-entropy estimate. It can be quite difficult to produce this style of argument (and in some cases not feasible, as in the case where the vendor is using an RNG from another company). In any case, I suspect that you'll be well served by doing as much of this process as you can (in coordination with your testing lab) and hope that CMVP agrees with your reasoning. Sadly, there has been no firm guidance from CMVP that really tells the labs precisely what CMVP expects to happen. Is the NIST Statistical Test Suite sufficient for evaluating your entropy source, and will the certification labs accept results from the STS as an assessment of the entropy source? sts does a fairly good job at testing to see if the RNG under test produces data that appears to be statistically random. If you know a priori that your seed information is not full entropy, then you don't gain much by passing the seed data through sts, as the sts testing result will almost certainly be a 'fail, perhaps spectacularly so. Of course, if you pass almost any seed data through a cryptographic process, it will look statistically random, and will pass sts testing. This pass is also meaningless, as you could have effectively 0 min-entropy, and still pass sts testing. As a practical matter, I view passing sts testing with some suspicion. In my experience, entropy sources with perfect statistical properties are rare, but inclusion of cryptographic processing within the seeding process is common. As such, a passing sts test result is more likely to mean that the data has been cryptographically processed (and thus the test results are meaningless) than the seed inputs are full entropy. Additionally, sts is easy to misuse, and it seems that many users of the tool don't read through the SP800-22 document prior to using the tool. As a result, sts users often select some fairly odd testing parameters that yield results that are not statistically meaningful. Recent versions of sts catch many of these problems, but not all of them, so it's still important to read through the SP800-22 document prior to using the tool. Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: FIPS 140-2, PRNGs, and entropy sources
On Sat, Jul 07, 2007 at 10:53:17PM -0600, Darren Lasko wrote: 1) Can a product obtain FIPS 140-2 certification if it implements a PRNG from NIST SP 800-90 (and therefore is not listed in FIPS 140-2 Annex C)? If not, will Annex C be updated to include the PRNGs from SP 800-90? The PRNGs in SP800-90 are listed in the current Annex C (see item #6 on page 4; this occurred in January of this year). http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf There is no algorithm testing for the SP800-90 RNGs yet, but they are allowed for use in the approved mode of operation because of IG 1.10 (http://csrc.nist.gov/cryptval/140-1/FIPS1402IG.pdf). You'll also want to read IG 1.12, which directly pertains to the testing that is required to test the vendor's assertion that they have a compliant SP80-90 RNG. 2) Does FIPS 140-2 have any requirements regarding the quality of the entropy source that is used for seeding a PRNG? Yes. The requirement imposed by FIPS 140-2 (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf) are in section 4.7.2: Compromising the security of the key generation method (e.g., guessing the seed value to initialize the deterministic RNG) shall require as least as many operations as determining the value of the generated key. (which would apply to any RNG output that became a key) and in section 4.7.3: Compromising the security of the key establishment method (e.g., compromising the security of the algorithm used for key establishment) shall require at least as many operations as determining the value of the cryptographic key being transported or agreed upon. (which would apply to any RNG output that is used in a security relevant way in a key establishment scheme) Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NCipher Takes Hardware Security To Network Level
In fact, if you're clever, you can manage to not trouble yourself to get the key-management, etc. certified, getting only the simple, symmetric-cipher stuff run through the process. You can, but that doesn't mean that it's ok. Key management is explicitly covered under FIPS 140-2. If you have an underlying FIPS 140-2 module doing the basic low level crypto, and then have (crypto based) key management performed outside the module boundary, the larger system is not a FIPS 140-2 module, FIPS 140-2 compliant, or appropriate for the protection of sensitive but unclassified information within a federal agency without a separate FIPS 140-2 validation of the larger module. The government will still buy your encryption devices (FIPS-140 certified) That will greatly depend on the sophistication of the agency concerned. The US Forest Service (for example) may not have the level understanding of the FIPS 140-2 standard that the US Navy has. Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote: In fact they wouldn't even validate Crypto++ as a static library despite an earlier verbal agreement that a static library was ok. It had to be turned into a DLL at the last moment (i.e. during the review phase). That's unfortunate. The answer as to the static vs dynamic library issue seems to vary according to who at NIST reviews the report. I've never understood NIST's general objection to static libraries. (We wanted to avoid making a DLL from Crypto++ since it has so many algorithms. With a static library the linker would only bring in the algorithms you use, but a DLL has to contain a pre-selected set of algorithms. I ended up putting only FIPS Approved algorithms in the DLL, and made a second static library that contains only non-Approved algorithms, so that both could be used together.) So, having said that, I can say that pulling out bits of the evaluated module won't fly. All of it would have to go in, or none of it. Further, the module needs to have some way of checking its authenticity (for the operating environment area requirements) and its integrity on power up. As such, you'll either need to be able to locate the module within the resulting executable, or verify the entire resulting executable. Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification
On Fri, Sep 05, 2003 at 01:32:21PM -0400, Anton Stiglic wrote: If I'm not mistaken, this would be the first free, open-source, crypto library that has FIPS 140 module certification! I believe that this is incorrect. The two open-source projects that I'm aware of that have FIPS 140 certs are The Crypto++ Library, (cert 343, issued today) and The Mozilla project's NSS, which was certified by SUN under FIPS 140-1, levels 1 and 2. (certs 247 and 248). Josh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
