practical experience of cc3.1 applied on smartcard hardware wouter slegers + 31 15 269 2500...
TRANSCRIPT
Practicalexperience of
CC3.1 applied on smartcard hardware
Wouter Slegers+ 31 15 269 2500
Practical experience of CC3.1
page 3brightsight® your partner in security approval
Presentation Targets
Describe our experiences with CCv3.1 Release 1 on a smartcard ICPractice:
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?
Practical experience of CC3.1
page 4brightsight® your partner in security approval
Summary(or: teaser)
The 10.000 feet view:
Essentially, not much has changedThis is the good and the bad news
Practical experience of CC3.1
page 5brightsight® your partner in security approval
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.
Practical experience of CC3.1
page 6brightsight® your partner in security approval
Setting and background
Experienced developer, entry into CC world:No existing CCv2.x legacy documentationChoice for new CCv3.x to be at cutting edgeAccepting 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.xCCv3.1 upgrade of PP and methodology not available at the timeProceeded 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
Practical experience of CC3.1
page 7brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS, IMP, ARC
Guidance(AGD)
Security Target
evaluation (ASE)
Evaluation experience so far
Practical experience of CC3.1
page 8brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS, IMP, ARC
Guidance(AGD)
Security Target
evaluation (ASE)
Most interesting parts(with respect to impact of the CCv3.1 changes)
Practical experience of CC3.1
page 9brightsight® your partner in security approval
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-bypassIncludes side channel analysis
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 10brightsight® your partner in security approval
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-bypassIncludes side channel analysis
ALC
ATE, AVA
ADV AGDASE
Essentially sums up what property of smartcard HW we test:To keep secrets secret,
except when the software outputs them
Practical experience of CC3.1
page 11brightsight® your partner in security approval
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
ADV AGDASE
Practical experience of CC3.1
page 12brightsight® your partner in security approval
SFRs in smartcard hardware domain
Standard smartcard SFRs describe:Protection of the test functionality
Not available, and/orHarmless
Protection against malfunctioningPrevention, and Detection
Protection against leakage/tappingDuring transport, andDuring usage
...
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 13brightsight® your partner in security approval
SFRs in smartcard hardware domain
Standard smartcard SFRs describe:Protection of the test functionality
Not available, and/orHarmless
Protection against malfunctioningPrevention, and Detection
Protection against leakage/tappingDuring transport, andDuring usage
...
ALC
ATE, AVA
ADV AGDASE
Also describes what propertyof smartcard HW we test:To keep secrets secret,
except when the software outputs them
Practical experience of CC3.1
page 14brightsight® your partner in security approval
SFRs in smartcard hardware domain
Standard smartcard SFRs describe:Protection of the test functionality
Not available, and/orHarmless
Protection against malfunctioningPrevention, and Detection
Protection against leakage/tappingDuring transport, andDuring usage
...
ALC
ATE, AVA
ADV AGDASE
Most properties of smartcard HW are SFRs,so must be in ADV_TDS, not in ADV_ARC
Practical experience of CC3.1
page 15brightsight® your partner in security approval
What do we do in ADV_ARC then?
Our approach: In ADV_TDS describe the full design
Including non-bypass & self-protection capabilitiesPhysical 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/SFRsI.e. why we cannot break the TSF with that method
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 16brightsight® your partner in security approval
What do we do in ADV_ARC then?
Our approach: In ADV_TDS describe the full design
Including non-bypass & self-protection capabilitiesPhysical 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/SFRsI.e. why we cannot break the TSF with that method
ALC
ATE, AVA
ADV AGDASE
Architecture becomes the developers reasoning explaining“why you have no chance attacking my TOE”
(excellent starting information for evaluators and certifiers)
Practical experience of CC3.1
page 20brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS, IMP, ARC
Guidance(AGD)
Security Target
evaluation (ASE)
Most interesting parts(with respect to impact of the CCv3.1 changes)
Practical experience of CC3.1
page 21brightsight® your partner in security approval
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
ADV AGDASE
Practical experience of CC3.1
page 22brightsight® your partner in security approval
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 stepsMinimum system requirements for secure installation (?)Requirements due to objectives for environmentAny security settingsHandling exceptions and problems (!)
ALC
ATE, AVA
ADV AGDASE
Mapped to shipping and first time startup guidance(more procedure oriented, “installation” does not fit smartcard HW life-cycle)
Practical experience of CC3.1
page 23brightsight® your partner in security approval
Operational user guidance (AGD_OPE)
How to make “effective use” of the TSFShow modes of operation of the TO
including modes after failure, andoperational errors
Cover “human visible TSFI” one at a timeCover all objectives for the operational environmentShould be reasonable and clear
Compared to CCv2.3 AGDNo big changesHuman user argument more explicit
ALC
ATE, AVA
ADV AGDASE
Mapped to programmers guidance(because the program has to follow these rules
to make effective use of the TSF in operational use)
Practical experience of CC3.1
page 24brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS, IMP, ARC
Guidance(AGD)
Security Target
evaluation (ASE)
Most interesting parts(with respect to impact of the CCv3.1 changes)
Practical experience of CC3.1
page 25brightsight® your partner in security approval
Delivery to customer
Formerly known as ADO
(More) explicitly covers everything from production to userIncluding warehousing!
Checking of this process is more explicitly covered, by one ofSite visitGetting the TOE from somewhere in the delivery processBuying the TOE and inspecting itAsking 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
ADV AGDASE
Practical experience of CC3.1
page 26brightsight® your partner in security approval
ALC_DVS
1. Site security must be goodOfficially: Not defined what is goodUnofficially: 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 securityALC_DVS.2 = High security for development environment
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 27brightsight® your partner in security approval
Summary changes in ALC, ACM
CCv2.3 to CCv3.1:Double work collapsedALC_DVS.2 interpretation has changed (?)ALC_LCD.2 shifted from “standardized” to “measureable” life-cycle
More important change: Site certificationAllows more re-usable and modular evaluation of sitesFormalization of site visit re-use practices in smartcard domainIs likely to reduce site visit load significantly
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 30brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS,
IMP
Guidance(AGD)
Security Target
evaluation (ASE)
Theory:What has essentially changed?
Practical experience of CC3.1
page 31brightsight® your partner in security approval
ThreatsOrganizational
Security Policies
Assumptions
SFRsAssuranceMeasures
Sec. Objectivesfor the TOE
Sec. Objectivesfor
Environment
TOE Evaluation
SARs
SFRsfor
IT Environment
SecurityFunctions
ST structure in CCv2.3
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 32brightsight® your partner in security approval
AssuranceMeasures
Sec. Objectivesfor the TOE
ThreatsOrganizational
Security Policies
Assumptions
SFRs
Sec. Objectivesfor
Environment
TOE Evaluation
SARs
SFRsfor
IT Environment
SecurityFunctions
What is used in TOE evaluation in CCv2.3?
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 33brightsight® your partner in security approval
ThreatsOrganizational
Security Policies
Assumptions
SFRsSARs
Sec. Objectivesfor the TOE
Sec. ObjectivesOperationalEnvironment
TOE Evaluation
AssuranceRationale
ST structure in CCv3.1
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 34brightsight® your partner in security approval
ThreatsOrganizational
Security Policies
Assumptions
Sec. Objectivesfor the TOE
SFRsSARs
Sec. ObjectivesOperationalEnvironment
TOE Evaluation
AssuranceRationale
What is used in TOE evaluation in CCv3.1?
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 35brightsight® your partner in security approval
ThreatsOrganizational
Security Policies
Assumptions
Sec. Objectivesfor the TOE
SFRsSARs
Sec. ObjectivesOperationalEnvironment
TOE Evaluation
AssuranceRationale
Essential change
ALC
ATE, AVA
ADV AGDASE
Practical experience of CC3.1
page 36brightsight® your partner in security approval
Impact of changes in ASE/CCv3.x(or: philosophical view)
CCv2.x structure and result:Tracing SFRs and Security FunctionsWhat the TOE doesWhat requirements are to be met
CCv3.x structure and result:Tracing the SFRsDescribe how the TOE is meeting the requirements
ALC
ATE, AVA
ADV AGDASE
Focus is now more onproving that the TOE meets the requirements(not that the TOE does something interesting)
Practical experience of CC3.1
page 37brightsight® your partner in security approval
Life-cycle support (ALC)
Tests (ATE),Vulnerability Assessment (AVA_VAN)
Development(ADV) withFSP, TDS,
IMP
Guidance(AGD)
Security Target
evaluation (ASE)
Clearer insight:Where does the extra effort/money in CC evaluations go?
Practical experience of CC3.1
page 38brightsight® your partner in security approval
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
ADV AGDASE
Focus can now be more onproving that the TOE meets the requirements
Practical experience of CC3.1
page 39brightsight® your partner in security approval
Impact for “standard”smartcard developer
Assurance components by Evaluation Assurance level
Assurance class
Assurance family
EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7
ADV_ARC 1 1 1 1 1 1 ADV_FSP 1 2 3 4 5 5 6 ADV_IMP 1 1 2 2 ADV_INT 2 3 3 ADV_SPM 1 1
Development
ADV_TDS 1 2 3 4 5 6 AGD_OPE 1 1 1 1 1 1 1 Guidance
documents AGD_PRE 1 1 1 1 1 1 1 ALC_CMC 1 2 3 4 4 5 5 ALC_CMS 1 2 3 4 5 5 5 ALC_DEL 1 1 1 1 1 1 ALC_DVS 1 1 1 2 2 ALC_FLR ALC_LCD 1 1 1 1 2
Life-cycle support
ALC_TAT 1 2 3 3 ASE_CCL 1 1 1 1 1 1 1 ASE_ECD 1 1 1 1 1 1 1 ASE_INT 1 1 1 1 1 1 1 ASE_OBJ 1 2 2 2 2 2 2 ASE_REQ 1 2 2 2 2 2 2 ASE_SPD 1 1 1 1 1 1
Security Target Evaluation
ASE_TSS 1 1 1 1 1 1 1 ATE_COV 1 2 2 2 3 3 ATE_DPT 1 2 3 3 4 ATE_FUN 1 1 1 1 2 2
Tests
ATE_IND 1 2 2 2 2 2 3 Vulnerability Assessment
AVA_VAN 1 2 2 3 4 5 5
Practical experience of CC3.1
page 40brightsight® your partner in security approval
Questions?
Practical experience of CC3.1
page 41brightsight® your partner in security approval
Contact information
Note: the name “TNO ITSEF”has changed to “Brightsight”
Brightsight BVDelftechpark 12628 XJ DelftThe Netherlands
Telephone: +31-15-269 2500FAX: +31-15-269 2555Email: [email protected]: http://www.brightsight.com/