Common Criteria methodology for Smart Cards and Similar Devices
an overview of ISCI achievements
27 September 2011 12th ICCC Kuala-Lumpur 1
ISCI-WG1 - Eurosmart
Speaker : Alain Boudou
SOG-IS Mutual Recognition Agreement
Joint InterpretationWorking Group (JIWG)
CCDB
27 September 2011 12th ICCC Kuala-Lumpur 2
Smart Card & Similar DevicesTechnical Domain
Technical Community
ISCI - WG1Methodology
(ISCI-WG2) JHASAttacks
Supporting documentsinterpretation of CC
ISCI is a Eurosmart initiative
Eurosmart– International non-profit association founded in 1995 in Brussels– 30 companies of the Smart Security industry (smart card manufacturers, semiconductors,
terminals, issuers)
Smart Secure Devices & Systems promotion
27 September 2011 12th ICCC Kuala-Lumpur 3
Need for a universal framework for security evaluation and certification
Fair, high quality, comparable, standardised evaluations
Adapted to the technology and market
Continuous improvement of the efficiency and cost effectiveness of the process
A common objective with JIWG:
Consistent application of the criteria and methods between national schemes
Benefit of this Technical Community
• A common objective: efficiency improvement, consistent application
• A concensus on the needs: which direction?
• A concensus on the methods: how to interpret CC?
• An implementation keeping the process applicable
• A common understanding and agreement expressed in supporting documents
• An environment promoting the emergence of usefull and applicable PPs
27 September 2011 12th ICCC Kuala-Lumpur 5
Smart cards & Similar Devices Technical Domain
Attackers have physical access to devicesA part of security functionality is devoted to self protection
Devices implement crypto services & secretsA specific lifecycle of the devices
Balance vulnerability analysis
27 September 2011 12th ICCC Kuala-Lumpur 6
Make clear the security properties
Balance vulnerability analysisand compliance analysis
Open products certification
Take into account the evolution
ARC guidance
Collection of evidences
(Next presentation)
Open product certification (1)
Composite product evaluation
CCDB-2007-09-001
Application
Platform guide guide
Pre-issuance
Post-issuance
Open Platform
Applications
27 September 2011 12th ICCC Kuala-Lumpur 7
�Standard evaluation imposes to consider all other applications
�Independent certificate approach focus on the application to be certified� with the restriction: evaluation results remains valid only when all otherapplications respect the platform certification constraints
�Some of the other applications maybe not known at evaluation time�Applications may be combined in a large number of configurations�Some configurations may include applis with independent certificates�Platform evaluation anticipates the evolution of the product
ApplicationCertificate
Benefit:
� Objectives for the TOE
� Protection against hostile application: �isolation between all applications and between applications and platform
� Controlled loading:
�Issuer authentication and integrity/authenticity of application before installation
What are the platform certification constraints ?
PlatformCertificate
27 September 2011 12th ICCC Kuala-Lumpur 8
� Objective for the environment�All applications have to be verified respecting the platform guide related to isolation
� Availabilty of authenticity and integrity evidence for each application
� Product samples with identification of the TOE components and out of TOE components
� Guidance
� related to isolation property preservation (verification)
� related to controlled loading
Phase 1
TO
E c
onst
ruct
ion
CC Delivery
Traditional lifecycle Controlledloading
Verification
Audit Check evidence
Check evidenceOr
Org. measures
Environment
27 September 2011 12th ICCC Kuala-Lumpur 9
Postissuance
Open Platform
Phase 6
Phase 7
TO
E c
onst
ruct
ion
TO
E u
sagePre-issuance
Delivery toEnd user
OrAssumption
Assumption
Assumption
Tech. measures
Check evidenceOr
Assumption
Controlled loading sec. function.
Isolation sec. function.
Identification
TOE
Open product certification (4)
• The Certification Body guarantees that:
� Applications are protected against each other by isolation
(under the assumption of verification)
� Non-verified application cannot resides on the platform� Non-verified application cannot resides on the platform
(under the assumption of controlled loading )
� Assumptions are recalled in the « usage restrictions » chapter of the certification report
• It’s up to the product risk manager to rely on assumpti ons
27 September 2011 12th ICCC Kuala-Lumpur 10
ARC guidance (composite evaluation)
Requirements
Security Target
Security FonctionalRequirements (SFR)
Security PropertiesSecurity Functions
Security architecture
Security Services
Domain SeparationNon-BypassabilitySecure InitializationSelf-Protection
27 September 2011 12th ICCC Kuala-Lumpur 11
Security Target
Description
Implementation
Security Features
Security Properties(ASE_TSS.2)
Security Functions(ASE_TSS.1)
ADV_TDS.3 ADV_ARC
Security Mechanisms
Security Servicesoffer by platform
How the TOE intends to thwart attacks
• Domain separation� Access of active entities to resources is maintained separated from each other� Access to resources from different domains is controlled by SFR� Domain separation maybe maintained by by Plateform (Security Services).
Domains are instantiated for applications
OS / ES OS
isolation
OS
isolation
Application
27 September 2011 12
IC
Integrated product(0 domain)
IC
Platform of a layered product (2 domains)
IC
Layered product(2 domains)
AppliC code
IC
JCS
isolation
OS
IC
OS / JCS
isolation
IC
OS / JCS
isolation
Applications
Multi application platform (n domains)
Multi application product (n domains)
Hybrid product(n + 1 domains)
Usage phaseEvaluated configuration
Low-function mode
Not evaluated configuration
(Delivery)
Development phase
Power onReset
Secure StateFull TSF
Power off Savepowermode
• Secure Initialization
27 September 2011 12th ICCC Kuala-Lumpur 13
Describe the process of Init.List the involved components In the secure state Init. components are
• not reachable• not usable for tampering from TSFI
Initialization code maintain:•TSF integrity• initialisation process integrity
In the secure state the not-evaluatedlow-function mode
• services are not accessible• code is prevented from running
Self
-pro
tect
Self
-pro
tect
Secu
re I
nit
• Non-Bypassability
Documentedoperations
SFR-enforcing: high level entity
SFR-enforcing
TSFIFunctionnal Interface
Case 2
Not documentedoperationsOther entities
out of TSF
Not documented interfaces
27 September 2011 12th ICCC Kuala-Lumpur 14
SFR-enforcinglow level entity
Other module
Protected objectNot Protected object
Case 1
Case 4
Case 3
Case 1: exploit undocumented mode or operation of TSFI Case 3: exploit undocumented functional interface
Case 2: exploit insufficient design or implementation Case 4: exploit side channel
ADV_FSP & TDS with EAL4+ ADV_ARC
• Self-Protection
Manipulation from external entities by the way of:
� the electrical ports
� the surface� hostile applications
TSF is protected by:
27 September 2011 12th ICCC Kuala-Lumpur 15
Open Platform
�Sec. Mech. implementing SFRs
�Sec. Mech. not directly observable from TSFI
�Sec. Mech. spreaded design countermeasures
�Domains (isolation)
�Binding of Sec. Mech.
�Combination of HW & SW Sec. Mech.
�Sharing of responsibility between Applis & PlatformTO
E
ARC Guidance
• Security Architecture (ADV_ARC) for smart cards and similardevices supporting document– Including specificities for composite evaluation– Mandatory part: ADV_ARC requirements for the developer– Informative part:
� Guideline & explanations� Examples� ADV_ARC Template
21 September 2010 11th ICCC Antalya 16
Chapter 2Security services & mechanisms
Chapter 5 & 6Side channel & manipulation
Chapter 7Protection against attacks
SS.3
SM.2
SS.1
SS.3
SS.1SM.2
SM.4SM.2
SF.2
SF.1Attack Path A
Attack Path A
Attack Path A