Entropy Documentation - commoncriteria/pp-template GitHub Wiki
18 January 2024
For TOEs that use entropy sources, NIAP requires that PPs include an Appendix describing the requirements for documenting and assessing these entropy sources in an Entropy Assessment Report (EAR). For PP-Modules, the Appendix generally refers to the Base PPs. For technology types that use entropy, PPs and cPPs must include an Entropy Documentation and Assessment Appendix.
This Appendix must be manually declared and defined among the Appendixes. It generally appears after the ECD Appendix, so it is often Appendix D or E.
These Appendixes can be largely boilerplate, but should be tailored to the specific technology type when it makes sense. This is what the Entropy Documentation and Assessment Appendix for the NDcPP 3.0e (published December 2023) would look like if it were written in NIAP XML:
<appendix id="apndx-entropy" title="Entropy Documentation and Assessment">
This appendix describes the required supplementary information for each
entropy source used by the TOE.<h:p/>
The documentation of the entropy source(s) should be detailed enough that, after
reading, the evaluator will thoroughly understand the entropy source and why it
can be relied upon to provide sufficient entropy. This documentation should
include multiple detailed sections: design description, entropy justification,
operating conditions, and health testing. This documentation is not required to be
part of the TSS.
<section id="sec-ent-design" title="Design Description">
Documentation shall include the design of each entropy source as a whole,
including the interaction of all entropy source components. Any information that
can be shared regarding the design should also be included for any third-party
entropy sources that are included in the product.<h:p/>
The documentation shall describe how unprocessed (raw) data was obtained for
the analysis. This description shall be sufficiently detailed to explain at what
point in the entropy source model the data was collected and what effects, if any,
the process of data collection had on the overall entropy generation rate. The
documentation should walk through the entropy source design indicating where
the entropy comes from, where the entropy output is passed next, any post-processing
of the raw outputs (hash, XOR, etc.), if/where it is stored and finally,
how it is output from the entropy source. Any conditions placed on the process
(e.g., blocking) should also be described in the entropy source design. Diagrams
and examples are encouraged.<h:p/>
This design must also include a description of the content of the security
boundary of the entropy source and a description of how the security boundary
ensures that an adversary outside the boundary cannot affect the entropy rate.<h:p/>
If implemented, the design description shall include a description of how third-party
applications can add entropy to the RBG. A description of any RBG state
saving between power-off and power-on shall be included.
</section>
<section id="sec-ent-justification" title="Entropy Justification">
There should be a technical argument for where the unpredictability in the
source comes from and why there is confidence in the entropy source delivering
sufficient entropy for the uses made of the RBG output (by this particular TOE).
This argument will include a description of the expected min-entropy rate (i.e. the
minimum entropy (in bits) per bit or byte of source data) and explain that
sufficient entropy is going into the TOE randomizer seeding process. This
discussion will be part of a justification for why the entropy source can be relied
upon to produce bits with entropy.<h:p/>
The amount of information necessary to justify the expected min-entropy rate
depends on the type of entropy source included in the product.
For developer-provided entropy sources, in order to justify the min-entropy rate,
it is expected that a large number of raw source bits will be collected, statistical
tests will be performed, and the min-entropy rate determined from the statistical
tests. While no particular statistical tests are required at this time, it is expected
that some testing is necessary in order to determine the amount of min-entropy
in each output.<h:p/>
For third-party provided entropy sources, in which the TOE developer has limited
access to the design and raw entropy data of the source, the documentation will
indicate an estimate of the amount of min-entropy obtained from this third-party
source. It is acceptable for the developer to “assume” an amount of min-entropy,
however, this assumption must be clearly stated in the documentation provided.
In particular, the min-entropy estimate must be specified, and the assumption
included in the ST.<h:p/>
Regardless of the type of entropy source, the justification will also include how
the DRBG is initialized with the entropy stated in the ST, for example by verifying
that the min-entropy rate is multiplied by the amount of source data used to seed
the DRBG or that the rate of entropy expected based on the amount of source data
is explicitly stated and compared to the statistical rate. If the amount of source
data used to seed the DRBG is not clear or the calculated rate is not explicitly
related to the seed, the documentation will not be considered complete.<h:p/>
The entropy justification shall not include any data added from any third-party
application or from any state saving between restarts.
</section>
<section id="sec-ent-oc" title="Operating Conditions">
The entropy rate may be affected by conditions outside the control of the entropy
source itself. For example, voltage, frequency, temperature, and elapsed time
after power-on are just a few of the factors that may affect the operation of the
entropy source. As such, documentation will also include the range of operating
conditions under which the entropy source is expected to generate random data.
Similarly, documentation shall describe the conditions under which the entropy
source is no longer guaranteed to provide sufficient entropy. Methods used to
detect failure or degradation of the source shall be included.
</section>
<section id="s-ent-health" title="Health Testing">
More specifically, all entropy source health tests and their rationale will be
documented. This will include a description of the health tests, the rate and
conditions under which each health test is performed (e.g., at start up,
continuously, or on-demand), the expected results for each health test, TOE
behaviour upon entropy source failure, and rationale indicating why each test is
believed to be appropriate for detecting one or more failures in the entropy
source.
</section>
</appendix>