Wouter Slegers 31 15 269 2500 Slegers brightsight

Скачать презентацию Wouter Slegers 31 15 269 2500 Slegers brightsight

2271e26c85e7ec515fcd7a3184fc8fc2.ppt

Количество слайдов: 35

Wouter Slegers + 31 15 269 2500 [email protected] com www. brightsight. com Practical experience of CC 3. 1 applied on smartcard hardware

Practical experience of CC 3. 1 Presentation Targets Describe our experiences with CCv 3. 1 Release 1 on a smartcard IC Practice: What works well? What does not work well (yet)? Theory: What has essentially changed? What is the effort/cost impact of these changes to an evaluation? brightsight® your partner in security approval page 3

Practical experience of CC 3. 1 Summary (or: teaser) The 10. 000 feet view: Essentially, not much has changed This is the good and the bad news brightsight® your partner in security approval page 4

Practical experience of CC 3. 1 This was made possible by: Developer and Sponsor: Certification Body: Netherlands Scheme for Certification in the area of IT Security (NSCIB) As usual, this presentation is my opinion, I do not speak for others. brightsight® your partner in security approval page 5

Practical experience of CC 3. 1 Setting and background Experienced developer, entry into CC world: No existing CCv 2. x legacy documentation Choice for new CCv 3. x to be at cutting edge Accepting the bleeding edge aspects of this choice Timing relative to other activities on CC smartcard domain: Eurosmart PP (BSI-PP-0002) the choice, but CCv 2. x CCv 3. 1 upgrade of PP and methodology not available at the time Proceeded under estimate that the PP would not significantly change (or an ST would be made stand-alone and match the old PP) Effectively this was parallel evolution to the Eurosmart/ISCI work brightsight® your partner in security approval page 6

Practical experience of CC 3. 1 Evaluation experience so far Life-cycle support (ALC) Security Target evaluation (ASE) Development (ADV) with FSP, TDS, IMP, ARC Guidance (AGD) Tests (ATE), Vulnerability Assessment (AVA_VAN) brightsight® your partner in security approval page 7

Practical experience of CC 3. 1 Most interesting parts (with respect to impact of the CCv 3. 1 changes) Life-cycle support (ALC) Security Target evaluation (ASE) Development (ADV) with FSP, TDS, IMP, ARC Guidance (AGD) Tests (ATE), Vulnerability Assessment (AVA_VAN) brightsight® your partner in security approval page 8

Practical experience of CC 3. 1 ALC Architecture (ADV_ARC) ASE AGD ADV ATE, AVA Needs to include a description how the following items are provided: “Security domains” i. e. environments provided “for use by potentiallyharmful entities” Startup (“initialisation sequence”) Self protection Non-bypass Includes side channel analysis brightsight® your partner in security approval page 9

Practical experience of CC 3. 1 ALC Architecture (ADV_ARC) ASE AGD ADV ATE, AVA Needs to include a description how the following items are provided: “Security domains” i. e. environments provided “for use by potentiallyharmful entities” Startup (“initialisation sequence”) Self protection Non-bypass Includes side channel analysis Essentially sums up what property of smartcard HW we test: To keep secrets secret, except when the software outputs them brightsight® your partner in security approval page 10

Practical experience of CC 3. 1 ALC Architecture (ADV_ARC) versus design (ADV_TDS) ASE AGD ADV ATE, AVA Something belongs in design (ADV_TDS): If a SFR can/must be mapped to TSFI / subsystem / module Something belongs in architecture (ADV_ARC): Not defined, effectively “the rest” If not explicitly required/covered by SFR but needed for self protection Corollary, architecture (ADV_ARC): is the place to put the security mechanisms that are needed to explain why an attack path will not work in AVA_VAN, But not the security mechanisms that cover the SFRs (or we are duplicating things) So what are the SFRs then? brightsight® your partner in security approval page 11

Practical experience of CC 3. 1 ALC SFRs in smartcard hardware domain ASE AGD ADV ATE, AVA Standard smartcard SFRs describe: Protection of the test functionality Not available, and/or Harmless Protection against malfunctioning Prevention, and Detection Protection against leakage/tapping During transport, and During usage. . . brightsight® your partner in security approval page 12

Practical experience of CC 3. 1 ALC SFRs in smartcard hardware domain ASE AGD ADV ATE, AVA Standard smartcard SFRs describe: Protection of the test functionality Not available, and/or Harmless Protection against malfunctioning Prevention, and Detection Protection against leakage/tapping During transport, and During usage. . . Most properties of smartcard HW are SFRs, so must be in ADV_TDS, not in ADV_ARC brightsight® your partner in security approval page 14

Practical experience of CC 3. 1 ALC What do we do in ADV_ARC then? ASE AGD ADV ATE, AVA Our approach: In ADV_TDS describe the full design Including non-bypass & self-protection capabilities Physical countermeasures (even without real interfaces), Sidechannel countermeasures, etc In ADV_ARC describe: For each JIL attack method/path, describe why it cannot be used to bypass the TSF/SFRs I. e. why we cannot break the TSF with that method brightsight® your partner in security approval page 15

Practical experience of CC 3. 1 ALC What do we do in ADV_ARC then? ASE AGD ADV ATE, AVA Our approach: In ADV_TDS describe the full design Including non-bypass & self-protection capabilities Physical countermeasures (even without real interfaces), Sidechannel countermeasures, etc In ADV_ARC describe: For each JIL attack method/path, describe why it cannot be used to bypass the TSF/SFRs I. e. why we cannot break the TSF with that method Architecture becomes the developers reasoning explaining “why you have no chance attacking my TOE” (excellent starting information for evaluators and certifiers) brightsight® your partner in security approval page 16

Practical experience of CC 3. 1 ALC Guidance (AGD_OPE and AGD_PRE) ASE AGD ADV ATE, AVA Replaces CCv 2. 3 AGD_*+ADO_* Major changes: No “administrator” and “user”, now just “users in roles” Acceptance procedure user is included Devided in “Preparative procedures” (AGD_PRE) Receipt of TOE (checking it) Installation “Operational guidance” (AGD_OPE) Day to day running of the system brightsight® your partner in security approval page 21

Practical experience of CC 3. 1 ALC Preparative procedures (AGD_PRE) ASE AGD ADV ATE, AVA Describe acceptance process user should follow (former ADO) Checking that the product is the TOE (with all necessary version checks) Checking for modification/masquerading (And the users receiving procedure is checked against the developers shipping procedure in ALC_DEL) Describe installation steps Minimum system requirements for secure installation (? ) Requirements due to objectives for environment Any security settings Handling exceptions and problems (!) Mapped to shipping and first time startup guidance (more procedure oriented, “installation” does not fit smartcard HW life-cycle) brightsight® your partner in security approval page 22

Practical experience of CC 3. 1 ALC Operational user guidance (AGD_OPE) ASE AGD ADV ATE, AVA How to make “effective use” of the TSF Show modes of operation of the TO including modes after failure, and operational errors Cover “human visible TSFI” one at a time Cover all objectives for the operational environment Should be reasonable and clear Compared to CCv 2. 3 AGD No big changes Human user argument more explicit Mapped to programmers guidance (because the program has to follow these rules to make effective use of the TSF in operational use) brightsight® your partner in security approval page 23

Practical experience of CC 3. 1 ALC Delivery to customer ASE ADV AGD ATE, AVA Formerly known as ADO (More) explicitly covers everything from production to user Including warehousing! Checking of this process is more explicitly covered, by one of Site visit Getting the TOE from somewhere in the delivery process Buying the TOE and inspecting it Asking end-users how this is done Note: interacts with AGD_PRE (where the user’s side is checked whether it fits the sending procedures) brightsight® your partner in security approval page 25

Practical experience of CC 3. 1 ALC_DVS ASE ADV AGD ATE, AVA 1. Site security must be good Officially: Not defined what is good Unofficially: about the AVA_VAN level 2. + must argue why it is sufficient CCv 2. 3 interpretations (in smartcard domain) were different: ALC_DVS. 1 = Site security documentation needed, some security ALC_DVS. 2 = High security for development environment brightsight® your partner in security approval page 26

Practical experience of CC 3. 1 ALC Summary changes in ALC, ACM ASE ADV AGD ATE, AVA CCv 2. 3 to CCv 3. 1: Double work collapsed ALC_DVS. 2 interpretation has changed (? ) ALC_LCD. 2 shifted from “standardized” to “measureable” life-cycle More important change: Site certification Allows more re-usable and modular evaluation of sites Formalization of site visit re-use practices in smartcard domain Is likely to reduce site visit load significantly brightsight® your partner in security approval page 27

Practical experience of CC 3. 1 Theory: What has essentially changed? Life-cycle support (ALC) Security Target evaluation (ASE) Development (ADV) with FSP, TDS, IMP Guidance (AGD) Tests (ATE), Vulnerability Assessment (AVA_VAN) brightsight® your partner in security approval page 30

Practical experience of CC 3. 1 ALC ASE ST structure in CCv 2. 3 AGD ADV ATE, AVA Organizational Security Policies SARs Assurance Measures Security Functions Assumptions Sec. Objectives for the TOE Threats Sec. Objectives for Environment SFRs for IT Environment TOE Evaluation brightsight® your partner in security approval page 31

Practical experience of CC 3. 1 ALC ASE What is used in TOE evaluation in CCv 2. 3? AGD ADV ATE, AVA Organizational Security Policies SARs Assurance Measures Security Functions Assumptions Sec. Objectives for the TOE Threats Sec. Objectives for Environment SFRs for IT Environment TOE Evaluation brightsight® your partner in security approval page 32

Practical experience of CC 3. 1 ALC ASE ST structure in CCv 3. 1 AGD ADV ATE, AVA Organizational Security Policies Assumptions Assurance Rationale Sec. Objectives for the TOE Sec. Objectives Operational Environment SARs SFRs Threats TOE Evaluation brightsight® your partner in security approval page 33

Practical experience of CC 3. 1 ALC ASE What is used in TOE evaluation in CCv 3. 1? AGD ADV ATE, AVA Organizational Security Policies Assumptions Assurance Rationale Sec. Objectives for the TOE Sec. Objectives Operational Environment SARs SFRs Threats TOE Evaluation brightsight® your partner in security approval page 34

Practical experience of CC 3. 1 ALC ASE Essential change AGD ADV ATE, AVA Organizational Security Policies Assumptions Assurance Rationale Sec. Objectives for the TOE Sec. Objectives Operational Environment SARs SFRs Threats TOE Evaluation brightsight® your partner in security approval page 35

Practical experience of CC 3. 1 ALC Impact of changes in ASE/CCv 3. x (or: philosophical view) ASE AGD ADV ATE, AVA CCv 2. x structure and result: Tracing SFRs and Security Functions What the TOE does What requirements are to be met CCv 3. x structure and result: Tracing the SFRs Describe how the TOE is meeting the requirements Focus is now more on proving that the TOE meets the requirements (not that the TOE does something interesting) brightsight® your partner in security approval page 36

Practical experience of CC 3. 1 Clearer insight: Where does the extra effort/money in CC evaluations go? Life-cycle support (ALC) Security Target evaluation (ASE) Development (ADV) with FSP, TDS, IMP Guidance (AGD) Tests (ATE), Vulnerability Assessment (AVA_VAN) brightsight® your partner in security approval page 37

Practical experience of CC 3. 1 ALC ASE Summary AGD ADV ATE, AVA With existing SFRs, design (ADV_TDS) and architecture could overlap, but Describing how the JIL attacks are countered is a good basis for the architecture (ADV_ARC) evidence. Overhead of the “CC paperwork for the sake of paperwork” reduced Focus can now be more on proving that the TOE meets the requirements brightsight® your partner in security approval page 38

Practical experience of CC 3. 1 Impact for “standard” smartcard developer brightsight® your partner in security approval page 39

Practical experience of CC 3. 1 Questions? brightsight® your partner in security approval page 40

Practical experience of CC 3. 1 Contact information Note: the name “TNO ITSEF” has changed to “Brightsight” Brightsight BV Delftechpark 1 2628 XJ Delft The Netherlands Telephone: FAX: Email: Web: +31 -15 -269 2500 +31 -15 -269 2555 [email protected] com http: //www. brightsight. com/ brightsight® your partner in security approval page 41