1. Practical experience of CC3.1 applied on smartcard hardware Wouter Slegers + 31 15 269 2500 Slegers@brightsight.com www.brightsight.com

2. page 2brightsight ® your partner in security approval Practical experience of CC3.1 XXX For internal reference. Version d.d. 2007-09-20 Author and course maintainer: Wouter. Please feed back changes to him. Biggest changes since N/A: New version See notes for trainer information Additional improvements to do: Cost analysis (vs CAST-like evaluations)

3. page 3brightsight ® your partner in security approval Practical experience of CC3.1 Presentation Targets Describe our experiences with CCv3.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?

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

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

6. page 6brightsight ® your partner in security approval Practical experience of CC3.1 Setting and background Experienced developer, entry into CC world: No existing CCv2.x legacy documentation Choice for new CCv3.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 CCv2.x CCv3.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

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

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

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

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

11. page 11brightsight ® your partner in security approval Practical experience of CC3.1 Architecture (ADV_ARC) versus design (ADV_TDS) 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? ALC ATE, AVA ADVAGD AS E

12. page 12brightsight ® your partner in security approval Practical experience of CC3.1 SFRs in smartcard hardware domain 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... ALC ATE, AVA ADVAGD AS E

13. page 13brightsight ® your partner in security approval Practical experience of CC3.1 SFRs in smartcard hardware domain 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... ALC ATE, AVA ADVAGD AS E Also describes what property of smartcard HW we test: To keep secrets secret, except when the software outputs them

14. page 14brightsight ® your partner in security approval Practical experience of CC3.1 SFRs in smartcard hardware domain 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... ALC ATE, AVA ADVAGD AS E Most properties of smartcard HW are SFRs, so must be in ADV_TDS, not in ADV_ARC

15. page 15brightsight ® your partner in security approval Practical experience of CC3.1 What do we do in ADV_ARC then? 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 ALC ATE, AVA ADVAGD AS E

16. page 16brightsight ® your partner in security approval Practical experience of CC3.1 What do we do in ADV_ARC then? 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 ALC ATE, AVA ADVAGD AS E Architecture becomes the developers reasoning explaining “why you have no chance attacking my TOE” (excellent starting information for evaluators and certifiers)

17. page 17brightsight ® your partner in security approval Practical experience of CC3.1 ADV_FSP/ADV_TDS experiences Labelling: SFR-enforcing Criterium: Directly implements the SFRs SFR-supporting Everything that the SFR-enforcing parts depend on Criterium: If you remove that part and the SFR-enforcing parts do not function anymore, it is SFR-supporting SFR-non-interfering None of the above, but could impact the SFRs Criterium: if this part misbehaves or is hostile, it can influence the above. None of the above: TOE but not TSF ALC ATE, AVA ADVAGD AS E

18. page 18brightsight ® your partner in security approval Practical experience of CC3.1 ADV_FSP/ADV_TDS experiences Labelling: SFR-enforcing Criterium: Directly implements the SFRs SFR-supporting Everything that the SFR-enforcing parts depend on Criterium: If you remove that part and the SFR-enforcing parts do not function anymore, it is SFR-supporting SFR-non-interfering None of the above, but could impact the SFRs Criterium: if this part misbehaves or is hostile, it can influence the above. None of the above: TOE but not TSF ALC ATE, AVA ADVAGD AS E No clear separation

19. page 19brightsight ® your partner in security approval Practical experience of CC3.1 Legend: A = Provide argument S = Summary D = Description Bold = new requirement compared to previous EAL ALC ATE, AVA ADVAGD AS E But the differences in evaluation are minimal

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

21. page 21brightsight ® your partner in security approval Practical experience of CC3.1 Guidance (AGD_OPE and AGD_PRE) Replaces CCv2.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 ALC ATE, AVA ADVAGD AS E

22. page 22brightsight ® your partner in security approval Practical experience of CC3.1 Preparative procedures (AGD_PRE) 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 (!) ALC ATE, AVA ADVAGD AS E Mapped to shipping and first time startup guidance (more procedure oriented, “installation” does not fit smartcard HW life-cycle)

23. page 23brightsight ® your partner in security approval Practical experience of CC3.1 Operational user guidance (AGD_OPE) 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 CCv2.3 AGD No big changes Human user argument more explicit ALC ATE, AVA ADVAGD AS E Mapped to programmers guidance (because the program has to follow these rules to make effective use of the TSF in operational use)

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

25. page 25brightsight ® your partner in security approval Practical experience of CC3.1 Delivery to customer 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) ALC ATE, AVA ADVAGD AS E

26. page 26brightsight ® your partner in security approval Practical experience of CC3.1 ALC_DVS 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 CCv2.3 interpretations (in smartcard domain) were different: ALC_DVS.1 = Site security documentation needed, some security ALC_DVS.2 = High security for development environment ALC ATE, AVA ADVAGD AS E

27. page 27brightsight ® your partner in security approval Practical experience of CC3.1 Summary changes in ALC, ACM CCv2.3 to CCv3.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 ALC ATE, AVA ADVAGD AS E

28. page 28brightsight ® your partner in security approval Practical experience of CC3.1 Life-cycle support (ALC), Configuration Management (ACM) Tests (ATE), Vulnerability Assessment (AVA) Development (ADV) with FSP, HLD, LLD, IMP, RCR Delivery and operation (ADO), Guidance (AGD) Security Target evaluation (ASE) Assurance Measures in CCv2.3

29. page 29brightsight ® your partner in security approval Practical experience of CC3.1 Life-cycle support (ALC) Tests (ATE), Vulnerability Assessment (AVA_VAN) Development (ADV) with FSP, TDS, IMP, ARC Guidance (AGD) Security Target evaluation (ASE) Assurance Measures in CCv3.1

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

31. page 31brightsight ® your partner in security approval Practical experience of CC3.1 Threats Organizational Security Policies Assumptions SFRs Assurance Measures Sec. Objectives for the TOE Sec. Objectives for Environment TOE Evaluation SARs SFRs for IT Environment Security Functions ST structure in CCv2.3 ALC ATE, AVA ADVAGD AS E

32. page 32brightsight ® your partner in security approval Practical experience of CC3.1 Assurance Measures Sec. Objectives for the TOE Threats Organizational Security Policies Assumptions SFRs Sec. Objectives for Environment TOE Evaluation SARs SFRs for IT Environment Security Functions What is used in TOE evaluation in CCv2.3? ALC ATE, AVA ADVAGD AS E

33. page 33brightsight ® your partner in security approval Practical experience of CC3.1 Threats Organizational Security Policies Assumptions SFRsSARs Sec. Objectives for the TOE Sec. Objectives Operational Environment TOE Evaluation Assurance Rationale ST structure in CCv3.1 ALC ATE, AVA ADVAGD AS E

34. page 34brightsight ® your partner in security approval Practical experience of CC3.1 Threats Organizational Security Policies Assumptions Sec. Objectives for the TOE SFRsSARs Sec. Objectives Operational Environment TOE Evaluation Assurance Rationale What is used in TOE evaluation in CCv3.1? ALC ATE, AVA ADVAGD AS E

35. page 35brightsight ® your partner in security approval Practical experience of CC3.1 Threats Organizational Security Policies Assumptions Sec. Objectives for the TOE SFRsSARs Sec. Objectives Operational Environment TOE Evaluation Assurance Rationale Essential change ALC ATE, AVA ADVAGD AS E

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

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

38. page 38brightsight ® your partner in security approval Practical experience of CC3.1 Summary 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 ALC ATE, AVA ADVAGD AS E Focus can now be more on proving that the TOE meets the requirements

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

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

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