Common Criteria methodology for Smart Cards and … Boudou.pdf · Common Criteria methodology for Smart Cards and Similar Devices ... ISCI - WG1 Methodology (ISCI-WG2) JHAS Attacks

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

[email protected]

SOG-IS Mutual Recognition Agreement

Joint InterpretationWorking Group (JIWG)

CCDB


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


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

ISCI WG1 2011 Contributors


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


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


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


�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


� 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


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


ARC guidance (composite evaluation)

Requirements

Security Target

Security FonctionalRequirements (SFR)

Security PropertiesSecurity Functions

Security architecture

Security Services

Domain SeparationNon-BypassabilitySecure InitializationSelf-Protection


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


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


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:


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

Documents

Common Criteria methodology for Smart Cards and … Boudou.pdf · Common Criteria methodology for Smart Cards and Similar Devices ... ISCI - WG1 Methodology (ISCI-WG2) JHAS Attacks