In Common Criteria, there has been increasing emphasis on the evaluation of the entropy used by manufacturers in the development and deployment of their systems. The following post discusses considerations and approaches for entropy health testing.
Health testing is, of course, necessary to ensure the proper functioning of the noise being provided to the critical components of the cryptographic systems. Therefore, if a vendor is investing resources in ensuring a strongly seeded DRBG, there should be some effort expended on doing some form of health testing.
When it comes to health testing, NIST SP800-90B draft 2 has two mandatory tests that any conforming implementation will need to run: the Repetition Count test (described in section 4.4.1) and the Adaptive Proportion test (described in section 4.4.2). Both of these continuous tests are described in detail in the Special Publication, so we won’t describe them further in this post.
Lightship has published proof of concept C and Python code that vendors can customize to work into their noise source analytics. You can find that code over on our Github repository (C code, Python code). While the tests themselves are relatively trivial to implement, our value-add is that we have constructed them so that they can operate continuously. The descriptions in NIST 800-90B only consider the standalone algorithms rather than how one might actually implement this in a continuous fashion. These code samples are published as-is without any warrant of fitness, but they might provide starting points for developers to include the functionality into future certifiable products.
With NIST SP 800-90B now published, we should expect to see new requirements soon come in terms of data collection, system documentation, quantitative analysis and health testing.
For more information about approaches to collecting, decoding, health testing and making sense of your entropy sources, talk to Lightship Security.