Evaluation Report as part of the Evaluation Technical Report, Part B ETR-Part Deterministic Random Number Generator

Transcription

1 ##Classification Evaluation Report as part of the Evaluation Technical Report, Part B ETR-Part Deterministic Random Number Generator Evaluation Assurance Level ##EAL 1-7 Version: Version 0.10 Date: Filename: DRNG_Evaluation Product: ##TOE name (long) Sponsor: ##Sponsor (long) Evaluation Facility: ##Evaluation Facility_Name Certification ID: BSI-DSZ-CC-## Signatures: Author(s): ## QS: ## Other Evaluators: ## Report V0.10.odt ##Evaluation Facility_Name page 1 of 16

2 The following document is a template (Version 0.10, ) for the Evaluation Report of the Random number generator. For each task, the template proposes a framework to be used by the evaluator. Each work unit ends with the final judgement of the evaluator. Each framework includes the evaluator statement of a judgement which may be used in case of a positive result. Note 1: Framework elements are highlighted cursively or marked with ##. The evaluator shall delete this text in his final report. ##Evaluation Facility_Name page 2 of 16

3 Document Information History of changes Version Date Approved Changes Application Note (reason for change; effects of change on work units; if applicable, which comments of the certification body were observed) Hesselmann minor changes ##Evaluation Facility_Name page 3 of 16

4 Document Invariants Name Invariant (edit here) Output value Filename and size calculated automatically DRNG_Evaluation Report V0.10.odt Current version Version 0.10 Version 0.10 Date Classification ##Classification ##Classification TOE name (long) ##TOE name (long) ##TOE name (long) TOE name (short) ##TOE name (short) ##TOE name (short) Sponsor (long) ##Sponsor (long) ##Sponsor (long) Sponsor (short) ##Sponsor (short) ##Sponsor (short) Developer (short) ##Developer ##Developer Certification ID BSI-DSZ-CC-## BSI-DSZ-CC-## Certification body (long) Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee , Bonn, Germany Certification body (short) BSI BSI Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee , Bonn, Germany ##Evaluation Facility_Name page 4 of 16

5 Table of contents 1 Impact in case of a re-evaluation Evaluation results Examination of DRG Examination of DRG Examination of DRG Indications for Potential Vulnerabilities Missing Information Questions to / Conditions on the Developer Necessary Changes/Improvements Effects on other Documents Annex Glossary and list of acronyms Bibliography...14 ##Evaluation Facility_Name page 5 of 16

6 1 Impact in case of a re-evaluation ## In case of a re-evaluation, the impact resulting from the changes that have been applied to the product must be discussed in this chapter only. Therefore, the evaluator might use the suitable parts of the Impact Analysis Report. ## The differences between the certified and the changed TOE should be discussed in this chapter only. The following chapters should contain the appropriately marked changes with respect to the previous evaluation process. Furthermore, the following chapters should not mention the previous TOE to allow for a consistent description that provides clarify in further re-evaluation activities. ## The current evaluation process is not a re-evaluation process. 2 Evaluation results 2.1 Examination of DRG.1 If the RNG belongs to class DRG.1, the evaluator is expected to handle the work units listed below. To avoid unnecessary repetitions due to several identical work units being part of multiple components, each component begins with a table that displays the changes from the hierarchically-lower ordered components. This table must include exact references. DRNG.1-1 DRNG.1-2 DRNG.1-3 DRNG.1-4 DRNG.1-5 DRNG.1-6 DRNG.1-7 DRNG.1-8 DRNG.1-9 DRNG.1-10 ##Evaluation Facility_Name page 6 of 16

7 [DRNG.1-1] Examine the description of the intended use of the RNG in the developer evidence document, the ST, and the guidance documents, and check whether the descriptions are complete and internally consistent. Some possible conflicts related to RNGs are: The PP / ST refers to different types of RNGs, but it is not clearly stated which one is used for the specific purpose. The PP / ST describes the use of DRNGs without any assumption about their initialization process or the external RNG seeding the DRNG. Examine all operations left open in FCS_RNG.1 Check the parameters assigned in the element FCS_RNG.1.1 (DRG.{1,2,3}.1) for whether they meet the attack potential identified in the vulnerability analysis component, if applicable. Check the parameters assigned in quality claim FCS_RNG.1.2 (DRG.1.3, DRG.{2,3}.4) for whether they meet the attack potential identified in the vulnerability analysis component. Check that the general advice for the specification of random number generation is followed. [DRNG.1-2] Examine the developer description of the DRNG module and check whether it is internally consistent. The evaluator shall examine the evidence provided by the developer as required by [10] in D.2. [DRNG.1-3] Examine that the implementation of the RNG is in accordance with the developer description of the DRNG module. The correct implementation of the deterministic part can be shown by using known answer tests (KAT) and/or by source code review. A rational must be added if only tests are conducted, but the source code is not inspected. If the software implementation of a RNG uses timing loops, there is a risk that compilers remove them as part of optimization. This must be checked by appropriate testing, inspection of the compiler switches, or other appropriate approaches. ##Evaluation Facility_Name page 7 of 16

8 [DRNG.1-4] Examine the developer's demonstration for the quality claim and repeat the tests according to the test suites for DRG.1.4. The calculated test values of each test of the evaluator shall be given. The standard test suites for uniformly-distributed binary sequences support the reproducibility of the functionality tests and the comparability of test results for RNGs in different products under evaluation. The evaluator may use additional statistical test suites if suspicion arises about the quality of output, or properties of the DRNG design. If the seeding procedure described in the guidance documents does not allow for generation of a sufficient quantity of random numbers with which to execute the test suite successfully, the aim of running the test suites cannot be reached. Depending on the TOE, the evaluator should switch off the re-seeding procedure in test mode or write a software program of the DRNG (following the description of the DRNG module in terms of the 6- tuple (S, I, R, φ, ψ, pa ) to generate a sufficient quantity of random numbers for the test suites. [DRNG.1-5] Examine the developer's demonstration/description about the characteristics of the entropy input provided to the DRNG for seeding. The evaluator shall examine that a clearly-stated assumption about the operational environment is provided in the ST and guidance documentation, as appropriate. Possible reasons for insufficient entropy include, but are not limited to: insufficient entropy of the seeding sequence provided to the DRNG for the initial state, inappropriate seeding function generating initial states with low entropy even if the seeding sequence contains sufficient entropy. [DRNG.1-6] Examine the developer's demonstration that the internal states will bear the Min-entropy assigned in DRG.{1,2,3}.1. Possible reasons for insufficient entropy include but are not limited to: small internal state space, reduction of the entropy of the internal state due to state transition function, reduction of the entropy of the internal state due to long lifetime of the DRNG instantiations. Any use of DRNG output is prevented until the condition for seeding is met. Reseeding the DRNG may be enforced if the entropy of the internal state might not have sufficient entropy. ##Evaluation Facility_Name page 8 of 16

9 The 'requirements for seeding' have to be assigned in DRG.{1,2,3}.1 and in DRG.1.3, DRG.{2,3}.4. The evaluator has to examine both assignments for inconsistency. [DRNG.1-7] Examine the developer's demonstration for the claimed security capability DRG.{1,2,3}.2 [DRNG.1-8] Examine the developer's demonstration for the quality claim for DRG.1.3, DRG.{2, 3}.4 [DRNG.1-9] Examine the developer's demonstration and evaluate (using independent penetration tests) whether the RNG is protected from tampering, monitoring and/or misuse. This is done by observing or controlling the external interfaces to determine whether the procedures described in the guidance documents are followed. This includes the protection of the internal state and the RNG output (if necessary) both during operation and while the TOE is switched off. The evaluator shall examine the results of all penetration testing to determine whether the TOE, in its operational environment, is resistant to an attacker possessing an attack potential identified in the ST as described in the CEM for AVA_VAN.{1,2,3,4} and in the scheme documents for AVA_VAN.5 [7]. The following aspects of attacks on DRNG's external interfaces should be considered (not limited): Tampering with the seeding process in order to prevent seeding. Replay of the seeding sequence in order to repeat the initial state and, therefore, the output. For example, if the TSF implements different DRNG instantiations (e.g., for different entities), it shall be examined whether each instantiation uses different internal states. Manipulation of the seeding sequence in order to reduce the entropy or even set it to a known sequence. There exist effective methods to determine the initial state of an autonomous DRNG, e.g., rainbow tables 1. Tampering with the state transition function or preventing the update of the internal state, (i.e., physical interfaces), and electromagnetic emanation due to their physical value and timing behaviour. 1 Rainbow tables might be useful for guessing passwords and are implemented in some programs, e.g., Ophcrack or RainbowCrack. ##Evaluation Facility_Name page 9 of 16

10 Running the DRNG in the user space of the operational memory of a personal computer allows an attacker to compromise or manipulate the internal state or the output. Tampering with the output function (e.g., replay, setting known output). Illicit information flow might include side channel attacks using information contained in any signals, like power consumption and output ports. [DRNG.1-10] Examine the developer's documents for the secure installation of the DRNG, secure preparation of the operational environment and secure seeding of the DRNG. Examine: the requirements for the seeds necessarily provided for the installation of the DRNG, the security measures to protect the confidentiality and integrity of the seed and prevent misuse of the seeding process. Misuse might arise from incomplete guidance documentation, unreasonable guidance, and unintended misconfiguration of the TOE. Address the security problem definition to determine that it describes the assumptions about the operational environment of the TOE and development guidance. 2.2 Examination of DRG.2 If the RNG belongs to class DRG.2, the evaluator is expected to handle the work units listed below. To avoid unnecessary repetitions due to several identical work units being part of multiple components, each component begins with a table that displays the changes from the hierarchically-lower ordered components. This table must include exact references. DRNG.2-1 same as DRNG.1-1 DRNG.2-2 DRNG.2-3 DRNG.2-4 DRNG.2-5 DRNG.2-6 DRNG.2-7 same as DRNG.1-2 same as DRNG.1-3 DRNG.1-4 enhanced same as DRNG.1-5 same as DRNG.1-6 same as DRNG.1-7 ##Evaluation Facility_Name page 10 of 16

11 DRNG.2-8 DRNG.2-9 DRNG.2-10 DRNG.2-11 same as DRNG.1-8 same as DRNG.1-9 same as DRNG.1-10 [DRNG.2-4] Examine the developer's demonstration for the quality claim and repeat the tests according to the test suites for DRG.{2,3}.5 See DRNG.1-4. In addition, examine whether the theoretical arguments about both the proposed statistical properties of the RNG output function and the used assumptions are reasonable. [DRNG.2-11] Examine the developer's demonstration for the claimed security capability DRG Examination of DRG.3 If the RNG belongs class DRG.3, the evaluator is expected to handle the work units listed below. To avoid unnecessary repetitions due to several identical work units being part of multiple components, each component begins with a table that displays the changes from the hierarchically-lower ordered components. This table must include exact references. DRNG.3-1 same as DRNG.2-1 DRNG.3-2 DRNG.3-3 DRNG.3-4 same as DRNG.2-2 same as DRNG.2-3 same as DRNG.2-4 ##Evaluation Facility_Name page 11 of 16

12 DRNG.3-5 DRNG.3-6 DRNG.3-7 DRNG.3-8 DRNG.3-9 DRNG.3-10 DRNG.3-11 same as DRNG.2-5 same as DRNG.2-6 same as DRNG.2-7 same as DRNG.2-8 same as DRNG.2-9 same as DRNG.2-10 DRNG.2-11 enhanced [DRNG.3-11] Examine the developer's demonstration for the claimed security capability DRG Indications for Potential Vulnerabilities ##The evaluator did not find any potential vulnerabilities indicated by the current evaluation aspect. 2.5 Missing Information ##There is no further information, which the developer/sponsor has to provide. ##In the case of the verdict inconclusive, the evaluator is expected to put some issues into the sections Missing Information or Questions to /Conditions on the Developer of his/her single evaluation report, cf. AIS Questions to / Conditions on the Developer ##There are no questions, recommendations to, or conditions on the developer. ##In the case of the verdict inconclusive, the evaluator is expected to put some issues into the sections Missing Information or Questions to / Conditions on the Developer of his/her single evaluation report, cf. AIS14. ##Evaluation Facility_Name page 12 of 16

13 2.7 Necessary Changes/Improvements ##There are no changes that should be done by the developer. ##In the case of the verdict fail, the evaluator is expected to put some issues into the section Necessary Changes/Improvements of his/her single evaluation report, cf. AIS Effects on other Documents ##There are no effects on other documents. ##Evaluation Facility_Name page 13 of 16

14 3 Annex 3.1 Glossary and list of acronyms term Deterministic RNG Entropy Random number generator (RNG) Seed True RNG definition / explanation An RNG that produces random numbers by applying a deterministic algorithm to a randomly selected seed and, possibly, on additional external inputs. The entropy of a random variable X is a mathematical measure of the amount of information gained by an observation of X. A group of components or an algorithm that outputs sequences of discrete values (usually represented as bit strings). Value used to initialize the internal state of an RNG. A device or mechanism for which the output values depend on some unpredictable source (noise source, entropy source) that produces entropy. abbreviation term definition / explanation DRNG Deterministic RNG EAL Evaluation Assurance Level PP Protection Profile refer to [CC part 1] RNG Random Number Generator ST Security Target refer to [CC part 1] TOE Target of Evaluation TSF TOE Security Functionality SFR Security Functional Requirement 3.2 Bibliography Criteria and Methodology [1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, September 2012, Version 3.1, Revision 4, CCMB [2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, September 2012, Version 3.1, Revision 4, CCMB [3] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, September 2012, Version 3.1, Revision 4, CCMB ##Evaluation Facility_Name page 14 of 16

15 [4] Common Methodology for Information Technology Security Evaluation, Evaluation methodology, September 2012, Version 3.1, Revision 4, CCMB [5] Anwendungshinweise und Interpretationen zum Schema, AIS 14: Anforderungen an Aufbau und Inhalt der ETR-Teile für Evaluationen nach CC, Version 6, , Bundesamt für Sicherheit in der Informationstechnik [6] Anwendungshinweise und Interpretationen zum Schema, AIS 19: Anforderungen an Aufbau und Inhalt der Zusammenfassung des ETR für Evaluationen nach CC und ITSEC, Version 6, , Bundesamt für Sicherheit in der Informationstechnik [7] Anwendungshinweise und Interpretationen zum Schema, AIS 34: Evaluation Methodology for CC Assurance Classes for EAL5+, [8] W. Killmann, W. Schindler, A proposal for: Functionality classes for random number generators, Version 2.0, September 18, 2011 [9] Evaluation of Random Number Generators, Version 0.10 [10] Developer evidence for the evaluation of a deterministic random number generator, Version 0.9, February 28, 2013 Legislatives and Standards ## or none Developer Documents [ST] ##Title ST, ##Author, Version ##, ##Date [FSP] ##Title Functional Specification, ##Author, Version ##, ##Date [TDS] ##Title TOE Design Specification, ##Author, Version ##, ##Date [ALC] ##Title Life-Cycle Documentation, ##Author, Version ##, ##Date [ACM] ##Title Configuration Management Documentation, ##Author, Version ##, ##Date [CLIST] ##Title Configuration List, ##Author, Version ##, ##Date [DVS] ##Title Development Site Security Documentation, ##Author, Version ##, ##Date [DEL] ##Title Delivery Documentation, ##Author, Version ##, ##Date [OPERG] ##Title Operational Guidance, ##Author, Version ##, ##Date [PREPG] ##Title PREPG (Preparative Guidance), ##Author, Version ##, ##Date Single Evaluation Reports [ATE_IND] ##Title ATE_IND, ##Author, Version ##, ##Date [ALC-CL] ##Title Checklist for site visit, ##Author, Version ##, ##Date ##Or none ##Evaluation Facility_Name page 15 of 16

16 Other documents ## certificates, protection profiles etc. ##Evaluation Facility_Name page 16 of 16