1 / 23

Graduated CC Protection Profiles for Cryptographic Modules

Graduated CC Protection Profiles for Cryptographic Modules. Bundesamt für Sicherheit in der Informationstechnik (BSI) (Federal Office for Information Security). 8. ICCC, Rome, 25. - 27. September 2007. Gereon Killian Head of Certification Body. Overview of presentation. Why these PPs?

nailah
Download Presentation

Graduated CC Protection Profiles for Cryptographic Modules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Graduated CC Protection Profiles for Cryptographic Modules Bundesamt für Sicherheit in der Informationstechnik (BSI) (Federal Office for Information Security) 8. ICCC, Rome, 25. - 27. September 2007 Gereon Killian Head of Certification Body

  2. Overview of presentation • Why these PPs? • Advantages / Difficulties • The project • The concept • Methodology • Scheme issues • Project results • Project status

  3. Why these PPs? • Commercial applications use more and more dedicated cryptographic devices for data security also within classical safety or industrial areas -Evidence on assurance is needed • Non-classified governmental applications need more support in security assessment • CC evaluation could be a basis for further assessment and approval in classified area • Existing standards are either domestic from certain nation (e.g. FIPS 140 / US) or or proprietary or no appropriate scheme is available (e.g. ISO)

  4. Advantages / Difficulties • Existing national evaluation and certification scheme can be used • Well defined structure of PPs • Well defined structure of CC assurance requirements -------------------------------------------------------- • Evaluation methodology needs to be amended (compared to CEM) as assessment of cryptographic algorithms is not deeply implemented within CC • PP concept has low flexibility in using options • Specific evaluation competence of lab required

  5. The project • Investigation of marked needs and industrial implementation practise • Assessment of available information on requirements • Identification of high assurance requirements • Mapping and categorisation of requirements into functional and assurance aspects • Downgrading for applications with lower assurance needs • PP development process • Pilot evaluation

  6. The concept • Focus on Hardware Security Modules including Single Chip Solutions. • e.g. for a PKI system for generation and certification of keys / for mass signature • high performance encryption • Pure software implementations are not covered • Graduated approach on functional requirements • Graduated approach on assurance requirements • Consideration of national peculiarities by using concept of endorsed national functions or standards

  7. The concept • 4 PPs under development (currently CC V2.3 is used) • Security levels targeting: Security level low: Basic assuranceSecurity level moderate: commercial standardSecurity level enhanced: commercial high, gov. standardSecurity level high: gov. high • CC part 2 extended, CC part 3 conformant • Note on gov usage: for classified applications additional requirements may apply

  8. The concept - Relation to FIPS 140 or ISO/IEC 19790 • Focus on specific type of products • Test requirements covered • Functional requirements amended • Functional graduation similar as within FIPS but not exactly same • PP Assurance graduation based on CC concept with strong requirements on AVA according to the state of the art methods • Focus of PPs and its graduation in defining sensible set of requirements for up to high assurance level

  9. Methodology • Application of cryptography requires specific functional details to be defined • Adequate evaluation process must be ensured • Flexibility of CC in terms of operations on functional components and on assurance components is being used • Refinement of functional as well as of assurance requirements is being used • Testing methodology / test suite for national endorsed functions

  10. Scheme issues • Established certification schemes • Sufficient oversight by CB needed • Monitoring of specific lab competence by scheme / national authority • Rating of Strength of Function / Vulnerability Assessment is scheme responsibility • CC-RA does not cover recognition in this area - products for commercial usage might not need this aspect under governmental recognition but require well defined approach under oversight of national authority

  11. Project results - Assurance Packages • PP Assurance packages: • low: EAL3 + or plane EAL4 planned; details not yet defined • moderate: EAL4 + IMP.2, SPM.2, DVS.2, VLA.3 • enhanced: EAL4 + IMP.2, SPM.2, DVS.2, VLA.4 • high: EAL4 + IMP.2, INT.1, SPM.3, DVS.2, CCA.1, MSU.3, VLA.4 • Refinements on:ADV_FSP, _HLD, _LLD, _IMP, _SPM.3 / _SPM.2ATE_FUN (differently)AGD_ADM, _USR (differently)ACM_SCPAVA_MSU.3, _VLA.3 / VLA.4

  12. Project results - TOE Definition • Cryptographic module that implements Endorsed cryptographic functions (ECF) ( and no non-ECF) • Protection of confidentiality, integrity or both of user data according to a security policy of an IT system. • Management and protection of cryptographic keys for ECF. • TOE is physically: a set of hardware and software and/or firmware within the cryptographic boundary. • TOE logically: defined by the provided security functions depending on the implemented cryptographic algorithms and protocols.

  13. Project results - Roles • Roles as defined: • Administrator for Management of TOE • Crypto officer to perform cryptographic initialization and management functions • End User assumed to perform general security services, including cryptographic operations and other Endorsed security functions. • Maintenance Personal (if applicable) for physical maintenance and/or logical maintenance services (e.g., hardware/software diagnostics) • Unidentified User • Unauthenticated User: identified but not being authenticated.

  14. Project results - Objectives • Addressed topics for the TOE- Red-black separation of the TOE- Implementation of Endorsed cryptographic functions - Need for Identification and authentication of users- Roles known to TOE- Access control for services- Access control for cryptographic keys- Audit of the TOE- Export of cryptographic keys- Generation of cryptographic keys by the TOE- Import of cryptographic keys- Management of cryptographic keys- Destruction of cryptographic keys- Check for correct operation- Physical protection- Prevent leakage of confidential information

  15. Project results - Objectives • Addressed topics for the TOE-Environment- Assurance Security Measures in Development and Manufacturing Environment- Key generation by IT environment- Separation of red and black area of the IT system- Analysis of TOE audit data- Personnel security- Availability of cryptographic key and key material

  16. Project results - SFRs • Cryptographic operation and key management- FCS_CKM.1 Cryptographic key generation (endorsed) - FCS_CKM.2/Import Cryptographic key distribution (endorsed)- FCS_CKM.2/Export Cryptographic key distribution (endorsed)- FTP_ITC.1 Inter-TSF trusted channel - FCS_CKM.4 Cryptographic key destruction - FCS_COP.1 Cryptographic operation (endorsed)- FCS_RNG.1 (ext) Random number generation (endorsed) • User I&A- FIA_ATD.1 User attribute definition - FIA_UID.1 Timing of identification - FIA_UAU.1 Timing of authentication - FIA_UAU.6 Re-authenticating- FIA_UAU.7 Protected authentication feedback - FIA_USB.1 User-subject binding - FIA_AFL.1 Authentication failure handling

  17. Project results - SFRs • Protection of user data - FDP_ACC.2/Key_Man Complete access control - FDP_ACF.1/Key_Man Security attribute based access control- FDP_ACC.2/Oper Complete access control- FDP_ACF.1/Oper Security attribute based access control - FDP_ACC.2/Mode_Trans Complete access control - FDP_ACF.1/Mode_Trans Security attribute based access control - FDP_IFC.2 Complete information flow control (high only)- FDP_IFF.1 Simple security attributes (high only)- FDP_ITC.2 Import of user data with security attributes (endorsed)- FDP_ETC.2 Export of user data with security attributes (endorsed)- FDP_UCT.1 Basic data exchange confidentiality (diff) - FDP_UIT.1 Data exchange integrity - FDP_RIP.2 Full residual information protection

  18. Project results - SFRs • Audit- FAU_GEN.1 Audit data generation (diff)- FAU_GEN.2 User identity association - FAU_SAR.1 Audit Review- FAU_SAR.2 Protected audit trail storage- FAU_STG.1 Protected audit trail storage- FAU_STG.3 Action in Case of Possible Audit Data Loss (diff)- FAU_STG.4 Prevention of Audit Data Loss- FPT_STM.1 Reliable time stamps

  19. Project results - SFRs • Management of TSF and protection of TSF data- FMT_SMF.1 Specification of Management Functions - FMT_SMR.2 Restrictions on security roles (diff) - FMT_MTD.1/Admin Management of TSF data - FMT_MTD.1/User Management of TSF data - FMT_MTD.1/Audit Management of TSF data - FMT_MOF.1/CO Management of security functions behaviour - FMT_MOF.1/Adm Management of security functions behaviour - FMT_MSA.1/Key_Man_1 Management of security attributes - FMT_MSA.1/Key_Man_2 Management of security attributes - FMT_MSA.1/Key_Man_3 Management of security attributes (diff) - FMT_MSA.2 Secure security attributes - FMT_MSA.3 Static attribute initialisation

  20. Project results - SFRs • TSF protection- FPT_TDC.1 Inter-TSF basic TSF data consistency - FRU_FLT.2 Limited fault tolerance (high only)- FPT_FLS.1 Failure with preservation of secure state (diff) - FPT_EMSEC.1 (ext) TOE Emanation - FPT_RVM.1 Non-bypassability of the TSP - FPT_SEP.1 TSF domain separation - FPT_TST.1 TSF testing - FPT_TST.2 (ext) TSF self-testing (endorsed)- FPT_PHP.3 Resistance to physical attack (diff)

  21. PP graduation summary • 4 PPs: 4 requirements level • Graduation within SFRs or its operations • Graduation of assurance packages • Graduation within assurance refinements

  22. Project status • PP level high, enhanced and moderate in final review and under CC evaluation according to class APEcertification planned by end of 2007 • PP level low under development • Pilot product evaluation ongoing until Q2 2008 • Methodology under development, finalisation with results of pilot product evaluation

  23. Contact Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security) Godesberger Allee 185-189 53175 Bonn Tel: +49 (0)3018 9582 111 Fax: +49 (0)3018 10 9582 5477 zertifizierung@bsi.bund.de www.bsi.bund.de www.bsi.bund.de/gshb/zert gereon.killian@bsi.bund.de

More Related