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

Gereon Killian8. ICCC, Rome, September 2007 Slide 2 Overview of presentation  Why these PPs?  Advantages / Difficulties  The project  The concept  Methodology  Scheme issues  Project results  Project status

Gereon Killian8. ICCC, Rome, September 2007 Slide 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)

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 7 The concept  4 PPs under development (currently CC V2.3 is used)  Security levels targeting: Security level low:Basic assurance Security level moderate:commercial standard Security level enhanced:commercial high, gov. standard Security level high:gov. high  CC part 2 extended, CC part 3 conformant  Note on gov usage: for classified applications additional requirements may apply

Gereon Killian8. ICCC, Rome, September 2007 Slide 8 The concept - Relation to FIPS 140 or ISO/IEC  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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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.2 ATE_FUN (differently) AGD_ADM, _USR (differently) ACM_SCP AVA_MSU.3, _VLA.3 / VLA.4

Gereon Killian8. ICCC, Rome, September 2007 Slide 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.

Gereon Killian8. ICCC, Rome, September 2007 Slide 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.

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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_TransComplete 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.2Import of user data with security attributes (endorsed) - FDP_ETC.2 Export of user data with security attributes (endorsed) - FDP_UCT.1Basic data exchange confidentiality (diff) - FDP_UIT.1Data exchange integrity - FDP_RIP.2 Full residual information protection

Gereon Killian8. ICCC, Rome, September 2007 Slide 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

Gereon Killian8. ICCC, Rome, September 2007 Slide 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_1Management of security attributes - FMT_MSA.1/Key_Man_2Management of security attributes - FMT_MSA.1/Key_Man_3Management of security attributes (diff) - FMT_MSA.2 Secure security attributes - FMT_MSA.3 Static attribute initialisation

Gereon Killian8. ICCC, Rome, September 2007 Slide 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)

Gereon Killian8. ICCC, Rome, September 2007 Slide 21 PP graduation summary  4 PPs: 4 requirements level  Graduation within SFRs or its operations  Graduation of assurance packages  Graduation within assurance refinements

Gereon Killian8. ICCC, Rome, September 2007 Slide 22 Project status  PP level high, enhanced and moderate in final review and under CC evaluation according to class APE certification planned by end of 2007  PP level low under development  Pilot product evaluation ongoing until Q  Methodology under development, finalisation with results of pilot product evaluation

Gereon Killian8. ICCC, Rome, September 2007 Slide 23 Contact Bundesamt für Sicherheit in der Informationstechnik (Federal Office for Information Security) Godesberger Allee Bonn Tel: +49 (0) Fax: +49 (0)