practical experience of cc3.1 applied on smartcard hardware wouter slegers + 31 15 269 2500...

Practicalexperience of

CC3.1 applied on smartcard hardware

Wouter Slegers+ 31 15 269 2500

[email protected]

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?



Summary(or: teaser)

The 10.000 feet view:

Essentially, not much has changedThis is the good and the bad news



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.



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



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






Guidance(AGD)

Security Target

evaluation (ASE)

Most interesting parts(with respect to impact of the CCv3.1 changes)



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



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



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



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








...

ALC

ATE, AVA

ADV AGDASE

Also describes what propertyof smartcard HW we test:To keep secrets secret,

except when the software outputs them








...

ALC

ATE, AVA

ADV AGDASE

Most properties of smartcard HW are SFRs,so must be in ADV_TDS, not in ADV_ARC



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



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)






Guidance(AGD)

Security Target

evaluation (ASE)




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



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)



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)






Guidance(AGD)

Security Target

evaluation (ASE)




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



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



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





Development(ADV) withFSP, TDS,

IMP

Guidance(AGD)

Security Target

evaluation (ASE)

Theory:What has essentially changed?



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



AssuranceMeasures



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




Security Policies

Assumptions

SFRsSARs


Sec. ObjectivesOperationalEnvironment

TOE Evaluation

AssuranceRationale

ST structure in CCv3.1

ALC

ATE, AVA

ADV AGDASE




Security Policies

Assumptions


SFRsSARs


TOE Evaluation

AssuranceRationale

What is used in TOE evaluation in CCv3.1?

ALC

ATE, AVA

ADV AGDASE




Security Policies

Assumptions


SFRsSARs


TOE Evaluation

AssuranceRationale

Essential change

ALC

ATE, AVA

ADV AGDASE



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)





Development(ADV) withFSP, TDS,

IMP

Guidance(AGD)

Security Target

evaluation (ASE)

Clearer insight:Where does the extra effort/money in CC evaluations go?



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



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



Questions?



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/

practical experience of cc3.1 applied on smartcard hardware wouter slegers + 31 15 269 2500...

Documents

security domains

security approvalsummaryor

security approvalsetting

security approvalxxx

security approvalthis

arcversus design adv

new ccv3

eurosmart pp bsipp