March 2001
Tokyo Smartcard Security
Conference

Smartcard Platform Certification
Using the Common Criteria
Issues & Opportunities
Alain Jarre

STMicroelectronics

Agendaq Introduction
q Evaluation and Certification Parties
q From Protection Profile (PP) to Security Target (ST)ü PP, TOE, Assurance level, Augmentation, ST

q Evaluation and certification processq Examples & comments on CC & PP’s.
q New initiatives GlobalPlatform - eEurope
q Conclusions

MPG – PTSC0010 – 010 – 21

Evaluation and Certification
The SchemePolicy
Certification Body

Management Board• Scheme policy arbitration• Scheme operationAccreditation Body

• Evaluation facility

Licensingcertificate

licensing

Accreditation
certificate• Evaluation
monitoring• Certification

Evaluation Facility• Conduct of IT

security evaluation
Work planevaluation
Anomaly
Anomaly reportreportETR
Anomaly report
Deliverables

Certificate
Certification
reportSponsor• Evaluation facility
accreditation

Deliverables
Work plan evaluation
Anomaly report
ETR

Deliverables

Developer• Target of evaluation• Evaluation start up

development

Anomaly reportand funding• Deliverables production

MPG – PTSC0010 – 010 – 3

Evaluation and Certification
example of partnershipPolicy
Certification Body

Management Board• Scheme policy arbitration
Accreditation Body

SCSSI

Certificate
Certification
reportLicensingcertificate
Deliverables
Work plan evaluation
Anomaly report
ETRWork planevaluation
Anomaly report
ETR

Sponsor

STMicroelectronics

Accreditation
certificate
COFRAC
Evaluation Facility
Serma Technology

AnomalyreportAnomaly report
Deliverables

Anomaly report

Deliverables

Developer

STMicroelectronics

MPG – PTSC0010 – 010 – 42

Protection Profileq What is a Protection Profile?
ü An implementation-independent set of S ecurity Requirements for acategory of products(T O E s ) which meet specific category of u s e r s n e e d s

q PP/9806 is the Protection Profile used up to now forS martcard Ics.

q PP9911 is the one used for single applications
q Many others are under evaluation.
q Some PP’s are used to “filter” the architectures andfunctional specifications. Open Kernel – MASSC(MedeaA1112)
MPG – PTSC0010 – 010 – 5

Security Requirements
q Functional requirements
ü Desired security behavior of the TOE

q Assurance requirements
ü Grounds for confidence that the TOE meets its security objective s
IT Security RequirementsFunctional Requirements

Functional Package

Assurance Requirements

Assurance Package, i.e. EALs

Protection Profile/Security Target

MPG – PTSC0010 – 010 – 63

Examples of Security Requirements
q Functional requirements
ü FIA – user identification and authentication before allowing use ofother TOE security functions

ü F P T – notification of physical attack
providing unambiguous detection of physical tamperingq Assurance requirements
ü A D V – stepwise refinement from the summary specification in thesecurity target down to the actual implementation

ü A G D – understandability and coverage of the operational
documentation provided by the developer

MPG – PTSC0010 – 010 – 7Assurance Level
q EAL7 = Formally verified design and tested
q EAL6 = Semi -formally verified design and tested
q EAL5 = Semi -formally verified design and tested
q EAL4 = Methodically designed, tested and reviewed
q EAL3 = Methodically tested and checked
q EAL2 = Structurally tested
q EAL1 = Functionally tested

MPG – PTSC0010 – 010 – 84Augmentation
q Assurance requirements
ü Classesv

ACM – Configuration managementv

A D O – Deliver and O perationv

A D V – Developmentv

AGD – Guidance document sv

A L C – Life Cycle supportv

ATE – T e s t sv

AVA – Vulnerabilities A ssessment

ü Additional Assurance requirements for ST19SFxx platform ( E A L 4 ) arev

ADV_IMP.2 (from EAL5)v

A L C _ D V S . 2 (from E A L 6 )v

A V A _ V L A . 4 (f r o m E A L 6 )MPG – PTSC0010 – 010 – 9TOE PhysicalProtection

Environment

Required Assets

Assumptions

Threats

Environment Objectives

Functional Requirements

Security Functions

TOE Purpose

ST Introduction
TOE Description

Organizational

TOE Security

Security Policies

Environment

TOE Objectives

Assurance
Requirements

Assurance Measures

Security Objectives

IT Security
Requirements

ST Chapters

PP Chapters

From Protection Profile
to Security Target

TOE Summary

PP Chapters

Specification

External Reference

PP Claims

Internal Coherence

Rationale

MPG – PTSC0010 – 010 – 105

Evaluation / Certification Steps
Maintenance
Maintenance

Certification

Approbation

Report& Certification& Certificate

Evaluation

Evaluation
Technical
ReportPreparation to
the Evaluation

CLASSIFIED
Evaluation

DOCUMENTS

Documents

Target

MPG – PTSC0010 – 010 – 11

Global Platform Card Committee
q OPEN KERNEL Working Groupq More representative of industry
q Chip manufacturers
ü Hitachi
ü Infineon
ü Philips
ü ST

q Card suppliers & Others
ü Bullü Datacard Platform 7
ü OCS
ü Gemplus

MPG – PTSC0010 – 010 – 126

Open Kernel Architecture
Optional

Optional

Mandatory

Application framework
I/O, Control, Loader
Services for state dependant behavior
I/O, allocation, defragmentationtransaction
I/O
Storage
Crypto
Timer
Clock
IT
Error management
BootFramework

Libraries

HardwareAbstraction
Layer

Integrated Circuit
MPG – PTSC0010 – 010 – 13List of OK deliverables
q OK general specification
é Blue layer specification: HAL
é Red layer specification: libraries
é Black layer specification: framework

q OK Protection Profileé Guideline and/or Protection ProfileqOK detailed specification: semi-formal modelq

OK testing methodé link with other working groups

MPG – PTSC0010 – 010 – 147

Overview the current PP’s scenario
PP9911
Application Layer
Operating System Layer

Visa OP PPSCSUG PPSLB PP ?

Open Kernel Layer

GP OK PP

Hardware Layer

PP9806
SSVG

PP/0001

Plus: MEDEA A112 PP’s and other applications PP’s
MPG – PTSC0010 – 010 – 15

OK on security approach (1)q Is a new PP really required ???
q PP: Security Functional +AssuranceRequirements
q No market standard requirements for security level.
q If PP: assumptions are necessary on upper levels
q A guideline defining security functions needed in OK will help
to define new PP and even the ST.

q Both will perhaps be necessary

MPG – PTSC0010 – 010 – 168

OK on security approach (2)q Security issues are handled by security and Common Criteria
expert members (some ESWGs ).

q Plenary and dedicated meeting on the subject.
q Technical writing by Datacard experts (formal SW evaluators).

MPG – PTSC0010 – 010 – 17Another experience for cryptographicmodules
q Summary of CygnaCom Experience in Developing
Cryptography based Systems PPs and STs

q Examples of comparison with FIPS 140 .

Source: CygnaCom

MPG – PTSC0010 – 010 – 189

FIPS 140-1/2 and CC Differences
q FIPS 140-1/2 contain specific security requirements for acryptomodule which may be included in a product. CCspecifies generic requirements for a security product orsystem.

q FIPS 140-1/2 tries to minimize security analysis performedby testing laboratories. CC requires testing laboratories todetermine what is good enough to meet the genericrequirement.

q FIPS 140-1/2 is more specific but less flexible. FIPS
techniques will become outdated over time. CC is moreflexible but requires more interpretation and evaluation.
Source: CygnaCom
MPG – PTSC0010 – 010 – 19

FIPS 140-1/2 and CC Differences(Concluded)
q FIPS 140-1/2 testing laboratories are accredited by NISTand CSE. CC testing laboratories in U.S. are accredited
by NIAP (NIST and NSA).

q FIPS 140-1/2 is recognized by U.S. and Canada. CC
testing is recognized by U.S., Canada, France, Germany,UK, Australia, and News Zealand.

q FIPS 140-1/2 specifies a four levels of cryptomodulesecurity. CC specifies the criteria whereby security
functionality and assurance can be specified.
Source: CygnaCom
MPG – PTSC0010 – 010 – 2010

FIPS 140-1/2 and CC Differences:
Examplesq FIPS requires specific cryptomodule states (e.g., power
on/off, crypto officer, key-CSP entry, user, and error). CCis not specific to cryptomodules.

q FIPS has specific maintenance role requirements for keyand CSP protection. CC does not mention maintenancerole.

q FIPS has specific physical security requirements such as
hard opaque tamper evident coatings, seals, physicallocks, and key zeroization. CC requires detection,
notification, and response but no specific physicalfeatures.
Source: CygnaCom
MPG – PTSC0010 – 010 – 21

FIPS 140-1/2 and CC Differences:
Examples (Continued)
q FIPS distinguishes three cryptomodule embodiments eachhaving different requirements. CC does not distinguishbetween embodiments.

q FIPS distinguishes security levels by adding additionalrequirements. CC distinguishes physical security levels asdetection, notification, and response.

q FIPS 140-1 deals primarily with the functions of the vendor
product. CC also covers assurance requirements forconfiguration management, delivery, operation,development, and life cycle support.

Source: CygnaCom
MPG – PTSC0010 – 010 – 2211

FIPS 140-1/2 and CC Differences:
Examples (Concluded)
q FIPS 140-1 has minimal audit requirements. CC
has extensive audit requirements. FIPS 140-2 willhave more audit requirements.

q FIPS 140-1/2 requires a semiformal security
policy model. CC allows for informal, semiformal,
and formal security policy models.

Source: CygnaCom

MPG – PTSC0010 – 010 – 23

Observation: TOE Definition
Cryptographic Application -- TSF
Operating System -- TOE

Hardware -- TOE

CryptographicModule** TOE, TSF, or Environmental Assumption
Source: CygnaCom

MPG – PTSC0010 – 010 – 24

12

ScopeSC-TB3E- Gov

E-paym.

HealthPublicTransport

Generic functions: ID, Digital signature
Multiapplication
applicationPlatform
Platform
Multi
GenericCardreaderCardreader
GenericSS
EE
CC
UU
RR
IITT
YY//PPPPContactless
ContactlessUU
SS
EE
RRIINN
TT
EE
RRFF
AA
CC
EE

MPG – PTSC0010 – 010 – 25

SC-TB3Mission

q The mission of the trailblazer 3 working group is topromote and facilitate the adoption of the Common
Criteria (CC) – ISO/IEC 15408 standard through theSmartcard Industry (card issuers - service providers –product’ s manufacturers - software providers evaluation facilities - certification bodies etc …) for theevaluation and the certification of products and systems,
to provide trust and confidence to the smartcard users.

MPG – PTSC0010 – 010 – 2613SC-TB3

Strategyq To this purpose: the group will elaborate a framework
to facilitate the process (product development evaluation – certification …) of using the CC in a cost
and time effective way to support internationallyrecognised certifications.

MPG – PTSC0010 – 010 – 27

SC-TB3

Objectives & Schedule (1)q List of current issues in using CC in a cost & time effectiveway.
Common document:

End Q1-2001

q Propose possible solutions
Common document:

End Q3-2001

q Proof of concept:
Evaluation/Certification on apratctical example

2002

MPG – PTSC0010 – 010 – 28

14

SC-TB3

Objectives & Schedule (2)Promotion & Educationq

Establish communication plan:qPromotion & education:

End Q-1 2001

Start: Q2-2001
End : Q4- 2002

MPG – PTSC0010 – 010 – 29Conclusion
q CC is still at the innovation stage and have not yet been largely
e n d o r s e d.
More active participants are welcome … .

q CC can only work if a c o m m o n m e t h o d o l o g y for smartcards evaluations
is in place.

q This methodology is not wideley shared and recognized.
q CC can be viewed (a n d u s e d ) as an industrial espionage toll.
q « Security is n o t a b o u t technology but p r o c e s s a n d m e t h o d o l o g y on
how to implement technology » - (Bruce S c h n e i e r).

MPG – PTSC0010 – 010 – 3015