Germany and The Netherlands Certification of cryptographic modules

Transcription

1 Germany and The Netherlands Certification of cryptographic modules Leo Kool (Msc), Brightsight 18 May 2016,

2 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 2

3 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 3

4 What *is* the CC? It is not a security evaluation standard Rather, it describes and formalizes parameters of security evaluation standards It is a toolbox that can be used to define a security evaluation standard 4

5 What Common Criteria and Scheme arranges What properties of the product will be tested? How will my product be tested? Who will test it? Scheme Rules 5

6 Which parameters do the CC+Scheme describe? 1. Security Claim (ST) 2. Requirements (SFR) 3. Developer Input (SAR) 4. Evaluator Actions (SAR) 5. Strictness (EAL#) Scheme Rules 6

7 The Dutch and the German CC Scheme NSCIB BSI Mutual Recognition Agreement CC evaluations under CCRA-members are accepted up to EAL2 Within Europe (governmental: FR, GE, NL, SP, UK) up to EAL7 (Both Lab and Scheme) Smart Cards Hardware Devices with Security Boxes 7

8 Quality control via strict review procedures Developer Licensed facility (ITSEF) Overseer Certification Body 8

9 Quality control via strict review procedures NSCIB Developer Licensed facility (ITSEF) Overseer Certification Body 9

10 Quality control via strict review procedures BSI Developer Licensed facility (ITSEF) Overseer Certification Body 10

11 Quality control via strict review procedures CC - Assurance Requirements (Classes: ADV, AGD, ALC, ATE, AVA) Developer Licensed facility (ITSEF) Overseer Certification Body 11

12 Quality control via strict review procedures Certification Work Procedures Developer Licensed facility (ITSEF) Overseer Certification Body 12

13 Quality control via strict review procedures Lab Quality Requirements of the Scheme (Scheme Procedures) Developer Licensed facility (ITSEF) Overseer Certification Body 13

14 Quality Requirements of the Scheme Labs must show its competence in the Common Criteria Evaluators must pass a CC exam Evaluation reports are under review and responsibility of senior evaluator (internally) All work is under review by the scheme,nscib and BSI (externally) Labs must show its technical competence For each project the lab must show that the evaluation team is competent for this product Lab must have ISO (ISO ) accreditation Yearly we have audits for our ISO accreditation 14

15 Quality control via strict review procedures Schemes review. each other. Developer Licensed facility (ITSEF) Overseer Overseer Certification Body Certification Body 15

16 Quality control via strict review procedures Developer Licensed facility (ITSEF) Overseer Overseer Certificate Certification Body Certification Body 16

17 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 17

18 Classes of the Common Criteria Security Claim Development Process Claim Product Use Security Claim Product Design Description Certified product (to ship). Manuals Testing and Vulnerability Analysis Certified product (to use). 18

19 Classes of the Common Criteria Security Claim (PP) Claim Product Use Security Claim (ST) Product Design Description (ADV) Development Process (ALC) Certified product (to ship). Manuals (AGD) Certified product (to use) Testing and Vulnerability Analysis (ATE, AVA) 19

20 Process at the Dutch Scheme Preparation Kick Off meeting Monitoring First evaluation meeting Second evaluation meeting Final evaluation meeting Certification Certification finalisation 20

21 Process at the Dutch Scheme Kick Off meeting NSCIB, Developer, Lab Draft Security Target Draft Workplan Goal: Establish common ground for the certification: TOE Scope, Planning, Peculiarities, open Questions to NSCIB 21

22 Process at the Dutch Scheme First evaluation meeting Certifier, Lab, Preferably with Developer Security Target is evaluated and accepted as the base for the evaluation Evaluator presents: TOE in its environment Interfaces Specification Subsystems and modules Mappings IMP sample Configuration Items Goal: Show that the evaluator understands the TOE Design Establish quick turn around of certifier questions 22

23 Process at the Dutch Scheme Second evaluation meeting Certifier, Lab, Developer is welcome Evaluator presents: Developer testing approach Evaluator validation testing approach Vulnerability Analysis Evaluator penetration testing approach Life cycle Site Audit approach Goal: Obtain approval for evaluator testing, and site audit approach 23

24 Process at the Dutch Scheme Final evaluation meeting Certifier, Lab, Developer is welcome Evaluator presents: Final Security Target Testing results Sites audit results Goal: Complete the evaluation 24

25 Process at the Dutch Scheme Certification finalisation Evaluation Technical Report (ETR) (written by the Lab) Certification report including certificate (written by NSCIB) 25

26 BSI is more than a CC scheme 26

27 Process at the German Scheme Start meeting Report & Review AVA Kickoff meeting Testing Certification finalisation 27

28 Process at the German Scheme Kick Off meeting NSCIB, Developer, Lab Draft Security Target Draft Workplan Goal: Establish common ground for the certification: TOE Scope, Planning, Peculiarities, open Questions to BSI 28

29 Process at the German Scheme Report & Review Intermediate Reports (IR) for each CC-class (ADV, AGD, ALC, ATE, AVA) (written by a lab) Review report (written by the BSI certifier) Goal: Show that the work units are correctly and completely fulfilled (work unit = detailed evaluator task on the evidence provided by developer) 29

30 Process at the German Scheme AVA Kickoff meeting Certifier, Lab, Developer can be present silently Presentation, Challenging and Q&A sessions Evaluator presents: Vulnerability Analysis Evaluator Test plan Goal: Obtain approval for evaluator testing approach 30

31 Process at the German Scheme Testing Intermediate Reports ATE, AVA and final test plan with test results (written by a lab) Review report (written by the BSI certifier) Goal: Show that the TOE react according to the expected results in the test plan 31

32 Process at the Dutch Scheme Certification finalisation Evaluation Technical Report (ETR) (written by the Lab) Certification report including certificate (written by BSI) 32

33 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 33

34 Limitations of the Common Criteria and Scheme Procedures and Interpretations Scheme Common Criteria standard Schemes need to assure that at certification the lab has: Complete and Correct coverage of all CC requirement Rationale for each verdict of the CC requirement Common Approach of each Lab The CC does not define each topic in all detail e.g.: Reuse of similar products Reporting style Technical fields: Emission measurement Strength of cryptographic algorithms Random number generator evaluation approach Scheme Procedures & Interpretation & PP 34

35 Limitations of the Common Criteria and Scheme Procedures and Interpretations Scheme Procedures Interpretations and NSCIB BSI SOGIS NSCIB Scheme Interpretation (NSI) NSCIB Scheme Procedures (NSP#) Also uses AIS# of BSI (e.g. AIS20/31 and AIS46) # around 15 Supporting Document Anwendungshinweise und Interpretationen zum Schema (AIS): Some AIS are in German some published # around 50 35

36 SOGIS interpretations and procedures Agreed crypto algorithms SOGIS: (supporting documents) Support for evaluators and developers Classification of security mechanisms Security levels e.g. SOG-IS Crypto Evaluation Scheme Agreed Cryptographic Mechanisms Status is draft (but used) Crypto strength changes over time, and with that the view of the Schemes e.g. of an HMAC see below 36

37 BSI interpretations and procedures for Crypto AIS20 / AIS31 define criteria for evaluating random number generators AIS46 define the allowed crypto algorithms, additional to SOGIS supporting documents RSA, DSA and Diffie-Hellman Key Exchange ECC Memory Encryption AIS20 deterministic RNG AIS31 physical RNG AIS46 crypto algorithm 37

38 Further support of BSI Public AIS: website Some AIS# have English support e.g. for Randoms BSI has a long history of defining crypto related Protection profiles Cryptographic Modules, Security Level [Low, Moderate, Enhanced] Secure signature creation device Security Module of a Smart Metering System Smart Meter Gateway (Security Module) - (Sicherheitsmodul der Kommunikationseinheit) 38

39 AVA Kick off Starting point for the lab test program BSI has a dedicated requirements that need to be addressed in the Vulnerability Analysis, important are side channel perturbation BSI regularly updates the document, e.g. due to academic findings There is an attack list and each of these attacks has to be addressed 39

40 NSCIB interpretations and procedures NSCIB uses some AIS# from BSI AIS#31/20 on random numbers AIS#46 on crypto algorithms AIS#38 ALC re-use not longer allowed to be used NSCIB Scheme Interpretations (NSI#) NSI#1 Site audit rules NSI#7 TSFI interpretation NSI#8 Crypto strength Several others NSCIB Scheme procedures (NSI#) NSP#6 presentation based reporting Several others 40

41 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 41

42 TOE scoping to minimize number of interfaces More TOE Interfaces implies more attack vectors implies more evaluation effort Application SubSystem SS Operating System with Many interfaces 42

43 Subsystem description must support understanding of the TOE More subsystems does not always lead to better understanding of the TOE The interaction must give an overview to the evaluator Source code could then give better understanding Subsystem description must make technically sense should not just repeat the requirement e.g. TOE must verify the password and subsystem description states This SubS verifies the password e.g. This SubS contains a hardcoded list of passwords and verifies these in a while loop. Application SubSystem SS Operating System with Many interfaces 43

44 Outline CC and Schemes Evaluation Process and Reporting forms (NSCIB, BSI) Scheme procedures and interpretations TOE scoping and design description Summary 44

45 Summary - German and The Netherlands Certification of cryptographic modules Cryptographic modules are treated as any other device, noteworthy Strength Crypto algorithms are not assessed There are dedicated requirements on crypto and RNG Schemes NSCIB, BSI In both schemes Have different reporting forms (Intermediate reports vs presentation) Very similar usage of scheme interpretation, and procedures Proper choices TOE boundary and proper technical SubS description makes an evaluation much more smooth 45

46 More information - German and The Netherlands NSCIB website (English version) The website contains General information on NSCIB Scheme documentation Prices Certification (completed, ongoing) BSI website (English version) certification_node.html The website contains Product in evaluation International and German certificates Guidance and interpretations General information 46

47 Questions? 47