CC V3 application to Smart Cards and similar devices

Transcription

1 CC V3 application to Smart Cards and similar devices 8th ICCC Rome, September 2007 ISCI-WG1 speaker: Françoise Forge September th ICCC Rome 1

2 Presentation overview ISCI - a Eurosmart Initiative ICSI contribution to CC V3 Interpretation of ADV_ARC Transition issues for smart security devices Conclusion September th ICCC Rome 2

3 Eurosmart International non-profit association founded in 1995 in Brussels 27 companies of the Smart Security industry (smart cards manufacturers, semiconductors, terminals, issuers) Promotion and standardization of smart secure devices and smart secure systems Harmonization of security evaluation schemes ISCI created by Eurosmart ISCI a Eurosmart initiative To involve all actors of the evaluation process, with the goal to improve smart card evaluation time & cost To provide supporting documents to guide smart card evaluation September th ICCC Rome 3

4 Two working groups WG1 for methodology WG2 for technical issues (JHAS) ISCI-WG1 Contributors ISCI contributors Smart card manufacturers, developers, Issuers, IC manufacturers Evaluation laboratories Certification Authorities September th ICCC Rome 4

5 ISCI Contribution to CC V3 Updating of smart card supporting documents Achievements Application to attack potential for smart cards (JHAS) Composite Product evaluation for smart cards and similar devices Defines Developer and evaluators task for composite evaluations Compliant with CC V2.3 and CC V3.1 Includes template of ETR for composite evaluation Current work Interpretation of ADV_ARC Review possible CCV3 transition issues for composite evaluation September th ICCC Rome 5

6 ADV_ARC new requirement CCV2 CCV3 APE-ASE ADV_FSP, HLD, LLD, IMP ADV_RCR, SPM APE-ASE ADV_ARC, FSP, TDS, IMP, ADV_SPM New requirement ATE_COV, DPT, FUN_IND AVA_CCA, SOF, VLA ALC_DVS, FLR, LCD, TAT ACM_AUT, CAP,SCP ADO_DEL, IGS AGD_ADM, USR ATE_COV, DPT, FUN_IND AVA_VAN : Evaluator s task ALC_DVS, FLR, LCD,TAT ALC_CMC, CMS ALC_DEL AGD_OPE, PRE Removed for developers September th ICCC Rome 6

7 Definition Interpretation of ADV_ARC for smart cards (1) Requires the developer to design and provide an architecture that exhibits Arguments Secure initialization process of the TSF Self-protection, domain separation, and non-bypassability Specification of security functionality implementing the SFRs is described in ADV_FSP, TSF interfaces are refined in ADV_TDS Secure initialization, self-protection non-bypassability and domain separation are design properties of the TSF not necessarily described in SFRs. Vulnerability analysis (AVA_VAN) is an assessment to determine whether potential vulnerabilities could allow attackers to violate the SFRs. The description of architectural soundness can be thought of as a developer's vulnerability analysis, in that it provides the justification for why the TSF is sound and enforces all of its SFRS September th ICCC Rome 7

8 Interpretation of ADV_ARC for smart cards (2) Considering smart cards evaluation with CCV2.3 FPT_RVM, FPT_SEP were used in most protection profiles De facto non-bypassability and domain separation were described in ADV documentation. Developer vulnerability analysis (AVA_VLA.4) described how vulnerabilities cannot be exploited. ADV_ARC for smart cards should be Reusing information in design documentation related to FPT_SEP, FPT_RVM and start-up/initialization, Reusing former AVA_VLA developer vulnerability analysis, Providing a re-structured document giving a clear view of all countermeasures implemented in the design of the TSF September th ICCC Rome 8

9 Defining ARC for smart cards Smart card technology combines Integrated Circuit, Operating systems, and applications Security IC evaluation is based on a unique protection profile, each product with similar types of mechanisms to protect the TSF Smart card (composite) evaluation is dependant on the application type (signature, MRTD, banking ).although exhibiting basic identical protection mechanisms of the TSF against known attacks (SPA,DPA, fault attacks.) Smart card security evaluation benefits from a well defined Attack methods list. Guidance will provide concrete use cases for each ADV_ARC requirements September th ICCC Rome 9

10 Definition (CEM 5.27) Domain separation Security domains refer to environments supplied by the TSF for use by potentiallyharmful entities; for example, a typical secure operating system supplies a set of resources (address space, per-process environment variables) for use by processes with limited access rights and security properties. Interpretation for hardware Security domains: Test mode, application mode, user mode Description of domain isolation: separation of high and low privileged tasks mechanisms Interpretation for software Security domains: Memory partition (execution, data storage); Java card security domains; life-cycle modes Description of domain isolation: access control mechanism, execution discrimination September th ICCC Rome 10

11 Secure startup definition (CEM 529) The information provided in the security architecture description relating to TSF initialization is directed at the TOE components that are involved in bringing the TSF into an initial secure state (i.e. when all parts of the TSF are operational) when power-on or a reset is applied. Interpretation for hardware Description of IC power-on operation: physical integrity test, sensors test Description of power save modes: synchronization of functionalities Interpretation for software Secure start-up Description of software application initialization: verification of secure states flags, executable code integrity, default configuration September th ICCC Rome 11

12 Self protection definition (CEM 532) Self-protection refers to the ability of the TSF to protect itself from manipulation from external entities that may result in changes to the TSF. The security architecture description shall demonstrate that the TSF protects itself from tampering. Interpretation for hardware Physical probing (bus probing), physical manipulation (deactivation of sensors) Interpretation for software Self-protection Mechanism to protect from TSF data manipulation: backup system, duplication of system information, execution error detection What about SFRs addressing tampering : e.g FPT_PHP.3 FPT_PHP.3.1 : The TSF shall resist [physical tampering scenarios] to the [list of TSF devices/elements] by responding automatically such that the SFRs are always enforced. What is in ADV_TDS, what is in ADV_ARC? September th ICCC Rome 12

13 By-Passing By-passing definition (CEM 537) Non-bypassability is a property that the security functionality of the TSF (as specified by the SFRs) is always invoked. For example, if access control to files is specified as a capability of the TSF via an SFR, there must be no interfaces through which files can be accessed without invoking the TSF's access control mechanism. Interpretation for hardware Protection against fault attacks, side channel,software attacks Interpretation for software Protection against fault attacks, side channel,software attacks Sometimes difficult to distinguish between by-passing and self protection September th ICCC Rome 13

14 Some clues to help building ADV_ARC TSFI TSF Assets Indirect attacks Direct attacks Distinguish between ADV_TDS and ADV_ARC: Properties addressed by ADV_ARC largely have no directly observable interfaces at the TSF. All behavior described in ADV_TDS shall be mapped to the TSFIs that invokes it. By-passing: TSF is not involved or deactivated but unchanged (indirect attacks) Self Protection: TSF is manipulated; TSF protects itself against direct attack, e.g deactivation) September th ICCC Rome 14

15 ADV_ARC guidance content Introduction of Security Architecture interpretation for smart cards Propose ADV_ARC document structure with detailed examples for hardware and software Refer to ADV_TDS if mechanism is already described in design documentation Reuse CC V2 developer vulnerability analysis technical content Security services: Cryptography, RNG Security mechanisms: operating condition control, shields, software countermeasures. Demonstrate cooperation of security mechanisms in self-protection and non-bypassability for known attack paths September th ICCC Rome 15

16 For the developer Benefits of ARC Not a new topic for experienced developers, their may reuse CC V2 vulnerability analysis Consider TSF protection early in the development Better structure to describe effectiveness of security mechanisms For the evaluator Helpful delivery for vulnerability analysis Get early in the evaluation process, the overview of security mechanisms contribution to TSF protection. Could ARC get a fail verdict? No requirements for developer to provide and prove that ARC is complete. The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Guidance will provide common interpretation between all parties September th ICCC Rome 16

17 Some transition issues (1) Transition phase for smart cards products Timing on most used Protection profiles updates Hardware PP : ready Other PPs: not ready certified before April 2008? Signature (SSCD), e-passport (MRTD), health cards, Banking application (based PP9911),e-purse (Moneo), Java Card PPs Composite evaluation issues for EAL4 augmented VLA4; IMP.2 VAN5; IMP.1 Smart card using CC V2.3 PP Based on Hardware certified CC V3.1 VAN5; IMP.1 VLA4; IMP.2 Smart card using CC V3.1 PP Based on hardware certified CC V September th ICCC Rome 17

18 Some transition issues (2) CC V2 and CC V3 assurance requirements are equivalent (mapping) Results of a hardware platform evaluation (technical information) are independent from CC version Smart card using CC Based V2.3 PP on Based V3.1 PPon Hardware certified CC V3.1 Smart card using CC Hardware certified CC V2.3 Statement of compatibility Hardware ST/Composite ST VAN5 = VLA4 CC V3 ADV_IMP.1 entire implementation ;subset examined CC V2.3 ADV_IMP.1 entire implementation supplied & examined Statement of compatibility Hardware ST/Composite ST VAN5 = VLA4 CC V3.1 ATE_DPT.2 : tested at module level (low level) CC V2.3 ATE_DPT.2 : tested at high level Design Need assessment of equivalence from evaluators and Certification authorities September th ICCC Rome 18

19 ARC interpretation for smart cards Near to completion Should be presented as a part of supporting document to CCDB end Transition issues Push for PP updates/ intermediate solution Next steps Conclusion Get to practice and start as soon as possible evaluation with CC V3, Review any issue and propose solutions September th ICCC Rome 19

20 25-27 September th ICCC Rome 20